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

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 <rats-bounces@ietf.org> On Behalf Of Henk Birkholz
Sent: Thursday, November 11, 2021 5:01 AM
To: Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>; Brendan Moran <Brendan.Moran@arm.com>; Laurence Lundblade <lgl@island-resort.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>; teep <teep@ietf.org>; Dave Thaler <dthaler@microsoft.com>; rats@ietf.org
Subject: Re: [Rats] [Teep] EAT claims needed by TEEP

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

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/d4e19b4a091cbbd6
> f94545688e2d1fc33c39a136 
> <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" <teep-bounces@ietf.org> 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 <lgl@island-resort.com
>     <mailto:lgl@island-resort.com>> 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 <dthaler@microsoft.com
>         <mailto:dthaler@microsoft.com>> 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 <rats-bounces@ietf.org
>         <mailto:rats-bounces@ietf.org>> On Behalf Of Michael Richardson
>         Sent: Wednesday, November 10, 2021 12:23 PM
>         To: Laurence Lundblade <lgl@island-resort.com
>         <mailto:lgl@island-resort.com>>;rats@ietf.org
>         <mailto:rats@ietf.org>; teep <teep@ietf.org <mailto:teep@ietf.org>>
>         Subject: Re: [Rats] EAT claims needed by TEEP
>
>
>         Laurence Lundblade <lgl@island-resort.com
>         <mailto:lgl@island-resort.com>> 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  [
>         ] mcr@sandelman.ca
>         <mailto:mcr@sandelman.ca>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 <mcr+IETF@sandelman.ca
>         <mailto:mcr+IETF@sandelman.ca>>, Sandelman Software Works  -=
>         IPv6 IoT consulting =-
>
>     _______________________________________________
>     TEEP mailing list
>     TEEP@ietf.org <mailto:TEEP@ietf.org>
>     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
> TEEP@ietf.org
> https://www.ietf.org/mailman/listinfo/teep
>

_______________________________________________
RATS mailing list
RATS@ietf.org
https://www.ietf.org/mailman/listinfo/rats