Re: [Rats] EAT claims needed by TEEP

Laurence Lundblade <> Fri, 12 November 2021 16:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F92D3A0C25 for <>; Fri, 12 Nov 2021 08:46:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KD1pCG4rGn8U for <>; Fri, 12 Nov 2021 08:46:31 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 44B883A0C18 for <>; Fri, 12 Nov 2021 08:46:31 -0800 (PST)
Received: from [] ([]) by :SMTPAUTH: with ESMTPSA id lZh7mHv3QU02ClZh7m7dAC; Fri, 12 Nov 2021 09:46:30 -0700
X-CMAE-Analysis: v=2.4 cv=BZsdbph2 c=1 sm=1 tr=0 ts=618e9a66 a=VPU1mRQhDhA4uSX60JRRww==:117 a=VPU1mRQhDhA4uSX60JRRww==:17 a=NEAV23lmAAAA:8 a=48vgC7mUAAAA:8 a=8pif782wAAAA:8 a=o83nqyVRAAAA:8 a=pGLkceISAAAA:8 a=y6WFtdQdAAAA:20 a=qlatCZPWAAAA:20 a=l70xHGcnAAAA:8 a=7CQSdrXTAAAA:8 a=MZXgNqHveanxa18cQoAA:9 a=QEXdDO2ut3YA:10 a=MDABLX8d_eUA:10 a=JDrJ-FpfaccA:10 a=53J-nn582usA:10 a=j43q7CBPvGTGPXPkuYkA:9 a=3g1i1AI_qX6IOsWu:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=JtN_ecm89k2WOvw5-HMO:22 a=a-qgeE7W1pNrGK8U0ZQC:22
From: Laurence Lundblade <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CD44094B-5D88-466D-95F9-55B7B84BF3CD"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Fri, 12 Nov 2021 08:46:29 -0800
In-Reply-To: <>
Cc: Michael Richardson <>, "" <>, teep <>
To: Ira McDonald <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <27150.1636465193@localhost> <> <398725.1636575788@dooku> <> <> <> <21384.1636638211@localhost> <>
X-Mailer: Apple Mail (2.3608.
X-CMAE-Envelope: MS4xfJWuju1Fs2hHJ0IRv2mFkXOeQirlYRQnMszS0rwTSwlPYEVIwz/FaOYRFrzJaIMwoG6GbrpstJHf+Zgf7vNJUBoRVmDlDzzGIEI8bkWJt2Te7giMhp9V D/V3neKauJlT2sJHJjFD5vf0M5+mDv2jvC+c8BdkikpWRYGLP8GMe2MC2zkSekc3UuGWfH97x+d8zlSR7dBkwRqyUivqcKPa9+7XuVnTMp299Ase8UyRgT74 RXD7D8dP8ikii3u15WuCPZbe/6hbnzXzTB5DJzumljg=
Archived-At: <>
Subject: Re: [Rats] EAT claims needed by TEEP
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Nov 2021 16:46:38 -0000

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 <> 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 <> 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 <> or IEEE OUI <>, 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.


> On Nov 11, 2021, at 5:38 PM, Ira McDonald <> wrote:
> 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
> <>
> <>
> mailto: <>
> (permanent) PO Box 221  Grand Marais, MI 49839  906-494-2434
> On Thu, Nov 11, 2021 at 8:43 AM Michael Richardson < <>> wrote:
> Thomas Fossati < <>> 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 < <>> 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 < <>>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> _______________________________________________
> RATS mailing list
> <>
> <>
> _______________________________________________
> RATS mailing list