Support DSSE-style enveloped signatures

[woodruffw]

This is part of Sigstore bundle support: we currently only support "raw" signatures, while some users of Sigstore may chose to use enveloped DSSE-style signatures.

From protobuf-specs:

// An authenticated message of arbitrary type.
message Envelope {
  // Message to be signed. (In JSON, this is encoded as base64.)
  // REQUIRED.
  bytes payload = 1;

  // String unambiguously identifying how to interpret payload.
  // REQUIRED.
  string payloadType = 2;

  // Signature over:
  //     PAE(type, payload)
  // Where PAE is defined as:
  // PAE(type, payload) = "DSSEv1" + SP + LEN(type) + SP + type + SP + LEN(payload) + SP + payload
  // +               = concatenation
  // SP              = ASCII space [0x20]
  // "DSSEv1"        = ASCII [0x44, 0x53, 0x53, 0x45, 0x76, 0x31]
  // LEN(s)          = ASCII decimal encoding of the byte length of s, with no leading zeros
  // REQUIRED (length >= 1).
  repeated Signature signatures = 3;
}

message Signature {
  // Signature itself. (In JSON, this is encoded as base64.)
  // REQUIRED.
  bytes sig = 1;

  // *Unauthenticated* hint identifying which public key was used.
  // OPTIONAL.
  string keyid = 2;
}

...where payload is the to-be-signed attestation statement.

xref sigstore/fulcio#1131

Work tracker:

• Add sigstore-rekor-types (rekor: use sigstore_rekor_types for models #788)
• Use sigstore-rekor-types to provide DSSE creation and retrieval support in our Rekor bindings
• Expose DSSE signing via the Python API (API-level DSSE signing support #804)
  • sigstore/sign: sign API takes bytes, not I/O #921
• Expose DSSE verification via the Python API
  • sigstore: prep verify APIs for DSSE #904
  • sigstore: use our own Statement type #930
  • Initial DSSE verify APIs #962
• (Maybe?) expose DSSE signing and verification via the sigstore CLI

[woodruffw]

xref sigstore/fulcio#1131 for original motivating context.

[woodruffw]

Starting on this now -- we'll need it for uploading and retrieving build provenance attestations for Homebrew.

[woodruffw]

Thinking about this some more, I think the "right" way to do this is similar to what sigstore-js has done:

1. We need a new sigstore-rekor-types (or similar) package that exposes Rekor's OpenAPI types as Python types
2. We should use sigstore-rekor-types here to standardize our interactions with Rekor's REST API (maybe replacing our homespun client entirely?)

[TomHennen]

Will this be based on this work? (Apologies if I should have know that already, the change is spread out across a number of places)

[woodruffw]

Will this be based on this work? (Apologies if I should have know that already, the change is spread out across a number of places)

I haven't had a chance to look at that recently, so I'm not sure 🙂. I'll try and take another look this afternoon/evening.

As a roundabout way of answering: the Sigstore clients are generally producing/consuming Sigstore bundles as their top level "unit of work," so signing is likely to continue doing that. For verification, we'll want to support a Sigstore bundle containing a DSSE-formatted signature, but we may also support the inverse form (DSSE containing a Sigstore bundle).

(But all of that is entirely up in the air -- first I need to actually get the data models working, followed by adding client-side support for Rekor's DSSE type, etc.)

[woodruffw]

I've created https://github.com/trailofbits/sigstore-rekor-types to supply auto-generated models for Rekor's types.

[jku]

xref sigstore/fulcio#1131 for original motivating context.

Could you expand on this and the use case in general -- I assume you want to create attestations over the same content but with different predicate data? I assume we want to implement this inside sigstore-python since rekor supports in-toto attestations, correct?

How does this work in the verifying side (e.g. how does the predicate content get verified)? Do you expect this to be done by some intoto verification system? I think cosign has something builtin (cosign verify-attestation --policy policy.rego ...)

Am I correct that this is more accurately "Support intoto attestation signing" than DSSE -- in-toto just happens to use DSSE? Non-intoto use cases don't make sense here, right?