Subject: [Rats] EAT HW OEM ID, vendor ID, ...

From: Laurence Lundblade <[email-masked]>
Date: Thu, 19 Aug 2021 20:09:32 -0700

I’ve made a PR <https://github.com/ietf-rats-wg/eat/pull/124> that makes the OEM ID claim more general and thus hopefully more useful.

I realize that different attestation use cases will necessarily have different ways of identifying the OEM/vendor/manufacturer and one claim will not suit all. But I do want the claims in EAT to be most generally useful, hence this improvement.

This is partly motivated by looking at SUIT’s vendor ID and the chip vendor in Eric’s attestation results. I also realize that EAT OEM ID might not be what they need.

Note that one single device might support multiple attestation use cases. For example, it might be doing attestation to join the network, for a financial transaction and for access to some data. A general purpose HW OEM ID might work across all of those and be of more value because it does.

Here are the changes:

- OEM ID is now for the identification of HW. That was always my intention, but it didn’t say that before.

- It still supports a 3-byte IEEE OUI (vendor part of MAC address) which many vendors already have and is nice and short.

- IANA PEN <https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers> support is added. This encodes to 2 bytes in CBOR.

- A 16 byte RNG/hash option is added.

- The attester can use any one of these 3 it wants. The verifier/RP should accept all 3.

Personally, I think this provides most everything a UUID-based OEM ID can provide, is simpler and easier to understand, and has two super-compact options that UUIDs don’t.

I did the birthday problem math to know that 128-bits is enough and that sometimes we could squeak by with 96. It doesn’t seem worth the trouble to define a 96-bit version, though. It just saves 4 bytes.

The entire text of the new OEM ID section is below. I am particularly interested in comments on how this can be the most generally useful for the most use cases.

LL

