On Jun 29, 2023, at 1:41 PM, Ilari Liusvaara <[email protected]<mailto:[email protected]>> wrote:
On Thu, Jun 29, 2023 at 04:00:09PM +0000, Jeremy O'Donoghue wrote: The short version is that I *strongly* prefer a single “alg” integer to further parameterise the key usage space. The use of a construction like “hkc” is almost certain to complicate interoperability and testing. Large-scale systems may be able to support many options, but constrained systems rarely have that luxury. While configuration or profile documents can help, there is generally a risk over time of there being a large enough number of configurations that they no longer help very much as everyone chooses his/her favourite. There has *never* been "single alg parameter" in COSE. Even in stock RFC 8152, Message recipients can involve *three* different alg parameters (+ fourth thing). It is my goal that this message have no opinion of mine, that it is just a summary of IDs used in RFC 8152, 9052 and 9053. COSE_Sign1 and COSE_Sign+COSE_Recipient Single integer — The integer specifies the hash, signing algorithm and the curve COSE_Mac0 Single integer — the HMAC alg COSE_Encrypt0 Single integer — the bulk content encryption alg COSE_Encrypt+COSE_Recipient or COSE_Mac+COSE_Recpient This is the one of interest. It has at least two algorithm identifiers: * The COSE_Encrypt bulk content encryption algorithm, typically AES-GCM * The COSE_Recipient algorithm In the case of ECDH, the curve comes from the key, not from the algorithm ID, so for RFC 9053 6.3 and 6.4 encryption there are 3 identifiers: * COSE_Encrypt bulk alg, e.g. AES-GCM * COSE_Recipient alg, e,g, ECDH-ES + A128KW * Curve which comes from the key, e.g. NIST P-256 There is also the case of nested COSE_Recipients, in which case there is an algorithm identifier per nesting level. COSE_Key A single algorithm identifier from the same space used by COSE_Sign1…COSE_Recipient plus a curve identifier for EC keys. While a COSE_Encrypt may have more than one algorithm identifier, that algorithm identifier is never a tuple, vector, array or map like “hkc". It is alway a single integer (or string). Also, I looked through the COSE message archive going back to 2015 to see if this was discussed. I found almost no discussion. It looks to me like the single specifier was inherited from JOSE. JOSE also has no tuple, vector, array or map for specifying anything like “hkc”. Would appreciate confirmation that this is a correct summary — maybe before going on to subjective opinions. LL
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
