Proposal Details
The timeline of plausible CRQC has shifted which made my previous preference for a wait-and-see approach to signatures unfortunately obsolete. Merkle Tree Certificates are progressing and the WebPKI will probably migrate to those in 2027, but
- they still requires a ML-DSA leaf public key
- they are not ready now, and they'll probably be too late for many private PKIs.
The time has come to add support for ML-DSA to crypto/tls and crypto/x509.
This proposal is about pure ML-DSA signatures, which are relatively simple to add. I shared on the TLS WG mailing list the reason to deploy pure ML-DSA over composite signatures (which is at least a partial outcome of the wait-and-see period). If there is demand for composite signatures, please open a separate proposal, ideally including all the API changes necessary. Do not use this proposal to discuss composite signatures.
This proposal builds on top of the #77626 API. It looks like a lot of surface but it's really only adding some values to various enums and switch statements.
Specifications
The X.509 bits will be based on RFC 9881. Like in #77626, we'll only be implementing the recommended seed private key format.
The TLS bits will be based on draft-ietf-tls-mldsa-02. It's a draft due to irrelevant IETF WG infighting, but the TLS codepoints are already registered in the IANA TLS SignatureScheme registry, and there are other implementations out there.
crypto/x509
- Add support for verifying ML-DSA signatures on the chain
- Add
const MLDSA PublicKeyAlgorithm = iota
- Add
const MLDSA44 SignatureAlgorithm = iota
const MLDSA65 SignatureAlgorithm = iota
const MLDSA87 SignatureAlgorithm = iota
- Add support for
*mldsa.PublicKey to
- Certificate.PublicKey
- CertificateRequest.PublicKey
- CreateCertificate
- MarshalPKIXPublicKey
- ParsePKIXPublicKey
- Add support for
*mldsa.PrivateKey (or other crypto.Signers returning *mldsa.PublicKey from Public(), as applicable) to
- CreateCertificate
- CreateCertificateRequest
- CreateRevocationList
- MarshalPKCS8PrivateKey
- ParsePKCS8PrivateKey
crypto/tls
- Add support for verifying handshake signatures from ML-DSA X.509 certificates
- Add
const MLDSA44 SignatureScheme = 0x0904
const MLDSA65 SignatureScheme = 0x0905
const MLDSA87 SignatureScheme = 0x0906
- Add support for
crypto.Signers returning *mldsa.PublicKey from Public() to Certificate.PrivateKey
/cc @golang/security
Proposal Details
The timeline of plausible CRQC has shifted which made my previous preference for a wait-and-see approach to signatures unfortunately obsolete. Merkle Tree Certificates are progressing and the WebPKI will probably migrate to those in 2027, but
The time has come to add support for ML-DSA to crypto/tls and crypto/x509.
This proposal is about pure ML-DSA signatures, which are relatively simple to add. I shared on the TLS WG mailing list the reason to deploy pure ML-DSA over composite signatures (which is at least a partial outcome of the wait-and-see period). If there is demand for composite signatures, please open a separate proposal, ideally including all the API changes necessary. Do not use this proposal to discuss composite signatures.
This proposal builds on top of the #77626 API. It looks like a lot of surface but it's really only adding some values to various enums and switch statements.
Specifications
The X.509 bits will be based on RFC 9881. Like in #77626, we'll only be implementing the recommended seed private key format.
The TLS bits will be based on draft-ietf-tls-mldsa-02. It's a draft due to irrelevant IETF WG infighting, but the TLS codepoints are already registered in the IANA TLS SignatureScheme registry, and there are other implementations out there.
crypto/x509
*mldsa.PublicKeyto*mldsa.PrivateKey(or othercrypto.Signers returning*mldsa.PublicKeyfromPublic(), as applicable) tocrypto/tls
crypto.Signers returning*mldsa.PublicKeyfromPublic()to Certificate.PrivateKey/cc @golang/security