Compositional Notion On Attestation Types

[SantiagoTorres]

It'd be nice to describe a strategy for different types of attestations within the same action.

Should we have these two types of attestations live under the same object? or would they be separate attestations attached to the same action. I.e., you could have 1 subject with multiple predicates.

F.e., Having a provenance type that includes a measured boot record:

{
  "subject": [
    { "name": "curl-7.72.0.tar.bz2",
      "digest": { "sha256": "ad91970864102a59765e20ce16216efc9d6ad381471f7accceceab7d905703ef" }},
  "predicateType": "https://in-toto.io/Provenance/v1",
  "predicate": {
    "builder": { "id": "https://github.com/Attestations/GitHubHostedActions@v1" },
    "recipe": {
      "type": "https://github.com/Attestations/GitHubActionsWorkflow@v1",
      "definedInMaterial": 0,
      "entryPoint": "build.yaml:maketgz"
    },
    "metadata": {
      "buildStartedOn": "2020-08-19T08:38:00Z"
    },
    "materials": [
      {
        "uri": "git+https://github.com/curl/curl-docker@master",
        "digest": { "sha1": "d6525c840a62b398424a78d792f457477135d0cf" },
        "mediaType": "application/vnd.git.commit",
        "tags": ["source"]
      }
    ]
    "tpm-measured-boot: {
       "PCR0": "xxxx",
       "PCR1": "yyyy",
       ...
    }
  }
}

This way, we would be able to know provenance information of the build + information about the host's integrity.

[MarkLodato]

There are two simple, existing solutions:

• Issue two independent attestations.
• Use a single predicate with all the information you want.

This feature request is about cases where the above solutions won't work.

Theoretical use cases (if there are more, please add them):

• One attestation depends on another.

  • Example: PolicyDecision attestation depends on a prior Provenance attestation.
  • Possible solution: consider the dependent attestation an artifact like any other. (Challenge: requires stable serialization of the attestation, which is broken if the envelope is signed multiple times. Could alternatively refer to the Statement instead of the Envelope, but then that loses the attester, which is often critical.)

• Multiple predicates must be tied together but also must be able to be authenticated independently.

  • Example: a small Provenance predicate is intended for an automated policy engine, while a large MeasuredBoot predicate contains more information for analysis. You want to tie the two together but be able to authenticate the Provenance without requiring MeasuredBoot. Separate attestations isn't good because then an attacker can mix and match, e.g. one build with {good provenance, bad boot} and one build with {bad provenance, good boot}, then combine to get {good provenance, good boot}. A single attestation isn't good because then you need to ship around the large MeasuredBoot when it isn't needed.
  • Possible solution: Treat this as the "depends on another" case above, e.g. Provenance depends on MeasuredBoot. (Con: may not work for all cases.)
  • Possible solution: Include a UUID in both. (Con: tricky to get right.)
  • Possible solution: Create a new "MultiPredicate" predicate that includes hashes of other predicates, then have some way in the envelope of shipping these other blobs of data. (Con: complicated.)

• Independent attestations/predicates are logically OK but there is a desire to sign both in a single operation, say for performance reasons.

My inclination is to defer this until we have significant real-world examples where existing solutions won't work.

[marcelamelara]

I wanted to bump this issue since I've been thinking about nested predicates as well as capturing attestation dependencies for my work on CDI. Since our goal is to provide fine-grained application level attestations about artifacts with corresponding evidence (which itself may consist of other types of attestations), I specifically have the need for capturing nested predicates, or at least references to other attestation objects.

Let me give a more concrete example:
Say I'm building a binary with gcc v9, and running the build inside of a TEE-container like Gramine for SGX for added integrity. To fully check the assertion "this binary was built by gcc v9", I need to check that (1) the build ran on a legitimate SGX platform, (2) that the container image in which I ran indeed matches the SGX enclave measurement attested in step 1, and (3) that the version of gcc I ran inside the container is the version loaded by the container in step 2. So here, check 2 uses the attestation from check 1 as evidence, and check 3 uses the container image and manifest from check 2 as evidence.

If I then additionally want to attest to the assertion "this binary contains buffer guard variables", I might do this by showing that the binary was built with gcc v9 using the -fstack-protector flag. So, this higher-level attestation now has a dependency on the complex attestation for "this binary was built by gcc v9". This ties into @MarkLodato's points about including the hashes or generating some kind of UUIDs for other predicates or attestation objects, because I might not want to include the entire first attestation predicate in the second predicate for scalability and/or reusability.

Maybe this is still too theoretical a use case, but since part of my work on CDI is to enable the use of TEEs for builds and such complex application-level attestations about artifacts, this is an issue I'm actively looking into right now. So, I think getting some feedback from this community as to what predicate identifiers or references could make sense for in-toto would be helpful so I can take that into consideration as I develop an in-toto compatible predicate schema for CDI.

[MarkLodato]

My inclination is to consider attestations immutable and reference them by hash.

[marcelamelara]

I tend to agree that referencing other attestations by hash makes a lot of sense. The only other question then is, how do we find this attestation if the only reference we receive is the hash? I think there's going to have to be some kind of location URI or some other info to resolve the referenced attestation. For example, if the referenced attestation is stored in a Rekor instance, we should be able point to that address.

[marcelamelara]

@MarkLodato @SantiagoTorres

Separate, but related question. It seems like there is at least a potential ITE in here, which is this notion of cross-attestation references. Is this something that's worth drafting up at this point?

And it seems like if we were to add support for signing a list of predicates under a single attestation generated within a single step (which is not the same thing as a bundle), this would be part of the ITE-6 spec? Or does this warrant a separate ITE that enhances ITE-6?

In both of these cases, it might make sense to push ITE-6 towards acceptance before adding support for composed/nested attestations and references.

[MarkLodato]

how do we find this attestation if the only reference we receive is the hash?

I suggest that we move this to slsa-framework/slsa#269. My feeling is that we should always have some other identifier/URI in addition to a hash. You don't just get a blob of data out of nowhere. You have some idea of what it is.

this notion of cross-attestation references. Is this something that's worth drafting up at this point?

I think it should at least be documented. I don't know if it needs a full-blown ITE. @SantiagoTorres thoughts?

And it seems like if we were to add support for signing a list of predicates under a single attestation generated within a single step (which is not the same thing as a bundle), this would be part of the ITE-6 spec? Or does this warrant a separate ITE that enhances ITE-6?

I think we should expand the attestation format (Statement layer) to support this as a first-class concept. Again, I don't know if it need a separate ITE.

[marcelamelara]

@SantiagoTorres @MarkLodato The general consensus for multiple attestations about a subject is to use a bundle. With the new ResourceDescriptor type (introduced in #143), we can embed pointers to attestations within other predicates. Do we think that the intent behind this issue is covered now?

[MarkLodato]

I'm good closing it.