For .NET 10 we will be adding the following algorithms:

• Signature Algorithms
  • ML-DSA (FIPS 204)
  • Composite ML-DSA (draft-ietf-lamps-pq-composite-sigs)
  • SLH-DSA (FIPS 205)
• Key Encapsulation Algorithms
  • ML-KEM (FIPS 203)

For each algorithm we anticipate one core class (e.g. System.Security.Cryptography.MLDsa), interop-implementation types as needed (MLDsaCng, MLDsaOpenSsl), and an associated specifier type (e.g. MLDsaAlgorithm). The details of these classes will be addressed in subordinate issues (one per algorithm/family).

These new algorithms do not play nicely with the existing AsymmetricAlgorithm base class (e.g. what is the KeySize value of an ML-DSA-44 key?), and so the core classes will not derive AsymmetricAlgorithm. Until a need is demonstrated, there will be no common base class across these new algorithms.

Signing algorithms will be incorporated throughout the platform:

• X.509 Public Key Certificates
  • Accessing public and private keys
  • Creating test certificates with CertificateRequest
• SignedCms
• COSE (Sign1 and multi-sign)
• TLS
• (any other areas where certificates or asymmetric signatures are utilized)

ML-KEM cannot create self-signed certificates, but there will be a story for creating ML-KEM transport certificates and accessing keys thereupon.

What Are We Not Doing?

• Any algorithm not listed above is not included in .NET 10.
  • For the sake of transparency: We do not believe there is a need for any FIPS 206 algorithms in .NET workloads, they are planned as "never" until evidence suggests otherwise.
• SignedXml will not be updated, even if a specification combining xmldsig and PQC is created.
• EncryptedXml will not be updated, even if a specification combining xmlenc and PQC is created.
• EnvelopedCms is unlikely to gain support for ML-KEM in .NET 10. We will evaluate the timing of ML-KEM in EnvelopedCms based on user feedback and industry trends.