[TLS] Photosynthesis, an update to Merkle Tree Certificates

[David Benjamin <[e-mail]>]

Hi all,

A while ago, we presented Merkle Tree Certificates, a certificate
optimization for Web-PKI-like PKIs with a transparency requirement.

We’ve since updated it with a new version, draft-05, which we’ve been
informally calling “Photosynthesis”, so named because I enjoy silly puns
too much: we are converting sunlight[0][1] into certificates.

https://www.ietf.org/archive/id/draft-davidben-tls-merkle-tree-certs-05.txt
https://www.ietf.org/archive/id/draft-davidben-tls-merkle-tree-certs-05.html

Photosynthesis combines the Static CT API[2][3] with the ideas in Merkle
Tree Certificates, which itself is a rehash of STH Discipline[4].

For context, the CT ecosystem is moving to a new “Static CT” API, as
implementation experience has shown that the RFC 6962 and RFC 9162 APIs
aren’t well-aligned with many common serving architectures, e.g. CDN
caching.

Where the original Merkle Tree Certificates only targeted the optimized
case with a bespoke tree structure, Static CT showed one can implement a
CT-scale log in an efficient, scalable, and cache-friendly way. The
underlying “tlog” work also defines an ecosystem of “cosigners” and
“witnesses”[5], which aligns with how we were envisioning the transparency
ecosystem with Merkle Tree Certificates[6][7].

While the same core idea is there, the formulation is very different, so
I’d encourage folks to take a look. In particular:

* This gives a natural fast issuance flow, so Merkle Tree Certificates is
now a single integrated mechanism. As it’s now integrated, we’ve changed
from a custom certificate format to something based in X.509. (The log
entry format is extensible to new formats.)

* The design of the original Merkle Tree Certificates naturally led to some
nice log size optimizations, which we’ve applied to Photosynthesis. Log
entry sizes do not increase from post-quantum at all.

Since this is really PKI work, not TLS, and thus outside this WG’s core
expertise and scope, I don’t expect this work to ultimately live here. But
since we first presented this work here, I wanted to let you all know about
the update.

One thing I’d like to call out is Section 8, which sketches how to use this
with TLS. In particular, we’d really like to negotiate “cosigners” when
presenting a certificate. This is analogous to today’s unsolved SCT
negotiation problem, which is a part of why CT enforcement for the long
tail of non-browser, Web-adjacent clients is difficult today. (That is
probably a discussion in itself.)

As always, this document is intended as a starting point. Although we’ve
worked out many details concretely, this is only to help illustrate the
design. (After all, we went from draft-04 to this formulation, and I would
still consider this to be in continuity with draft-04!)

Let us know if you have any thoughts, either here or on GitHub[8]!

David

[0] https://datatracker.ietf.org/doc/draft-laurie-pki-sunlight/12/
[1] https://sunlight.dev/
[2] https://c2sp.org/static-ct-api
[3] https://letsencrypt.org/2025/06/11/reflections-on-a-year-of-sunlight/
[4] https://mailarchive.ietf.org/arch/msg/trans/Zm4NqyRc7LDsOtV56EchBIT9r4c/
 (Apologies, Richard! I had thought I’d included your mail in the
acknowledgements long ago but apparently forgot. It is there now.)
[5] https://c2sp.org/tlog-witness
[6]
https://github.com/davidben/merkle-tree-certs/commit/0e87eafaf1378edea744ed9fb07df3583f8d16c4
[7] If you read earlier iterations of the MTC draft and balked at the
“transparency service”, that was simply a poor choice of terminology on my
part. It was always meant as an opaque “insert transparency ecosystem here”
box to be filled in later. The relevant text in draft-03 was “This is
conceptually a single service, but may be multiple services, run by
multiple entities in concert.”
[8] https://github.com/davidben/merkle-tree-certs