Update ITE-10: change step predicates and add selectors #62
Conversation
Signed-off-by: Marcela Melara <[email protected]>
trishankkarthik
left a comment
trishankkarthik
left a comment
There was a problem hiding this comment.
Thanks very much for these simple but highly effective improvements, Marcela! Just a few comments...
Signed-off-by: Marcela Melara <[email protected]>
Signed-off-by: Marcela Melara <[email protected]>
Signed-off-by: Marcela Melara <[email protected]>
|
@adityasaky PTAL |
| ``` | ||
| predicateType: string | ||
| predicate_type: string | ||
| inputs_selector: string |
There was a problem hiding this comment.
👀 this is interesting. Do we need outputs_selector?
Two cases:
informational -> inputs is subject, no outputs
transformational -> inputs is predicate specific, outputs is subject
we could have just the inputs_selector, with options subject and predicate.<field> where the field is set. If it's predicate.<field> we can safely assume the contents of subject make up the output. If input_selector is subject, then there's no output.
There was a problem hiding this comment.
Good catch! Actually, we talk about I/O selectors in the Policy Framework draft.
There was a problem hiding this comment.
This is an interesting suggestion. My inclination is to specify things as explicitly as possible so consumers of policies don't need to bake in implicit assumptions into their verification flow. How do others feel about removing outputs_selector ?
| is updated to support matching on predicate types as well. In addition, | ||
| The verification workflow in the in-toto v1.0 specification matches links to | ||
| use by the name of the step and the key ID used to sign it. This part of the | ||
| workflow is updated to support matching on predicate types as well. In addition, |
There was a problem hiding this comment.
side note: we don't specify how to match on predicate types; we should consider this but separately.
ITE/10/README.adoc
Outdated
| ResourceDescriptor object is used for pattern matching and the `digest` field | ||
| is used to verify equality of two artifacts. | ||
|
|
||
| As in in-toto v.10, the `layoutEnvelope` and `layoutKeys` contain the signed |
Co-authored-by: Aditya Sirish <[email protected]>
| in the process. Note that this expects the verifier to be capable of generating | ||
| distinct predicates--the in-toto v1.0 verifier was only aware of links and | ||
| sublayout verification therefore generated an in-toto summary link. This is | ||
| discussed further on in <<Custom Verifiers>>. |
There was a problem hiding this comment.
Where is the discussion of the supported languages and custom verifiers? I'd love to have us choose something really small and sane here which is unlikely to have any security issues.
Usually running complex code during signature checking is a bad idea. Since this is running potentially attacker provided code during verification, this should be really locked down. (I acknowledge and regret how inspections work in the current in-toto layouts, so I'm mostly pointing the finger at myself here.)
There was a problem hiding this comment.
That discussion is not here: this is specific to just: (1) fixing a step to exactly one predicate type, and (2) introducing I/O Selectors.
The general discussion on policies is here. We do have not a list of supported policy languages and engines, and are not likely to do so. Please see that doc for our rationale on why we want flexibility.
There was a problem hiding this comment.
I took a look at the document and would love to have more discussion about the pros and cons. Happy to do this in the document, on this issue, or in another format. I do think there needs to be more of a comparative discussion resulting from this, regardless of the eventual design choice.
There was a problem hiding this comment.
Why don't we discuss over a Zoom/Meet and go from there? I'll send out an invitation.
Co-authored-by: Trishank Karthik Kuppusamy <[email protected]>
6 participants
This PR makes revisions to the current text of ITE-10 based on practical experiences and case studies verifying in-toto attestations:
These changes were first proposed at OpenSSF Community Day NA '25.