Subject: [Rats] challenges of building dependant specifications against Internet-Drafts -- a way forward for EAT

From: Michael Richardson <[email-masked]>
Date: Sun, 29 Nov 2020 15:18:03 -0500

Hi, sorry that I missed the RATS IETF109 meeting: I was engaged as co-chair
of ASDF at the same time.   I watched the video.

I think that the many EAT concerns are now at the point where more
conversation probably will make it worse rather than better.
It's time to move on with the EAT framework: many of the issues discussed
will become much clearer when it is used.
That's why we have "PS" vs "Internet Standard".

I found Giri's presentation interesting: I scanned through the FIDO IoT
Onboarding document, and I have no idea why FIDO needs to re-invent
(Constrained) BRSKI.   But, I'm excited about it!

The more the manufacturers understand the need for device identities, and
for a "home base" (A Registrar), the better our whole industry will be.
When MS tried to do this with the XBOX-1 a decade ago, people cried foul, but
maybe they weren't ready for this in the home yet.  We certainly need it to
be standards based, and free of stupid IPR stuff.  What will CHIP do, I wonder.

The single reference to RFC8366 did not explain why that document did not
adopt a semantically compatible voucher format.

draft-ietf-anima-constrained-voucher explains how to serialize the YANG to
CBOR using draft-ietf-core-yang-cbor and draft-ietf-core-sid.
This is then signed with COSE.
{Or CMS, but that option is going away}

The result is almost *syntactically* identical to an EAT (a map of stuff
signed by COSE)!
But the semantics are a fair bit different.
Vouchers contain many things which I would not call claims, but embody
essentially a single claim concerning ownership.

draft-ietf-core-sid establishes a registry for SID values, which as
essentially map keys for CBOR.  It has been difficult to get the document to
advance, and until it did, we couldn't figure out how we'd be able to do
the IANA allocation process: hard to get an early allocation against a
registry which does not yet exist.

What we did, and what Giri could ask the EAT authors and WG to do is to
allocate some claims in the initial IANA Considerations section.
That is, until such time as the document progresses through the IESG,
the WG and the document authors essentially act as IANA.

Here is what it looks like from draft-ietf-core-sid:

section 7.5.3 (of sid-14):

   Initial entries in this registry are as follows:

   +-------+------+---------------------------+------------------------+
   | Entry | Size | Module name               | Document reference     |
   | Point |      |                           |                        |
   +-------+------+---------------------------+------------------------+
   |  1000 |  100 | ietf-coreconf             | [I-D.ietf-core-comi]   |
   |  1100 |   50 | ietf-yang-types           | [RFC6991]              |
   |  1150 |   50 | ietf-inet-types           | [RFC6991]              |
   |  1200 |   50 | iana-crypt-hash           | [RFC7317]              |
   |  1250 |   50 | ietf-netconf-acm          | [RFC8341]              |
   |  1300 |   50 | ietf-sid-file             | RFCXXXX                |
   |  1500 |  100 | ietf-interfaces           | [RFC8343]              |
   |  1600 |  100 | ietf-ip                   | [RFC8344]              |
   |  1700 |  100 | ietf-system               | [RFC7317]              |
   |  1800 |  400 | iana-if-type              | [RFC7224]              |
   |  2400 |   50 | ietf-voucher              | [RFC8366]              |
   |  2450 |   50 | ietf-constrained-voucher  | [I-D.ietf-anima-constr |
   |       |      |                           | ained-voucher]         |
   |  2500 |   50 | ietf-constrained-voucher- | [I-D.ietf-anima-constr |
   |       |      | request                   | ained-voucher]         |
   +-------+------+---------------------------+------------------------+

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 30 Nov 2020 11:40:58 +0000

Hi Michael,

In his presentation Giri pointed out that companies and industry groups want to see progress on the EAT specification.

In this specific case, Giri was talking about EAT being used by the FIDO device onboard specification. But the same is actually true for us (at Arm) and for Qualcomm, who are using EAT today.

A discussion about the FIDO device onboarding spec is IMHO distinct from the EAT topic.

Ciao
Hannes

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Michael Richardson
Sent: Sunday, November 29, 2020 9:18 PM
To: Giri Mandyam <[email-masked]>; [email-masked]
Subject: [Rats] challenges of building dependant specifications against Internet-Drafts -- a way forward for EAT

I think that the many EAT concerns are now at the point where more conversation probably will make it worse rather than better.
It's time to move on with the EAT framework: many of the issues discussed will become much clearer when it is used.
That's why we have "PS" vs "Internet Standard".

I found Giri's presentation interesting: I scanned through the FIDO IoT Onboarding document, and I have no idea why FIDO needs to re-invent
(Constrained) BRSKI.   But, I'm excited about it!

The more the manufacturers understand the need for device identities, and for a "home base" (A Registrar), the better our whole industry will be.
When MS tried to do this with the XBOX-1 a decade ago, people cried foul, but maybe they weren't ready for this in the home yet.  We certainly need it to be standards based, and free of stupid IPR stuff.  What will CHIP do, I wonder.

The single reference to RFC8366 did not explain why that document did not adopt a semantically compatible voucher format.

