On Thu, 23 Oct 2025 at 17:01, Filip Skokan <[email protected]> wrote:
> but I’d like to confirm if this approach works for you > > > It's just OKP with renamed crv > kem_params, x > pub, and d > priv, so > other than believing that "alg" should be required thus making "kem_params" > redundant or sticking with AKP in the first place? Sure, at the very least > the PR is now presentable as WIP at the meeting in November. > Yes, the intent is for the WG to weigh all the options including this one and decide which approach to adopt. Cheers, -Tiru > > S pozdravem, > *Filip Skokan* > > > On Thu, 23 Oct 2025 at 13:11, tirumal reddy <[email protected]> wrote: > >> Thanks, Filip, for the quick response. I’ve updated the PR, please take a >> look. It still needs a few more updates, but I’d like to confirm if this >> approach works for you. >> >> -Tiru >> >> On Thu, 23 Oct 2025 at 14:08, Filip Skokan <[email protected]> wrote: >> >>> Thanks Tiru, >>> >>> For ML-KEM, the fixed-length public key is sufficient to identify the >>>> parameter set. >>> >>> >>> But since there's no required parameter that would say that the key is >>> ML-KEM the key type definition breaks down the moment more KEM algorithms >>> come into the mix alongside of ML-KEM if by happenstance they would have >>> the same pub key length. >>> >>> The update you made after my review made "alg" part of the key >>> thumbprint calculation, which means it must be a required parameter. As per >>> RFC7638 (JSON Web Key (JWK) Thumbprint) Optional members of JWKs are >>> intentionally not included in the JWK Thumbprint computation so that their >>> absence or presence in the JWK does not alter the resulting value. >>> >>> A new key type which at its most bare public representation looks like >>> this (taken from the PR example having stripped "priv") >>> >>> { >>> "kty": "KEM", >>> "pub": "8GQOjk8fT3F4l8n5E2aG7v5K9P..." >>> } >>> >>> is not a sufficiently defined key type for ML-KEM, let alone KEM in >>> general as its "kty" suggests, we've been over why in this very thread >>> earlier starting at >>> https://mailarchive.ietf.org/arch/msg/jose/4Zj0C4n-w_twx956j8mC3OBnuu0/ >>> >>> S pozdravem, >>> *Filip Skokan* >>> >>> >>> On Thu, 23 Oct 2025 at 10:05, tirumal reddy <[email protected]> wrote: >>> >>>> Hi Filip, >>>> >>>> Thanks for the feedback, please see inline >>>> >>>> On Thu, 23 Oct 2025 at 12:29, Filip Skokan <[email protected]> wrote: >>>> >>>>> Hello Tiru, >>>>> >>>>> Said PR is >>>>> >>>>> - updating the spec's JSON Web Key Elliptic Curves IANA >>>>> considerations but the spec doesn't make use of them at all >>>>> - doesn't fully define a JWK format as it omits to specify the >>>>> parameters used for JWK Thumbprint calculation >>>>> - inexplicably mixes COSE and JOSE key representation types in the >>>>> same table column >>>>> - re-defines "alg" as something specific to this kty when this is >>>>> in fact a JWK-actual defined Parameter >>>>> >>>>> Those are the easy to fix omissions. >>>>> >>>> >>>> Thanks, I fixed those issues in the PR. >>>> >>>> >>>>> >>>>> Most importantly tho, it opens up a key without an alg in a JWK Set to >>>>> be selectable not only for multiple modes but also multiple different >>>>> families of algorithms (i.e. ML-KEM-1024 and ML-KEM-512) since without an >>>>> alg there's nothing in the representation that says "hey, i'm a ML-KEM-512 >>>>> key" other than anecdotal "pub" parameter length. This is, much like the >>>>> earlier suggested PR ( >>>>> https://github.com/tireddy2/PQC_JOSE_COSE/pull/19) which attempted to >>>>> make AKPs "alg" conditionally optional when used with PQ KEMs, not a good >>>>> idea. >>>>> >>>>> Furthermore, as expected: >>>>> >>>>> The "alg" parameter is to allow flexibility in using the same key >>>>>> pair for multiple algorithm variants that share the same key >>>>>> structure. This is >>>>>> useful, for example, when the same ML-KEM key pair is used with both: >>>>>> * Direct Key Agreement (alg = "ML-KEM-768") >>>>>> * Key Agreement with Key Wrap (alg = "ML-KEM-768+A256KW") >>>>> >>>>> >>>>> We've discussed this ad nauseam. It is not a required trait and as >>>>> such the "alg" JWK-defined Parameter should just be required which not >>>>> only >>>>> resolves the aforementioned issue but also, makes this type proposal equal >>>>> to AKP. >>>>> >>>> >>>> For ML-KEM, the fixed-length public key is sufficient to identify the >>>> parameter set. >>>> >>>> The "alg" field is intentionally optional for the new key type. The >>>> earlier proposals to use "AKP" or modify "AKP" to make "alg" optional were >>>> discussed and there was no consensus. The new key type was introduced as a >>>> clean alternative that avoids impacting existing key types while providing >>>> the flexibility. Implementations that require stricter policy can still >>>> include "alg" in their JWK Sets. >>>> >>>> At this stage, the WG effectively has four options: >>>> >>>> a) reuse "OKP" >>>> b) reuse "AKP" , >>>> c) modify "AKP" to make "alg" optional, or >>>> d) define a new key type ("KEM") with optional "alg" . >>>> >>>> I understand the position that option b) should be used, but others >>>> don't agree with it. It would be helpful for the WG to confirm which path >>>> it wants to pursue so the work can move forward. >>>> >>>> -Tiru >>>> >>>> >>>> S pozdravem, >>>>> *Filip Skokan* >>>>> >>>>> >>>>> On Thu, 23 Oct 2025 at 08:20, tirumal reddy <[email protected]> wrote: >>>>> >>>>>> I raised a new PR https://github.com/tireddy2/PQC_JOSE_COSE/pull/20 >>>>>> to address the issue. >>>>>> >>>>>> Cheers, >>>>>> -Tiru >>>>>> >>>>>> On Wed, 22 Oct 2025 at 21:37, Orie <[email protected]> wrote: >>>>>> >>>>>>> If we assume AKP, and there is a desire to restrict a key to only >>>>>>> integrated encryption, then the algorithm identifiers would need to be >>>>>>> updated. >>>>>>> >>>>>>> I can buy the security argument that it should be possible to >>>>>>> restrict a key to only integrated encryption... Especially because with >>>>>>> key >>>>>>> encryption a weaker recipient could be attacked leading to disclosure. >>>>>>> >>>>>>> Having a way to distinguish the supported algorithms also fits with >>>>>>> the spirit of fully specified algorithms. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> OS >>>>>>> >>>>>>> On Wed, Oct 22, 2025, 1:09 AM tirumal reddy <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> I am good to proceed with defining a new key type for PQC KEMs and >>>>>>>> to keep the "alg" parameter optional. Implementations that require >>>>>>>> strict >>>>>>>> algorithm binding can mandate the presence of "alg". The "alg" field >>>>>>>> can >>>>>>>> be omitted when the same key structure is reused across different >>>>>>>> modes, >>>>>>>> such as direct encryption and key wrap similar to the way "alg" is not >>>>>>>> specified for the existing OKP key type. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> -Tiru >>>>>>>> >>>>>>>> On Wed, 22 Oct 2025 at 03:04, Brian Campbell <bcampbell= >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Apologies, the beginning of the text in the parenthetical of that >>>>>>>>> last sentence should have said "I'm *not* totally convinced myself" >>>>>>>>> >>>>>>>>> On Tue, Oct 21, 2025 at 1:34 PM Brian Campbell < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Agree with much of Orie's perspective here. >>>>>>>>>> >>>>>>>>>> Please do not attempt to redefine AKP. >>>>>>>>>> >>>>>>>>>> If consensus is that AKP isn't right for keys for PQ KEMs (I'm >>>>>>>>>> totally convinced myself but I do definitely understand some of the >>>>>>>>>> rationale), then new key type(s) are the appropriate way forward. >>>>>>>>>> >>>>>>>>>> On Sat, Oct 11, 2025 at 7:32 AM Orie <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> I left comments on >>>>>>>>>>> https://github.com/tireddy2/PQC_JOSE_COSE/pull/19 >>>>>>>>>>> >>>>>>>>>>> I will repeat them here for the list. >>>>>>>>>>> >>>>>>>>>>> Do not update the definition of AKP. >>>>>>>>>>> >>>>>>>>>>> Make a new key type if you want to have keys that have a >>>>>>>>>>> different set of security properties (such as being explicitly used >>>>>>>>>>> with >>>>>>>>>>> multiple algorithms). >>>>>>>>>>> >>>>>>>>>>> If you want to go this route, I would lean into the idea that >>>>>>>>>>> you can't actually enforce any algorithm checking at the key side, >>>>>>>>>>> and just >>>>>>>>>>> say that the attacker controlling the algorithm in the message is >>>>>>>>>>> not a >>>>>>>>>>> concern for kems. >>>>>>>>>>> (I don't agree with this, but that's what the argument appears >>>>>>>>>>> to be to me, please correct me if I am wrong). >>>>>>>>>>> >>>>>>>>>>> In JOSE and COSE, the algorithm on security objects is >>>>>>>>>>> controlled by the attacker. >>>>>>>>>>> Without requiring the algorithm to be on the key, you will need >>>>>>>>>>> to "try it out" to see if it works. >>>>>>>>>>> As soon as you do that, you are doing work for the attacker... >>>>>>>>>>> The system may still fail closed, but you've already done more work >>>>>>>>>>> than >>>>>>>>>>> you needed to. >>>>>>>>>>> >>>>>>>>>>> It's easy to make a new key type, if the WG thinks a key type >>>>>>>>>>> that can explicitly be used with many algorithms is a good thing, >>>>>>>>>>> make one, >>>>>>>>>>> that way people will know what they are getting when they see that >>>>>>>>>>> key type. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> OS >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Sat, Oct 11, 2025 at 8:09 AM Neil Madden < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> > On 11 Oct 2025, at 13:24, Ilari Liusvaara < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> > >>>>>>>>>>>> > On Sat, Oct 11, 2025 at 10:29:59AM +0100, Neil Madden wrote: >>>>>>>>>>>> >> >>>>>>>>>>>> https://neilmadden.blog/2018/09/30/key-driven-cryptographic-agility/ >>>>>>>>>>>> > >>>>>>>>>>>> > AKP is incompatible with key driven cryptographic agility. >>>>>>>>>>>> > >>>>>>>>>>>> > The idea of key driven cryptographic agility is to specify >>>>>>>>>>>> some >>>>>>>>>>>> > cryptographic service (e.g., signature, mac, KEM) at protocol >>>>>>>>>>>> level and >>>>>>>>>>>> > then have key specify how exactly that is implemented. And >>>>>>>>>>>> since this >>>>>>>>>>>> > is polymorphic by definition, KDCA is also incompatible with >>>>>>>>>>>> fully >>>>>>>>>>>> > specified algorithms. >>>>>>>>>>>> >>>>>>>>>>>> None of these things is true. >>>>>>>>>>>> >>>>>>>>>>>> — Neil >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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] >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>>>>>> privileged material for the sole use of the intended recipient(s). Any >>>>>>>>> review, use, distribution or disclosure by others is strictly >>>>>>>>> prohibited. >>>>>>>>> If you have received this communication in error, please notify the >>>>>>>>> sender >>>>>>>>> immediately by e-mail and delete the message and any file attachments >>>>>>>>> from >>>>>>>>> your computer. Thank you.* >>>>>>>>> _______________________________________________ >>>>>>>>> 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]
