Subject: [Teep] Class ID claim (and other HW identification)

From: Laurence Lundblade <[email-masked]>
Date: Mon, 3 Jan 2022 12:47:46 -0800

I talked to Dave which resulted in reorientation of my understanding of Class ID in TEEP.

Class ID basically identifies HW IP <https://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core> from a HW designer like Arm or Synopsis that is integrated into chips made by various HW OEMs like Qualcomm, Samsung and Apple. The term used frequently for this is “IP” (I know this well from my days working on HW at Qualcomm).

I’ve created a PR for HW Class <https://github.com/ietf-rats-wg/eat/pull/147>.

Since what is identified spans OEMs, this must be a globally unique identifier. We need to be explicit about that. 

I know of four ways to have a global identifier:
- Use OIDs
- Use DNS / URI
- Probabilistically using a big enough byte string
- A new registry, perhaps IANA (but we probably don’t want this)

The PR allows all but the last, but this could be reduced to just one or two of the above.

I don’t see this claim as essential for EAT, but I committed to working through this with TEEP. I’m fine with this PR going into a TEEP document rather than EAT.

On to the other HW identification in EAT… 

Right now it stands as:

- HW OEM ID, the manufacturer of the HW; globally unique by either IEEE registry, PEN or probabilistically
- HW Model number which distinguishes products by an OEM; this is unique for an OEM; (this is previously what I thought was wanted for class ID)
- HW Version; this is sortable
 
The text for these is merged in GitHub and I am happy with it. Manufacturer and model are very common and well understood. 

LL

---

From: Dave Thaler <[email-masked]>
Date: Mon, 3 Jan 2022 21:00:39 +0000

Laurence Lundblade wrote:
> Class ID basically identifies HW IP from a HW designer like Arm or Synopsis that is integrated into chips made by various HW OEMs like Qualcomm, Samsung and Apple. The term used frequently for this is "IP" (I know this well from my days working on HW at Qualcomm).
> 
> I've created a PR for HW Class.
>
> - A new registry, perhaps IANA (but we probably don't want this)
>

PR looks great to me, except that would I agree with reducing it to one or two.
Since the ability to take a value and resolve it to something meaningful is useful in many cases (logging, wireshark analysis, etc.), I would remove the third option.

OIDs, encoded as int arrays, probably compress the best so if only one, then I'd pick that one.  URIs are convenient though also so if two, then that's my second pick. 

> I don't see this claim as essential for EAT, but I committed to working through this with TEEP. I'm fine with this PR going into a TEEP document rather than EAT.

The notion of HW class ID is not specific to TEEs, hence the request to put it in EAT rather than in anything that would imply use is limited to TEEs (hence not in a TEEP document).

-Dave

---

From: Brendan Moran <[email-masked]>
Date: Tue, 4 Jan 2022 11:06:45 +0000

I think devices will need to report multiple vendor/class pairs.

For example, A mobile device could potentially contain:
1. A Mobile Device OEM Vendor ID
2. A Silicon vendor’s Vendor ID
3. An IP vendor’s Vendor ID

This is not an exhaustive list.

For Arm Trust Zone TEEs, I would expect to see:
1. The Arm Vendor ID + the processor core’s Class ID
2. The Trusted OS Vendor ID + the Trusted OS Class ID
3. The Silicon vendor’s Vendor ID + the processor Class ID
4. The Device OEM’s Vendor ID + the device Class ID

Cheers,
Brendan

On 3 Jan 2022, at 21:00, Dave Thaler <dthaler=[email-masked]<mailto:dthaler=[email-masked]>> wrote:

-Dave

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

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: Henk Birkholz <[email-masked]>
Date: Tue, 4 Jan 2022 15:40:39 +0100

Hi all,

while I understand the appeal of a nice and simple scopes solution, the 
truth is it often far more complex than two separate Claim types.

I think Brendan highlighted something very important here: "multiple 
vendor/class pairs". This seems to be the direction where others 
solutions area also moving towards to, I think :-)

Viele Grü0e,

Henk

