Add support for release attestations

[steiza]

Description

We are working on adding an in-toto predicate for release attestations.

There have been discussions about what information should live in Fulcio code signing certificate OIDs vs in the in-toto attestation, and in those discussions @trishankatdatadog asked about how Fulcio might support release attestations.

Today many of the workload identity providers in Fulcio's config IssuerType correspond to the provenance predicate (like IssuerTypeBuildkiteJob, IssuerTypeGithubWorkflow, and IssuerTypeGitLabPipeline). End users are the ones creating in-toto attestation documents with the provenance predicate, and as a result the issued Fulcio code signing certificate contains many properties from the build platform in OIDs, so the user-contributed information in the in-toto attestation document can be verified. Adding a new platform can be a fair amount of work as we map properties from that platform to the OIDs (see https://github.com/sigstore/fulcio/blob/main/docs/oid-info.md).

But release attestations aren't directly accessible to end-users, and so we don't need to encode any information in OIDs. It should be fairly straightforward to add a generic IssuerTypeRelease, and then we could onboard platforms that issue release attestations with a configuration change.

If this sounds reasonable to folks, I'm happy to post a draft PR with implementation details.

[steiza]

After the Sigstore TSC meeting this week, I thought I'd add some details about possible alternative approaches.

Should Fulcio code signing certificates include OIDs for release attestation properties like we do for SLSA provenance?

I'm leaning towards "no" but I'm open to discussion.

The major difference is that CI/CD workload identity's first purpose was to assume into a cloud provider, or do something like trusted publishing, so the end-user needed to have access to the OIDC token. Like we state above, this means the end-user is involved in the SLSA provenance flow and so we need to distinguish between user-contributed content (the in-toto attestation document) and content that we can trust from the CI/CD platform (like the signed OIDC workload identity).

But for release attestations, we're proposing that the platform handle the entire flow of interacting with Sigstore. In that case, there won't be user-contributed content that we need to double check, and so we don't need to require that information to also be in the Fulcio code signing certificate OIDs. There are a variety of opinions on if it should be there, discussed on slsa-framework/slsa#1019.

Should Fulcio support generic issuer types?

This time I'm leaning towards "yes" but I'm also open to discussion.

If there isn't per-provider content we need to map from OIDC tokens into issued certificate OIDs, there really isn't that much to a IssuerTypeRelease, and conceivably we could make a generic implementation instead of making a IssuerTypeNpmRelease, IssuerTypePypiRelease, etc. This would be nice because then we could onboard new platforms with a config change instead of a code change, but I'm fairly new to the Fulcio code base and so there might be some subtleties I'm missing here. Of course, if we decide we do want OIDs for release attestations, then we probably need per-provider implementations, like we do for CI/CD providers and SLSA provenance.

[haydentherapper]

I wrote up a post then re-read what you wrote and realized I was saying the same thing, so now this is shorter 😄

Should Fulcio code signing certificates include OIDs for release attestation properties like we do for SLSA provenance?

I agree with this being "no". The motivation behind providing provenance claims within a Fulcio certificate was because what signed the build provenance is not the same as a destination of the artifact, so we used Fulcio as an intermediary. In the case of release attestations, the signer is the same as where the release attestation will live, so we don't need a secure intermediary to pass through values.

Should Fulcio support generic issuer types?

To test this with an alternative using what already exists, what if the package registry managed a signing identity and fetched a code-signing certificate that only includes its identity as an email or username certificate identity type? This looks a lot like a generic issuer. Are we asking too much on package registries to manage an additional OIDC provider when they could manage an email instead?

One reason in support of this, to avoid a generic issuer and have a per-package-repo issuer, would be to mitigate impersonation for a given deployment. The configuration can require a 1-1 mapping between an issuer release type and its OIDC issuer URL. This however makes Fulcio quite opinionated and is somewhat contrary to the direction we'd like to go, to rely on automation for OIDC issuer registrations as much as possible.

[bdehamer]

@haydentherapper

what if the package registry managed a signing identity and fetched a code-signing certificate that only includes its identity as an email or username certificate identity type? This looks a lot like a generic issuer. Are we asking too much on package registries to manage an additional OIDC provider when they could manage an email instead?

I'm intrigued by this, but not sure I quite understand. Can you explain a bit more about how this would work? I see that Fulcio supports some fairly simple issuer types but is there a way to use these which doesn't involve setting-up an OIDC provider?