> On Nov 21, 2022, at 2:55 PM, AJITOMI Daisuke <[email protected]> wrote: > > Hi Laurence, > > Thanks for summarizing the two ways. Basically, I agree with you too. > > Two-layer mode, usually multiple recipients > > - Always COSE_Encrypt and there is always a COSE_Recipient > > > COSE_Mac is also acceptable, right?
Yes of course. > > One more thing, I'm thinking we also need to decide how to handle the HPKE > Export-Only AEAD in COSE. Can you say more? What is the purpose and/or an example use case? Seems like this comes for free in the one-layer mode. Would we really want it for the two layer mode? LL > > Regards, > Daisuke > > 2022年11月21日(月) 18:06 Hannes Tschofenig <[email protected] > <mailto:[email protected]>>: > Hi Laurence, > > > > I agree with your assessment that we need both mechanisms. Nice summary of > the two modes. > > > > Just a small note regarding this statement: > > “ > > I think this is also important to have a more COSE-centric integration of > HPKE — If you read section 5 of RFC 9052 and section 6 of RFC 9053, you get > the sense that the one-layer Encrypt0 is mostly intended for very simple use > cases without a key ID and probably not for public key-based crypto. > Everything in section 6 of RFC 9053 , all the public key-based encryption, > goes in a COSE_Recipient. It seems like the COSE authors thought the > content/body algorithm was always a content encryption algorithm like > AES-CCM-16-64-128 and never a public key algorithm like HPKE or ECDH. > > “ > > > > Jim may have had this in mind but it also predates HPKE. Hence, it is a bit > hard to second-guess what the intention was. > > > > Ciao > Hannes > > > > > > From: COSE <[email protected] <mailto:[email protected]>> On Behalf > Of Laurence Lundblade > Sent: Saturday, November 19, 2022 10:06 PM > To: cose <[email protected] <mailto:[email protected]>> > Subject: [COSE] The main two COSE-HKPE modes > > > > Here’s how I’m thinking the two ways HPKE integrates with COSE: > > > > One-layer mode, always single recipient > > - Always a COSE Encrypt0 and there is never a COSE_Recipient > > - Algorithm ID for content/body header param is HPKE > > - Further header parameter(s) indicate KEM, AEAD, HKDF using HPKE algorithm > IDs > > - Also the “enc” output from HPKE is carried in a header parameter > > - Content/body ciphertext is the direct output of HPKE > > - There is no CEK, just the inner workings of HPKE > > > > You could this describe this as full-on HPKE. COSE is contributing very > little here. > > > > It seems good to have this mode for people that are primarily into HPKE and > maybe see COSE as incidental. It almost exclusively involves HPKE algorithm > IDs. You could think of it as providing almost the simplest possible encoding > of HPKE in CBOR. > > > > The one thing it can’t do is multiple recipients (but maybe HPKE does > multiple recipients on its own some day). > > > > > > Two-layer mode, usually multiple recipients > > - Always COSE_Encrypt and there is always a COSE_Recipient > > - Usually multiple recipients but it is allowed for there to be only one > COSE_Recipient > > - The algorithm ID for content/body header param is one of the COSE content > encryption algorithms already standardized > > - There is a CEK that exists outside of HPKE > > - Body ciphertext is the output of the COSE content encryption algorithm > > > > - Algorithm ID for COSE_Recipient is HPKE > > - COSE_Recipient header parameter(s) indicate KEM, AEAD, HKDF using HPKE IDs > and are from HPKE ID space > > - Also the “enc” output from HPKE is carried in a header parameter > > - The HPKE AEAD is just for wrapping the CEK > > - ciphertext in COSE_Recipient is output of HPKE and is a wrapping of the CEK > > > > - There may be other COSE_Recipients that are not HPKE along side the HPKE > COSE_Recipient > > > > You could describe this as typical COSE with an HPKE-based COSE_Recipient. > > > > The main use for this is multiple recipients. > > > > I think this is also important to have a more COSE-centric integration of > HPKE — If you read section 5 of RFC 9052 and section 6 of RFC 9053, you get > the sense that the one-layer Encrypt0 is mostly intended for very simple use > cases without a key ID and probably not for public key-based crypto. > Everything in section 6 of RFC 9053 , all the public key-based encryption, > goes in a COSE_Recipient. It seems like the COSE authors thought the > content/body algorithm was always a content encryption algorithm like > AES-CCM-16-64-128 and never a public key algorithm like HPKE or ECDH. > > > > > > So, I think it’s important to have both of these two modes supported well. > The first for the HPKE-oriented crowd and the second to fit in better with > the COSE design intent and to support multiple recipients. > > > > LL > > > > > > > > > > > > > > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > _______________________________________________ > COSE mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/cose > <https://www.ietf.org/mailman/listinfo/cose>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