On 04.01.22 12:06, Brendan Moran wrote:
>> On 3 Jan 2022, at 21:00, Dave Thaler 
>> <dthaler=[email-masked] 
>> <mailto:dthaler=[email-masked]>> wrote:
>>
>>> Class ID basically identifies HW IP from a HW designer like Arm or 
>>> Synopsis that is integrated into chips made by various HW OEMs like 
>>> Qualcomm, Samsung and Apple. The term used frequently for this is 
>>> "IP" (I know this well from my days working on HW at Qualcomm).
>>>
>>> Since what is identified spans OEMs, this must be a globally unique 
>>> identifier. We need to be explicit about that.
>>>
>> Since the ability to take a value and resolve it to something 
>> meaningful is useful in many cases (logging, wireshark analysis, 
>> etc.), I would remove the third option.
>>
>> OIDs, encoded as int arrays, probably compress the best so if only 
>> one, then I'd pick that one.  URIs are convenient though also so if 
>> two, then that's my second pick.
>>
>>> I don't see this claim as essential for EAT, but I committed to 
>>> working through this with TEEP. I'm fine with this PR going into a 
>>> TEEP document rather than EAT.
>>
>> The notion of HW class ID is not specific to TEEs, hence the request 
>> to put it in EAT rather than in anything that would imply use is 
>> limited to TEEs (hence not in a TEEP document).
>>
>> -Dave
>>
>> [email-masked] <mailto:[email-masked]>
>> <https://www.ietf.org/mailman/listinfo/teep>
> 
> 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.
> 
> [email-masked]

---

From: Dave Thaler <[email-masked]>
Date: Tue, 4 Jan 2022 19:05:26 +0000

When Laurence and I chatted, I was unsure that we needed a class ID claim for software ("The Trusted OS Vendor ID + the Trusted OS Class ID" in Brendan's email) other than what a CoSWID already provides.

If anyone thinks a CoSWID is not sufficient for software cases, please speak up.

Dave

-----Original Message-----
From: TEEP <[email-masked]> On Behalf Of Henk Birkholz
Sent: Tuesday, January 4, 2022 6:41 AM
To: Brendan Moran <[email-masked]>; Dave Thaler <dthaler=[email-masked]>
Cc: rats <[email-masked]>; teep <[email-masked]>; Laurence Lundblade <[email-masked]>
Subject: Re: [Teep] [Rats] Class ID claim (and other HW identification)

Hi all,

while I understand the appeal of a nice and simple scopes solution, the truth is it often far more complex than two separate Claim types.

I think Brendan highlighted something very important here: "multiple vendor/class pairs". This seems to be the direction where others solutions area also moving towards to, I think :-)

Viele Grü0e,

Henk

On 04.01.22 12:06, Brendan Moran wrote:
> 2. A Silicon vendor's Vendor ID
> 3. An IP vendor's Vendor ID
> 
> 1. The Arm Vendor ID + the processor core's Class ID 2. The Trusted OS 
> Vendor ID + the Trusted OS Class ID 3. The Silicon vendor's Vendor ID 
> + the processor Class ID 4. The Device OEM's Vendor ID + the device 
> Class ID
> 
> Cheers,
> Brendan
> 
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>> .ietf.org%2Fmailman%2Flistinfo%2Fteep&amp;data=04%7C01%7Cdthaler%40mi
>> crosoft.com%7Cc48b2ec9ba054b78066a08d9cf903c6d%7C72f988bf86f141af91ab
>> 2d7cd011db47%7C1%7C0%7C637769041163250085%7CUnknown%7CTWFpbGZsb3d8eyJ
>> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C200
>> 0&amp;sdata=EzozAFvWlhouvLI%2B1BVqneNi%2Bt7QYDpauVizouSOu3A%3D&amp;re
>> served=0 
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
>> w.ietf.org%2Fmailman%2Flistinfo%2Fteep&amp;data=04%7C01%7Cdthaler%40m
>> icrosoft.com%7Cc48b2ec9ba054b78066a08d9cf903c6d%7C72f988bf86f141af91a
>> b2d7cd011db47%7C1%7C0%7C637769041163250085%7CUnknown%7CTWFpbGZsb3d8ey
>> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C20
>> 00&amp;sdata=EzozAFvWlhouvLI%2B1BVqneNi%2Bt7QYDpauVizouSOu3A%3D&amp;r
>> eserved=0>
> 
> 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.
> 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fteep&amp;data=04%7C01%7Cdthaler%40micr
> osoft.com%7Cc48b2ec9ba054b78066a08d9cf903c6d%7C72f988bf86f141af91ab2d7
> cd011db47%7C1%7C0%7C637769041163250085%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp
> ;sdata=EzozAFvWlhouvLI%2B1BVqneNi%2Bt7QYDpauVizouSOu3A%3D&amp;reserved
> =0
> 

