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? One more thing, I'm thinking we also need to decide how to handle the HPKE Export-Only AEAD in COSE. Regards, Daisuke 2022年11月21日(月) 18:06 Hannes Tschofenig <[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]> *On Behalf Of * Laurence Lundblade > *Sent:* Saturday, November 19, 2022 10:06 PM > *To:* cose <[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] > https://www.ietf.org/mailman/listinfo/cose >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
