Cryptography & Security Newsletter

Waiting for Static CT Logs

30 September 2025

Feisty Duck’s Cryptography & Security Newsletter is a periodic dispatch bringing you commentary and news surrounding cryptography, security, privacy, SSL/TLS, and PKI. It's designed to keep you informed about the latest developments in this space. Enjoyed every month by more than 50,000 subscribers. Written by Ivan Ristić.

NEWSLETTER SPONSOR

Red Sift's Guide to Post-Quantum Cryptography. Our concise and authoritative guide to post-quantum cryptography is packed with all the information you need to kickstart your migration and protect your critical systems from "store now, decrypt later" attacks. RED SIFT

Certificate Transparency (CT) has been a resounding success. It took about a decade, but we went from a world in which we don’t know what certificates are issued, why, and to whom, to complete visibility—at least for Web PKI, where CT is mandatory. This combination of visibility with increased scrutiny, continuous improvements in the detailed technical requirements for issuance, and linting helped us largely get Web PKI in order.

Equally important, the success of CT also helped establish the more general concept of transparency as a key technique for establishing trust in complex ecosystems. We’re already seeing transparency implemented for binaries and, in the future, for private keys and perhaps even domain validation and revocation.

Growing Pains

Behind the scenes, it hasn’t necessarily been easy. One terrifying aspect of CT, as currently implemented, is that it creates an issuance bottleneck. Previously, certification authorities (CAs) could issue certificates independently, but now they need to first obtain signatures from multiple CT logs. If the required minimum number of signatures cannot be obtained, then issuance cannot proceed.

So far we haven’t seen global availability issues caused by CT, but regular readers of this newsletter and subscribers to the ct-policy mailing list will know of the variety of problems faced by the organizations maintaining the CT infrastructure. There are constant issues with databases, storage limitations, failures, rate limiting, and the like.

Some types of failure are catastrophic and require logs to be retired. When that happens, certificate issuance has to shift to the remaining active logs. We’ve been able to do this so far, but it’s not clear how prepared we are for wider failures that might occur from, for example, reduced certificate lifetimes. In addition, are we prepared to defend the issuance infrastructure from deliberate attack?

Enter Static CT

As it stands, the bulk of the world’s certificates are recorded to CT logs operated by five organizations. In alphabetical order, they are Cloudflare, DigiCert, Google, Let’s Encrypt, and Sectigo. These days, many CT logs contain in excess of two billion certificates, and that’s after temporal sharding was introduced. With certificates allowed to last for only forty-seven days by March 2029, it’s guaranteed that the number of certificates will at least double by then. Can the system cope?

A new approach called Static CT will help. Designed by Filippo Valsorda with help from Let’s Encrypt and others, Static CT is an iteration of CT that is simpler to operate, costs less, and scales reads through caching and compression. According to Filippo, Tuscolo, the first Static CT log, costs about $10,000/year to run. The hope is that the new design will not only help existing organizations but also encourage new operators to join the ecosystem.

Let’s Encrypt is leading the adoption of Static CT with the Sycamore and Willow logs, both qualified. It also recently decided not to use the original (RFC 6962) design any more. There is also a new entrant: IPng Networks is the first smaller independent organization to join (not counting Geomys, which is affiliated with Filippo), with two sharded production logs: Gouda is already qualified, while Halloumi is in the works.

It’s not likely that the evolution of CT will end with Static CT. In fact, the next challenge will be a possible transition to a new design that will be safe against quantum computers that can break cryptography. We’ll talk more about that in due course.

Subscribe to the Cryptography & Security Newsletter

This subscription is just for the newsletter; we won't send you anything else.

Red Sift's Guide to Post-Quantum Cryptography

When it comes to post-quantum cryptography, there is a wealth of information available, but differentiating between what is immediately relevant and what isn’t can be tricky. As a treat this month, and to stay ahead of the noise, I am happy to share with you my concise guide to post-quantum cryptography. I've filled it with everything you need to know, and it's in a small package. Disclosure: I wrote this guide for my employer, Red Sift, who is also this month's sponsor. RED SIFT

Short News

Designed by Ivan Ristić, the author of SSL Labs, Bulletproof TLS and PKI, and Hardenize, our course covers everything you need to know to deploy secure servers and encrypted web applications.

Remote and trainer-led, with small classes and a choice of timezones.

Join over 2,000 students who have benefited from more than a decade of deep TLS and PKI expertise.

Find out More