On Thu, 10 Jul 2025 at 12:52, Filip Skokan <[email protected]> wrote:
> I'm aware of the implications and what may or may not be possible. PQ-KEM > isn't in any way special that it shouldn't follow suit and accept the AKP > type with its restrictions. We do not *need* a singular key > representation instance to allow for this flexibility. > If such a restriction does not exist for traditional asymmetric algorithms, imposing it for PQC KEMs alone would represent an unwarranted change in behavior. I don't see any such restricted behavior defined in JWK. > > FWIW your PR refers to "crv" as (curve) instead of (the subtype of key > pair) which is what the parameter was registered as for OKP. > Thanks, fixed. Cheers, -Tiru > > S pozdravem, > *Filip Skokan* > > > On Thu, 10 Jul 2025 at 08:48, tirumal reddy <[email protected]> wrote: > >> 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]