3.6.  <file:///Users/lgl/IETF/EAT/eat-drafts/oemid/draft-ietf-rats-eat.html#section-3.6>Hardware OEM Identification (oemid) <file:///Users/lgl/IETF/EAT/eat-drafts/oemid/draft-ietf-rats-eat.html#name-hardware-oem-identification>
This claim identifies the OEM of the hardware. Any of the three forms may be used at the convenience of the attester implementation. The receiver of this claim MUST be able to handle all three forms. <file:///Users/lgl/IETF/EAT/eat-drafts/oemid/draft-ietf-rats-eat.html#section-3.6-1>
3.6.1.  <file:///Users/lgl/IETF/EAT/eat-drafts/oemid/draft-ietf-rats-eat.html#section-3.6.1>Random Number Based <file:///Users/lgl/IETF/EAT/eat-drafts/oemid/draft-ietf-rats-eat.html#name-random-number-based>
This format is always 16 bytes in size (128 bits). <file:///Users/lgl/IETF/EAT/eat-drafts/oemid/draft-ietf-rats-eat.html#section-3.6.1-1>
The OEM may create their own ID by using a cryptographic-quality random number generator. They would perform this only once in the life of the company to generate the single ID for said company. They would use that same ID in every device they make. This uniquely identifies the OEM on a statistical basis and is large enough should there be ten billion companies. <file:///Users/lgl/IETF/EAT/eat-drafts/oemid/draft-ietf-rats-eat.html#section-3.6.1-2>
The OEM may also use a hash like SHA-256 and truncate the output to 128 bits. The input to the hash should be somethings that have at least 96 bits of entropy, but preferably 128 bits of entropy. The input to the hash may be something whose uniqueness is managed by a central registry like a domain name. <file:///Users/lgl/IETF/EAT/eat-drafts/oemid/draft-ietf-rats-eat.html#section-3.6.1-3>
This is to be base64url encoded in JSON. <file:///Users/lgl/IETF/EAT/eat-drafts/oemid/draft-ietf-rats-eat.html#section-3.6.1-4>
3.6.2.  <file:///Users/lgl/IETF/EAT/eat-drafts/oemid/draft-ietf-rats-eat.html#section-3.6.2>IEEE Based <file:///Users/lgl/IETF/EAT/eat-drafts/oemid/draft-ietf-rats-eat.html#name-ieee-based>
The IEEE operates a global registry for MAC addresses and company IDs. This claim uses that database to identify OEMs. The contents of the claim may be either an IEEE MA-L, MA-M, MA-S or an IEEE CID [IEEE.RA <file:///Users/lgl/IETF/EAT/eat-drafts/oemid/draft-ietf-rats-eat.html#IEEE.RA>]. An MA-L, formerly known as an OUI, is a 24-bit value used as the first half of a MAC address. MA-M similarly is a 28-bit value uses as the first part of a MAC address, and MA-S, formerly known as OUI-36, a 36-bit value. Many companies already have purchased one of these. A CID is also a 24-bit value from the same space as an MA-L, but not for use as a MAC address. IEEE has published Guidelines for Use of EUI, OUI, and CID [OUI.Guide <file:///Users/lgl/IETF/EAT/eat-drafts/oemid/draft-ietf-rats-eat.html#OUI.Guide>] and provides a lookup services [OUI.Lookup <file:///Users/lgl/IETF/EAT/eat-drafts/oemid/draft-ietf-rats-eat.html#OUI.Lookup>] <file:///Users/lgl/IETF/EAT/eat-drafts/oemid/draft-ietf-rats-eat.html#section-3.6.2-1>
Companies that have more than one of these IDs or MAC address blocks should pick one and prefer that for all their devices. <file:///Users/lgl/IETF/EAT/eat-drafts/oemid/draft-ietf-rats-eat.html#section-3.6.2-2>
Commonly, these are expressed in Hexadecimal Representation [IEEE.802-2001 <file:///Users/lgl/IETF/EAT/eat-drafts/oemid/draft-ietf-rats-eat.html#IEEE.802-2001>]also called the Canonical format. When this claim is encoded the order of bytes in the bstr are the same as the order in the Hexadecimal Representation. For example, an MA-L like "AC-DE-48" would be encoded in 3 bytes with values 0xAC, 0xDE, 0x48. For JSON encoded tokens, this is further base64url encoded. <file:///Users/lgl/IETF/EAT/eat-drafts/oemid/draft-ietf-rats-eat.html#section-3.6.2-3>
This format is always 3 bytes in size in CBOR. <file:///Users/lgl/IETF/EAT/eat-drafts/oemid/draft-ietf-rats-eat.html#section-3.6.2-4>
3.6.3.  <file:///Users/lgl/IETF/EAT/eat-drafts/oemid/draft-ietf-rats-eat.html#section-3.6.3>IANA Private Enterprise Number <file:///Users/lgl/IETF/EAT/eat-drafts/oemid/draft-ietf-rats-eat.html#name-iana-private-enterprise-num>
IANA maintains a simple integer-based company registry called the Private Enterprise Number (PEN) [PEN <file:///Users/lgl/IETF/EAT/eat-drafts/oemid/draft-ietf-rats-eat.html#PEN>]. <file:///Users/lgl/IETF/EAT/eat-drafts/oemid/draft-ietf-rats-eat.html#section-3.6.3-1>
PENs are often used to create an OID. That is not the case here. They are used only as a simple integer. <file:///Users/lgl/IETF/EAT/eat-drafts/oemid/draft-ietf-rats-eat.html#section-3.6.3-2>
This is encoded as a major type 0 integer in CBOR and is typically 2 when encoded. It is encoded as a number in JSON. <file:///Users/lgl/IETF/EAT/eat-drafts/oemid/draft-ietf-rats-eat.html#section-3.6.3-3>
oemid-pen = int

oemid-ieee = bstr .size 3

oemid-random = bstr .size 128

oemid-claim = (
    oemid => oemid-random / oemid-ieee / oemid-pen
)
 <file:///Users/lgl/IETF/EAT/eat-drafts/oemid/draft-ietf-rats-eat.html#section-3.6.3-4>

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 19 Aug 2021 20:19:00 -0700

> On Aug 19, 2021, at 8:09 PM, Laurence Lundblade <[email-masked]> wrote:
> 

oemid-random = bstr .size 16

---

From: Russ Housley <[email-masked]>
Date: Fri, 20 Aug 2021 11:08:19 -0400

> On Aug 19, 2021, at 11:09 PM, Laurence Lundblade <[email-masked]> wrote:
> 

The most recent PEN assignment is 57825.  The need for a third byte is in sight.

Russ

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 20 Aug 2021 18:58:57 -0700

> On Aug 20, 2021, at 8:08 AM, Russ Housley <[email-masked]> wrote:
> 
> 
>> On Aug 19, 2021, at 11:09 PM, Laurence Lundblade <[email-masked] <mailto:[email-masked]>> wrote:
>> 

Hi Russ,

In CBOR it is encoded as a type 0 integer, which will scale up to 64-bits if necessary, so no worries.

LL