Add start on mtcrgdd/mtc

1 files changed, 73 insertions, 0 deletions

diff --git a/content/post/merkle-tree-certificates.md b/content/post/merkle-tree-certificates.md
new file mode 100644
index 0000000..94a441c
--- /dev/null
+++ b/content/post/merkle-tree-certificates.md
@@ -0,0 +1,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