Subject: [Rats] Processing Endorsements and Evidence into Results

From: Laurence Lundblade <[email-masked]>
Date: Thu, 2 Apr 2020 12:36:22 -0700

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

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 2 Apr 2020 16:16:35 -0700

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 <[email-masked]> wrote:
> 
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 3 Apr 2020 04:20:07 +0000

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 <[email-masked]> on behalf of Laurence Lundblade <[email-masked]>
Date: Thursday, April 2, 2020 at 4:16 PM
To: "[email-masked]" <[email-masked]>
Subject: Re: [Rats] Processing Endorsements and Evidence into Results

Endorsement
{

Evidence
{

Results
{

Evidence
{

Results
{
    “verified”: true,
}

LL

On Apr 2, 2020, at 12:36 PM, Laurence Lundblade <[email-masked]<mailto:[email-masked]>> 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).

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.

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

                       |              |                 |

           Endorsements|              |                 |

                       |              |Appraisal        |

                       |              |Policy for       |

                       |              |Evidence         | Appraisal

                       |              |                 | Policy for

                       |              |                 | Attestation

                       |              |                 |  Result

                       v              v                 |

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

              |                               |         |

              |                    Attestation|         |

              |                    Results    |         |

              | Evidence                      |         |

              |                               |         |

              |                               v         v

_______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats

---

From: Dave Thaler <[email-masked]>
Date: Fri, 3 Apr 2020 04:27:02 +0000

Debug-disable is not (in general, but can be in specific cases) permanent for a device, it can vary by application on the same device,
and can vary over time as say software/firmware is patched or configured, so cannot in that case be in an endorsement.

Also I would expect that endorsements generally also carry some sort of expiration or validity period as well, which isn’t in Laurence’s example.
(And expiration time is an example of something that equality comparison against a “known good value” doesn’t work for.)

Dave

From: RATS <[email-masked]> On Behalf Of Smith, Ned
Sent: Thursday, April 2, 2020 9:20 PM
To: Laurence Lundblade <[email-masked]>; [email-masked]
Subject: Re: [Rats] Processing Endorsements and Evidence into Results

-Ned

From: RATS <[email-masked]<mailto:[email-masked]>> on behalf of Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Date: Thursday, April 2, 2020 at 4:16 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] Processing Endorsements and Evidence into Results

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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.commoncriteriaportal.org%2Ffiles%2Fepfiles%2F0879V3a_pdf.pdf&data=02%7C01%7Cdthaler%40microsoft.com%7C4809b6abf17245234e7a08d7d78651b3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637214844793201421&sdata=E69tACqMXmlHdnjeBU9Y8cDT5DJAwHo0%2B7fAIgvtU4s%3D&reserved=0>”,      // E3, from draft-birkholz-rats-endorsement-eat-00
}

Evidence
{

Results
{
    “common-criteria”: https://www.commoncriteriaportal.org/files/epfiles/0879V3a_pdf.pdf<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.commoncriteriaportal.org%2Ffiles%2Fepfiles%2F0879V3a_pdf.pdf&data=02%7C01%7Cdthaler%40microsoft.com%7C4809b6abf17245234e7a08d7d78651b3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637214844793201421&sdata=E69tACqMXmlHdnjeBU9Y8cDT5DJAwHo0%2B7fAIgvtU4s%3D&reserved=0>”,      // R3, from draft-birkholz-rats-endorsement-eat-00

Evidence
{

Results
{
    “verified”: true,
}

LL

Now that we have a first draft describing endorsements<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-birkholz-rats-endorsement-eat-00&data=02%7C01%7Cdthaler%40microsoft.com%7C4809b6abf17245234e7a08d7d78651b3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637214844793211423&sdata=8ZPy3ny07A3FO%2BHn3fCrWnCoUKBbIkKhxbCMvF5Jbl8%3D&reserved=0>, and they look like Evidence and Results, it seems interesting to consider some of how the verifier uses Endorsements (reference the architecture diagram below).

One way E0 could be defined in the draft describing endorsements<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-birkholz-rats-endorsement-eat-00&data=02%7C01%7Cdthaler%40microsoft.com%7C4809b6abf17245234e7a08d7d78651b3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637214844793211423&sdata=8ZPy3ny07A3FO%2BHn3fCrWnCoUKBbIkKhxbCMvF5Jbl8%3D&reserved=0> 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.

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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats-wg%2Feat%2Fissues%2F58&data=02%7C01%7Cdthaler%40microsoft.com%7C4809b6abf17245234e7a08d7d78651b3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637214844793221414&sdata=uXX3tjZCocPUqEI47BoDPHVaSOWaAssDjlSWZgY0fZw%3D&reserved=0> against EAT and comments from Giri and Dave.

LL

                       |              |                 |

           Endorsements|              |                 |

                       |              |Appraisal        |

                       |              |Policy for       |

                       |              |Evidence         | Appraisal

                       |              |                 | Policy for

                       |              |                 | Attestation

                       |              |                 |  Result

                       v              v                 |

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

              |                               |         |

              |                    Attestation|         |

              |                    Results    |         |

              | Evidence                      |         |

              |                               |         |

              |                               v         v

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 3 Apr 2020 11:00:04 -0700

The latest debug disable text is here <https://github.com/ietf-rats-wg/eat/blob/master/draft-ietf-rats-eat.md> in GitHub but not yet in a released draft.

The “permanent disable” state still allows for the OEM (and only the OEM) to enable for things like RMA so it couldn't go in an endorsement. “full permanent disable” could, but only if the manufacturer really did it for every chip they shipped.

The debug facilities the claim is aimed at are HW and system facilities like JTAG, scan chain, Arm Coresight <https://developer.arm.com/ip-products/system-ip/coresight-debug-and-trace> and such. 

Maybe for some app download systems it might make sense to make the app an Attestation Target and make claims about that app’s debug state, but that’s not how debug for SW / apps usually works. There’s not usually config to turn debug on or off for individual apps.

LL

> On Apr 2, 2020, at 9:27 PM, Dave Thaler <dthaler=[email-masked]> wrote:
> 
> From: RATS <[email-masked] <mailto:[email-masked]>> on behalf of Laurence Lundblade <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>     “common-criteria”: https://www.commoncriteriaportal.org/files/epfiles/0879V3a_pdf.pdf <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.commoncriteriaportal.org%2Ffiles%2Fepfiles%2F0879V3a_pdf.pdf&data=02%7C01%7Cdthaler%40microsoft.com%7C4809b6abf17245234e7a08d7d78651b3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637214844793201421&sdata=E69tACqMXmlHdnjeBU9Y8cDT5DJAwHo0%2B7fAIgvtU4s%3D&reserved=0>”,      // E3, from draft-birkholz-rats-endorsement-eat-00
> }
>  
> Evidence
> {
>     “common-criteria”: https://www.commoncriteriaportal.org/files/epfiles/0879V3a_pdf.pdf <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.commoncriteriaportal.org%2Ffiles%2Fepfiles%2F0879V3a_pdf.pdf&data=02%7C01%7Cdthaler%40microsoft.com%7C4809b6abf17245234e7a08d7d78651b3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637214844793201421&sdata=E69tACqMXmlHdnjeBU9Y8cDT5DJAwHo0%2B7fAIgvtU4s%3D&reserved=0>”,      // R3, from draft-birkholz-rats-endorsement-eat-00
> On Apr 2, 2020, at 12:36 PM, Laurence Lundblade <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Now that we have a first draft describing endorsements <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-birkholz-rats-endorsement-eat-00&data=02%7C01%7Cdthaler%40microsoft.com%7C4809b6abf17245234e7a08d7d78651b3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637214844793211423&sdata=8ZPy3ny07A3FO%2BHn3fCrWnCoUKBbIkKhxbCMvF5Jbl8%3D&reserved=0>, and they look like Evidence and Results, it seems interesting to consider some of how the verifier uses Endorsements (reference the architecture diagram below).
>  
> One way E0 could be defined in the draft describing endorsements <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-birkholz-rats-endorsement-eat-00&data=02%7C01%7Cdthaler%40microsoft.com%7C4809b6abf17245234e7a08d7d78651b3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637214844793211423&sdata=8ZPy3ny07A3FO%2BHn3fCrWnCoUKBbIkKhxbCMvF5Jbl8%3D&reserved=0> 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.
>  
> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats-wg%2Feat%2Fissues%2F58&data=02%7C01%7Cdthaler%40microsoft.com%7C4809b6abf17245234e7a08d7d78651b3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637214844793221414&sdata=uXX3tjZCocPUqEI47BoDPHVaSOWaAssDjlSWZgY0fZw%3D&reserved=0> against EAT and comments from Giri and Dave.
>  
> LL
>  
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>

---

From: Dave Thaler <[email-masked]>
Date: Fri, 3 Apr 2020 19:14:45 +0000

“that’s not how debug for SW / apps usually works. There’s not usually config to turn debug on or off for individual apps.”

I can tell you that IS how it works for Intel processors, including apps that run in SGX enclaves.
So “usually” is perhaps a matter of perspective, or a matter that varies by chip vendor.

From: Laurence Lundblade <[email-masked]>
Sent: Friday, April 3, 2020 11:00 AM
To: Dave Thaler <[email-masked]>
Cc: Ned Smith <[email-masked]>; [email-masked]
Subject: debug disable (was Re: [Rats] Processing Endorsements and Evidence into Results)

The latest debug disable text is here<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats-wg%2Feat%2Fblob%2Fmaster%2Fdraft-ietf-rats-eat.md&data=02%7C01%7Cdthaler%40microsoft.com%7Ccc125ca1c90445f1433308d7d7f8da45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637215336822524667&sdata=Tq0ty5ZdUg2CEQbrqhxRs2lSy2FXPkS5ktpdXdmKvks%3D&reserved=0> in GitHub but not yet in a released draft.

The debug facilities the claim is aimed at are HW and system facilities like JTAG, scan chain, Arm Coresight<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.arm.com%2Fip-products%2Fsystem-ip%2Fcoresight-debug-and-trace&data=02%7C01%7Cdthaler%40microsoft.com%7Ccc125ca1c90445f1433308d7d7f8da45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637215336822534662&sdata=VWtpD%2BT2BxIxdamCpIKesvGcezuiZ9Xn5NpZum76Is8%3D&reserved=0> and such.

LL

On Apr 2, 2020, at 9:27 PM, Dave Thaler <dthaler=[email-masked]<mailto:dthaler=[email-masked]>> wrote:

Dave

From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Smith, Ned
Sent: Thursday, April 2, 2020 9:20 PM
To: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Rats] Processing Endorsements and Evidence into Results

-Ned

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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.commoncriteriaportal.org%2Ffiles%2Fepfiles%2F0879V3a_pdf.pdf&data=02%7C01%7Cdthaler%40microsoft.com%7Ccc125ca1c90445f1433308d7d7f8da45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637215336822534662&sdata=nsZC6mvYV9zlP7uRNMHQfmJz0dQQV6rFIS4B6CzJ1DY%3D&reserved=0>”,      // E3, from draft-birkholz-rats-endorsement-eat-00
}

Evidence
{

Results
{
    “common-criteria”: https://www.commoncriteriaportal.org/files/epfiles/0879V3a_pdf.pdf<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.commoncriteriaportal.org%2Ffiles%2Fepfiles%2F0879V3a_pdf.pdf&data=02%7C01%7Cdthaler%40microsoft.com%7Ccc125ca1c90445f1433308d7d7f8da45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637215336822544656&sdata=lsMPnL5msEN1uX2ou2%2FQtvfs9rO%2BjgAkESghd7fJDk8%3D&reserved=0>”,      // R3, from draft-birkholz-rats-endorsement-eat-00

Evidence
{

Results
{
    “verified”: true,
}

LL

Now that we have a first draft describing endorsements<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-birkholz-rats-endorsement-eat-00&data=02%7C01%7Cdthaler%40microsoft.com%7Ccc125ca1c90445f1433308d7d7f8da45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637215336822544656&sdata=SW8xIOOAErhMdjKuNsNgBARAZQmHfOAQ7HuolO2ekV4%3D&reserved=0>, and they look like Evidence and Results, it seems interesting to consider some of how the verifier uses Endorsements (reference the architecture diagram below).

One way E0 could be defined in the draft describing endorsements<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-birkholz-rats-endorsement-eat-00&data=02%7C01%7Cdthaler%40microsoft.com%7Ccc125ca1c90445f1433308d7d7f8da45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637215336822554653&sdata=kidjLndIlonCynAiwdKXGgMg5bHAUKPYkXL%2BB2fpzE0%3D&reserved=0> 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.

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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats-wg%2Feat%2Fissues%2F58&data=02%7C01%7Cdthaler%40microsoft.com%7Ccc125ca1c90445f1433308d7d7f8da45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637215336822554653&sdata=nam1GKA%2BNGc31Lubnb%2BsT2xqe9Ft9vDtw4v4JL%2BrWKg%3D&reserved=0> against EAT and comments from Giri and Dave.

LL

                       |              |                 |

           Endorsements|              |                 |

                       |              |Appraisal        |

                       |              |Policy for       |

                       |              |Evidence         | Appraisal

                       |              |                 | Policy for

                       |              |                 | Attestation

                       |              |                 |  Result

                       v              v                 |

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

              |                               |         |

              |                    Attestation|         |

              |                    Results    |         |

              | Evidence                      |         |

              |                               |         |

              |                               v         v

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

_______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frats&data=02%7C01%7Cdthaler%40microsoft.com%7Ccc125ca1c90445f1433308d7d7f8da45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637215336822564647&sdata=RR7tPQoY1JmQd5MEOCQyxxRs%2BpCkExAi0B%2BB53aSJhg%3D&reserved=0>

_______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frats&data=02%7C01%7Cdthaler%40microsoft.com%7Ccc125ca1c90445f1433308d7d7f8da45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637215336822564647&sdata=RR7tPQoY1JmQd5MEOCQyxxRs%2BpCkExAi0B%2BB53aSJhg%3D&reserved=0>

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 3 Apr 2020 12:37:36 -0700

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 <[email-masked]> wrote:
> 
>     “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
> {
>     “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

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 3 Apr 2020 12:45:41 -0700

> On Apr 3, 2020, at 12:14 PM, Dave Thaler <[email-masked]> wrote:
> 

Hopefully the debug disable claim in EAT can still handle this along with the user of submods. 

I’d like to understand a bit more here. Which debuggers are you thinking of? Something you use from an IDE like MSVC? Something you use from a JTAG port?

Debug per SGX enclave makes sense. Presumably that could be handled in EAT with submods. Any pointers to SGX debug documentation?

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 6 Apr 2020 23:43:19 +0000

Another way to understand it is if the state is updated by lifecycle events, such as SW update, then the Endorsement that is rendered untrue as a result needs to be updated too.

These are the semantics for SW update image integrity. They could apply to debug state too.

Expiration of a ‘static’ Endorsement claim doesn’t make the intrinsic nature of the claim go away, just the assertion of the claim goes away.

The alternative, that an attestation of the claim doesn’t replace the role of Endorsement can also be true. It just means the Evidence is presented without corresponding Endorsement. The verifier might still accept the Evidence because of the trust it places in the Attesting Environment to know that the claim is extant.

These are all examples of corner conditions that Appraisal policy needs to comprehend IMO.

-Ned

From: Dave Thaler <[email-masked]>
Date: Thursday, April 2, 2020 at 9:27 PM
To: "Smith, Ned" <[email-masked]>, Laurence Lundblade <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Rats] Processing Endorsements and Evidence into Results

Dave

-Ned

Endorsement
{

Evidence
{

Results
{

Evidence
{

Results
{
    “verified”: true,
}

LL

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

LL

                       |              |                 |

           Endorsements|              |                 |

                       |              |Appraisal        |

                       |              |Policy for       |

                       |              |Evidence         | Appraisal

                       |              |                 | Policy for

                       |              |                 | Attestation

                       |              |                 |  Result

                       v              v                 |

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

              |                               |         |

              |                    Attestation|         |

              |                    Results    |         |

              | Evidence                      |         |

              |                               |         |

              |                               v         v

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 7 Apr 2020 14:36:01 +0000

Hi Laurence,

Thanks for bringing this up.  A few thoughts below.

On 03/04/2020, 20:37, "RATS on behalf of Laurence Lundblade"
<[email-masked] on behalf of [email-masked]> wrote:
> 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:
> - 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?

A two level lookup key, model+instance, seems to be quite generally
applicable as an endorsement locator.  The model part would get you to
the shared data (e.g., certification, measured boot KGVs, etc.), while
the instance part can be used to retrieve device-specific state:
verification key(s) as well as other metadata, e.g., if some gear is
blacklisted.  In PSA we have something quite (though not entirely)
similar with implementation and instance IDs [1] [2].

(Context-switching for a second on our previous UEID/GEID discussion: I
guess we might model an instance as an anonymity set, and therefore
treat EUIDs as the special case GEIDs with cardinality == 1?)

For the sake of building a shared and reusable vocabulary, I'd prefer
keeping model and instance identifiers as separate claims rather than
having an opaque endorsement ID claim that clumps together those and
possibly other stuff in a use-case specific fashion.  For the same
reason I would not override key ID with instance ID semantics.

cheers, thanks!

[1] https://www.ietf.org/id/draft-tschofenig-rats-psa-token-05.html#name-implementation-id
[2] https://www.ietf.org/id/draft-tschofenig-rats-psa-token-05.html#name-instance-id

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 7 Apr 2020 12:12:38 -0700

This is a reply to both Thomas and Ned’s message on debug in the related threat.

My inclination is to associate endorsements with time-invariant characteristics of the device. At the moment this doesn’t seem like the only way to do it, but it seems like a good way. Things that are not time invariant are policy, k-g-v or such.

Endorsement
System architecture — Does the Attester use a TEE or a TPM or maybe it is simple system with just a simple CPU, but it is encased in titanium. Is defense against chip invasive attacks considered? Do keys become inaccessible when debug is enabled.

Development process — Is there a special security-oriented team? Does the team have a code review policy? Is there a bug bounty? Are the desktops and IT systems used for HW and SW development isolated?

Manufacturing — Are the factories secured in a special way? Is the attestation key provisioning system hardened in some way (e.g., uses HSMs).

Certifications — These take a long time to achieve and will usually require some of the above.

My thinking for EAT was that you only put attestation keys into devices that meet some criteria like some of the above. Since there is often no way to recover from a compromised attestation key because no key more secure than it, you kind of have to have all that. 

Since these don’t change much over time, the endorsement wouldn’t change.  They could even span several models and varying HW.

Policy, K-G-V, other
SW Versions — As long as the SW follows a development process like that above, it doesn’t have to be included in the endorsement. Of course the smaller the SW and the better the process, the more it is true (and vice versa).

Blacklists — These might be specific to UEIDs, versions of SW, deployments a particular OEM or such

Debug status — Most of the debug status values can vary on a day-day basis

OEM model — If the attestation is implemented by a chip vendor and the endorsement is for the chip, then the OEM model will vary widely.

None of these can be criteria as to whether an attestation key is put into a device or not as they are not known at manufacturing time and/or must be allowed to vary widely after manufacturing.

I think what I’ve described above lines up pretty well for a TPM. The system architecture is mostly set by the TCG. HW TPMs are almost always certified. They are independent of OEM model. It also lines up reasonably well with secure elements and can line up with TEE’s.  

The crux of endorsement to me is the security characteristics of the attester that protect the attestation key because there is generally no recovery from a compromised attestation key. It sets the baseline risk of the HW and SW of the device.

On one extreme is a separate endorsement for every device (“micro endorsement"?), which is what I think Thomas and ARM PSA are tending towards. The other extreme is one endorsement for a product line (“macro endorsement"?),, say a product line of TPMs. Then it’s more like the data sheet for the product. 

Then there’s different ways to fan this out to the different key / signing schemes (per-device key, group key, ECDAA, X.509). For example a macro-endorsement could include the root of an X.509 hierarchy and the individual devices (or groups of devices) would have individual keys that chain up. With a micro-endorsement the per-device public key could be per endorsement.

The most important thing about the endorsement seems to me is the characterization of how the attestation key is protected.

LL

> On Apr 7, 2020, at 7:36 AM, Thomas Fossati <[email-masked]> wrote:
> 
> Hi Laurence,
> 
> <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
> [1] https://www.ietf.org/id/draft-tschofenig-rats-psa-token-05.html#name-implementation-id <https://www.ietf.org/id/draft-tschofenig-rats-psa-token-05.html#name-implementation-id>
> [2] https://www.ietf.org/id/draft-tschofenig-rats-psa-token-05.html#name-instance-id <https://www.ietf.org/id/draft-tschofenig-rats-psa-token-05.html#name-instance-id>
> 
> 
>

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 7 Apr 2020 23:11:29 +0000

See inline nms>

From: RATS <[email-masked]> on behalf of Laurence Lundblade <[email-masked]>
Date: Tuesday, April 7, 2020 at 12:12 PM
To: Thomas Fossati <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Smith, Ned" <[email-masked]>
Subject: Re: [Rats] Endorsement ID and verification key (was Processing Endorsements and Evidence into Results)

My inclination is to associate endorsements with time-invariant characteristics of the device. At the moment this doesn’t seem like the only way to do it, but it seems like a good way. Things that are not time invariant are policy, k-g-v or such.
Nms> Certainly any property that is time invariant (about the device) can be explicitly captured in Endorsements. Since they are time-invariant it doesn’t make sense to Attest to them in Evidence (they will always be the same result). I disagree that Endorsement MUST ONLY be time invariant claims however.
Nms> Not sure if the questions below are rhetorical.

Endorsement

My thinking for EAT was that you only put attestation keys into devices that meet some criteria like some of the above. Since there is often no way to recover from a compromised attestation key because no key more secure than it, you kind of have to have all that.
Nms> The idea that a device has an Attesting Environment(s) and Target Environment(s) implies the Attesting Environment is/should be more hardened is what some refer to as Root-of-Trust. The techniques for protecting the Attesting Environment should be immutable/invariant which is why some use the term “Hardware Root of Trust” when describing an ideal Attesting Environment.

Since these don’t change much over time, the endorsement wouldn’t change.
Nms> The Endorsement conveys the immutability / property of time invariance to the Verifier. It describes the Root of Trust / Attesting Env.  Where the attestation key is held because if the root attestation sub-system is broken there is no other protection mechanism to fall back on for recovery that doesn’t involve physical remediation.

 They could even span several models and varying HW.
Nms> Or not. It depends on the system architecture.

Policy, K-G-V, other
Nms> Policy (aka Appraisal Policy for Evidence, Appraisal Policy for Attestation Results) is different from Endorsement. Known Good Values are synonymous with Endorsement. The architecture uses one word to capture a variety of possible claims that supply chain entities can convey to Verifiers. I don’t think it makes sense to conflate Policy with Endorsements. It might make sense for Policy to have an opinion as to what is ‘good’. But it is a case of an Owner deciding vs. the manufacturer. It is appropriate for both to have something to say about the claim.
SW Versions — As long as the SW follows a development process like that above,

it doesn’t have to be included in the endorsement.
Nms> I disagree with this conclusion. The vendor determines which version string is applied to SW it produces. That value is an assertion only the SW vendor can make. Owner Policy can say that the version is ‘good’ or ‘bad’ or ‘unknown’ but can’t say that the version is X.

Of course the smaller the SW and the better the process, the more it is true (and vice versa).

Blacklists — These might be specific to UEIDs, versions of SW, deployments a particular OEM or such
Nms> Many entities can produce black/white lists legitimately. If the entity is in the supply chain the assertion is an Endorsement. If the entity is an Owner then the assertion is a Policy. The difference is in how the Verifier treats Endorsements vs. Policies.
Example:
      S0) Endorser E0 says Key KD speaks for Device D
S1) Attester KD says SW S is extant on D
      S2) Endorser E1 says SW S is version 1.0
      S3) Endorser E2 says version 1.0 (of S) is bad
      S4) Owner policy says version 1.0 (of S) is good.
      S5) Owner policy says E1 is trusted to say S is version 1.0
      S6) Owner policy says E2 is trusted to say S is good/bad
      S7) Owner Policy says E0 is trusted to provision KD on D
      Appraisal evaluates the statements:
Prove: X = SW is extant on device D and it is good.
Proof:
       S3 says E2 says version 1.0 is bad <and> S6 says E2 can say this | valid
S2 says E1 says S is version 1.0 <and> S5 says E1 can say this | valid
       S1 says KD says S is extant on D <and> S7 says KD can say this | valid
       S0 says KD speaks for D <and> S7 says E0 can say this | valid
  Therefore X is FALSE at this point; but
       S4 says version 1.0 is good <and> Owner can say anything | valid
  Therefore X is TRUE

Debug status — Most of the debug status values can vary on a day-day basis
Nms> It depends on the debug mechanism.

OEM model — If the attestation is implemented by a chip vendor and the endorsement is for the chip, then the OEM model will vary widely.
Nms> Not sure how this is relevant

None of these can be criteria as to whether an attestation key is put into a device or not as they are not known at manufacturing time and/or must be allowed to vary widely after manufacturing.
Nms> Devices can be a mix of hardware and firmware. Even hardware can be mutable. Endorsements describe the mutability properties of the device. Endorsement also describe the range of possible (and acceptable) values the mutable properties can accept.

I think what I’ve described above lines up pretty well for a TPM.
Nms> I disagree.
The system architecture is mostly set by the TCG.
Nms> No, the TCG specifies interfaces not implementation.
HW TPMs are almost always certified.
Nms> An independent evaluation entity specifies how an implementation scored according to the criteria. There are lots of TPMs that are not certified or are certified to different levels. The important point should be that the Verifier doesn’t know unless it asks for Evidence and Endorsements.
They are independent of OEM model.
Nms> This isn’t true. Every TPM has a vendor, model/product name etc… that is not chosen by TCG.
It also lines up reasonably well with secure elements and can line up with TEE’s.

The crux of endorsement to me is the security characteristics of the attester that protect the attestation key because there is generally no recovery from a compromised attestation key. It sets the baseline risk of the HW and SW of the device.
Nms> I agree that the Attesting Environment is trusted by the Target Environment. If the Attesting Environment is compromised, there is no way for the Target Environment trustworthiness to be assessed.

On one extreme is a separate endorsement for every device (“micro endorsement"?), which is what I think Thomas and ARM PSA are tending towards. The other extreme is one endorsement for a product line (“macro endorsement"?),, say a product line of TPMs.
Nms> I disagree with this characterization of TPMs. Each vendor’s TPM product is different and has different intrinsic trustworthiness properties. Many are CC evaluated and some achieve a similar score. That doesn’t mean they are the same product.
Then it’s more like the data sheet for the product.

Then there’s different ways to fan this out to the different key / signing schemes (per-device key, group key, ECDAA, X.509). For example a macro-endorsement could include the root of an X.509 hierarchy and the individual devices (or groups of devices) would have individual keys that chain up.
Nms> The root of a X.509 hierarchy is called a “Root CA”. A policy that accepts a Root CA public key/cert is called a “Trust Anchor”. A trust anchor management protocol that conveys a trust anchor to a Verifier is an Endorsement of a Root CA that chains to an attestation key. The Endorsement might be useful for constructing a policy similar to “S0” above. (It isn’t saying more than that IMO)

With a micro-endorsement the per-device public key could be per endorsement.
Nms> I don’t think the architecture should try to define ‘micro endorsement’ or ‘macro endorsement’.

The most important thing about the endorsement seems to me is the characterization of how the attestation key is protected.
Nms> The first line in the Endorsement section of the architecture document says this almost verbatim.

LL

On Apr 7, 2020, at 7:36 AM, Thomas Fossati <[email-masked]<mailto:[email-masked]>> wrote:

Hi Laurence,

On 03/04/2020, 20:37, "RATS on behalf of Laurence Lundblade"
<[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

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

Thoughts?

cheers, thanks!

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 8 Apr 2020 13:06:09 -0700

Hi Ned,

Seems like there is general agreement on the core purpose of the endorsement — describing the security characteristics of the Endorser.

I’m not advocating any definitions in the architecture document here. I was after some general characteristics and common understanding. I know implementations are going to vary wildly. 

To be more clear on “OEM model”. I was using that to refer to the end device like a router, a phone or a washing machine, not the manufacturer of a chip, a TPM or a TEE.  The TEE might be the Attester and might be the same Attester with the same endorsement that is in both a Motorola phone and a Sony phone, each with a different OEM Model claim.

When I was referring to a “product line of TPMs”, I was thinking of several very similar models from the same TPM vendor. Seems like this would share the more invariant characteristics of a Endorsement and maybe could share an Endorsement. However, I have no strong sense that it has to be one way or the other.

One of the main reasons I’ve dug into all this is to try to understand how Endorsements and Verification Keys are identified in the Evidence so we can define what is needed in EAT. That was the main reason for distinguishing micro and macro endorsements. It is not to have them formally defined. 

Thomas’ comments where really enlightening as to how ARM PSA is thinking of this (and how it was quite different from mine).

I haven’t come to any conclusions yet. Would be interested to understand how identification of a particular Key come from a particular Endorsement which comes from fields COSE / JOSE headers and / or contained claims for lots of different instantiations and implements of of RATS protocols.

LL

> On Apr 7, 2020, at 4:11 PM, Smith, Ned <[email-masked]> wrote:
> 
> See inline nms>
>  
> To: Thomas Fossati <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "Smith, Ned" <[email-masked] <mailto:[email-masked]>>
>> On Apr 7, 2020, at 7:36 AM, Thomas Fossati <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> Hi Laurence,
>>

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 9 Apr 2020 11:46:06 +0200

Hi Laurence,

did you really mean "describing the security characteristics of the 
Endorser" or instead "describing the security characteristics of the 
Attester by an Endorser"?

Viele Grüße,

Henk

On 08.04.20 22:06, Laurence Lundblade wrote:
> Hi Ned,
> 
> Seems like there is general agreement on the core purpose of the 
> endorsement — describing the security characteristics of the Endorser.
> 
> I’m not advocating any definitions in the architecture document here. I 
> was after some general characteristics and common understanding. I know 
> implementations are going to vary wildly.
> 
> To be more clear on “OEM model”. I was using that to refer to the end 
> device like a router, a phone or a washing machine, not the manufacturer 
> of a chip, a TPM or a TEE.  The TEE might be the Attester and might be 
> the same Attester with the same endorsement that is in both a Motorola 
> phone and a Sony phone, each with a different OEM Model claim.
> 
> When I was referring to a “product line of TPMs”, I was thinking of 
> several very similar models from the same TPM vendor. Seems like this 
> would share the more invariant characteristics of a Endorsement and 
> maybe could share an Endorsement. However, I have no strong sense that 
> it has to be one way or the other.
> 
> 
> One of the main reasons I’ve dug into all this is to try to understand 
> how Endorsements and Verification Keys are identified in the Evidence so 
> we can define what is needed in EAT. That was the main reason for 
> distinguishing micro and macro endorsements. It is not to have them 
> formally defined.
> 
> Thomas’ comments where really enlightening as to how ARM PSA is thinking 
> of this (and how it was quite different from mine).
> 
> I haven’t come to any conclusions yet. Would be interested to understand 
> how identification of a particular Key come from a particular 
> Endorsement which comes from fields COSE / JOSE headers and / or 
> contained claims for lots of different instantiations and implements of 
> of RATS protocols.
> 
> LL
> 
> 
> 
>> On Apr 7, 2020, at 4:11 PM, Smith, Ned <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> See inline nms>
>> *From:*RATS <[email-masked] <mailto:[email-masked]>> on 
>> behalf of Laurence Lundblade <[email-masked] 
>> <mailto:[email-masked]>>
>> *Date:*Tuesday, April 7, 2020 at 12:12 PM
>> *To:*Thomas Fossati <[email-masked] 
>> <mailto:[email-masked]>>
>> *Cc:*"[email-masked] <mailto:[email-masked]>" <[email-masked] 
>> <mailto:[email-masked]>>, "Smith, Ned" <[email-masked] 
>> <mailto:[email-masked]>>
>> *Subject:*Re: [Rats] Endorsement ID and verification key (was 
>> Processing Endorsements and Evidence into Results)
>> My inclination is to associate endorsements with time-invariant 
>> characteristics of the device. At the moment this doesn’t seem like 
>> the only way to do it, but it seems like a good way. Things that are 
>> not time invariant are policy, k-g-v or such.
>> Nms> Certainly any property that is time invariant (about the device) 
>> can be explicitly captured in Endorsements. Since they are 
>> time-invariant it doesn’t make sense to Attest to them in Evidence 
>> (they will always be the same result). I disagree that Endorsement 
>> MUST ONLY be time invariant claims however.
>> *_Endorsement_*
>>> System architecture — Does the Attester use a TEE or a TPM or maybe 
>>> it is simple system with just a simple CPU, but it is encased in 
>>> titanium. Is defense against chip invasive attacks considered? Do 
>>> keys become inaccessible when debug is enabled.
>>> Development process — Is there a special security-oriented team? Does 
>>> the team have a code review policy? Is there a bug bounty? Are the 
>>> desktops and IT systems used for HW and SW development isolated?
>>> Manufacturing — Are the factories secured in a special way? Is the 
>>> attestation key provisioning system hardened in some way (e.g., uses 
>>> HSMs).
>> My thinking for EAT was that you only put attestation keys into 
>> devices that meet some criteria like some of the above. Since there is 
>> often no way to recover from a compromised attestation key because no 
>> key more secure than it, you kind of have to have all that.
>> Nms> The idea that a device has an Attesting Environment(s) and Target 
>> Environment(s) implies the Attesting Environment is/should be more 
>> hardened is what some refer to as Root-of-Trust. The techniques for 
>> protecting the Attesting Environment should be immutable/invariant 
>> which is why some use the term “Hardware Root of Trust” when 
>> describing an ideal Attesting Environment.
>> Nms> The Endorsement conveys the immutability / property of time 
>> invariance to the Verifier. It describes the Root of Trust / Attesting 
>> Env.  Where the attestation key is held because if the root 
>> attestation sub-system is broken there is no other protection 
>> mechanism to fall back on for recovery that doesn’t involve physical 
>> remediation.
>> *_Policy, K-G-V, other_*
>> Nms> Policy (aka Appraisal Policy for Evidence, Appraisal Policy for 
>> Attestation Results) is different from Endorsement. Known Good Values 
>> are synonymous with Endorsement. The architecture uses one word to 
>> capture a variety of possible claims that supply chain entities can 
>> convey to Verifiers. I don’t think it makes sense to conflate Policy 
>> with Endorsements. It might make sense for Policy to have an opinion 
>> as to what is ‘good’. But it is a case of an Owner deciding vs. the 
>> manufacturer. It is appropriate for both to have something to say 
>> about the claim.
>>> Nms> I disagree with this conclusion. The vendor determines which 
>>> version string is applied to SW it produces. That value is an 
>>> assertion only the SW vendor can make. Owner Policy can say that the 
>>> version is ‘good’ or ‘bad’ or ‘unknown’ but can’t say that the 
>>> version is X.
>>> Nms> Many entities can produce black/white lists legitimately. If the 
>>> entity is in the supply chain the assertion is an Endorsement. If the 
>>> entity is an Owner then the assertion is a Policy. The difference is 
>>> in how the Verifier treats Endorsements vs. Policies.
>>> Example:
>>> OEM model — If the attestation is implemented by a chip vendor and 
>>> the endorsement is for the chip, then the OEM model will vary widely.
>> None of these can be criteria as to whether an attestation key is put 
>> into a device or not as they are not known at manufacturing time 
>> and/or must be allowed to vary widely after manufacturing.
>> Nms> Devices can be a mix of hardware and firmware. Even hardware can 
>> be mutable. Endorsements describe the mutability properties of the 
>> device. Endorsement also describe the range of possible (and 
>> acceptable) values the mutable properties can accept.
>> Nms> An independent evaluation entity specifies how an implementation 
>> scored according to the criteria. There are lots of TPMs that are not 
>> certified or are certified to different levels. The important point 
>> should be that the Verifier doesn’t know unless it asks for Evidence 
>> and Endorsements.
>> The crux of endorsement to me is the security characteristics of the 
>> attester that protect the attestation key because there is generally 
>> no recovery from a compromised attestation key. It sets the baseline 
>> risk of the HW and SW of the device.
>> Nms> I agree that the Attesting Environment is trusted by the Target 
>> Environment. If the Attesting Environment is compromised, there is no 
>> way for the Target Environment trustworthiness to be assessed.
>> On one extreme is a separate endorsement for every device (“micro 
>> endorsement"?), which is what I think Thomas and ARM PSA are tending 
>> towards. The other extreme is one endorsement for a product 
>> line (“macro endorsement"?),, say a product line of TPMs.
>> Nms> I disagree with this characterization of TPMs. Each vendor’s TPM 
>> product is different and has different intrinsic trustworthiness 
>> properties. Many are CC evaluated and some achieve a similar score. 
>> That doesn’t mean they are the same product.
>> Then there’s different ways to fan this out to the different key / 
>> signing schemes (per-device key, group key, ECDAA, X.509). For example 
>> a macro-endorsement could include the root of an X.509 hierarchy and 
>> the individual devices (or groups of devices) would have individual 
>> keys that chain up.
>> Nms> The root of a X.509 hierarchy is called a “Root CA”. A policy 
>> that accepts a Root CA public key/cert is called a “Trust Anchor”. A 
>> trust anchor management protocol that conveys a trust anchor to a 
>> Verifier is an Endorsement of a Root CA that chains to an attestation 
>> key. The Endorsement might be useful for constructing a policy similar 
>> to “S0” above. (It isn’t saying more than that IMO)
>> The most important thing about the endorsement seems to me is the 
>> characterization of how the attestation key is protected.
>>> <[email-masked] <mailto:[email-masked]>on behalf 
>>> [email-masked] <mailto:[email-masked]>> wrote:
>>>
>>> [1]https://www.ietf.org/id/draft-tschofenig-rats-psa-token-05.html#name-implementation-id
>>> [2]https://www.ietf.org/id/draft-tschofenig-rats-psa-token-05.html#name-instance-id
>>>
>>>
>>>
>>> IMPORTANT NOTICE: The contents of this email and any attachments are 
>>> confidential and may also be privileged. If you are not the intended 
>>> recipient, please notify the sender immediately and do not disclose 
>>> the contents to any other person, use it for any purpose, or store or 
>>> copy the information in any medium. Thank you.

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 9 Apr 2020 11:54:09 +0000

Hi Laurence,

On 07/04/2020, 20:12, "Laurence Lundblade" <[email-masked]> wrote:
> On one extreme is a separate endorsement for every device ("micro
> towards. The other extreme is one endorsement for a product line
> (macro endorsement"?), say a product line of TPMs. Then it's more
> like the data sheet for the product.
>
> Then there's different ways to fan this out to the different key /
> keys that chain up.  With a micro-endorsement the per-device public
> key could be per endorsement.

One tiny clarification.  While it's true that the current PSA
attestation format gravitates towards micro-endorsements, that is not a
necessary outcome of the underlying security architecture.  The baseline
requirement is for a raw public key, but nothing prevents it being a
certified key instead.

There is both already shipped and in-progress work that would help
moving in the direction, specifically:
- have the attestation key associated with a profiled [1] and compressed
  [2] cert;
- have EAT / PSA tokens carry cert material instead of just key
  identifiers [3].

cheers!

[1] RFC7925
[2] draft-mattsson-tls-cbor-cert-compress
[3] draft-ietf-cose-x509

---

From: Guy Fedorkow <[email-masked]>
Date: Thu, 9 Apr 2020 14:31:29 +0000

Hi Laurence,
  I understand that the discussion on the topic below mainly pertains to EAT, but I'd like to make sure we're not missing something on the RIV side.
  For OS software image integrity using a TPM, it seems like finding the right manifest shouldn't be that hard...
  The Attester needs to have pre-provisioned identity and attestation keys as outlined in the RIV draft.  That provides the Verifier with the vendor identity for the root of trust.  The measurement logs contain the alleged product name and version number for the software installed on the box.  Use the vendor ID to narrow the scope to specific vendor's product and version space, and find the RIM that matches.  Then check if the hashes line up; if so, you're good, if not, either the claim of what software is present was incorrect, or something got hacked.
  Seems like a verifier could follow this same model through the entire chain of trust, even through multiple vendors, as long as there are no gaps in the chain.
  I know EAT needs to work in a less-constrained environment, but let me know if you think we're oversimplifying this on RIV.

  Thanks
/guy

Juniper Business Use Only
From: RATS <[email-masked]> On Behalf Of Laurence Lundblade
Sent: Tuesday, April 7, 2020 3:13 PM
To: Thomas Fossati <[email-masked]>
Cc: [email-masked]; Ned Smith <[email-masked]>
Subject: Re: [Rats] Endorsement ID and verification key (was Processing Endorsements and Evidence into Results)

[External Email. Be cautious of content]

This is a reply to both Thomas and Ned's message on debug in the related threat.

My inclination is to associate endorsements with time-invariant characteristics of the device. At the moment this doesn't seem like the only way to do it, but it seems like a good way. Things that are not time invariant are policy, k-g-v or such.

Endorsement
System architecture - Does the Attester use a TEE or a TPM or maybe it is simple system with just a simple CPU, but it is encased in titanium. Is defense against chip invasive attacks considered? Do keys become inaccessible when debug is enabled.

Development process - Is there a special security-oriented team? Does the team have a code review policy? Is there a bug bounty? Are the desktops and IT systems used for HW and SW development isolated?

Manufacturing - Are the factories secured in a special way? Is the attestation key provisioning system hardened in some way (e.g., uses HSMs).

Certifications - These take a long time to achieve and will usually require some of the above.

Since these don't change much over time, the endorsement wouldn't change.  They could even span several models and varying HW.

Policy, K-G-V, other
SW Versions - As long as the SW follows a development process like that above, it doesn't have to be included in the endorsement. Of course the smaller the SW and the better the process, the more it is true (and vice versa).

Blacklists - These might be specific to UEIDs, versions of SW, deployments a particular OEM or such

Debug status - Most of the debug status values can vary on a day-day basis

OEM model - If the attestation is implemented by a chip vendor and the endorsement is for the chip, then the OEM model will vary widely.

I think what I've described above lines up pretty well for a TPM. The system architecture is mostly set by the TCG. HW TPMs are almost always certified. They are independent of OEM model. It also lines up reasonably well with secure elements and can line up with TEE's.

On one extreme is a separate endorsement for every device ("micro endorsement"?), which is what I think Thomas and ARM PSA are tending towards. The other extreme is one endorsement for a product line ("macro endorsement"?),, say a product line of TPMs. Then it's more like the data sheet for the product.

Then there's different ways to fan this out to the different key / signing schemes (per-device key, group key, ECDAA, X.509). For example a macro-endorsement could include the root of an X.509 hierarchy and the individual devices (or groups of devices) would have individual keys that chain up. With a micro-endorsement the per-device public key could be per endorsement.

LL

Hi Laurence,

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:
 endorsements so there's no one-one correlation

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?

cheers, thanks!

[1] https://www.ietf.org/id/draft-tschofenig-rats-psa-token-05.html#name-implementation-id<https://urldefense.com/v3/__https:/www.ietf.org/id/draft-tschofenig-rats-psa-token-05.html*name-implementation-id__;Iw!!NEt6yMaO-gk!RQ8gyO3Roy-dIEd6S_ka45lFEGm1GIH2lt_D1NafmaQWpjjsOx629zhu-LmUi1MMMWs$>
[2] https://www.ietf.org/id/draft-tschofenig-rats-psa-token-05.html#name-instance-id<https://urldefense.com/v3/__https:/www.ietf.org/id/draft-tschofenig-rats-psa-token-05.html*name-instance-id__;Iw!!NEt6yMaO-gk!RQ8gyO3Roy-dIEd6S_ka45lFEGm1GIH2lt_D1NafmaQWpjjsOx629zhu-LmUQhSzg4E$>

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/rats__;!!NEt6yMaO-gk!RQ8gyO3Roy-dIEd6S_ka45lFEGm1GIH2lt_D1NafmaQWpjjsOx629zhu-LmUzQTPUAY$>

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 9 Apr 2020 09:23:21 -0700

Attester by Endorser. Thanks for the correction, Henk.

LL

> On Apr 9, 2020, at 2:46 AM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi Laurence,
> 
> did you really mean "describing the security characteristics of the Endorser" or instead "describing the security characteristics of the Attester by an Endorser"?
> 
> Viele Grüße,
> 
> Henk
> 
>>> On Apr 7, 2020, at 4:11 PM, Smith, Ned <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> See inline nms>
>>> *From:*RATS <[email-masked] <mailto:[email-masked]>> on behalf of Laurence Lundblade <[email-masked] <mailto:[email-masked]>>
>>> *To:*Thomas Fossati <[email-masked] <mailto:[email-masked]>>
>>> *Cc:*"[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "Smith, Ned" <[email-masked] <mailto:[email-masked]>>
>>> *Subject:*Re: [Rats] Endorsement ID and verification key (was Processing Endorsements and Evidence into Results)
>>>> <[email-masked] <mailto:[email-masked]>on behalf [email-masked] <mailto:[email-masked]>> wrote:
>>>>

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 9 Apr 2020 13:54:35 -0700

Hi Guy,

> On Apr 9, 2020, at 7:31 AM, Guy Fedorkow <[email-masked]> wrote:
> 
> Hi Laurence,
>   I understand that the discussion on the topic below mainly pertains to EAT, but I’d like to make sure we’re not missing something on the RIV side.

Was trying for a general description into which TPM-based stuff fits too.

>   For OS software image integrity using a TPM, it seems like finding the right manifest shouldn’t be that hard…
>   The Attester needs to have pre-provisioned identity and attestation keys as outlined in the RIV draft.  That provides the Verifier with the vendor identity for the root of trust. 

That is to say you have a functioning TPM-based attester. Identity is of the Attester only, not the OS Software, right?

> The measurement logs contain the alleged product name and version number for the software installed on the box.

Are you saying that the OS software will write its product name and version into a TPM measurement log?

> Use the vendor ID to narrow the scope to specific vendor’s product and version space, and find the RIM that matches.

Presumably the vendor of the device, (e.g., Samsung for a phone, Lenovo for a laptop) since vendor’s customize OS SW.

>   Then check if the hashes line up; if so, you’re good, if not, either the claim of what software is present was incorrect, or something got hacked.

Seems like there’s a step of measuring the OS Software missing. That has to be built into the boot loading sequence to be properly secure. Step 1 measures the code for Step 2, then Step 2 loads, then Step 2 measures code for Step 3 all the while recording the measurements in the TPM.  Pretty sure there are lots of OS’s that don’t know how to put measurements into a TPM.

Some TEE-based architectures use the TEE to load and verify a subsystem. For example a phone might consist of a TEE, a main OS running Android and some subsystems (Audio, cellular modem…). The TEE takes care of the loading and verification of the subsystem SW by reading and writing into the subsystems memory, then the TEE signals the subsystem to go out of reset. It more or less booted without the subsystem’s CPU doing a thing. (And the TEE can later to a run-time integrity check on it, something you can’t do with a TPM).

>   Seems like a verifier could follow this same model through the entire chain of trust, even through multiple vendors, as long as there are no gaps in the chain.

Seems like you need each participant in the chain know how to measure and write into the TPM. That doesn’t seem likely to happen to me unless the whole architecture was designed around a TPM.

>   I know EAT needs to work in a less-constrained environment, but let me know if you think we’re oversimplifying this on RIV.

EAT is intended to work in very constrained environments. If you just have limited subset of claims, you can build HW to implement EAT. CBOR is designed well enough that this is possible.

>   Thanks

Appreciate these discussions as it helps illuminate the core principles at work on the TPM side and the TEE side. Both are secure, AFAIK :-), but made different choices and have different capabilities. 

LL

> From: RATS <[email-masked] <mailto:[email-masked]>> On Behalf Of Laurence Lundblade
> Cc: [email-masked] <mailto:[email-masked]>; Ned Smith <[email-masked] <mailto:[email-masked]>>
> [1] https://www.ietf.org/id/draft-tschofenig-rats-psa-token-05.html#name-implementation-id <https://urldefense.com/v3/__https:/www.ietf.org/id/draft-tschofenig-rats-psa-token-05.html*name-implementation-id__;Iw!!NEt6yMaO-gk!RQ8gyO3Roy-dIEd6S_ka45lFEGm1GIH2lt_D1NafmaQWpjjsOx629zhu-LmUi1MMMWs$>
> [2] https://www.ietf.org/id/draft-tschofenig-rats-psa-token-05.html#name-instance-id <https://urldefense.com/v3/__https:/www.ietf.org/id/draft-tschofenig-rats-psa-token-05.html*name-instance-id__;Iw!!NEt6yMaO-gk!RQ8gyO3Roy-dIEd6S_ka45lFEGm1GIH2lt_D1NafmaQWpjjsOx629zhu-LmUQhSzg4E$>
> 
> 
> 
> https://www.ietf.org/mailman/listinfo/rats <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/rats__;!!NEt6yMaO-gk!RQ8gyO3Roy-dIEd6S_ka45lFEGm1GIH2lt_D1NafmaQWpjjsOx629zhu-LmUzQTPUAY$>

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 10 Apr 2020 00:01:30 +0000

Inline nms>

From: RATS <[email-masked]> on behalf of Laurence Lundblade <[email-masked]>
Date: Wednesday, April 8, 2020 at 1:06 PM
To: "Smith, Ned" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Thomas Fossati <[email-masked]>
Subject: Re: [Rats] Endorsement ID and verification key (was Processing Endorsements and Evidence into Results)

Hi Ned,

To be more clear on “OEM model”. I was using that to refer to the end device like a router, a phone or a washing machine, not the manufacturer of a chip, a TPM or a TEE.  The TEE might be the Attester
Nms> I think you mean ‘Attesting Environment’
and might be the same Attester with the same endorsement that is in both a Motorola phone and a Sony phone, each with a different OEM Model claim.
Nms> Right. That would be true if the ingredients for the Attesting Environments for the various models was the same subset. The Endorsement could be a manifest of a variety of ingredients that each could be identified in terms of {vendor, model, version} in some sort of nesting structure. Maybe there are privacy concerns or whatever, but most systems have a way of reporting something about what is inside the chassis. Endorsements could follow something like that. A TPM, TEE, MCU or other technology could be part of the Attesting Environment. The Endorsement could be explicit about that. Since there is a ‘root’ Attesting Environment (one that is the bottom layer), the Endorsement is the only mechanism for communicating these details to the Verifier. Attestation doesn’t work except as an introspection (which some believe has security challenges).

When I was referring to a “product line of TPMs”, I was thinking of several very similar models from the same TPM vendor. Seems like this would share the more invariant characteristics of a Endorsement and maybe could share an Endorsement. However, I have no strong sense that it has to be one way or the other.
Nms> I think it is correct for Endorsements to provide vectors of interchangeable parts for a given system. For example, many OEMs source the ‘same’ part from multiple suppliers to ensure there is redundancy in the supply chain. The parts have different vendor, model, version but comply to a standard set of interface specs so that parts can be interchangeable. An Endorsement might list all of the possible suppliers for the same ‘spec’ part. If that is the case, then attestation Evidence identifies which of the various possibilities was chosen.

There is a possibility where an “introspection” case could exist for the ‘root’ Attesting Environment where the OEM sources multiple suppliers for the same ‘spec’ parts and the Attesting Environment may be the only available entity to disambiguate which supplier’s part was chosen. It may also be the case that the part isn’t self-aware and therefore remains silent. The Verifier may have to conclude that the root Attesting Environment is either vendor-A or vendor-B (based on the Endorsement vector), but doesn’t know which. Verifier Policy has to allow both vendor’s spec part since it can’t tell the difference. If a flaw was found in one vendor’s spec part but not the other vendor’s part both would have to be disallowed since it can’t tell which vendor’s part was used.

Ideally, these corner cases would be minimized in implementations.

From a definitional perspective, Endorsement data definition should anticipate the possibility of multiple instances (suppliers) for the same ‘spec’ part. Whereas for Evidence, it may be adequate if it only supported 0 or 1 occurrences of the ‘spec’ part.

One of the main reasons I’ve dug into all this is to try to understand how Endorsements and Verification Keys are identified in the Evidence
Nms> I think of Endorsements as ‘class’ structures where an Endorsement represents a class of something, for example an iPhone 8+. Evidence represents an ‘instance’ of something, for example and iPhone 8+ with the serial number XYZ. The key is used to authenticate the instance (not necessarily identify it). For example, if the key was a group key like DAA / EPID then knowledge of the key would not be sufficient to narrow down to an instance. You still need something like serial number or UEID. Evidence therefore should contain ‘instance’ identifier(s) as claims. The keys are external to Evidence. Therefore, the wording “Verification Keys are identified in the Evidence” seems incorrect because the instance identifier doesn’t necessarily have to be a key. It is possible to generate an instance identifier from a key, but that is different from being the key.

so we can define what is needed in EAT. That was the main reason for distinguishing micro and macro endorsements. It is not to have them formally defined.

I haven’t come to any conclusions yet. Would be interested to understand how identification of a particular Key come from a particular Endorsement
Nms> Given the above explanation of class and instance identifiers and their relationship to Endorsments and Evidence, does it still make sense to pose the question as “how identification of a particular Key come from a particular Endorsement”?

which comes from fields COSE / JOSE headers and / or contained claims for lots of different instantiations and implements of of RATS protocols.
Nms> I think of the Verifier’s task as primarily needing to; for each claim in the Evidence, (a) select from a list of possible reference synonym claims and (b) match the Evidence claim with one in the list.

Nms> The Verifier needs enough context about how the device is constructed (e.g. submod? context) to know which Endorsements should be used as the reference claims for a given Evidence claim. The conveyance protocol and attestation key play a role in establishing this context, but I don’t think the architecture has been fleshed out enough yet. For example, it might be necessary for Endorsements to be structured according to a submods-like “bill-of-materials” and given a sort of record identifier that can be included with (in?) the Evidence so the Verifier knows how to ask for the appropriate Endorsement records. It is also possible that the conveyance protocol could convey the Endorsement records directly if they happen to be available on the Attester. But it is still necessary for the Verifier to correlate which Endorsement record corresponds to which piece of Evidence. A ‘piece of Evidence’ could be nested (e.g. submod?) consisting of still other ‘pieces of evidence’ etc… This also implies the Endorsement record reference(s) is(are) known by the Attesting Environment at the time Evidence is conveyed. (*Maybe this should be added as an issue to the arch draft?*)

@Henk Berkholz<mailto:[email-masked]> – Does CoSWID have the equivalent of a record identifier for something that is like a sub-component of something else? /Resource/ doesn’t allow nesting and /File/ seems to be overloading what was originally intended. Of course /Resource/ could refer to a UCCS (https://tools.ietf.org/html/draft-birkholz-rats-uccs-00) which allows nesting.

LL

On Apr 7, 2020, at 4:11 PM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

See inline nms>

From: RATS <[email-masked]<mailto:[email-masked]>> on behalf of Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 7, 2020 at 12:12 PM
To: Thomas Fossati <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Smith, Ned" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] Endorsement ID and verification key (was Processing Endorsements and Evidence into Results)

Endorsement

Policy, K-G-V, other

LL

Hi Laurence,

There's a few scenarios:

Thoughts?

cheers, thanks!

---

From: Guy Fedorkow <[email-masked]>
Date: Fri, 10 Apr 2020 13:25:06 +0000

Hi Lawrence

Juniper Business Use Only
From: Laurence Lundblade <[email-masked]>
Sent: Thursday, April 9, 2020 4:55 PM
To: Guy Fedorkow <[email-masked]>
Cc: [email-masked]; Ned Smith <[email-masked]>
Subject: Re: [Rats] Endorsement ID and verification key (was Processing Endorsements and Evidence into Results)

Hi Guy,

On Apr 9, 2020, at 7:31 AM, Guy Fedorkow <[email-masked]<mailto:[email-masked]>> wrote:

Hi Laurence,

Was trying for a general description into which TPM-based stuff fits too.
[guy] Yes, I appreciate the need for a general solution, but at the same time, I’d like to try to not import complexity to the applications that don’t seem to need it.

That is to say you have a functioning TPM-based attester. Identity is of the Attester only, not the OS Software, right?
[guy] Yes, the pre-provisioned keys assumed in RIV are for the identity of the platform itself (DevID) and the attestation key in the TPM (IAK).  Implementations using TPM of course assume that the TPM itself is secure, but also require some implicitly-trusted code to take the first measurement, launching the chain of trust.

Are you saying that the OS software will write its product name and version into a TPM measurement log?
[guy] – I don’t think it matters…  the OS can report it’s version and name any way it wants…  it’s only a hint at shortening a search for an applicable RIM.

Presumably the vendor of the device, (e.g., Samsung for a phone, Lenovo for a laptop) since vendor’s customize OS SW.
[guy] Yes.  This admittedly is *much* easier on an embedded device like a router, where the vendor supplies the hardware, it’s root of trust, and the OS, but I don’t think that’s an essential requirement.

[guy] Absolutely, I think most integrity plans assume the chain of trust model.  The TPM approach assumes an unbroken chain of measurements from the root of trust. Lots of OS’s can’t do that, but all an embedded vendor needs is one that can!

Seems like you need each participant in the chain know how to measure and write into the TPM. That doesn’t seem likely to happen to me unless the whole architecture was designed around a TPM.
[guy] See “embedded” above 😊

EAT is intended to work in very constrained environments. If you just have limited subset of claims, you can build HW to implement EAT. CBOR is designed well enough that this is possible.
[guy] ah, difference in what we mean by Constrained…  I think you’re thinking of constrained in terms of power and transistors.  I was thinking more of the ecosystem…  as you say, you can’t just take any old random collection of parts, OS’s and applications, stir in some TPM and get security.  (As much as our various VP’s and exec’s would like!)

  Thanks

[guy] Yes, different means to a similar end.  I think the view partly depends on whether the vendor in question principally relies commodity processors, or is in charge of designing their processors from silicon on up.
  Thanks Laurence!

/guy

LL

Juniper Business Use Only
From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Laurence Lundblade
Sent: Tuesday, April 7, 2020 3:13 PM
To: Thomas Fossati <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Ned Smith <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] Endorsement ID and verification key (was Processing Endorsements and Evidence into Results)

Endorsement

Policy, K-G-V, other

LL

Hi Laurence,

There's a few scenarios:

Thoughts?

cheers, thanks!

---

From: Laurence Lundblade <[email-masked]>
Date: Sun, 12 Apr 2020 11:56:17 -0700

Trying again, after re reading your question a few times (and a few not-sent replies).

First you need the endorsement for the TPM that is serving as the attester. This endorsement would come from the TPM vendor. I assume that is fairly well understood and in practice today through TPM architecture and conventions already in place with things like IDevID. (Maybe you all know it, but I don’t know how this works. I would be interested in references and/or a description of it).

Next you need to identify the RIM. That might come from the OS Vendor or from the device vendor or even a third party, none of which are the TPM vendor. For example, with Android, Google produces the OS, but it is open source and the phone (the device) vendor can modify it, so the RIM would probably come from the phone/device vendor. It seems possible to have split RIMs where part comes from the the OS vendor and part comes from the device vendor.

Seems like OS/device/3rd-party Vendor IDs, product names and product versions are very non-uniform. You couldn’t write much generic Verifier code to work with them as they are today. The best attempts at making these generic I know of seem EAT’s IEEE-based OEMID, and PSA’s EAN-13 based HW version, but I don’t think these are enough. Maybe there is something else out there. SWID of some sort? 

Agreed that the identifier of the RIM doesn’t have to be secured / attested, just like key ID’s don’t have to be. If the Verifier gets the wrong one, the verification just fails.

This is certainly not a solved problem in the EAT space. Maybe there’s a solution in common? My first though is some sort of URI, maybe related to SWID, that is part of the measurements in the Evidence sent to the Verifier. It doesn’t have to be mandatory or used by everyone, but it seems likely to benefit at least some.

To be clear, I’m thinking that the Endorsement of the TPM Attester is quite separate from the Endorsement that is the RIM. They come from completely different vendors. The TPM Endorsement is of little use to identify the RIM.

LL

>   The Attester needs to have pre-provisioned identity and attestation keys as outlined in the RIV draft.  That provides the Verifier with the vendor identity for the root of trust.  The measurement logs contain the alleged product name and version number for the software installed on the box.  Use the vendor ID to narrow the scope to specific vendor’s product and version space, and find the RIM that matches.  Then check if the hashes line up; if so, you’re good, if not, either the claim of what software is present was incorrect, or something got hacked.

---

From: "Shwetha Bhandari (shwethab)" <[email-masked]>
Date: Mon, 13 Apr 2020 01:44:19 +0000

> First you need the endorsement for the TPM that is serving as the attester. This endorsement would come from the TPM vendor. I assume that is fairly well understood and in practice today through TP…
Also endorsement of key used for attestation – the Attestation Identity key<https://trustedcomputinggroup.org/wp-content/uploads/IWG-AIK-CMC-enrollment-FAQ.pdf>.

> My first though is some sort of URI, maybe related to SWID, that is part of the measurements in the Evidence sent to the Verifier. It doesn’t have to be mandatory or used by everyone, but it seems likely to benefit at least some.

+1 to the URI. A programmatic and uniform way to query the published RIM for all the artifacts would be useful, I assume this cannot be reported by the device itself as it cannot be trusted. In addition to OEMID, HW ID/version, SWID – An easy way to look up RIM - vendor specific database to query - DNS RR hosted by the vendors perhaps?

Here’s an example of the RIM produced by a Network device and OS vendor:
https://www.cisco.com/c/en/us/about/trust-center/downloads.html

Thanks,
Shwetha

From: RATS <[email-masked]> on behalf of Laurence Lundblade <[email-masked]>
Date: Monday, April 13, 2020 at 12:26 AM
To: Guy Fedorkow <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Ned Smith <[email-masked]>
Subject: Re: [Rats] Endorsement ID and verification key (was Processing Endorsements and Evidence into Results)

LL

Hi Laurence,

  Thanks
/guy

Endorsement

Policy, K-G-V, other

LL

Hi Laurence,

There's a few scenarios:

Thoughts?

cheers, thanks!

---

From: Guy Fedorkow <[email-masked]>
Date: Mon, 13 Apr 2020 15:24:06 +0000

Hi Laurence,
  Thanks for your response...  I've added annotations, marked with [guy]...
/guy

Sent: Sunday, April 12, 2020 2:56 PM

First you need the endorsement for the TPM that is serving as the attester. This endorsement would come from the TPM vendor. I assume that is fairly well understood and in practice today through TPM architecture and conventions already in place with things like IDevID. (Maybe you all know it, but I don't know how this works. I would be interested in references and/or a description of it).
[guy] Yes, I think most TPMs ship with a pre-provisioned Endorsement Key and a certificate signed by the TPM manufacturer.  Use of that key is controlled to prevent unwanted privacy abuses, but it's there specifically to validate the source of the TPM.
  For RIV, I'm not sure that needs to be done by the end-user of the device...  the OEM who makes the 'router' (yes, or switch or firewall or access point) should pre-provision a DevID signed by the OEM, and a trustworthy OEM wouldn't sign an IDevID in their facility without verifying that the TPM they've just soldered down is authentic.
  Some OEMs actually customize their TPMs slightly to contain their own signature on the EK, rather than the TPM vendor's, but I don't think that's common.
  In addition to the identity of the device itself, RIV depends on verification of the certificate that goes with the TPM Attestation key.  We've made that as easy as possible in RIV by pre-provisioning the IAK along with the IDevID, so the two will contain the same identity information, signed by the same vendor.
  For more-generic TPM applications where a pre-provisioned DevID may be inappropriate, there's a well-specified series of steps to validate the TPM before remotely installing the ID or attestation keys.  The TCG spec with the gory details is still in draft, but if you have TCG access, it's called "TPM Keys for Platform DevID for TPM2".

Next you need to identify the RIM. That might come from the OS Vendor or from the device vendor or even a third party, none of which are the TPM vendor. For example, with Android, Google produces the OS, but it is open source and the phone (the device) vendor can modify it, so the RIM would probably come from the phone/device vendor. It seems possible to have split RIMs where part comes from the the OS vendor and part comes from the device vendor.
  [guy] Agreed - the RIM will almost certainly not come from the TPM vendor.  This seems fundamentally like a task for the system administrator, to decide who they trust for RIMs.  If the OEM or software vendor ships RIMs, that seems like an obvious choice, but administrators can decide any way they want.

Seems like OS/device/3rd-party Vendor IDs, product names and product versions are very non-uniform. You couldn't write much generic Verifier code to work with them as they are today. The best attempts at making these generic I know of seem EAT's IEEE-based OEMID, and PSA's EAN-13 based HW version, but I don't think these are enough. Maybe there is something else out there. SWID of some sort?
[guy] TCG has a draft spec out for public review covering RIM.  'DRAFT: TCG Reference Integrity Manifest Information Model'
    https://trustedcomputinggroup.org/wp-content/uploads/TCG_RIM_Model_v1-r13_2feb20.pdf
The doc is completely based on ISO SWID, with the NIST guidelines.  There's a CBOR variant called CoSWID at IETF (I think you can guess which Henk, out of the universe of all Henks, you could ask for details!)
  If you have interest in commenting on the TCG RIM spec, I know the authors would be glad to hear from you.
  But about identity of RIMs...
  The RIM is signed, so once you've done the policy task of deciding which RIM supplier you like, verifying it is easy.  I realize of course that there's little commonality on how to name a product or version, but I'm not sure that matters.  The RIM corresponds to a very specific product and release.  The vendor can call it whatever they want, as long as they don't issue two release with the same name.  After that, I think it's just a string compare.
  I suppose if third-party RIM suppliers exist, then the RIM has to explicitly call out the software manufacturer by name, but that's already part of the SWID & RIM specs.
  As far as we can tell, SWID embodies sufficient flexibility to describe any software release that can be expressed as files and directories.  I have a small project on my todo list to prove that for a Juniper release, but so far, I don't see a problem.  Again, if you're interested, now is the time for review!

Agreed that the identifier of the RIM doesn't have to be secured / attested, just like key ID's don't have to be. If the Verifier gets the wrong one, the verification just fails.

This is certainly not a solved problem in the EAT space. Maybe there's a solution in common? My first though is some sort of URI, maybe related to SWID, that is part of the measurements in the Evidence sent to the Verifier. It doesn't have to be mandatory or used by everyone, but it seems likely to benefit at least some.
[guy] Henk might have suggestion for potential commonality with EAT.  As noted, SWID is strongly oriented to software releases with packages, directories and files, but maybe there's something useful there.

To be clear, I'm thinking that the Endorsement of the TPM Attester is quite separate from the Endorsement that is the RIM. They come from completely different vendors. The TPM Endorsement is of little use to identify the RIM.
[guy] Yes, in fact I think there are at least three suppliers that could be verified; the TPM vendor, the hardware platform OEM who made the Attester, and the RIM supplier who certifies the software image.  Given the way RIV is scoped, I think verification of the TPM itself is up to the OEM, but verification of the OEM's DevID and IAK is one thing, and verification of the authenticity of the RIM is another independent operation, both of which  belong in a RATS-compatible Verifier.
  Let me know what we're missing!
  /guy

LL

Hi Laurence,

  Thanks
/guy

Endorsement

Policy, K-G-V, other

LL

Hi Laurence,

There's a few scenarios:

Thoughts?

cheers, thanks!

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 13 Apr 2020 11:44:14 -0700

So I suspect the router world is really different from the IoT world in a way that affects the finding of RIMs. 

Seems like the router world is a small number of manufacturers, less than ten. Seems like routers are purchased and managed by very technically competent staff that already work with lots of technical details. It’s not that hard for network admins to go to the router manufacturers web site and download a few RIMs and configure them into their verifiers.

Seems like the IoT world involves a much larger number of manufacturers, hundreds or even thousands. IoT management is scattered and works in lots of different ways. Sometimes it is the device maker itself. Sometimes it is an enterprise. Sometimes it is a third party, maybe with a fourth and fifth party...

Phones have their own challenge — they have huge numbers of relying parties — each app is a relying party.

It seems a URI-based scheme for finding RIMs is important for the IoT world, and maybe the phone world, but not so much for the router world. Seems like it has to be URI-based because that’s the way to identify a resource on the broad internet.

It looks like the TCG RIM document <https://trustedcomputinggroup.org/wp-content/uploads/TCG_RIM_Model_v1-r13_2feb20.pdf> already has something like this as mentioned in Appendix C. Not sure it is fully developed as it is in an appendix.

The TCG Platform Certificate Profile [10] also defines a PlatformConfigurationURI attribute that contains “URI where the reference integrity measurements could be obtained by the verifier”. The Platform Certificates Platform Configuration URI MUST hold a reference to the location of the Primary RIM Bundle. The URI MAY point to a location on the Endpoint platform or it MAY reside in a publicly accessible location. The Base RIM MUST contain a LINK element that points to the same URI as the Platform Certificates PlatformConfigurationURI. 

Glad to see the use of CoSWID. Seems like that will line up for EAT as well.

LL

> On Apr 13, 2020, at 8:24 AM, Guy Fedorkow <[email-masked]> wrote:
> 
> Hi Laurence,
>   Thanks for your response…  I’ve added annotations, marked with [guy]…
> /guy
>  
>  
>  
> From: Laurence Lundblade <[email-masked] <mailto:[email-masked]>> 
> To: Guy Fedorkow <[email-masked] <mailto:[email-masked]>>
> [guy] Yes, I think most TPMs ship with a pre-provisioned Endorsement Key and a certificate signed by the TPM manufacturer.  Use of that key is controlled to prevent unwanted privacy abuses, but it’s there specifically to validate the source of the TPM.
>   For RIV, I’m not sure that needs to be done by the end-user of the device…  the OEM who makes the ‘router’ (yes, or switch or firewall or access point) should pre-provision a DevID signed by the OEM, and a trustworthy OEM wouldn’t sign an IDevID in their facility without verifying that the TPM they’ve just soldered down is authentic.
>   Some OEMs actually customize their TPMs slightly to contain their own signature on the EK, rather than the TPM vendor’s, but I don’t think that’s common.
>   In addition to the identity of the device itself, RIV depends on verification of the certificate that goes with the TPM Attestation key.  We’ve made that as easy as possible in RIV by pre-provisioning the IAK along with the IDevID, so the two will contain the same identity information, signed by the same vendor.
>   For more-generic TPM applications where a pre-provisioned DevID may be inappropriate, there’s a well-specified series of steps to validate the TPM before remotely installing the ID or attestation keys.  The TCG spec with the gory details is still in draft, but if you have TCG access, it’s called “TPM Keys for Platform DevID for TPM2”.
>  
>   [guy] Agreed – the RIM will almost certainly not come from the TPM vendor.  This seems fundamentally like a task for the system administrator, to decide who they trust for RIMs.  If the OEM or software vendor ships RIMs, that seems like an obvious choice, but administrators can decide any way they want.
>  
>     https://trustedcomputinggroup.org/wp-content/uploads/TCG_RIM_Model_v1-r13_2feb20.pdf <https://trustedcomputinggroup.org/wp-content/uploads/TCG_RIM_Model_v1-r13_2feb20.pdf>
> The doc is completely based on ISO SWID, with the NIST guidelines.  There’s a CBOR variant called CoSWID at IETF (I think you can guess which Henk, out of the universe of all Henks, you could ask for details!)
>   But about identity of RIMs…
>   The RIM is signed, so once you’ve done the policy task of deciding which RIM supplier you like, verifying it is easy.  I realize of course that there’s little commonality on how to name a product or version, but I’m not sure that matters.  The RIM corresponds to a very specific product and release.  The vendor can call it whatever they want, as long as they don’t issue two release with the same name.  After that, I think it’s just a string compare.
>   I suppose if third-party RIM suppliers exist, then the RIM has to explicitly call out the software manufacturer by name, but that’s already part of the SWID & RIM specs.
>   As far as we can tell, SWID embodies sufficient flexibility to describe any software release that can be expressed as files and directories.  I have a small project on my todo list to prove that for a Juniper release, but so far, I don’t see a problem.  Again, if you’re interested, now is the time for review!
>  
>  
> [guy] Henk might have suggestion for potential commonality with EAT.  As noted, SWID is strongly oriented to software releases with packages, directories and files, but maybe there’s something useful there.
>  
> [guy] Yes, in fact I think there are at least three suppliers that could be verified; the TPM vendor, the hardware platform OEM who made the Attester, and the RIM supplier who certifies the software image.  Given the way RIV is scoped, I think verification of the TPM itself is up to the OEM, but verification of the OEM’s DevID and IAK is one thing, and verification of the authenticity of the RIM is another independent operation, both of which  belong in a RATS-compatible Verifier.
>   Let me know what we’re missing!
>   /guy
>  
> LL
>  
>  
>  
>  
> 
> On Apr 9, 2020, at 7:31 AM, Guy Fedorkow <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Laurence,

---

From: Guy Fedorkow <[email-masked]>
Date: Mon, 13 Apr 2020 19:18:49 +0000

Hi Laurence,
  I don't disagree about the complexity of the market space outside the router world, although the TCG RIM and ISO SWID are meant to work in more chaotic ecosystems, and I think that's reflected in the excerpt below.
  If you see something that you think would help bind the RIM and a product more reliably, I'm sure the TCG editors would want to hear about it.
  Thanks
/guy

Juniper Business Use Only
From: Laurence Lundblade <[email-masked]>
Sent: Monday, April 13, 2020 2:44 PM
To: Guy Fedorkow <[email-masked]>
Cc: [email-masked]; Ned Smith <[email-masked]>; Jessica Fitzgerald-McKay <[email-masked]>
Subject: Re: [Rats] Endorsement ID and verification key (was Processing Endorsements and Evidence into Results)

Seems like the router world is a small number of manufacturers, less than ten. Seems like routers are purchased and managed by very technically competent staff that already work with lots of technical details. It's not that hard for network admins to go to the router manufacturers web site and download a few RIMs and configure them into their verifiers.

Phones have their own challenge - they have huge numbers of relying parties - each app is a relying party.

It seems a URI-based scheme for finding RIMs is important for the IoT world, and maybe the phone world, but not so much for the router world. Seems like it has to be URI-based because that's the way to identify a resource on the broad internet.

It looks like the TCG RIM document<https://urldefense.com/v3/__https:/trustedcomputinggroup.org/wp-content/uploads/TCG_RIM_Model_v1-r13_2feb20.pdf__;!!NEt6yMaO-gk!SALZ6TaSQ78mNyy8DyIQoZwE5kuKwfbEpslSl3mgCsuvRd2cjADGaW2-xXgu3XRIGQ4$> already has something like this as mentioned in Appendix C. Not sure it is fully developed as it is in an appendix.

The TCG Platform Certificate Profile [10] also defines a PlatformConfigurationURI attribute that contains "URI where the reference integrity measurements could be obtained by the verifier". The Platform Certificates Platform Configuration URI MUST hold a reference to the location of the Primary RIM Bundle. The URI MAY point to a location on the Endpoint platform or it MAY reside in a publicly accessible location. The Base RIM MUST contain a LINK element that points to the same URI as the Platform Certificates PlatformConfigurationURI.

LL

On Apr 13, 2020, at 8:24 AM, Guy Fedorkow <[email-masked]<mailto:[email-masked]>> wrote:

Hi Laurence,

Juniper Business Use Only
From: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, April 12, 2020 2:56 PM
To: Guy Fedorkow <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Ned Smith <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] Endorsement ID and verification key (was Processing Endorsements and Evidence into Results)

    https://trustedcomputinggroup.org/wp-content/uploads/TCG_RIM_Model_v1-r13_2feb20.pdf<https://urldefense.com/v3/__https:/trustedcomputinggroup.org/wp-content/uploads/TCG_RIM_Model_v1-r13_2feb20.pdf__;!!NEt6yMaO-gk!SALZ6TaSQ78mNyy8DyIQoZwE5kuKwfbEpslSl3mgCsuvRd2cjADGaW2-xXgu3XRIGQ4$>

LL

Hi Laurence,

  Thanks
/guy

Endorsement

Policy, K-G-V, other

LL

Hi Laurence,

There's a few scenarios:

Thoughts?

cheers, thanks!

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 13 Apr 2020 20:11:59 +0000

It was stated or implied by someone earlier in this thread that managing Endorsements in an IoT ecosystem would be complicated. One potential simplifying approach observes that, at least in terms of SW/FW image integrity claims, the part that might be called a ‘reference manifest’ is already a subset of the SW update manifest (SUIT). That is, the identification of the image, an integrity digest of the image and a signature over possibly multiple digests is very close to what RATS arch defines as a reference manifest. The main difference is a SUIT manifest also contains the update image(s); which a RATS Verifier doesn’t need.

A reasonable SW update use case that includes attestation might pass the SUIT manifest minus the images as Endorsements to the Verifier who might (upon successful attestation) give Attestation Results to a Relying Party in charge of SW update who might proceed to install an update. The Relying Party might decide to share just the reference measurements for the newly installed SW with the Verifier for subsequent attestation verifications.

This approach allows the SW vendor the ability to create Endorsements using the same tool chain used to generate the SUIT manifest.

Since the IoT vendors are (presumably) already motivated to implement SUIT, they conceivably are not overly burdened by creating Endorsements for RATS use cases.

SUIT manifests can (at least in part) be CoSWID. I believe it is possible for CoSWID to include UCCS claims which implies it is possible to extend a SUIT manifest to include other claims besides code integrity claims. An IoT device OEM might be in a position to make both code integrity and other claims. That would be a natural extension to their release process that produces a SUIT manifest.

Regards,
-Ned

From: Guy Fedorkow <[email-masked]>
Date: Monday, April 13, 2020 at 12:18 PM
To: Laurence Lundblade <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Smith, Ned" <[email-masked]>, Jessica Fitzgerald-McKay <[email-masked]>
Subject: RE: [Rats] Endorsement ID and verification key (was Processing Endorsements and Evidence into Results)

Hi Laurence,
  I don’t disagree about the complexity of the market space outside the router world, although the TCG RIM and ISO SWID are meant to work in more chaotic ecosystems, and I think that’s reflected in the excerpt below.
  If you see something that you think would help bind the RIM and a product more reliably, I’m sure the TCG editors would want to hear about it.
  Thanks
/guy

LL

Hi Laurence,

LL

Hi Laurence,

  Thanks
/guy

Endorsement

Policy, K-G-V, other

LL

Hi Laurence,

There's a few scenarios:

Thoughts?

cheers, thanks!