> On Nov 17, 2022, at 3:28 AM, Hannes Tschofenig <[email protected]>
> wrote:
>
> Hi Daisuke,
>
> Let us provide a bit of background about the multiple recipient setup.
>
> Imagine a sender wants to encrypt plaintext and wants to share it with
> multiple recipients.
> (The goal here is that all recipients receive the same plaintext. If you want
> to send different plaintext to different recipients then we are back to
> one-layer structure (Section 3.1.1 in the draft)).
>
> The sender encrypts a CEK (Content Encryption Key) using HPKE and places the
> result in the recipient structure. Multiple recipients implies multiple
> recipient structures. Each encrypted CEK looks different but the CEK is the
> same.
> In a second step, the CEK is used to encrypt the plaintext (such as a
> firmware image).
>
> (With AES-KW, used in the SUIT firmware encryption draft, there is another
> option. I am not describing it here.)
>
> Daisuke, you are proposing to put no information as shown below (snippet from
> Github PR). IMHO information has to be provided on how the plaintext is
> encrypted with the CEK.
Yes, in the two layer example there needs to be a COSE algorithm ID and the
body plaintext must be encrypted per the COSE specification.
It is possible in the two layer example that one of the COSE_Recipients is not
HPKE. For example it might be AES Key wrap per section 6.2 of RFC 9053.
In this mode HPKE is fitting into COSE as a COSE_Recipient in a very similar
way as ECDH in section 6.4 of RFC 9053. It is just there to wrap a CEK.
LL
> In the example below this information is absent.
>
> 96_0([
> h'', // **This is the mandatory point to be fixed.**
> {},
> h'',
> [
> [
> h'a10120',
> {
> 4: h'3031',
> -4: {
> 1: 16,
> 5: 1,
> 2: 1,
> 3: h'040..90',
> },
> },
> h'5f..a9',
> ],
> ],
>
> Ciao
> Hannes
>
>
> From: COSE <[email protected]> On Behalf Of AJITOMI Daisuke
> Sent: Wednesday, November 16, 2022 11:25 PM
> To: Laurence Lundblade <[email protected]>
> Cc: Ilari Liusvaara <[email protected]>; cose <[email protected]>
> Subject: Re: [COSE] AEAD algorithm ID for HPKE
>
> Ilari has said most of what I want to say but let me add one point.
>
> > From reading the PR#9 more carefully I see that you put HPKE as the
> > algorithm ID in both the body header and recipient headers.
>
> As I mentioned in the following comment, I think that the alg value for the
> first layer should not be "HPKE" in the Layer Two example and I asked Hannes
> to fix it.
>
> https://github.com/cose-wg/HPKE/pull/9#issuecomment-1288984512
> <https://github.com/cose-wg/HPKE/pull/9#issuecomment-1288984512>
>
> Best,
> Daisuke
>
> 2022年11月17日(木) 4:48 Laurence Lundblade <[email protected]
> <mailto:[email protected]>>:
>
>
>
> On Nov 16, 2022, at 9:00 AM, Ilari Liusvaara <[email protected]
> <mailto:[email protected]>> wrote:
>
> On Wed, Nov 16, 2022 at 08:21:21AM -0800, Laurence Lundblade wrote:
>
>
> It’s taking some time for me to understand HPKE well. Patience
> appreciated. Let me ask a couple questions that seem important and
> clarifying and have you confirm my understanding.
>
> Is the bulk AEAD operation (JUST the bulk operation) on the pt that
> produce the ct the same for HPKE as for the methods in COSE section
> 6? They both can use AES 128 GCM, but it looks to me like they aren’t
> the same because HPKE has a stateful encryption context (HPKE section
> 5.2) and COSE doesn’t. You might be able to use the same AES 128 GCM
> library for both, but the surrounding inputs don’t seem compatible.
>
> Yes, all the surrounding stuff is different, the two only unify in
> the raw AES 128 GCM implementation.
>
> In my implementation, the common part is just the methods
>
> - EncryptionKey::encrypt_buffer_to_buffer()
> - DecryptionKey::decrypt_buffer_to_buffer()
>
> Which implement raw AES-GCM/Chacha20-Poly1305 (EncryptionKey/
> DecryptionKey also contains the algorithm used)
>
> Makes sense.
>
> In this case the body parameter algorithm ID is clearly NOT one of the COSE
> content encryption algorithms registered today from section 4 of RFC 9053
> <https://www.rfc-editor.org/rfc/rfc9053.html#name-content-encryption-algorith>.
> Definitely not A128GCM (1)…, definitely not AES-CCM-16-64-128 (10).
>
>
>
>
> Are we considering whether and how reuse of the HPKE encryption
> context fits into COSE? It is probably not useful in COSE (but
> can see it is critical in TLS).
>
> I don't think there has ever been a proposal for COSE-HPKE to reuse
> the context.
>
> OK. Just checking because I haven’t read all the back history here. Makes
> sense. Possibly the COSE-HPKE draft should mention that.
>
>
>
> How will multiple recipients be handled with COSE-HPKE? In one case
>
> one HPKE recipient may use Edwards curves and another HPKE recipient
> NIST curves. There’s also the possibility that one recipient uses HPKE
> and another something that is not HPKE like AES key wrap from RFC 9053
> section 6.2.
>
> It kind of seems like HPKE was not designed for multiple recipients
> because it was designed in the TLS context. You mentioned two-layered
> HPKE in a previous message. What is that?
>
> Use COSE to encrypt with freshly generated random key, then use HPKE to
> encrypt that random key N times, and stick the N HPKE encryptions as
> recipients of the message.
>
> Makes sense. It parallels section 6.4 of RFC 9052
> <https://www.rfc-editor.org/rfc/rfc9053.html#name-key-agreement-with-key-wrap>,
> right? It’s two layers of encryption (content and key wrap) plus key
> agreement, right?
>
> In this case the body parameter algorithm ID IS clearly one of the COSE
> content encryption algorithms registered today from section 4 of RFC 9053
> <https://www.rfc-editor.org/rfc/rfc9053.html#name-content-encryption-algorith>.
> One of A128GCM (1)…, AES-CCM-16-64-128 (10, ...). The algorithm ID in the
> COSE_Recipient is HPKE.
>
> I believe the COSE-HPKE draft should address this to be complete. Seems like
> some details to work out to be sure it is right.
>
>
>
> My first thought for multiple recipients in COSE-HPKE is to use the
>
> facilities COSE has, but I’m not sure how to line that up with the
> way AEAD is integrated into the HPKE encryption context. It does
> seem necessary to address this now.
>
> That's the way it is done.
>
> The first layer (bulk encryption) in case of multiple recipients can
> not use HPKE because it is symmetric-only operation, where HPKE always
> involves asymmetric step (it is possible to do asymmetric-only, via
> exporters but not vice versa).
>
> Glad we’re getting some alignment here. :-)
>
> LL
>
>
>
>
>
>
>
>
>
> So focusing on the COSE body header parameter algorithm ID, it seems
> that it should be a COSE algorithm ID if it is doing what COSE says
> to do even if the recipient structure is HPKE, but if it is not
> compatible with COSE’s use of AEAD, then it should be something else
> (which must be in the COSE registry). Not saying which way to go here.
> Just building up some facts.
>
> Yes, if doing two-layer (required for multi-recipient):
>
> - The main message algorithm is old COSE algorithm id (e.g., 24 for
> Chacha20-Poly1305)
> - The recipient algorithm is HPKE (whatever the numeric value will be).
>
>
> Then there are subtle differences between one- and two-layer even for
> single recipient: My implementation only ever attempts one bulk
> decryption. In case there are multiple applicable keys, in case of one-
> layer, it gives up if the first key is wrong, in case of two-layer, it
> will proceed to try the remaining keys. This limitation comes from the
> way the code handles very large messages (it is not bound by system RAM
> size).
>
>
>
> -Ilari
>
> _______________________________________________
> COSE mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/cose
> <https://www.ietf.org/mailman/listinfo/cose>
>
> _______________________________________________
> COSE mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/cose
> <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
