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]
