Re: [Rats] Where does a EAT end?

> On Jun 3, 2022, at 12:53 PM, Smith, Ned <ned.smith@intel.com> wrote:
> 
> Is the motivation for limiting extensions to an IETF standards track document that extension by a vendor or other standards setting organization might result in non-interoperable tokens? Something else?

To be clear, the issue at hand here is only the definition of more top-level formats for EAT. This is not about limiting EAT extension in general (not about limiting claims, not about limiting profiles…).

The more top-level formats we have for EAT (e.g., XML claims-set, DER claims-set, …) the more complicated it is for implementors and/or the less interoperability we have. It is already difficult enough with CBOR and JSON. Many RATS people don’t have any need for JSON (but note that JSON and CBOR support is mentioned in the charter).

This is worse when you consider composite devices. If every attester picks the format convenient for themselves and then someone builds a device that uses 4 attesters that use 4 different top-level formats, the composite / collection might have one token that is CBOR, one that is JSON, one that is XML and one that is DER. That makes it pretty difficult for the verifier.

I think we do need to consider the composite device in most of what we do for the sake of wide-spread adoption of attestation over the next decades.

To me the IETF was founded on the idea of having one protocol we all speak rather than n. You know going back to when there was SNA, DecNET, AppleTalk, NetBios… When you have n, you end up with an n^2 implementation problem.

LL

>  
> From: Laurence Lundblade <lgl@island-resort.com>
> Date: Friday, June 3, 2022 at 12:36 PM
> To: "Smith, Ned" <ned.smith@intel.com>
> Cc: Giridhar Mandyam <mandyam@qti.qualcomm.com>, Thomas Fossati <Thomas.Fossati@arm.com>, "rats@ietf.org" <rats@ietf.org>
> Subject: Re: [Rats] Where does a EAT end? - consensus?
>  
> Didn’t think this was an interoperability issue. It is an extensibility issue. How much extension to other formats are allowed.
>  
> My question is whether there is consensus or objections around this PR <https://github.com/ietf-rats-wg/eat/pull/194>. 
>  
> It simply adds the sentence "Any new format that plugs into this socket MUST be defined in a IETF standards track document."
>  
> LL
>  
> 
> 
>> On Jun 3, 2022, at 11:38 AM, Smith, Ned <ned.smith@intel.com <mailto:ned.smith@intel.com>> wrote:
>>  
>> To summarize, it appears the way to address the issue of a potential for non-interoperability of “top-level” statements in the EAT draft is to acknowledge that this potential exists, and that it can be accommodated in a variety of ways that don’t need to be discussed within the EAT draft.
>>  
>> Does anyone disagree that this addresses the issue?
>>  
>> -Ned
>>  
>> From: RATS <rats-bounces@ietf.org <mailto:rats-bounces@ietf.org>> on behalf of Giridhar Mandyam <mandyam@qti.qualcomm.com <mailto:mandyam@qti.qualcomm.com>>
>> Date: Thursday, June 2, 2022 at 1:40 PM
>> To: Thomas Fossati <Thomas.Fossati@arm.com <mailto:Thomas.Fossati@arm.com>>, "rats@ietf.org <mailto:rats@ietf.org>" <rats@ietf.org <mailto:rats@ietf.org>>
>> Subject: Re: [Rats] Where does a EAT end? (was: Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat>)
>>  
>> > Not sure I follow: profiles are type constraints that apply to *existing* top-level EAT types.  They can't be used to extend the number and shape of base EAT types.
>>  
>> I was commenting on interop, not on extension of top-level EAT types.  I don’t think we need to provide a mechanism to extend the base EAT types within the EAT specification itself.  I’ve already mentioned with the example of JWT’s that the underlying specifications such as JS allow for that today.
>>  
>> If someone has identified a new field that must be added at the top-level of an EAT, they are welcome to come up with their own specification, as described in https://github.com/ietf-rats-wg/eat/pull/194 <https://github.com/ietf-rats-wg/eat/pull/194>.  I personally don’t think we should call it an EAT at that point, but that is a minor point.
>>  
>> -Giri
>>  
>> From: Thomas Fossati <Thomas.Fossati@arm.com <mailto:Thomas.Fossati@arm.com>> 
>> Sent: Thursday, June 2, 2022 1:30 PM
>> To: Giridhar Mandyam <mandyam@qti.qualcomm.com <mailto:mandyam@qti.qualcomm.com>>; rats@ietf.org <mailto:rats@ietf.org>
>> Subject: Re: [Rats] Where does a EAT end? (was: Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat>)
>>  
>> WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
>> > Giridhar Mandyam <mandyam@qti.qualcomm.com <mailto:mandyam@qti.qualcomm.com>> wrote:
>> > > > I think the underlying data structures make it extensible,
>> > > > independent of the CDDL notation.  However if an implementor
>> > > > chooses to extend EAT without an accompanying standard as a
>> > > > result, then interoperability may not be assured.  Therefore it is
>> > > > in an implementor’s interest to define a standard if they are
>> > > > seeking interop.
>> >  
>> > > The core difference is the extensibility story for the claims-set is
>> > > governed by the CWT Claims registry, whilst the EAT type system has
>> > > no such mechanism (yet).
>> >  
>> > I don’t agree:  the profile definition addresses interop – see
>> > https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat#section-7 <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat#section-7>.
>> > Up to this point, no-one has objected to the way profiles are defined
>> > in the specification, nor the lack of a registry.
>>  
>> Not sure I follow: profiles are type constraints that apply to
>> *existing* top-level EAT types.  They can't be used to extend the number
>> and shape of base EAT types.
>>  
>> FWIW, I'm a big fan of profiles.
>>  
>>  
>>  
>>  
>>  
>> 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.
>> _______________________________________________
>> RATS mailing list
>> RATS@ietf.org <mailto:RATS@ietf.org>
>> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>