Add support for ML-DSA "post-quantum" key types

[dralley]

Add MLDSA44, MLDSA65, and MLDSA87 key types for generating post-quantum certificates using the cryptography library's ML-DSA support (requires OpenSSL 3.5+).

[dralley]

Seems like the existing pattern is to support one key length per variant, but I think for ML-DSA it makes a little bit of sense to distinguish, because the keys / certs / signatures tend to be larger than existing certs, and that actually matters from a testing perspective sometimes

e.g. aio-libs/aiohttp#13397

[dralley]

@A5rocks Before I go through the effort of polishing this, would something like this be accepted?

[A5rocks]

I don't really know much about this library or whether this is a good idea, unfortunately. It seems to me that we should stick to standards, probably even specifically to TLS standards, and I don't know whether ML-DSA is part of that?

[dralley]

ML-DSA is standardized. Its addition to TLS 1.3 is not 100% final but it's in the final phases of review. The main thing is that because the post-quantum cryptography push is happening so quickly, you need to be able to test the certs on your infra to see where the issues are. For people who are required to follow federal standards the deadlines are pretty short.

FIPS 204 - https://csrc.nist.gov/pubs/fips/204/final / https://www.nist.gov/publications/module-lattice-based-digital-signature-standard

CNSA 2.0 - https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF

IETF draft - https://datatracker.ietf.org/doc/draft-ietf-tls-mldsa/

pyca/cryptography support - https://cryptography.io/en/latest/changelog/#v49-0-0

In the next version of the Golang standard library - https://go.dev/doc/go1.27#crypto_mldsa

LetsEncrypt support roadmap - https://letsencrypt.org/2026/06/03/pq-certs

Cloudflare support roadmap - https://blog.cloudflare.com/post-quantum-roadmap/

Google support roadmap - https://cloud.google.com/blog/products/identity-security/pqc-in-plaintext-google-clouds-post-quantum-cryptography-roadmap

[A5rocks]

Thanks that makes sense to me. I'm not thrilled about this (maybe a +0 or +0.5) because it would be annoying/extra maintenance to a mostly stable project to chase a moving target, but it sounds like it shouldn't change which is good.

Maybe @pquentin would have more opinions?

[A5rocks]

Actually re: maintenance burden we can probably just add you as a collaborator if necessary. So sounds fine to me, though I haven't taken a look at the code.