Apple also has a list at https://valid.apple.com/ct/log_list/current_log_list.json

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.

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 do hope we get some more log operators. We've discussed with a couple organizations that are potentially interested, so I'm hopeful we get another 2 or 3 soon.

Cost of log operation is definitely a big part of it, but I think the operational overhead of existing log software is also an issue (which is also cost, but in engineering time).

That's a fun JSON file. It's served with open CORS headers which means I can query it in Datasette Lite like this:

https://lite.datasette.io/?json=https://www.gstatic.com/ct/l...