Subject: Re: [Rats] EAT claims needed by TEEP

From: Dave Thaler <[email-masked]>
Date: Mon, 8 Nov 2021 17:20:33 +0000

Following up on the RATS meeting today, I compared the latest EAT document
against the TEEP requirements discussed most recently at the IETF 111 RATS meeting.

There were 5 requirements from TEEP for claims, ideally general use ones not profile specific ones.
My reading is that the latest EAT doc now meets 4 of the 5 and only "device class" is missing,
and indeed the EAT document discussion of ueid explicitly says
"It does not identify types, models or classes of devices."
but nothing else in the document I could find provides a way to identify such.

Henk's proposal there was section 3.1.2 of draft-birkholz-rats-suit-claims:

> 3.1.2.  class-identifier
>
>   A RFC 4122 UUID representing the class of the Attester or one of its
>   hardware and/or software components.
>
>   $$system-property-claim //= ( class-identifier => RFC4122_UUID )

The other four requirements from TEEP can be met as follows, if I understand
the intent correctly:

  1.  Device unique identifier -> use ueid claim
  2.  Vendor of the device -> use oemid
  3.  Firmware type -> use sw-name
  4.  Firmware version -> use sw-version

The above claims would go in a claimset about the TEE (which may or may not be
a separate processor), but EAT already supports different claimsets for different
components as I understand it, so that's fine.

https://github.com/ietf-rats-wg/eat/issues/138 tracks this issue and my belief
is it should be simple to add a device class claim into a draft -12 of EAT.

I will also cover this in the TEEP WG meeting on Friday where I will discuss
what we need to change in the TEEP protocol spec, where this is tracked by
https://github.com/ietf-teep/teep-protocol/issues/165

Dave

From: Thomas Fossati <[email-masked]>
Sent: Thursday, October 29, 2020 2:21 PM
To: Laurence Lundblade <[email-masked]>
Cc: [email-masked]; teep <[email-masked]>; Dave Thaler <[email-masked]>; Simon Frost <[email-masked]>; Thomas Fossati <[email-masked]>
Subject: Re: [Rats] EAT claims needed by TEEP

On 29/10/2020, 21:07, "RATS" <[email-masked]<mailto:[email-masked]>> wrote:
> On Oct 29, 2020, at 1:45 PM, Thomas Fossati <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi Laurence,
>
> > My understanding is that they are always encoded as CBOR text strings,
> > so floating-point doesn't mean #7.25 or such.
>
> Correct.  In (Co)SWID software-version is just a text string and version-scheme
> is there to do some semantic polishing.  But the underlying type is always #3.
>
> Maybe I'm misunderstanding your proposal here, but I would be circumspect
> in mixing SWIDs attributes, which are scoped to software artifacts, with HW
> identifiers.
>
>
> Hi Thomas,
>
> All the SW Version stuff would fall under a single EAT claims that
> contains a full CoSWID.
>
> For HW Version, I was thinking of two EAT claims, one for the version
> text, another for the version scheme (or we could go off and define a
> full CoHWID).

OK, looks like I had misunderstood your plan :-) thanks for the
clarification!
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: Mon, 8 Nov 2021 13:20:20 -0800

This PR <https://github.com/ietf-rats-wg/eat/pull/139> now exists to address class.

I was never quite sure what it was and it seemed TEEP/SUITE specific to me, one of the reasons I didn’t do anything about it for the -11 draft. See if what I’ve got in the PR makes sense.

LL

> On Nov 8, 2021, at 9:20 AM, Dave Thaler <[email-masked]> wrote:
> 
> My reading is that the latest EAT doc now meets 4 of the 5 and only “device class” is missing,
> “It does not identify types, models or classes of devices.”
> Henk’s proposal there was section 3.1.2 of draft-birkholz-rats-suit-claims:
>  
> > 3.1.2.  class-identifier
> > 
> Device unique identifier -> use ueid claim
> Vendor of the device -> use oemid
> Firmware type -> use sw-name
> Firmware version -> use sw-version
>  
> components as I understand it, so that’s fine.
>  
> https://github.com/ietf-rats-wg/eat/issues/138 <https://github.com/ietf-rats-wg/eat/issues/138> tracks this issue and my belief
> https://github.com/ietf-teep/teep-protocol/issues/165 <https://github.com/ietf-teep/teep-protocol/issues/165>
>  
> Dave
>  
> On 29/10/2020, 21:07, "RATS" <[email-masked] <mailto:[email-masked]>> wrote:
> > On Oct 29, 2020, at 1:45 PM, Thomas Fossati <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > Hi Laurence,
> > 
> > > so floating-point doesn’t mean #7.25 or such.
> >

---

From: Dave Thaler <[email-masked]>
Date: Mon, 8 Nov 2021 22:25:08 +0000

Yes I agree that PR would be sufficient to close the issue I raised.
Thanks Laurence for opening the PR, and I hope others will review so this
could get merged before the Friday meeting if there are no objections.

Dave

From: Laurence Lundblade <[email-masked]>
Sent: Monday, November 8, 2021 1:20 PM
To: Dave Thaler <[email-masked]>
Cc: Giridhar Mandyam <[email-masked]>; [email-masked]; teep <[email-masked]>
Subject: Re: [Rats] EAT claims needed by TEEP

