Subject: [Rats] Timeline for EAT early assignment code points by IANA

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

Given the mailing list doesn’t identify any issues related early registration of EAT values.  The timeline for publication is Friday, February 4, 2022 (which accounts for a three-week review period specified by RFC 8392).
Thx,
Ned

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 22 Jan 2022 14:32:48 -0700

I’ve made a PR against the EAT draft <https://github.com/ietf-rats-wg/eat/pull/152/files> with the Claim Key assignments for CBOR (IANA section, CDDL, examples, all validating as consistent).

Here’s the CDDL for label assignments:

nonce-label = 10
ueid-label = 256
sueids-label = 257
oemid-label = 258
hardware-model-label = 259
hardware-version-label = 260
security-level-label = 261
secure-boot-label = 262
debug-status-label = 263
location-label = 264
profile-label = 265
submods-label = 266

uptime-label = <TBD267>
boot-seed-label = <TB268>
intended-use-label = <TBD269>
dloas-label = <TBD270>
sw-name-label = <TBD271>
sw-version-label = <TBD272>
manifests-label = <TBD273>
swevidence-label = <TBD274>
swresults-label = <TBD275>

This is a little different than what Mike proposed and what Ned assumed was agreed upon. 

Please let us make sure we’re all agreed on this before sending to IANA. There’s no big rush here. It is more important to get it right.

LL

> On Jan 20, 2022, at 2:47 PM, Smith, Ned <[email-masked]> wrote:
> 
> _______________________________________________
> RATS mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 24 Jan 2022 14:11:49 +0000

A comment on the overall "Security Level Claim".  The overall intent of claim is about the signing key protection countermeasures.   A term like "security-level" and "security-level-label" seem overly generic for this task, considering everything we are doing is about security.   What about a more descriptive claim name like "signing-key-protection"?

Note: I do recognize the term has been in EAT since the first adopted WG draft.  So I am not pushing strongly here, I just am looking for thoughts.

Eric

From: RATS <[email-masked]> On Behalf Of Laurence Lundblade
Sent: Saturday, January 22, 2022 4:33 PM
To: Smith, Ned <[email-masked]>
Cc: rats <[email-masked]>
Subject: Re: [Rats] Timeline for EAT early assignment code points by IANA

nonce-label = 10

ueid-label = 256

sueids-label = 257

oemid-label = 258

secure-boot-label = 262

debug-status-label = 263

location-label = 264

profile-label = 265

submods-label = 266

uptime-label = <TBD267>

dloas-label = <TBD270>

sw-name-label = <TBD271>

LL

On Jan 20, 2022, at 2:47 PM, Smith, Ned <[email-masked] <mailto:[email-masked]> > wrote:

Thx,

Ned

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

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 25 Jan 2022 10:47:44 -0800

(forking the discussion since this is security-level semantics, not early assignment)

> On Jan 24, 2022, at 6:11 AM, Eric Voit (evoit) <[email-masked]> wrote:
> 
> A comment on the overall "Security Level Claim".  The overall intent of claim is about the signing key protection countermeasures.   A term like "security-level" and "security-level-label" seem overly generic for this task, considering everything we are doing is about security.   What about a more descriptive claim name like "signing-key-protection”?

It’s not just about signing key protection. Here’s some of the description:

This claim characterizes the entity's ability to defend against attacks aimed at capturing the signing key, forging claims and at forging EATs. 

For many implementations this is the security level of the Attesting Environment so it covers collecting the claims and such.

LL

> On Jan 20, 2022, at 2:47 PM, Smith, Ned <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 27 Jan 2022 10:05:15 -0800

Hi folks,

If there are no objections to this by the end of the week, I’m going to push it through with IANA.

The difference between this and what Mike proposed is that it includes three more claims for early allocation:

sueids-label = 257

I’ve picked these because they fill out the UEIDs group of claims and the HW Identification group of claims (OEM, Model, Version) and allow the numbering to be conveniently sequential.

LL

