Short answer: Post-quantum signatures are much larger than the ones used on the web today, and a TLS handshake carries several of them. Merkle Tree Certificates (MTCs) are an IETF proposal, still in draft form, to cut that overhead by combining certificate issuance with public logging, aiming at under 1,000 bytes to authenticate a TLS key in one draft's design. They are meant to complement existing certificates, not replace them, and apply only where the relying party meets certain conditions. This is a proposal, not a deployed standard.

The size problem

An early Internet-Draft on Merkle Tree certificates notes that current signature schemes can use as few as 32 bytes per key and 64 bytes per signature, but post-quantum replacements are much larger. It gives ML-DSA-65 as an example, with 1,952 bytes per public key and 3,309 bytes per signature. It estimates that a TLS Certificate message with four ML-DSA-65 signatures and one intermediate public key would total 15,188 bytes of authentication overhead, against 3,561 and 6,913 bytes for Falcon-512 and Falcon-1024.

A later draft from the IETF PLANTS working group gives figures for ML-DSA-44, with 1,312 bytes per public key and 2,420 bytes per signature, and says that even with a directly trusted intermediate, two certificate transparency timestamps and a leaf signature add 7,260 bytes of overhead with ML-DSA-44 and 9,927 bytes with ML-DSA-65. It adds that larger keys and signatures also grow certificate transparency log entries, and that the move to shorter-lived certificates increases the number of entries.

A Cloudflare blog post, which is a vendor's account, makes the same point. It says ML-DSA-44 signatures are 2,420 bytes against 64 bytes for ECDSA-P256, and public keys 1,312 bytes against 64, roughly a twentyfold increase. It says the average TLS handshake includes several keys and signatures, adding tens of kilobytes of overhead, enough to have a noticeable impact on performance.

What MTCs propose

The drafts describe Merkle Tree certificates as a new certificate form that integrates the roles of X.509 and Certificate Transparency, achieving comparable security properties with a smaller message size. In the PLANTS draft, each certificate authority maintains logs of everything it issues, and the design reduces logging overhead in the face of shorter-lived certificates and large post-quantum signatures. It also admits an optional size optimization that avoids signatures altogether, at the cost of applying only to up-to-date relying parties and older certificates. The earlier draft describes a relying party that regularly fetches information from trusted mirrors, with an authentication cost under 1,000 bytes, and says the cost is more limited applicability. For one parameter choice the draft recommends a batch duration of one hour and a lifetime of 14 days, giving a validity window of 336 and 10,752 bytes of hashes.

The Cloudflare post describes a plan, brought with industry partners to the IETF, to redesign web certificate infrastructure for a smooth transition to post-quantum authentication, and says the goal is to whittle the number of keys and signatures in a handshake to the minimum. It states that the web today needs about five signatures and two public keys per handshake when transparency timestamps are counted.

What this does not tell you

The drafts say the mechanism is not intended to replace existing certificate mechanisms and will not be usable for all TLS connections. They are working documents that may change, and these sources do not report what browsers or certificate authorities will adopt. The performance claims come from the drafts' authors and from a vendor blog.

FAQ

Why are post-quantum certificates a problem?

Signatures and keys are much larger, and a handshake carries several, which adds overhead.

What are Merkle Tree Certificates?

A draft certificate type that integrates issuance with public logging to reduce the size of authentication.

Do they replace X.509?

The earlier draft says they complement existing mechanisms and will not suit every connection.

How small can authentication get?

The earlier draft describes authenticating a TLS key with under 1,000 bytes under its conditions.

Is it a standard?

No. The sources are Internet-Drafts.

All field notes