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]
