@Ilari Liusvaara <[email protected]> And if encrypting to multiple JWKs and there is > a single-recipient one? Ouch.
I don't follow what you're describing here, when using General JWE JSON Serialization Syntax with multiple recipients (i.e. encrypting to multiple JWKs, but not necessarily JWKs) there's one CEK and one ciphertext, ergo any Direct Agreement-like algorithm, albeit ECDH-ES (no KW), dir, ML-KEM-* (no KW), or HPKE using integrated encryption, is not possible in the first place. And again, much like in the several previous iterations of this argument, I fail to see what it has to do with JWK key representation mandating the exact algorithm it is meant for. S pozdravem, *Filip Skokan* On Sat, 11 Oct 2025 at 14:11, Ilari Liusvaara <[email protected]> wrote: > 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] >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
