Merkle Tree Certificates (MTCs) are a proposed new form of X.509 certificate being developed in the IETF. Instead of a certificate authority (CA) signing each certificate, the CA adds it to a public log. The server then proves inclusion with a short Merkle tree proof, which keeps authentication data compact even when post-quantum signatures are used.
This guide explains what MTCs are, how they work, how they differ from certificates you use today, and what is still unsettled. The specification is an active draft, so details may change before any final standard.
What Are Merkle Tree Certificates?
An MTC is a certificate whose trust comes from a log entry rather than a classic CA signature. The CA still validates domain control and identity, as it does today. What changes is the final step: the CA “certifies by logging.” It appends a record of the certificate to an append-only issuance log and publishes signed checkpoints of that log.
The design is described in draft-ietf-plants-merkle-tree-certs, a Standards Track Internet-Draft. Revision 07 was published on October 7, 2026 and is set to expire on April 10, 2027, which is normal for a document still under review. It comes from the PLANTS working group, short for PKI, Logs, And Tree Signatures.
If the vocabulary is new, our SSL glossary covers the basics of certificates, chains and trust anchors.
Why Is the Web PKI Looking at a New Certificate Design?
The short answer is size. Today’s TLS handshake sends a certificate chain, and each certificate carries a public key and a CA signature. Classical keys and signatures are small. ECDSA and Ed25519 signatures are 64 bytes.
Post-quantum signatures are much larger. The NIST standard for ML-DSA, FIPS 204, defines three parameter sets, shown below.
| ML-DSA parameter set | Public key | Signature |
|---|---|---|
| ML-DSA-44 | 1,312 bytes | 2,420 bytes |
| ML-DSA-65 | 1,952 bytes | 3,309 bytes |
| ML-DSA-87 | 2,592 bytes | 4,627 bytes |
Sizes from FIPS 204. For comparison, an Ed25519 signature is 64 bytes.
A handshake that carries several such signatures and keys can add many kilobytes. That extra data can slow connections, especially on poor networks, and can push handshakes past packet-size limits. MTCs aim to cut this overhead by replacing most of those signatures with a hash-based proof.
Key exchange is a separate problem. Hybrid key exchange such as X25519MLKEM768 is already being deployed to protect traffic against future quantum attacks. Authentication, meaning certificates, is the harder part, because the signatures are large. MTCs target that part.
How Do Merkle Tree Certificates Work?
The process has four steps. The example is simplified, so check the draft for exact message formats.
- The CA validates the request, for example through ACME, as it does for any certificate.
- The CA adds an entry to its issuance log. The entry holds the certificate details, including a hash of the subject’s public key rather than the key itself.
- The CA publishes a signed checkpoint that commits to the whole log state through a Merkle tree root hash.
- Independent cosigners, sometimes called mirrors, watch the log and add their own signatures to checkpoints, which makes it harder for one CA to show different views to different people.
The certificate the server presents then contains an inclusion proof. In the draft, this proof sits in the certificate’s signature field, identified by the algorithm identifier id-alg-mtcProof. To a relying party, it looks like an X.509 certificate with an unusual signature.
Anyone who has seen Certificate Transparency will recognize the idea. Today, CT logs are a separate system, and a certificate carries signed certificate timestamps (SCTs) as evidence of logging. With MTCs, logging is the issuance mechanism itself, so there is no separate proof to attach.
What Is an Inclusion Proof, and How Small Is It?
A Merkle tree is a binary tree of hashes. Each leaf is the hash of a log entry, and each parent is the hash of its two children. The top hash, the root, commits to every entry beneath it.
To show that one entry is in the tree, you provide the sibling hashes along the path from that leaf to the root. The verifier recomputes the path and compares the result with the signed root. The proof needs at most ceil(log2 n) SHA-256 hashes for a log of n entries, at 32 bytes each.
| Log size (entries) | Maximum proof hashes | Proof size |
|---|---|---|
| 1,000 | 10 | 320 bytes |
| 1,000,000 | 20 | 640 bytes |
| 1,073,741,824 (2^30) | 30 | 960 bytes |
Worked from the formula above. Real proofs may include other fields.
The proof grows slowly as the log grows. A log with a billion entries still needs under a kilobyte of hashes, which is smaller than a single ML-DSA-44 signature.
What Are Standalone and Landmark-Relative Certificates?
The draft describes two ways a certificate can be verified. They trade off independence against size.
Standalone certificates
A standalone certificate carries the inclusion proof plus cosignatures on the checkpoint. A client can check it without any prior setup beyond trusting the relevant CA and cosigners. It is larger, because it still includes signatures.
Landmark-relative certificates
A landmark-relative certificate is signature-free. The client already holds a recent, trusted tree hash called a landmark, and the certificate proves inclusion against it. This is the smallest form.
The catch is freshness. A new certificate cannot be verified this way until a landmark that covers it has been distributed to clients, so there is a processing delay. Servers can fall back to the standalone form in the meantime.
What Does a Browser Check During an MTC Handshake?
A browser validating an MTC still performs the familiar checks: the certificate must match the requested hostname, be within its validity window, and chain back to something the browser trusts. The difference is what counts as the trust evidence.
- The server sends its certificate, which includes the inclusion proof and, for the standalone form, cosignatures.
- The browser recomputes the root hash from the entry and the proof hashes.
- It compares that root with a checkpoint it can trust, either through cosignatures from parties it already trusts or through a stored landmark.
- If the computed root matches and the usual name and date checks pass, the connection proceeds.
Because the check is hashing rather than verifying a long chain of public-key signatures, it is also cheap to compute. The savings that matter most, though, are in the bytes sent over the network.
What Security Problems Do Cosigners and Mirrors Address?
A log is only useful if everyone sees the same log. If a CA could show one version of its log to one client and a different version to another, it could hide a mis-issued certificate from the domain owner.
Cosigners reduce that risk. Each one watches the log, checks that it only grows and never rewrites history, and signs the checkpoints it accepts. A client that requires signatures from several independent cosigners is much harder to deceive than one that trusts a single CA.
Mirrors serve a related purpose: they keep a copy of the log’s data, so monitors and auditors can keep working even if the original operator is slow, unreachable or uncooperative. This mirrors the accountability goals that led to Certificate Transparency in the first place.
| Term | Plain-language meaning |
|---|---|
| Issuance log | An append-only record of every certificate the CA issues |
| Checkpoint | A signed snapshot of the log’s root hash at a point in time |
| Cosigner | An independent party that signs checkpoints it has verified |
| Mirror | A copy of the log kept by another operator for auditing |
| Inclusion proof | The sibling hashes that show an entry is part of a checkpoint |
| Landmark | A trusted tree hash that clients store to verify signature-free certificates |
Key terms used in the MTC draft, explained simply.
What Are Common Misunderstandings About MTCs?
- “MTCs replace TLS.” They do not. TLS still secures the connection; MTCs change only the certificate format and issuance model.
- “MTCs are available now.” They are a draft specification with early experiments, not a mainstream product.
- “A smaller proof means weaker security.” The proof is shorter because it uses hashes, which are efficient, not because it checks less. Security depends on the hash function and on honest, independent cosigners.
- “Everything will switch at once.” Adoption is expected to be gradual, with traditional certificates continuing to work alongside MTCs for some time.
How Do MTCs Compare With Today’s X.509 Certificates?
| Aspect | Current WebPKI certificate | Merkle Tree Certificate |
|---|---|---|
| What the CA produces | A signature over each certificate | A log entry plus a signed checkpoint |
| Evidence of logging | SCTs from separate CT logs | Built into issuance |
| Authentication data in handshake | Chain of signatures and public keys | Inclusion proof (hashes), optionally cosignatures |
| Post-quantum size impact | Large if ML-DSA is used throughout | Smaller, since proofs are hashes |
| Client state | Trusted root certificates | Trusted CAs plus recent landmarks (landmark form) |
| Standards status | Mature and widely deployed | Active IETF draft |
A simplified comparison. Based on the draft as of revision 07.
Our reading is that MTCs keep the familiar X.509 framework while changing how trust is established. Existing validation steps, such as checking a domain, are unchanged.
How Do MTCs Fit With ACME and Existing CAs?
MTCs are designed to slot into the existing ecosystem rather than replace it. Domain validation and the ACME protocol, which most automated certificate issuance already uses, remain the front door. A subscriber requests a certificate, proves control of the domain, and the CA responds as usual.
What changes is the back end. Instead of producing and signing a standalone certificate, the CA operates a log and issues entries into it. That is a meaningful operational shift for CAs: they must run log infrastructure, publish checkpoints reliably and coordinate with cosigners.
For subscribers, the experience could stay very similar. The ACME client still fetches the certificate material and installs it on the server. The difference is that the material includes proof data that must be refreshed as landmarks and checkpoints advance, which means automation matters even more than it does now.
That last point is worth stressing. Teams that still renew certificates by hand are the most likely to struggle with any future change to certificate formats, MTC-based or not.
What Is the Current Status and Timeline?
MTCs are not a finished standard, and you cannot buy one from a commercial CA today. Here is what has been reported or published so far.
- IETF: the specification is an Internet-Draft in the PLANTS working group, at revision 07 as of October 2026.
- Chrome and Cloudflare: the two have publicly described an experiment with MTCs. Reported results include a median connection speed-up of about 9%. Treat that as one experiment’s result, not a general guarantee.
- Chrome root program: Google has outlined a Quantum-resistant Root Store (CQRS) with phased plans, in which MTC-based issuance is expected to play a role.
- Let’s Encrypt: the organization has said it plans to begin testing in its staging environment in late 2026, with production support targeted for 2027. Timelines like these can shift.
For the wider picture of certificate changes this year, see our overview of SSL/TLS changes and security trends in 2026.
What Are the Trade-Offs and Open Questions?
MTCs solve a real size problem, but they bring new design questions. These are the ones most often raised.
- Freshness: landmark-relative certificates depend on clients receiving up-to-date landmarks. A new certificate may not be usable in that form right away.
- Non-browser clients: devices, libraries and embedded software that rarely update will need support before they can validate MTCs.
- Middleboxes: in our assessment, inspection proxies and similar equipment could need changes. This is an inference, not a documented finding.
- Revocation: the draft handles revocation by marking index ranges in the log, which differs from CRLs and OCSP. How this works in practice at scale is still being worked out.
- Ecosystem diversity: the design adds new roles, including log operators and cosigners. Keeping that ecosystem varied and independently run matters for trust.
None of these is necessarily a blocker. They explain why the work is happening in a standards body, with experiments first.
What Should Certificate Owners Do Now?
Most site owners do not need to act on MTCs today. A sensible approach is to prepare the basics that any certificate change will depend on.
- Take inventory of your certificates, issuers and where they are deployed.
- Automate issuance and renewal with ACME where possible. MTC issuance is expected to build on ACME-style workflows.
- Check that your servers and libraries are current, and review how certificate validation works in your own clients.
- Run a configuration check on your public sites with an SSL checker.
- Follow the IETF draft and your CA’s announcements for concrete dates.
Frequently Asked Questions
Are Merkle Tree Certificates a replacement for HTTPS?
No. HTTPS and TLS stay in place. MTCs change only how server certificates are issued and proven, not how the connection is encrypted.
Are MTCs the same as Certificate Transparency?
No, but they are related. CT is a separate logging system that records certificates after or alongside issuance. With MTCs, the log entry is what makes the certificate valid.
Do MTCs make certificates quantum-safe?
They help with size, not with the underlying algorithms. A deployment still needs quantum-resistant signatures, such as ML-DSA, for the CA and cosigner checkpoints. MTCs reduce how many of those signatures a client must receive.
Can I get an MTC today?
Not for general production use. The draft is still evolving, and issuers have only described testing plans so far.
Will I need to replace my existing certificates?
There is no such requirement. Current certificates continue to work, and any move to MTCs would be gradual and driven by browser and CA announcements.