[Proposal] - Better added value for Vault (or OpenBao)

[gillg]

Current situation

Hashicorp Vault, or its fork OpenBao are designed to securely store self-hosted secrets and provide an auditable access to them.
One of its power resides in the multiple kind of secrets it can host via engines. The base is obviosly a simple key value database, and it's what this current notation plugin supports. But plenty of other tools are doing that, cloud managed, local, self managed, because encrypting key/values strings is the base, but not really a challenge. Using Vault just for that is probably a missunderstanding of what can be done.

Storing a private certificate signature key on it, means you generated it localy, and nothing proves that key were not shared before in an internal wiki/git/whatever, and any admin of vault (at the minimum) can exfiltate the key in the future. You have no way to know if it has been used outside of your supply chain, once you discover it it's too late...

Proposed improvement

As we consider users of this plugin already have a Vault (or are able to manage a vault), the PKI secrets engine fits a lot more for a secure code signing.
Using PKI engine instead of key/value, you can generate a CA cert and private key directly on vault (not locally with openSSL) without never having access to the private key.
Then you call the /sign API to derivate sub signing keys with a short life time. That means we get the private key locally (like with kv) but it can't be stollen and reused later thanks to the short life. In the trust policy of Notary, you trust your root certificate from Vault and its derivate "short life" signature certificates.
Limitation: you can't use a cert provided by a public root CA as you can't import the private key or make a CSR.

Example https://www.hashicorp.com/blog/code-signing-with-hashicorp-vault-and-github-actions

Alternatives / future steps

If you use Hachicorp vault enterprise, you can even ask for EV CodeSigning certs to a public CA because your vault can be FIPS 140-2 level 2 (required for a public EV cert).
And maybe thanks to the enterprise feature EST https://developer.hashicorp.com/vault/docs/secrets/pki/est it could be possible to generate a leaf cert (instead of a CA), and get the CSR from it then re-import the final issued cert inside vault.
This is what is possible also via "Azure KeyVault", but the main benefit of Vault is the cloud agnostic and self-hosted approach.

[cipherboy]

@gillg Some good news, and some bad news!

Bad news: neither OpenBao nor Vault allow you to accomplish this step:

Using PKI engine instead of key/value, you can generate a CA cert and private key directly on vault (not locally with openSSL) without never having access to the private key.

The PKI engine is not a usage engine (i.e., it does not hold certificates on behalf of callers), it is a Certificate Authority and thus simply creates certificates.

The issue endpoints return and do not store the key material. It is up to the caller to do so and would merely replace the OpenSSL step.

---

That said, the good news is that both OpenBao and Vault have a solution to this: Transit. This is a Key Management System (KMS) type solution with support for PKI Cert association: https://openbao.org/api-docs/secret/transit/#sign-csr + https://openbao.org/api-docs/secret/transit/#set-certificate-chain

This will let you generate key material within OpenBao, create a CSR for some to sign, import the final certificate, and use the corresponding key material whenever desired. K/V thus isn't necessary.

I had mentioned it here: notaryproject/.github#26 (comment) and @Gabrielopesantos subsequently implemented it in Vault and ported the feature to OpenBao.

I think a PR in this direction would definitely be welcome!

---

The interesting question is what our version compatibility policy is. AFAIK we have not yet done a release so we could do things correctly now, given the feature exists in both places. But we might also run afoul of our external version compatibility promises (e.g., to integrate with all supported releases rather than just the latest of 3rd party software). I think Vault 1.15 is getting old (based on https://endoflife.date/hashicorp-vault it is no longer supported), so we could perhaps be fine with this.

Thoughts, @FeynmanZhou ?