_______________________________________________
TEEP mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&amp;data=04%7C01%7Cdthaler%40microsoft.com%7Cc48b2ec9ba054b78066a08d9cf903c6d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637769041163250085%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=EzozAFvWlhouvLI%2B1BVqneNi%2Bt7QYDpauVizouSOu3A%3D&amp;reserved=0

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 7 Jan 2022 15:56:21 -0800

So rather than a HW Class, how about a HW IP claim? It would reuse the same triple for identifying HW, OEM, Model, Version. It could occur along side the HW OEM, model and version. This seems better than my current PR and lines up better with Brendan’s examples and with the reality that HW IP comes from a vendor, has models and versions. I’ll write up a PR for it if I receive some positive feedback here.

The distinction between chip and device is intended to be handled by submodules in EAT. Submodules can express arbitrarily complex architectures and device compositions.

I think it’s cleaner to keep the HW-identifying claims separate from the SW-identify claims. Would really like the identification of the Trusted OS Vendor be handled by CoSWID and friends. Trying to make some claim suitable for identifying both SW and HW for all of attestation seems over-ambitious.

I also think it’s fine to define some claims better suited to the TEE world in TEEP if we can’t find enough common ground between TEEP and the very broadly applicable stuff that goes into EAT.

LL

Note: I find the use of the word “class” here confusing. If I were putting TV’s into classes I’d uses classes like smart/dumb, display type (LCD, CRT, OLED) and such that identify characteristics of TVs independent of vendor and model. "Sony Bravia" is not a class IMO. Nor is “Microsoft Windows” (an OS the runs on lots of HW platforms). I’d like to move away from the word.

> On Jan 4, 2022, at 3:06 AM, Brendan Moran <[email-masked]> wrote:
> 
>> On 3 Jan 2022, at 21:00, Dave Thaler <dthaler=[email-masked] <mailto:dthaler=[email-masked]>> wrote:
>> 
>> https://www.ietf.org/mailman/listinfo/teep <https://www.ietf.org/mailman/listinfo/teep>

---

From: Dave Thaler <[email-masked]>
Date: Sat, 8 Jan 2022 00:07:17 +0000

"IP" (as in Intellectual Property, not Internet Protocol) is not the right term in my view since that implies there actually is some IP as opposed to (say) conformance to a standard.  I am fine with "Class" as you had it in the PR, but I think "IP" is too narrow in implication.

Dave

From: TEEP <[email-masked]> On Behalf Of Laurence Lundblade
Sent: Friday, January 7, 2022 3:56 PM
To: Brendan Moran <[email-masked]>
Cc: Dave Thaler <dthaler=[email-masked]>; teep <[email-masked]>; rats <[email-masked]>
Subject: Re: [Teep] [Rats] Class ID claim (and other HW identification)

So rather than a HW Class, how about a HW IP claim? It would reuse the same triple for identifying HW, OEM, Model, Version. It could occur along side the HW OEM, model and version. This seems better than my current PR and lines up better with Brendan's examples and with the reality that HW IP comes from a vendor, has models and versions. I'll write up a PR for it if I receive some positive feedback here.

I think it's cleaner to keep the HW-identifying claims separate from the SW-identify claims. Would really like the identification of the Trusted OS Vendor be handled by CoSWID and friends. Trying to make some claim suitable for identifying both SW and HW for all of attestation seems over-ambitious.

I also think it's fine to define some claims better suited to the TEE world in TEEP if we can't find enough common ground between TEEP and the very broadly applicable stuff that goes into EAT.

LL

Note: I find the use of the word "class" here confusing. If I were putting TV's into classes I'd uses classes like smart/dumb, display type (LCD, CRT, OLED) and such that identify characteristics of TVs independent of vendor and model. "Sony Bravia" is not a class IMO. Nor is "Microsoft Windows" (an OS the runs on lots of HW platforms). I'd like to move away from the word.

On Jan 4, 2022, at 3:06 AM, Brendan Moran <[email-masked]<mailto:[email-masked]>> wrote:

