Draft: Let's Encrypt Picks Merkle Tree Certificates for Post-Quantum TLS

[krakenhavoc]

Sources

• Let's Encrypt primary announcement: https://letsencrypt.org/2026/06/03/pq-certs
• IETF PLANTS working group draft (MTC spec v04): https://datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs/
• Help Net Security coverage: https://www.helpnetsecurity.com/2026/06/05/lets-encrypt-mcts-web-post-quantum-authentication/
• Cloudflare original MTC proposal: https://blog.cloudflare.com/bootstrap-mtc/
• RFC 9881 (ML-DSA in X.509): https://datatracker.ietf.org/doc/rfc9881/

Uniqueness check

Three most recent posts reviewed:

1. public-ca-eku-separation-june-2026.md (2026-05-27) -- clientAuth EKU removal from public TLS intermediates. No overlap.
2. sc098v2-caa-rfc8657-mandatory.md (2026-05-20) -- CAA RFC 8657 parameter enforcement. No overlap.
3. post-quantum-tls-certificate-readiness.md (2026-04-19) -- General PQC migration overview covering ML-DSA algorithm sizes and hybrid certificate strategy. The April post addresses the problem space; this post covers the specific architectural solution (MTC) that Let's Encrypt committed to on June 3. No substantial overlap.

Why this topic this week

Let's Encrypt's June 3 announcement is the first public commitment from a major CA to the MTC architecture. Because Let's Encrypt issues 54% of public TLS certificates, this decision effectively determines whether MTCs become viable across the majority of the encrypted web. The IETF PLANTS draft-04 was revised nine days before the announcement, making this the right moment to document both the protocol mechanics and what ACME operators need to track.