> On Nov 17, 2022, at 9:17 AM, Hannes Tschofenig <[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]>
> Sent: Thursday, November 17, 2022 4:55 PM
> To: Hannes Tschofenig <[email protected]>
> Cc: Ilari Liusvaara <[email protected]>; cose <[email protected]>
> Subject: Re: [COSE] AEAD algorithm ID for HPKE
>
> Hi Hannes
>
>> On Nov 17, 2022, at 3:09 AM, Hannes Tschofenig <[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.
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
