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