MIME-Version: 1.0
From: David Benjamin <davidben@chromium.org>
Date: Fri, 20 Jun 2025 14:44:04 -0400
Message-ID: 
 <CAF8qwaDsznO8MUnn4e5GRpzZpZ-6jOz8KSMVhhu1KhX3-Tgu4w@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000012e7590638054080"
Message-ID-Hash: XOVFOE3RXV6ZMWRDP5HJXNKMTI2CR37J
CC: Filippo Valsorda <ietf@filippo.io>, asymmetric@chromium.org
Precedence: list
Subject: =?utf-8?q?=5BTLS=5D_Photosynthesis=2C_an_update_to_Merkle_Tree_Certificates?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/tls/6jqhUVz58s4ZgsZ8HvuZftncT9A>

--00000000000012e7590638054080
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi all,

A while ago, we presented Merkle Tree Certificates, a certificate
optimization for Web-PKI-like PKIs with a transparency requirement.

We=E2=80=99ve since updated it with a new version, draft-05, which we=E2=80=
=99ve been
informally calling =E2=80=9CPhotosynthesis=E2=80=9D, so named because I enj=
oy 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.htm=
l

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 =E2=80=9CStatic CT=E2=80=
=9D API, as
implementation experience has shown that the RFC 6962 and RFC 9162 APIs
aren=E2=80=99t well-aligned with many common serving architectures, e.g. CD=
N
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 =E2=80=9Ctlog=E2=80=9D work also defines an ecosystem of =E2=80=
=9Ccosigners=E2=80=9D and
=E2=80=9Cwitnesses=E2=80=9D[5], which aligns with how we were envisioning t=
he transparency
ecosystem with Merkle Tree Certificates[6][7].

While the same core idea is there, the formulation is very different, so
I=E2=80=99d 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=E2=80=99s now integrated, we=E2=80=
=99ve 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=E2=80=99ve 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=E2=80=99s =
core
expertise and scope, I don=E2=80=99t expect this work to ultimately live he=
re. But
since we first presented this work here, I wanted to let you all know about
the update.

One thing I=E2=80=99d like to call out is Section 8, which sketches how to =
use this
with TLS. In particular, we=E2=80=99d really like to negotiate =E2=80=9Ccos=
igners=E2=80=9D when
presenting a certificate. This is analogous to today=E2=80=99s 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=E2=80=
=99ve
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=E2=80=99d 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/0e87eafaf1378edea744ed=
9fb07df3583f8d16c4
[7] If you read earlier iterations of the MTC draft and balked at the
=E2=80=9Ctransparency service=E2=80=9D, that was simply a poor choice of te=
rminology on my
part. It was always meant as an opaque =E2=80=9Cinsert transparency ecosyst=
em here=E2=80=9D
box to be filled in later. The relevant text in draft-03 was =E2=80=9CThis =
is
conceptually a single service, but may be multiple services, run by
multiple entities in concert.=E2=80=9D
[8] https://github.com/davidben/merkle-tree-certs

--00000000000012e7590638054080
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi all,<br><br>A while ago, we presented Merkle Tree Certi=
ficates, a certificate optimization for Web-PKI-like PKIs with a transparen=
cy requirement.<br><br>We=E2=80=99ve since updated it with a new version,=
=C2=A0draft-05, which we=E2=80=99ve been informally calling =E2=80=9CPhotos=
ynthesis=E2=80=9D, so named because I enjoy silly puns too much: we are con=
verting sunlight[0][1] into certificates.<br><br><a href=3D"https://www.iet=
f.org/archive/id/draft-davidben-tls-merkle-tree-certs-05.txt">https://www.i=
etf.org/archive/id/draft-davidben-tls-merkle-tree-certs-05.txt</a><br><a hr=
ef=3D"https://www.ietf.org/archive/id/draft-davidben-tls-merkle-tree-certs-=
05.html">https://www.ietf.org/archive/id/draft-davidben-tls-merkle-tree-cer=
ts-05.html</a><br><br>Photosynthesis combines the Static CT API[2][3] with =
the ideas in Merkle Tree Certificates, which itself is a rehash of STH Disc=
ipline[4].<br><br>For context, the CT ecosystem is moving to a new =E2=80=
=9CStatic CT=E2=80=9D API, as implementation experience has shown that the =
RFC 6962 and RFC 9162 APIs aren=E2=80=99t well-aligned with many common ser=
ving architectures, e.g. CDN caching.<br><br>Where the original Merkle Tree=
 Certificates only targeted the optimized case with a bespoke tree structur=
