Laurence,
a few remarks below: * 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). [Hannes] In the two-layer structure the layer 0 (corresponding to the COSE_Encrypt) has to contain algorithm information since otherwise you do not know how to encrypt the plaintext with the CEK. 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. [Hannes] This is what is described in Section 3.2.1 of the draft, see https://datatracker.ietf.org/doc/html/draft-ietf-cose-hpke-02#section-3.2.1 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? [Hannes] Yes, if you call HPKE a key wrap mechanism. 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. [Hannes] If “body parameter” is the structure at layer 0, then this is correct. 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. [Hannes] The COSE-HPKE draft describes this aspect. The challenge is how to encode the output of HPKE and where to place it. Ilari and Daisuke have a different view on how this should look like. To help myself understand their proposals I have created two PRs accordingly, see - Daisuke’s proposal: https://github.com/cose-wg/HPKE/pull/9 - Ilari’s proposal: https://github.com/cose-wg/HPKE/pull/10 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. :-) [Hannes] These are the parts of the draft where there has been an agreement. So far, there has not been any misalignment on those aspects. Ciao Hannes 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
