Support the protobuf bundle format in Cosign

[haydentherapper]

Background

Sigstore created a common format in sigstore/protobuf-specs for the output from Sigstore clients. sigstore-python, sigstore-java and sigstore-js currently support the bundle format. Golang currently does not support the bundle: sigstore-go is under active development, and Cosign has defined its own format.

Requirements

• [P0] Output bundle for cosign sign-blob or cosign attest-blob
• [P0] Read bundle for cosign verify-blob or cosign verify-blob-attestation
• [P0] Verify conformance with other clients

Secondary goals

• [P1] Persist bundle in OCI image manifest for cosign sign
• [P1] Persist bundle in OCI image manifest for cosign attest
• [P1] Read bundle from OCI image manifest for cosign verify or cosign verify-attestation

Nice to haves

• [P2] Separation of utilities in a dedicated package to make it easy to move code to sigstore-go
• [P2] Support for uploading a bundle to OCI with cosign attach

Resources

• Bundle specification
• Rekor output to protobuf library

Justification for sign-blob being a P0 and sign being a P1 is that OCI handles storage already, so it's less critical to have a new format.

[wata727]

@haydentherapper I'm interested in working on this. Can we move this forward?
If you don't have any other blockers, I can open a pull request after tweaking the patch d652a11

A summary of this patch is:

• Introduce pkg/cosign/bundle.SignedEntity instead of cosign.LocalSignedPayload.
  • In order to cut out a dedicated package to sigstore-go that will generate a Sigstore bundle in the future, I thought we would need a struct that satisfies an interface like sigstore-go/pkg/verify.SignedEntity.
  • A side effect of introducing this is that we can refactor to use this entity for creating a Cosign bundle.
• Introduce pkg/bundle package.
  • This package is intended to be moved to sigstore-go in the future and accepts the SignedEntity interface as an argument to Build method.
  • This interface is almost the same as sigstore-go/pkg/verify.SignedEntity, but has been copied to avoid adding sigstore-go dependencies on Cosign. We can also add and replace the sigstore-go dependencies if you wish.
• Add --sigstore-bundle flag to sign-blob command.

This patch is a work in progress, and if you agree with the direction, I could add support for attest-blob and verify, refactor redundant implementations, add tests, etc.

Having said that, I'm concerned about the following points at the moment:

• Handling of the root certificate
  • As I was proceeding with this implementation, I noticed bundle support for sign-blob #3138 (comment). I did some research, but I couldn't figure out a pattern that would actually return anything other than a leaf certificate.
• Public key hint
  • In the current implementation, the Hint field is always empty when returning a public key. When I looked at the implementations of sigstore-js, sigstore-python, and sigstore-java, they didn't seem to generate hints either. Is this okay?
  • According to the spec, it says "The format of the hint must be agreed upon out of band by the signer and the verifiers" but it is my understanding that there is no consensus across the Sigstore ecosystem yet.
• Package interface compatibility
  • I ended up choosing an interface centered around sigstore-go/pkg/verify.SignedEntity, but I'm not sure if this is appropriate. It may be arguable to add this as a public interface if there is not already enough discussion to design a suitable interface.

[haydentherapper]

Hey @wata727, sorry for the delay, I will reply to this next week! I do have lots of thoughts on this and really appreciate you taking a look!

[cmurphy]

@wata727 are you still working on this? Do you want to go ahead and submit your patch as a PR so it can be reviewed?

This interface is almost the same as sigstore-go/pkg/verify.SignedEntity, but has been copied to avoid adding sigstore-go dependencies on Cosign

My understanding is eventually cosign will leverage sigstore-go more and more, so it should be fine to add as a dependency.

[wata727]

My original motivation was solved by GitHub introducing Artifact Attestations, so to be honest I don't have any motivation to move forward with this right now. So if you have your own plans, feel free to reject my patch.

However, if you think my patch could be useful in your work, I'd be happy to submit a PR.