Quoting from said PR, which for the record I object to.
> This specification updates the use of the "alg" parameter to be optional
> for the "AKP" key type when used for PQ KEMs.
This suggests that the public key representation could just be { "kty":
"AKP", "pub": "..." }? Just to be clear, that's horrible.
> Using distinct "alg" values provides unambiguous identification of how
> the key is to be used and prevents accidental misuse across Direct Key
> Agreement and Key Agreement with Key Wrap modes.
>
On top of that it also simplifies the implementation and key selection
process from recipient's JWKS. In practice the AKP type definition paired
with Fully-Specified Algorithms shows us how redundant "kty" is now. The
"kty" type definition is, unironically, tied for first place in terms of
recent advancements of the entire JOSE suite together with the deprecation
of Unsecured JWT.
> It reduces algorithm agility, since a stored key is bound to a specific
> mode.
This statement is not true. Storage and representation needn't be tied
together, which in turn makes the next bullet point moot and likewise
untrue.
> It couples storage with operational policy, embedding runtime behavior
> into the key representation rather than leaving it to higher-layer protocol
> logic.
See above.
> It limits re-use of the same key material across compatible modes,
> increasing management complexity.
Given ECDH-ES and ECDH-ES+KW as reference, this has not proven to be a
desired trait or needed in practice.
S pozdravem,
*Filip Skokan*
On Sat, 11 Oct 2025 at 09:18, tirumal reddy <[email protected]> wrote:
> On Thu, 9 Oct 2025 at 21:48, Ilari Liusvaara <[email protected]>
> wrote:
>
>> On Thu, Oct 09, 2025 at 10:28:39AM -0400, Simo Sorce wrote:
>> > On Thu, 2025-10-09 at 19:20 +0530, tirumal reddy wrote:
>> > >
>> > > The key trade-off seems to be between enforcing algorithm binding
>> > > in the key structure to reduce misuse and keeping flexibility to
>> > > avoid layering issues. If JWK starts enforcing operational policies
>> > > (like “this key must only be used for this algorithm”), it may
>> > > interfere with higher layers (such as application logic or key
>> > > management) that should be making those decisions. One possible
>> > > balanced approach would be to continue using AKP, but make the "alg"
>> > > field optional when the key is used for key agreement.
>> >
>> > The problem is that once JWKs carry the algorithm the only option is
>> > not whether or not alg is used, but whether or not multiple algorithm
>> > should be considered equivalent and interchangeable for some mechanism,
>> > and I believe that will not be a good compromise, which is why I
>> > brought it up here. I do agree that the WG really need to think hard
>> > whether it is proper to try to enforce policy mechanisms at the storage
>> > format/information exchange level, or not (I think not).
>>
>> (I think all this has been said before, but..)
>>
>>
>> I think considering algorithms equivalent and interchangeable is a very
>> bad idea. Even if it is rarely a security problem, it can very easily
>> become nasty interoperability problem.
>>
>> When dealing with JOSE and COSE, the only place where I wished alg was
>> mandatory in keys was with oct/symmetric keys.
>>
>> And I do not think this is even correct for enforcing policy it purports
>> to enforce: The NIST specs talk about only using key for one _purpose_.
>> Well, KEM and KEM+KW are the same _purpose_, especially when properly
>> separated (like in this draft). It is JOSE that makes those two not
>> interchangeable (in theory the two are interchangeable in COSE).
>>
>> The policy is really already enforced, I think the only possible way to
>> use the key for another purpose would be key a MAC with one in COSE, but
>> that is inherently a Bad Idea (and mandatory alg would not stop that!).
>>
>> Another issue is that JOSE does not mandate JWK. Thus even if JWK uses
>> AKP, one can still end up with keys with no algorithm specified. The
>> analogous issue holds for COSE and COSE_Key.
>>
>
> I have raised PR #19 <https://github.com/tireddy2/PQC_JOSE_COSE/pull/19>
> as a placeholder to document and weigh the respective pros and cons of
> using the "alg" parameter.
> I will not commit or publish this PR until there is consensus in the WG.
>
> -Tiru
>
>
>>
>>
>>
>> -Ilari
>>
>> _______________________________________________
>> 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]
