This is one of the projects I've been most excited about in the last few years. It let me backport to Certificate Transparency some of the modern designs ideas that came after it.
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.
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.
As far as I can tell, that schema currently only supports RFC6962 logs. Are there plans in train to support enumeration of Sunlight-format logs? Or am I just far too impatient?
> As the specification, implementations, and ecosystem support evolve, we look forward to being able to include Sunlight logs alongside RFC6962 logs in Chrome. While we're not quite there yet, we encourage the CT community to experiment with the prototype logs and specification as much as possible.
> That said, we’re not planning on accepting new Sunlight logs quite yet in the Apple CT Program (though we hope that is the end result). Before that jump, we’d especially like to hear additional input (even if it’s just “LGTM”) from CT log Monitors and Auditors, as well as CAs and other relying parties submitting certificates to CT logs. Along with that, we invite input from additional SMEs able to perform (informal) security and risk assessments of the proposal — especially if they’re accompanied by filed issues :)
The log list schema is a relatively small problem and should be easily enough to solve.
Thanks for replying to what was a rather half-baked question, typed out in some excitement.
I guess a more thought-through version is as follows: Currently, the CT logs with state == usable are operated by only six entities (Cloudflare, DigiCert, Google, LE, Sectigo, TrustAsia). In the earlier days of CT logs, there were a larger number of log operators. I think it's a reasonable assumption that we've ended up in the current situation at least partly because of the cost of log operation?
Since Sunlight aims to drastically reduce the cost of log operation, might we expect the number of log operators to rise, and if so would there be likely changes to the ways that log operators are enumerated as "trusted", or would things likely be as they are now?
I'm super excited about Sunlight. The CT ecosystem is really fragile right now, with current log implemetations being expensive to operate and very difficult to operate correctly, as evidenced by the recent failures of multiple logs[1][2]. And if too many logs fall over, it becomes infeasible to include the requisite number of SCTs in certificates, or worse, already-issued certificates can become effectively untrusted.
With Sunlight reducing costs by a couple orders or magnitude and significantly easing deployment complexity, it will be a huge boon to the whole ecosystem. I really hope log monitors begin crawling sunlight logs and browsers accept them as trusted in the near future.
Is there a specification one can follow to implement a verifier for certificate transparency logs? I looked up RFC 6962, but it does not contain test vectors. I am particularly interested in history tree inclusion and consistency proofs and don’t care how tree root is signed.
We're working on it! RFC 6962 specifies inclusion and consistency proofs, but indeed it's missing test vectors. Keep an eye on https://c2sp.org and https://c2sp.org/CCTV.
There are six trusted operators, many with multiple logs. So there is some degree of redundancy, but this project is definitely an outcome of those same concerns.
Readit News
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?
As far as I can tell, that schema currently only supports RFC6962 logs. Are there plans in train to support enumeration of Sunlight-format logs? Or am I just far too impatient?
Getting them accepted as trusted lists is the goal, but how exactly that happens is not yet determined. Both the Apple and Chrome CT programs have responded to our announcement email at https://groups.google.com/a/chromium.org/g/ct-policy/c/v9Jzl...
> As the specification, implementations, and ecosystem support evolve, we look forward to being able to include Sunlight logs alongside RFC6962 logs in Chrome. While we're not quite there yet, we encourage the CT community to experiment with the prototype logs and specification as much as possible.
> That said, we’re not planning on accepting new Sunlight logs quite yet in the Apple CT Program (though we hope that is the end result). Before that jump, we’d especially like to hear additional input (even if it’s just “LGTM”) from CT log Monitors and Auditors, as well as CAs and other relying parties submitting certificates to CT logs. Along with that, we invite input from additional SMEs able to perform (informal) security and risk assessments of the proposal — especially if they’re accompanied by filed issues :)
The log list schema is a relatively small problem and should be easily enough to solve.
I guess a more thought-through version is as follows: Currently, the CT logs with state == usable are operated by only six entities (Cloudflare, DigiCert, Google, LE, Sectigo, TrustAsia). In the earlier days of CT logs, there were a larger number of log operators. I think it's a reasonable assumption that we've ended up in the current situation at least partly because of the cost of log operation?
Since Sunlight aims to drastically reduce the cost of log operation, might we expect the number of log operators to rise, and if so would there be likely changes to the ways that log operators are enumerated as "trusted", or would things likely be as they are now?
https://lite.datasette.io/?json=https://www.gstatic.com/ct/l...
With Sunlight reducing costs by a couple orders or magnitude and significantly easing deployment complexity, it will be a huge boon to the whole ecosystem. I really hope log monitors begin crawling sunlight logs and browsers accept them as trusted in the near future.
[1]: https://groups.google.com/a/chromium.org/g/ct-policy/c/6mvSo...
[2]: https://groups.google.com/a/chromium.org/g/ct-policy/c/_dhkS...
[2]: a database server had its disk full that lead to a corrupted database
SRE is tough.
Deleted Comment
https://datatracker.ietf.org/doc/draft-laurie-pki-sunlight/0...