`subject` part of spec not precise enough for validation

[fmoessbauer]

In https://github.com/sigstore/cosign/issues/3641 I tried to come up with a concept of a generic workflow for signing and validating attestation data. While defining this, I stumbled upon some ambiguities in the subject part of the spec. As source of truth I considered both the textual representation and the .proto definition of https://github.com/in-toto/attestation/blob/v1.0/spec/v1.0/statement.md

Ambiguities in statement:

• subject: array of objects, required: May that be empty as well? The .proto allows this, but for me it is unclear if that semantically makes sense. How to perform validation in this case, especially w.r.t. what to check.
• subject[*].name: If this is set, what exactly needs to be checked? In subject, there is a statement that matching is performed PURELY by digest. In this case I would consider the subject[*].name to be only of informative nature but not relevant for matching. Why do the producer and consumer need to agree on naming schemes then?
• to consider a statement matching, must ALL or ANY subject match? Or is this decision made on a per-subject basis / left up to the consumer? A user-case would be a single attestation for a set of subjects, while the consumer might only want to know if a particular artifact (subject) is valid. This however makes the validation prone against attacks that rely on deliberately dropping artifacts. Might be related to https://github.com/in-toto/attestation/issues/292

Monotonic parsing rule:

How does this play together with subject[*].digest: Two DigestSets are considered matching if ANY of the fields match.? If two digests (e.g. sha1, sha256) on the same artifact do not match, but parser A can only check sha1, which matches, while parser B can only check sha256 which does not match? While this is not strictly against the monotonic criteria, it is in conflict with the statement A policy is considered monotonic if ignoring an attestation, or a field within an attestation, will never turn a DENY decision into an ALLOW

[marcelamelara]

PTAL @in-toto/attestation-maintainers

[TomHennen]

subject: array of objects, required: May that be empty as well? The .proto allows this, but for me it is unclear if that semantically makes sense. How to perform validation in this case, especially w.r.t. what to check.

IMO subject MUST be non-empty.

subject[].name: If this is set, what exactly needs to be checked? In subject, there is a statement that matching is performed PURELY by digest. In this case I would consider the subject[].name to be only of informative nature but not relevant for matching. Why do the producer and consumer need to agree on naming schemes then?

The spec says "The semantics are up to the producer and consumer and they MAY use them when evaluating policy" . So in-toto has no opinion on how to validate them.

The reason the producer and consumer need to agree on naming schemes is if they want to validate them for some particular purpose. But that's none of our business.

to consider a statement matching, must ALL or ANY subject match

This implies 'ANY' but note that it's related to the artifact being verified. So if someone is verifying a single artifact then yeah, any of them must match. If people are validating multiple artifacts at once then all the things being verified (which might be a subset of subject!) must match.

How does this play together with subject[*].digest: Two DigestSets are considered matching if ANY of the fields match.? If two digests (e.g. sha1, sha256) on the same artifact do not match, but parser A can only check sha1, which matches, while parser B can only check sha256 which does not match? While this is not strictly against the monotonic criteria, it is in conflict with the statement A policy is considered monotonic if ignoring an attestation, or a field within an attestation, will never turn a DENY decision into an ALLOW

The monotonic principle applies to ignoring an entire attestation, not a subset of that attestation. It also should likely only apply within the context of a single parser?

I'd also say that if multiple digest types are present the verifying doesn't need to verify that they all match, but rather just one of them.