> What do we do if the OCSP Responder is down? Well, it turns out, clients don't really care and they just skip the check and accept the certificate anyway, making the whole thing pointless. OCSP checking add no security!
Don't agree with this statement. It's only adding no security when the CA is down. In case a Cert is revoked and the OCSP is up, it will be blocked.
The purpose of HTTPS is to defend again MITM attacks. An MITM attacker can effectively make the OCSP responder be down, by detecting and blocking traffic to it. So, no security.
I can think of cases where an attacker can do one or not the other (in particular where they're intercepting traffic near the web server end, not the client). In those cases there is a benefit.
Because the CA is not hosted by the server itself, the routing path is very different and only converges near the end user.
I know it's less likely but to say that there is no security at all is not true in my opinion.
I went through a similar journey when trying to figure out how to revoke JWTs, i.e. forcefully sign out everywhere.
We ended up on the following: Either you accept the fact that once signed, it has a life on its own until it expires, or the issuer becomes the single point of failure.
Another issue we dealt with was validating that the person doing the request with a JWT was the owner of the JWT, and not someone who stole it. A possible fix? Distribute private keys to clients, and have them sign the JWTs on the fly. How do you check for revoked private keys? Catch-22.
[1] https://letsencrypt.org/2024/12/05/ending-ocsp/?