1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
|
---
title: "Merkle Tree Certificates"
date: 2025-08-13
---
# Merkle Tree Certificates
The latest revision of [Merkle tree certificates][mtc] was circulated on several
mailing lists two months ago. When discussing the draft with one of the authors
over a virtual walk, I remember ending the conversation saying 'You know what
surprised me the most when giving this a thorough read'? I continued, 'That
the document is 55 pages, that there's so much terminology, yet the gist is so
simple'.
This post aims to help readers see the forest for the trees.
[mtc]: https://www.ietf.org/archive/id/draft-davidben-tls-merkle-tree-certs-05.html
## Why this type of innovation is needed
A typical certificate looks something like this:
+-------------------------------------|
| Names: example.com, www.example.com |
| Public key: <serialized key> |
| |
| Valid From: 2025-07-01 12:00 UTC |
| Valid To: 2025-09-29 12:00 UTC |
| |
| ... |
| |
| Issuer: Let's Encrypt Authority X3 |
| Signature: <serialized signature> |
+-------------------------------------|
What will happen when the site's public key is transitioned from RSA to a
post-quantum secure alternative?
What will happen when the issuer's signature is replaced with a post-quantum
secure alternative?
You got that right---the certificate size will increase because post-quantum
secure keys and signatures are larger than today's RSA and eliptic curve
cryptography. Citing the [latest revision][mtc] of the Merkle tree
certificate's draft:
>
> Current signature schemes can use as few as 32 bytes per key and 64 bytes per
> signature [RFC8032], but post-quantum replacements are much larger. For
> example, ML-DSA-44 [FIPS204] uses 1,312 bytes per public key and 2,420 bytes
> per signature. ML-DSA-65 uses 1,952 bytes per public key and 3,309 bytes per
> signature.
>
It's even worse than the above diagram suggests, because there are also
additional signatures that I omitted from Certificate Transparency logs.
>
> Even with a directly- trusted intermediate (Section 7.5 of
> [I-D.ietf-tls-trust-anchor-ids]), two SCTs and a leaf certificate signature
> adds 7,260 bytes of authentication overhead with ML-DSA-44 and 9,927 bytes
> with ML-DSA-65.
>
Increased certificate sizes is less than ideal, ranging from the amount of bits
that your browser needs to transfer early on in the TLS handshake on every
website visit (a.k.a. increased latency) to the amount of bytes a Certificate
Transparency log needs to receive, store, and serve (a.k.a. disk, RAM, and
bandwidth costs).
If we want to do something about these costs, now is the time to put our
collective minds together and incrementally move towards a solution.
## How to think about Merkle tree certificates
|