For Arm Trust Zone TEEs, I would expect to see:
1. The Arm Vendor ID + the processor core's Class ID
2. The Trusted OS Vendor ID + the Trusted OS Class ID
3. The Silicon vendor's Vendor ID + the processor Class ID
4. The Device OEM's Vendor ID + the device Class ID

Cheers,
Brendan

-Dave

_______________________________________________
TEEP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teep<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&data=04%7C01%7Cdthaler%40microsoft.com%7Cef652de70c044c9ff23408d9d2395570%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637771966678289215%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ekkSra9yeVxu5Pcs2WrVPPSs62LGatVTxkqDcptp5PQ%3D&reserved=0>

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 8 Jan 2022 11:41:39 -0800

Yeah, I was confused by the use of “IP" when I first heard it after joining the HW team at Qualcomm, but it is the phrase that is used by the HW industry:

https://www.synopsys.com/designware-ip.html
https://www.arm.com/products/silicon-ip-security
https://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core
https://www.imaginationtech.com/products/

“IP” is even in the URL’s.

How about one of these?
   “Silicon IP ID”
   “HW Design IP ID”
   “Semiconductor IP ID"

We can add a sentence or two that gives some context for people that haven’t run into this.

More important than the name, I’d like to make the claim:
   a map or array that
      must contain an OEM ID of the vendor of the IP
      may contain a model indicator
      may contain a version

I think this lines up with what Brendon suggests is needed and makes more sense to me because it describes the very common convention of identifying physically built things (cars, chips, refrigerators...).

LL

> On Jan 7, 2022, at 4:07 PM, Dave Thaler <[email-masked]> wrote:
> 
> “IP” (as in Intellectual Property, not Internet Protocol) is not the right term in my view since that implies there actually is some IP as opposed to (say) conformance to a standard.  I am fine with “Class” as you had it in the PR, but I think “IP” is too narrow in implication.
>  
> Dave
>  
> On Jan 4, 2022, at 3:06 AM, Brendan Moran <[email-masked] <mailto:[email-masked]>> wrote:
>  
> https://www.ietf.org/mailman/listinfo/teep <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&data=04%7C01%7Cdthaler%40microsoft.com%7Cef652de70c044c9ff23408d9d2395570%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637771966678289215%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ekkSra9yeVxu5Pcs2WrVPPSs62LGatVTxkqDcptp5PQ%3D&reserved=0>
>

---

From: Giridhar Mandyam <[email-masked]>
Date: Sat, 8 Jan 2022 20:15:51 +0000

During the RATS meeting in IETF 112, the EAT editors were assured that the TEEP WG had reached a consensus that if this claim is defined as opaque data (https://github.com/ietf-rats-wg/eat/pull/139) then the TEEP requirement would be met.

Based on the discussion below, the TEEP WG has clearly not arrived at consensus as to what a HW class claim is supposed to be.  Rather than to keep trying to iterate on an EAT PR that may or may not represent TEEP consensus, I would suggest the TEEP WG continue the discussion on this topic and present a formal proposal to the RATS WG.  When I say “TEEP WG”, I mean that the proposal should be provided by one or more individuals who can credibly claim to speak for the WG, such as the Working Group chairs.

-Giri Mandyam, co-editor of EAT

From: RATS <[email-masked]> On Behalf Of Laurence Lundblade
Sent: Saturday, January 8, 2022 11:42 AM
To: Dave Thaler <[email-masked]>
Cc: Dave Thaler <dthaler=[email-masked]>; teep <[email-masked]>; Brendan Moran <[email-masked]>; rats <[email-masked]>
Subject: Re: [Rats] [Teep] Class ID claim (and other HW identification)

How about one of these?
   “Silicon IP ID”
   “HW Design IP ID”
   “Semiconductor IP ID"

LL

On Jan 7, 2022, at 4:07 PM, Dave Thaler <[email-masked]<mailto:[email-masked]>> wrote:

Dave

From: TEEP <[email-masked]<mailto:[email-masked]>> On Behalf Of Laurence Lundblade
Sent: Friday, January 7, 2022 3:56 PM
To: Brendan Moran <[email-masked]<mailto:[email-masked]>>
Cc: Dave Thaler <dthaler=[email-masked]<mailto:dthaler=[email-masked]>>; teep <[email-masked]<mailto:[email-masked]>>; rats <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teep] [Rats] Class ID claim (and other HW identification)

