Add ITE-10 adding policy definitions in layouts for in-toto attestations

[adityasaky]

ITE-6 introduced the in-toto attestation framework. Since then, we've seen a number of attestation types be proposed and used such as SLSA provenance, runtime trace attestations, SCAI, and more. However, ITE-6 did not update in-toto layouts with mechanisms to verify the contents of new attestation types.

The latest draft of the ITE allows for verifying attribute claims at each step using lightweight DSLs built for such validations via expectedAttributes alongside the standard expectedMaterials and expectedProducts. It also adds similar support to current inspections. Finally, it adds a variation of a standard inspection that collects all claims pertaining to one or more subjects and applies specified constraints against those claims.

[adityasaky]

Some tangential thoughts:

• I think this will revive ITE-8 Proposal Draft: provide an in-toto-library #29 as a way to define a library of policies for desirable properties, perhaps curated via SLSA requirements. I'll go so far as to say that this ITE's acceptance should be predicated on having a usable set of policies ready to go to prove its capabilities.

• There's probably another related ITE regarding accepted_attestation_types for which attestations can be used to attest to some property (or artifacts). There is, I think, overlap with discussions around predicate dictionaries and what not.

[colek42]

I would like a way to write policy over a attestation bundle. This would also let us create a policy linter. @mikhailswift has some thoughts here as well.

```json
{
    "_type": "inspection",
    "name": "<NAME>",
    "functionaries": ["<KEYID>", "..."],
    "threshold": "<THRESHOLD>",
    "subject": ["<SUBJECT>", "..."],
    "attestations": [{
        "payloadType:" "<PAYLOADTYPE>,
        "policyLanguage": "<POLICY_LANGUAGE>",
        "policy": "<POLICY>"
         }...]
    "run": "<COMMAND>"
}

[colek42]

Also, we can probably remove "run" and have in-toto generate an SLSA attestation. You can then use the policy language to evaluate if the "run" command meets policy.

[znewman01]

My main question here is one of motivation. I agree fully that Rego/CUE against attestations is a useful primitive. But why does it need first-class support from in-toto? You could always run an external program, so this doesn't add any theoretical capabilities, right?

I almost wonder if you could achieve the same thing with a small wrapper program that you could stick in run. Then you don't really need any in-toto changes, right?

(I might be missing something obvious here.)

[colek42]

@znewman01

1: in-toto policy is signed, embedding the rego/cue within the policy lets the system assert that the entire policy came from a trusted source.

2: We want to improve the UX around in-toto policy evaluation. Forcing the user to build custom workflows and tools will lower adoption rates.

3: Policy distribution is difficult enough, having a single source of truth for what is allowed/disallowed will help simplify the process.

If you want to see an example of what this looks like in practice please take a look at my talk here: https://www.youtube.com/watch?v=zCznRGlsYvo and my blog article here: https://www.testifysec.com/blog/attestations-with-witness/

[znewman01]

1: in-toto policy is signed, embedding the rego/cue within the policy lets the system assert that the entire policy came from a trusted source.

Agreed that we should inline the policy into the in-toto document.

But I was imagining something like:

{
   [...],
   "run": "cue --policy '<cue policy here>' input.json",
}

Which is ugly/unergonomic but should work.

2: We want to improve the UX around in-toto policy evaluation. Forcing the user to build custom workflows and tools will lower adoption rates.

I agree: ergonomics alone is a compelling enough reason to do this. I'm just trying to understand whether this proposal is mostly sugar.

3: Policy distribution is difficult enough, having a single source of truth for what is allowed/disallowed will help simplify the process.

Agreed, but I think something like what I mentioned above takes care of this (though I agree sugar for better ergonomics is worthwhile.)

If you want to see an example of what this looks like in practice please take a look at my talk here: https://www.youtube.com/watch?v=zCznRGlsYvo and my blog article here: https://www.testifysec.com/blog/attestations-with-witness/

Nice!

[trishankatdatadog]

How should a verifier call out to these policy languages? Seems completely unspecified to me, especially error handling.

[adityasaky]

I was hoping for some input here actually. Witness supports rego policies via the official library, and they don't shell out to a binary, for example. As Zack pointed out, shelling out is already possible. Should the ITE explicitly disallow shelling out to handle these policies? I am a little wary of overspecifying here. cc @colek42

[znewman01]

I think underspecifying is bad too. How will the attestations be made available to the policy environment? That needs to be documented. If the ITE doesn't do that, we should at least say where it will happen

[adityasaky]

Pushed a third draft that revisits several ideas. With this one, we support chaining predicates that don't fit the link-esque model but are more claims / attributes oriented (eg: test run results, reviews etc). It still opens up support for embedding other DSLs throughout so attributes can be verified without relying on external scripts. It also supports the previous draft's notions about inspecting all claims (from all applicable attestations presented for verification) for one or more subjects.

[JustinCappos]

I wonder if it would be useful to add some examples here to motivate and ground this. Reading the other reviewer comments, I do think this may help to address some of them as well by making this more concrete.

[trishankatdatadog]

Just to note that I gave my feedback to Aditya over an online meeting last week. Please let me know if you need another review, thanks!

[marcelamelara]

Thanks @adityasaky ! A few comments on clarity and terminology.

[marcelamelara]

I feel like something is missing here. A couple questions: How do verifiers map predicate types in the predicates field to whether they are link class or attribute class? Also, how is the expectedAttributes used? This description only talks about how materials and product rules may be applied in the attribute class case.

[adityasaky]

I've clarified the expectedAttributes field inline, thanks for pointing that out.

How do verifiers map predicate types in the predicates field to whether they are link class or attribute class?

I'm still working this out. I suspect we'll need to add some of those notions as predicates are vetted. IMO if a predicate can cleanly be mapped to having both a materials and products field, we can bucket it as part of the link class.

[adityasaky]

Also added some details to the verification workflow though I think it's not going to yet answer everything.

[adityasaky]

As with the current in-toto specification, the verification workflow is
presented with a root layout, public keys to verify the layout's signatures, and
a bundle of in-toto attestations. As the verifier expects a certain set of
predicate types, it is also expected to be aware of the class of each predicate.

Is this a reasonable expectation?

[adityasaky]

I've split this ITE into two separate ones (with possibly a third in the works). They're at #49 and #50. I'm closing this PR in favour of those, thanks for the comments everyone!