Symantec Conclusions and Next Steps

The deadline for Symantec to submit comments passed yesterday; they
chose to issue a large PDF[0] of responses just before the deadline,
leaving no time for further discussion and clarification. That's their
right, of course, but it may leave some places where we have to make

I've updated the Issues list:
with the latest information. 3 issues have been marked as STRUCK due to
lack of evidence of anything actually being wrong - including,
importantly, the suggestion that they have unaudited unconstrained
intermediates (further audits have been published).

I would assess the situation now as follows:

Issue D: Test Certificate Misissuance
Issue L: Cross-Signing the US Federal Bridge
Issue P: UniCredit Sub CA Failing To Follow BRs
Issue T: CrossCert Misissuances
Issue V: GeoRoot Program Audit Issues
Issue W: RA Program Audit Issues

Issue Q: Symantec Audit Issues 2016
Issue J: SHA-1 Issuance After Deadline, Again

Issue B: Issuance of 1024-bit Certificate Expiring After Deadline
Issue E: Domain Validation Vulnerability
Issue H: SHA-1 Issuance After Deadline
Issue N: Premature Manual Signing Using SHA-1

Issue F: Symantec Audit Issues 2015

Issue R: Insecure Issuance API
Issue X: Incomplete RA Program Remediation
Issue Y: Unaudited Unconstrained Intermediates

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.


4/21/2017 10:16:56 AM 1322 articles. 2 followers. Post Follow

2 Replies

Similar Articles

[PageSpeed] 43

Content-Type: text/plain;
Content-Transfer-Encoding: quoted-printable

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
>] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Friday, April 21, 2017 6:17 AM
> To:
> 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=E2=80=99ve =
> considered the feedback posted on the Mozilla forums along with =
> on the Google forums and other community feedback. We=E2=80=99ve also =
> input from our customers who are the ones that would bear the impact =
> changes, whether as a result of our proposal or any other.
> We plan to send a proposal for Mozilla=E2=80=99s and the =
community=E2=80=99s 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.=20

On March 23, Google posted a blog outlining a proposal to change how =
Symantec=E2=80=99s 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=E2=80=99s 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.=20

Feedback from our Enterprise Customers=20

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=E2=80=99s 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=E2=80=99 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 redistributed.
- 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 communications.=20

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=E2=80=99ve 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.=20

To give a perspective of scale, Symantec secures more than 80% of the =
world=E2=80=99s ecommerce transactions through its certificate =
infrastructure. Additionally, Symantec is the world=E2=80=99s 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 communications.

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

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 =
A%20Blog.png (source: =
represents their findings of Symantec EV certificate compliance compared =
to the rest of the industry.=20

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:=20

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=E2=80=99s 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=E2=80=99s behalf. We want to provide assurance =
that all Symantec certificates are properly issued. With these issues in =

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

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 = post at the = 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 following:

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.=20

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 proposal. =20

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 =
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.=20

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.=20

Continuous Improvement of our CA Operations

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

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.=20

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.=20

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=E2=80=99s 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 =
=E2=80=93 e.g., =E2=80=9CFinancial Services,=E2=80=9D =
=E2=80=9CEducation,=E2=80=9D =E2=80=9CMalicious Sources/Malnets=E2=80=9D =
or =E2=80=9CSuspicious=E2=80=9D =E2=80=93 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 sites.=20

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=E2=80=99s 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 =

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 =

Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"


4/27/2017 12:48:15 AM
I don't know about others, but I am quite disappointed by Symantec's propos=
ed remediation plan. Intentional or not, these response seems to indicate t=
hey don't really understand the potential consequences of many of their pas=
t actions.  Essentially, they promise to:

1) Have a third party audit all of their EV certs
2) Have a third party audit all of their partner certs
3) Have quarterly audits
4) Will offer certs with 3 month validity periods
5) Engage better with CAB and browser programs to help the ecosystem

These steps, while no doubt appealing to Symantec and its customers, do not=
 address the significant relying party risks introduced by their past actio=
ns, including allowing various third parties carte blanche to issue certs c=
haining to publicly trusted roots without meaningful oversight (issues L, W=
, and Y). This is compounded by apparent institutional difficulties with pr=
operly identifying the scope of problems and resolving them (e.g. why did S=
HA-1 Issue H not lead to procedures so Issue J didn't happen; on Issue D, w=
hy did the first set of test cert mis-issues not catch the March 2016 ones?=
). Further doubts as to the trustworthiness of Symantec's PKI comes from th=
e significant lack of oversight (intentional or not) even in cases where th=
ey *knew* there were problems (e.g. Issues P,Q,T,V).=20

In light of this history (as well as related history for other CAs discusse=
d on this forum in the past), on what basis are relying parties supposed to=
 conclude that "more audits" and a "promise to do better" is a sufficient r=

