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

[Henk Birkholz <[e-mail]>]

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.
>   * EAT should allow profiles to extend the HW class type.
>       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.
> 
> 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" <[e-mail]> 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.
> 
> 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 <[e-mail]
>     <mailto:[e-mail]>> wrote:
> 
>     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 <[e-mail]
>         <mailto:[e-mail]>> wrote:
> 
>         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 <[e-mail]
>         <mailto:[e-mail]>> On Behalf Of Michael Richardson
>         Sent: Wednesday, November 10, 2021 12:23 PM
>         To: Laurence Lundblade <[e-mail]
>         <mailto:[e-mail]>>;[e-mail]
>         <mailto:[e-mail]>; teep <[e-mail] <mailto:[e-mail]>>
>         Subject: Re: [Rats] EAT claims needed by TEEP
> 
> 
>         Laurence Lundblade <[e-mail]
>         <mailto:[e-mail]>> 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  [
>         ] [e-mail]
>         <mailto:[e-mail]>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 <[e-mail]
>         <mailto:[e-mail]>>, Sandelman Software Works  -=
>         IPv6 IoT consulting =-
> 
>     _______________________________________________
>     TEEP mailing list
>     [e-mail] <mailto:[e-mail]>
>     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.
> 
> 
> _______________________________________________
> TEEP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teep
>