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

From: Thomas Fossati <[email-masked]>
Date: Fri, 12 Feb 2021 18:14:02 +0000

Ned, Laurence, Giri, all,

On 05/02/2021, 19:50, "Smith, Ned" <[email-masked]> wrote:
> Folks,
> The EAT draft https://datatracker.ietf.org/doc/draft-ietf-rats-eat/
> contains proposed IANA pre-RFC early assignment code point definitions
> in section 7.3.1.
>
> The conditions for making an official IANA request are below in [c]
> and [d].
>
> Does the list believe the code points are stable?
>
> Does the list have sufficient interest in pre-RFC implementation and
> deployment to move forward with the request?

It'd be extremely useful to us if the "profile" claim could be added to
the list early assignments.

That way the PSA token would just use the standard code point assigned
to "profile" to create the context to interpret the rest of the private
PSA claims - which means we would not need to make any further request
to IANA.

Hopefully it is not too late to ask :-)

Cheers!

> Thanks,
> Ned / RATs Chairs
>
> [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.
>
> [d] The Working Group chairs and Area Directors (ADs) judge that
>  there is sufficient interest in the community for early (pre-RFC)
>  implementation and deployment, or that failure to make an early
>  allocation might lead to contention for the code point in the
>  field.

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

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: Laurence Lundblade <[email-masked]>
Date: Sat, 13 Feb 2021 16:00:54 -0700

Profiles and are only in EAT drafts from the last month so they haven’t had much review or discussion. That makes them different from the other claims for which pre-assignment is requested.  I don’t think I have even presented them in detail in any meetings. So personally I am kind of on the fence about this.

A thorough reading and commenting by folks other than Arm would get me off the fence.

Happy to hear what the chairs think too.

LL

> On Feb 12, 2021, at 11:14 AM, Thomas Fossati <[email-masked]> wrote:
>

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 15 Feb 2021 19:36:22 +0000

The topic of how vendor specific data should be handled has been brought up in the past. The conversation seemed to reach consensus by using the CWT/JWT existing mechanisms for vendor specific tags. Maybe someone should summarize how the profile mechanism compares to CWT/JWT vendor specific mechanisms?

Ned Smith - Intel - [email-masked]

________________________________________
From: Laurence Lundblade <[email-masked]>
Sent: Saturday, February 13, 2021 3:00 PM
To: Thomas Fossati
Cc: Smith, Ned; [email-masked]; Adrian Shaw; Hannes Tschofenig; Simon Frost
Subject: Re: [Rats] IANA pre-RFC code points

LL

On Feb 12, 2021, at 11:14 AM, Thomas Fossati <[email-masked]<mailto:[email-masked]>> wrote:

Cheers!

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 15 Feb 2021 13:36:33 -0700

They are largely complementary mechanisms.  Maybe you could call the IANA claims registry the palette of colors and a profile the painting.

The IANA claims registry describes lots of different claims. Some implementations will use one set of them, other implementations will use others. Some will use proprietary claims that are not in the registry. This however doesn’t give much guarantee of interoperability between an Attester and Verifier.

A profile says which claims are in use for a give use case. It says which claims are prohibited, which are required and which are optional. It should be complete enough to give full interoperability for a use case.

A profile also says which crypto, which serialization format and such to use so that interoperability can be achieved.  There are 12 separate things that a profile should specify (e.g., required claims, prohibited claims, JSON/CBOR, algorithms, CBOR serialization, endorsement identification…). Take a look at the text here <https://tools.ietf.org/html/draft-ietf-rats-eat-08#section-5>.

LL

> On Feb 15, 2021, at 12:36 PM, Smith, Ned <[email-masked]> wrote:
>

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 16 Feb 2021 16:44:35 +0000

Is it the intent of this spec to define a machine readable format for stating the 12 ‘things’ the profile should specify?
What if any convention addresses profile name collisions? If vendor-A uses profile name is “A” and vendor-B also uses “A”, is that considered either a security problem or an interoperability problem?
-Ned

From: Laurence Lundblade <[email-masked]>
Date: Monday, February 15, 2021 at 12:36 PM
To: "Smith, Ned" <[email-masked]>
Cc: Thomas Fossati <[email-masked]>, "[email-masked]" <[email-masked]>, Adrian Shaw <[email-masked]>, Hannes Tschofenig <[email-masked]>, Simon Frost <[email-masked]>
Subject: Re: [Rats] IANA pre-RFC code points

A profile also says which crypto, which serialization format and such to use so that interoperability can be achieved.  There are 12 separate things that a profile should specify (e.g., required claims, prohibited claims, JSON/CBOR, algorithms, CBOR serialization, endorsement identification…). Take a look at the text here<https://tools.ietf.org/html/draft-ietf-rats-eat-08#section-5>.

LL

On Feb 15, 2021, at 12:36 PM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

Ned Smith - Intel - [email-masked]<mailto:[email-masked]>

________________________________________
From: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, February 13, 2021 3:00 PM
To: Thomas Fossati
Cc: Smith, Ned; [email-masked]<mailto:[email-masked]>; Adrian Shaw; Hannes Tschofenig; Simon Frost
Subject: Re: [Rats] IANA pre-RFC code points

LL

On Feb 12, 2021, at 11:14 AM, Thomas Fossati <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> wrote:

Cheers!

---

From: Simon Frost <[email-masked]>
Date: Tue, 16 Feb 2021 16:56:03 +0000

The original intent for the spec was to be human readable rather than machine readable, with the main audience being a developer of a relying party or verifier. I agree it would be useful to establish a convention for the values to prevent interoperability problems (eg. vendor-product-version), not sure how strict such a convention would need to be.

Thanks
Simon

From: Smith, Ned <[email-masked]>
Sent: 16 February 2021 16:45
To: Laurence Lundblade <[email-masked]>
Cc: Thomas Fossati <[email-masked]>; [email-masked]; Adrian Shaw <[email-masked]>; Hannes Tschofenig <[email-masked]>; Simon Frost <[email-masked]>
Subject: Re: [Rats] IANA pre-RFC code points

From: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 15, 2021 at 12:36 PM
To: "Smith, Ned" <[email-masked]<mailto:[email-masked]>>
Cc: Thomas Fossati <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Adrian Shaw <[email-masked]<mailto:[email-masked]>>, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>, Simon Frost <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] IANA pre-RFC code points