> On Jan 22, 2022, at 1:32 PM, Laurence Lundblade <[email-masked]> wrote:
> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 27 Jan 2022 21:41:27 +0000

Only open question I have is on "security-level-label".   Let's work that on the parallel thread so we don't partition/duplicate the discussion.

Eric

From: Laurence Lundblade, January 27, 2022 1:05 PM

Hi folks,

sueids-label = 257

LL

On Jan 22, 2022, at 1:32 PM, Laurence Lundblade <[email-masked] <mailto:[email-masked]> > wrote:

nonce-label = 10

ueid-label = 256

sueids-label = 257

oemid-label = 258

secure-boot-label = 262

debug-status-label = 263

location-label = 264

profile-label = 265

submods-label = 266

uptime-label = <TBD267>

dloas-label = <TBD270>

sw-name-label = <TBD271>

LL

Thx,

Ned

---

From: Giridhar Mandyam <[email-masked]>
Date: Fri, 28 Jan 2022 00:05:46 +0000

I assume an ‘open question’ is not an objection.

Security Level was designated for early assignment in draft -09, which was also the draft that encompassed all claims that were agreed upon by the group for early assignment.  If the Chairs and AD had completed the process of requesting early assignment a year ago as they were supposed to do, then we would have had those values reflected in the IANA registry and we wouldn’t even be discussing them at such a late stage.

I don’t think we should derail the early assignment of claim values based on any other side discussions.

-Giri

From: RATS <[email-masked]> On Behalf Of Eric Voit (evoit)
Sent: Thursday, January 27, 2022 1:41 PM
To: Laurence Lundblade <[email-masked]>; Smith, Ned <[email-masked]>
Cc: rats <[email-masked]>
Subject: Re: [Rats] Timeline for EAT early assignment code points by IANA

Eric

sueids-label = 257

LL

On Jan 22, 2022, at 1:32 PM, Laurence Lundblade <[email-masked]<mailto:[email-masked]>> wrote:

I’ve made a PR against the EAT draft<https://github.com/ietf-rats-wg/eat/pull/152/files> with the Claim Key assignments for CBOR (IANA section, CDDL, examples, all validating as consistent).

nonce-label = 10
ueid-label = 256
sueids-label = 257
oemid-label = 258

uptime-label = <TBD267>

LL

On Jan 20, 2022, at 2:47 PM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

_______________________________________________
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: Henk Birkholz <[email-masked]>
Date: Fri, 28 Jan 2022 01:17:11 +0100

Hi Giri,

okay, well... that reads wrong to me. Work happened in the time that 
passed. Things evolved, we all now know more than a year before. There 
seems to be semantic conflict now between the concepts Eric highlighted 
and the concepts reflected in the "security level" Claim.

While I can understand and share the frustration - this is how it is 
now. I've been following this discussion very carefully and to be 
honest, Eric does have a point.

Additionally, whatever the resolution might be, I disagree with the 
"derailing" statement and find it... non-applicable.

As these are just observations and not a proposal towards a resolution: 
why not just qualify the Claim name with an appropriate prefix. It will 
be an integer "on the wire" with CBOR anyways.

Viele Grüße,

Henk

