Still trying to keep this to objective facts and not express any opinion of mine.
> On Jun 30, 2023, at 10:53 AM, Ilari Liusvaara <[email protected]> > wrote: > > On Fri, Jun 30, 2023 at 05:29:32PM +0000, lgl island-resort.com wrote: >> >> >> 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: >> >> COSE_Sign1 and COSE_Sign+COSE_Recipient >> Single integer — The integer specifies the hash, signing algorithm and >> the curve > > It does not specify the curve (it does in JOSE, but not in COSE). Yes, you are right about that. My mistake. Also, I wrote the title wrong. It should be COSE_SIgn1 and COSE_Sign+COSE_Signature. >> 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. > > Yes, one can also do ECDH as follows: > > * COSE_Encrypt bulk alg, e.g. AES-GCM > * COSE_Recipient alg, e,g, A128KW > * ECDH alg, e.g., ECDH-ES + SHA256 > * Curve which comes from the key, e.g. NIST P-256 > > 3 algs, plus key subtype... Yes, that is described in Appendix B of RFC 9052, but ECDH-ES + A128KW (-29) is a short-cut for it. There’s no point in using that particular 3-layer structure. > Then COSE is not limited to 3 layers, even if nobody has yet invented > use for that yet. > > >> COSE_Key >> A single algorithm identifier from the same space used by >> COSE_Sign1…COSE_Recipient plus a curve identifier for EC keys. > > The alg there is optional. Not a good idea with symmetric algorithms, > but asymmetric algorithms are much less troublesome without alg in key. > > >> 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). > > The point is that there is no single ciphersuite, but the information is > disaggregated. Let’s call it partially disaggregated. There is aggregation of (pub key alg + HKDF + Keywrap) in ECDH-ES + A128KW (-29), and that aggregation doesn’t include the bulk content encryption algorithm or the curve. There is aggregation within major COSE structures and messages, but disaggregation when multiple COSE structures and messages are combined. Plus COSE disaggregates the curve. I also would say that there is no kind of vector, tuple, array or map in COSE or JOSE that is akin to “hkc”. There is nothing in to COSE or JOSE that does the kind of disaggregation in “hkc”. COSE-HPKE had to invent a new structure for it. LL _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
