Hacker News Reader

Comment by jaas | Hacker News Reader

OCSP systems at scale are complex. At the core there is an on-demand or pre-signed OCSP response generation system, then there is usually an internal caching layer (redis or similar), then there is an external CDN layer. Just because the outer layer appears not to know about a certificate (a bug, to be sure), doesn't necessarily mean that other CA systems don't know about it.

Requiring CAs to run OCSP makes running a CA more complex and expensive, which has considerable downsides like it does for any system, particularly as it is a zero sum game. Every dollar or hour of engineering time that Let's Encrypt spends on OCSP (and it is a considerable amount) is a dollar or hour not being spent on other parts of the CA. From the outside that may not be very visible because it's not obvious what isn't getting done instead but there is a real and considerable cost that is not worth it IMO.

View on HN

CAs are money printing machines. If they cannot even track the state of their delegated trust, then why should they be trusted themselves?! Trust is their core value proposition, the only reason they exist!

For what it's worth, the person you're replying to is the founder and executive director of Let's Encrypt, the non-profit free and open CA which decidedly isn't a money-printing machine.

The person you're replying to (Josh Aas) is the head of the largest CA in the world, which has never charged anyone for a certificate and has never made a profit. That CA, at least, isn't a money-printing machine!

Good point. Though being a non-profit doesn't remove the fact that the value proposition of CAs is trust.

Perhaps there is some compromise like they just have to submit all issuances certs to a 3rd party, and maintain the last few months worth of issuances.

Part of that compromise is already in effect:

https://certificate.transparency.dev/

Why don’t CT logs include revocations? Seems like that could provide transparency into this without the need for another system (OCSP)

Downloading the CT log is an enormous amount of data, so it addresses a rather different case from the "is this certificate valid right now (because I'm thinking of accepting it)?" question.

Do you disagree that OCSP would be significantly less costly and complex if the responder URL were not included in certificates, freeing the responders from having to serve hundreds of millions of clients?

Yes, I disagree. Best case scenario I think it would just allow us to get rid of the CDN layer. We'd still have to build and manage the rest with utmost care.

Even that really depends on what the "SLA" expectation is. How many QPS would we be required to support before we're allowed to start dropping queries? If there's any possibility of a burst beyond what we can handle locally we'd keep the CDN, so maybe the CDN bill would be significantly smaller on account of lower volume but all the complexity and care of operation would still be there.

They are so complex, and in practice unreliable, that my employer runs a caching proxy for our (non-browser) users (they mostly don’t want fail open).

IMO it is unfixable and should go

I don’t understand what relevance your caching proxy has. if you have time, are you able to explain this a bit further?

The CA ocsp endpoints are so unreliable we have to run a cache (the sdk we provide will use it).

Relying on OCSP alone client-side is simply too unreliable, either the responses have to be cached client-side or the server has to do stapling.

Reply on news.ycombinator.com