Certificate revocation checking: A simpler fix
The last two outcomes bother me the most. Requiring each issuer to notify Google directly means certificate issuers must support at least two revocation notification pathways: one just for Google, and the normal, standard method for everyone else. It's double the work at the very least. If every browser, OS, application, and service vendor decides to follow Google's lead, then it will quickly multiply the number of notifications, each with its own procedure and format. What's to stop Facebook, Twitter, or any other service with sufficient clout from requiring its own revocation checking method, now that Google has dismissed the current method as broken?
The current process is broken only because browsers do not enforce revocation checking, and there are no consequences for failure. If the major browser vendors forced revocation checking and blocked on failure as the protocol inventors intended, most revocation problems would disappear almost overnight. The only reason digital certificate issuers get away with poor implementation is that the browsers don't enforce revocation. If the browsers did their job, the users who rely on digital certificates would force the certificate issuers and owners to fall in line.
I understand that the real problem is with consumers. A few years ago, during a major Firefox update, when the Firefox browser all of a sudden enforced revocation, Mozilla received a hailstorm of complaints that forced the company to reverse the decision. The same thing happened to Microsoft when it tried to enforce certificate revocation in Internet Explorer. It "broke" websites, pissed off customers, and drove many users to alternative browsers.
If consumers demanded that PKI worked like the inventors said it would, they would demand that revocation checking be enforced. Digital certificate issuers, hearing complaints from users and websites, would fix errant certificates and revocation pointers.
That is my main problem with Google's decision. The current process works, or would work, if we'd use it as intended. Abandoning online revocation checking for an entirely new process will only lead to varying standards, confusion, and multiplication of effort. The inventors of PKI understood this. It's why they created a standard way for checking revocation information. Plus, we have existing PKI standards such as OCSP Stapling and Strict Transport Security that can be used or extended to overcome the problems Google is trying to escape.
I don't blame Google for feeling compelled to protect its customers as quickly as it can. Fixing existing protocols is a very long process, often measured in years. Still, there is a better solution than the one Google has proposed. I'd much rather see the major browser vendors coming together and agreeing on a common enforcement date. Give the major certificate issuers and owners a set period of time to get their houses in order, then enable enforcement of revoked certificates. General industry agreement would protect the largest number of consumers with the least amount of work. It's a "kumbaya" opportunity that doesn't require proprietary mechanisms or reinvention.
This story, "Chrome turns its back on security standard," was originally published at InfoWorld.com. Keep up on the latest developments in network security and read more of Roger Grimes's Security Adviser blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.