Hi Hannes, > On Mar 12, 2023, at 8:31 AM, Hannes Tschofenig <[email protected]> > wrote: > > Hi Laurence, Hi Daisuke, > > > in a recent email you wrote: > > >> I think an Enc_structure (5.3 in 9052) with context “Enc_Recipient” is > >> what should be given to SealBase for the aad parameter. Also, I think > >> the info parameter to SealBase here should be “”. > > > There are two cases to consider, namely > > * the one layer mode, and > > * the two layer mode. > > > For the one layer mode using the Enc_structure as input to the aad > parameter of SealBase seems correct to me. A caller can still put > further aad information into the external_aad structure, one of the > fields in the Enc_structure. > > For the two layer mode I believe you are wrong. When the COSE RFC was > written HPKE did not exist. In no other place in the COSE spec you > provide the Enc_structure to the recipient structures. Hence, Jim > couldn't anticipate that there would be a HPKE spec asking for info and > aad parameters.
The ECDH key agreement in 6.3 are very close to HPKE and the ones in 6.4 are even closer. It looks to me like Jim did implement these. He certainly did implement AEADs. There are examples / test data of this here: https://github.com/cose-wg/Examples/tree/master/ecdh-wrap-examples. I didn’t check them to confirm how Enc_Recipient works, but we can. > Instead, Section 5.3 of RFC 9052 talks about > authenticated data structure in context of the AEAD cipher used at the > lowest level -- the COSE_Encrypt and COSE_Encrypt0 structure rather than > the recipient structures. > > The Enc_structure becomes the additional authenticated data for the > AEAD. I also took a (very) brief look at Jim's code and I couldn't find > the place where he puts the Enc_structure into the AAD of the recipient > layer. Look for COSE_Encrypt_Build_AAD() called in COSE_Recipient_encrypt(). The Externally Supplied Data comes in through a someone global context. I’m about 80% convinced from looking at Jim’s code. > What information is passed to the HPKE information at the recipient > layer should be kept flexible, as it is currently the case in the > COSE-HPKE draft (with the info structure) and as it is also done in RFC > 9053 since the content is application dependent. Here is what Section > 5.2 of RFC 9053 says about the information structure: > " > > The context information structure is used to ensure that the derived > keying material is "bound" to the context of the transaction. > > " > > > Specifications using COSE-HPKE know about the context and will have to > populate the fields accordingly. In COSE the extra info to be bound into the integrity protection goes in protected header parameters or in Externally Supplied Data — the AAD input to COSE at the top level. To allow input directly into the key agreement algorithm would be disruptive to the COSE ecosystem and implementations because not all key agreement algorithms may support that. It wouldn’t really even be compliant with the COSE standard. I will admit that it does seem like the use of Enc_Recipient is a little degenerate and could be viewed as unnecessary. Enc_structure = [ context : "Encrypt" / "Encrypt0" / "Enc_Recipient" / "Mac_Recipient" / "Rec_Recipient", protected : empty_or_serialized_map, external_aad : bstr ] The external_aad is already protected at level 0, so it’s presence here is a little redundant. That leaves only the protected headers and the context string. One might think that this could have been simpler by just giving the protected headers to the AEAD. I suspect it is so for consistency and because the binding to “Enc_Recipient” helps with some attacks. Personally, I don’t see HPKE as that big an increment over what is there in the key agreement algorithms that COSE already defined. The problem with integrating HPKE with COSE is not that COSE didn’t anticipate stuff like this, it’s more that both COSE and HPKE see themselves as the dog, not the tail. The more I look, the more I think Jim did a huge amount of work and was way ahead of the rest of us — may he rest in peace. LL
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
