I agree with Filip here. I haven’t had much time recently to respond to WG threads, but here are some references for why tying the key directly to the algorithm is a good idea:
NIST SP 800-57 part 1:
Section 6.2.3: “When metadata is used, the metadata should accompany a key (i.e., the metadata is typically stored or transmitted with a key). […]
Some examples of metadata elements include: […] 2. The algorithm to be used with the key;”
NIST SP 800-152 for KMS also says that algorithms shall be associated with keys.
Using a single key for more than one algorithm (a) needs careful analysis even if they are the “same” algorithm family, (b) is an extremely niche requirement in reality, and (c) is easily accomplished anyway by simply duplicating the JWK.
— Neil 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.
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 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]
|