LL

Cheers,
Brendan

-Dave

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 8 Jan 2022 22:28:28 +0100

> “IP” (as in Intellectual Property, not Internet Protocol) is not the right term in my view since that implies there actually is some IP as opposed to (say) conformance to a standard.  I am fine wit…

+1 about not wanting “IP” as in productized silicon design library.  The scope of the assertion you can make based on having licensed such a package is not well-defined; I don’t know what a TEEP party could do with such an identifier.

As Brendan notes, a device may need to be in (subject of claims about) multiple “classes”.  The term “class” can then be confusing to people who think about “the class” of an item.

Maybe it’s not productive to try to group these kinds of identifiers into “classes”, “IP”, … — maybe you just need an assertion about the device and an identifier.  Just using an opaque byte string here is not very efficient, as these need to be long and random to be distinct (and you can’t look them up, as Dave noted).

On an unrelated point, if you *really* want to do something with ASN.1 OIDs, there is also RFC 9090 (I’m just the messenger here, this is not really “my” RFC…).
I’d rather do a new registry, though...

Grüße, Carsten

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 8 Jan 2022 14:15:37 -0800

> On Jan 8, 2022, at 1:28 PM, Carsten Bormann <[email-masked]> wrote:
> 

The industry doesn’t use “IP” here to mean there are actual patents filed or that it is even a product. It means “a generic silicon design”. Maybe think of it as “function” in SW. Seems that HW people started using the term this way because there were often actual patents, but then it got applied generically.  People use words in weird ways sometimes. Just happens. 

This is definitely not about anything legal, financial or ownership. I agree legal status is not useful criteria in an attestation claim.

The important question is whether a claim to identify generic silicon designs is useful, what it looks like and how it actually gets used (by TEEP).

LL

---

From: Henk Birkholz <[email-masked]>
Date: Sat, 8 Jan 2022 23:23:09 +0100

Hi Giri,

TL;DR Are we waiting for this? How log will it take?

