Subject: [Rats] Early assignment of EAT claim keys

From: Laurence Lundblade <[email-masked]>
Date: Fri, 14 Jan 2022 11:36:39 -0800

So it has come to pass that the early assignment of EAT claim key <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-11#section-9.3.1>  didn’t actually complete. The claim key numbers (10 for nonce, 11 for UEID...), in the EAT drafts are not officially assigned. The designated expert has commented that most of these claims are not of general enough use to warrant assignment to these low numbers. It seems very unlikely that all of these assignments will stand.

This email is to solicit comments, particularly from implementers and particularly as to which should be in which range. The ranges are:

1-byte — -24 to 23
2-byte — -256 to 255 excluding the 1-byte range
3-byte — -655536 to 65535 excluding the 1 and 2-byte ranges

Below is the proposal from the designated expert. Only nonce retains its number and most are in the 3-byte range.

All of these claims are in a standards track document so they are all eligible for any number on that basis. The issue is primarily about the encoding size.

I am sorry for my part in this not going as expected and the trouble it will cause for implementers. 

I suspect some implementations will have to conditionally accept some of the non-early assigned numbers to manage compatibility. For example, if UEID is now 256, a decoder will have to accept 256 and 11 in some contexts since UEID has been 11 in IETF drafts for about a year now.

LL

  o  Claim Name: Nonce
  o  Claim Description: Nonce
  o  JWT Claim Name: "nonce" (already registered for JWT)
  o  Claim Key: 10
  o  Claim Value Type(s): byte string
  o  Change Controller: IESG
  o  Specification Document(s): [OpenIDConnectCore], *this document*

  o  Claim Name: UEID
  o  Claim Description: The Universal Entity ID
  o  JWT Claim Name: "ueid"
  o  CWT Claim Key: 256
  o  Claim Value Type(s): byte string
  o  Change Controller: IESG
  o  Specification Document(s): *this document*

  o  Claim Name: OEMID
  o  Claim Description: IEEE-based OEM ID
  o  JWT Claim Name: "oemid"
  o  Claim Key: 257
  o  Claim Value Type(s): byte string
  o  Change Controller: IESG
  o  Specification Document(s): *this document*

  o  Claim Name: Security Level
  o  Claim Description: Characterization of the security of an Attester or submodule
  o  JWT Claim Name: "seclevel"
  o  Claim Key: 258
  o  Claim Value Type(s): integer
  o  Change Controller: IESG
  o  Specification Document(s): *this document*

  o  Claim Name: Secure Boot
  o  Claim Description: Indicate whether the boot was secure
  o  JWT Claim Name: "secboot"
  o  Claim Key: 259
  o  Claim Value Type(s): Boolean
  o  Change Controller: IESG
  o  Specification Document(s): *this document*

  o  Claim Name: Debug Status
  o  Claim Description: Indicate status of debug facilities
  o  JWT Claim Name: "dbgstat"
  o  Claim Key: 260
  o  Claim Value Type(s): integer
  o  Change Controller: IESG
  o  Specification Document(s): *this document*

  o  Claim Name: Location
  o  Claim Description: The geographic location
  o  JWT Claim Name: "location"
  o  Claim Key: 261
  o  Claim Value Type(s): map
  o  Change Controller: IESG
  o  Specification Document(s): *this document*

  o  Claim Name: Profile
  o  Claim Description: Indicates the EAT profile followed
  o  JWT Claim Name: "eat_profile"
  o  Claim Key: 262
  o  Claim Value Type(s): map
  o  Change Controller: IESG
  o  Specification Document(s): *this document*

  o  Claim Name: Submodules Section
  o  Claim Description: The section containing submodules (not actually a claim)
  o  JWT Claim Name: "submods"
  o  Claim Key: 263
  o  Claim Value Type(s): map
  o  Change Controller: IESG
  o  Specification Document(s): *this document*

---

From: Michael Richardson <[email-masked]>
Date: Sat, 15 Jan 2022 18:14:53 -0500

