I Built a New Certificate Transparency Log in 2024 - Here’s What I Learned
Certificate transparency (CT) is such a useful research tool and I’d been wanting to learn more about it for a while. After Sunlight was announced last year, I decided the best way to learn was to write a CT log, and set off on quite the adventure.
The CT ecosystem is evolving. The original specification, RFC6962, was published in June 2013. Subsequent projects such as Go’s SumDB extended the application of transparency logs to other places. The Static CT API takes the lessons learned from these projects and applies them back to CT, moving some expensive operations from server-side to client-side. This change drastically simplifies how CT logs function and makes them much cheaper to operate.
To better appreciate the impact of these changes, my CT log implementation, Itko, supports both RFC6962 and the Static CT API. Itko also has an operational instance which is available for querying and testing against.
The Static CT API is a variant of the more generic tiled transparency log specification, a specification you can use to bring transparency to your own ecosystem – here are some of my takeaways which may be useful for you.
