Supporting DSSE Signature Extensions as an alternative to the Sigstore Bundle

[adityasaky]

Description

This is related to issue #8, opened after a discussion with @mnm678. In that issue, we started discussing the proposal for DSSE signature extensions (secure-systems-lab/dsse#61) to embed verification materials for a sigstore signature alongside the signature itself. The other discussion point there is to serialize the sigstore bundle itself as JSON and transmit / store the resulting file. However, this has challenges in a few cases.

First, when a DSSE envelope contains multiple signatures, it’s not clear which signature the verification materials refer to. This will be the case for use cases such as most TUF metadata or in-toto layouts. If all signatures are issued by sigstore, each signature needs to be associated with distinct tlog entry IDs. Also, while they may all share the same cert chain today, that may not be the case in future. However, the bundle format only has space for one cert chain. It makes more sense to associate verification materials with each signature rather than at an envelope level.

Second, when we have multiple signatures, only a subset of them may be sigstore signatures. In these cases, we need both sigstore verification info and the public key ID hint. DSSE signatures can already include the key ID, but it does mean that clients have to get some verification info from the bundle and others from the envelope. This can complicate client logic. There’s also a question in a completely non-sigstore case where the bundle can only include a single key ID for multiple signatures. Also, we generally have two unauthenticated public key hints (in the bundle and in the envelope) that may or may not match, further complicating client behavior.

Finally, the bundle sometimes acts like a signature envelope with a payload (when it embeds a DSSE file) and at other times does not (when it only includes a raw signature with an unauthenticated digest of the message). This means that a serialized sigstore bundle can’t trivially be used in place of a DSSE file in cases like an in-toto attestation bundle where each entry is an attestation because the user cannot be sure it contains the DSSE envelope until after parsing.

Supporting DSSE’s Signature Extension

We propose using DSSE’s signature extension capabilities for sigstore. While that’s currently an open PR, it’d be great to get some momentum there from the sigstore maintainers to ensure the proposal works for sigstore use cases. In the extension, each sigstore signature is associated with its verification materials using the format defined by sigstore already. Non sigstore signatures are associated optionally with an unauthenticated public key identifier, supported in DSSE from the start.

Given that some clients already support the serialized format of the sigstore bundle, we’re trying to understand if it is also possible to start supporting DSSE's format. We’re also trying to understand the aims of the clients. If the idea is to support verifying arbitrary sigstore signatures on DSSE envelopes, we believe the multiple signature issue will be encountered sooner rather than later.

As the signature extension for sigstore reuses the verification materials definition, would it be a lot of work to add in support for that? In the long term, does it make sense to switch the default over from the bundle?

[znewman01]

Thanks for the thorough write-up. Added this to the agenda for the Sep. 5 clients meeting. We can also discuss async as that's a ways away.

Conceptually, I think viewing the Bundle->VerificationMaterial+signature as a (really complicated) signature makes sense. In that case, the Bundle is really just an envelope. And then using DSSE instead of inventing yet-another envelope format also makes sense. Whether it's worth the transition costs is another question but certainly worth discussing.

[znewman01]

@mnm678 and I just had a conversation about this. Our thoughts:

• The Sigstore bundle format is doing two things: (1) it's a signature envelope for Rekor Types that do not themselves function as a Sigstore-compatible envelope (which includes DSSE before Add support for signature extensions secure-systems-lab/dsse#61 winds up getting merged, in fact), and (2) it's a meta-format for wrapping a bunch of different Rekor Types.
  • We believe that (2) is actually Bad and Confusing (TM). This aspect is what leads to the concerns about conflicting information coming from the DSSE envelope and the bundle.
• It actually makes a whole lot of sense for DSSE-native verifiers/signers to use DSSE itself, with no support for the bundle format except that the verification materials from the bundle need to get embedded as a DSSE signature extension.
• So maybe the move is:
  1. Have Sigstore clients review Add support for signature extensions secure-systems-lab/dsse#61 to make sure it's adequate.
  2. Disallow DSSE+signature extensions in the bundle.
  3. (Optionally) discourage DSSE without signature extensions in the bundle, in favor of upgrading to DSSE+signature extensions.
• In general, the rule should maybe be that we should avoid putting envelope formats inside meta-envelope formats. That is, if an envelope format is Sigstore-friendly, it MUST NOT go in the bundle. If an envelope format is not Sigstore-friendly, we MAY put it in the bundle, but should be really careful about interactions between redundant data.

[adityasaky]

I think that makes sense, starting with a review of the DSSE PR would be great. What would step 2 and 3 look like in action?

PS: On that note, while re-using VerificationMaterials may be simpler to start off, your points also make me think we could define a subset of that for the DSSE extension that gets rid of the keyID field.

[znewman01]

I think that makes sense, starting with a review of the DSSE PR would be great.

Awesome, I'll tag a few folks in.

What would step 2 and 3 look like in action?

Mostly docs and changes to the spec. We'll leave this open until that time.

PS: On that note, while re-using VerificationMaterials may be simpler to start off, your points also make me think we could define a subset of that for the DSSE extension that gets rid of the keyID field.

I think that's a solid idea too. We don't have backwards compat worries here so we should strive to do the right thing to start.

[adityasaky]

I think that's a solid idea too. We don't have backwards compat worries here so we should strive to do the right thing to start.

Shall I submit a PR to the proto definition with a DSSE extension that's a subset of VerificationMaterials?