Merkle Tree Certificates (a.k.a. Photosynthesis)
501 views
Skip to first unread message
David Benjamin
Jun 30, 2025, 10:33:23 PMJun 30
to Certificate Transparency Policy, Bas Westerbaan, Filippo Valsorda, Luke Valenta, asymm...@chromium.org
Hi CT folks,
A bunch of us (myself, Devon O’Brien, Bas Westerbaan, Luke Valenta, and Filippo Valsorda) have been working on a design called Merkle Tree Certificates, which
https://datatracker.ietf.org/doc/draft-davidben-tls-merkle-tree-certs/
https://github.com/davidben/merkle-tree-certs
https://davidben.github.io/merkle-tree-certs/draft-davidben-tls-merkle-tree-certs.html
For folks who’ve seen an earlier iteration, this is a new version of the idea, building on some of the tlog work behind the Static CT API. We’ve been informally calling this iteration “Photosynthesis” because I enjoy silly puns too much: we’re converting sunlight into certificates. (From draft-laurie-pki-sunlight to sunlight.dev, there’s a history of CT things being called “sunlight”.)
Merkle Tree Certificates integrates CT into the certificate issuance process, rather than bolting it on after the fact. The integration lets us, I hope, deal with some inefficiencies in CT today and mitigate the size impacts of post-quantum keys/signatures in both certificate and log size. It’s a pretty long document, so I’ll give an overview here with an eye to the CT end of things:
In CT, CAs send individual certificates to a quorum of logs, with each log building its own independent tree. In MTC, the CAs construct logs, but containing only what they have issued. Log entries do not have signatures. Rather, putting an entry in the log and signing a new checkpoint constitutes the CA certifying everything in the checkpoint. Add in a public key hashing step and log sizes do not increase from post-quantum at all! We’re also working on a pruning extension to tlog which hopefully will help with the volume increase from short-lived certificates, without the churn of temporal sharding.
Instead of a quorum of logs, we use the cosignature and witness ideas from tlog. We’re also working on defining a mirror role that I think fits in this setting particularly well. These cosigners take the role of CT logs today, providing a quorum of evidence that a checkpoint is globally consistent and durably logged.
However, unlike CT, it’s all still the same per-CA tree. In CT, the monitor ecosystem can’t be guaranteed certificates are all cross-logged and must download the contents of each log. In MTC, mirrors are provably consistent with each other. If you got entries 1000-2000 from mirror A, there’s no need to re-download them from mirror B, as long as A and B’s checkpoints are consistent.
Then we package up the certificate info, an inclusion proof, and signatures into an X.509 certificate, which is what’s ultimately sent down to the client. (As a size optimization, these use a signed subtree instead of a root.)
Finally, we adapt an old STH discipline idea to mitigate PQ signatures: every hour or so, checkpoints are marked as “landmark checkpoints”. After your entry has been in the log for long enough for a landmark checkpoint, you can get a “signatureless certificate” anchored at it, but skipping the signatures. Instead, the landmark checkpoints are pre-distributed to clients. TLS servers can now present these smaller certificates when the client is up-to-date enough to already trust the landmark.
And that’s it in a nutshell. There’s a lot of pieces here, but it’s building on the work that’s already happened with CT and I expect can reuse or minimally adapt much of that existing code.
Let us know if you have any thoughts, either here or on GitHub!
David
A bunch of us (myself, Devon O’Brien, Bas Westerbaan, Luke Valenta, and Filippo Valsorda) have been working on a design called Merkle Tree Certificates, which
https://datatracker.ietf.org/doc/draft-davidben-tls-merkle-tree-certs/
https://github.com/davidben/merkle-tree-certs
https://davidben.github.io/merkle-tree-certs/draft-davidben-tls-merkle-tree-certs.html
For folks who’ve seen an earlier iteration, this is a new version of the idea, building on some of the tlog work behind the Static CT API. We’ve been informally calling this iteration “Photosynthesis” because I enjoy silly puns too much: we’re converting sunlight into certificates. (From draft-laurie-pki-sunlight to sunlight.dev, there’s a history of CT things being called “sunlight”.)
Merkle Tree Certificates integrates CT into the certificate issuance process, rather than bolting it on after the fact. The integration lets us, I hope, deal with some inefficiencies in CT today and mitigate the size impacts of post-quantum keys/signatures in both certificate and log size. It’s a pretty long document, so I’ll give an overview here with an eye to the CT end of things:
In CT, CAs send individual certificates to a quorum of logs, with each log building its own independent tree. In MTC, the CAs construct logs, but containing only what they have issued. Log entries do not have signatures. Rather, putting an entry in the log and signing a new checkpoint constitutes the CA certifying everything in the checkpoint. Add in a public key hashing step and log sizes do not increase from post-quantum at all! We’re also working on a pruning extension to tlog which hopefully will help with the volume increase from short-lived certificates, without the churn of temporal sharding.
Instead of a quorum of logs, we use the cosignature and witness ideas from tlog. We’re also working on defining a mirror role that I think fits in this setting particularly well. These cosigners take the role of CT logs today, providing a quorum of evidence that a checkpoint is globally consistent and durably logged.
However, unlike CT, it’s all still the same per-CA tree. In CT, the monitor ecosystem can’t be guaranteed certificates are all cross-logged and must download the contents of each log. In MTC, mirrors are provably consistent with each other. If you got entries 1000-2000 from mirror A, there’s no need to re-download them from mirror B, as long as A and B’s checkpoints are consistent.
Then we package up the certificate info, an inclusion proof, and signatures into an X.509 certificate, which is what’s ultimately sent down to the client. (As a size optimization, these use a signed subtree instead of a root.)
Finally, we adapt an old STH discipline idea to mitigate PQ signatures: every hour or so, checkpoints are marked as “landmark checkpoints”. After your entry has been in the log for long enough for a landmark checkpoint, you can get a “signatureless certificate” anchored at it, but skipping the signatures. Instead, the landmark checkpoints are pre-distributed to clients. TLS servers can now present these smaller certificates when the client is up-to-date enough to already trust the landmark.
And that’s it in a nutshell. There’s a lot of pieces here, but it’s building on the work that’s already happened with CT and I expect can reuse or minimally adapt much of that existing code.
Let us know if you have any thoughts, either here or on GitHub!
David
David Benjamin
Aug 5, 2025, 12:28:20 PMAug 5
to Certificate Transparency Policy, Bas Westerbaan, Filippo Valsorda, Luke Valenta, asymm...@chromium.org
Hi all!
To give an update on this work, we gave a quick presentation[1] of Merkle Tree Certificates at secdispatch in IETF 123. The result is we now have the PLANTS mailing list, PKI, Logs, And Tree Signatures!
I'd like to invite you all to join in the discussion at the list. You can find a link to subscribe and skim the archives here:
Beyond making as many plant puns as possible, the first order of business is to settle on a scope and charter for an IETF working group. There's an initial draft version at [2].
David
Phillip Hallam-Baker
Aug 8, 2025, 4:39:25 PMAug 8
to David Benjamin, Certificate Transparency Policy, Bas Westerbaan, Filippo Valsorda, Luke Valenta, asymm...@chromium.org
I have been looking at a similar approach but incorporating revocation as well.
Basically, making use of Bloom filters to identify the certificates that have been revoked. Alternatively, could resurrect Paul Kocher/ Silvio Micali's revocation trees.
--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CAF8qwaCZOJzFr8bm7wbG2%3DkE2W_p0QmAz0GYTwHq%3DKQOV5tseg%40mail.gmail.com.
Ben Laurie
Aug 11, 2025, 10:27:55 AMAug 11
to Phillip Hallam-Baker, David Benjamin, Certificate Transparency Policy, Bas Westerbaan, Filippo Valsorda, Luke Valenta, asymm...@chromium.org
We wrote up revocation transparency long ago, using spare Merkle trees...
Reply all
Reply to author
Forward
0 new messages