This PR<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats-wg%2Feat%2Fpull%2F139&data=04%7C01%7Cdthaler%40microsoft.com%7Ccd1bfedf9bf24e41e68208d9a2fd94a6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637720032296857318%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=33oCO7YuLj53p%2BgsjN%2FAINMAnc7Yec1oKj5%2F2WR4fYg%3D&reserved=0> now exists to address class.

I was never quite sure what it was and it seemed TEEP/SUITE specific to me, one of the reasons I didn't do anything about it for the -11 draft. See if what I've got in the PR makes sense.

LL

On Nov 8, 2021, at 9:20 AM, Dave Thaler <[email-masked]<mailto:[email-masked]>> wrote:

https://github.com/ietf-rats-wg/eat/issues/138<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats-wg%2Feat%2Fissues%2F138&data=04%7C01%7Cdthaler%40microsoft.com%7Ccd1bfedf9bf24e41e68208d9a2fd94a6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637720032296857318%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1yQ6r3uJM0T%2B9MvBxu901cHuyZZBNxRpY%2BLZSLd8nfI%3D&reserved=0> tracks this issue and my belief
is it should be simple to add a device class claim into a draft -12 of EAT.

I will also cover this in the TEEP WG meeting on Friday where I will discuss
what we need to change in the TEEP protocol spec, where this is tracked by
https://github.com/ietf-teep/teep-protocol/issues/165<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Fteep-protocol%2Fissues%2F165&data=04%7C01%7Cdthaler%40microsoft.com%7Ccd1bfedf9bf24e41e68208d9a2fd94a6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637720032296867281%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xYQeyXBbyZ3FORI8I5ISSeMVQ0F4ZJ7aNS1nDfZxOOE%3D&reserved=0>

Dave

From: Thomas Fossati <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, October 29, 2020 2:21 PM
To: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; teep <[email-masked]<mailto:[email-masked]>>; Dave Thaler <[email-masked]<mailto:[email-masked]>>; Simon Frost <[email-masked]<mailto:[email-masked]>>; Thomas Fossati <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] EAT claims needed by TEEP

---

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Nov 2021 08:39:53 -0500

I'm reviewing the pull request at:
   https://github.com/ietf-rats-wg/eat/pull/139/files

About the hardware-class-claim.

  "There is no global scheme or format for this claim."

So I wonder how TEEP's flow will deal with this.
Forgive me if that's buried in TEEP somewhere.
If so, I think that the EAT document should perhaps refer to that informatively.

I can see how the verifier can be okay with lack of scheme: the signing key on the
evidence can index into a database of devices, and then it's a string
comparison to see if the device claimed correctly.

But, equally well, the verifier already knows, via that database, what the
value is.  The only utility I can see if that the RP is going to see this in
the Attestation Results and use it to decide what binary to ask the TAM to
load.

I'm concerned that any hardware vendor can put any value in this.
The Verifier, provided by the hardware OEM, agrees.
The only thing the RP can do is the rely on it's contract with the Verifier.
That's actually the thing the RP ever does, I think: so don't mistake me.
What I'm asking is, given that, is this claim even needed as evidence?
Maybe it's only useful as Attestation Results.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 9 Nov 2021 09:02:24 -0800

Appreciate the comments.  Think it is important to keep this generic since it is going in EAT. TEEP can have specific ways it uses HW class, but don’t think we should be referencing TEEP in EAT.

There’s also some comments filed as issues in GitHub <https://github.com/ietf-rats-wg/eat/pull/139>.

Seems like it’s the concatenation of HW OEM ID, HW Class and HW Version that pin point exactly what HW you have. HW Class is kind like a model number.

LL

> On Nov 9, 2021, at 5:39 AM, Michael Richardson <[email-masked]> wrote:
> 
> 
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: Dave Thaler <[email-masked]>
Date: Tue, 9 Nov 2021 19:25:00 +0000

I agree with Laurence that it is important to keep it generic.  I have no preference as to
whether EAT informatively references TEEP or any other use case as examples (definitely
not by way of limitation).

