Hi Daisuke So far I haven’t seen the use case but maybe there is one. Let me know if you run into one and we should discuss it
Ciao Hannes From: AJITOMI Daisuke <[email protected]> Sent: Wednesday, November 23, 2022 12:58 AM To: Hannes Tschofenig <[email protected]> Cc: Laurence Lundblade <[email protected]>; cose <[email protected]> Subject: Re: [COSE] The main two COSE-HKPE modes 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]<mailto:[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]<mailto:[email protected]>> Sent: Monday, November 21, 2022 11:55 PM To: Hannes Tschofenig <[email protected]<mailto:[email protected]>> Cc: Laurence Lundblade <[email protected]<mailto:[email protected]>>; cose <[email protected]<mailto:[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]<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]<mailto:[email protected]>> On Behalf Of Laurence Lundblade Sent: Saturday, November 19, 2022 10:06 PM To: cose <mailto:[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 mailto:[email protected]<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. 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
