[Rats] Endorsement ID and verification key (was Processing Endorsements and Evidence into Results)

[Laurence Lundblade <[e-mail]>]

So how does a Verifier find the applicable endorsement for Evidence it wishes to verify and know that is really the right endorsement?

Seems like the Evidence needs some sort of an endorsement locator ID. This could be a URL or a GUID. EAT currently has the origination claim to try to solve this, but it is half-baked. It needs to get fixed. I’m fishing for comments here on what it should be like.

Pretty sure the Endorsement needs to include or reference the public key that is used to verify the signature. Without that, the Attester could lie and pick any old Endorsement that it wishes. There needs to be some binding between items in the endorsement (E0, E1,…) and the verification key. That could be in the form of a signed token or certificate, but doesn’t have to be. Pretty sure this needs to be discussed in the architecture doc.

There’s a few scenarios:
- One endorsement applies to lots of devices in the same class, but each has their own attestation key.
- - Probably ECDAA fits in here
- - One option here is an X509 hierarchy
- Group keys are used (for privacy reasons or other) so there is a one-one correlation with the Endorsements (the GEID discussion)
- Group keys are used, but across devices that have different endorsements so there’s no one-one correlation

While the last one seems odd and unlikely, I think it could occur, because from a lot of real experience the set up of attestation keys is very idiosyncratic. It is wildly affected by manufacturing costs and issues on assembly lines, sub contractor structure, location of secure facilities and approaches to making money on it. They are like snowflakes, each one is different.  So maybe endorsement locator ID and key ID are not the same, but they can be in some use cases?

 I am also tempted to encourage the placement of the endorsement locator ID in the COSE or JOSE header parameters so you don’t have to parse the unverified body of claims to be able to find the key material to verify it.

Thoughts?

LL



> On Apr 2, 2020, at 4:16 PM, Laurence Lundblade <[e-mail]> wrote:
> 
> 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 <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 <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 <[e-mail] <mailto:[e-mail]>> 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
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/rats
> 
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats