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

[Jeremy O'Donoghue <[e-mail]>]

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" <[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        |   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.