On Mon, 14 Jul 2025 at 12:53, Filip Skokan <[email protected]> wrote:
> 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. > > > Except that we can take a look at existing ECDH prior art and realize that > this duality increases implementation complexity, needlessly. Just because > it's possible doesn't mean it's been proven useful and needed to be carried > over. > I have not seen any other WG members raise implementation challenges that justify introducing this restriction solely for PQC KEMs. Imposing such a restriction within this spec would require consensus among WG members. I will present this issue in the WG meeting next week. Cheers, -Tiru > > S pozdravem, > *Filip Skokan* > > > On Mon, 14 Jul 2025 at 09:16, tirumal reddy <[email protected]> wrote: > >> 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]
