Re: [Rats] Processing Endorsements and Evidence into Results

BTW: Since ‘debug-disable’ is permanent it could probably equally be included in Endorsement.
It is also reasonable that Verifier could downgrade ‘security level’ based on other claims and how they relate to policies. Security level in Evidence is an assertion the attester makes that has to be substantiated in some way. It could also be used exclusively as a conclusion in Results based on review of a bunch of other claims (in other words Attestation Results cold acquire additional claims beyond what originally existed in the intersection of Evidence and Endorsement.

Policies and or standardized profiles decide all these variables IMHO.

But the example seems to be illustrative (if that was the intent).

-Ned

From: RATS <rats-bounces@ietf.org> on behalf of Laurence Lundblade <lgl@island-resort.com>
Date: Thursday, April 2, 2020 at 4:16 PM
To: "rats@ietf.org" <rats@ietf.org>
Subject: Re: [Rats] Processing Endorsements and Evidence into Results

Let me make this much more concrete with an example. I’m using JSON representation of CWT/EAT/Endorsements with C-style comments for reading ease.

Endorsement
{
    “trust-evidence”: “all”,           // E0, I just made this up
    “field-upgradable”: true,          // E1, from draft-birkholz-rats-endorsement-eat-00
    “shielded-secret”: internal,       // E2, from draft-birkholz-rats-endorsement-eat-00
    “common-criteria”: https://www.commoncriteriaportal.org/files/epfiles/0879V3a_pdf.pdf”,      // E3, from draft-birkholz-rats-endorsement-eat-00
}

Evidence
{
    “iat": 5734873409823,              // C1 time stamp for evidence creation time(eg) from EAT draft
    “security-level”: 4                // C2 the security level is “hardware” from EAT draft
    “debug-disable”: “permanent”       // C3 debug is permanently disabled for all but the OEM from EAT draft
}

Results
{
    “field-upgradable”: true,          // R1, from draft-birkholz-rats-endorsement-eat-00
    “shielded-secret”: internal,       // R2, from draft-birkholz-rats-endorsement-eat-00
    “common-criteria”: https://www.commoncriteriaportal.org/files/epfiles/0879V3a_pdf.pdf”,      // R3, from draft-birkholz-rats-endorsement-eat-00
    “iat": 5734873409823,              // R4 time stamp for evidence creation time(eg)
    “security-level”: 4                // R5 the security level is “hardware”
    “debug-disable”: “permanent”       // R6 debug is permanently disabled for all but the OEM
}

In this example, the RP is probably feeding this into a risk engine so they want all the details.

Here’s another very abbreviated example with made up claim names:

Endorsement (not showing any signing)
{
    “expected-hash”: “TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZW”
}

Evidence
{
    “actual-hash”: “TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZW"
}

Results
{
    “verified”: true,
}

This all seems like the eventual logical result of the EAT, endorsements and architecture drafts to me.

LL

On Apr 2, 2020, at 12:36 PM, Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>> wrote:

Now that we have a first draft describing endorsements<https://tools.ietf.org/html/draft-birkholz-rats-endorsement-eat-00>, and they look like Evidence and Results, it seems interesting to consider some of how the verifier uses Endorsements (reference the architecture diagram below).

Let’s say there are three things in the endorsement, E1, E2 and E3, three things in the evidence, C1, C2 and C3 and three in the results, R1, R2 and R3.

Then three simpleton top-level cases:

1) An Endorsement is passed through and becomes a result: E1 — > R1
2) A Claim is passed through and becomes a results: C1 —> R2
3) Some endorsements combine with some claims to become a result: {E2, E3, C2, C3} —> R3

However that seems to be too simple and I think there has to be some sort of a primitive endorsement, call it E0, whose semantics are that some or all of the claims can always be believed. I think that means 2) doesn’t really exist, but has to be this:

2) Some claims can pass through with the use of the primitive E0 endorsement: {E0, C1} —> R2

One way E0 could be defined in the draft describing endorsements<https://tools.ietf.org/html/draft-birkholz-rats-endorsement-eat-00> is that it is a list of the labels of claims that are trusted to be passed through. For numeric labels  a range INT64_MAX to INT64_MIN (or -infinity to +infinity)  indicates all claims are trusted. It could also list specific ones that are trusted.

From the TEE, FIDO and Android Attestation views of the world where measurements aren’t a primary thing and secure/trusted boot is required and always on, a common model will be to pass everything through to create an aggregate result. It could be represented this way:

E1->R1
E2->R2
E3->R3
{E0,C1}->R4
{E0,C2}->R5
{E0,C3}->R6

I think this goes on to submodules too and has some relation to the attempted to propose a connection type.  Endorsements may be able to say how submodules are trusted. There might even be an E00 primitive that says the lead attester is allowed to say how submodules are trusted. This whole line of thinking was partly prompted by this issue<https://github.com/ietf-rats-wg/eat/issues/58> against EAT and comments from Giri and Dave.

LL

                 ************   ************    *****************

                 * Endorser *   * Verifier *    * Relying Party *

                 ************   *  Owner   *    *  Owner        *

                       |        ************    *****************

                       |              |                 |

           Endorsements|              |                 |

                       |              |Appraisal        |

                       |              |Policy for       |

                       |              |Evidence         | Appraisal

                       |              |                 | Policy for

                       |              |                 | Attestation

                       |              |                 |  Result

                       v              v                 |

                     .-----------------.                |

              .----->|     Verifier    |------.         |

              |      '-----------------'      |         |

              |                               |         |

              |                    Attestation|         |

              |                    Results    |         |

              | Evidence                      |         |

              |                               |         |

              |                               v         v

        .----------.                      .-----------------.

        | Attester |                      | Relying Party   |

        '----------'                      '-----------------'

_______________________________________________
RATS mailing list
RATS@ietf.org<mailto:RATS@ietf.org>
https://www.ietf.org/mailman/listinfo/rats