On Sat, Oct 11, 2025 at 10:52:00AM +0200, Filip Skokan wrote:
> 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.
Yeah, very Bad Idea.
> > 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.
No, such misuse is prevented by the context structure. Relying on
mechanism like this to prevent misuse would be a serious security
problem.
There is nothing to prevent an implementation from treating the two as
equivalent in order to solve operational problems (and getting
interoperability problems in exchange).
> On top of that it also simplifies the implementation and key selection
> process from recipient's JWKS.
No, it does not. One is now also forced to consider if there is just
one or many recipients. And if encrypting to multiple JWKs and there is
a single-recipient one? Ouch.
One can not get this issue with using AKP with JOSE-HPKE: Integerated
Encryption and Key Encryption modes are considered to be the same
algorithm.
> 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 is not redundant, and the main reason is actually exactly the same as
here: Key agreement keys and wrapped and unwrapped key agreement being
considered two distinct algorithms.
Then there are some more minor stuff with things like RSA signing keys.
And see above about how JOSE-HPKE can get away with using AKP.
> > 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.
Most protocols are single-recipient (judging from many JOSE libs only
supporting one recipient). But this very much matters for any protcol
that can be multi-recipient.
-Ilari
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