It seems to me the existing Symantec PKI is a mess and any steps short of c=
omplete distrust of all existing roots leaves relying parties exposed to si=
gnificant risk.

No-one (apparently not even Symantec given demonstrated past inability to i=
dentify similar issues within their PKI) has a full view of all the past ac=
tions (e.g. cross-signs, creation of unconstrained CAs, etc.) under their e=
xisting roots; and the scope of issues here are more serious than other cas=
es that have led to full dis-trust under Mozilla's program.=20

The problem of course is compatibility (Symantec's own plan essentially say=
s "yes, many bad architectural decisions were made by us and our (mostly la=
rge enterprise) clients, so we are too big to fail and you can't do drastic=

But this does not absolve Symantec's existing PKI of their 6+ year history =
of poor decisions and management.

So what about the following: plan a scheduled phasing out of trust in exist=
ing Symantec certificates (timeline from Google's proposal seems reasonable=
), but with all certificates chaining to existing roots, and the old roots =
themselves, distrusted in the final milestone.=20

This may seem more extreme, but with one addition there are some attractive=
 features that actually reduce compatibility risks (especially to non-brows=
er facing systems), allows symantec to rearchitect their public PKI to foll=
ow practices that should help avoid complete distrusts in the future, and g=
ives stronger assurances to relying parties:

To deal with the compatibility consequences, during this timeframe, permit =
Symantec to generate and begin using new root CAs. These roots could/should=
 be unidirectionally cross-signed by one or more of their existing (but to =
be removed) roots, so that they can begin issuing replacement certificates =
~immediately for their customers from sub CAs under the new roots. The plan=
 would then be to strive to have these new roots incorporated in the trust =
store by the time of the final milestone above (and given Symantec's public=
 statements to support their customers, they would actually do this).

>From the perspective of the public web PKI, this "cleans the slate", and al=
lows the various root programs to clearly articulate requirements under whi=
ch these new roots operate (eg mandatory disclosure and auditing of all sub=
CAs and cross-signed roots (and their subCAs) *technically capable* (even i=
f administratively constrained or constrained by technical means not recogn=
ized by public web PKI browsers) of issuing browser trusted certificates, C=
T logging, validation methods, certificate validity limits, etc). Since the=
se new roots don't have legacy baggage, any violations of root program poli=
cy thus become clear cut, simplifying monitoring.

If done right, this approach might even help *reduce* compatibility issues.=
 Each server using existing Symantec certificates falls into one of three c=
1) services solely non-browser clients (eg fixed firmware devices, apps,...=
2) services solely browser clients
3) services both 1&2

#1 should be completely unaffected by the above plan (continue to use Syman=
tec's old PKI which is now essentially a large private PKI).

#2 has three sub-categories:
2a: solely browsers managed by enterprise policy: these can be made immune =
to the above (and continue to use Symantec's old PKI) if the to be publicly=
 distrusted roots can be added as private roots (or an enterprise setting t=
o achieve the same effect) on the clients. Or, they pay the one-time effort=
 of moving to certificates to the new Symantec roots. Of course the former =
comes at some cost to security of those users, but Crucially reduces compat=
ibility issues by giving enterprises flexibility in planning their internal=
 certificate changes (vs the original Google proposal where the not distrus=
ted but not trusting old certs logic makes this much harder).
2b: solely browsers not managed by enterprise policy. Here is compatibility=
 risk comparable to the original Google proposal, but without the potential=
 security risks from undisclosed baggage under old roots. This plan require=
s no more work on the admins part than any other change of certificate (eg =
in the original Google proposal) and the cross-sign of the new roots by the=
 old ensures non-updated clients retain access.
2c: some policy managed and some unmanaged. Appropriate admixture of 2a/2b.

#3: if browsers are all managed, this is equivalent to 2a. If some browsers=
 are unmanaged, here is the biggest risk, since it is possible there are no=
n-browser cert pins,etc, that are mutually exclusive with using certs from =
new roots to keep trust in new browsers. But this is no greater risk than i=
n the original Google proposal, and the number of systems in this category =
should be low (relative to the other categories), since usual architectures=
 would point fixed function devices at api-stable subdomains rather than mo=
re frequently changed browser-accessed ones. Further,there are pure server-=
side solutions that could address these cases if absolutely required (cf cl=
oudflare sha1 serving to legacy clients).

I can understand that some previous CAs in the mozilla program might compla=
in that the above is unfair (why does Symantec get to immediately propose n=
ew roots, while we did not), but this just reflects the reality=20

Even if you ignore all the above, I don't care which way you slice it, the =
actions of Symantec on these issues means they should not be trusted with E=
V for a long long time, as their policy seems to have been: what their cust=
omer wants, their customer gets.
4/27/2017 11:04:18 AM