Define a field for attestor identification

[AdamZWu]

An In-Toto attestation has several layers, e.g., DSSE, in-toto statement, and predicate. The DSSE layer is responsible for ensuring the data integrity, while the predicate layer delivers data intended for various purposes.

When verification takes place on an in-toto attestation, one security relevant check is: "is the entity that issued this attestation qualified to do so?" For example, two builders A and B each met different SLSA levels, it is unexpected for builder A to issue a build provenance that claims the build was done by builder B; it is also unacceptable for any builder to issue a VSA pretending their artifacts have been verified. So there are needs to verify the alignment between the attestors and signing keys.

Currently In-Toto does not define a field for attestor identification at the statement layer, so users (such as SLSA) resort to using the predicate fields. However, this introduces complexities in verifier design and implementation, due to the lack of standards for such a common needs. For example, SLSA VSA identifies the attestor as verifier, but build provenance uses the term builder; and within the provenance spec, v0.1/v0.2 and v1.0 places builder ID in two different locations, and it can move again in future revisions.

As a verifier, we either have to place the logic of "how to read out 'attestor' for every revision of every predicate type" into DSSE envelop validation, or we have to send DSSE key IDs into every type of predicate processing, and inject the logic "DSSE envelop can be signed by many keys, one of them must match the attestor". Neither way is neat.

A common "attestor ID" field in the Statement layer would make the whole situation a lot better, because it would allow the check to be done at the DSSE verification layer, without having to expose predicate-specific knowledge to it. (Or at the In-Toto statement processing layer, shared across all current and future predicate types and revisions.)

---

There may be an alternative: if In-Toto could specify a constraint on DSSE signing, limiting all signing keys must belong to one and only one attesator, then it effectively eliminates the need to separately identify the attestor, as we can simply map the key_id to an attestor.

However, this will also preclude use cases of multiple entity signing. (What use case I don't know, just to bring this alternative up for discussions. :P)

Also, there will be a new failure case of "multiple signatures with key IDs mapping to different entities", which may be a bit confusing to diagnose.

[adityasaky]

Hi @AdamZWu, have you looked at in-toto layouts? They're the counterpart to an in-toto attestation that define the steps in a supply chain and who can perform each step, identified by their public keys. The v1 in-toto spec doesn't support the attestation framework but we're working on updating that with ITEs 10 and 11. You can see prototype layouts here and Witness's take on policies here. Note that layouts also support declaring multiple trusted actors for each step and you can also require a minimum number that must agree.

[marcelamelara]

@AdamZWu bumping this issue. Please let us know if/how we can help resolve this.