We believe that we have put forward a proposal [1] that provides the highest level of transparency and reassurance of trust in active SSL/TLS certificates available in the industry. We also believe that our proposal avoids the imposition of significant compatibility and interoperability risks, as well as customer business disruption, which would result from any proposal that limits the trust of existing Symantec SSL/TLS certificates, imposes shorter validity periods on newly issued Symantec certificates, and/or removes EV recognition for our certificates in browsers. This post responds to comments about our proposal made by Ryan Sleevi in his post summarizing Google’s discussions with Symantec [2] and by Gervase Markham in his draft proposal on behalf of Mozilla [3].
1. We are confident in our issuance processes and in the additive protection measures already in place, which is why we are conducting extensive audits that will be made public as outlined in our proposal. We have proposed audits that go far beyond the scope of traditional WebTrust for CAs and Baseline Requirements audits.
a. In the case of EV certs we will have an external auditor examine 100% of the active EV certificates issued. We are confident in our processes and a full, detailed external audit is the best mechanism we are aware of to showcase this.
b. In the case of our SSL/TLS RA program, we have taken the most conservative action possible: we have shut it down. Additionally we have almost completed our revalidation of every active certificate that our former TLS RA partners have authenticated. As of May 4, 2017, the status of the revalidation or review of the active certificates authenticated by our former TLS RA partners is as follows:
* The certificates in the “Errors” column of the table above, which we have revoked and replaced, were due to spelling mistakes in information in the organization name, imprecise values in locality (e.g. related to the name change of Distrito Federal to Ciudad de Mexico, similar to those called out by other CAs and considered acceptable exceptions to the Baseline Requirements by Google [4] and Mozilla [5]), or instances where we did not receive sufficient documentation to substantiate subject information. In the case of Certisur, after receipt of additional substantiating information and further review, we concluded that 6 of the revoked certificates were compliant with the Baseline Requirements and satisfied Symantec policies.
c. Further, we have proposed to have an external auditor revalidate all of our work described in the table above with RAs and make that report public. For clarity, we are not proposing an audit that is subject to standard audit sampling practices, but rather third party review and validation of 100% of these active, RA-validated certificates.
In addition, we previously added extensive controls to our issuance process in response to the 2015 test certificate mis-issuance incident documented here [6]. This included an automated compliance checking engine that blocks non-compliance with the Baseline Requirements.
Moreover, the additional transparency we are already providing by logging all certificates issued to Certificate Transparency logs – including DV and OV – is a practice that the rest of the industry has yet to adopt. This transparency effort included explicitly providing to Google for whitelisting the certificates that were issued by Symantec prior to us fully deploying CT support.
Finally, we have proposed moving to quarterly WebTrust audits going forward to provide the community with even more frequent updates on the reliability of our processes.
These measures are designed to demonstrate the integrity of our active certificates and to provide timely visibility into the integrity of our future certificate issuances. A third party review of all (100%) active EV and RA-issued certificates is at the extreme end of transparency and we believe such reviews will assure the community about our issuance practices.
2. Mr. Sleevi has set forth a second proposal that involves Symantec outsourcing its SSL/TLS issuance to a third party. We have evaluated this sub-CA proposal and believe it is unwarranted and not proportional to the actual or perceived risk that is mitigated under our proposal. We believe our issuance processes are sound and that the transparency initiatives outlined above – specifically, published reports from our third party audits that we expect to complete by August 31, 2017 – will confirm this for the community. Until the audit results are available for public review, we think it is premature to suggest that Symantec consider any such sub-CA proposal.
3. While we recognize that shorter validity certificates may reduce exposure to certain security risks, we believe any such change must be consistent across the entire CA industry and be phased in over a period of time taking into consideration existing barriers to adoption. Both Mr. Sleevi (in his latest proposal) and Mr. Markham propose a 13-month validity limit for Symantec certificates. Limiting Symantec’s ability to issue longer-lived certificates while not imposing that same limit on other CAs is uniquely punitive to Symantec’s CA business and unjustified. We also do not believe that a 13-month validity limit should be imposed on the CA industry at this time– a conclusion that is reinforced by the recent CA/Browser Forum vote rejecting ballot 185, which proposed to limit the maximum validity of SSL/TLS certificates issued by all CAs to 13 months. As we have stated in our public response, many enterprises are not at the level of automation maturity necessary to practically and cost-effectively adopt shorter validity certificates. For these organizations, standardizing on shorter validity certificates would present substantial increases in their operating costs. A significant percentage of our active certificates have a validity period greater than 13 months. We have heard from many customers that they will move to another CA if a major browser limits the validity of Symantec certificates to 13 months or less to avoid the operational burden of replacing certificates more frequently – particularly when commercial alternatives exist. If this action is taken exclusively against Symantec, it will create significant disruption for hundreds of thousands of customers / users and will harm our CA business.
In light of the difficulty of currently operationalizing the replacement cycle of short-lived certificates for many of our customers, we have proposed 9-month domain revalidation of all of our certificates. An initial certificate validation is one level of authentication. Certificate domain revalidation post-deployment further extends the trustworthiness of the initial certificate, which is a positive extension of the CA trust model. This 9-month domain revalidation proposal is intended to supplement our proposed expanded offering of shorter validity certificates for those customers for whom it would be a significant burden to adopt them. We’ve proposed reporting our revalidation findings externally and, working with the browser community, we believe we can establish appropriate transparency mechanisms (e.g. through an OCSP extension or a signed revalidation list) that provide an attestation to this revalidation and ensure accountability of our implementation of this action. We’ve also proposed continuing our investments in automation to enable organizations with even the most complex infrastructure to practically and cost-effectively adopt shorter validity certificates.
4. Portions of Mr. Sleevi’s sub-CA proposal were redacted and he mentioned that Symantec shared additional details with Google during our joint meetings that Symantec did not make public in its response. In our private discussions with Google, we shared key elements of our current solution roadmap, which, as a normal evolution of our business, includes enhancing our issuance platform to create a competitive advantage in the marketplace. We publicly highlighted our investments in this area in our proposal as part of our discussion of automation and supporting shorter validity certificates – specifically, “[o]ur near term investments will focus on modernizing our certificate issuance systems and workflows to enable faster issuance, and developing tools that enable customers to rapidly and securely implement their certificates and configure their systems.” We intend to keep the community informed about our progress here as part of the quarterly updates we have proposed to deliver to the community.
In summary, we believe our proposal provides the most open and transparent posture of any CA in the industry and reassures trust in active Symantec certificates and our current issuance practices. Our proposal also mitigates the significant compatibility and interoperability risks, as well as customer burden, which would result from any proposal that limits the trust of existing Symantec SSL/TLS certificates, imposes shorter validity periods on newly issued Symantec certificates, and/or removes EV recognition for our certificates in browsers.
We understand our role as a key player in the trust ecosystem of the Internet and take it very seriously, including the obligation to follow the compliance frameworks set forth by the CA/Browser Forum and browser root programs. We believe the error rate of our issuances is low compared to our peers and we welcome objective third party information that puts this into context. While third party, comparative data from Netcraft supports our position that our certificate issuances are equal to or better than other CAs, we always work to do better.
We encourage the community to consider objective, comparative results of our processes with others along with the merits of our proposal. It is important that any actions taken by Google and Mozilla don’t overreach and result in unnecessary business disruption to customers and users of sites that rely on Symantec SSL/TLS certificates. We believe careful and deliberate consideration of the strengths and weaknesses of Symantec’s proposal as compared to those proposed by Google and Mozilla requires more time than has been implied by Mr. Markham and should involve more feedback from the affected stakeholders in the Internet ecosystem than has been received to date. To that end, we recommend that Google and Mozilla take the time to proactively reach out to the enterprises whose voice is greatly underrepresented in these forums to truly understand the customer use cases we have described and the reasoning behind our proposal.
[1]: https://www.symantec.com/connect/blogs/symantec-ca-proposal
[2]: https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/lOHrTr97Qx0/2IkcSGq9AQAJ
[3]: https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/IZYmm8zsSKU/vwPIi2L1AgAJ
[4]: https://groups.google.com/d/msg/mozilla.dev.security.policy/DgeLqKMzIds/x-Rj2AgSAwAJ
[5]: https://groups.google.com/d/msg/mozilla.dev.security.policy/DgeLqKMzIds/emMZb_E4AwAJ
[6]: https://www.symantec.com/page.jsp?id=test-certs-update#