In my last blog post, I provided background on why Google proposed changing the trust of Symantec certificates in Chrome. But the dust still hasn’t settled. A lot still depends on recent discussions between Symantec and the browser vendors (Google and Mozilla). Google recently indicated that new information has come to light, such as potentially several additional unaudited sub-CAs chaining to Symantec. Additional information may also arise from Symantec’s formal response by the April 20 deadline set by Mozilla. As a result, Google will likely make changes to its original proposal (especially since the time available to implement changes initially proposed in Chrome 59 is too short).
Notwithstanding any new information that comes to light, I’d like to explore what options we have as an industry to respond to a situation like this. Is it, in fact, best to have the browser vendors drive remedial CA action? How should the industry as a whole respond to certificate issues like this?
Here are a few possible options and some consideration of the pros/cons of each:
Don’t do anything. As an industry, we could agree to let the existing Symantec certificates be trusted and have faith that Symantec will enforce better policies for new certificates (note that Symantec has already made changes, like eliminating their external RA program).
Pros: This option would minimize disruption to site owners and users because all existing Symantec certificates would expire at their expected times.
Cons: This essentially renders the Baseline Requirements meaningless. People can complain that certificate authorities (CAs) aren’t following good practices, but if the industry chooses this option, the CAs don’t really have to worry about any consequences for ignoring the Baseline Requirements. You could retort that CAs could suffer reputation risk and lost business if they cause a big certificate issue. The problem with this line of thinking is that we must wait for issues to occur instead of proactively enforcing good practices to avoid the issues in the first place. CAs who have been investing in security to meet the Baseline Requirements might start to reduce their investments because there is no market incentive to continue those investments.
Have Symantec Self-Remediate. Symantec could offer to proactively reach out to its existing customers and replace all of its existing certificates. They might even start revoking them on a schedule similar to the one proposed by Google for distrusting them. Symantec has already indicated that they will replace certificates free of charge if Google moves forward but, in this option, they would replace them proactively.
Pros: This option enables Symantec to proactively show it considers that its recent issues merit remediation to preserve the integrity of Internet security (I’m using this term as shorthand for the myriad of implications connected with the issues Google and Mozilla have uncovered). Effectively, Symantec avoids a black eye and shows its commitment to proactively addressing the issues resulting from its actions.
Cons: The challenge is that Symantec is reliant on site owners to renew certificates (Symantec can’t replace a certificate without a site owner submitting a request). Symantec may not have up-to-date contact information for all site owners, especially since some of this information was collected by Symantec sub-CAs, and site owners may simply not take timely action. With respect to Symantec potentially forcing replacement by starting to revoke certificates, revocation checking is not consistently enforced across the applications and systems that use certificates so it is not a reliable mechanism for forcing change. Finally, if attackers did get a rogue certificate through a crack in Symantec’s (or their RA’s or sub-CA’s) processes, they’re not going to want to replace that certificate and will hold out as long as they can so they can gain maximum leverage from that attack asset.
Have Google (and other Browsers) Implement the Proposed Change in Trust. After concluding its discussions with Symantec and getting requested approvals from the Blink API Owners, Google would move forward with an updated version of their proposed plan to accelerate distrust of Symantec certificates. Other browsers might also follow suit.
Pros: This ensures that existing Symantec certificates with questionable issuance pedigree are replaced as soon as practicable. It also reinforces the importance of certificate security and the need for all participants in public key infrastructure (PKI)—not just CAs—to make security a priority. In addition, this raises the awareness of the need to be prepared to respond to large scale CA incidents as well as other PKI incidents. This is, in effect, a dry run for how to handle a CA compromise.
Cons: This course of action will likely result in many sites unexpectedly being distrusted prior to the original certificate expiration date. This will cause disruption for the site owners and their users.
In my mind, option #1 (do nothing) is not a prudent path for the industry. Certificates form the bedrock of Internet security. If the standards that govern their issuance are not enforced, they simply cannot be trusted. Because there is no effective way we can educate internet users on how to decide for themselves which CAs and certificates they will or won’t trust, we simply can’t rely on each CA coming up with its own “standards” for secure issuance.
Options #2 and #3 (Symantec remediation and browser remediation) could be implemented in tandem to reduce potential disruption. This is likely to be the way this situation plays out. I’m sure that Symantec, with its depth of security experience, is already looking at how to remedy this situation—independent of what any other party does—to ensure the security of the Internet.