Open fmoessbauer opened 3 months ago
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:
Proposed solution (signing):
cosign attest-blob
command--statement
flag--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):
cosign verify-blob-attestation
command--statement
flag--path
option (can be specified multiple times) to set the artifact search path--statement
is set, the <BLOB>
is considered to be a statement and cosign operates on the internalsResourceDescriptor
with a digest)--path
has a checksum that matches. Note, that the artifacts are matched purely by digest, regardless of content type (and name? Spec is imprecise). https://github.com/in-toto/attestation/issues/28Alternative implementation:
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.
cc @laurentsimon
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 ahttps://cosign.sigstore.dev/attestation/v1
. The output then contains the original predicate inPredicate.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.