Closed shibumi closed 1 year ago
This is definitely on the roadmap, but not on our critical path right now as our reference architecture utilizes SPIFFE/SPIRE. We would accept any PRs adding support for Fulcio generated certs.
I don't know if this is a feature for witness or for in-toto-golang. As far as I understand the code in witness, you are not using in-toto-golang's signing features at all, right?
We're not importing in-toto-golang's signing code but all of the signing schemes and what not should be compatible with in-toto-golang's. Using RSA-PSS by default, for example.
As Cole mentioned cosign's OIDC issuer is definitely of interest for us. I believe SPIFFE/SPIRE is a better solution for workload identities in high compliance environments but it isn't as nice for human interaction, where this wins out.
Code sample on how to fetch a cert from fulcio here: https://github.com/sigstore/fulcio/pull/324
We will need to get Fulcio set up to work on this issue.
First MR will be to support witness sign
to enable OIDC signing of policy.
We support Fulcio keyless, I'll open other issues specific to Rekor and CA/timestamp policy verification
I am reading the code for the signature generation right now. I see that we are using x509 certificates for signing already. Would it make sense to support keyless signatures via OIDC-issuer, either via Email-based OpenIDs or via Workload Identities. The first would make sense if a human signs the attestations. The latter makes sense if witness runs in a CI environment and there should be no interaction that needs manual intervention.
If you are not up to date with keyless signatures here is a short walkthrough:
You might know the OpenID Connect standard. The OpenID Connect standard allows identifying yourself via your email to a foreign system. For example, when you login into a new website via your Github ID you are doing this via OpenID Connect.
The sigstore project is currently pushing the idea that we could use this user identity to generate an ephemeral certificate key pair for signing operations. This has the huge advantage that the user does not need to care about private key management at all. No keys in a cold storage, no key backups, no potential key leaks. The only thing the user has to care about is securing their Identity, for example via 2FA.
Workload identities are working the same way. The only difference is that a workload identity is coupled to the CI Pipeline. In terms of Github Actions github will create a token, only valid for this one pipeline run, and sigstore uses that token to generate an ephemeral key pair and so on.
The cosign library manages most of this (including uploading the signature(s) to the rekor transparency log). The transparency log can be compared to a https certificate transparency log... it tracks all signing operations + stores the used public certificate and a digest of the artifact.
On the long term I would like to have this feature in in-toto-golang as well, but unfortunately I am afraid, that we need to make huge changes in in-toto-golang. First step could be a Signer interface (right now most signing operations are pretty much hard coded).
I don't know if this is a feature for witness or for in-toto-golang. As far as I understand the code in witness, you are not using in-toto-golang's signing features at all, right?