Correction: Summary item #3 should read: 3. May 1, 2018 a. Single date of distrust of certificates issued prior to 6/1/2016. (changed from August 31,2017 for certificates issued prior to 6/1/2015 and from January 18, 2018 for certificates issued prior to 6/1/2016).
> -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > bounces+steve_medin=symantec....@lists.mozilla.org] On Behalf Of > Steve Medin via dev-security-policy > Sent: Tuesday, July 18, 2017 2:23 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: [EXT] Symantec Update on SubCA Proposal > > *Progress Update on SubCA RFP, Partner Selection, and Execution* > > > > Since June 1, Symantec has worked in earnest to operationalize the SubCA > proposal outlined by Google and Mozilla and discussed in community > forums. The core of this proposal is to transfer the authentication and > issuance of certificates to a set of new SubCAs that are operated by > "Managed CAs", with the eventual end state being a move from the existing > Symantec PKI to a modernized platform. We are providing this update to > share our initial findings of our efforts to implement the SubCA proposal, > and as previously posted, propose aggressive but achievable dates for > certain aspects of the SubCA proposal. > > > > Last month, we released a Request for Proposal (RFP) that covered all > aspects of the SubCA proposal, including key management, technical > integration, staffing, training, compliance, support, and the end-to-end > coordination of operations. This RFP was sent to the CAs that we felt best > met the browser requirements and had the potential to successfully fulfill > the scope and volume of our CA authentication and issuance activities. > > > > After receiving RFP responses, we met with the prospective Managed CAs > to discuss and refine their proposed approach, clarify intent and answer > questions impacting their proposals, which addressed their approach to > and schedule for integration, staffing, compliance, support, and other > operational aspects. Over the last two weeks, we have continued to receive > detailed responses from RFP respondents and hold meetings with the > prospective Managed CAs to review their proposals in order to select the > final Managed CA partner(s) that will be able to best execute on the plan > proposed by Google and Mozilla. We appreciate the CAs who have replied > and recognize that drafting the proposals required a tremendous amount > of time and effort as part of this accelerated process. > > > > We continue to work through implementation details with our prospective > Managed CA partners, to understand the depth of analysis that has gone > into their development schedules and staffing plans, and to assess the > feasibility of those plans. We expect to complete the selection process > within the next 2 weeks. After selecting the final Managed CA partner(s), we > will work aggressively towards the execution of an agreement and > integration plan. > > > > As we finalize the selection process, our development team is actively > working towards the transition. Currently, we are shifting from design to > implementation of a common set of APIs across platforms to simplify the > integration with one or more Managed CAs. > > > > Based on the RFP responses, internal planning, and discussions with RFP > respondents to date, we are still concerned with the implementation > timing. Based on both our own internal scoping and the RFP responses, we > see a practical, aggressive transition being achievable between early- > December and late-February, depending on the specific Managed CA(s) and > the unknowns that come with an effort of this magnitude. This timeframe > is based on the Managed CAs' RFP responses regarding how long it will take > to integrate our existing customer portals (front-ends) with the Managed > CA validation and issuance systems. The transition timeline also > incorporates the effort required for the Managed CAs to build out support > for scalable domain validation (both automated and manual), CAA record > checking, CT logging, and certificate management functions. The primary > factors we heard from potential Managed CA partners are the need to scale > their operations to the certificate volumes currently sup ported by > Symantec, the need for integration, and the time required to prepare and > process key ceremonies on both ends. Some of the prospective Managed > CAs have proposed supporting only a portion of our volume (some by > customer segment, others by geographic focus), so we are also evaluating > options that involve working with multiple Managed CAs. > > > > *Timing Proposal Based on Key Activities* > > > > Based on the key activities and customer dependencies associated with the > transition (additional details provided at the end of this post), we believe > that the following adjustments to the current SubCA proposal timelines are > appropriate and necessary. These adjustments will allow us to work toward > deadlines that are as close as possible to the original dates and take into > account the full scope of the required implementation efforts while > prioritizing moving to full authentication by the Managed CAs for new > certificates. > > > > New Certificate Issuance: We believe the dates for transition of validation > and issuance to the Managed CA that are both aggressive and achievable > are as follows: > > - Implement the Managed CA by December 1, 2017 (changed from August > 8, 2017); > > - Managed CA performs domain validation for all new certificates by > December 1, 2017 (changed from November 1, 2017); and > > - Managed CA performs full validation for all certificates by February 1, > 2018. Prior to this date, reuse of Symantec authenticated organization > information would be allowable for certificates of <13 months in validity. > > > > Replacement of Unexpired Certificates Issued Before June 1, 2016: There > are two major milestones that must be achieved after implementation of > the Managed CA in order to replace unexpired certificates issued before > June 1, 2016 that do not naturally expire before the distrust date(s) in the > SubCA proposal. Those include the full revalidation of certificate > information and then the customer replacement of those certificates. This > activity would need to start during the December holiday season when > many organizations impose infrastructure blackout periods. As such, we > believe that the only achievable timing for this transition is after the > holiday > season. We understand that browsers may want to technically enforce this > transition and that multiple milestones may be undesirable from a coding > perspective. In order to accommodate a simplified and cost efficient > transition schedule (especially for organizations that currently have > certificates with notBefore dates of both June 1, > 2015 and June 1, 2016) and to allow impacted organizations the time, as > they will likely need to replace, test and operationalize these replacement > certificates in their infrastructure, we recommend consolidating Chrome's > distrust dates to a single date of May 1, 2018. This would mean that > Chrome's distrust of Symantec certificates issued before June 1, 2015 > would change from August 31, 2017 to May 1, 2018, and that Chrome's > distrust of Symantec certificates issued before June 1, 2016 would change > from January 18, 2018 to May 1, 2018. > > > > To add additional context, targeting May 1, 2018 would give organizations > a 9-month planning and execution window to replace certificates that > would be distrusted before their expiration date (assuming that the > community comes to consensus to convert the SubCA proposal into an > agreed upon plan by August 1, 2017). Given the hundreds of thousands of > certificates that would be impacted, we think that May 1, 2018 is the > earliest acceptable distrust date that does not introduce significant > operational risk in the replacement of these certificates in enterprises' > infrastructure. This 9-month window is significantly more aggressive than > other extraordinary events that have involved early certificate replacement, > such as the years of transition to 2048 bit and SHA-256 certificates. While > we believe our proposed 9-month window is achievable with early > customer outreach and careful planning, we urge the community to > consider moving this distrust date out even further to February 1, 20 > 19 in order to minimize the risk of end user disruption by ensuring that > website operators have a reasonable timeframe to plan and deploy > replacement certificates. This recommendation is echoed by our > prospective Managed CA partners. > > > > *Additional Details on Key Activities that Inform our Timing Proposal* > > > > In this section, we provide more detailed information that forms the basis > of our proposed timing modifications to the SubCA proposal. Based on our > understanding of the SubCA proposal, the following activities require the > most time to implement: > > > > Development and Integration: Symantec has developed the architecture for > and is working towards decoupling the retail, mid-market, enterprise, and > partner facing systems from the internal authentication and signing > systems backing our certificate offerings. We have developed and published > an API to the prospective Managed CAs. We have also started the > engineering work to integrate this new API into our systems. Technical > integration with the Managed CA(s) involves establishing the connection > between Symantec and the Managed CA(s) for all certificate lifecycle > functions for retail, partner, and Enterprise RA models, supporting > enrollment, all methods of domain verification, organization and extended > validation vetting, re-authentication, replacement, renewal, cancelation, > modification, revocation, CAA checking, CT logging, and CRL and OCSP > response provisioning. Technical integration is focused on the engineering > resource and implementation plans of the Managed CA(s), includin > g cross-team engagement, gap filling (to address any material existing > implementation differences), development, end-to-end testing, and > production deployment. This activity is projected to be the most time > consuming element of our transition execution - development and > integration will take an estimated 16 weeks to go live with new SubCAs > within the Managed CA's infrastructure. > > > > Key Management: Key management under the Managed CA model includes > the creation and cross signing of new roots by Symantec, integration with > the Managed CAs for both primary and disaster recovery sites, the > coordination of signing ceremonies by both parties, and scheduling audits > for these activities. Key requirements in our planning are separating HSMs > that would be used for these managed CAs both for management and > scaling purposes, and not relying on the existing HSMs at our Managed CA > partner(s). These requirements will enable an eventual seamless transition > back to Symantec, without requiring subsequent SubCA changes by server > operators, and are also a practical infrastructure necessity of several of the > RFP respondents. HSM procurement typically takes 4-5 weeks from the > point at which a purchase order is submitted. This includes the time for the > HSM vendor to make the hardware available and to ship it to the key > ceremony location. Once received, HSM initialization and k > ey ceremony activities take on average 2 weeks including coordination with > the auditors for the key ceremony of root CAs. Following this, the HSM > needs to be configured and deployed in both active and disaster recovery > data centers, including travel/secure transport, which will be an additional > 1-2 week effort. In total, we expect the key migration to potentially take up > to 12 weeks. These activities would be done in parallel with our other > preparations for transitioning to the Managed CA(s). > > > > Authentication Staffing and Re-authentication Efforts: The authentication > activities for the volume of certificates that Symantec issues annually > requires hundreds of people to conduct validation, review the validation > work and authorize certificate issuance, supervise, conduct training, and > audit this activity. These people operate out of multiple locations to provide > 24/7 support to customers globally in local languages. Prospective > Managed CAs we have engaged with confirmed that they will need to > increase their staffing by comparable levels to handle our certificate > volume. We researched the staffing options under local laws to enable > Managed CAs to potentially retain our staff to handle the authentication > volume required both for ongoing requests and the additional re- > authentication effort required globally under the SubCA proposal. In any > such arrangement, staff would be under the management and control of > the Managed CA. We have proposed to our prospective Managed CA pa > rtners that they consider this redeployment of current Symantec staff to > simplify the staff ramp, decrease training times (i.e., Symantec staff would > operate under the Managed CA subject to their validation requirements and > processes), and de-risk and accelerate the move to the Managed CA model. > > > > We've also received feedback from some of our prospective Managed CA > partners that they would like Symantec validation staff to continue to > perform verification of identity under the baseline requirements. The > Managed CA would complete all domain validation and they would make > the final decision on certificate issuance. In this scenario, Symantec would > continue to undertake a baseline requirement audit and WebTrust audit for > as long as it operates that particular RA function. Permitting Symantec to > perform just the organizational validation (not the domain validation) > would give customers an uninterrupted experience while still meeting the > stated objectives. We look forward to community feedback on this > proposed change to the SubCA proposal. > > > > Customer Support and Operations: The scope of our planning with the > prospective Managed CAs also covers support and end-to-end operations, > addressing practical considerations such as call and chat routing across > organizations, issue/escalation management, coordinating ongoing system > enhancements, and service level agreements (SLAs) for dozens of aspects > related to supporting the authentication and issuance activities at our scale. > > > > The factors above all depend on the integration efforts between the > Managed CA(s) and Symantec. Customers and partners need to be > considered in this effort as well. > > > > Customer and Partner Dependencies: A related dependency with customers > and partners that could delay transition is the time required after the key > ceremony for entities to migrate to the new hierarchies. For example, some > customers and/or partners have hard-coded particular SubCAs in their > environments, have built applications that build trust chains in unique > ways, and have other technical implementations that may be incompatible > with and may delay individual organization's transitions to the new SubCA > model. In addition, although we believe the Managed CA(s) and Symantec > could be ready in December 2017, this time frame falls squarely within > most organizations' blackout periods. To accommodate the need for > customer transitions as well as any required reissuances of existing > certificates by the Managed CA, we request that any distrust dates be > delayed until May 1, 2018. During that time, we will work with customers > and partners to update their certificates and will continue > to improve and test the Managed CA implementation. Additionally, while > Symantec and its Managed CA partner(s) will be ready to issue properly > validated certificates in December, the actual deployment of these > certificates by customers who are replacing unexpired certificates that were > issued before June 1, 2016 will take time, as described earlier. We would > also like to develop a clear process to evaluate exception requests that > includes consultations with the browsers to handle corner cases of system > incompatibility for situations with complex interdependencies that pose > material ecosystem risks. > > > > *Summary* > > > > Implementing this proposal is a major effort for Symantec as well as the > prospective Managed CAs, but it is an effort that we believe will minimize > customer, browser user, and ecosystem disruption. > > > > The implementation and distrust dates we have recommended here are > based on our understanding of the constraints of the consensus proposal > and at our potential Managed CA partners: > > > > 1. December 1, 2017 > > a. Initial implementation date (changed from August 8, 2017) of > operational Managed CA. > > b. Domain validation for all new certificates is performed by Managed > CA(s) (changed from November 1, 2017). > > > > 2. February 1, 2018 > > a. Full validation for all certificates is performed by Managed CA(s). > Prior > to this date, reuse of Symantec authenticated organization information > would be allowable for certificates of <13 months in validity. > > > > 3. May 1, 2018 > > a. Single date of distrust of certificates issued prior to 6/1/2016. > (changed > from August 31,2017 for certificates issued prior to 6/1/2015 and from > January 18, 2018 for certificates issued prior to 6/1/2018) > > > > We expect to conclude our final selection of a Managed CA partner(s) within > the next 2 weeks. During this time, we welcome any final clarifications from > Google, Mozilla and the rest of the community regarding the key activities > and other assumptions we have outlined in this post to inform the final > dates that we can incorporate into the contracting and implementation > phase of this Managed CA plan. > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
