Illari answered a related question here: https://mailarchive.ietf.org/arch/msg/cose/eIxt4u8ox8N35-ZbDk_vsFD9PP4/
I have similar questions on how HPKE, PQC KEMs, and COSE Key work together in practice. OS On Thu, Nov 17, 2022 at 9:55 AM Laurence Lundblade <[email protected]> wrote: > 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 > -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
