A single PQ KEM key pair might be used with both Direct Key Agreement and Key Agreement with Key Wrap modes. Since the AKP key type requires specifying a single, fixed alg, this introduces rigidity when the same key is valid for use with multiple modes. This kind of restriction does not exist for traditional asymmetric algorithms (e.g., X25519 or ECDH), where the key representation remains agnostic of the specific mode used. Introducing such a restriction specifically for PQ KEMs would reduce flexibility.
RFC8037, explicitly states that it does not assume that there is an underlying elliptic curve, despite the existence of the 'crv' and 'x' parameters. Cheers, -Tiru On Wed, 9 Jul 2025 at 18:03, Filip Skokan <[email protected]> wrote: > 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 <[email protected]>: > > > 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 <[email protected]> > wrote: > >> On Mon, Jul 07, 2025 at 12:44:47PM +0530, tirumal reddy wrote: >> > On Fri, 4 Jul 2025 at 21:13, Ilari Liusvaara <[email protected]> >> > 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 -- [email protected] >> To unsubscribe send an email to [email protected] >> > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] > >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
