On Mon, Jul 07, 2025 at 12:44:47PM +0530, tirumal reddy wrote: > On Fri, 4 Jul 2025 at 21:13, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > Got it, "OKP" won't work either, since RFC8037 mandates that "crv" must > come from the "JSON Web Elliptic Curve" registry. Since ML-KEM is not an > elliptic curve, it seems defining a new "kty" is necessary.
RFC8037 explicitly allows things that are not elliptic curves — and technically neither x25519 nor x448 is an elliptic curve. Then COSE explicitly inherits that. OKP was designed to support stuff other than elliptic curves from the very beginning — There even was early version that had different name for what is now "crv". (It might be useful to fix the fixable — pretty much all except the "crv" name in JOSE — issues with OKP.) > > JOSE/COSE HPKE has absolutely nothing to do with how key agreement > > works in JOSE/COSE. There is no "similar", only is or is not. > > > > And COSE-HPKE does explicitly use protected via the structures passed as > > HPKE aad. > > > > Then RFC 9052 explicitly requires protected in context info for Key > > Agreement with Key Wrap, and impiles that protected is required for > > Direct Key Agreement. > > > > Then Direct Key Agreement is a privileged mode in both JOSE and COSE > > with properties no other mode can have. Thus using KEM for deriving > > CEK has to be Direct Key Agreement, it can not be anything else. > > > > Key Agreement with Key Wrapping is also privileged mode in JOSE. > > However, Key Agreement with Key Wrap is not privileged in COSE, but > > what KEM followed by Key Wrap does fits perfectly in that mode. > > > > Thanks for the clarification. What would be the security justification for > excluding PartyUInfo and PartyVInfo in both COSE and JOSE ? Lack of sender keys — building authenticated post-quantum KEM is an open problem — renders PartyUInfo/PartyVInfo moot: - Sender/receiver symmetry inherently can not exist. - The ephemeral key inherently provides per-kex entropy. - There is nothing to prevent attacker from putting whatever that causes the most damage into PartyUInfo/PartyVInfo. These do apply to ECDH-ES as well — I think the reason why JOSE has PartyUInfo/PartyVInfo at all is that it copied the NIST spec without thinking why the stuff is there. COSE has ECDH-SS, which has sender keys, and thus needs a mechanism to break the symmetry and inject per-kex entropy — PartyUInfo/PartyVInfo can be used for this purpose. -Ilari _______________________________________________ jose mailing list -- jose@ietf.org To unsubscribe send an email to jose-le...@ietf.org
