Hi Laurence, I indeed took the CDDL for the COSE_Recipient structure from the RFC and renamed the ciphertext field to encCEK to reduce confusion (since otherwise we have two structures named ciphertext just at different layers).
* There’s no need for a key wrap and KEK because Ilari says it’s OK to use HPKE Seal() to encrypt the CEK. That’s also my impression. Ciao Hannes From: Laurence Lundblade <[email protected]> Sent: Thursday, November 17, 2022 11:09 PM To: Hannes Tschofenig <[email protected]> Cc: Ilari Liusvaara <[email protected]>; cose <[email protected]> Subject: Re: [COSE] AEAD algorithm ID for HPKE Importance: High On Nov 17, 2022, at 9:17 AM, Hannes Tschofenig <[email protected]<mailto:[email protected]>> wrote: Hi Laurence, I will update the draft based on your request. Give me till tomorrow to present a PR for you to review. No rush on my part :-) Regarding your concern: I don’t know if HPKE can output a CEK the way ECDH does and even if it did that doesn’t give you multiple recipients with a shared CEK. It is important to note that there are two plaintexts here at play. Based on the terminology used here (*) they are: 1. The plaintext that leads to the value in the ciphertext field at layer 0 (COSE_Encrypt structure). 2. The plaintext that leads to the value in the corresponds to the encCEK field at layer 1 (COSE_recipient structure). Only #2 is encrypted by HPKE. #1 is encrypted using a regular COSE encryption algorithm. The way the two layer structure works is as follows (at least right now): 1. Generate a random CEK. This becomes the plaintext for HPKE. When HPKE is applied to it, it will be called encCEK in the COSE_recipient structure). Here’s the CDDL for COSE_Recipient from RFC 9052. COSE_recipient = [ Headers, ciphertext : bstr / nil, ? recipients : [+COSE_recipient] ] Seems like “encCEK” is just “ciphertext" in the above CDDL. I suppose it doesn’t matter what you call it in the CDDL as long as it is a bstr after the headers and we’re clear we’re making a COSE_Recipient here. Even if you encrypt a plaintext (=CEK in our case) for multiple recipients, it will still be the same plaintext when decrypted. (Ciphertext will be different, of course.) 2. Then, you encrypt the plaintext that results in ciphertext for layer 0. Does this make sense? I guess I should add a picture or better description in the draft to make this clear (somehow). Seems right. Yes. There’s no need for a key wrap and KEK because Ilari says it’s OK to use HPKE Seal() to encrypt the CEK. LL Regarding the use of a MAC (instead of the digital signature): I can add text too. Ciao Hannes *: / Layer 0 / COSE_Encrypt = [ Headers, ciphertext : bstr / nil, recipients : + COSE_recipient ] / Layer 1 / COSE_recipient = [ protected : bstr .cbor header_map, unprotected : header_map, encCEK : bstr, ] -----Original Message----- From: Laurence Lundblade <[email protected]<mailto:[email protected]>> Sent: Thursday, November 17, 2022 4:55 PM To: Hannes Tschofenig <[email protected]<mailto:[email protected]>> Cc: Ilari Liusvaara <[email protected]<mailto:[email protected]>>; cose <[email protected]<mailto:[email protected]>> Subject: Re: [COSE] AEAD algorithm ID for HPKE Hi Hannes On Nov 17, 2022, at 3:09 AM, Hannes Tschofenig <[email protected]<mailto:[email protected]>> wrote: Laurence & Ilari, there is text in the COSE HPKE draft on how to work with multiple recipients. Sorry I missed that. Section 3.2.1 offers the details, see https://datatracker.ietf.org/doc/html/draft-ietf-cose-hpke-02#section-3.2.1 Let me know if the text is unclear. It should probably say that the content/body header parameter algorithm ID and encryption are per the COSE specification. While this is kind of restating COSE, but I think it would be helpful given the way HPKE is all-encompassing for the one-layer structure. But here’s what seems like a more substantial issue to me: I don’t know if HPKE can output a CEK the way ECDH does and even if it did that doesn’t give you multiple recipients with a shared CEK. A key wrap layer is needed for multiple recipients, one that parallels section 6.4 in RFC 9053. This is still two layers of header parameter and algorithm ID, but three layers of crypto (content encryption, key wrap, public key). The details of how HPKE wraps the CEK are needed. The simple answer could be that the CEK is the plain text input to Seal(), but typically we want to use a specialized key wrap protocol when wrapping keys and Seal() may not be that. Maybe it’s OK though, but the crypto experts that know why key wrap is needed should make that call. Alternatively, we could come up with some way for HPKE to output a KEK. We should describe all this as HPKE for COSE_Recipient in a general way so it can be used with COSE_Mac and COSE_Mac0. This is what RFC 9053 does. Probably this is called HPKE+A128KW, HPKE+A192KW… See 6.4 inRFC 9053. If we were adding this to 9053 it would be a content key distribution method and maybe becomes section 6.5. 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. 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
