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

[Laurence Lundblade <[e-mail]>]

(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] <mailto:[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.