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
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