Laurence Lundblade <[email-masked]> wrote:
    > This email is to solicit comments, particularly from implementers and
    > particularly as to which should be in which range. The ranges are:

    > 1-byte — -24 to 23 2-byte — -256 to 255 excluding the 1-byte range

    > Below is the proposal from the designated expert. Only nonce retains
    > its number and most are in the 3-byte range.

I personally do not feel any pressing reason why 3-byte assignments aren't small enough.

On many 802.15.4 networks, where every byte counts, it is likely that the claims
will be carried within DTLS / CoAP connections, with significant overhead
already.  Plus an EAT CWT signature, etc.
On such networks, where we use use the constrained-RFC8995 (BRSKI) we already
use CoAP block mode for voucher requests and voucher responses.
We plan to convey attestation evidence and responses within that, and I don't
see the difference between 2-byte and 3-byte key values breaking the bank.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 15 Jan 2022 16:32:58 -0800

On Jan 15, 2022, at 3:14 PM, Michael Richardson <[email-masked]> wrote:
> 
> Laurence Lundblade <[email-masked] <mailto:[email-masked]>> wrote:

You’re probably right about that.

My minimum use case would be a “bullet" EAT (small nonce and signature) coming out of a tiny HW block / chip sent over some minimal RF link in a super low-cost use case. About 70 vs 72 bytes, 2% size increase. 

Or take an EAT with 10 claims of each 8 bytes + nonce and signature. About 160 vs 180 bytes, 12% size increase.

This is not just about EAT as a use case, but also OAuth and other CWT use cases (like maybe an X.509 alternate base on CWT). It’s the cross-use case claims that deserve the low numbers the most.

This is basically a reset on claim key numbers including the early allocation so we can pretty much do what ever we want here possibly including expansion of what is submitted for early allocation.

I will make a proposal for all the claim key numbers for all the claims currently in the EAT draft in next day or two.

LL

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 17 Jan 2022 00:56:11 +0100

Hi Laurence & Michael,
hi all,

the experts here are:

> Mike Jones, Hannes Tschofenig, Chuck Mortimore, Ludwig Seitz

The reasoning highlighted for excluding some Claims in the "Standards 
Action" space seems to be... a bit sparse, I think. This is a standards 
action.

My assumption is that EAT - at first glance - exceeds the initial intend 
of CWT. This issue exists because EAT are CWT, but is the "Standards 
Action" scope enough of a reason for dismissal here?

I actually don't know. So, maybe I am just lazy or did not subscribe to 
the correct list, but it might be useful to get more context here. What 
do the designated experts expect here? How general does a Claim has to 
be? In which context, based on which assumptions?

I am not arguing against the decision! I am just not well informed how 
it came to be and I do not know how to change that.

Viele Grüße,

Henk

On 16.01.22 00:14, Michael Richardson wrote:
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 20 Jan 2022 20:56:38 +0000

Based on activity on the list it seems everyone is basically OK with the proposed code point assignments? 
-Ned

On 1/16/22, 3:56 PM, "RATS on behalf of Henk Birkholz" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Laurence & Michael,
    hi all,

    Viele Grüße,

    Henk

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 20 Jan 2022 20:35:33 -0700

> On Jan 20, 2022, at 1:56 PM, Smith, Ned <[email-masked]> wrote:
> 

Here’s what I propose.

This adds early allocation for SUIEIDs,  HW Model and HW Version over and above the previous attempt. I think these are well enough understood and it is nice to have the UEID and SUEID consecutive and to the full triple for HW identification.

Nonce            10
UEID            256
SUEIDs          257
HW OEMID        258
HW Model        259
HW Version      260
Security Level  261
Secure Boot     262
Debug Status    263
Location        264
Profile         265
Submodules      266

These are NOT for early allocation, but want to mention them and their numbers. I could be convinced that intended use and DLOAs are also OK for early allocation, but probably not the SW identification.

Intended Use           TBD267
DLOAs                  TBD268
SW Name                TBD269
SW Version             TBD270
SW Manifests           TBD271 
SW Evidence            TBD280
SW Measurement Results TBD281

LL