Re: [Iot-directorate] EAT profiles (was Re: Iotdir last call review of draft-ietf-rats-eat-13)

[Eliot Lear <[e-mail]>]

Hi Laurence,

Every point you made below is something that could have been addressed, 
if necessary, using the MUSTs and SHOULDs Toerless discussed.  As I 
wrote earlier, the most absurd case of this is whether a nonce is an 
array or a single object.  You have several easy choices to avoid that: 
either say that it can be both, or simply require an array.  Thomas and 
I have gone back and forth about the length of the nonce.  Was there any 
discussion or objection to simply limiting the size of the nonce, as 
described in the PSA profile?

Carsten covered 7.2.2 and 7.2.3.  7.2.4 doesn't give me warm fuzzies 
because it's not even clear what you mean in this case. For key 
identification, it would have been better to read, “When using JWS, do 
the following.”  Otherwise, Section 6 reads as under-specified, meaning 
that different profiles can implement the same identification method and 
not be interoperable.

At the end of the day, if you still need a profile, hopefully it would 
be a LOT smaller, and a lot better structured as Toerless mentioned.  To 
me, a WG should argue over every last aspect that could be profiled, 
where a profile is the absolutely last option.

Eliot


On 08.06.22 01:26, Laurence Lundblade wrote:
> (sending again with corrections and because it doesn’t seem to have 
> posted to the archive)
>
> Hi Elliot,
>
> To me EAT inherits extant interoperability issues in CBOR, COSE and 
> CWT. Or perhaps we say EAT is a framework like CBOR, COSE and CWT. 
> With profiles, EAT takes the issue head-on and does something about it.
>
> Yes, I sometimes think “I” in IETF is for interoperability and is 
> fundamental to the IETF culture. I’ve been arguing lately to limit the 
> number of forms of EAT for this reason. I am a bit surprised that 
> CBOR, COSE and CWT don’t deal with the issue more directly. I really 
> do believe in interoperability — and this belief led me to write much 
> of the profiles section (kind of wondering what people would say).
>
> Here’s some of the issues:
>
>     CBOR — RFC 8949 clearly allows for both indefinite and definite
>     encoding. If one implementation chooses one and another the other,
>     there will not be interoperability.
>
>     COSE — No algorithms are mandated, not even for a receiver. No
>     full key identification scheme is mandated (CMS at least had this).
>
>     CWT — There are no required claims to send or to be able to receive.
>
>     CBOR/JSON/… — This is somewhat new particularly with CDDL now
>     useful to specify multiple encodings. RFC 8428 has this issue.
>
>
> To me this flexibility and consequently these interoperability issues 
> are built in to the frame up and approach not only for EAT, but also 
> for CBOR, COSE and CWT. I don’t think we want to change that approach. 
> For example, we want the CBOR encoding flexibility and we want the 
> COSE algorithm and key identification flexibility in specifications at 
> this level.
>
> I can see adding some more wording to EAT that gives the background 
> I’ve given above in the profiles section. I can’t see changing the 
> approach to start mandating algorithms and encodings. Maybe there’s 
> something else to do?
>
> Also, I don’t think PSA token gives tight interoperability. It doesn’t 
> say which algorithms to use or how key identification works. Maybe 
> that is OK. Maybe it is not.
>
> FIDO is a protocol that I know gives complete interoperability. For 
> example in FIDO you MUST implement all of a set of crypto algorithms 
> on the server side; the client side gets to  choose.
>
> One more comment below.
>
> LL
>
>
>
>> On Jun 5, 2022, at 5:57 AM, Eliot Lear via Datatracker 
>> <[e-mail]> wrote:
>>
>> Major:
>>
>> The most major problem with the document is this:
>>
>> 7.  Profiles
>>
>>   This EAT specification does not gaurantee that implementations of it
>>   will interoperate.  The variability in this specification is
>>   necessary to accommodate the widely varying use cases.  An EAT
>>   profile narrows the specification for a specific use case.  An ideal
>>   EAT profile will guarantee interoperability.
>>
>> This is quite counter-cultural to the IETF.  You start with the
>> smallest set of functionality and then expand outward to cover
>> different use cases that make use of different extensions.  I'm
>> not saying that profiles would not be necessary, but that some
>> additional thought be given to extension mechanisms.
>>
>> This statement in particular is quite disturbing.
>>
>>   In some cases CDDL may be created that replaces CDDL in this or other
>>   document to express some profile requirements.
>
> CoSWID is doing this with COSE.
>
>>
>> Not only is this counter-cultural, but it would require an Updates:
>> header on any such profile, and would further just be plain out
>> confusing.
>>
>> In short, the profile mechanism is harmful to the very concept of
>> interoperability.
>
>