letsencrypt
Allow ML-DSA roots and intermediates
Add support for using ML-DSA-65 to generate Pebble's root and intermediate keys and certificates.
This uses Cloudflare's "circl" library to handle generating ML-DSA keys, serializing pubkeys, and generating signatures. Specifically, it uses the mldsa44, mldsa65, and mldsa87 packages, as well as the abstractions provided by the sign and pki packages:
- https://pkg.go.dev/github.com/cloudflare/[email protected]/sign/mldsa/mldsa44
- https://pkg.go.dev/github.com/cloudflare/[email protected]/sign/mldsa/mldsa65
- https://pkg.go.dev/github.com/cloudflare/[email protected]/sign/mldsa/mldsa87
- https://pkg.go.dev/github.com/cloudflare/[email protected]/sign
- https://pkg.go.dev/github.com/cloudflare/[email protected]/pki#CertificateScheme
However, the Go stdlib crypto/x509 package does not support using these keys. Although they implement the crypto.Signer interface, the x509 package also needs to be able to map keys to PublicKeyAlgorithm and SignatureAlgorithm OIDs, and does not provide any hooks for crypto.Signers to provide that information. As such, this PR also forks the relevant portions of crypto/x509 (MarshalPKIXPublicKey, CreateCertificate, and ParseCertificate), strips them down to their bare bones, and then adds support for ML-DSA.
We may need to fork crypto/x509
Forking individual package from Go's standard library is almost impossible, I tried. See the reason here.
As I already mentioned in https://github.com/golang/go/issues/64537, check out AgiliGo.
Should this use assembly for the ML-DSA operations to prevent side-channel attacks? Or is that not an issue because production users will use an HSM?
Should this use assembly for the ML-DSA operations to prevent side-channel attacks? Or is that not an issue because production users will use an HSM?
Pebble is not intended for production use; as documented in its README and as demonstrated by the fact that it generates its signing keys on startup and forgets them on shutdown, it is intended for testing and development use only. It's fine if its signing operations are not constant-time.