On Wed, May 31, 2023 at 10:13:39AM -0700, Laurence Lundblade wrote: > 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).
The context "Enc_Recipient" has a clear purpose: To be used in AEAD- capable algorithms used in recipient slot. And the reason why it is not currently used is that there are currently no AEAD-capable algorithms used in recipient slot. > 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 COSE_KDF_Context is part of key derivation for ECDH. And this can in some situations create a bit silly results: Imagine a alg that combines ECDH-ES with AEAD-capable key wrap. That would use both COSE_KDF_Context and Enc_structure, protecting the headers twice! > 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). The two-layer structure using Enc_structure with context "Enc_Recipient" is correct, because HPKE is AEAD-capable and goes into recipient slot. And I think the binding to sender/receiver is just misdesigned. Binding unauthenticated sender makes no sense. Lifting sender from signed envelope, sure, but COSE_KDF_Context can not do that. And COSE_KDF_Context contains a field (key size) that just plain does not make sense with HPKE. This is because COSE_KDF_Context is meant for KDF function in COSE, but HPKE has its own internal KDF mechanism that works differently. > 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. RFC 9052 is pretty clear on when it is used. And the present two-layer HPKE design does hit the criteria that trigger its use. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
