> > 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. 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]
