Thanks Illari for the detailed explanation, updated PR https://github.com/tireddy2/PQC_JOSE_COSE/pull/11, please have a look.
Cheers, -Tiru On Wed, 9 Jul 2025 at 12:48, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > 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 >
_______________________________________________ jose mailing list -- jose@ietf.org To unsubscribe send an email to jose-le...@ietf.org
