That works for me. Thank you. S pozdravem, *Filip Skokan*
On Mon, 14 Jul 2025 at 15:57, tirumal reddy <[email protected]> wrote: > > > 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]
