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-
>] On Behalf Of
> Steve Medin via dev-security-policy
> Sent: Tuesday, July 18, 2017 2:23 PM
> To:
> 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 mailing list

Reply via email to