And yes I believe it is useful (whether for TEEP or non-TEEP cases like Eric's router case)
in evidence, and attestation results, and even endorsements for that matter.
It's true that TEEP use cases would need in attestation results, but whether the
Verifier gets it from evidence or endorsements or appraisal policy, it needs to get
it from somewhere.

Dave

From: RATS <[email-masked]> On Behalf Of Laurence Lundblade
Sent: Tuesday, November 9, 2021 9:02 AM
To: Michael Richardson <[email-masked]>
Cc: [email-masked]; teep <[email-masked]>
Subject: Re: [Rats] EAT claims needed by TEEP

Appreciate the comments.  Think it is important to keep this generic since it is going in EAT. TEEP can have specific ways it uses HW class, but don't think we should be referencing TEEP in EAT.

There's also some comments filed as issues in GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats-wg%2Feat%2Fpull%2F139&data=04%7C01%7Cdthaler%40microsoft.com%7Ce1fc220c743a4db6499908d9a3a2ba01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637720742769829040%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=BTwJlDuZ16IG1jxj4827FkZ9DDfCert3UUzncKGYTP4%3D&reserved=0>.

Seems like it's the concatenation of HW OEM ID, HW Class and HW Version that pin point exactly what HW you have. HW Class is kind like a model number.

LL

On Nov 9, 2021, at 5:39 AM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

I'm reviewing the pull request at:
  https://github.com/ietf-rats-wg/eat/pull/139/files<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats-wg%2Feat%2Fpull%2F139%2Ffiles&data=04%7C01%7Cdthaler%40microsoft.com%7Ce1fc220c743a4db6499908d9a3a2ba01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637720742769838996%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=LfCSUvAJuk3UbPiSCIGnY25ct9Tq162%2Bq3pCyAQyWEA%3D&reserved=0>

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>   . o O ( IPv6 IøT consulting )
          Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Nov 2021 15:23:08 -0500

Laurence Lundblade <[email-masked]> wrote:
    > Appreciate the comments.  Think it is important to keep this generic
    > since it is going in EAT. TEEP can have specific ways it uses HW class,
    > but don’t think we should be referencing TEEP in EAT.

Then I suggest that:

     "There is no global scheme or format for this claim."
->
     "The format for this scheme will need to be specified within profiles that
      use it."

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Dave Thaler <[email-masked]>
Date: Wed, 10 Nov 2021 21:03:49 +0000

If it's a string, I think it should be up to the vendor specified by the oemid,
rather than by a vendor-agnostic profile.
If it's a UUID then that's not needed.

Personally I would argue for treating it as opaque in either case
and a verifier should only compare it for equality, rather than permitting
semantic structure in it.   That's because I think some hardware implementation
may fillvin values that can be used for multiple profiles.

Dave

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Michael Richardson
Sent: Wednesday, November 10, 2021 12:23 PM
To: Laurence Lundblade <[email-masked]>; [email-masked]; teep <[email-masked]>
Subject: Re: [Rats] EAT claims needed by TEEP

Laurence Lundblade <[email-masked]> wrote:
    > but don't think we should be referencing TEEP in EAT.

Then I suggest that:

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sandelman.ca%2F&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C47461df1d4ae4c6cc7f208d9a487f27c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637721726675767230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2BOIH8fZw6zju18DcoR9hQ4HkrtDsMkhTXwQTitkKsSQ%3D&amp;reserved=0        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 10 Nov 2021 13:25:40 -0800

An advantage of a string over a UUID is that it can be very short if that’s all the OEM needs, “S”, “3, “X” and “Y” in the case of Tesla.

LL

> On Nov 10, 2021, at 1:03 PM, Dave Thaler <[email-masked]> wrote:
> 
> From: RATS <[email-masked] <mailto:[email-masked]>> On Behalf Of Michael Richardson
> To: Laurence Lundblade <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; teep <[email-masked] <mailto:[email-masked]>>
> ]     [email-masked] <mailto:[email-masked]>  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sandelman.ca%2F&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C47461df1d4ae4c6cc7f208d9a487f27c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637721726675767230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2BOIH8fZw6zju18DcoR9hQ4HkrtDsMkhTXwQTitkKsSQ%3D&amp;reserved=0 <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sandelman.ca%2F&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C47461df1d4ae4c6cc7f208d9a487f27c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637721726675767230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2BOIH8fZw6zju18DcoR9hQ4HkrtDsMkhTXwQTitkKsSQ%3D&amp;reserved=0>        |   ruby on rails    [
> 
> 
> --
> Michael Richardson <[email-masked] <mailto:[email-masked]>>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Dave Thaler <[email-masked]>
Date: Wed, 10 Nov 2021 22:08:55 +0000

Good point, I agree.

Dave

From: Laurence Lundblade <[email-masked]>
Sent: Wednesday, November 10, 2021 1:26 PM
To: Dave Thaler <[email-masked]>
Cc: Michael Richardson <[email-masked]>; [email-masked]; teep <[email-masked]>
Subject: Re: [Rats] EAT claims needed by TEEP

An advantage of a string over a UUID is that it can be very short if that's all the OEM needs, "S", "3, "X" and "Y" in the case of Tesla.

LL

On Nov 10, 2021, at 1:03 PM, Dave Thaler <[email-masked]<mailto:[email-masked]>> wrote:

Dave

-----Original Message-----
From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Michael Richardson
Sent: Wednesday, November 10, 2021 12:23 PM
To: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; teep <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] EAT claims needed by TEEP

Laurence Lundblade <[email-masked]<mailto:[email-masked]>> wrote:

