Support working with SLSA statements (without wrapping)

[fmoessbauer]

The SLSA attestation model [1] defines a "statement" as an in-toto attestation, e.g. as "https://in-toto.io/Statement/v1" [2]. This statement contains both the predicate (e.g. "provenance" / "cyclonedx") as well as the "subject", that defines for which files the predicate holds. It would be great, if the cosign tool could directly work with these json documents instead and just add the DSSEv1 envelope (+key handling, rekor uploading,...).

The current version of cosign only allows to work with raw predicates (--predicate), but these are wrapped into a https://cosign.sigstore.dev/attestation/v1. The output then contains the original predicate in Predicate.Data, which hides it from tooling that directly works on the predicates.

Another alternative would be to split the cosign workflow into the certificate fetching part and the upload to rekor part. Then, the creation of the DSSEv1 (which is rather trivial) could be done by other tooling.

• [1] https://slsa.dev/attestation-model
• [2] https://github.com/in-toto/attestation/blob/main/protos/in_toto_attestation/v1/statement.proto

[fmoessbauer]

Let's formalize this a bit. The most important aspect hereby is to clearly define the interface between the application which generates the SLSA statements and the signing / verification.

Use-Case:

• a non sigstore component generates SLSA statements: this statement must include zero or more subjects (the spec is a bit imprecise w.r.t zero subjects)
• The statement is passed to cosign to sign it and upload to rekor
• For verification, the generated DSSE + a search path is passed to cosign to check if all artifact checksums match (+ certificate / key material, as already implemented)

Proposed solution (signing):

• extend the cosign attest-blob command
• add --statement flag
• if --statement is set, the <BLOB> is considered to be a statement and cosign operates on the internals. No need to re-compute and check file hashes. Only syntactic validation shall be performed on the <BLOB>.

Proposed solution (verification):

• extend the cosign verify-blob-attestation command
• add --statement flag
• add --path option (can be specified multiple times) to set the artifact search path
• if --statement is set, the <BLOB> is considered to be a statement and cosign operates on the internals
• on execution:
  • validate integrity of DSSE (already implemented)
  • extract all subjects (these should be ResourceDescriptor with a digest)
  • for each RD, check if any artifact in the --path has a checksum that matches. Note, that the artifacts are matched purely by digest, regardless of content type (and name? Spec is imprecise). Consider adding a "digest kind" and/or "content type" to subject in-toto/attestation#28

Alternative implementation:

• use dedicated commands for this mode of operation
• in verification step, let user pass filenames to avoid the complexity around the discovery and matching by checksum only.

Closing words:

It would be great if someone more familiar with the SLSA / in-toto attestations could have a look at the ambiguities in the spec (mentioned above). Maybe that's just due to my imprecise reading of the spec, but if it is really imprecise or unclear, we should improve the spec as well. Anyways, I'm happy to hear feedback.

[haydentherapper]

cc @laurentsimon