[jose] Re: Feedback on draft-ietf-jose-pqc-kem-01

[Filip Skokan <[e-mail]>]

AKP should still be used despite having to have an alg that says whether this key is for MLKEM512 or MLKEM512-AES128KW. 

Not having the ability to have the same representation for a key usable for both is in my opinion not a good reason to use OKP and in so the continued awkwardness of use of crv and x.

- Filip

9. 7. 2025 v 13:16, tirumal reddy <[e-mail]>:



Thanks Illari for the detailed explanation, updated PR https://github.com/tireddy2/PQC_JOSE_COSE/pull/11" rel="nofollow">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 <[e-mail]> wrote:

On Mon, Jul 07, 2025 at 12:44:47PM +0530, tirumal reddy wrote:
> On Fri, 4 Jul 2025 at 21:13, Ilari Liusvaara <[e-mail]>
> 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 -- [e-mail]
To unsubscribe send an email to [e-mail]

_______________________________________________
jose mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]