draft-ietf-anima-constrained-voucher explains how to serialize the YANG to CBOR using draft-ietf-core-yang-cbor and draft-ietf-core-sid.
This is then signed with COSE.
{Or CMS, but that option is going away}

The result is almost *syntactically* identical to an EAT (a map of stuff signed by COSE)!
But the semantics are a fair bit different.
Vouchers contain many things which I would not call claims, but embody essentially a single claim concerning ownership.

draft-ietf-core-sid establishes a registry for SID values, which as essentially map keys for CBOR.  It has been difficult to get the document to advance, and until it did, we couldn't figure out how we'd be able to do the IANA allocation process: hard to get an early allocation against a registry which does not yet exist.

What we did, and what Giri could ask the EAT authors and WG to do is to allocate some claims in the initial IANA Considerations section.
That is, until such time as the document progresses through the IESG, the WG and the document authors essentially act as IANA.

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.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Nov 2020 07:37:02 -0500

Hannes Tschofenig <[email-masked]> wrote:
    > In his presentation Giri pointed out that companies and industry groups
    > want to see progress on the EAT specification.

Right, and yet, the WG can't really guarantee a schedule.
If you read to end, you'll see that I propose a way in which the various
industry groups can receive official EAT claim #s from the not-yet-created
IANA registry.
That allows them to do interop while EAT specification progresses.
Whether they wish to "release" before EAT has an RFC# or not, is up to them.

    > In this specific case, Giri was talking about EAT being used by the
    > FIDO device onboard specification. But the same is actually true for us
    > (at Arm) and for Qualcomm, who are using EAT today.

    > A discussion about the FIDO device onboarding spec is IMHO distinct

Distinct, and yet they are related because FIDO's voucher specification seems
to be an EAT rather than a constrained-voucher.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 30 Nov 2020 17:19:37 +0000

Hi Michael,

This thread reminds me of some of the EAT draft adoption discussions from May of 2019.   Some of the threads I remember from the discussion include:

https://mailarchive.ietf.org/arch/msg/rats/7Uzkd84plkQ_LJ6oUYTQ3iwkmws/
https://mailarchive.ietf.org/arch/msg/rats/KPU6WgiCGkT6mUTbf5Ga41KwSNc/
https://mailarchive.ietf.org/arch/msg/rats/jBCYPK2hly554HGYTXZXa2t_AGw/

At the time, there was general agreement that where object definitions existed, it would be good to re-use them.  That would reduce the mapping needed between IANA maintained object definitions between technology spaces.  

Below in your email you point to a list of YANG specifications named within draft-ietf-core-sid, section 7.5.3.  I think you are doing this for as a starting point for some object definition contents.  Am I interpreting this correctly?   If yes, this is exactly what I was hoping might happen.

Eric

> From: Michael Richardson, November 29, 2020 3:18 PM
> The more the manufacturers understand the need for device identities, and for a
> "home base" (A Registrar), the better our whole industry will be.
> maybe they weren't ready for this in the home yet.  We certainly need it to be
> standards based, and free of stupid IPR stuff.  What will CHIP do, I wonder.
> 
> draft-ietf-core-sid establishes a registry for SID values, which as essentially map
> keys for CBOR.  It has been difficult to get the document to advance, and until it
> did, we couldn't figure out how we'd be able to do the IANA allocation process:
> hard to get an early allocation against a registry which does not yet exist.
> 
> That is, until such time as the document progresses through the IESG, the WG
> and the document authors essentially act as IANA.
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 30 Nov 2020 17:28:03 +0000

Hi Michael,

I know that the IETF does not work on deadlines. Giri wanted to make the group aware of dependencies.

I have suggested FIDO to request registration of claims in the CWT IANA registry, in a style similar to what you suggest below. I guess there are not many other options given of where we are.

Ciao
Hannes

-----Original Message-----
From: Michael Richardson <[email-masked]>
Sent: Monday, November 30, 2020 1:37 PM
To: Hannes Tschofenig <[email-masked]>; Giri Mandyam <[email-masked]>; [email-masked]
Subject: Re: [Rats] challenges of building dependant specifications against Internet-Drafts -- a way forward for EAT

Right, and yet, the WG can't really guarantee a schedule.
If you read to end, you'll see that I propose a way in which the various industry groups can receive official EAT claim #s from the not-yet-created IANA registry.
That allows them to do interop while EAT specification progresses.
Whether they wish to "release" before EAT has an RFC# or not, is up to them.

    > A discussion about the FIDO device onboarding spec is IMHO distinct

Distinct, and yet they are related because FIDO's voucher specification seems to be an EAT rather than a constrained-voucher.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 30 Nov 2020 17:30:13 +0000

Eric,

From the discussion in May 2019 we agreed that we would use the CWT registry for the claims in the EAT. This was a good conclusion.

The example with the YANG specifications was, if I understood it, just an example.

Ciao
Hannes

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Eric Voit (evoit)
Sent: Monday, November 30, 2020 6:20 PM
To: Michael Richardson <[email-masked]>; Giri Mandyam <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rats] challenges of building dependant specifications against Internet-Drafts -- a way forward for EAT

