Good general summary, but it misses some big issues with revocation checking. OCSP servers are notoriously unreliable - and with the increasing use of tls I do

Good general summary, but it misses some big issues with revocation checking. OCSP servers are notoriously unreliable - and with the increasing use of tls I don't see that improving - and that required open failure for TLS connections in browsers. That kind of defeats the purpose of revocation checks as someone can kill the OCSP connection and browsers will have to continue. Even when EV certs were a thing OCSP responders had a tendency to go down. The really big problem though is privacy - revocation checks require transmitting every server name you are accessing, and secure DNS (if it existed) would not be sufficient to hide where you are navigating. CT "solves" this by at least requiring an SCT so we know that in principle any cert we do encounter has been posted somewhere where effected individuals can see a misissuance. This obviously doesn't stop misissuance, it just makes it visible and allows us to determine whether CAs have verification flaws, etc. It also doesn't do anything about revocation checking as that is still dependent on OCSP, so has the aforementioned problems. Part of the move to short term certificates is to reduce the need for revocation checks as the lifetime of threat is much more restricted, so someone has to repeatedly compromise a CA to maintain an attack. One other mechanism browsers have is certificate kill lists, which came into existence following the CNNIC and Symantec misissuances - essentially in the event of high profile/major site misissuance vendors can post a more or less immediate "don't trust these certs" list that is fast and robust vs. OCSP.