-----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
