Cosign support for SLSA Source Track

[steiza]

Description

The draft of the SLSA Source Track includes an example in-toto statement. What are the gaps required to cover for cosign to be able to sign and verify these statements?

For signing, the attest-blob subcommand is close to what we want. It lets you specify the path to the predicate contents with --predicate and the predicate type with --type, but we don't have a way of setting the subject to match the example. And of course we'd use --new-bundle-format=true --bundle to get a protobuf bundle that the Sigstore clients have standardized on.

If we use attest-blob for signing, we should probably use verify-blob-attestation for verification. We'd use --bundle to supply the bundle from signing, but we also need some way to supply the hash we're expecting was used for signing (and again, likely it'd be SHA1 instead of SHA256). Here we have an advantage in that verify-blob-attestation will always use sigstore-go (which we already know can verify these in-toto statements) if a protobuf bundle is being used, but we need a way to supply the hash (and hash algorithm) to send to sigstore-go.

In this description of the problem, I am purposefully not suggesting solutions. But people should feel free to propose solutions in the issue discussion!

[steiza]

Alright, so here are some options on the attest-blob side:

Option 1: try to take advantage of as many existing flags as possible

cosign attest-blob --new-bundle-format=true --bundle output.sigstore.json --subject subject.json --predicate predicate.json --type="https://slsa.dev/verification_summary/v1"

The only flag added here is actually --subject, although the implementation needs to be reworked a bit to handle that case (we would skip attestation.GenerateStatement() and have to implement something to assemble the statement from the --subject, --predicate, and --type. Also you'd have to handle not requiring a blob when a --subject is provided instead.

Option 2: be more like sigstore-go

cosign attest-blob --new-bundle-format=true --bundle output.sigstore.json --attestation intoto.json

sigstore-go says that you, the user, are responsible for assembling the attestation and it will handle the rest. Instead of cosign being opinionated about the subject, predicate type, and requiring a blob, just pass the attestation you want signed and we'll sign it. This would be a departure from cosign's existing API, but it would be pretty easy to special case when the --attestation flag is provided, and maybe this is the direction we want to go in with the API anyways.

Here's what things would look like on the verify-blob-attestation side:

cosign verify-blob-attestation --bundle output.sigstore.json --hash c0ffee... --hashAlg gitCommit

Similar to signing, we've gotten rid of the required blob in favor of providing a hash. --hash is part of other cosign commands, like attest-blob. We also require specifying the hash algorithm, although note that this is used to key into the in-toto subject digest dictionary, not to select an algorithm for computation. gitCommit is what the SLSA Source track draft uses for the in-toto subject digest dictionary.

[steiza]

Back in February, @codysoyland made #4032 which is very similar to option 2 for attest-blob listed above.

[haydentherapper]

sigstore-go says that you, the user, are responsible for assembling the attestation and it will handle the rest. Instead of cosign being opinionated about the subject, predicate type, and requiring a blob, just pass the attestation you want signed and we'll sign it.

I talked about my preferences in #4019 (comment), which is aligned to how we've created the sigstore-go API. I'd much rather smaller tools that we compose, with each smaller tool implementing the spec. If there isn't a tool to compose an unsigned SLSA source track statement yet, then we should create one, but let it be maintained as part of the SLSA community. Cosign can take in the unsigned statement and return a bundle with the signed dsse_envelope (or, if we really want to keep Cosign agnostic to formats, it could just return the signature in the bundle, and let it be the responsibility of a DSSE library to compose the signature and payload and update the bundle, though that adds yet another tool to the mix). I think Cosign (and sigstore-go) should be minimally opinionated, and so I like the second proposal.

Requiring subject, type, and predicate is a requirement by SLSA. If we want to continue to have Cosign be a catch-all tool for SSCI (at least in the interim until we figure out if we want more tools under SLSA), then I think we shouldn't put these under cosign attest-blob, but under something like cosign attest-blob intoto ... or even a more precise cosign attest-blob slsa, but again, the more precise we get, the more we are requiring ourselves to implement specifications (with a goal of avoiding being opinionated and implementing only a part of the spec).

cosign verify-blob-attestation --bundle output.sigstore.json --hash c0ffee... --hashAlg gitCommit

I also like that this makes no assumptions on what hash algorithm is supported, though this would require specifying a subject as well I believe.

[haydentherapper]

Oh also, option 2 is what Tom proposed in #4019.