> > 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?
How would HPKE Export-Only AEAD impact the integration into COSE? What I wanted to say was that the encryption/decryption algorithm for the Export-Only AEAD is not specified in the COSE layer like existing COSE algs or HPKE algorithms other than Export-Only AEAD. It means that it is necessary for the applications to pass encryption/decryption functions using HPKE's export() to the COSE layer. Therefore, the COSE library needs to have a new and different interface for this. >From a library implementor's point of view, I don't want to put effort into implementing a feature that has little need, so I'm thinking that not supporting the Export-Only AEAD would be an option. Regards, Daisuke 2022年11月22日(火) 17:58 Hannes Tschofenig <[email protected]>: > FWIW both modes are already described in draft-ietf-cose-hpke. > > COSE_Mac/COSE_Mac0 and COSE_Sign1/COSE_Sign are wrappers covering the > entire COSE_Encrypt/COSE_Encrypt0 payload. > > How would HPKE Export-Only AEAD impact the integration into COSE? > > Ciao > Hannes > > From: AJITOMI Daisuke <[email protected]> > Sent: Monday, November 21, 2022 11:55 PM > To: Hannes Tschofenig <[email protected]> > Cc: Laurence Lundblade <[email protected]>; cose <[email protected]> > Subject: Re: [COSE] The main two COSE-HKPE modes > > 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 <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 <mailto:[email protected]> On Behalf Of Laurence Lundblade > Sent: Saturday, November 19, 2022 10:06 PM > To: cose <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 > mailto:[email protected] > https://www.ietf.org/mailman/listinfo/cose > 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
