Define ML-KEM, ML-DSA and SLH-DSA

[twiss]

No description provided.

[Frosne]

Not sure if it's worth an issue, so writing here:

You introduced raw-secret in 4.1 Data Types, but you're not using it anywhere. I understand that it's a part of the discussion about exporting private keys as seed/raw bytes, maybe we should specify it somewhere?

[twiss]

Thanks for pointing it out! My plan was to switch from "raw" to "raw-secret" for the symmetric algorithms proposed in this document (AES-OCB, ChaCha20-Poly1305, etc.), and propose to allow the same for other existing symmetric algorithms in Web Crypto, and deprecate the use of "raw" (as it's a bit ambiguous). I didn't get to it yet, though.
"raw-private" would instead be used for raw private (asymmetric) keys; indeed this document has no examples unless we add support for semi-expanded ML-KEM and ML-DSA keys. But, other existing asymmetric algorithms in Web Crypto could use it potentially, so I included it for completeness.
Alternatively, we could also try to introduce it in the Web Crypto repo directly and then adopt it here later if necessary :)

[panva]

@twiss please see https://datatracker.ietf.org/doc/draft-ietf-cose-dilithium/ for ML-DSA appropriate JWK format and JWK "alg" identifiers.

[panva]

@twiss please see datatracker.ietf.org/doc/draft-ietf-cose-dilithium for ML-DSA appropriate JWK format and JWK "alg" identifiers.

Note that this is a draft and may still change. The important part that's different from previous JWK representations

• new "kty" (JWK Key Type) value "AKP" - Algorithm Key Pair
• "alg" is a required JWK property (to be checked during import, and must be present during export)
• "priv" is a seed, not the the expanded expression

Both "priv" and "pub" must be present in private JWK representations.

If you've got any feedback then please present it on the COSE WG mailing list.

[twiss]

@panva Thanks for pointing that out! It looks reasonable to me.

[panva]

On that same note, see https://datatracker.ietf.org/doc/draft-ietf-jose-pqc-kem/ for ML-KEM

[panva]

JOSE Definitions for SLH-DSA-SHA2-128s, SLH-DSA-SHAKE-128s, and SLH-DSA-SHA2-128f are in https://datatracker.ietf.org/doc/draft-ietf-cose-sphincs-plus/

[twiss]

@panva I've taken a stab at defining JWK import and export for the PQC algorithms; please take a look if you have time and let me know whether it looks reasonable 😊

[panva]

@twiss Thank you, is there a deployed preview I could use for the review?

[twiss]

@panva Deployed now here: https://twiss.github.io/webcrypto-modern-algos/pqc.html

[panva]

Is this possible for SLH-DSA?

[twiss]

I think so; in an SLH-DSA private key, both the private and public values are included (see FIPS 205, Figure 15). If the AKP key type requires both the pub and priv properties, then it's possible for them not to match. But it should be trivial to check for SLH-DSA, basically the second half of priv needs to equal pub.

In the example in Appendix 1.1 of draft-ietf-cose-sphincs-plus-05, it looks like the first half of priv matches pub rather than the second half, but I imagine that's a mistake.

Section 5.1 also talks about validating public keys, though I'm not 100% sure if they're talking about this or something else.

[panva]

basically the second half of priv needs to equal pub.

You're 100% right. Thank you.

[twiss]

I'll merge this for now; we can always make changes later. We may also still want to add spki and pkcs8 import/export at some point.

[panva]

We may also still want to add spki and pkcs8 import/export at some point.

For sure.