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