On Tue, Nov 22, 2022 at 09:25:08AM -0800, Laurence Lundblade wrote: > > > On Nov 22, 2022, at 12:58 AM, Hannes Tschofenig <[email protected]> > > wrote: > > > > FWIW both modes are already described in draft-ietf-cose-hpke. > > > > COSE_Mac/COSE_Mac0 and COSE_Sign1/COSE_Sign are wrappers covering > the entire COSE_Encrypt/COSE_Encrypt0 payload. > > It’s not COSE message wrapping/nesting here. RFC 9052 section 6.1 > allows the use of a COSE_Recpient (e.g., with HPKE) to establish the > secret key used with HMAC for COSE_Mac as kind of an alternate way of > signing data. I’m not sure what the use case is and why it’s better > or worse than ECDSA, Edwards and other such signing, but the COSE > authors went to a lot of trouble to create it and provide a lot of > examples for it. > > It seems not a lot (close to zero) work to support it with > two-layer HPKE, so we should.
I do not think that actually works, due to two problems: - HPKE operates in base mode, which has no sender authentication. - There is implicit key wrap, so in terms of security considerations for COSE, "no proof of origin is implied". Furthermore, even in HPKE auth mode with export-only (no implicit key wrap) if the private key is shared among multiple entities, those entities can forge messages to each other (analogous issue is covered in COSE security considerations for ECDH). -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
