Cosign signing bundles

[patflynn]

Details of this proposal available in this Google Doc.

Summary

The current sign-blob command and documentation steer the user towards producing two files (raw sig and cert) for each signing operation. This is not ideal because:

• the two files do not contain enough information to enable offline verification.
• more files to store and pass as arguments is worse from a usability stand point.
• there is a lack of symmetry with the cosign sign command for OCI images which produces just one signing artifact.

These issues are likely to exacerbate inconsistencies across package manager and language ecosystems as each platform could produce a different combination of sig|cert|bundle.

Our proposal produces a default blob signing and verification path that produces just one complete artifact supporting all verification use-cases.

At this stage mainly looking for feedback/sanity check. Some details left to be worked out. Very happy to take suggestions for improvements.

[kommendorkapten]

This initiative is great, and as I'm working on a similar concept but for attestations, where the actual payload is captured in the signature file, I was inspired by this and so created this proposal: #2147.
As they are so similar, there came an immediate comment #2147 (comment) that we could actually compose these two proposals into one!
I would be very interesting to hear your thoughts on that, I think it's very compelling.

[patflynn]

Fantastic! Attestations was a distant blip on my radar for blobs but I was getting an uneasy feeling that they applied here. I'm very happy to see you connect the dots with this proposal. It makes complete sense to me that simple signatures couple be folded into some kind of attestation type so that we can use the same format across these very similar use-cases. Merging these proposals seem trivial at first glance assuming that the binary signature as an attestation makes sense to the sigstore experts.

@znewman01
@asraa
@haydentherapper

[kommendorkapten]

What would be the next step? I read through the linked google doc again, the Filespec table is what needs to be updated. The sections on cli signing and verification is still valid I reckon. The need we have right now, is not to introduce a new cli option (that can come at a later phase if it's desired). Aligning on detached, actionable signature files is what I would like to see now.

So the two attestations type known to me right now are:

attestation/blob

...
  "attestationType": "attestation/blob",
  "attestation": {
    "payloadHash": "87428fc522803d31065e7bce3cf03fe475096631e5e07bbd7a0fde60c4cf25c7",
    "payloadHashAlgorithm": "sha256",
    "signature": "B64(SIGNATURE)",
  },
...

attestation/dsse

  "attestationType": "attestation/dsse",
  "attestation": {
    "payloadType": "application/vnd.in-toto+json",
    "payload": "B64(STRING)",
    "signatures": [
      {
        "keyid": "",
        "sig": "B64(SIGNATURE)"
      }
    ]
  },

In this proposal, there is a version field, in the example I could find this: "dev.cosign.sig/version": "0.1", in the other proposal we had a mediaType. I'm fine with either, as long as it's uniquely identifiable.

[dlorenc]

It makes complete sense to me that simple signatures couple be folded into some kind of attestation type so that we can use the same format across these very similar use-cases.

The only real downside to using attestations for everything is that then you'll need DSSE, which means its a bit harder of a transtion for folks. You can't really directly verify it with openssl or other command line tools.

[znewman01]

You can't really directly verify it with openssl or other command line tools.

I'd argue that that's a plus—openssl can't verify the timestamps from Rekor, so it's a little bit of false security. Useful for debugging but we don't really want regular users doing this.

IMO if we want that functionality, it belongs behind a cosign inspect or similar command. So you could extract to get a vanilla signature, and then openssl verify that signature.

[kommendorkapten]

The only real downside to using attestations for everything is that then you'll need DSSE

This would only be true for the the attestation/dsse, for attestation/type would it would still work, albeit you would need extract that param via e.g. grep and friends or jq. Or were you thinking about the use-case when a SLSA attestation is signed as a blob? That could still be signed as a blob. This proposal as of now only changes the output signature file for the sign blob command, and only defines a "sigstore bundle" that can be used by more "integrated" clients, that e.g. can rely on Rekor too for extra verification.

[patflynn]

Seems like everybody is onboard. @kommendorkapten I just gave you edit access to the doc. Feel free to update or suggest changes to the spec and I'll fold them in.

[dlorenc]

Confirmed with @patflynn this doesn't require any changes to rekor, dropping ga-candidate.

[znewman01]

As an update: there is a draft of the signature file format in this repo: https://github.com/sigstore/protobuf-specs

We are experimenting with it in various Sigstore clients.

[znewman01]

We're ready to pull this into Cosign, gated behind a COSIGN_EXPERIMENTAL_BUNDLE env var.

[znewman01]

Closing as dupe of (newer but more concise) #3139