HN Reader

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.

For the downstream side Mozilla has done some great progress with CRLite, which I think hasn't gotten enough attention.

https://youtube.com/watch?v=gnB76DQI1GE&t=19517s

https://research.mozilla.org/files/2025/04/clubcards_for_the...

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..

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.

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

How does the CT system generally accomplish the goal of append-only entries, with public transparency of when entries were made?

Is this actually a good use case for (gasp) blockchains? Or would it be too much data?

Instead of mainstreaming DANE, you want me to help a bunch of centralized CAs? No thanks. DANE is the future, it will happen

Original HN title: "You Should Run a Certificiate Transparency Log"

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..

> You Should Run a Certificate Transparency Log

And:

> Bandwidth: 2 – 3 Gbps outbound.

I am not sure if this is correct, is 2-3Gbps really required for CT?

The original article seems deleted, so https://archive.ph/TTXnK this.