This is an attempt to structure this as an engineering trade-off decision between pros and cons. I’m setting this up as a choice between 1) a single integer alg ID like most of COSE today and 2) a data structure holding a triple like we have in the latest COSE-HPKE draft.
I’m trying to structure here with the facts and trade-offs separate from my personal opinion. Hoping that we can agree on some of the facts, even if we don’t have the same opinion. Compatibility with COSE COSE today centers around a single integer algorithm ID. This is the only type of algorithm ID defined in 9052 and 9053. It is used in all the message types and for COSE_key. Any algorithm negotiation scheme built as suggested in 9052 section 10 is going to support a single integer because most of COSE uses it. As COSE is used more widely, other protocols and facilities will need to identify algorithms. For example, X.509-like certificates. We won’t just see algorithm identification in the COSE RFCs. My opinion: I prefer the single integer. The triple is something many COSE-using projects and protocols won’t do by default where the integer is. Ease of Coding Is it easier to pass an integer around or a structure? What about error conditions and code size? For the integer option, some code to map the integer to the three alg inputs to HPKE is needed. but that is not too complex and similar already exists in COSE for things like ECDH-ES (alg -29). For the 3-item structure code is also needed. It will have some error conditions that decoding a single integer won’t. My opinion: It’s not a big deal either way, but I prefer the single integer, based on work in t_cose. Facilitating Algorithm Choice What I bring up here is how implementors and deployers will choose what algorithm(s) to use. How will the pick from the lists of available algorithms? With a single integer we’ll only define a subset of all the combo’s of what’s possible. We can make the decision easier for many by providing fewer choices (and if someone doesn’t like the combo we’ve defined, they have to either go to the trouble to define a new one or use one in the proprietary space). On the other hand, with the triple, the full fanout of the choice is theirs and there is full flexibility. My opinion: I lean to the single integer and limited choice because I think too much choice is not helpful or necessary and many combos don’t make sense. That said, I can see how some want the full mix-and-match. Note that COSE ECDH-ES already has the exactly the same fan-out problem and seems to manage without a triple. Ease of adding a new HPKE KEM (or other alg) This is about what happens when we need a new KEM, say for PQ. With the triple, the KEM just gets registered and everything is done as far as alg IDs and documents. There will still need to be a major SW update for anyone to know about the new KEM. With the integer ID, a new integer ID must be created, documented and registered in addition to the addition to the HPKE registry. The document only has to be informational though. So the integer ID means some extra registrations and an informational document. My opinion: Some advantages for the triple, but probably the SW update that needs to be done no matter what sort of ID we use is a much bigger task. Also, the number of new algorithms registered should small, like two or three. LL P.S. If of interest, here’s a few of the reasons I’ve changed my mind. At first I was interested in just getting something workable agreed upon that wasn’t too bad. Over the last months I’ve come think more about how COSE works as a ecosystem including COSE_Key and algorithm negotiation and came to see the single integer as a cleaner solution. Then Orie and Christopher Wood chimed in supporting the single integer. On Jun 7, 2023, at 9:45 AM, Ilari Liusvaara <[email protected]<mailto:[email protected]>> wrote: On Wed, Jun 07, 2023 at 07:25:48AM -0500, Orie Steele wrote: HPKE should work without creating new key types for dh kems, and should work with existing APIs that currently generate keys and envelopes based on alg. The first part works, and I have written an implementation. The second part has _never_ worked in either JOSE nor COSE. I believe the current record is 5 different key subtypes for one alg (for both COSE and JOSE)! A single equality check should confirm if the suite is acceptable to the recipient, if they have a restricted key. And what about check if suite is acceptable for _sender_? I think that barring a major flaw in HPKE, there is no need for recipient to ever have a restricted key. Interop is separate matter, and there can be many different supported combinations. The size and expression of the alg value, should be debated, but following the conventions and fully specifying HPKE with alg, should be resolved first. The convetion in COSE is to _not_ have ciphersuites. The some stuff that looks a bit like ciphersuites is just size optimizations. COSE HPKE will need to update registries, so let's make the minimal updates necessary to support what the industries wants to use. I think the minimum number of registry changes possible is 3. - A new alg - A new header parameter - A new key type or a reserved crv range. We don't need to create new key types. It is much cleaner to create a new key type than to reserve a crv range. How is HPKE KEM 48 represented in _systematic_ manner? We don't need to expose a new way to parameterize alg. Doing so saves a lot of work. If we don't know which alg values for COSE HPKE need to be registered, we can wait till people show up who do. What we do know is that it is either going to be a long list among time or 1 up-front. A simple RFC that follows conventions doesn't take long to update the registry. It is still unnecressary work. -Ilari _______________________________________________ COSE mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/cose
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
