Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

subject part of spec not precise enough for validation #349

Open
fmoessbauer opened this issue Apr 21, 2024 · 0 comments
Open

subject part of spec not precise enough for validation #349

fmoessbauer opened this issue Apr 21, 2024 · 0 comments
Labels

Comments

@fmoessbauer
Copy link

In sigstore/cosign#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 Are subjects conjunctive or disjunctive? #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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants