> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec....@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Friday, April 21, 2017 6:17 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Symantec Conclusions and Next Steps
> Symantec have also written to Mozilla to say the following:
> "We have been working hard on a thorough and thoughtful proposal that
> responds to community questions and concerns regarding our compliance
> and issuance practices. In drafting this proposal, we’ve thoughtfully
> considered the feedback posted on the Mozilla forums along with comments
> on the Google forums and other community feedback. We’ve also solicited
> input from our customers who are the ones that would bear the impact of
> changes, whether as a result of our proposal or any other.
> We plan to send a proposal for Mozilla’s and the community’s consideration
> on Wednesday April 26th that addresses these important areas:
> * The Integrity of our EV Validation Process
> * Validity of Existing Certificates
> * Increased Transparency
> * Move to Shorter Validity Certificates
> * Continuous Improvement of our CA Operations"
> This date is in the middle of next week. We permitted WoSign to propose a
> remediation plan; I think it is reasonable to do the same for Symantec. So we
> will wait to hear what they have to say, and then discuss appropriate action 
> in
> the light of it.
> Gerv

Symantec CA Response to Google Proposal and Community Feedback

We take our role as a key player in the trust ecosystem of the Internet very 
seriously. We believe that secure and compliant issuance of SSL/TLS 
certificates is fundamental to the security of the Internet and that we have a 
responsibility to collaborate with our customers and the broader community to 
continuously improve industry standards, and specifically our practices, for 
certificate issuance. 

On March 23, Google posted a blog outlining a proposal to change how Symantec’s 
SSL/TLS certificates are recognized in Chrome. Their proposal stemmed from 
prior certificate mis-issuances that occurred in our Certificate Authority (CA) 
business, which we have taken extensive remediation measures to correct. We 
have carefully reviewed Google’s proposal and sought input from the broader 
browser and user community on this topic, which has informed our continuous 
improvement planning. This post outlines important measures that we propose to 
implement in our CA business. We believe our proposal addresses the concerns 
raised by Google about our CA business without imposing undue business 
disruption on our customers and Chrome users that we believe would result if 
Google implements its proposal. 

Feedback from our Enterprise Customers 

In addition to our review of public commentary on these issues, we have also 
sought input and feedback from Symantec customers on the compatibility and 
interoperability impact of the significant changes that could result from the 
implementation of Google’s proposal. These customers include many of the 
largest financial services, critical infrastructure, retail and healthcare 
organizations in the world, as well as many government agencies. This cohort is 
an important constituency that we believe has been under-represented to date in 
the public commentary that has been posted to the Google and Mozilla boards 
since large organizations rarely authorize employees to engage in such public 
discussions, particularly in an area related to security. We first solicited 
feedback to understand the disruption that a browser-initiated trust change, 
like the one proposed by Google, would cause organizations that opt to replace 
their existing SSL/TLS certificates in order to maintain interoperability with 
all browsers. We learned that these organizations’ publicly facing web 
applications, while extensive, only represent a fraction of their dependency on 
publicly trusted Symantec roots. Many large organizations have complex, and 
potentially undocumented and little-known dependencies on their certificate 
infrastructure. Examples of complex dependencies on Symantec public roots that 
our customers have shared or we have identified include:

- Embedded devices that are pinned to certificates issued by a Symantec public 
root to communicate to resources over the Internet or Intranet. Replacing these 
certificates would result in immediate failures and the need to recode and 
reimage the firmware for these devices.
- Mobile applications that have pinned certificates. Replacing server 
certificates would require these applications to be recoded, recompiled and 
- Critical infrastructure organizations that use certificates issued off of 
Symantec roots to validate internal and external resources. In many cases the 
applications being used are pinned to Symantec certificates.
- Some large organizations use certificates chained to Symantec public roots 
for nearly all internal applications and communications. Many of these 
organizations are under regulatory requirements to encrypt even internal 

Additionally, many of these organizations estimate that just the planning 
process to prepare to move to a new certificate authority could take many 
months and in some cases years because of unknown and undocumented 
dependencies. Moreover, few large enterprises that we’ve received feedback from 
have implemented the level of certificate lifecycle automation required to 
enable safe and cost-effective adoption of shorter validity certificates. We 
believe that it is important for the broader community to understand and give 
more weight to these compatibility and interoperability risks, particularly 
given the fact that many of these organizations are prohibited from commenting 
publicly on these topics. 

To give a perspective of scale, Symantec secures more than 80% of the world’s 
ecommerce transactions through its certificate infrastructure. Additionally, 
Symantec is the world’s largest provider of Organization Validation (OV) and 
Extended Validation (EV) certificates which are primarily used by large 
enterprises. Many of these certificates sit inside corporate and government 
networks and are an important part of the trust fabric of internal 

In short, our assessment based on customer feedback is that the 
interoperability and compatibility failures that could result from a 
large-scale certificate replacement or invalidation event would be significant 
and unpredictable.

Our Proposal to the Community

We understand the importance of providing transparency into our CA operations 
and responding to community questions and feedback to inspire trust. We propose 
to undertake the following actions in response to browser concerns and customer 
feedback as well as to increase trust and confidence in our processes and our 
commitment to the compliance frameworks set forth by the CA/B forum and browser 
root programs.

Our EV Process 

Symantec has some of the most comprehensive Extended Validation processes in 
the industry. We have, on occasion, been criticized for the time it takes us to 
validate EV certificates while some of our competitors boast rapid (15-20 
minute) validation times for EV. We believe that issuing an EV certificate 
represents the highest bar of certificate validation in the industry and that 
the process used to validate these certificates must be conducted with the 
appropriate care. The widespread adoption of Certificate Transparency for EV 
certificate issuance now makes it possible for independent third parties to 
compare the accuracy of these issued certificates. One such organization, 
Netcraft, has been evaluating EV issuance over time. Their graph at 
 (source: http://trends.netcraft.com/www.symantec.com) represents their 
findings of Symantec EV certificate compliance compared to the rest of the 

The Netcraft numbers demonstrate strong EV requirements compliance for Symantec 
relative to our peers. Our point-in-time and recent period-in-time audits have 
demonstrated that we are issuing EV certificates in accordance with industry 
requirements. We are confident in our EV issuance practices, which we have 
informally benchmarked against other CAs. We believe our EV validation 
processes are among the most thorough ones employed by any CA. Nevertheless, to 
reassure the browser community regarding our EV issuance practices we propose 
to undertake the following: 

1. We will commission a third party auditor to perform a backward-looking audit 
of all active EV certificates that have been issued by Symantec to give comfort 
around the validity and integrity of our EV certificates and our EV certificate 
issuance practices. This action is proposed as an alternative to Chrome’s 
suggestion to remove EV treatment of past or future issued EV certificates, 
which we believe is unjustified. We believe this additional audit of our EV 
certificates provides full transparency into our EV certificate practices and 
reaffirms confidence that our active Symantec EV certificates are trustworthy. 
Our intention is to complete this third party audit by August 31, 2017.
Registration Authority Authenticated and Issued Certificates

Historically, Symantec has issued SSL/TLS certificates either directly or 
through Registration Authority (RA) partners who have issued such certificates 
on Symantec’s behalf. We want to provide assurance that all Symantec 
certificates are properly issued. With these issues in mind:

2. We will commission a third party auditor to attest to the list of active 
certificates that had been issued by any prior SSL/TLS RA partner, including 
CrossCert, Certisign, Certsuperior and Certisur. The purpose of this action is 
to provide transparency regarding existing certificates validated by RA 
personnel. We believe this action also provides additional assurance regarding 
the efforts we have already undertaken to revalidate all active CrossCert 
certificates as well as review 100% of the certificates issued by the other 
former RA partners. Further, we will ask our external auditors to audit 100% of 
the work we have done to revalidate or review and, where necessary, remediate 
active certificates issued by all of these former SSL/TLS RA partners. Our 
intention is to complete this third party audit by August 31, 2017.

Increased Transparency 

We recognize that an accurate understanding of our past incidents is important 
to enable an objective evaluation of any proposal regarding this topic. We have 
responded to, and will continue to review and respond to the salient questions 
posed on the https://wiki.mozilla.org/CA:Symantec_Issues post at the 
mozilla.dev.security.policy forum to provide further transparency into our past 
compliance incidents.

Furthermore, we understand the importance of providing increased transparency 
into our CA operations. As part of our effort to do so, we will do the 

3. We will conduct a six month period-in-time WebTrust audit for the period 
from December 1, 2016 to May 31, 2017. We will thereafter move to a cadence of 
quarterly WebTrust audits (in lieu of annual period-in-time audits), beginning 
with the period from June 1, 2017 through August 31, 2017, until such time as 
we receive four consecutive quarterly WebTrust audits without qualification. 
The purpose of this action is to provide greater transparency regarding our 
operations and new certificates issued by Symantec going forward. 

4. We will publish a quarterly letter to update the community on the progress 
of our third party audits identified in this proposal and the progress of our 
continuous improvement program that incorporates the other actions in this 

5. We will work through the CA/B Forum to recommend new (or where applicable, 
updated) guidelines for appropriate customer exception requests to baseline 
requirements. While the CA/B forum has developed a process for exception 
requests, we believe it should consider further guidelines to assess the risk 
associated with these requests and determine conditions under which the CA/B 
forum might expeditiously approve exception requests.

6. We will endeavor to improve the timeliness of our responses to the browser 
community as well as the level of technical detail we provide in them, 
balancing the interest of the community to receive prompt responses to their 
questions with the time required to perform the investigative steps necessary 
to provide thorough responses to such questions. 
Move to Shorter Validity Certificates

We support the added option of shorter validity certificates, as do several 
browsers and others in the ecosystem. Shorter validity certificates can reduce 
exposure in the case of an undetected key compromise, enable faster adoption of 
improvements to industry standards (e.g. move to ECDSA or SHA3), and drive more 
rapid remediation of potential TLS-related vulnerabilities (like Heartbleed) 
that can require certificate replacement. 

7. By August 31, 2017, we will begin to broadly offer SSL/TLS certificates with 
three month validity periods to give our customers greater choice and 
flexibility in the validity periods of the certificates they purchase and 
deploy from Symantec. From the customer feedback we have received to date, we 
believe this offering may be most attractive to customers that have already 
enabled automation, such as customers and partners integrated with our APIs and 
e-commerce customers with less complex environments. In addition, we will 
continue our investments in automation to enable organizations with even the 
most complex infrastructure to practically and cost-effectively adopt shorter 
validity certificates. Our near term investments will focus on modernizing our 
certificate issuance systems and workflows to enable faster issuance, and 
developing tools that enable customers to rapidly and securely implement their 
certificates and configure their systems.

8. We will perform a domain revalidation of all issued certificates that have a 
validity period longer than nine months at the nine-month mark (at no 
additional cost to our customers). This approach is intended to balance the 
customer impact of replacing certificates, for those not ready to move to 
shorter validity certificates, with visibility that ensures that certificates 
are being used appropriately. We commit to working with the browser community 
regarding appropriate transparency mechanisms (e.g., an extension of CT 
logging, OCSP extension, signed DNS text record, or signed revalidation list) 
that provide an attestation to this revalidation and ensure accountability of 
our implementation of this action. An initial certificate validation is one 
level of authentication. Certificate domain revalidation post-deployment 
further extends the trustworthiness of the initial certificate, which is a 
positive extension of the CA trust model. 

Continuous Improvement of our CA Operations

We seek to continuously improve our systems and processes around certificate 
issuance. With this in mind: 

9. We are further increasing our investment in the Security and Risk function 
of our CA operations, with a focus on our security and compliance controls and 
risk assessments. As a first step, we are commissioning a third party to 
conduct a process and systems risk assessment of our CA operations. The scope 
of this assessment will include an inventory of our systems and use cases, and 
a review of the security controls we have in place with respect to all of our 
PKI services, including SSL/TLS certificates. This third party assessment will 
also incorporate red teaming and penetration testing of our processes and 
systems beyond what we do already. The purpose of this third party risk 
assessment, which we expect to complete by October 31, 2017, is to provide 
increased confidence in the risk management posture of our CA operations beyond 
WebTrust audit reports. 

10. We will update our Root Program to more directly compartmentalize different 
certificate use cases. This update will involve creating dedicated roots and/or 
sub-CAs, for example, to segment customers who today use our publicly trusted 
hierarchies for closed ecosystems like set-top boxes, for customers who have 
mixed ecosystems like point-of-sale systems and ATMs which connect to the same 
servers as browser-based applications, for customers who choose to use longer 
validity certificates, or for customers who serve disproportionately large web 
traffic. As certificates expire, we will issue new certificates that chain to 
the use case-appropriate roots. 

11. Industry analysts estimate that 50% or more of all network attacks 
targeting enterprises this year will take advantage of SSL/TLS encryption to 
bypass security controls. We believe that CAs have a necessary and critical 
role to play in validating whether an encrypted website is malicious. 
Symantec’s technology infrastructure includes a Global Intelligence Network 
that analyzes websites, domains, servers and web services at scale and runs 
both real-time and background checks on such external hosts, including over a 
billion previously unseen and uncategorized websites a day. Our Global 
Intelligence Network includes technology that categorizes websites into over 80 
categories – e.g., “Financial Services,” “Education,” “Malicious 
Sources/Malnets” or “Suspicious” – based on linguistic analysis, inter-site 
relationships, host-attribute analysis and reputation and history. Modules 
within our Global Intelligence Network analyze site content such as images, 
video and embedded links and can run in-depth content analysis in over 50 
languages to help categorize sites and identify potential risk. We will begin 
to use our Global Intelligence Network to identify encrypted websites that have 
an increased threat risk based on our rating categorization and take 
appropriate action to mitigate risk for our certificates associated with such 

Even though our past mis-issuance events have not, to our knowledge, resulted 
in customer harm, we consider compliance with industry standards a critical 
responsibility of our CA business. We believe our multi-faceted proposal 
addresses the concerns regarding the trustworthiness of Symantec’s past and 
future SSL/TLS certificate issuances. We also believe our proposal 
appropriately balances these concerns with the significant compatibility and 
interoperability risks, as well as customer burden, which would result from any 
proposal that limits the trust of existing Symantec SSL/TLS certificates, 
imposes shorter validity periods on newly issued Symantec certificates and/or 
removes EV recognition for our certificates in browsers. 

We welcome constructive feedback to our proposal, which we understand may take 
time for the Internet community to fully consider. In the meantime, we will 
continue to solicit feedback from our customers and partners, which are 
important stakeholders that will be impacted by changes to our operations, 
whether as a result of our proposal or any other.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

dev-security-policy mailing list

Reply via email to