> On Mar 13, 2023, at 4:08 AM, Hannes Tschofenig <[email protected]> > wrote: > > Hi Laurence, >
From a deeper look it seems we're both right... > thanks for the feedback. A few remarks below: > > > >> 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 >> <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. >> > Section 6.3 of RFC 9053 specifies a content key distribution with direct key > agreement. The DH-derived key is fed into a key derivation function and the > resulting key is then used as a content encryption key. Hence, there is no > AES computation as part of the recipient layer. > Right. > > Section 6.4 of RFC 9053 goes one step further and uses a content key > distribution with key agreement plus key wrap. Here the DH-derived key is fed > into the key derivation function and then serves as a KEK to encrypt a > CEK with AES-KW. AES-KW is not an AEAD cipher and has no public parameters > that vary on a per-invocation basis. COSE does not specify other key wrap > algorithms other than AES-KW. > Right. > FWIW an example of the mechanism described in Section 6.4 is shown in > Appendix B of RFC 9052. > > > > Jim implemented AEADs but not in the way we use it. > Right. > >>> 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. >> COSE_Recipient_encrypt() is the code to build a COSE_Recipient and it is used for all the different key distribution methods that a COSE_Recipient can use that are defined in 9053. Cose_Recipient ALWAYS calls COSE_Encrypt_Build_AAD() which builds an “Enc_Recipient” type of Enc_structure. COSE_Encrypt_Build_AAD() ALWAYS uses the Externally Supply AAD for external_aad. BUT, it never uses the output of COSE_Encrypt_Build_AAD() because, as you say above and Illari says elsewhere, Jim never implemented any COSE_Recipient like HPKE that takes AAD as input. Good thing I only said 80% convinced. I read your -04 draft. It is clear. It is workable and I believe it aligns with Jim’s code and with 9052. However, it doesn’t seem so strongly stated in 9052 that we couldn’t consider an alternative. If I understand correctly Illari recently suggested that external_aad be an empty bstr in COSE_Recipients. I see some implementation benefits to this. The Externally Supplied AAD would only be processed at layer 0 and wouldn't have to be passed to COSE_Recipient creation saving some code. Theoretically, Externally Supplied AAD can be large which means you have to either have a buffer to hold the entire Enc_structure. While you can’t avoid this at layer 0 it might be nice to avoid it at layer 1. I don’t see a security issue here. The Externally Supplied AAD is covered just fine at layer 0. We could specify this only for HPKE. I don’t think this is a big deal either way and what’s in the -04 draft is OK, but thought I’d bring up the alternative. Also, It seems like there should be Errata for 9052 here. It could say either it is always Externally Supplied AAD, always an empty bstr or it varies with the key distribution method. I will fork the SealBase info parameter discussion into a separate thread. LL
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
