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.