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
(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 <noreply@xxxxxxxx> 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.
Attachment:
OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
