Post-quantum certificates with Merkle trees

Summary

Andrew Gabbitas describes how Let’s Encrypt wants to enable post-quantum authentication with Merkle Tree Certificates without slowing down TLS connections with large individual signatures. An ML-DSA-44 signature is about 2,420 bytes. A current ECDSA P-256 signature, by contrast, needs 64 bytes.

Ideas

• Merkle Tree Certificates sign whole groups of certificates instead of each certificate individually.
• Browsers obtain signed landmarks separately from the actual TLS handshake.
• An inclusion proof shows that a certificate belongs to the published tree.
• Built-in transparency prevents certificates outside the logged Merkle tree.
• A standalone fallback format helps clients with an outdated landmark.
• Small standard paths are meant to enable post-quantum authentication without oversized handshakes.

Insights

• Batch signatures trade individual independence for smaller proofs and shared infrastructure.
• Web-wide cryptographic migrations fail because of ecosystem boundaries rather than individual algorithms.
• Transparency becomes stronger when it is part of issuance rather than added afterwards.

Quotes

• Nothing changes today. – Andrew Gabbitas on existing Let’s Encrypt certificates

Habits

• The article does not describe any personal routines or habits of the author.

Facts

• An ML-DSA-44 signature is about 2,420 bytes.
• A current ECDSA P-256 signature, by contrast, needs 64 bytes.
• Let’s Encrypt plans an MTC test environment for the end of 2026.
• A production-ready MTC environment is announced as a goal for 2027.

References

• Andrew Gabbitas: A Post-Quantum Future for Let’s Encrypt
• RFC 9881: Internet X.509 Public Key Infrastructure – Algorithm Identifiers for ML-DSA
• IETF PLANTS: standardisation of transparent post-quantum certificate structures.
• X25519MLKEM768: hybrid post-quantum key exchange for TLS.

Critique

• Timeline and architecture still depend on standards, browsers, libraries and ACME clients.
• Separately distributed landmarks create new dependencies on updates and availability.

Remarks

• The dates mentioned are planning goals and not a promise of production availability.
• Existing certificates and their automatic renewal do not change for the time being.

Recommendations

• Enable X25519MLKEM768 on supported servers and check client compatibility.
• Follow the PLANTS, TLS and ACME drafts if you automate your own certificates.
• Plan MTC tests separately from production certificate operations.

Read the original article at Let’s Encrypt →

Search the Web Archive

Links to the original source and the Web Archive open in a new tab.