On Mon, Oct 30, 2023 at 10:28:25AM +0000, lgl island-resort.com wrote: > > > On Oct 30, 2023, at 2:02 AM, Ilari Liusvaara <[email protected]> > > wrote: > > > > On Mon, Oct 30, 2023 at 05:37:11AM +0000, lgl island-resort.com wrote: > >> > >> COSE-HPKE could use an Enc_structure of type “Enc_Recipient”. I think > >> that’s what we were doing before 07. It is probably the simplest, > >> but it doesn’t afford all the stuff in Context Information Structure, > >> but you could maybe put some of that into Enc_structure by putting > >> equivalent fields in newly defined protected headers. > > > > It must use Enc_structure/Enc_Recipient. Using CIS does not work. > > Not sure why CIS can’t be used, but let’s assume we’ll use > Enc_structure/Enc_Recipient.
- Both variants have to do the same thing. - There is no contextualization in CIS. - The key length makes absolutely no sense. - Non-interoperable due to quickly hitting (ridiculously small) HPKE limits. > How are next algorithm and salt included in Enc_structure/Enc_Recipient? > You say they are important above. I agree that they are definitely > useful and possibly important. Salt is not needed as HPKE is ES-type (not SS-type), next algorithm is done internally by HPKE. > Also seems like we want an application context naming string to be > included in the key set up context. When CIS is used, we can put that > in SuppPubInfo.other. Because HPKE is ES-type, it does not have to be in key set up context, one can use external aad instead. > The Enc_structure/Enc_Recipient structure goes into the the “info” > parameter, not the “aad” parameter for Seal<MODE>(), right? No, Enc_structure goes to the aad parameter. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
