Based on the OP tweet... depending on the way it is unavailable, the failure is indeed ignored in some cases. "Denying that connection fixes it, because OCSP is a soft failure (Disconnect internet also fixes.)"
So it may be an actual unintended bug that a particular failure path results in a DoS instead?
A better option is to asynchronously update a Certificate Revocation List ("CRL") and perform any check local to the machine. This avoids disclosing to Apple every single time you run a program, which program it is, and what network you're on. It could also emergency-revoke certificates just as quickly as the OCSP design by polling at the same frequency (every app startup).
Much faster, updates relatively quickly, and not subject to network outages.
I don’t think the design is wrong, I just think it’s tuned a little too cautious. If you’re going to verify certs then checking the CRL is something you really should do before approval. And you can’t sync the database entirely because it’s too big.
There really aren’t any good solutions to this unless you can solve the cache invalidation problem.
I think it's probably an unintended bug that this failure mode was fail-closed.
The costs of this unintended bug are going to be huge to Apple's reputation, as demonstrated in this whole HN thread, where many assuming what's going on is even WORSE than it really is.
(Personally I think having signed certs (with opt-in ability to run unsigned apps, as MacOS has) is fine. And fail-open OSCP revocation check is also fine-ish, although it would annoy me if it's making it slower to launch apps on the regular. The problem here is a bug, not one of design. But most of this thread is assuming Apple was doing something different than this. Of course, how often a company produces fairly catastrophic bugs is also on them).
I agree that breaking system availability when an OCSP server isn't available is user-hostile and unnecessary.