e, Static CT showed one can implement a CT-scale log in an efficient, scala=
ble, and cache-friendly way. The underlying =E2=80=9Ctlog=E2=80=9D work als=
o defines an ecosystem of =E2=80=9Ccosigners=E2=80=9D and =E2=80=9Cwitnesse=
s=E2=80=9D[5], which aligns with how we were envisioning the transparency e=
cosystem with Merkle Tree Certificates[6][7].<br><br>While the same core id=
ea is there, the formulation is very different, so I=E2=80=99d encourage fo=
lks to take a look. In particular:<br><br>* This gives a natural fast issua=
nce flow, so Merkle Tree Certificates is now a single integrated mechanism.=
 As it=E2=80=99s now integrated, we=E2=80=99ve changed from a custom certif=
icate format to something based in X.509. (The log entry format is extensib=
le to new formats.)<br><br>* The design of the original Merkle Tree Certifi=
cates naturally led to some nice log size optimizations, which we=E2=80=99v=
e applied to Photosynthesis. Log entry sizes do not increase from post-quan=
tum at all.<br><br>Since this is really PKI work, not TLS, and thus outside=
 this WG=E2=80=99s core expertise and scope, I don=E2=80=99t expect this wo=
rk to ultimately live here. But since we first presented this work here, I =
wanted to let you all know about the update.<br><br>One thing I=E2=80=99d l=
ike to call out is Section 8, which sketches how to use this with TLS. In p=
articular, we=E2=80=99d really like to negotiate =E2=80=9Ccosigners=E2=80=
=9D when presenting a certificate. This is analogous to today=E2=80=99s uns=
olved SCT negotiation problem, which is a part of why CT enforcement for th=
e long tail of non-browser, Web-adjacent clients is difficult today. (That =
is probably a discussion in itself.)<br><br>As always, this document is int=
ended as a starting point. Although we=E2=80=99ve worked out many details c=
oncretely, 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!)<br><br>Let us know if you have any thoughts, ei=
ther here or on GitHub[8]!<br><br>David<br><br>[0] <a href=3D"https://datat=
racker.ietf.org/doc/draft-laurie-pki-sunlight/12/">https://datatracker.ietf=
.org/doc/draft-laurie-pki-sunlight/12/</a><br>[1] <a href=3D"https://sunlig=
ht.dev/">https://sunlight.dev/</a><br>[2] <a href=3D"https://c2sp.org/stati=
c-ct-api">https://c2sp.org/static-ct-api</a><br>[3] <a href=3D"https://lets=
encrypt.org/2025/06/11/reflections-on-a-year-of-sunlight/">https://letsencr=
ypt.org/2025/06/11/reflections-on-a-year-of-sunlight/</a><br>[4] <a href=3D=
"https://mailarchive.ietf.org/arch/msg/trans/Zm4NqyRc7LDsOtV56EchBIT9r4c/">=
https://mailarchive.ietf.org/arch/msg/trans/Zm4NqyRc7LDsOtV56EchBIT9r4c/</a=
> =C2=A0(Apologies, Richard! I had thought I=E2=80=99d included your mail i=
n the acknowledgements long ago but apparently forgot. It is there now.)<br=
>[5] <a href=3D"https://c2sp.org/tlog-witness">https://c2sp.org/tlog-witnes=
s</a><br>[6] <a href=3D"https://github.com/davidben/merkle-tree-certs/commi=
t/0e87eafaf1378edea744ed9fb07df3583f8d16c4">https://github.com/davidben/mer=
kle-tree-certs/commit/0e87eafaf1378edea744ed9fb07df3583f8d16c4</a><br>[7] I=
f you read earlier iterations of the MTC draft and balked at the =E2=80=9Ct=
ransparency service=E2=80=9D, that was simply a poor choice of terminology =
on my part. It was always meant as an opaque =E2=80=9Cinsert transparency e=
cosystem here=E2=80=9D box to be filled in later. The relevant text in draf=
t-03 was =E2=80=9CThis is conceptually a single service, but may be multipl=
e services, run by multiple entities in concert.=E2=80=9D<br>[8] <a href=3D=
"https://github.com/davidben/merkle-tree-certs">https://github.com/davidben=
/merkle-tree-certs</a><br></div>

--00000000000012e7590638054080--