It makes sense to build CredHub for many reasons. A few that come to mind
quickly are below.

1) The service must start and restart without human intervention. This
immediately means the key encrypting key resides in a Hardware Security
Module (HSM) of some kind. We think this is a first-class feature and
should be part of CredHub open source.
2) CloudFoundry runs in production in some of the most restricted
environments in the world. These environments tend towards favoring crypto
stacks they have seen and reviewed before. The Java ecosystem contains
several. The Go ecosystem will eventually get there, but it isn't right
now. We're fully aware there are tons of great Go apps (including large
chunks of CloudFoundry) that perform crypto today. We received credible
feedback that showed a Java preference for this type of application.
3) Authorization is an important part of credential management in CF.
Authorization can be an incredibly difficult problem, and an authorization
implementation can be very hard to change after it is built. We didn't see
anything available that had the right feature set. We could have bolted
something in front of another product, but we decided it made more sense to
build something new.

MVP certainly requires hitting a threshold of capabilities, but it also
requires leaving runway for what's ahead.

App secrets are a mainline scenario. Let's take it as a given that apps
must have access to plaintext secrets. From there, the discussion centers
on two questions: 1) what's the chain of custody of the secret and what has
access to it, and 2) how is the secret made available to the app. (1) is
all about CredHub and (2) is mostly about Diego. We'll engage in a
discussion on these in the weeks ahead.