I see, but I’m not sure if it is a good idea to implement on-the-fly OCSP validation in an event-driven single threaded proxy/webserver.
We would probably block the whole process while we validate OCSP. The SSL handshake already leads to problems in medium/big setups, external OCSP verification is even more problematic. Do you really want to stall all your traffic for seconds while the OCSP validation times out?
I don’t think that’s a good idea, and actually, both Google and Mozilla are going down with a revocation list push approach, Chrome doesn’t actually do OCSP and Google even removed OCSP from boringssl completely.
If you are concerned about memory usage, think about the memory usage of caching your 500k OCSP responses in haproxy and what an attacker can do with the knowledge that your box validates client certificates with OCSP which it of course has to cache.
Yes, to push new CRLs haproxy has to be reloaded, but I’m sure this can be improved, to load refreshed CRL’s like we load refreshed OCSP responses for stapling (via the admin socket ).
If you operate your own CA, you can automate the post revocation process and push a CRL to your proxies in minutes. With OCSP you have a fixed timeout; I don’t see how OCSP can be faster, if you properly automate a CRL push to haproxy.
I suggest you post your use case to the mailing list, there are more eyes and ears there.