Support attestation revocation

[MarkLodato]

It would be useful to have a mechanism for revoking specific sets pf attestations without having to revoke an entire key. A real-world use case is that a builder had a bad release and generating bad provenance for a short period of time. We'd like to revoke the provenance generated only by that bad release, without having to do a full key revocation, since the latter would have a much larger negative impact.

Note that signature revocation was mentioned in secure-systems-lab/dsse#39, where we said it would be a better fit inside the payload. That's why I filed the issue here.

It's also possible we push this down further into the predicate and have predicate-specific methods. For the use case above, https://slsa.dev/provenance could have a builderVersion field and we could revoke based on that. But I don't particularly like that idea since revocation seems like it would apply equally to all attestations.

I don't have good ideas for solutions, but wanted to mention this here since it is is a real issue that has already come up.

[dn-scribe]

I agree that revocation should be at the attestation level.

Suggestion: Use an attestation:
Create a new predicate type: attestation-revocation-predicate, that would define that an attestation or a group of attestations that adhere to some criteria (e.g. time frame) are revoked. Naturally it could be signed by an authorized entity and a policy could enforce that.

It will be the user's responsibility to search his attestation store for these attestations.

[trishankatdatadog]

Hmm, interesting. I can think of a few different solutions to the problem. Some of them are higher-level than attestations, but if you wanted to keep it at the same level, then one solution is to use a short-lived Verification Summary Attestation (VSA) to admit any artifact. That way, the thing issuing these short-lived VSAs can choose to say that it revoked a particular artifact based on a no-longer trustworthy attestation somewhere in the steps.