LL

LL

Cheers!

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 16 Feb 2021 17:07:43 +0000

Hi Simon, Ned,

On 16/02/2021, 16:56, "Simon Frost" <[email-masked]> wrote:
> The original intent for the spec was to be human readable rather than
> machine readable, with the main audience being a developer of a
> relying party or verifier. I agree it would be useful to establish a
> convention for the values to prevent interoperability problems (eg.
> vendor-product-version), not sure how strict such a convention would
> need to be.
>
> Thanks Simon
>
>
> On 16/02/2021, 16:45, "Smith, Ned" <[email-masked]> wrote:
> > Is it the intent of this spec to define a machine readable format
> > for stating the 12 ‘things’ the profile should specify?  What if any
> > convention addresses profile name collisions? If vendor-A uses
> > profile name is “A” and vendor-B also uses “A”, is that considered
> > either a security problem or an interoperability problem?
> > -Ned

ISTM that non-collision should be a hard requirement.  We have all the
pieces available - either using explicitly namespaced objects (URIs,
OIDs) or huge random pools (UUID/UEID-like) - we just need to pick what
we need.  The benefit of avoiding ambiguities about the semantics of the
very things that determine the DOI of Evidence is well worth the (small,
one-shot) cost we impose on the profile owner.

cheers, t

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 16 Feb 2021 10:42:58 -0700

I was expecting at least a few profiles to be standards track RFCs. Other’s will be authored by other standard’s orgs (e.g., FIDO, GP). Other’s by companies.

I expect profiles to be focused on domains. Here’s some examples: consumer IoT, phone key store attestation, automotive, user authentication, routers in closets.

In many scenarios a machine readable format will have no use. For example, in a constrained environment you only want to implement one crypto algorithm and the smallest and most efficient options for serialization.

So, no, not machine readable. 

I think profiles are important for EAT interoperability:
- COSE and JOSE algorithm support is open-ended and there is no negotiation like TLS
- Many serialization formats and variants (EAT defines 2, EAT architecture suggests even more)
- - CBOR has it’s own variants in serialization formats and in tagging
- Varying problem domains

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 hope we don’t delay the pre allocation much longer. It’s been over 2 months since I made the first clear formal request.

