attestation
attestation copied to clipboard
in-toto
Support subjects that are not digests
We have use cases where we need to refer to subjects that cannot be describe by a cryptographic hash. Example: Subversion repository revision, which is only identified by URI. We'd only want to support things that are semantically immutable.
Another use case: attestation on a builder, where the subject is the builder ID. An auditor can, e.g. describe SLSA requirements that are met for all builders having that builder ID.
This information should not go in the provenance itself because it is metadata about how the provenance was generated. No one should ever trust that field. Either the consumer believes it to be true already (so they don't need the field) or they don't (so they ignore the field). But having an attestation on the builder would be great.
One potential concern is related to #81: how do we know that the meaning of the builder ID doesn't drift over time? My intuition is that we can't. We just have to trust it. For example, if an auditor reviews a build system and certifies that it generates provenance non-falsifiably, there may be a future change that breaks that guarantee. But I think we have to accept that and maybe re-certify over time. It's not really feasible to hash the entire trusted computing base on which the attestation rests, and even if it were, it's likely not meaningful. An auditor wouldn't review every single change to every single dependency, thus we have to just trust that implementations don't drift substantially over time.
In terms of implementing this, we could add support for a uri subject, which would support most use cases.
A tricky question is what the semantics are when both uri and digest are set. Must the consumer verify both? What if they only have one to verify against? A simple workaround is to disallow that case, at least for now. You can set either field but not both, which is unambiguous. Once we have some concrete use cases for having both set, then we can figure out what the semantics should be.
I'm proposing a solution with "Proposal: support subjects that have no digests #92". The basic idea is to allow a subject.uri (a resourceURI) instead of a subject.digest.
Bumping this issue, since this is also relevant to #112 I just opened. The use case I'm concerned with is referencing artifacts or attestations within other attestations, and being able to validate both the integrity of the subject as well as locate it at the URI. I think it would be useful to (1) add the optional URI field to the subject, and (2) generalize the subject field type to something like the object reference proposed in section 3 of the SCAI spec.
EDIT: This also relates to https://github.com/in-toto/attestation/issues/2. I also describe an example use case in that issue that would benefit from being able to use the subject field type to reference other attestations within an attestation.
@marcelamelara could you provide a concrete example in JSON of how this would be used and what the semantics would be?
@MarkLodato apologies for the delayed response. Here's a concrete example for an attestation with subject that contains both a digest and a URI:
{
// Standard attestation fields
"_type": "https://in-toto.io/Statement/v0.1",
"subject": [{
"name": "gcc9.3.0",
"digest": { "sha256": "78ab6a8..." },
"locationURI": "http://us.archive.ubuntu.com/ubuntu/pool/main/g/gcc-defaults/gcc_9.3.0-1ubuntu2_amd64.deb"
}],
"predicateType": "scai/attribute-report/v0.1",
"predicate": {
"subjectAttributes": [{
"attribute": "IMPLEMENTS_STACK_PROTECTION",
"conditions": { "flags": "-fstack-protector*" }
},
{
"attribute": "REPRODUCIBLE",
"evidence": {
"name": "rebuilderd-attestation",
"digest": { "sha256": "abcdabcde..." },
"locationURI": "http://example.com/rebuilderd-instance/gcc_9.3.0-1ubuntu2_amd64.att",
"objectType": "https://in-toto.io/link/v0.1"
}
}]
}
}
This is a new proposed predicate type, the goal is to be able to attest to specific security attributes of binaries. In this case, if we want to attest to the gcc v9.3.0 binary. We assume that the gcc binary is shipped separately from the attestation (say, via apt and sigstore, respectively).
Semantics: The attestation is about the gcc binary located at the locationURI. The digest is used to match the retrieved gcc binary with the attestation subject.
BTW, regarding object references more generally, the Artifact Reference in the new SLSA provenance https://github.com/slsa-framework/slsa/blob/e60f7426f501f34e8b41e9b4da594bb7ec1c57bb/docs/provenance/v1.0.cue#L37 is precisely the kind of pattern I'm proposing we formalize as well.
@marcelamelara Is that a "location hint" so to speak, where it's just informing where you could download the artifact, or is it actually required to match BOTH digest AND uri?
@MarkLodato it's more supposed to be a "location hint", but only the digest must match in my model. So, if the consumer already has the artifact, and it matches the digest, we could assume that the attestation applies to the artifact.
I believe this is addressed by #212 . @MarkLodato Please let me know if you disagree.
No, #212 kept the semantics the same: digest is still a required field and validation.md still says that you match on digest.