[Rats] Processing Endorsements and Evidence into Results

[Laurence Lundblade <[e-mail]>]

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   |
        '----------'                      '-----------------'