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

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 <teep-bounces@ietf.org> On Behalf Of Ira McDonald
Sent: Thursday, November 11, 2021 5:38 PM
To: Michael Richardson <mcr+ietf@sandelman.ca>; Ira McDonald <blueroofmusic@gmail.com>
Cc: rats@ietf.org; teep <teep@ietf.org>
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.

+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 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: blueroofmusic@gmail.com<mailto:blueroofmusic@gmail.com>
(permanent) PO Box 221  Grand Marais, MI 49839  906-494-2434

On Thu, Nov 11, 2021 at 8:43 AM Michael Richardson <mcr+ietf@sandelman.ca<mailto:mcr%2Bietf@sandelman.ca>> wrote:

Thomas Fossati <tho.ietf@gmail.com<mailto:tho.ietf@gmail.com>> wrote:
    > 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.

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

Brendan Moran <Brendan.Moran@arm.com<mailto:Brendan.Moran@arm.com>> wrote:
    > 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."

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

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

!

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

--
Michael Richardson <mcr+IETF@sandelman.ca<mailto:mcr%2BIETF@sandelman.ca>>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

_______________________________________________
RATS mailing list
RATS@ietf.org<mailto:RATS@ietf.org>
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>