Re: [Rats] IANA pre-RFC code points

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 <ned.smith@intel.com> 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
>  
> From: Laurence Lundblade <lgl@island-resort.com>
> Date: Monday, February 15, 2021 at 12:36 PM
> To: "Smith, Ned" <ned.smith@intel.com>
> Cc: Thomas Fossati <Thomas.Fossati@arm.com>, "rats@ietf.org" <rats@ietf.org>, Adrian Shaw <Adrian.Shaw@arm.com>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>, Simon Frost <Simon.Frost@arm.com>
> 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 <ned.smith@intel.com <mailto:ned.smith@intel.com>> 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 - ned.smith@intel.com <mailto:ned.smith@intel.com>
>> 
>> ________________________________________
>> From: Laurence Lundblade <lgl@island-resort.com <mailto:lgl@island-resort.com>>
>> Sent: Saturday, February 13, 2021 3:00 PM
>> To: Thomas Fossati
>> Cc: Smith, Ned; rats@ietf.org <mailto:rats@ietf.org>; 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 <Thomas.Fossati@arm.com <mailto:Thomas.Fossati@arm.com><mailto:Thomas.Fossati@arm.com <mailto:Thomas.Fossati@arm.com>>> 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!
>> 
> 
>  
> _______________________________________________
> RATS mailing list
> RATS@ietf.org <mailto:RATS@ietf.org>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>