Here’s the improved description of IDs used that I promised with a new summary at the end
This alg ID topic is just one aspect of the whole discussion. It’s a ton of work to write complete factual statements like this that answer every little comment (many of which IMO don’t really change the fundamental facts, but make it seem like there’s a problem). 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 sometimes the curve Curve — In the case of EC, the curve is not specified by the single integer 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. Appendix B is an example of three levels, but in alg ID -29, -30 and -31 are a two-level short cut for it that is much preferred. 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. While a COSE_Encrypt message may have more than one algorithm identifier, that algorithm identifier is never a tuple, vector, array or map like what is used in “hkc” or HPKE_sender_info. Summary - COSE aggregates into a single identifier for each major structure like COSE_Encrypt or COSE_Recipient - COSE does not aggregate into a complete ciphersuite across major structures - Sometimes COSE aggregates the EC curve ID and sometimes the curve ID comes from the key - COSE algorithm IDs **roughly** align with JOSE - While COSE and JOSE don’t use complete ciphersuites they never disaggregates the way HPKE does I believe I’m just stating fact here about COSE and JOSE. I’ve tried to keep my opinion out of it. LL
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