On 28.01.22 01:05, Giridhar Mandyam wrote:
> Security Level was designated for early assignment in draft -09, which 
> was also the draft that encompassed all claims that were agreed upon by 
> the group for early assignment.  If the Chairs and AD had completed the 
> process of requesting early assignment a year ago as they were supposed 
> to do, then we would have had those values reflected in the IANA 
> registry and we wouldn’t even be discussing them at such a late stage.
> 
> *From:* RATS <[email-masked]> *On Behalf Of * Eric Voit (evoit)
> *Sent:* Thursday, January 27, 2022 1:41 PM
> *To:* Laurence Lundblade <[email-masked]>; Smith, Ned 
> <[email-masked]>
> *Cc:* rats <[email-masked]>
> *Subject:* Re: [Rats] Timeline for EAT early assignment code points by IANA
> 
> Only open question I have is on "security-level-label".   Let's work 
> that on the parallel thread so we don't partition/duplicate the discussion.
> 
> 
> Eric
> 
> *From:* Laurence Lundblade, January 27, 2022 1:05 PM
> 
> Hi folks,
> 
> I’ve picked these because they fill out the UEIDs group of claims and 
> the HW Identification group of claims (OEM, Model, Version) and allow 
> the numbering to be conveniently sequential.
> 
> LL
> 
>     On Jan 22, 2022, at 1:32 PM, Laurence Lundblade
>     <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     I’ve made a PR against the EAT draft
>     <https://github.com/ietf-rats-wg/eat/pull/152/files> with the Claim
>     Key assignments for CBOR (IANA section, CDDL, examples, all
>     validating as consistent).
> 
>     Please let us make sure we’re all agreed on this before sending to
>     IANA. There’s no big rush here. It is more important to get it right.
> 
>     LL
> 
>         Given the mailing list doesn’t identify any issues related early
>         registration of EAT values.  The timeline for publication is
>         Friday, February 4, 2022 (which accounts for a three-week review
>         period specified by RFC 8392).
> 
>         Thx,
> 
>         Ned
> 
>         <https://www.ietf.org/mailman/listinfo/rats>
> 
>     <https://www.ietf.org/mailman/listinfo/rats>
> 
>

---

From: Giridhar Mandyam <[email-masked]>
Date: Fri, 28 Jan 2022 00:33:22 +0000

As I mentioned below - the early assignment of claim values was a reflection of what was group consensus at the time.  The fact that the Chairs did not execute in a timely manner is no reason to derail (yes - I will use that word again) a straightforward procedure that should have completed a year ago.

> While I can understand and share the frustration - this is how it is now. I've been following this discussion very carefully and to be honest, Eric does have a point.

Thank you for your opinion.  I happen to disagree.

I would expect the RATS Chairs to chime in now and reset this discussion, but maybe that is just too large an ask.  

-Giri

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Henk Birkholz
Sent: Thursday, January 27, 2022 4:17 PM
To: Giridhar Mandyam <[email-masked]>; Eric Voit (evoit) <evoit=[email-masked]>; Laurence Lundblade <[email-masked]>; Smith, Ned <[email-masked]>
Cc: rats <[email-masked]>
Subject: Re: [Rats] Timeline for EAT early assignment code points by IANA

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

Hi Giri,

okay, well... that reads wrong to me. Work happened in the time that passed. Things evolved, we all now know more than a year before. There seems to be semantic conflict now between the concepts Eric highlighted and the concepts reflected in the "security level" Claim.

While I can understand and share the frustration - this is how it is now. I've been following this discussion very carefully and to be honest, Eric does have a point.

Additionally, whatever the resolution might be, I disagree with the "derailing" statement and find it... non-applicable.

As these are just observations and not a proposal towards a resolution:
why not just qualify the Claim name with an appropriate prefix. It will be an integer "on the wire" with CBOR anyways.

Viele Grüße,

Henk

On 28.01.22 01:05, Giridhar Mandyam wrote:
> was also the draft that encompassed all claims that were agreed upon 
> by the group for early assignment.  If the Chairs and AD had completed 
> the process of requesting early assignment a year ago as they were 
> supposed to do, then we would have had those values reflected in the 
> IANA registry and we wouldn’t even be discussing them at such a late stage.
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 28 Jan 2022 00:49:17 +0000

I agree some code point is needed for an attribute with this functional purpose.

I have raised what I believe are reasonable concerns on a meaningful attribute name and related domain of values.  If a code point value can be reserved while these reasonable questions are open, then that is fine with me.

Eric

