Sunlight and static-ct-api are a breath of fresh air in the CT log space. Traditional CT log implementations were built on databases (because that's the easiest way to implement the old API) and were over-complicated due to a misplaced desire for high write availability. This made operating a CT log difficult and expensive (some operators were spending upwards of $100k/year). Consequentially, there have been a rash of CT log failures and few organizations willing to run logs. I'm extremely excited by how Sunlight and static-ct-api are changing this.
Is any amateur or professional auditing done on the CA system? Something akin to amateur radio auditing?
Consumers and publishers take certificates and certs for granted. I see many broken certs, or brands using the wrong certs and domains for their services.
SSL/TLS has done well to prevent eavesdropping, but it hasn't done well to establish trust and identity.
These sound like good improvements but I still don't really get why the ct log server is responsible for storage at all (as a 3rd party entity)..
Couldn't it just be responsible for its own key and signing incremental advances to a log that all publishers are responsible for storing up to their latest submission to it?
If it needed to restart and some last publisher couldn't give it its latest entries, well they would deserve that rollback to the last publish from a good publisher..
Add an incentive mechanism to motivate runn a server, and hey it's a blockchain. But those have no practical application so it must not be a blockchain..
I wonder how much putting a CDN in front of this would reduce this.
According to the readme, it seems like the bulk
of the traffic is highly cacheable, so presumably you could park something a CDN in front and substantially reduce the bandwidth requirements.
Seems like something that might be useful to store on Arweave a block chain for storage. Fees go to an endowment that’s has been calculated to far exceed the cost of growing storage
I like the idea and I like DNSSEC too (well, well enough at least—lots of tooling could be better), but DANE can’t catch on faster than DNSSEC does. And DNSSEC isn’t exactly taking the world by storm.
Even if everyone catches up on DANE, we still have ICANN controlling the registrars and root nameservers. It's absolutely crazy how everyone (incl. me, unfortunately) gave in to the centralized DNS model
1. Relying on just ICANN instead of ICANN+CA Forum would be an improvement. I assume, at least? Thinking about it though, the CA Forum setup with transparency logs and such does provide some safeguards against CA operator abuse. Those are safeguards that wouldn't be available in a DANE-only world where nameserver operators could surreptitiously inject malicious TLSA records at their whim. That could be safeguarded by DNSSEC where the domain owner does their own signing and then the nameserver operator simply serves those pre-signed records. However, that's a lot of complication. Gonna have to think about this...
2. Tbh I am not convinced of the virtues of decentralized DNS. If people use different roots in practice, then we lose the utility of a single view of names. At its most extreme, you then would not be able to reliably do things like publish a URL. However, maybe you're suggesting that DNS shouldn't be centralized with the root, but rather have a constellation of TLDs as roots? Obviously that would require shipping resolvers with hardcoded roots and wouldn't be robust when new TLDs are brought online. But maybe there'd be value in that...I'm not convinced yet though.
28 comments
[ 3.1 ms ] story [ 46.0 ms ] threadConsumers and publishers take certificates and certs for granted. I see many broken certs, or brands using the wrong certs and domains for their services.
SSL/TLS has done well to prevent eavesdropping, but it hasn't done well to establish trust and identity.
Couldn't it just be responsible for its own key and signing incremental advances to a log that all publishers are responsible for storing up to their latest submission to it?
If it needed to restart and some last publisher couldn't give it its latest entries, well they would deserve that rollback to the last publish from a good publisher..
In all seriousness, the incentive is primarily in having the data imo
And:
> Bandwidth: 2 – 3 Gbps outbound.
I am not sure if this is correct, is 2-3Gbps really required for CT?
According to the readme, it seems like the bulk of the traffic is highly cacheable, so presumably you could park something a CDN in front and substantially reduce the bandwidth requirements.
Is this actually a good use case for (gasp) blockchains? Or would it be too much data?
1. Relying on just ICANN instead of ICANN+CA Forum would be an improvement. I assume, at least? Thinking about it though, the CA Forum setup with transparency logs and such does provide some safeguards against CA operator abuse. Those are safeguards that wouldn't be available in a DANE-only world where nameserver operators could surreptitiously inject malicious TLSA records at their whim. That could be safeguarded by DNSSEC where the domain owner does their own signing and then the nameserver operator simply serves those pre-signed records. However, that's a lot of complication. Gonna have to think about this...
2. Tbh I am not convinced of the virtues of decentralized DNS. If people use different roots in practice, then we lose the utility of a single view of names. At its most extreme, you then would not be able to reliably do things like publish a URL. However, maybe you're suggesting that DNS shouldn't be centralized with the root, but rather have a constellation of TLDs as roots? Obviously that would require shipping resolvers with hardcoded roots and wouldn't be robust when new TLDs are brought online. But maybe there'd be value in that...I'm not convinced yet though.
https://youtube.com/watch?v=gnB76DQI1GE&t=19517s
https://research.mozilla.org/files/2025/04/clubcards_for_the...