Then I suggest that:

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]<mailto:[email-masked]>  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sandelman.ca%2F&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C47461df1d4ae4c6cc7f208d9a487f27c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637721726675767230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2BOIH8fZw6zju18DcoR9hQ4HkrtDsMkhTXwQTitkKsSQ%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sandelman.ca%2F&data=04%7C01%7Cdthaler%40microsoft.com%7C89acf0870451455dc6db08d9a490a673%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637721763618882927%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=C8qHyE3%2BCgJ1Wq7Y5LWISkqmNucKNruTZnAR28Mzu48%3D&reserved=0>        |   ruby on rails    [

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 11 Nov 2021 10:34:39 +0000

There has been some detailed discussion on the PR [1] but I'd like to
point out a couple of more high level considerations.

Using a byte string (i.e., with no explicit typing) means coupling all
the RATS roles around the *syntax* of the claim.  For example, a
reference value provider (maybe a third party rather than the ODM
itself) would need to have detailed knowledge of the specific encoding
used by the attester on a given device in order to correctly instruct
the verifier.  While this is likely OK for a bunch of very simple
cases, I don't think it's a viable strategy in general.

An OID could be in dotted-decimal notation or BER-encoded or
RFC9090-encoded, an URI could be a string or a CRI, UUIDs could be in
canonical 8-4-4-4-12 format or binary encoded, etc.  All of those
encodings should be possible as long as it's understood by all the
involved roles that the thing is a URI or whatever.  The roles
distinction in the RATS architecture requires shared semantics, not
shared syntax.  In fact, I don't think we can have fine-grained
appraisal policies without a well defined typing system as the base for
the semantic layer.

Besides, it looks like we'd be creating a bad precedent because then one
could easily argue that *every* claim is possibly just a byte string or,
pushing this line of reasoning just a bit further, the whole claims-set
could be seen as one single gigantic opaque claim.

That said, if TEEP wants to go down this road I think it's fair and
fine, as long as it remains within the TEEP scope (i.e., within the
confines of TEEP's EAT profile) and doesn't claim general applicability.

cheers, thanks!

[1] https://github.com/ietf-rats-wg/eat/pull/139/files

-- 
Thomas

---

From: Brendan Moran <[email-masked]>
Date: Thu, 11 Nov 2021 11:27:36 +0000

Strings are not the right choice for machine readable fields. There are extremely good reasons not to use them. Please do not use strings for model IDs.

When you have a string, it is inevitable that someone in marketing will realise that it’s human-readable. The next step is that it must be controlled to preserve brand image. When this happens, it is also inevitable that *wildly incompatible hardware* with *the same function* will be forced into the same “model number.”

By making model identification explicitly non-parseable by humans, we prohibit its use as a controllable, human facing identifier. This ensures that it has a better chance of being used correctly as a means to distinguish between mutually incompatible versions.

Human readable strings used as machine-readable distinguishing tokens are a bad idea. Don’t do it.

Brendan

On 10 Nov 2021, at 21:25, Laurence Lundblade <[email-masked]<mailto:[email-masked]>> wrote:

LL

Dave

-----Original Message-----
From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Michael Richardson
Sent: Wednesday, November 10, 2021 12:23 PM
To: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; teep <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] EAT claims needed by TEEP

Then I suggest that:

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]<mailto:[email-masked]>  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sandelman.ca%2F&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C47461df1d4ae4c6cc7f208d9a487f27c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637721726675767230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2BOIH8fZw6zju18DcoR9hQ4HkrtDsMkhTXwQTitkKsSQ%3D&amp;reserved=0        |   ruby on rails    [

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

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Thu, 11 Nov 2021 12:21:52 +0000

Almost every point that has been made is reasonable, but I think we are typing to boil the ocean if we attempt to create a universal (or even “very widely applicable” HW class in EAT). Unfortunately we also have existing standards for HW where human readable strings form all/part of a normative HW definition – I do not think it is reasonable to simply disallow them, even if the approach is, as Brendan rightly states, not ideal.

Since the thread started by stating that being able to attest a TEE is a good idea, I will add that one relevant example where strings are used in this way is the GlobalPlatform TEE Management Framework (and GlobalPlatform OTrP management framework). These definitions cannot be changed in a backward-incompatible way (GlobalPlatform interoperability rules), so we are already in a position where what are almost certainly the most extensively commercially deployed TEE management frameworks in the world have a normative structure which employs strings (for those interested the relevant claims are in sections 9.1.3, 9.1.4, 9.1.5 and 9.1.6 of the GlobalPlatform TEE Management Framework)

To summarize what I have proposed in the PR (https://github.com/ietf-rats-wg/eat/pull/139/commits/d4e19b4a091cbbd6f94545688e2d1fc33c39a136).

  *   EAT should define two or three ways to encode HW class which are known to be collision-resistant. Thomas Fossati has suggested OID, UUID and URL in the PR, and this seems reasonable to me.
  *   EAT should allow profiles to extend the HW class type.
     *   My suggestion is that this pluggable type should be CBOR encoded so that a verifier that does not know how to decode a particular pluggable type can at least treat it is a somewhat-significant stream of bytes.
     *   Further, plugable type SHOULD be used in conjunction with profile claim
     *   Where pluggable type is used with profile claim, the combination profile claim + bstr encoding of pluggable type SHALL uniquely identify HW

I think this places us in a reasonable position from a standardization perspective without trying to cover all bases, and remembering that having a mechanism to enable EAT to be used with existing schemes that may have infelicitous characteristics is a useful goal.

In CDDL my proposal looks like:

hardware-class-label => $hardware-class-type

$hardware-class-type /= tagged-oid
$hardware-class-type /= tagged-uuid
$hardware-class-type /= tagged-url
$hardware-class-type /= bytes .cbor pluggable-x-hw-class-type

Best regards
Jeremy

On 11/11/2021, 11:28, "TEEP" <[email-masked]> wrote:

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Strings are not the right choice for machine readable fields. There are extremely good reasons not to use them. Please do not use strings for model IDs.

Brendan

LL

Dave

-----Original Message-----
From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Michael Richardson
Sent: Wednesday, November 10, 2021 12:23 PM
To: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; teep <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] EAT claims needed by TEEP

Then I suggest that:

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 11 Nov 2021 14:01:05 +0100

Thanks Jeremy for you thorough summary,

the extensible type-choice highlighted by Thomas - and extended by your 
proposal - is based on:

> https://github.com/ietf-rats/ietf-corim-cddl/blob/main/concise-mid-tag.cddl

To Brendan's point here:

> https://github.com/ietf-rats-wg/eat/pull/139#issuecomment-966230941

Trying to alter the semantics of SUIT-related information elements in 
order to generalize to a CWT Claim registry applicable scope might 
exceed feasibility. I am not against specifying a Claim with a string 
value that intends to identify a kind of hardware class in a given scope 
in the EAT I-D. But years ago (before chartering RATS) some decisions 
were made in EAT to work with a flat list of Claims and not a taxonomy 
of assertions, which now leaves us with the issue that we cannot cram 
all the semantics into a single Claim nor can we define subclass trees 
of assertions.

In summary, we can define a HW class Claim in EAT that uses a string 
value now and move forward. The other HW class identifiers can be 
handled by the corresponding documents where they are specified and 
used. Adding corresponding CWT Claims registry requests when these 
documents progress seems sensible to me.

What do others think?

Viele Grüße,

Henk

On 11.11.21 13:21, Jeremy O'Donoghue wrote:
> Almost every point that has been made is reasonable, but I think we are 
> typing to boil the ocean if we attempt to create a universal (or even 
> “very widely applicable” HW class in EAT). Unfortunately we also have 
> existing standards for HW where human readable strings form all/part of 
> a normative HW definition – I do not think it is reasonable to simply 
> disallow them, even if the approach is, as Brendan rightly states, not 
> ideal.
> 
> Since the thread started by stating that being able to attest a TEE is a 
> good idea, I will add that one relevant example where strings are used 
> in this way is the GlobalPlatform TEE Management Framework (and 
> GlobalPlatform OTrP management framework). These definitions cannot be 
> changed in a backward-incompatible way (GlobalPlatform interoperability 
> rules), so we are already in a position where what are almost certainly 
> the most extensively commercially deployed TEE management frameworks in 
> the world have a normative structure which employs strings (for those 
> interested the relevant claims are in sections 9.1.3, 9.1.4, 9.1.5 and 
> 9.1.6 of the GlobalPlatform TEE Management Framework)
> 
> To summarize what I have proposed in the PR 
> (https://github.com/ietf-rats-wg/eat/pull/139/commits/d4e19b4a091cbbd6f94545688e2d1fc33c39a136 
> <https://github.com/ietf-rats-wg/eat/pull/139/commits/d4e19b4a091cbbd6f94545688e2d1fc33c39a136>).
> 
>   * EAT should define two or three ways to encode HW class which are
>     known to be collision-resistant. Thomas Fossati has suggested OID,
>     UUID and URL in the PR, and this seems reasonable to me.
>       o My suggestion is that this pluggable type should be CBOR encoded
>         so that a verifier that does not know how to decode a particular
>         pluggable type can at least treat it is a somewhat-significant
>         stream of bytes.
>       o Further, plugable type SHOULD be used in conjunction with
>         profile claim
>       o Where pluggable type is used with profile claim, the combination
>         profile claim + bstr encoding of pluggable type SHALL uniquely
>         identify HW
> 
> I think this places us in a reasonable position from a standardization 
> perspective without trying to cover all bases, and remembering that 
> having a mechanism to enable EAT to be used with existing schemes that 
> may have infelicitous characteristics is a useful goal.
> 
> *WARNING:*This email originated from outside of Qualcomm. Please be wary 
> of any links or attachments, and do not enable macros.
> 
> Strings are not the right choice for machine readable fields. There are 
> extremely good reasons not to use them. Please do not use strings for 
> model IDs.
> 
> When you have a string, it is inevitable that someone in marketing will 
> realise that it’s human-readable. The next step is that it must be 
> controlled to preserve brand image. When this happens, it is also 
> inevitable that *wildly incompatible hardware* with *the same function* 
> will be forced into the same “model number.”
> 
> By making model identification explicitly non-parseable by humans, we 
> prohibit its use as a controllable, human facing identifier. This 
> ensures that it has a better chance of being used correctly as a means 
> to distinguish between mutually incompatible versions.
> 
>     An advantage of a string over a UUID is that it can be very short if
>     that’s all the OEM needs, “S”, “3, “X” and “Y” in the case of Tesla.
> 
>     LL
> 
> 
> 
>         From: RATS <[email-masked]
>         <mailto:[email-masked]>> On Behalf Of Michael Richardson
>         To: Laurence Lundblade <[email-masked]
>         <mailto:[email-masked]>>;[email-masked]
>         <mailto:[email-masked]>; teep <[email-masked] <mailto:[email-masked]>>
>         ] [email-masked]
>         <mailto:[email-masked]>https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sandelman.ca%2F&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C47461df1d4ae4c6cc7f208d9a487f27c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637721726675767230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2BOIH8fZw6zju18DcoR9hQ4HkrtDsMkhTXwQTitkKsSQ%3D&amp;reserved=0
>         <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sandelman.ca%2F&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C47461df1d4ae4c6cc7f208d9a487f27c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637721726675767230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2BOIH8fZw6zju18DcoR9hQ4HkrtDsMkhTXwQTitkKsSQ%3D&amp;reserved=0>       |
>            ruby on rails    [
> 
> 
>         --
>         Michael Richardson <[email-masked]
>         <mailto:[email-masked]>>, Sandelman Software Works  -=
>         IPv6 IoT consulting =-
> 
>     [email-masked] <mailto:[email-masked]>
> 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: Michael Richardson <[email-masked]>
Date: Thu, 11 Nov 2021 08:43:31 -0500

> could be seen as one single gigantic opaque claim.

! make me think about the multiple levels of "comment" that occured in the
JCL days, where commands were comments...

    > will be forced into the same “model number.”

This has happened multiple times out there.
Same box, same case, entirely different CPU inside.

    > to distinguish between mutually incompatible versions.

!

mcr suggested>

  "There is no global scheme or format for this claim."
    ->
  "The format for this scheme will need to be specified within profiles that use it."

---

From: Giridhar Mandyam <[email-masked]>
Date: Thu, 11 Nov 2021 17:54:05 +0000

I am not seeing any consensus here.  

Since the TEEP Working Group (or at least persons who claim to speak for the TEEP WG) is the one making the assertion that EAT needs an additional claim, I think it is up to the TEEP Working Group to come back with a solid proposal and perhaps even create the corresponding PR.  There is a candidate PR (https://github.com/ietf-rats-wg/eat/pull/139) created by the EAT editorship, but it might make sense for this issue to be brought back into the TEEP WG and achieve consensus there.  Given that several persons who have commented on the PR and on this topic are active TEEP participants, I am lead to believe there is disagreement even within the TEEP WG currently.

RATS Chairs,

As a co-editor, I don't think we are in a position to generate a -12 draft of the EAT document to include this TEEP claim because proponents have not articulated what actually is required for such a claim.  I also don't believe this should be a LC blocking issue.  If the TEEP WG can decide on a formal proposal for a class claim, then this can be considered as part of Last Call comment resolution.

-Giri

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Henk Birkholz
Sent: Thursday, November 11, 2021 5:01 AM
To: Jeremy O'Donoghue <[email-masked]>; Brendan Moran <[email-masked]>; Laurence Lundblade <[email-masked]>
Cc: Michael Richardson <[email-masked]>; teep <[email-masked]>; Dave Thaler <[email-masked]>; [email-masked]
Subject: Re: [Rats] [Teep] EAT claims needed by TEEP

> https://github.com/ietf-rats-wg/eat/pull/139#issuecomment-966230941

Trying to alter the semantics of SUIT-related information elements in order to generalize to a CWT Claim registry applicable scope might exceed feasibility. I am not against specifying a Claim with a string value that intends to identify a kind of hardware class in a given scope in the EAT I-D. But years ago (before chartering RATS) some decisions were made in EAT to work with a flat list of Claims and not a taxonomy of assertions, which now leaves us with the issue that we cannot cram all the semantics into a single Claim nor can we define subclass trees of assertions.

In summary, we can define a HW class Claim in EAT that uses a string value now and move forward. The other HW class identifiers can be handled by the corresponding documents where they are specified and used. Adding corresponding CWT Claims registry requests when these documents progress seems sensible to me.

What do others think?

Viele Grüße,

Henk

On 11.11.21 13:21, Jeremy O'Donoghue wrote:
> Almost every point that has been made is reasonable, but I think we 
> are typing to boil the ocean if we attempt to create a universal (or 
> even "very widely applicable" HW class in EAT). Unfortunately we also 
> have existing standards for HW where human readable strings form 
> all/part of a normative HW definition - I do not think it is 
> reasonable to simply disallow them, even if the approach is, as 
> Brendan rightly states, not ideal.
>
> Since the thread started by stating that being able to attest a TEE is 
> a good idea, I will add that one relevant example where strings are 
> used in this way is the GlobalPlatform TEE Management Framework (and 
> changed in a backward-incompatible way (GlobalPlatform 
> interoperability rules), so we are already in a position where what 
> are almost certainly the most extensively commercially deployed TEE 
> management frameworks in the world have a normative structure which 
> employs strings (for those interested the relevant claims are in 
> sections 9.1.3, 9.1.4, 9.1.5 and
> *WARNING:*This email originated from outside of Qualcomm. Please be 
> wary of any links or attachments, and do not enable macros.
>
> Strings are not the right choice for machine readable fields. There 
> are extremely good reasons not to use them. Please do not use strings 
> for model IDs.
>
> When you have a string, it is inevitable that someone in marketing 
> will realise that it's human-readable. The next step is that it must 
> be controlled to preserve brand image. When this happens, it is also 
> inevitable that *wildly incompatible hardware* with *the same 
> function* will be forced into the same "model number."
>
> Human readable strings used as machine-readable distinguishing tokens 
> are a bad idea. Don't do it.
>
> Brendan
>
>
>
>     that's all the OEM needs, "S", "3, "X" and "Y" in the case of Tesla.
>
>     LL
>
>
>
> 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: Thu, 11 Nov 2021 10:35:35 -0800

+1

> On Nov 11, 2021, at 9:54 AM, Giridhar Mandyam <[email-masked]> wrote:
>

---

From: Ira McDonald <[email-masked]>
Date: Thu, 11 Nov 2021 20:38:00 -0500

Hi,

+1 to Brendan's point about why "human-readable" strings are a *bad* idea
for
hardware type identifiers.

+1 to Thomas and Jeremy's observations.

Cheers,
- Ira

*Ira McDonald (Musician / Software Architect)*

*Chair - SAE Trust Anchors and Authentication TF*
*Co-Chair - TCG Trusted Mobility Solutions WG*

*Co-Chair - TCG Metadata Access Protocol SG*

*Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer
Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF
Designated Expert - IPP & Printer MIBBlue Roof Music / High North
Inchttp://sites.google.com/site/blueroofmusic
<http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc
<http://sites.google.com/site/highnorthinc>mailto: [email-masked]
<[email-masked]>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*

On Thu, Nov 11, 2021 at 8:43 AM Michael Richardson <[email-masked]>
wrote:

> are
> will
> function*

---

From: Dave Thaler <[email-masked]>
Date: Fri, 12 Nov 2021 14:19:43 +0000

Reporting this here since not all in RATS were present in the TEEP
meeting...

TEEP discussed this thread in the WG meeting this morning, where
many of the people who weighed in on this thread were present
(thanks!)   Nancy did two polls during the meeting to get a sense
of the room.

My takeaway is that TEEP (with various participants from SUIT
and RATS who weighed in) believes that RATS should define
a claim in the EAT spec, but leave the *values* to be defined by
profiles and by vendors (i.e., both categories are needed).
The TEEP profile would define values used by TEEP use cases,
as would other profiles.  Vendors would be able to define
vendor-specific values in addition to standard values defined in profiles.

Also TEEP had strong consensus that the values should be opaque
not structured.   As such, some believe a UUID would be better
than a byte blob or text string because a UUID helps ensure opaqueness,
but that's for RATS to decide if RATS defines the claim and requirements
for profiles.

Dave

From: TEEP <[email-masked]> On Behalf Of Ira McDonald
Sent: Thursday, November 11, 2021 5:38 PM
To: Michael Richardson <[email-masked]>; Ira McDonald <[email-masked]>
Cc: [email-masked]; teep <[email-masked]>
Subject: Re: [Teep] [Rats] EAT claims needed by TEEP

Hi,

+1 to Brendan's point about why "human-readable" strings are a *bad* idea for
hardware type identifiers.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - SAE Trust Anchors and Authentication TF
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsites.google.com%2Fsite%2Fblueroofmusic&data=04%7C01%7Cdthaler%40microsoft.com%7Ce47a9aa2c15a40d4b82208d9a57d1f55%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637722780338856205%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=7Qp8Rgwl%2FWaGlLU%2FqtxiFkIEDAwjCW3np3MNmyCZ2Zs%3D&reserved=0>
http://sites.google.com/site/highnorthinc<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsites.google.com%2Fsite%2Fhighnorthinc&data=04%7C01%7Cdthaler%40microsoft.com%7Ce47a9aa2c15a40d4b82208d9a57d1f55%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637722780338866160%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=1SzaaK0DOc%2B410s6fsOto9WD9X6SnXBGCGOakLci%2FuY%3D&reserved=0>
mailto: [email-masked]<mailto:[email-masked]>
(permanent) PO Box 221  Grand Marais, MI 49839  906-494-2434

On Thu, Nov 11, 2021 at 8:43 AM Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

    > realise that it's human-readable. The next step is that it must be
    > will be forced into the same "model number."

!

mcr suggested>

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

_______________________________________________
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=04%7C01%7Cdthaler%40microsoft.com%7Ce47a9aa2c15a40d4b82208d9a57d1f55%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637722780338866160%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ed8qtRtCzAgHcVRzqrzeX2dt0Pw7jl6W5HBC3hJj8CA%3D&reserved=0>

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 12 Nov 2021 08:46:29 -0800

I’d like to articulate the larger frame up for identifying HW in EAT. The applicability is all HW, not just TEEs.

I think it is the concatenation of these three:
   - OEM ID
   - Model/Class
   - Version

EAT draft 11 is missing model/class. It is good that TEEP brought this to our attention.

I have preference for “model” over “class”. Lots of things have model numbers (cars, TVs, phones…), and we know what is meant by a model number. The term “class" confused me and may confuse others (perhaps because there was little descriptive text or examples of real devices and “class" is usually for broad taxonomies like fruit vs vegetable).

I think the current proposal <https://github.com/ietf-rats-wg/eat/pull/139> of a byte string for model/class is fine. I don’t see the point of it being an OID or URL since it is not a global identifier.

I think having general HW identification split into three is useful because sometimes you care solely about OEM, sometimes you care right down to the version number.

The OEM ID must be a global identifier, but model and version are local to an OEM. Each OEM has their own model number scheme and that is fine. The product team for a particular model comes up with their version scheme, and that is fine. This seems parallels how the world mostly works for all sorts of HW.

The main thing a recipient does with an OEM ID and model is lookup them up in a database or compare them for equality, so we don’t need to specify any internal structure for a recipient to decode. The simpler they are, the better.

Version is different. We like comparing it for greater than and less than because there’s a good possibility that two versions of the hardware are compatible with some SW or such. Compatibility is less likely for models so lookup/equality is enough. To allow version comparison, EAT uses CoSWID version identifiers <https://www.ietf.org/archive/id/draft-ietf-sacm-coswid-19.html#name-version-scheme> which indicates how comparison works.

Another very useful thing here is to re use identifiers that already exist. In EAT the OEM is identified by existing OEM databases (PEN <https://en.wikipedia.org/wiki/Private_Enterprise_Number> or IEEE OUI <https://standards.ieee.org/content/dam/ieee-standards/standards/web/documents/tutorials/eui.pdf>, aka MAC address) or a 16-byte random number (which can be a UUID). We want OEMs to be able to re-use their extant internal model and version number schemes, so they are both strings (and can also be UUIDs).

Here’s real examples:

   OEM: 49279 (PEN actually assigned to Tesla)
   Model: “X"
   Version “2.3.2” (CoSWID type 1, multipartnumeric)

   OEM: 00A0C6  (OUI assigned to Qualcomm)
   Model: “Snapdragon 888”
   Version: “23” (CoSWID type 4, decimal)

   OEM: D0D003 (OUI assigned to Samsung)
   Model: 042aea10a0f14f2d391373599be69d53a7 (One-time randomly generated model ID for Samsung’s implementation of a particular ARM TEE)
   Version: “1.3c” (CoSWID type 2, multipartnumeric+suffix)

By one-time generated, I mean that an RNG was run once off the device and written down to be used for years to identify the particular TEE model/class. If it is a UUID, then it isn’t generated on the device being attested to, but on some administrative laptop or such, written down and the same one used for years on millions of devices.

LL

> On Nov 11, 2021, at 5:38 PM, Ira McDonald <[email-masked]> wrote:
> 
> Hi,
> 
> http://sites.google.com/site/blueroofmusic <http://sites.google.com/site/blueroofmusic>
> http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>
> mailto: [email-masked] <mailto:[email-masked]>
> On Thu, Nov 11, 2021 at 8:43 AM Michael Richardson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Thomas Fossati <[email-masked] <mailto:[email-masked]>> wrote:
> Brendan Moran <[email-masked] <mailto:[email-masked]>> wrote:
> Michael Richardson <[email-masked] <mailto:[email-masked]>>   . o O ( IPv6 IøT consulting )
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 12 Nov 2021 17:09:37 -0500

> vendor-specific values in addition to standard values defined in profiles.

Having missed this morning's party due to conflicts, I'm pleased by this
result.  That's basically what I said.
RATS needs to standardize that there such a claim, but it's not acceptable in
the end for it to be free-for-all.  TEEP needs to be clear as to what is
going to go in.

    > but that's for RATS to decide if RATS defines the claim and requirements

I'm all for it being up to TEEP.  I'm okay with UUID.
I would also suggest some kind of PEN-based structure, perhaps based upon a
two element CBOR array like: [ PEN, bstr ]

---

From: Michael Richardson <[email-masked]>
Date: Fri, 12 Nov 2021 17:13:58 -0500

Laurence Lundblade <[email-masked]> wrote:
    > I’d like to articulate the larger frame up for identifying HW in
    > EAT. The applicability is all HW, not just TEEs.

That's true and false.

The claim should have broad applicability to all sorts of HW, yes/true.

But, what are valid values for TEEs should be up to TEEP.
EAT will never be used without some kind of industry profile like TEEP, so false.

    > I think it is the concatenation of these three:

I don't think this is a useful thing to do.

    > Another very useful thing here is to re use identifiers that already
    > exist. In EAT the OEM is identified by existing OEM databases (PEN
    > <https://en.wikipedia.org/wiki/Private_Enterprise_Number> or IEEE OUI
    > <https://standards.ieee.org/content/dam/ieee-standards/standards/web/documents/tutorials/eui.pdf>,
    > aka MAC address) or a 16-byte random number (which can be a UUID). We
    > want OEMs to be able to re-use their extant internal model and version
    > number schemes, so they are both strings (and can also be UUIDs).

    > Version “2.3.2” (CoSWID type 1, multipartnumeric)

This actually isn't very useful, because you've used a marketing term.
You need to know the model + year/month + factory, to know what's inside.
That's why we shouldn't split out model/version.  Let the OEM do that.

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 13 Nov 2021 19:00:07 -0800

I’m update the PR for thi <https://github.com/ietf-rats-wg/eat/pull/139>s a lot:

* It is for OEM’s to identify individual products, models and variants

* It is only required to be unique for a given OEM. It is the combo of OEM ID and class that globally identifies a product. This allows re use of internal product schemes, allows them to be very short and doesn’t require engaging with some global identification scheme (but an OEM can use a global scheme if they want).

* The receiver of this MUST treat this an an opaque binary byte string (This is the same as UEID). The receiver can only use this for lookup in a database and comparison for equality.

* The sender can base this off of OIDs, URLs, UUIDs, an RNG, internal product codes and so on, but they SHOULD make it not human-readable (hash or such).

* I really don’t think we want to identify that it is an OID, URI or such because it is more work for the receiver to decode and because we don’t want the receiver doing anything with the internal structure.

* Added examples (that check against the CDDL).

LL

> On Nov 12, 2021, at 8:46 AM, Laurence Lundblade <[email-masked]> wrote:
> 
>> On Nov 11, 2021, at 5:38 PM, Ira McDonald <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi,
>>