> From: Giridhar Mandyam, January 27, 2022 7:33 PM
> 
> As I mentioned below - the early assignment of claim values was a reflection of
> what was group consensus at the time.  The fact that the Chairs did not execute
> in a timely manner is no reason to derail (yes - I will use that word again) a
> straightforward procedure that should have completed a year ago.
> 
> > While I can understand and share the frustration - this is how it is now. I've
> been following this discussion very carefully and to be honest, Eric does have a
> point.
> 
> To: Giridhar Mandyam <[email-masked]>; Eric Voit (evoit)
> <evoit=[email-masked]>; Laurence Lundblade <lgl@island-
> resort.com>; Smith, Ned <[email-masked]>
> Cc: rats <[email-masked]>
> WARNING: This email originated from outside of Qualcomm. Please be wary of
> any links or attachments, and do not enable macros.
> 
> Hi Giri,
> 
> okay, well... that reads wrong to me. Work happened in the time that passed.
> Things evolved, we all now know more than a year before. There seems to be
> semantic conflict now between the concepts Eric highlighted and the concepts
> reflected in the "security level" Claim.
> 
> While I can understand and share the frustration - this is how it is now. I've been
> following this discussion very carefully and to be honest, Eric does have a point.
>

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 28 Jan 2022 01:43:54 +0000

There was consensus regarding the set of claims that were earmarked for early allocation in section 9.3.1 titled “Claims for Early Assignment” that was cited from the list archive. That conversation was the justification to satisfy IANA requirements. The criteria for allocation was that these claims were understood well enough that subsequent revisions of the draft wouldn't result in the allocation being rescinded or modified. I didn't interpret the criteria to mean that the text describing the claim couldn't be altered / clarified. There is a risk that anyone implementing to a draft ahead of RFC is exposed to risk of the draft changing. My understanding of the IANA criteria isn't to provide insurance against this risk. 

I am a little concerned that there were 3 code points added to the IANA request that were not included with the original consensus discussions (which implies a separate consensus discussion is needed for those three). If the list believes that consensus discussion happened then we need to check if that was included with Roman's request. 

Maybe the EAT draft authors can provide more context surrounding the 3 code points and why there is an apparent difference?
    > > hardware-version-label = 260

Thanks,
Ned

On 1/27/22, 4:50 PM, "Eric Voit (evoit)" <[email-masked]> wrote:

    Eric

---

From: Giridhar Mandyam <[email-masked]>
Date: Fri, 28 Jan 2022 02:08:40 +0000

Hi Eric,

> I agree some code point is needed for an attribute with this functional purpose.

Thank you for the confirmation.  

 > I have raised what I believe are reasonable concerns on a meaningful attribute name and related domain of values.  If a code point value can be reserved while these reasonable questions are open,…

Fine - let us continue the discussion separate from reserving the code points.

-Giri

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Eric Voit (evoit)
Sent: Thursday, January 27, 2022 4:49 PM
To: Giridhar Mandyam <[email-masked]>; Henk Birkholz <[email-masked]>; Laurence Lundblade <[email-masked]>; Smith, Ned <[email-masked]>
Cc: rats <[email-masked]>
Subject: Re: [Rats] Timeline for EAT early assignment code points by IANA

Eric

> As I mentioned below - the early assignment of claim values was a 
> reflection of what was group consensus at the time.  The fact that the 
> Chairs did not execute in a timely manner is no reason to derail (yes 
> - I will use that word again) a straightforward procedure that should have completed a year ago.
>
> > now. I've
> been following this discussion very carefully and to be honest, Eric 
> does have a point.
>
> I would expect the RATS Chairs to chime in now and reset this 
> discussion, but maybe that is just too large an ask.
>
> -Giri
>
> WARNING: This email originated from outside of Qualcomm. Please be 
> wary of any links or attachments, and do not enable macros.
>
> Hi Giri,
>
> Things evolved, we all now know more than a year before. There seems 
> to be semantic conflict now between the concepts Eric highlighted and 
> the concepts reflected in the "security level" Claim.
>
> now. I've been following this discussion very carefully and to be honest, Eric does have a point.
>
> why not just qualify the Claim name with an appropriate prefix. It 
> will be an integer "on the wire" with CBOR anyways.
>
> Viele Grüße,
>
> Henk
>
> > Security Level was designated for early assignment in draft -09, 
> > which was also the draft that encompassed all claims that were 
> > agreed upon by the group for early assignment.  If the Chairs and AD 
> > had completed the process of requesting early assignment a year ago 
> > as they were supposed to do, then we would have had those values 
> > reflected in the IANA registry and we wouldn’t even be discussing them at such a late stage.
> >
> > The difference between this and what Mike proposed is that it 
> > includes three more claims for early allocation:
> >
> > sueids-label = 257
> >
> > I’ve picked these because they fill out the UEIDs group of claims 
> > and the HW Identification group of claims (OEM, Model, Version) and 
> > allow the numbering to be conveniently sequential.
> >
> > LL
> >