so, is this a blocker to the EAT core document then? Could we split that 
topic out? If we are starting with a (hardware system component 
characteristics taxonomy here - while actually worthwhile and useful to 
attempt - that will take a while. Even, if the target would be simpler, 
agreeing on the target will again take time and I think that most agree 
that a line most be drawn at which point (sorry...) claims go to other 
documents.

Viele Grüße,

Henk

On 08.01.22 21:15, Giridhar Mandyam wrote:
> During the RATS meeting in IETF 112, the EAT editors were assured that 
> the TEEP WG had reached a consensus that if this claim is defined as 
> opaque data (https://github.com/ietf-rats-wg/eat/pull/139 
> <https://github.com/ietf-rats-wg/eat/pull/139>) then the TEEP 
> requirement would be met.
> 
> Based on the discussion below, the TEEP WG has clearly not arrived at 
> consensus as to what a HW class claim is supposed to be.  Rather than to 
> keep trying to iterate on an EAT PR that may or may not represent TEEP 
> consensus, I would suggest the TEEP WG continue the discussion on this 
> topic and present a formal proposal to the RATS WG.  When I say “TEEP 
> WG”, I mean that the proposal should be provided by one or more 
> individuals who can credibly claim to speak for the WG, such as the 
> Working Group chairs.
> 
> *From:* RATS <[email-masked]> *On Behalf Of * Laurence Lundblade
> *Sent:* Saturday, January 8, 2022 11:42 AM
> *To:* Dave Thaler <[email-masked]>
> *Cc:* Dave Thaler <dthaler=[email-masked]>; teep 
> <[email-masked]>; Brendan Moran <[email-masked]>; rats <[email-masked]>
> *Subject:* Re: [Rats] [Teep] Class ID claim (and other HW identification)
> 
> Yeah, I was confused by the use of “IP" when I first heard it after 
> joining the HW team at Qualcomm, but it is the phrase that is used by 
> the HW industry:
> 
>     <https://www.synopsys.com/designware-ip.html>
> 
>     <https://www.arm.com/products/silicon-ip-security>
> 
>     <https://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core>
> 
>     <https://www.imaginationtech.com/products/>
> 
> I think this lines up with what Brendon suggests is needed and makes 
> more sense to me because it describes the very common convention of 
> identifying physically built things (cars, chips, refrigerators...).
> 
> LL
> 
> 
> 
>     “IP” (as in Intellectual Property, not Internet Protocol) is not the
>     right term in my view since that implies there actually is some IP
>     as opposed to (say) conformance to a standard.  I am fine with
>     “Class” as you had it in the PR, but I think “IP” is too narrow in
>     implication.
> 
>     Dave
> 
>     *From:*TEEP <[email-masked]
>     <mailto:[email-masked]>>*On Behalf Of*Laurence Lundblade
>     *Sent:*Friday, January 7, 2022 3:56 PM
>     *To:*Brendan Moran <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:*Dave Thaler <dthaler=[email-masked]
>     <mailto:dthaler=[email-masked]>>; teep
>     <[email-masked] <mailto:[email-masked]>>; rats <[email-masked]
>     <mailto:[email-masked]>>
>     *Subject:*Re: [Teep] [Rats] Class ID claim (and other HW identification)
> 
>     So rather than a HW Class, how about a HW IP claim? It would reuse
>     the same triple for identifying HW, OEM, Model, Version. It could
>     occur along side the HW OEM, model and version. This seems better
>     than my current PR and lines up better with Brendan’s examples and
>     with the reality that HW IP comes from a vendor, has models and
>     versions. I’ll write up a PR for it if I receive some positive
>     feedback here.
> 
>     The distinction between chip and device is intended to be handled by
>     submodules in EAT. Submodules can express arbitrarily complex
>     architectures and device compositions.
> 
>     I think it’s cleaner to keep the HW-identifying claims separate from
>     the SW-identify claims. Would really like the identification of the
>     Trusted OS Vendor be handled by CoSWID and friends. Trying to make
>     some claim suitable for identifying both SW and HW for all of
>     attestation seems over-ambitious.
> 
>     I also think it’s fine to define some claims better suited to the
>     TEE world in TEEP if we can’t find enough common ground between TEEP
>     and the very broadly applicable stuff that goes into EAT.
> 
>     LL
> 
>     Note: I find the use of the word “class” here confusing. If I were
>     putting TV’s into classes I’d uses classes like smart/dumb, display
>     type (LCD, CRT, OLED) and such that identify characteristics of TVs
>     independent of vendor and model. "Sony Bravia" is not a class IMO.
>     Nor is “Microsoft Windows” (an OS the runs on lots of HW platforms).
>     I’d like to move away from the word.
> 
> 
> 
> 
>                 Class ID basically identifies HW IP from a HW designer
>                 like Arm or Synopsis that is integrated into chips made
>                 by various HW OEMs like Qualcomm, Samsung and Apple. The
>                 term used frequently for this is "IP" (I know this well
>                 from my days working on HW at Qualcomm).
> 
>                 Since what is identified spans OEMs, this must be a
>                 globally unique identifier. We need to be explicit about
>                 that.
> 
>             Since the ability to take a value and resolve it to
>             something meaningful is useful in many cases (logging,
>             wireshark analysis, etc.), I would remove the third option.
> 
>             OIDs, encoded as int arrays, probably compress the best so
>             if only one, then I'd pick that one.  URIs are convenient
>             though also so if two, then that's my second pick.
> 
> 
> 
>                 I don't see this claim as essential for EAT, but I
>                 committed to working through this with TEEP. I'm fine
>                 with this PR going into a TEEP document rather than EAT.
> 
> 
>             The notion of HW class ID is not specific to TEEs, hence the
>             request to put it in EAT rather than in anything that would
>             imply use is limited to TEEs (hence not in a TEEP document).
> 
>             -Dave
> 
>             <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&data=04%7C01%7Cdthaler%40microsoft.com%7Cef652de70c044c9ff23408d9d2395570%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637771966678289215%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ekkSra9yeVxu5Pcs2WrVPPSs62LGatVTxkqDcptp5PQ%3D&reserved=0>
> 
>         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]
> https://www.ietf.org/mailman/listinfo/rats
>

---

From: Henk Birkholz <[email-masked]>
Date: Sat, 8 Jan 2022 23:27:00 +0100

I am not really happy with both the ambiguity of "IP" in our context, 
nor with the semantics of the intended concept.

If we are going towards taxonomy of characteristics here, a registry 
would be helpful, I think.

Viele Grüße,

Henk

---

From: Giridhar Mandyam <[email-masked]>
Date: Sun, 9 Jan 2022 20:07:28 +0000

> so, is this a blocker to the EAT core document then? Could we split that topic out?

We certainly have the option not to make it a blocker for EAT and take it out of scope for the EAT document.  I think that is the best approach given the current lack of consensus on what this claim is supposed to be.

> Even, if the target would be simpler, agreeing on the target will again take time and I think that most agree that a line most be drawn at which point (sorry...) claims go to other documents.

I don't understand the purpose of the HW class claim or how it provides any additional security assurances for a relying party.  I just assumed that the TEEP WG had already discussed this and come up with one or more valid use cases for this claim.  This does not appear to be the case.  Maybe the discussion should be up-leveled to get a better understanding of the goal(s) before starting a discussion on claim semantics.  

For instance, if the HW subsystem in question is self-attestable then it can already make use of the existing CWT issuer claim (https://datatracker.ietf.org/doc/html/rfc8392#section-3.1.1) - which is also a perfectly valid claim to include in an EAT.  If the HW subsystem issues an EAT where the iss field identified the make/model/version of the HW then would that be sufficient for the targeted use case?  If not, what is required in addition and would the proposed new claim provide additional information to a relying party about the security assurance offered by the HW subsystem?

-Giri

-----Original Message-----
From: Henk Birkholz <[email-masked]> 
Sent: Saturday, January 8, 2022 2:23 PM
To: Giridhar Mandyam <[email-masked]>; Laurence Lundblade <[email-masked]>; Dave Thaler <[email-masked]>
Cc: Dave Thaler <dthaler=[email-masked]>; teep <[email-masked]>; Brendan Moran <[email-masked]>; rats <[email-masked]>
Subject: Re: [Rats] [Teep] Class ID claim (and other HW identification)

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Giri,

so, is this a blocker to the EAT core document then? Could we split that topic out? If we are starting with a (hardware system component characteristics taxonomy here - while actually worthwhile and useful to attempt - that will take a while. Even, if the target would be simpler, agreeing on the target will again take time and I think that most agree that a line most be drawn at which point (sorry...) claims go to other documents.

Viele Grüße,

Henk

On 08.01.22 21:15, Giridhar Mandyam wrote:
> consensus as to what a HW class claim is supposed to be.  Rather than 
> to keep trying to iterate on an EAT PR that may or may not represent 
> TEEP consensus, I would suggest the TEEP WG continue the discussion on 
> this topic and present a formal proposal to the RATS WG.  When I say 
> “TEEP WG”, I mean that the proposal should be provided by one or more 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Fteep&data=04%7C01%7Cdthaler%40microso
> ft.com%7Cef652de70c044c9ff23408d9d2395570%7C72f988bf86f141af91ab2d7cd0
> 11db47%7C1%7C0%7C637771966678289215%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=
> ekkSra9yeVxu5Pcs2WrVPPSs62LGatVTxkqDcptp5PQ%3D&reserved=0>
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Jan 2022 10:05:54 -0500

> that a line most be drawn at which point (sorry...) claims go to other 

Removing many of the claims from the EAT document, and re-structuring 
the document was the main point of my review back in November.

I think that it's okay if we wind up with a dozen three page documents 
that progress through XYZ WG (with review from RATS) that define claims. 
The DHC WG DHCP option model is the one that we want to emulate.

With a good crystal ball, we should be able to know when we should 
collect a bunch of related claims into a single document, and when we 
should split them out into smaller documents because it is easier to 
cite "RFCXXXX" rather than "RFCYYYY section 4".

Of course, lacking such a perfectly predictive palantir, we'll make 
mistakes, but that's okay.  That's why we have Proposed Standards and 
Internet Standards as two steps.

So, could we please remove this Claim from EAT, and put it into an 
appropriate TEEP document?

---

From: Brendan Moran <[email-masked]>
Date: Mon, 10 Jan 2022 21:12:31 +0000

IMO, adding a new claim like this is counterproductive. It presupposes that we can predict all classes that a device may belong to. Sure, we can make a registry of different kinds of classes that a device can belong to, but why? Frankly, the naive approach is better than this: you have a database that maps OEM + model + revision into an application-specific taxonomy. Of course, now someone has to actually maintain that database. Have fun.

Why not take the easy route? It’s far simpler for a device to be the intersection of ANY properties that make it distinct. The entity consuming an EAT needs those anyway. And as to why I don’t want a taxonomy? Because it’s unnecessary. To use any of these identifiers, you have to use a database to convert the identifier into whatever it is that you actually care about. That database can just as easily contain any taxonomy you like.

We’re talking about adding more complexity to a specification in order to distinguish between:

SELECT * FROM hw_ip_identifiers WHERE id=${ID}
Vs
SELECT * FROM hw_identifiers WHERE id=${ID} AND taxonomy=“hwip"

Why would we complicate the spec to add taxonomies in order to simplify a database in such a trivial way?

In my opinion, we should look at a single physical device as the intersection of several sets:
* the OEM’s model identifier (incl. HW revision)
* the SoC identifier (incl. SoC revision)
* the processor’s type/version/revision
* the trusted OS’s version/revision
* the boot loader (especially if it’s in ROM) version/revision.

All of these matter (I think) to TEEP. We need to report them all. But is the list exhaustive? Probably not. While a registry for the different taxonomies may be relevant, I doubt it matters in EAT itself. That only matters when looking up an identifier.

What is the concrete value of specifying the taxonomy of an opaque blob in an interchange document?

Thanks,
Brendan

On 7 Jan 2022, at 23:56, Laurence Lundblade <[email-masked]<mailto:[email-masked]>> wrote:

LL

Cheers,
Brendan

-Dave

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 10 Jan 2022 23:17:51 +0100

On 2022-01-10, at 22:12, Brendan Moran <[email-masked]> wrote:
> 
> And as to why I don’t want a taxonomy? Because it’s unnecessary.

This.

(Maybe slightly worse, actually, because it might be used by an attacker to pretend that there is some semantics where there isn’t or it isn’t well-defined.)

Grüße, Carsten

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 10 Jan 2022 20:33:18 -0800

Hey Brendan,

I made the HW-IP PR as an educated guess, from talking to Dave, and from a some text in section 7 of TEEP Architecture. I don’t have any agenda here but to make EAT work well for SUIT and TEEP.

Obviously, I’m missing the mark, so I’m graciously bowing out. So no class ID in the EAT draft.

LL

P.S. I do appreciate the discussion as is resulted in adding the HW Model ID claim to EAT, something that was missing.

> On Jan 10, 2022, at 1:12 PM, Brendan Moran <[email-masked]> wrote:
> 
>> On 7 Jan 2022, at 23:56, Laurence Lundblade <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Brendan Moran <[email-masked]>
Date: Tue, 11 Jan 2022 09:12:47 +0000

Hi Lawrence,

I don’t think I was clear. I was saying that class IDs are important, but that there’s no need to differentiate between /types of classes/. When class IDs are opaque blobs, a lookup of some sort is implied. Since a lookup is being done, the /type of class/ should be extracted in the lookup. There’s no need to differentiate between types of classes in EAT itself since it’s for transporting information that will later have a lookup done.

Best Regards,
Brendan

On 11 Jan 2022, at 04:33, Laurence Lundblade <[email-masked]<mailto:[email-masked]>> wrote:

Hey Brendan,

LL

On Jan 10, 2022, at 1:12 PM, Brendan Moran <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Brendan

LL

Cheers,
Brendan

-Dave

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 12 Jan 2022 10:41:05 -0800

I can’t seem to be able to understand what is to be classified or typed or how and why this claim would be used by the RP or Verifier, so I’m not the one to write the definition of this claim. I’ve made several attempts that didn’t work out. Maybe if I understood TEEP better, but at this point I need to spend time on getting EAT through last call.

You can put a claim in the TEEP document and have it be used by lots of others. Doesn’t have to be in the EAT document to be of general use.

LL

> On Jan 11, 2022, at 1:12 AM, Brendan Moran <[email-masked]> wrote:
> 
> Hi Lawrence,
> 
>> On 11 Jan 2022, at 04:33, Laurence Lundblade <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hey Brendan,
>> 
>>> On Jan 10, 2022, at 1:12 PM, Brendan Moran <[email-masked] <mailto:[email-masked]>> wrote:
>>>