Moving from facts to opinion: So, right, COSE doesn’t have a perfect full cipher-suite. The HPKE triple is still a new construct that doesn’t occur in COSE (or JOSE) and makes COSE-HPKE a special case.
Here’s an example of a command line tool I’m building to encrypt and sign CWT and EAT. You will be able to specify the encryption and signing alg with something like “-sig_alg -7 and -enc_alg -29” (COSE integer alg IDs). With HPKE’s triple, I’ll have to create new special command line arguments. Similarly, the two libraries on which the tool is built will also have special-case APIs for COSE-HPKE. I expect this scenario to be replicated many times, perhaps very many times if COSE is a big success. APIs, command lines and COSE-using protocols will often have to add a special case for the HPKE triple. If we stick with the integer, they don’t. It is true that some of these might need stuff in addition to the single integer such as for the EC curve and the bulk content encryption alg, but the HPKE triple is still a special case over and above that. In my command line tool, I’ll easily infer a bulk content encryption algorithm from the recipient algorithm. COSE_Key may turn out to be really useful. It is starting to look like it could provide a clean and simple one-stop replacement for the DER formats that are spread across many RFCs ( RFC 5915, RFC 8017, RFC 8410, RFC 5958…) While the alg restriction is optional, it is useful, and it is nice that it is mostly unified with the algorithm specification in the rest of COSE. The HPKE triple creates a special case here too. (This is just one aspect related to compatibility with COSE infrastructure; coding, ease of upgrading and other are further aspect<https://mailarchive.ietf.org/arch/msg/cose/_Ye4wT9DnNvlnDMopM0BMak9ZbI/>s) LL On Jul 2, 2023, at 11:54 PM, Ilari Liusvaara <[email protected]<mailto:[email protected]>> wrote: On Sun, Jul 02, 2023 at 06:10:59PM +0000, lgl island-resort.com<http://island-resort.com> wrote: Here’s the improved description of IDs used that I promised with a new summary at the end COSE_Key A single algorithm identifier from the same space used by COSE_Sign1…COSE_Recipient plus a curve identifier for EC some keys. While the alg here is optional, it is a fact that it is a singe alg ID that is unified with all the above. It is only unified with the innermost one. Summary - COSE aggregates into a single identifier for each major structure like COSE_Encrypt or COSE_Recipient However, it composes those. - Sometimes COSE aggregates the EC curve ID and sometimes the curve ID comes from the key I think the aggeration is only for one special snowflake (ES256K). - While COSE and JOSE don’t use complete ciphersuites they never disaggregates the way HPKE does The result of composition can pretty much be disaggregation to similar level than in HPKE: Suppose you have a x448 key, and want to do ECDH-ES with it at nominal strength. Single-recipient setting: 1) The key specifies type 1 / subtype 5. 2) The only alg is -26. 3) Bulk cipher can be 3 or 24. This seems like similar three-way split as in HPKE. Multi-recipient setting: 1) The key specifies type 1 / subtype 5. 2) The only alg is -26. 3) Key wrap has to be -5 (however, 3 and 24 could be interpretted as allowed[1]). 4) Bulk cipher is 3 (or 24 if that could be used for key wrap This is four-way split, similar as in HPKE performing key wrap. [1] There is mechanism called iv-generation. It is only documented in conjunction with "Direct Key with KDF"[2], but I see no technical reason it would not work with "Direct ECDH". It would unlock using AES-GCM/Chacha20-Poly1305 for key wrap (of course, no existing implementation supports that). [2] As aside, that can be used to construct a situation that actually uses "Enc_Recipient". -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
