Subject: Re: [Cwt-reg-review] Registration of Entity Attestation Token claims in the CWT registry

From: Mike Jones <[email-masked]>
Date: Thu, 13 Jan 2022 02:11:07 +0000

Please change the proposed CWT claim values for claims UEID through Submodules Section from 11 through 20 to 41 through 50 so that they are not using up most of the rare single-byte claim numbers.  Only claims that are of general applicability across multiple kinds of applications should be allocated in that space.

The one exception I would consider is the Location claim, which could be of general applicability.  If you believe that this location representation will be used by multiple kinds of applications, I would be willing to consider registering it in the single-byte claim space.

                                                       -- Mike

From: Cwt-reg-review <[email-masked]> On Behalf Of Giridhar Mandyam
Sent: Saturday, October 16, 2021 4:11 PM
To: [email-masked]
Cc: Laurence Lundblade <[email-masked]>
Subject: [Cwt-reg-review] Registration of Entity Attestation Token claims in the CWT registry

To the CWT claims registry designated experts:

I am contacting you on behalf of the editors of the Entity Attestation Token specification (latest draft available at https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-10).  This is a standards-track document in the IETF Remote Attestation Procedures (RATS) Working Group.

Please note the requests for CWT registry of the claims outlined in https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-10#section-7.3.1.  We would like these claim values reflected in the IANA CWT registry as soon as possible.  Would this be possible?

