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]