Hi Michael,

Eric

> Subject: [Rats] challenges of building dependant specifications
> against Internet- Drafts -- a way forward for EAT
>
>
> It's time to move on with the EAT framework: many of the issues
> discussed will become much clearer when it is used.
> I found Giri's presentation interesting: I scanned through the FIDO
> IoT Onboarding document, and I have no idea why FIDO needs to re-invent
> The more the manufacturers understand the need for device identities,
> and for a "home base" (A Registrar), the better our whole industry will be.
> When MS tried to do this with the XBOX-1 a decade ago, people cried
> foul, but maybe they weren't ready for this in the home yet.  We
> certainly need it to be standards based, and free of stupid IPR stuff.  What will CHIP do, I wonder.
>
> The single reference to RFC8366 did not explain why that document did
> not adopt a semantically compatible voucher format.
>
> draft-ietf-anima-constrained-voucher explains how to serialize the
> YANG to CBOR using draft-ietf-core-yang-cbor and draft-ietf-core-sid.
> essentially map keys for CBOR.  It has been difficult to get the
> document to advance, and until it did, we couldn't figure out how we'd be able to do the IANA allocation process:
> What we did, and what Giri could ask the EAT authors and WG to do is
> to allocate some claims in the initial IANA Considerations section.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 30 Nov 2020 17:36:30 +0000

Yes, we agreed to use the CWT registry.  I also recall using YANG objects and a potential definition and range source for any new claims that people wanted to add.  (I.e., if it exists, let's use it.  And then we don't have to worry about cross-domain mapping.)   My reading of Michael's email is that this was the purpose of the table included in the bottom of this thread.

Eric

> From: Hannes Tschofenig <[email-masked]>
> Sent: Monday, November 30, 2020 12:30 PM
> To: Eric Voit (evoit) <[email-masked]>; Michael Richardson
> <[email-masked]>; Giri Mandyam <[email-masked]>
> Cc: [email-masked]
> Subject: RE: [Rats] challenges of building dependant specifications against
> Internet-Drafts -- a way forward for EAT
> 
> Eric,
> 
> From the discussion in May 2019 we agreed that we would use the CWT registry
> for the claims in the EAT. This was a good conclusion.
> 
> This thread reminds me of some of the EAT draft adoption discussions from May
> of 2019.   Some of the threads I remember from the discussion include:
> 
> At the time, there was general agreement that where object definitions existed,
> it would be good to re-use them.  That would reduce the mapping needed
> between IANA maintained object definitions between technology spaces.
> 
> Below in your email you point to a list of YANG specifications named within
> draft-ietf-core-sid, section 7.5.3.  I think you are doing this for as a starting point
> for some object definition contents.  Am I interpreting this correctly?   If yes, this
> is exactly what I was hoping might happen.
> 
> Eric
> 
> 
> 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.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 30 Nov 2020 17:58:12 +0000

Michael,

> Distinct, and yet they are related because FIDO's voucher specification seems to be an EAT rather than a constrained-voucher.

The FIDO voucher is a new design; it has no relationship to EAT or to the constrained voucher.

Ciao
Hannes

---

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Nov 2020 13:11:24 -0500

Eric Voit (evoit) <[email-masked]> wrote:
    > Yes, we agreed to use the CWT registry.

I didn't feel that this decision was very strong, and I thought that we went
back and forth at least twice on this, with various kinds of sub-registries
proposed.

    > I also recall using YANG objects and a potential definition and range
    > source for any new claims that people wanted to add.  (I.e., if it
    > exists, let's use it.  And then we don't have to worry about
    > cross-domain mapping.)   My reading of Michael's email is that this was
    > the purpose of the table included in the bottom of this thread.

As I understood Giri's issue, he didn't think he could register production
values into the EAT registry until the document was finished.  That's what I
got from watching the video.

If we are using the CWT registry, then he can just go ahead, as the registry
already exists, and at least some of it is FCFS.

If we are not, then my text was an example of what a different WG did to deal
with early adopters.

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 30 Nov 2020 12:37:34 -0800

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. 

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.

Here’s one proposal:

We put claim numbers in the EAT document from the private space CWT space (less than -65536). These can be the same as in my in-progress EAT implementation here. Hopefully other implementations do the same. Also, the same as the claims in the ARM PSA token draft <https://tools.ietf.org/html/draft-tschofenig-rats-psa-token-05> where they overlap.

When the EAT draft is standardized, new Standards Action range numbers will get assigned. Implementations can either continue using the old private space CWT numbers or they can move to the new numbers. It is pretty easy for a receiver of a token to accept both the old and new numbers. It is just one extra if statement or case in a case statement. The sender of a token can stick to the old private ones for a long time, until the receivers they care about support the new ones. There is some motivation to move to the new ones because of the size reduction.

Another proposal:

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.

LL

> On Nov 30, 2020, at 10:11 AM, Michael Richardson <[email-masked]> wrote:
> 
> 
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Nov 2020 18:16:59 -0500

Laurence Lundblade <[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.

    > 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]  http://www.sandelman.ca/        |   ruby on rails    [