Subject: Re: [Rats] Early assignment of EAT claim keys

From: Mike Jones <[email-masked]>
Date: Fri, 14 Jan 2022 19:52:15 +0000

Thanks for writing, Laurence.  I’m trying to assist in my role as designated expert in getting stable claim number assignments as soon as possible.  We can have them within about three weeks.  We would have faced the same issue we’re addressing now whenever the registrations were requested.  I’m glad that we’ve caught the issue with the proposed assignments earlier rather than later, so they can be addressed now.

The context is that some of the proposed claim assignments don’t meet the registration criteria for CWT Claims defined at https://datatracker.ietf.org/doc/html/rfc8392#section-9.1.  In particular:

   Criteria that should be applied by the Designated Experts includes
   determining whether the proposed registration duplicates existing
   functionality, whether it is likely to be of general applicability or
   whether it is useful only for a single application, and whether the
   registration description is clear.  Registrations for the limited set
   of values between -256 and 255 and strings of length 1 are to be
   restricted to claims with general applicability.

In my evaluation, “nonce” is clearly of general applicability and so retained its proposed assignment.  The others seemed likely to be application-specific.

The one additional claim that might be of general applicability is “location”, provided that this is the general-purpose GPS coordinate representation that we expect other applications to use.  But, location representations are large relative to the claim number, since they contain multiple floating point numbers.  Therefore, as a practical consideration, it seemed fine to place it in the >255 range with the others.

I’m open to feedback on the particular judgment calls about which claims are expected to be reused by other unrelated specifications and applications and which are not likely to.  Again, my motivations here are to help you get to stable claim number assignments quickly, as I completely understand the value of having those.

                                                       Best wishes,
                                                       -- Mike

From: RATS <[email-masked]> On Behalf Of Laurence Lundblade
Sent: Friday, January 14, 2022 11:37 AM
To: rats <[email-masked]>; Mike Jones <Michael.Jones=[email-masked]>
Subject: [EXTERNAL] [Rats] Early assignment of EAT claim keys

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*