ITE-6: Route to Acceptance
adityasaky opened this issue · comments
ITE-6 was merged as draft quite some time ago and we've seen in-toto attestations pop up in a number of contexts (SLSA Provenance, SBOM specific ones, SCAI, runtime traces, Alpha Omega scan results, and more!). The last couple of in-toto community meetings have discussed accepting it, and this thread is a formal request for comments before ITE-6 is accepted. Also note, #40 was opened to bring the ITE up to shape for acceptance, please use that version of the document.
Once accepted, does that mean the in-toto specification would be updated (i.e. section 4) to use in-toto attestations and the link predicate?
My understanding is that's waiting on 1.0 of the spec. After 1.0, I think the plan is to immediately work on a 1.1 that incorporates more of the attestation spec.
I would change the section that reads:
This ITE does not affect the security of in-toto because:
the link attestation type is isomorphic to the existing link schema and can be translated freely in both directions.
security must be evaluated in the context of each individual attestation type, which is out of scope of this ITE.
to read:
This ITE impacts the security of in-toto in a way that cannot be clearly defined here because security must be
evaluated in the context of each individual attestation type. This is out of scope of this ITE and is delegated to
each newly proposed attestation type.Note that the link attestation type is isomorphic to the existing link schema and can be translated freely in both
directions.
Opened #46 to address your comment, @JustinCappos.
#46 has now been merged.
I think this is ready to be accepted. Would love to hear from others...
I'd like to see this accepted. We're seeing a lot of interest in in-toto attestations and it would be good to have the in-toto spec using/recommending them and the reference implementations using them.
I think ITE-6 is good to go as well, I've added it to the agenda for the community meeting.
ITE-6 ha been accepted via #48!