I’m excited for others to see the work we’ve been doing to make CT easier to run.
Also see the discussion on the ct-policy mailing list: https://groups.google.com/a/chromium.org/g/ct-policy/c/v9Jzl...
(I am the author of the blog post)
Also see the discussion on the ct-policy mailing list: https://groups.google.com/a/chromium.org/g/ct-policy/c/v9Jzl...
(I am the author of the blog post)
Beyond the Let's Encrypt announcement and the ct-policy thread (which includes a technical and advantages summary), here are a few resources that might be interesting.
- Design document, including architecture and tradeoffs: https://filippo.io/a-different-CT-log
- Implementation: https://github.com/FiloSottile/sunlight
- API specification: https://c2sp.org/sunlight
- Website, including test logs and feedback channels: https://sunlight.dev/
If you’re thinking “oh we could use something similar” please reach out! Sunlight is retrofitting some of the modern tlog designs on a legacy system. With a greenfield deployment you can do even better! I’m working with the Sigsum project on specs, tooling, and a support ecosystem to make deploying tlogs easier and safer.
tlog = transparency log, but not neccessarily for X509 certificates?
One thing you end up needing to deploy tlogs is a way to reassure clients the tree is not forked, and for that you mostly need witness cosigning, where a quorum of third parties attest that a signed tree head is consistent with all the other ones they've seen. I've worked with the Sigsum project and the Google TrustFabric team on an interoperable specification for witnessing (which Sunlight interoperates with), and I am now working to develop a public, reliable ecosystem of witnesses.
Once you have witnessing, running a log can be as easy as hosting a few files in a GitHub repo or S3 bucket, updated with a batch script. I am very excited to make it possible for any project to get better-than-CT accountability for ~free.
(You might want to catch my RWC 2024 talk about this once it comes out!)