Re: [Rats] IANA pre-RFC code points

[Simon Frost <[e-mail]>]

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 <[e-mail]>
Sent: 16 February 2021 16:45
To: Laurence Lundblade <[e-mail]>
Cc: Thomas Fossati <[e-mail]>; [e-mail]; Adrian Shaw <[e-mail]>; Hannes Tschofenig <[e-mail]>; Simon Frost <[e-mail]>
Subject: Re: [Rats] IANA pre-RFC code points

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 <[e-mail]<mailto:[e-mail]>>
Date: Monday, February 15, 2021 at 12:36 PM
To: "Smith, Ned" <[e-mail]<mailto:[e-mail]>>
Cc: Thomas Fossati <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Adrian Shaw <[e-mail]<mailto:[e-mail]>>, Hannes Tschofenig <[e-mail]<mailto:[e-mail]>>, Simon Frost <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Rats] IANA pre-RFC code points

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 <[e-mail]<mailto:[e-mail]>> wrote:

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 - [e-mail]<mailto:[e-mail]>

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

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 <[e-mail]<mailto:[e-mail]><mailto:[e-mail]>> wrote:

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!

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.