It seems to me that RFC 9052 section 5.3 defines an Enc_structure with context “Enc_Recipient”, but nothing in RFC 9052 or 9053 makes use of it. I’m 75% confident that Jim’s code does the same. This is confusing and seems a dark corner of COSE that needs illuminating.
The purpose of Enc_structure with context “Enc_Recipient” would seem to be for COSE_Recipients that are used in COSE_Encrypt. It’s how the integrity protection of the protected headers is achieved, how the COSE_Recipient is bound into a COSE_Encrypt (so it can’t be cut/paste into a COSE_Mac) and how Externally Supplied Data is double-protected (previous HPKE-related discussion about this). BUT, all the ECDH + HKDF key agreement methods use RFC 9053 section 5.2 COSE_KDF_Context (AKA Info struct) instead. COSE_KDF_Context definitely covers the protected headers. It also provided binding to sender/receiver and some other bindings. Look at all the encrypt key agreement methods in 9053 section 6 and see none use Enc_structure: - ECDH + HKDF — COSE_KDF_Context is always the input to the info parameter for HKDF - Key wrap — Not possible to protect the headers, so nothing, no use of Enc_structure or COSE_KDF_Context - Direct — Same as key wrap In HPKE we defined use of Enc_structure with context “Enc_Recipient” as the “info” parameter to SealBase. I now believe that was wrong and it should be COSE_KDF_Context instead. I don’t think the extensive context hashing in HPKE provides everything that COSE_KDF_Context does (maybe HPKE Auth mode does, but Base mode doesn’t bind to sender/receiver). I’m almost convinced that Enc_structure with context “Enc_Recipient” should never be used and that we should always use COSE_KDF_Context because it provides a lot more. OR THIS — Get rid of COSE_KDF_Context. Replace it with a bunch of protected header parameters to hold the similar values. Use Enc_structure with context “Enc_Recipient” and feed that into the info parameter of HKDF and SealBase. That would be much cleaner and in line with the rest of COSE. Implementations could just reuse parameter encoding/decoding code. Probably too incompatible with published RFCs for this change though. Basically, some of the key agreement methods have an “info” parameter that can protect additional data (HKDF and Seal) and some don’t (keywrap and direct) (some new-fangled key wrap could have this though). COSE_KDF_Context is too-specifically associated with HKDF when it probably should be general and/or turned into COSE header parameters (I believe COSE_KDF_Context is cloned from previous CMS-related work). LL _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