LL

> On Feb 16, 2021, at 9:44 AM, Smith, Ned <[email-masked]> wrote:
> 
>> On Feb 15, 2021, at 12:36 PM, Smith, Ned <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> Ned Smith - Intel - [email-masked] <mailto:[email-masked]>
>> 
>> From: Laurence Lundblade <[email-masked] <mailto:[email-masked]>>
>> Cc: Smith, Ned; [email-masked] <mailto:[email-masked]>; Adrian Shaw; Hannes Tschofenig; Simon Frost
>> On Feb 12, 2021, at 11:14 AM, Thomas Fossati <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 16 Feb 2021 18:10:31 +0000

On 16/02/2021, 17:43, "Laurence Lundblade" <[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.

Cheers!

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 16 Feb 2021 13:24:27 -0700

Below...

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

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?

3) URI or OID. No text string. Is that what you are proposing above? 

4) Just a text string.

My preference is 1) since it is in use for other things.

We don’t have to resolve details of the 12 things suggested for a profile for pre-allocation, but we do have to resolve the data type and generally agree on what profiles are.

LL

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 17 Feb 2021 00:44:03 +0000

On 16/02/2021, 20:25, "Laurence Lundblade" <[email-masked]> wrote:
> Below...
>
> > On Feb 16, 2021, at 11:10 AM, <[email-masked]> wrote:
> >
> > On 16/02/2021, 17:43, <[email-masked]> wrote:
> >>
> >> pre-allocation.  We don't have to agree on the mechanism for
> >> defining profiles, just for naming them.
> >
> > 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,)
> >
> > 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.
>
> 1) Make it string-or-uri like the JWT issuer, subject and audience
>    claims. Already well-established approach.
>

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.

What is not clear to me at the moment is what kind of benefit we get
from allowing unstructured text?  And if there is a benefit, what
strategy do we want to recommend to avoid collisions?

> 3) URI or OID. No text string. Is that what you are proposing above?

Yes, that'd be my preference: namespaced types only.

> My preference is 1) since it is in use for other things.

See above.

> We don't have to resolve details of the 12 things suggested for a
> profile for pre-allocation, but we do have to resolve the data type
> and generally agree on what profiles are.

+1

Cheers!

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 16 Feb 2021 17:59:21 -0700

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

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

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.

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.

LL

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 17 Feb 2021 09:55:36 +0000

Hi Laurence,

On 17/02/2021, 00:59, "Laurence Lundblade" <[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 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:
> >>> ~~~
> >>> I don't think it's crazy to expect the profile owner to also
> >>> control a DNS name and/or a PEN.
> >>
> > 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.
>

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

> 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

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 17 Feb 2021 11:06:40 +0100

+ 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)

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 27 Feb 2021 21:29:15 -0700

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]> wrote:
> 
> + 1 to:
>

---

From: Laurence Lundblade <[email-masked]>
Date: Sun, 28 Feb 2021 19:11:36 -0800

FYI, one of the implications of using an OID here is that to translate a token to/from CBOR to JSON will require code to turn CBOR OIDs into text string dotted-decimal OIDs and vice versa. That’s going to require a full encoder/decoder of the ASN.1 OID format. 

This is probably OK because:
- this is nothing near a full ASN.1 encoder/decoder
- this will happen mostly on servers where code size is not an issue

Note that the plan to format an OID in JSON is to use a text string like “1.2.20.1”. 

(I’m working on code that will translate CBOR tokens to JSON; it’s a good validation of the EAT draft).

LL

> On Feb 27, 2021, at 8:29 PM, Laurence Lundblade <[email-masked]> wrote:
>

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 1 Mar 2021 07:03:46 +0000

Hi Laurence, thanks for the PR!

> (I’m working on code that will translate CBOR tokens to JSON; it’s a good validation of the EAT draft).

We have an implementation that can do this [1].  Once you have yours
up & running it'd be great to get together and define a bunch of test
cases to exercise the full round trip between codebases.

We are at the RATS hackathon table all week if you are interested.

cheers!

[1] https://github.com/veraison/eat/blob/c058d63f0079e62819434681d0cbf9a5283b8fef/eat_test.go#L164)