This is when someone would propose using Certificate Transparency, but except for Let's Encrypt there isn't any major CA publishing their full list. And, it's entirely optional thus far -- the CA base requirements do not require CT. Nor does submitting to one CT log submit any other; the onus is on the CA to submit to every CT log (infeasible) or for auditing groups/programs to track every CT log that comes up (a little more feasible, but still ridiculously hard).

So people have come up with using alternatives, like the blockchain! I feel like that's throwing the baby out with the bath water, though.

Certificate transparency is solving a different problem, one that is relatively specific to TLS. Most other uses of the CA model have a single CA or at least a single CA for each trust area, which makes other parties monitoring their output somewhat less urgent. TLS is quite special in that it has multiple independent CAs with full signing powers and in practice those CAs are not trusted by the people who actually use the certificates.

(Of course, a CT-like system is useful because it can enable early detection of bad or unexpected certificates. But within an organization you can achieve it by sending your CA signing logs into your regular log monitoring infrastructure and then building alerts on various criteria. TLS needs the whole CT infrastructure because its CAs live in different organizations.)

Also, I believe that CT is not currently part of the TLS trust model in the way OCSP is, in that you don't make a 'is it in the CT' check before trusting a certificate. It's just used for (outside) monitoring of issued certificates. As TLS has shown, you need a proactive pre-trust check; otherwise you are back in the after-the-fact revocation world where attackers get at least one success before you can stop them.

I like the idea of FreeIPA (or something similar) keeping a record of known host keys and serving them as SSHFP records (over DNSSEC, naturally) or via LDAPS (which sss_ssh_knownhostsproxy makes use of). But that only shifts the problem with CAs to DNSSEC and TLS.

Unfortunately in practice OCSP doesn't even work very well for the web as traditionally deployed -- the OCSP lookups often take so long that the rest of the web transaction could have happened first, so, eg, Google Chrome does not check OCSP. And what do you do if you can't reach the OCSP server? Fail closed? But the OCSP servers traditionally haven't been very reachable even in ideal circumstances. Fail open? In that case, an active attacker just blocks the OCSP traffic too, you fail open, and you're no better off than if you hadn't checked.

The only practical work around to this seems to be "short duration". Which is roughly what OCSP stapling aims to do (attach a short duration OCSP response to a longer duration certificate; eventually refuse certificates without it attached). And is partly what Lets Encrypt's shorter duration aims to do -- plus something that knew of the policy could, eg, refuse to accept a certificate claiming to be valid for any longer.

If the duration is made short enough, then it approximates the benefits of real-time OSCP checks, without the latency.

Ewen

My view is that while OCSP has real issues on the web, some form of an 'explicit check' protocol is much more feasible inside an organization (and I'd like to see it supported by protocols at least as an option). Many of the network issues are far less severe inside most organizations and this makes fail-closed much more viable. At least some of the time the organization already has a fail-closed authentication system that it's okay with for most purposes.

(Eg, if you're willing to use LDAP or some other centralized system for authentication you're clearly willing to have a central point of authentication failure.)

As you've mentioned before, a breach of CA security requires immediately revoking the CA itself and thus all of the certificates it has signed (and ideally it would also mandate some way to audit all prior uses of those certificates back to a time when the CA was known to be secure, which might be day 0, before the first certificate was ever signed).

I would suggest that when signed certificates are used for identification, authentication, and authorization, they really must be only one of the factors used, one with a weight no greater than at least one other factor, such as a passphrase, a one-time key, or maybe a crypto challenge processed by some separate physical device (which one might consider is effectively a separate private key).

I don't think it really matters whether the certificate is presented by the user, the server, or both.