Hi Steve,

Thank you for this update on Symantec's progress. I have a few follow-up
questions:

1) Did any of the RFP respondents indicate that they could provide the
Managed
   CA solution in the timeframe originally proposed by Google? (August 8th)
   Alternatively, is December 1st, 2017 the earliest date that any RFP
   respondents can achieve?

2) What selection criteria is Symantec using in considering RFP responses?

3) On June 1st, Symantec wrote that "we are in the midst of a rigorous RFP
   process"
   (
https://www.symantec.com/connect/blogs/symantec-s-response-google-s-subca-proposal
).
   In this mail you wrote that "Last month, we released a Request for
Proposal
   (RFP)". How do you reconcile those?

4) There are currently rumors that Symantec is considering a sale of its CA
   business
   (https://www.reuters.com/article/us-symantec-divestiture-idUSKBN19W2WI).
Do
   these timelines reflect that possibility, or should we expect requests to
   amend this timeline in the event of a change of ownership?

Thank you,
Alex

On Tue, Jul 18, 2017 at 3:37 PM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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
>
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to