How should DSSE Envelope Signatures work with a Timestamp Authority?

[steiza]

Description

Sigstore bundles using DSSE Envelopes can have one or more signatures: https://github.com/sigstore/protobuf-specs/blob/main/protos/envelope.proto#L41.

When we send a request to a Timestamp Authority, it should include a hashed message derived from the signature(s).

Today in sigstore-go, we assume your DSSE envelope has one signature, and the corresponding timestamp verification data is a hash of that one signature (see https://github.com/sigstore/sigstore-go/blob/75b405ded9aee87afa3c29facd08effbd35e43b2/pkg/bundle/signature_content.go#L100). But in the future, we want to support DSSE envelopes with more than one signature.

It would be nice if we came up with a standard behavior across clients. This issue was first raised on sigstore/sigstore-go#158 (comment).

[kommendorkapten]

My initial feeling is to have one counter signature from a TSA for each signature in the DSSE envelope. Keeping them independent makes it it easy to verify if only a single signature over the DSSE envelope is trusted, as the other can safely be discarded without impacting the signatures from the TSA. Also by treating them independent we don't need to deal with any canonicalization of the signatures. And a signature can be dropped from the envelope without affecting the others that are kept.

This would mean that a client must try to match them together as we can't rely on the order. But as the number of signatures is small, running a N^2 alg to verify them should not pose a problem here.

[loosebazooka]

Update: The current consensus from the sig-clients meeting is that we will

1. only accept 1 signature for now
2. fail if multiple sigs are found
3. figure out the multi-signature issue later

[adityasaky]

Re multiple signatures: secure-systems-lab/dsse#61 (comment)

We're working on upstream support for additional verification materials on a per signature basis. For sigstore, this currently proposes uses the existing verification_material message that's included in a sigstore bundle. On that PR, I proposed that the tooling invoking a sigstore client could massage each signature (with its verification material) into the sigstore bundle format to verify the signature using the sigstore client rather than potentially fragment formats in sigstore tooling. However, if there's interest in natively supporting multiple signatures in a DSSE envelope in the future, I think it would make sense to converge on the upstream extensions spec? 😄

I think this would also address having a TSA signature as part of the verification material on a per-signature basis in an envelope.

[kommendorkapten]

Nice @adityasaky!

The reason we are limiting now to a single signature for each envelope is primarily based on:

1. The bundle format and verification becomes much more complicated. Especially the verification logic will become hairy w.r.t thresholds of signatures, and the thresholds of the countersignatures for each of the signature.
2. No currently known use-case of multiple signatures in the Sigstore ecosystem.

If there is a strong scenario in the future that mandates multiple signatures, we may of course reconsider this. But one of the goals is to limit the complexity to simplify the signing and more importantly the verification flows to make it harder to introduce security flaws.

Not related but a similar limitation we have applied is related X.509 certificates, where we in the latest (v0.3) bundle format only permits leaf certificates. Intermediate certificates are not allowed which is a deviation from many other X.509 PKI deployments.

[adityasaky]

Apologies for posting to a closed issue.

@kommendorkapten, I think we're largely in agreement! For a multi-sig scenario, I'm proposing that the serialization format could be DSSE + extensions, while the verification of each individual sigstore signature in the envelope could be done via a sigstore client, possibly by creating a bundle on the fly. This would happen at the layer above the sigstore client, say witness (cc @jkjell) or github tooling for the use case described in the body of this issue. I think this is compatible with what you're saying, and I in fact agree that the sigstore client may not be the right place to reason about verifying multiple signatures because it's probably not the right layer to reason about thresholds, nor should it have to figure out how to verify non-sigstore signatures that may also be in the envelope. The tooling at the layer above can reason about whether to invoke the sigstore client or not as well as keep tabs on the number of successfully verified signatures etc.