---

From: Giridhar Mandyam <[email-masked]>
Date: Fri, 28 Jan 2022 04:57:37 +0000

Thanks Ned for providing the background.

> I didn't interpret the criteria to mean that the text describing the claim couldn't be altered / clarified. There is a risk that anyone implementing to a draft ahead of RFC is exposed to risk of the draft changing. My understanding of the IANA criteria isn't to provide insurance against this risk.

Agreed.  Sec Levels can fall into that category.

> I am a little concerned that there were 3 code points added to the IANA request that were not included with the original consensus discussions (which implies a separate consensus discussion is need…

Laurence has suggested adding them into the original list.  The two co-editors had no issue with the additions.  The additional entries were forwarded to the group to gauge objections, but in retrospect it should have been clarified in the mailing to the group that these 3 claims are added to the previous consensus decision from 1 year ago.  So sincere apologies for that oversight.

-Giri

-----Original Message-----
From: Smith, Ned <[email-masked]> 
Sent: Thursday, January 27, 2022 5:44 PM
To: Eric Voit (evoit) <[email-masked]>; Giridhar Mandyam <[email-masked]>; Henk Birkholz <[email-masked]>; Laurence Lundblade <[email-masked]>
Cc: rats <[email-masked]>
Subject: Re: [Rats] Timeline for EAT early assignment code points by IANA

Thanks,
Ned

    Eric

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 28 Jan 2022 16:09:31 +0000

>> I am a little concerned that there were 3 code points added to the IANA request that were >not included with the original consensus discussions (which implies a separate consensus >discussion is needed for those three). If the list believes that consensus discussion >happened then we need to check if that was included with Roman's request.
>
>Laurence has suggested adding them into the original list.  The two co-editors had no issue >with the additions.  The additional entries were forwarded to the group to gauge objections, >but in retrospect it should have been clarified in the mailing to the group that these 3 >claims are added to the previous consensus decision from 1 year ago.  So sincere apologies >for that oversight.

Is there anyone who disagrees that sueids-label = 257, hardware-model-label = 259, hardware-version-label = 260 should be included with the IANA early allocation request items?

Thx,
Ned

On 1/27/22, 8:57 PM, "Giridhar Mandyam" <[email-masked]> wrote:

    -Giri

    -----Original Message-----
    From: Smith, Ned <[email-masked]> 
    Sent: Thursday, January 27, 2022 5:44 PM
    To: Eric Voit (evoit) <[email-masked]>; Giridhar Mandyam <[email-masked]>; Henk Birkholz <[email-masked]>; Laurence Lundblade <[email-masked]>
    Cc: rats <[email-masked]>
    Subject: Re: [Rats] Timeline for EAT early assignment code points by IANA

    Thanks,
    Ned

        Eric

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 28 Jan 2022 16:39:41 +0000

Hi!

> From: RATS <[email-masked]> On Behalf Of Giridhar Mandyam
> Sent: Thursday, January 27, 2022 11:58 PM
> To: Smith, Ned <[email-masked]>; Eric Voit (evoit) <[email-masked]>;
> Henk Birkholz <[email-masked]>; Laurence Lundblade
> <[email-masked]>
> Cc: rats <[email-masked]>

[snip]

> > I am a little concerned that there were 3 code points added to the IANA
> request that were not included with the original consensus discussions (which
> implies a separate consensus discussion is needed for those three). If the list
> believes that consensus discussion happened then we need to check if that was
> included with Roman's request.

To responds about the request to IANA, these three code points were not in the request as they weren't in the early allocation request of Section 9.3.1 of draft-ietf-rats-eat-11 reviewed by IANA.  The consensus discussion (to support Step #3 of Section 3.1 of RFC7120) that I used was from Dec-4-2020, https://mailarchive.ietf.org/arch/msg/rats/FwCqNrYjbiTd0nGZ0Wg9RQ2uU8o/.  No objections were raised at the time.

Thanks Ned for pulling this call out on these additional claims here https://mailarchive.ietf.org/arch/msg/rats/Ih7btAFRtj6jWCS6KIsvmdOjS5A/.

The WG can choice to sequence the discussion in any whey they want.  From a process perspective, please consider Section 2 of RFC7120 which lays out requirements for asking for early assignment.  Specifically:

==[ snip ]==
   b.  The format, semantics, processing, and other rules related to
       handling the protocol entities defined by the code points
       (henceforth called "specifications") must be adequately described
       in an Internet-Draft.

   c.  The specifications of these code points must be stable; i.e., if
       there is a change, implementations based on the earlier and later
       specifications must be seamlessly interoperable.
==[ snip ]==

Practically this means no allocation can be requested until it is published into the EAT or some other document; and we're not going to request a change later.

Regards,
Roman

> To: Eric Voit (evoit) <[email-masked]>; Giridhar Mandyam
> <[email-masked]>; Henk Birkholz
> <[email-masked]>; Laurence Lundblade <lgl@island-
> resort.com>
> Cc: rats <[email-masked]>
> There was consensus regarding the set of claims that were earmarked for early
> allocation in section 9.3.1 titled “Claims for Early Assignment” that was cited
> from the list archive. That conversation was the justification to satisfy IANA
> requirements. The criteria for allocation was that these claims were understood
> well enough that subsequent revisions of the draft wouldn't result in the
> allocation being rescinded or modified. I didn't interpret the criteria to mean
> that the text describing the claim couldn't be altered / clarified. There is a risk
> that anyone implementing to a draft ahead of RFC is exposed to risk of the
> draft changing. My understanding of the IANA criteria isn't to provide insurance
> against this risk.
> 
> I am a little concerned that there were 3 code points added to the IANA
> request that were not included with the original consensus discussions (which
> implies a separate consensus discussion is needed for those three). If the list
> believes that consensus discussion happened then we need to check if that was
> included with Roman's request.
> 
> Maybe the EAT draft authors can provide more context surrounding the 3 code
> points and why there is an apparent difference?
>     I have raised what I believe are reasonable concerns on a meaningful
> attribute name and related domain of values.  If a code point value can be
> reserved while these reasonable questions are open, then that is fine with me.
> 
>     Eric
> 
> reflection of
>     > I would expect the RATS Chairs to chime in now and reset this discussion,
> but
>     > maybe that is just too large an ask.
>     >
>     > -Giri
>     >
> wary of
> passed.
> been
>     > why not just qualify the Claim name with an appropriate prefix. It will be
> an
>     > integer "on the wire" with CBOR anyways.
>     >
>     > Viele Grüße,
>     >
>     > Henk
>     >

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 28 Jan 2022 08:53:52 -0800

The rationale for including SUEIDs is that UEID and SUEID are related and it is nice that they go together and be adjacently numbered.

Similarly and more importantly the triple of HW OEM, HW Model and HW Version are a set necessary to identify something manufactured.

I was clear about the addition of these three in my email on January 21.

LL

> On Jan 28, 2022, at 8:09 AM, Smith, Ned <[email-masked]> wrote:
>