Ability to refer to one attestation from another

[MarkLodato]

There are likely use cases where you want to refer to one attestation from another. For example, you could have a "Policy Decision" predicate that says "I allow subject x to run in environment Y, based on input attestation Z."

Since this is just theoretical at the moment, we'll wait until we have a few concrete use cases to actually design and implement this. Please add any use cases you might have to this issue.

The straightforward solution is to treat the entire attestation as an artifact, and thus you refer to the attestation as a hash over the envelope. The downside to this approach is that it prevents one from re-encoding the envelope, such as if you add a signature to it, because doing so changes the hash. (Counter-point: don't do that.) Perhaps this is the best option.

Alternative ideas:

• Refer to the hash of the statement, rather than the envelope. Downside: that loses who signed it, which is critical information.
• Refer to the hash of some canonicalization of the envelope. Downside: that relies on canonicalization (frowned upon, see ITE-5), needs to be invented, and adds complexity.
• Each attestation has a UUID. Downside: adds complexity and could be error prone. For example, what if someone else creates one with the same UUID, either accidentally or on purpose?
• Store attestations in some ledger, then you can refer to the location within the ledger (transaction ID or leaf hash). Downside: requires a ledger, and is seemingly not any better than the straightforward solution.

[JustinCappos]

Can you do this with sublayouts and/or treating the result of an in-toto verification as a step? If not, can you give an example to make it clear why?

[MarkLodato]

@JustinCappos To clarify, this is just tracking the general idea. We don't have concrete use cases yet, so we can't really say whether any particular solution would work. I updated the initial comment to clarify.

That said, I don't think either of those are solutions here. Layouts are policies, and this is about attestations (i.e. links). The result of an in-toto verification is itself an attestation/link, so that has the exact same problem. I'm guessing that in-toto currently solves this problem by referring to the hash of the entirely link? I've now listed as the "straightforward solution" in the first post. Maybe I'm over-thinking this.

[marcelamelara]

@MarkLodato can you please take a look at the structure proposed in #117? Might this be a possible step in the right direction to support the functionality you're looking for?

There are also some examples at https://github.com/in-toto/attestation/blob/main/spec/predicates/scai.md#examples

[MarkLodato]

#117 seems reasonable to me.

To be clear, this issue was about how we recommend that one attestation refers to another. In the original post, I said:

The straightforward solution is to treat the entire attestation as an artifact, and thus you refer to the attestation as a hash over the envelope.

After more time to think about this, I suggest that we just close this bug and assume the straightforward solution is the one that people will naturally do. That is (IIUC) what #117 would do, for example.

So I'll close this bug, but please reopen if you disagree!