Was this AI-generated? It seems to keep circling around the same points and have some major misunderstandings.
> If that is the case, why should the server convey the certificate and the OCSP status to the client and defer to the client on the decision not to proceed with the TLS connection? Why shouldn’t the server simply terminate the TLS connection immediately itself?
Why does it matter? You're talking about a scenario that should essentially never happen, who cares about slightly suboptimal performance at that point?
> CRLs only really work efficiently when nobody revokes certificates.
Revocation is an emergency measure, not a routine one. That's ok.
> At this point, why not just use DANE (RFC 6698), store the public keys in the DNS, rely on DNSSEC to provide the necessary authenticity, and use DNS TTL settings to control the cached lifetime of the public key?
Because DNS' multilayered caching makes it notoriously impossible to operate safely or debug. Most large outages already originate in DNS issues; putting the crypto in that layer would redouble it.
> Revocation is an emergency measure, not a routine one. That's ok.
Rather the opposite: revocation is the one time it actually matters, so your infrastructure shouldn't come to a grinding halt when it happens!
Let's say a party like LetsEncrypt needs to do a mass revocation of all certificates. Unlikely, but it has happened before. This is going to instantly blow up the CRL from perhaps a few thousand to 700 million entries. Force every browser to download that regularly and you've essentially accidentally created a DDoS on LetsEncrypt's CRL service.
And how do you want the browser to respond? Fail-closed and you've just created a method to take 80% of the internet offline by DDoSing a single service, fail-open and you've just created a method for an attacker to bypass certificate revocation entirely.
With critical infrastructure like this you can't get away with only thinking about the happy path. It should always work - even in emergencies.
> fail-open and you've just created a method for an attacker to bypass certificate revocation entirely
I generally agree about the rest but isn't what you suggest there sufficiently disproportionate to fall well outside the threat model? It buys only a limited window of opportunity in a very specific scenario while painting a neon target on your back. I feel like it's vaguely akin to worrying about a military checkpoint failing open when hit with a 30k lb bomb.
Agreeing with my sibling commenter, this writer is extremely experienced and has been writing this blog for many years. I’d be appalled if this were LLM-written, but thankfully it reads with the same style and tone that he’s always had.
> Revocation is an emergency measure, not a routine one. That's ok.
At the scale modern CAs operate, even emergency measures (i.e. measures that are an emergency for the party receiving the leaf cert) are also routine for the CA/the party granting the leaf cert.
> Because DNS' multilayered caching makes it notoriously impossible to operate safely or debug.
That is not a problem for certs, you are not changing it every second. And the "impossible to operate or debug" is just plain failse or incompetence
> Most large outages already originate in DNS issues; putting the crypto in that layer would redouble it.
That is also just not true. Also, outage of DNS coz someone fucked up configuration management somewhere is not caused by anything related to DNS, it just so happens DNS is essential so any problem is visible.
> That is not a problem for certs, you are not changing it every second.
The problem is when you screw it up and can't fix it for 24 hours or worse.
In addition to what other commenters have said, it's a copy of a post on their personal blog: https://www.potaroo.net/ispcol/2026-04/revocation.html
On revocation, check out https://bugzilla.mozilla.org/buglist.cgi?product=CA%20Progra... I don't think any CA hasn't had an issue with revocation at some point (e.g. Let's Encrypt had a major one in 2021, and refused to revoke), which is why Let's Encrypt is moving to 7 day certs (so that revocation isn't required, basically https://www.imperialviolet.org/2011/03/18/revocation.html which is mentioned in the article). My impression is CRLs (and by implication current revocation methods) don't work, and browsers are effectively fudging around CAs with custom methods (e.g. allowing existing certs but no new certs from distrusted CAs).
I'm no security expert, but modern bind9 seems to just handle DNSSEC with no issues when I've used it, and given that the "WebPKI" seems is becoming more and more reliant on custom browser code, adopting DANE outside browsers might not be the worst idea.
> I don't think any CA hasn't had an issue with revocation at some point (e.g. Let's Encrypt had a major one in 2021, and refused to revoke)
Every software org has had issues with every piece of functionality, revocation isn't special.
> modern bind9 seems to just handle DNSSEC with no issues when I've used it
The happy path works. Everything is fine until it isn't. Very few people are confident enough to fully deploy it.
According to https://stats.labs.apnic.net/dnssec DNSSEC is sitting about 1/3, so "very few" isn't accurate. I'm not suggesting browsers should change what they do, but if WebPKI can't be used, building a new CA ecosystem would seem to be to be at least as hard as getting DANE working.
The author has a long history of quality content and should be considered experienced in his field of doing.
looks like so, the emojies are dead give away.
I am not against using LLMs, but the author should have validated the contents before posting.
If you look at the older article linked (https://www.potaroo.net/ispcol/2022-03/revocation.html), it's very similar and uses the same tick/cross, so I don't think it's AI generated.