Please contact myself Giri Mandyam or Laurence Lundblade (cc'ed) for further information if required.

Thanks

-Giri Mandyam

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 12 Jan 2022 19:52:25 -0800

+ RATS chairs

Hi Mike,

The claims key numbers 10-18, 20 are early assignments by IANA. I didn’t handle the interaction with IANA, but I understand this to be true.  Changing them now would undermine some implementations that are using them.

LL

> On Jan 12, 2022, at 6:11 PM, Mike Jones <[email-masked]> wrote:
> 
> I am contacting you on behalf of the editors of the Entity Attestation Token specification (latest draft available athttps://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-10 <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-10>).  This is a standards-track document in the IETF Remote Attestation Procedures (RATS) Working Group.
>  
> Please note the requests for CWT registry of the claims outlined in https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-10#section-7.3.1 <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-10#section-7.3.1>.  We would like these claim values reflected in the IANA CWT registry as soon as possible.  Would this be possible?
>  
> Please contact myself Giri Mandyam or Laurence Lundblade (cc’ed) for further information if required. 
>  
> Thanks
>  
> -Giri Mandyam

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 12 Jan 2022 20:18:29 -0800

A couple more comments.

I know what you mean about taking the numbers <24. Not trying to be a hog or anything. It seems nobody, myself included, thought about it when this was done a year ago.

I know that Arm has SW that uses these assignments (ask Hannes and Thomas F). I think FIDO does too. I think there would be objections to a re assignment. 

LL

> On Jan 12, 2022, at 7:52 PM, Laurence Lundblade <[email-masked]> wrote:
> 
> + RATS chairs
> 
> Hi Mike,
> 
>> On Jan 12, 2022, at 6:11 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> From: Cwt-reg-review <[email-masked] <mailto:[email-masked]>> On Behalf Of Giridhar Mandyam
>> To: [email-masked] <mailto:[email-masked]>

---

From: Giridhar Mandyam <[email-masked]>
Date: Thu, 13 Jan 2022 05:05:01 +0000

+ @Jeremy O'Donoghue<mailto:[email-masked]>

Ned, RATS Chairs,

We were assured by the RATS Chairs when we highlighted these values in Rev. -09 that they would be signed off for the registry.  This is one of the reasons why we did not try to accelerate Last Call during the first half of last year.  There was clearly a disconnect.  Can you check into why this occurred?

Mike,

We just put out an FDO update on the assumption that these claim values are set (https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-RD-v1.1-20211214/FIDO-device-onboard-spec-v1.1-rd-20211214.html).  We are planning a 2nd interop event during the next couple of months and we may have to put that off now.  Is this issue intractable?  Can the claims not be assigned to EAT?

Jeremy can comment on any GlobalPlatform dependencies.

-Giri

From: Laurence Lundblade <[email-masked]>
Sent: Wednesday, January 12, 2022 8:18 PM
To: Mike Jones <[email-masked]>
Cc: Giridhar Mandyam <[email-masked]>; [email-masked]; Smith, Ned <[email-masked]>; Nancy Cam-Winget (ncamwing) <[email-masked]>; Kathleen Moriarty <[email-masked]>
Subject: Re: Registration of Entity Attestation Token claims in the CWT registry

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
A couple more comments.

LL

On Jan 12, 2022, at 7:52 PM, Laurence Lundblade <[email-masked]<mailto:[email-masked]>> wrote:

+ RATS chairs

Hi Mike,

LL

On Jan 12, 2022, at 6:11 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

                                                       -- Mike

From: Cwt-reg-review <[email-masked]<mailto:[email-masked]>> On Behalf Of Giridhar Mandyam
Sent: Saturday, October 16, 2021 4:11 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Subject: [Cwt-reg-review] Registration of Entity Attestation Token claims in the CWT registry

I am contacting you on behalf of the editors of the Entity Attestation Token specification (latest draft available athttps://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-10).  This is a standards-track document in the IETF Remote Attestation Procedures (RATS) Working Group.

Thanks

-Giri Mandyam

Subject: Re: Attention Ned (was [Rats] IANA pre-RFC code points)
From: "Smith, Ned" <[email-masked]>
To: Laurence Lundblade <[email-masked]>
Cc: Giridhar Mandyam <[email-masked]>, Thomas Fossati <[email-masked]>
Date: Mon, 1 Mar 2021 17:21:18 +0000

CAUTION: This email originated from outside of the organization.

Thanks Laurence!

The -09 draft is sufficient for the list and area directors to identify pre-assignment requests.

From: Laurence Lundblade <[email-masked]>
Date: Saturday, February 27, 2021 at 8:31 PM
To: "Smith, Ned" <[email-masked]>
Cc: Giridhar Mandyam <[email-masked]>, Thomas Fossati <[email-masked]>
Subject: Attention Ned (was [Rats] IANA pre-RFC code points)

Ned, wanted to make sure you saw this. The next step is up to you.

LL

   Begin forwarded message:

   From: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>

   Subject: Re: [Rats] IANA pre-RFC code points

   Date: February 27, 2021 at 9:29:15 PM GMT-7

   To: "Smith, Ned" <[email-masked]<mailto:[email-masked]>>

   Cc: Henk Birkholz <[email-masked]<mailto:[email-masked]>>, Thomas Fossati <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Simon Frost <[email-masked]<mailto:[email-masked]>>, Adrian Shaw <[email-masked]<mailto:[email-masked]>>, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>

   OK. There’s a PR for OIDs and URIs now. It also does pre-assignment for the profile claim so it can be included.

   Ned, please advice on next step here.
   - Is Profile stable enough for reassignment?
   - If so, do we have to issue an -09 draft?

   Please, no more request for claims for pre-assignment so we can get this done.

   LL

      On Feb 17, 2021, at 3:06 AM, Henk Birkholz <[email-masked]<mailto:[email-masked]>> wrote:

      + 1 to:

      * oids as a preferred choice (uri are fine but alas not very concise)
      * avoiding unstructured text (and inheriting that weirdness here)
      * avoiding more registries (not only because of more delay)

      On 17.02.21 10:55, Thomas Fossati wrote:

         Hi Laurence,
         On 17/02/2021, 00:59, "Laurence Lundblade" <[email-masked]<mailto:[email-masked]>> wrote:

               On Feb 16, 2021, at 5:44 PM, Thomas Fossati <[email-masked]<mailto:[email-masked]>> wrote:

               On 16/02/2021, 20:25, "Laurence Lundblade" <[email-masked]<mailto:[email-masked]>> wrote:

                  Below...

                     On Feb 16, 2021, at 11:10 AM, <[email-masked]<mailto:[email-masked]>> wrote:

                     On 16/02/2021, 17:43, <[email-masked]<mailto:[email-masked]>> wrote:

                        If we can agree that profiles are necessary and that a simple
                        text string is good enough to name a profile, then we can put in
                        in the pre-allocation.  We don't have to agree on the mechanism
                        for defining profiles, just for naming them.

                     I think what is in -08 in terms of defining a profile is great.

                     I think we should just nail down the type and constraints around
                     the claim value.  The way it is now (i.e., plain, unstructured
                     tstr) creates an incentive to using short strings and therefore
                     increasing the chance of collisions, which is bad.

                     If we say:
                     ~~~
                     profile-claim = ( profile => $profile-type,)

                     $profile-type /= uri ; i.e., #6.32(tstr)
                     $profile-type /= oid ; draft-ietf-cbor-tags-oid
                     ~~~

                     We'd allow both human readable https://fidoalliance.org/profile/a,
                     as well as compact, machine readable 1.3.6.1.4.1.etc in a way that
                     prevents clashes.

                     I don't think it's crazy to expect the profile owner to also
                     control a DNS name and/or a PEN.

                  Yes, I was thinking we might want this to be a URI or such myself.
                  Here’s several options:

                  1) Make it string-or-uri like the JWT issuer, subject and audience
                    claims. Already well-established approach.

                  2) Allow string, URI or OID. Most flexibility, but do we really
                    need OIDs?

               I like OIDs because they are relatively compact and unambiguous.
               They look like the CBOR-friendly equivalent of URIs.  They also
               render well in JSON as strings in dotted notation.

            I think a good very compact CBOR-friendly way would be to use a simple
            integer in some way.

            One way to do that is to make an IANA registry for profiles with each
            entry:
             - integer
             - name
             - URI

         Yes, but we'd need another registry.  Going with URIs and OIDs (PENs)
         would avoid the extra IANA round-trip.

            The profile claim in a token could be solely the integer value. Or it
            could be the URI or the text string.

            I'd prefer that to more use of OIDs.

         I am not married to any particular format, I am looking for one that can
         effectively balance:
         * compactness of representation
         * minimal IANA impact
         * collision avoidance of the identifiers

            The policy for the registry would be pretty loose. Just indicate the
            existence of some document somewhere. Maybe reserve the values less
            than 24 for profiles documents that are standards.

            This seems pretty good to me, but I'm a bit worried about delaying the
            pre-allocation for it since it involves creating another IANA
            registry.

         yep
         cheers, t
         IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
         _______________________________________________
         RATS mailing list
         [email-masked]<mailto:[email-masked]>
         https://www.ietf.org/mailman/listinfo/rats

   _______________________________________________
   RATS mailing list
   [email-masked]<mailto:[email-masked]>
   https://www.ietf.org/mailman/listinfo/rats

---

From: Mike Jones <[email-masked]>
Date: Thu, 13 Jan 2022 05:58:14 +0000

Yours is not the first specification that’s tried to preallocate the rare single-byte claim numbers for claims not of general applicability.  At https://www.iana.org/assignments/cwt/cwt.xhtml, you’ll note that most of the claims allocated by draft-ietf-ace-oauth-authz are in the double-byte space because they’re not applicable to a wide variety of applications.  They were originally requested to be in the single-byte range and the designated experts negotiated with the editors to move their requested assignments.

Jim Schaad was always a stickler about specifications using TBD in their registration requests instead of assumed numbers.  At most, he would tolerate “TBD (requested assignment NNN)”.  Of course, he was right.  It’s up to IANA and the designated experts to make the assignments, particular of scarce resources, not the spec authors.

Therefore, please revise your specification to remove the current numbers and replace them with “TBD”.  At that point, it would be fine to make an early registration request.  The experts and IANA could likely get you permanent numbers at that point, probably within a matter of weeks.

If you do not want to go the early allocation route, the other option is to use numbers in the “less than -65536” space, which are designated as “Reserved for Private Use”.  You can use numbers in that space however you want for as long as you want – including for facilitating interop testing until permanent numbers are assigned.

I’m sorry this appears to have come as a surprise.  The designated experts are trying to ensure that the CWT Claims numbers are efficiently allocated to do the most good for the most applications.  I hope you’ll take this request in that spirit and choose one of the paths outlined above to quickly resolve this issue.

                                                       Best wishes,
                                                       -- Mike

From: Giridhar Mandyam <[email-masked]>
Sent: Wednesday, January 12, 2022 9:05 PM
To: Laurence Lundblade <[email-masked]>; Mike Jones <[email-masked]>; Jeremy O'Donoghue <[email-masked]>
Cc: [email-masked]; Ned Smith <[email-masked]>; Nancy Cam-Winget (ncamwing) <[email-masked]>; Kathleen Moriarty <[email-masked]>; rats-chairs <[email-masked]>
Subject: [EXTERNAL] RE: Registration of Entity Attestation Token claims in the CWT registry

Ned, RATS Chairs,

Mike,

-Giri

From: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, January 12, 2022 8:18 PM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>
Cc: Giridhar Mandyam <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Smith, Ned <[email-masked]<mailto:[email-masked]>>; Nancy Cam-Winget (ncamwing) <[email-masked]<mailto:[email-masked]>>; Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>
Subject: Re: Registration of Entity Attestation Token claims in the CWT registry

LL

+ RATS chairs

Hi Mike,

LL

                                                       -- Mike

Thanks

-Giri Mandyam

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 12 Jan 2022 22:31:22 -0800

Hi Mike,

I’m not trying grab anything here that we should not have.

The early allocation process, according to RFC 7120, is handled by the WG chairs. It is my understanding is that the RATS chairs followed this process and that number 10-18, 20 have early assignment. That’s why they are in the draft without “TBD”. Maybe the process wasn’t completed or there is some other confusion. I did not interact with IANA myself (but I did read 7120).

I think this needs to be resolved between the RATS chairs, designated experts and IANA. I am happy to adjust the draft when this gets resolved.

LL

> On Jan 12, 2022, at 9:58 PM, Mike Jones <[email-masked]> wrote:
> 
> Yours is not the first specification that’s tried to preallocate the rare single-byte claim numbers for claims not of general applicability.  At https://www.iana.org/assignments/cwt/cwt.xhtml <https://www.iana.org/assignments/cwt/cwt.xhtml>, you’ll note that most of the claims allocated by draft-ietf-ace-oauth-authz are in the double-byte space because they’re not applicable to a wide variety of applications.  They were originally requested to be in the single-byte range and the designated experts negotiated with the editors to move their requested assignments.
>  
> + @Jeremy O'Donoghue <mailto:[email-masked]>
>  
> Ned, RATS Chairs,
>  
> We just put out an FDO update on the assumption that these claim values are set (https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-RD-v1.1-20211214/FIDO-device-onboard-spec-v1.1-rd-20211214.html <https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-RD-v1.1-20211214/FIDO-device-onboard-spec-v1.1-rd-20211214.html>).  We are planning a 2nd interop event during the next couple of months and we may have to put that off now.  Is this issue intractable?  Can the claims not be assigned to EAT?
>  
> From: Laurence Lundblade <[email-masked] <mailto:[email-masked]>> 
> To: Mike Jones <[email-masked] <mailto:[email-masked]>>
> Cc: Giridhar Mandyam <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Smith, Ned <[email-masked] <mailto:[email-masked]>>; Nancy Cam-Winget (ncamwing) <[email-masked] <mailto:[email-masked]>>; Kathleen Moriarty <[email-masked] <mailto:[email-masked]>>
> On Jan 12, 2022, at 7:52 PM, Laurence Lundblade <[email-masked] <mailto:[email-masked]>> wrote:
>  
> + RATS chairs
>  
> Hi Mike, 
>  
> Cc: Laurence Lundblade <[email-masked] <mailto:[email-masked]>>

---

From: Mike Jones <[email-masked]>
Date: Thu, 13 Jan 2022 10:38:48 +0000

Early allocation did not occur.  If it had, the numbers would be assigned in https://www.iana.org/assignments/cwt/cwt.xhtml.  (For an example of early allocation listings, see claims 38, 39, and 40.)  Early registration, like normal registration, involves review by the designated experts, which also didn’t occur, because as far as I can tell, it wasn’t asked for.

I’m trying to help you get to stable assignments as soon as possible.  I know the value of having those.

Again, if you want stable assignments before upcoming interop events, I’d suggest making an early registration request by sending the registration request to [email-masked]<mailto:[email-masked]>.  It would be cleaner to do so by first changing the assignments in your IANA Considerations section to “TBD”, but you could also do so based on the current draft (realizing that the proposed assignments in the draft might not be the ones assigned by the designated experts and IANA).

You could have stable assignments within a few weeks if you choose to request them soon.

                                                       Best wishes,
                                                       -- Mike

From: Laurence Lundblade <[email-masked]>
Sent: Wednesday, January 12, 2022 10:31 PM
To: Mike Jones <[email-masked]>
Cc: Giridhar Mandyam <[email-masked]>; Jeremy O'Donoghue <[email-masked]>; [email-masked]; Ned Smith <[email-masked]>; Nancy Cam-Winget (ncamwing) <[email-masked]>; Kathleen Moriarty <[email-masked]>; rats-chairs <[email-masked]>
Subject: [EXTERNAL] Re: Registration of Entity Attestation Token claims in the CWT registry

Hi Mike,

LL

On Jan 12, 2022, at 9:58 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

                                                       Best wishes,
                                                       -- Mike

From: Giridhar Mandyam <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, January 12, 2022 9:05 PM
To: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>; Mike Jones <[email-masked]<mailto:[email-masked]>>; Jeremy O'Donoghue <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Ned Smith <[email-masked]<mailto:[email-masked]>>; Nancy Cam-Winget (ncamwing) <[email-masked]<mailto:[email-masked]>>; Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>; rats-chairs <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] RE: Registration of Entity Attestation Token claims in the CWT registry

Ned, RATS Chairs,

Mike,

-Giri

LL

+ RATS chairs

Hi Mike,

LL

                                                       -- Mike

Thanks

-Giri Mandyam

---

From: Giridhar Mandyam <[email-masked]>
Date: Thu, 13 Jan 2022 15:35:21 +0000

+ Roman D.

I would like to escalate this to the AD.  Note that the EAT editors acted in good faith in the expectation that the RATS  chairs would address early allocation, and we were assured last March that there was no issues with the requested values.  As a result, we put off Last Call for the draft and went forward with guidance to other SDO’s (e.g. FIDO Alliance, GlobalPlatform) that these claim values were stable.

Now for the first time we are finding out that (a) the values called out in the spec are not acceptable as per expert review criteria, and (b) the RATS chairs never initiated the process of pre-registration in the first place.

My request to the AD is simple:  allow for pre-registration of the values as called out in the current EAT draft.  If this is not possible (and it looks likely that it is not), then my additional request is that the AD directly manage shepherding of this spec to Last Call and RFC as I believe communication between the EAT editors and the RATS Chairs has broken down and the RATS Chairs are not driving consensus decisions from the Working Group with respect to this spec.

-Giri

From: Mike Jones <[email-masked]>
Sent: Thursday, January 13, 2022 2:39 AM
To: Laurence Lundblade <[email-masked]>
Cc: Giridhar Mandyam <[email-masked]>; Jeremy O'Donoghue <[email-masked]>; [email-masked]; Ned Smith <[email-masked]>; Nancy Cam-Winget (ncamwing) <[email-masked]>; Kathleen Moriarty <[email-masked]>; rats-chairs <[email-masked]>
Subject: RE: [EXTERNAL] Re: Registration of Entity Attestation Token claims in the CWT registry

                                                       Best wishes,
                                                       -- Mike

Cc: Giridhar Mandyam <[email-masked]<mailto:[email-masked]>>; Jeremy O'Donoghue <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Ned Smith <[email-masked]<mailto:[email-masked]>>; Nancy Cam-Winget (ncamwing) <[email-masked]<mailto:[email-masked]>>; Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>; rats-chairs <[email-masked]<mailto:[email-masked]>>

Hi Mike,

LL

                                                       Best wishes,
                                                       -- Mike

Ned, RATS Chairs,

Mike,

-Giri

LL

+ RATS chairs

Hi Mike,

LL

                                                       -- Mike

Thanks

-Giri Mandyam

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 13 Jan 2022 16:37:42 +0000

Hi all!

I wanted to acknowledge that I got this note, but I am not up-to-speed on the issue and need to catch-up before providing a meaningful response.  A search of my mailbox also found this related thread which I attached.

Roman

From: Giridhar Mandyam <[email-masked]>
Sent: Thursday, January 13, 2022 10:35 AM
To: Mike Jones <[email-masked]>; Laurence Lundblade <[email-masked]>; Roman Danyliw <[email-masked]>
Cc: Jeremy O'Donoghue <[email-masked]>; [email-masked]; Ned Smith <[email-masked]>; Nancy Cam-Winget (ncamwing) <[email-masked]>; Kathleen Moriarty <[email-masked]>; rats-chairs <[email-masked]>
Subject: RE: [EXTERNAL] Re: Registration of Entity Attestation Token claims in the CWT registry

+ Roman D.

-Giri

From: Mike Jones <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, January 13, 2022 2:39 AM
To: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Cc: Giridhar Mandyam <[email-masked]<mailto:[email-masked]>>; Jeremy O'Donoghue <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Ned Smith <[email-masked]<mailto:[email-masked]>>; Nancy Cam-Winget (ncamwing) <[email-masked]<mailto:[email-masked]>>; Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>; rats-chairs <[email-masked]<mailto:[email-masked]>>
Subject: RE: [EXTERNAL] Re: Registration of Entity Attestation Token claims in the CWT registry

                                                       Best wishes,
                                                       -- Mike

Hi Mike,

LL

                                                       Best wishes,
                                                       -- Mike

Ned, RATS Chairs,

Mike,

-Giri

LL

+ RATS chairs

Hi Mike,

LL

                                                       -- Mike

Thanks

-Giri Mandyam

Subject: Re: RATS CHAIRS PLEASE RESPOND -- IANA Early Allocation of Claim Keys
From: Laurence Lundblade <[email-masked]>
To: "Smith, Ned" <[email-masked]>
Cc: "Nancy Cam-Winget (ncamwing)" <[email-masked]>, Kathleen Moriarty <[email-masked]>, rats-chairs <[email-masked]>, Giridhar Mandyam <[email-masked]>, Roman Danyliw <[email-masked]>
Date: Thu, 21 Jan 2021 19:56:01 +0000

Hi Ned,

I believe I’ve addressed what you’ve requested. It’s checked in to the GitHub in this PR and I’ve made a PDF of it and attached it.

The descriptions of the claims for early assignment are in the -06 draft. There has been no change to these claims since it was published. The only thing new for these claims is the claim keys and the proposal for early assignment.

Note that the nonce is already registered for JWT, but not CWT. I’ve clarified that in the update.

Note also that this PR is against the current master which is a few pull requests (not related to the claims) ahead of the -06 draft.

LL

   On Jan 19, 2021, at 3:08 PM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

   Laurance,
   Would it be possible to create a sub section in section 7.3 with the section heading “RFC Required” that includes only the code points that are to be allocated by IANA in advance of the draft completion?

   We will want to pay close attention to this section in terms of RFC changes that impact interoperability. Hence, having that section clearly identified is important.

   Also, please identify the actual values to be reserved by IANA registries without descriptive text preceding the expected text. For example (JWT Claim Name: Value requested is "ueid") can remove the text “Value requested is” can be removed.

   In case of the nonce claim, the request indicates the nonce claim is already made but an entry exists nevertheless. Possibly this doesn’t belong in the section titled “RFC Required” or if there is name collision but different semantics, possibly a different claim name should be used (aka rats-nonce)?

   Additionally, since section 7.2 indicates claims appear to be from within either or both JWT and CWT namespaces. It may be best to create separate sub-sections for both CWT and JWT namespace reservations (or something equivalent) that clearly indicates which value constitutes the allocation from which namespace.

   Finally, in order for the chairs to assess spec stability across the WG, it makes sense to generate a new editor’s copy (or working draft) that can be reviewed by other WG members easily – specifically related to the Section 7.3 … “RFC Required” sub-section.

   Thanks,
   Ned

   From: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
   Date: Saturday, January 16, 2021 at 1:54 PM
   To: Nancy Cam-Winget <[email-masked]<mailto:[email-masked]>>
   Cc: Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>, "Smith, Ned" <[email-masked]<mailto:[email-masked]>>, rats-chairs <[email-masked]<mailto:[email-masked]>>, Giridhar Mandyam <[email-masked]<mailto:[email-masked]>>
   Subject: Re: RATS CHAIRS PLEASE RESPOND -- IANA Early Allocation of Claim Keys

   I’ve got a pull request <https://github.com/ietf-rats-wg/eat/pull/90> ready now with the preassigned values added to the IANA section. We can merge it and publish a new draft if that will help.

   Do you mind if I contact Roman on this directly to get this moving?

   Thanks

   LL

      On Jan 10, 2021, at 2:10 PM, Nancy Cam-Winget (ncamwing) <[email-masked]<mailto:[email-masked]>> wrote:

      Hi Laurence,
      I need to catch up on the latest EAT draft, but I don’t recall these being placed in the IANA request section of the draft?  I think we’ll need to have some reference to these and mark the request as TBD (not sure if you want the specific values you list below but those will need to be requested nonetheless).  I need to took at the latest EAT draft version as well as the CWT procedures as we likely need to cross that request with the ACE (and maybe COSE?) wgs….

      I’ve got some higher priority items to do at work this week, but will try to get to this in the next few days….unless the other co-chairs can help too.

      Best, Nancy

      From: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
      Date: Saturday, January 9, 2021 at 11:28 AM
      To: ncamwing <[email-masked]<mailto:[email-masked]>>, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>, "Smith, Ned" <[email-masked]<mailto:[email-masked]>>
      Cc: rats-chairs <[email-masked]<mailto:[email-masked]>>
      Subject: RATS CHAIRS PLEASE RESPOND -- IANA Early Allocation of Claim Keys
      Resent-From: <[email-masked]<mailto:[email-masked]>>
      Resent-To: ncamwing <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
      Resent-Date: Saturday, January 9, 2021 at 11:28 AM

      Hi Chairs,

      Sorry for the all-caps. Don’t mean to shout. Just wanted to make sure you see this as we haven’t heard a response from you after several requests (maybe the emails are getting lost?)

      There are several companies and groups (Google, ARM, FIDO and GP) working on EAT implementations. Early allocation of claim keys would be very beneficial.

      As I say below, the RFC 7120 procedure is for the WG chairs to take the next step of forwarding the request to the AD.

      I don’t mean to make a fuss, but If I don’t hear from you soon, I will contact Roman myself to try to move this forward.

      Thanks, LL

         Begin forwarded message:

         From: Giridhar Mandyam <[email-masked]<mailto:[email-masked]>>
         Subject: RE: [Rats] challenges of building dependant specifications against Internet-Drafts -- a way forward for EAT
         Date: December 18, 2020 at 1:28:41 PM PST
         To: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>, rats-chairs <[email-masked]<mailto:[email-masked]>>
         Cc: Bram Bonné <[email-masked]<mailto:[email-masked]>>

         Hi Chairs,

         Can we get guidance on the way forward?

         FIDO, GP, ARM and Google all have dependencies.

         -Giri

         From: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
         Sent: Monday, December 14, 2020 11:17 AM
         To: rats-chairs <[email-masked]<mailto:[email-masked]>>
         Cc: Giridhar Mandyam <[email-masked]<mailto:[email-masked]>>; Bram Bonné <[email-masked]<mailto:[email-masked]>>
         Subject: Fwd: [Rats] challenges of building dependant specifications against Internet-Drafts -- a way forward for EAT

         CAUTION: This email originated from outside of the organization.
         Hi WG chairs, according to RFC 7120<https://tools.ietf.org/html/rfc7120#section-3>, the ball is in your court on this.  It’s up to you to make the call that we have consensus and forward to the AD for the next step.

         It looks to me like we have consensus. Qualcomm/FIDO, ARM and the primary authors have affirmed and there are no objections.

         It would be nice to push this quickly because of Google’s implementation which is on a short time line.

         Can you take the next step and forward it to the AD? I am also happy to do that myself if you want, but I think you would have to at least give a nod to the AD that you are OK with this.

         Thanks,

         LL

            Begin forwarded message:

            From: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
            Subject: Re: [Rats] challenges of building dependant specifications against Internet-Drafts -- a way forward for EAT
            Date: December 4, 2020 at 11:57:02 AM PST
            To: Michael Richardson <[email-masked]<mailto:[email-masked]>>, "Nancy Cam-Winget (ncamwing)" <ncamwing=[email-masked]<mailto:ncamwing=[email-masked]>>, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>, "Smith, Ned" <[email-masked]<mailto:[email-masked]>>
            Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

            So I read RFC 7120 which is super clear and exactly what is needed. It lines up with my third proposal. We will ask IANA to pre-register claims in the Standards Action space of the CWT registry and also in the JWT registry. Or rather per the 7120, the WG chairs determine consensus here, then will ask the AD(s) and then ask IANA.

            Is there consensus on pre-registration of these?

            Name      Description         CWT     JWT                     Type
            nonce     Nonce               10      <already registered>    byte string
            ueid      Universal Entity ID 11      ueid                    byte string
            oemid     OEM ID              13      oemid                   byte string
            seclevel  Security Level      14      seclevel                integer
            secboot   Secure boot         15      secboot                 integer
            dbgstat   Debug status        16      dbgstat                 integer
            location  Location            17      location                map
            submods   Submodules Section  20      submods                 map

            These have all been in the EAT document for a long time and are described well in draft-ietf-rats-eat-06. They are fairly well understood and have either no open issues or only small open issues in GitHub against them. They include the most essential claims (nonce, ueid, oemid & submods) to implement an EAT.

            I have chosen not to ask for the others because I don’t think they are as essential or as well understood yet and thus don’t meet the criteria in RFC 7120.

            CWT numbers aren’t contiguous so as to line up with examples that have been in the EAT draft for a while. I’ve shortened the JWT claims keys to less than 8 per RFC 7519.

            If approved and registered, we’ll quickly publish a new EAT draft.

            LL

               On Nov 30, 2020, at 3:16 PM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

               Laurence Lundblade <[email-masked]<mailto:[email-masked]>> wrote:

                  The trouble is that I think many claims should be in the Standards
                  Action range (-255 to 255).  For example, nonce, ueid, submods section,
                  location, CoSWID and probably a few others should be in the standard
                  space. If I were IANA I would hesitate to register these in the
                  Standards Action range until the EAT document is further along.

               The WG can ask for Early Allocation.
               It should do it immediately, so that the Expert will provided feedback immediately.

                  It also seems poor practice to unilaterally pre-assign Standards Action
                  range claims in an EAT draft and then use them in a bunch of
                  implementations. Those numbers could be assigned to some one else
                  before EAT is an RFC.

               You can do that if a registry you are just creating.
               But, yes, you can't do that if you are using CWT.

                  Register them in the Specification Required space (255 to 65535) once
                  and for all. That will result in 3-byte map labels rather than 1-byte
                  map labels, but there’s no transition.

                  Finally, a third proposal:

                  Maybe we can convince IANA to pre-register a small clear set in the
                  standard space? Perhaps just nonce and UEID.

               Please go read RFC7120.

               --
               ]               Never tell me the odds!                 | ipv6 mesh networks [
               ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
               ]     [email-masked]<mailto:[email-masked]>  http://www.sandelman.ca/        |   ruby on rails    [