Thank you Daniel, speaking from first hand, almost intimate, experience with both a JOSE module maintenance and the Web Cryptography API it relies on
- if the input to a JWE operation is a JWK with an alg that indicates ML-KEM (such as HPKE-7 from https://www.ietf.org/archive/id/draft-reddy-cose-jose-pqc-hybrid-hpke-08.html) then i'll already know to import it to Web Cryptography using the right ML-KEM Web Crypto Algorithm Identifier. And i'll also know to use a universally recognized alg amongst its implementations for the import operation. This is not unlike what I already have to do with non-alg required JWKs where I have to strip the alg entirely because not every vendor behaves per spec when alg is present. - if the input to a JWE operation is a CryptoKey with a ML-KEM-768 as key.algorithm.name then i already know it's only applicable to use with algs HPKE-7 or ML-KEM-768 - if eventually there's an actual HPKE abstraction in Web Cryptography then the presence of HPKE-X also identifies the entire ciphersuite for me if a JWK or (i imagine) the CryptoKey will carry the ciphersuite when imported by a user. At no point in time am I asking Web Cryptography's encap/decap to do more than just that, I'm not asking it to do ConcatKDF, nor a different alg specific KDF defined in this draft. Web Cryptography's only concern is key representation when it comes to its own operations, not the JOSE suite. I guess what I'm trying to say is that to a JOSE library a JWK alg *is* enough to know that this is a ML-KEM key. It may not be apparent to Web Cryptography, but it is to a library that will smooth out the edges for Web Cryptography. S pozdravem, *Filip Skokan* On Mon, 11 Aug 2025 at 19:44, Daniel Huigens <[email protected]> wrote: > Hi all, > > I wanted to point out a potential consequence of this decision (AKP vs > OKP vs something else) that may or may not be obvious, and that may or > may not be specific to WebCrypto :) > > If new algorithms using ML-KEM keys get added to JWK, which I imagine > could happen if ML-KEM gets added to HPKE [1] and HPKE gets added to > JOSE [2], then it may be useful to indicate that those objects are > ML-KEM keys to implementations that don't know about the algorithm. > > For example, if we have: > > { > "kty": "AKP", > "alg": "HPKE-7", // or another number > "pub": ..., > "priv": ... > } > > Then there's no indication that that's an ML-KEM key, which means they > won't be importable by WebCrypto as-is (until it learns about ML-KEM in > HPKE in JOSE), nor with the `alg` removed (as it's required for AKP). > > So, the application would have to overwrite the `alg` with a fake value > before importing, and also correct the value when exporting a key. > > Now, you might argue it's strange that WebCrypto handles JWK without > handling JWE, and that those should be implemented at the same layer > (in which case this isn't a concern). And, I would agree with that :) > > But, this is a divergence from the other asymmetric encryption key types > in JWK, where the `alg` is not necessary to identify the key material. > > Still, if you think this concern doesn't apply to the rest of the JOSE > ecosystem, feel free to ignore the above, but I wanted to at least > bring it to the attention of the list. > > Best, > Daniel > > > [1]: https://datatracker.ietf.org/doc/draft-connolly-cfrg-hpke-mlkem/ > [2]: https://datatracker.ietf.org/doc/draft-ietf-jose-hpke-encrypt/ > >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
