Our primary objective has always been to minimize any potential business disruption for our customers and for browser users while also reassuring trust in Symantec certificates and our issuance practices. While we believe we achieved that balance with our original proposal to the community, the browser community (specifically, Google, Mozilla and Opera) has since converged upon a new proposal.
Google shared this new proposal for Symantec’s CA with the community on May 15. We have since been reviewing this proposal and weighing its merits against feedback we’ve heard from the broader community, including our CA customers. As part of our review, we’ve conducted a preliminary analysis of the engineering, contract and business development requirements needed to implement the subCA portion of the proposal outlined by Google. Additionally, we have had initial conversations with candidate partners (or “SubCAs”) to understand the potential timeline and integration constraints that would need to be factored into a successful adoption of a subCA approach. While we are waiting to receive detailed responses to a Request For Proposals (RFP) from these potential SubCAs, we wanted to share our initial feedback to Google’s current proposal.
First, we acknowledge the mis-issuances we’ve experienced in our CA business and we take these incidents very seriously. We believe these incidents are the exception and not the rule for our CA operations. Our CA business is led and staffed by experienced individuals around the world who serve our customers while ensuring our issuance practices comply with industry and browser requirements.
That said, we understand that any failure of our SSL/TLS certificates to be recognized by popular browsers could disrupt the business of our customers. In that light, we appreciate that Google's current proposal does not immediately pose compatibility or interoperability challenges for the vast majority of users. Indeed, while there are significant backend changes required under Google’s latest subCA proposal, we believe it is designed to minimize impact to our CA customers and browser users. Notably, Google’s current proposal preserves the treatment of Symantec EV certificates and provides a pathway for us to continue supporting our customers with industry standard certificate validity periods. Furthermore, the current proposal allows our customers, for the most part, to have an uninterrupted and unencumbered experience.
However, there are some aspects of the current proposal that we believe need to be changed before we can reasonably and responsibly implement a plan that involves entrusting parts of our CA operations to a third party.
As the largest issuer of EV and OV certificates in the industry according to Netcraft, Symantec handles significantly larger volumes of validation workloads across more geographies than most other CA’s. To our knowledge, no other single CA operates at the scale nor offers the broad set of capabilities that Symantec offers today. In addition to the vetting required to identify suitable CA partners, we believe there may be a significant ramp up period required for any CA to augment the resources needed to accommodate our certificate issuance volumes in a robust, reliable, secure, and fully compliant way. Before a technical integration and transition can begin, Symantec would need to evaluate the capabilities of interested and qualified CAs. We would also need time to put in place the governance, business and legal structures necessary to ensure the appropriate accountability and oversight for the subCA proposal to be successful.
Once we enter into a partnership with one or multiple SubCAs, Symantec and the SubCA(s) will need to perform engineering work to support the subCA model. These implementations would then need to be tested extensively.
Given the time needed to overcome these challenges, we have proposed modifications that we ask Google, Mozilla, other browsers, relying parties and the community to consider as we work to reach a final plan. Our goal is to move to an agreed-upon action plan that we can begin to implement in a reasonable timeframe that ensures a smooth transition. Detailed in-line responses to various parts of the proposal, along with clarifying questions, are provided below.
Overview / Background
Here's an update on the discussions about Symantec-issued certificates and the steps Chrome is proposing to move forward. Thank you to everybody who has contributed to the discussion so far.
On May 12, members of the Chrome team met with Symantec to discuss the set of concerns and our proposed remedy for them. These discussions were an expansion on a proposal previously shared with Symantec in April, and later shared on the mozilla.dev.security.policy list.
When the original Intent to Deprecate was posted, I proposed a plan that tried to best address issues we were aware of and provide a long-term path for comprehensive protections. We received a lot of great feedback from the Blink and wider PKI communities regarding the impact this plan would have and further issues to consider. In light of this feedback, we would like to propose a new plan that we believe ensures users are sufficiently secured while trying to minimize disruption to site operators, and providing an objective and reasonable path forward for those that have critical dependencies on certificates that chain to Symantec-operated roots.
We want to share an overview of this plan with the broader community, with more specific, detailed requirements at the end. The high-level overview of the plan is:
Symantec In-Line Response: While adhering to best practices for a modernized platform is self-evident, what process do Chrome and the community foresee as appropriate to establish this trust?
Symantec In-Line Response: This part of the proposal introduces a substantial additional authentication effort for SubCAs on top of an already challenging requirement to scale their processing capacity. Symantec has been logging all EV certificates to CT since Jan 1, 2015 and a large proportion of other certificates since prior to June 1, 2016. This distrust would affect over 425,000 certificates, of which ~130,000 have been logged to CT. Given that CT logging appears to be foundational, we would like to propose that ongoing trust be extended to any Symantec CT qualified certificate issued after Jan 1, 2015 as it currently is today in Chrome.
While the plan is not final, we believe it is converging on one that strikes a good balance of addressing security risk and mitigating interruption. We still welcome any feedback about it, as prior feedback has been valuable in helping shape this plan.
Transition to a New Symantec PKI
Chrome will require that by 2017-08-08 all new Symantec-chaining certificates be issued by independently operated third-parties (aka “Managed CAs”).
Chrome will implement a check, on-or-after 2017-08-08, to enforce this by ensuring that the certificate chain contain a whitelist of intermediates (independently operated sub-CAs or the Managed CAs).
Symantec In-Line Response: See date comments below.
If a Managed CA has fully revalidated the information, the validity period of new certificates can be up to the maximum allowed by Chrome for all CAs, which is currently specified as the maximum allowed by the Baseline Requirements and EV SSL Guidelines.
During a transition period, validation information can be reused, provided that the certificate is issued by the new infrastructure. However, the validity period of such certs must be no longer than 13 months.
If Symantec needs this flexibility, the following deadlines apply:
Symantec In-Line Response: Based on our initial research, we believe the timing laid out above is not achievable given the magnitude of the transition that would need to occur as we discussed at the beginning of this post and we propose that Google not conclude on final distrust dates for Symantec certificates at this time. We have conducted outreach to candidate partners (SubCAs) to understand the potential constraints, timelines and the integration work that might be needed. We have also formalized and issued a RFP with specific questions around timing, logistics and dependencies. We expect to have the required feedback to inform a project plan by the end of June, at which time we will come back to Google and the community regarding suggested dates that are both aggressive and achievable. In the meantime, we wanted to share some of some of the practical and constraining reasons that we believe the dates will need to be adjusted:
The use of existing or new validation information in a certificate should be signalled by using new OID in the Certificate Policies extension. See the Technical Details section for more information. If the managed CA is unable to validate the information by such milestones, then such certificates will not be able to be issued or trusted.
Chrome will continue to trust certificates issued after 2016-06-01, provided they are “CT Qualified” as defined in the Chrome CT Policy.
Enterprise Chrome users will be given a policy to allow certificates issued before 2016-06-01. This will give enterprise administrators the ability to control Chrome behavior for their organizations. This can be specified both at device-level as well as at user-level.
We’re proposing a phased distrust of all website certificates issued prior to 2016-06-01, which is the date in which Chrome both required and enforced Certificate Transparency. This provides a degree of assurance for site operators that certificates issued for the improper domain have a reasonable chance of being detected. With this, our goal is to attempt to minimize disruption to site operators, ensure reasonable notice of these changes, and avoid particularly sensitive holiday disruptions. These plans represent target dates, which may need to be adjusted based on interoperability or compatibility risk or additional information coming to light that may accelerate such distrust.
Symantec In-Line Response: As previously mentioned, Symantec has been logging EV certificates to CT since Jan 1, 2015; and a proportion of other certificates since before June 1, 2016. Given that CT logging appears to be foundational, we propose that ongoing trust be extended to any Symantec CT Qualified certificate issued after Jan 1, 2015. Doing so would reduce the incremental re-authentication effort from over 425K certificates to ~295K – a meaningful reduction in the re-authentication effort necessary under this part of the proposal.
In terms of specific feedback on certificate distrust dates and the associated distrust waterfall, we must consider the information that will be returned to us as part of our current RFP process before we revert to the community with suggested dates that would not cause undue disruption to our CA customers and browser users. In the meantime, we propose that Google not conclude on final distrust dates for Symantec certificates at this time.
Symantec In-Line Response: We would treat SubCAs as Delegated Third Parties and as such subject to audit under section 8 of the Baseline Requirements. However, given the possibility that multiple SubCAs may be required to accommodate the scope of our operations, it’s important to clarify that the actions of one SubCA should not automatically reflect on the operations of a separate SubCA. Can you further explain your rationale and intent on this point?
Symantec In-Line Response: In Symantec’s current authentication model, there is a two-step process, where validation of an order is done by one person and then that work is reviewed independently by another prior to issuance. To expedite the timing of our implementation of this proposal and to offset the ramp time needed for SubCAs to increase their authentication capacity, we suggest that Google’s proposal be modified to allow Symantec to conduct the first step of the validation, subject to 100% review of 100% of the orders by the SubCA, and issuance determination made by the subCAs.
Symantec In-Line Response: Where SubCAs use Delegated Third Parties in their existing CA operations, we propose that such SubCAs be permitted to continue to use such Delegated Third Parties with respect to performance of its responsibilities for the benefit of Symantec under this proposal. Restricting use of Delegated Third Parties by SubCAs under this proposal may limit the interest of SubCAs to partner with Symantec under this proposal and/or increase their cost to partner with Symantec under this proposal.
Symantec In-Line Response: We agree with the subsequent discussion on audit timing:
T0: Key Generation Ceremony
T+30-60: First server auth certificate issued
T+90-120: End of period (not less than 60 days after the prior T+timepoint)
T+180-210: Opinion published (not more than 90 days after end of period)
Symantec In-Line Response: Given that Symantec would partner with SubCAs that are established CAs, we do not believe these SubCAs should be burdened with audit requirements that exceed their requirements today. We believe it should not be necessary to force these SubCAs to provide audits with greater frequency than what they are currently required to do outside of the initial one outlined in the first audit bullet, which can be used to confirm that the transition was successful.
Transition to New Infrastructure
Symantec In-Line Response: Symantec is willing to provide such reports under non-disclosure agreements where they include detailed information of a sensitive nature (similar to sharing SOC2 reports with specific customers).
***** End of Google's Original Post and Symantec In-Line Response*****
We believe that we are on the path to reaching an agreed-upon plan that can be implemented in a reasonable timeframe and ensures minimal disruption for our customers. We will continue to pursue what we believe is the right course of action that allows for a smooth transition and reassures trust in Symantec certificates and our issuance practices. We welcome continued input from Google and the browser community as we work to reach a final agreement that serves the best interests of all stakeholders.