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

I've updated the Issues list:
https://wiki.mozilla.org/CA:Symantec_Issues
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:

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

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

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

Informational:
Issue F: Symantec Audit Issues 2015

Struck:
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.

Gerv

[0] https://bug1334377.bmoattachments.org/attachment.cgi?id=8860216
0
Gervase
4/21/2017 10:16:56 AM
mozilla.dev.security.policy 1100 articles. 1 followers. Post Follow

2 Replies
72 Views

Similar Articles

[PageSpeed] 4

------=_NextPart_000_078D_01D2BECE.6C368B20
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=3Dsymantec.com@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Friday, April 21, 2017 6:17 AM
> To: mozilla-dev-security-policy@lists.mozilla.org
> Subject: Symantec Conclusions and Next Steps
>=20
[snip]
>=20
> Symantec have also written to Mozilla to say the following:
>=20
> "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 =
thoughtfully
> considered the feedback posted on the Mozilla forums along with =
comments
> on the Google forums and other community feedback. We=E2=80=99ve 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.
>=20
> 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:
>=20
> * The Integrity of our EV Validation Process
> * Validity of Existing Certificates
> * Increased Transparency
> * Move to Shorter Validity Certificates
> * Continuous Improvement of our CA Operations"
>=20
> 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.
>=20
> Gerv
>=20

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 =
https://www.symantec.com/connect/sites/default/files/users/user-2785391/C=
A%20Blog.png (source: http://trends.netcraft.com/www.symantec.com) =
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 =
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=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 =
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 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 =
questions.=20
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 =
browsers.=20

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.


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

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEYYw
ggQZMIIDAQIQYXDLSYxfmEUp57Cm2VBbejANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBv
bmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRp
b24gQXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkG
A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3Jp
emVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl
cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCvCg3C1SzbZ7kt5ZQn3aW+4LBNj7NhVjzWfMP0zT6Gy6KI4uHYpGnFteK/waZHUF5GOYvVlrq1
bxS/EM4nE54FR5sxehPYH9nTAjeLrSxH8I6BBqcNMAzr9zwPIB3cckbupQLIW8PJVmlMxRjBkXsL
1RMAm7zvw0g+RmAghSrVkLbNi6DMMt23/UBVslAcVq7MjXdNxyBNpzF272iSipAeCIFWsq1po1LQ
yxzEIz0fmf5M6BZjjsYIjvYx9tL65XbdtRySo0nNzQHNaM2pabqj6x0NnKQgpsGgxdFGTBdt0qxm
P5aM4ITUNv8iWcX5EWCoXwR98hr2JUJhD8RKuD6JAgMBAAEwDQYJKoZIhvcNAQEFBQADggEBADQm
FTzAjU1DSR296SGS12act97FuNDkXV92IsAm+YQ6OvmMtfvsYPHozgSwyN2nA48w85jfpOakMd/T
HAtG3HIgP67uBTykMz8LOaxweHNLmSvfMMJUsKg7VaH+FijNQr10boDbJ0SnzkRd1BuQmA0eQpSx
ACwE0HSjAgUiY2PNg7X7wW1ia2l1/V1wQbn1v3zfvsEycyIhi1iBexWRerrjZEiwf/s2JdqV0PEk
FBfdGIBrRiM5VPWOYgkEHZSQppvmJeJCRaq4kK2+CI+pC0IYlM9yOeGxQ+Aoz7fnWmwTa0mz/+MY
fImLM12sM9en+do6VclYEPmq71q2z0tL3yowggZMMIIFNKADAgECAhAcNy3LuXA+a7c+8/rRC0IG
MA0GCSqGSIb3DQEBCwUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x
HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT
aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs
YXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xNTAx
MDYwMDAwMDBaFw0yNTAxMDUyMzU5NTlaMIGwMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50
ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsT
LENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMSowKAYDVQQDEyFT
eW1hbnRlYyBDbGFzcyAyIEVtcGxveWVlIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQC21/RXe57fcFE+yEhkaEDBiW4/BJJK7Rx0JyDaOM9Skzy50VrHFy0+aE5haQuybmh5
9AJ2CvjSbrYbfntLxrVP2r34SQ4Cz+ytamfrzgR5vYTM85ojBNbPQj9JzpYn6ySuYdk0uWZ6vIOJ
HxiUwGrAec5n4zVQiaJsde44X/H7ma7zF0gbFg8ZejRqIWZaFIMRQMKwntDbg87fBPIyQoMOZXsL
Ko5ZZXgbyWwsTl4XLjL4yuv4pTQtVo5GiJU1l8mq2hkADD5tp7GRA+PmgTUTF/OeQJrZOcwKCoda
HiIje9mGj1ZoiCDnhiqmNAd0WE2O3JsYFOEQOcYCgNy3jCD9AgMBAAGjggJEMIICQDASBgNVHRMB
Af8ECDAGAQH/AgEAMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0
cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRo
LmNvbS9ycGEwDgYDVR0PAQH/BAQDAgEGMDcGCCsGAQUFBwEBBCswKTAnBggrBgEFBQcwAYYbaHR0
cDovL3BraS1vY3NwLnN5bWF1dGguY29tMDcGA1UdHwQwMC4wLKAqoCiGJmh0dHA6Ly9jcmwud3Mu
c3ltYW50ZWMuY29tL3BjYTItZzMuY3JsMCgGA1UdEQQhMB+kHTAbMRkwFwYDVQQDExBTeW1hbnRl
Y1BLSS0yLTIzMB0GA1UdDgQWBBSkM6+ww0aHq+V4SbK04kaf6gn8FTCB8AYDVR0jBIHoMIHloYHQ
pIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0g
Rm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGlj
IFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IQYXDLSYxfmEUp57Cm2VBbejAN
BgkqhkiG9w0BAQsFAAOCAQEAobYafeqzznZLxBH6OMpOEPGrh3+S6lCVJcA3aAL7gq2AyzPUzEMw
sEVn+yKYhjzAFZ3XRY9qIYl922HdLZGqso3wyQ7WUCvWIDeRg9EUztoB0tDxzjsiQUgyeRtLpuDS
6H4ZAYfUahBN5gRevERnuE3u2eUk/qb4KhswvL/9sQxGXApV4XIfIDVO5rhZdfGHV/YFleeAXE49
JaPRPff9h1QjweUAMxYR6oB4w5xE6cOUtyZaSkxDF8qmlnf+flaPiA/o3edR0vgUtbtg4Lr/hb4C
DU1a6yDtcphIeS91zOIEKwoA+8moz0X/wSI8hf8cy/zjVKMXfHtYEfxNTffKMjCCBxUwggX9oAMC
AQICEDztlWuklUUR25LYiQfCRmEwDQYJKoZIhvcNAQELBQAwgbAxCzAJBgNVBAYTAlVTMR0wGwYD
VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y
azE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Ex
KjAoBgNVBAMTIVN5bWFudGVjIENsYXNzIDIgRW1wbG95ZWUgQ0EgLSBHMzAeFw0xNjA3MjAwMDAw
MDBaFw0xNzA3MjAyMzU5NTlaMFgxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMSAwHgYD
VQQLDBdTeW1hbnRlYyBFbXBsb3llZSBFbWFpbDEVMBMGA1UEAwwMU3RldmVuIE1lZGluMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvq01EJSDIsFS5i9XiwbGjdpqIA4wQ7syWfq4Ma68
tG7Rnpbowe06isw9AMe4jg+vfiD+YQ1ZTvzNEB0qc7XDtS9CGdWvbDZh2oWB/dk2K6nsxAqT9mlV
vs+VrSDXzpKCua6vDLghmoaTnb3F4IXqMcsUEuu9JM42jJQkyHjy61FNtw/wH2JtdcWKtFQLPYa3
eNkYwciUGtAUpR78gYMjEGXNbeuuGGoWhY1Vo6kwFdhRBmDaowrJoyHuMFnsZ/qeg94GraI2yqDW
Y3yTMWoD/RMik9pU2XG5KawZClRi9S1z5s8TILqLCqj4k/1On3+dnD0xP+toKOFLz3dCs64G3wID
AQABo4IDgDCCA3wwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwFgYDVR0lAQH/BAwwCgYI
KwYBBQUHAwQwHQYDVR0OBBYEFFaFSmgtcRDwfRFiqt3Vq8LJCLn5MCMGA1UdEQQcMBqBGFN0ZXZl
X01lZGluQHN5bWFudGVjLmNvbTAfBgNVHSMEGDAWgBSkM6+ww0aHq+V4SbK04kaf6gn8FTCCAWQG
CCsGAQUFBwEBBIIBVjCCAVIwJwYIKwYBBQUHMAGGG2h0dHA6Ly9wa2ktb2NzcC5zeW1hdXRoLmNv
bTCCASUGCCsGAQUFBzAChoIBF2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24uY29tL0NOJTIwJTNE
JTIwU3ltYW50ZWMlMjBDbGFzcyUyMDIlMjBFbXBsb3llZSUyMENBJTIwLSUyMEczJTJDJTIwT1Ul
MjAlM0QlMjBDbGFzcyUyMDIlMjBNYW5hZ2VkJTIwUEtJJTIwSW5kaXZpZHVhbCUyMFN1YnNjcmli
ZXIlMjBDQSUyQyUyME9VJTIwJTNEJTIwU3ltYW50ZWMlMjBUcnVzdCUyME5ldHdvcmslMkMlMjBP
JTIwJTNEJTIwU3ltYW50ZWMlMjBDb3Jwb3JhdGlvbiUyQyUyMEMlMjAlM0QlMjBVUz9jQUNlcnRp
ZmljYXRlO2JpbmFyeTBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vcGtpLWNybC5zeW1hdXRoLmNv
bS9jYV8yYzc5ZDVmMGM0NTZlMGUzZTJmYjNlMjM2OTAzZGExNS9MYXRlc3RDUkwuY3JsMGwGA1Ud
IARlMGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNv
bS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwQgYJKoZIhvcN
AQkPBDUwMzAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQB
KjArBgpghkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICAQGdpPp0FgUxNjc0ODA5BgpghkgBhvhF
ARAFBCswKQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3
DQEBCwUAA4IBAQAkFsvRsGAuybrzzBuilyhaw5EDCzYTHBL/dOMyrPgokGbHe0cQz7dEwbfkA7Q3
RI7J1JSOFXGSrbeHlx5vl9MkIIGU+76C64wf6sGmWiI9WIH8dDN0/MD1gyFVf6Hn136R9A11haNv
FQUZse4UpTyBxMxpTyOqhMPJMDZpCDNKdEyUFkavYVWF0a8mGfH11S7aVPRGid+vyuHlZCTu9gbt
LVFS2dG7w80ipCNRpFm9k2mKWw0yWtnfkNLJmGH+Pz2bDd/QZzw72t0PBYsjawMvNIaLblWGaS96
a0Uopc6gaBn9iejPNnXrTocaF+g2707Y4ge9H/4jJUT0+ouWnlVtMYIEqDCCBKQCAQEwgcUwgbAx
CzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3lt
YW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlk
dWFsIFN1YnNjcmliZXIgQ0ExKjAoBgNVBAMTIVN5bWFudGVjIENsYXNzIDIgRW1wbG95ZWUgQ0Eg
LSBHMwIQPO2Va6SVRRHbktiJB8JGYTANBglghkgBZQMEAgEFAKCCArMwGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNDI3MDA0ODEzWjAvBgkqhkiG9w0BCQQxIgQg
pTcGLOCWp9JZh1cV4wovE8l4i76+hYklPrBesruJouwwgZMGCSqGSIb3DQEJDzGBhTCBgjALBglg
hkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0D
AgICAIAwDQYIKoZIhvcNAwICAUAwCwYJYIZIAWUDBAIBMAsGCWCGSAFlAwQCAzALBglghkgBZQME
AgIwBwYFKw4DAhowgdYGCSsGAQQBgjcQBDGByDCBxTCBsDELMAkGA1UEBhMCVVMxHTAbBgNVBAoT
FFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMTUw
MwYDVQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEqMCgG
A1UEAxMhU3ltYW50ZWMgQ2xhc3MgMiBFbXBsb3llZSBDQSAtIEczAhA87ZVrpJVFEduS2IkHwkZh
MIHYBgsqhkiG9w0BCRACCzGByKCBxTCBsDELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj
IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMTUwMwYDVQQLEyxD
bGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEqMCgGA1UEAxMhU3lt
YW50ZWMgQ2xhc3MgMiBFbXBsb3llZSBDQSAtIEczAhA87ZVrpJVFEduS2IkHwkZhMA0GCSqGSIb3
DQEBAQUABIIBAAITwvJLHs+LI2ZktmgrHIFzXBXI9lxZDd+2y7S3Psi+u4qxniEm8wOnQe34t3BW
X8OipwJJ27vrMCxGPCtuo0DZWyrybG5b+JaG6V2jsWYbZQFtOUSwd5cbOiT3lExYWOnrZSxt8uVS
JeTdfh3SwXG7FvPPQSXAS8ejEr/dLR77F/TVNSlz/nPRWN5eGtuzik3nduI9y+BMK9G54Ym3BuWQ
1MH1UYMXVIsehm4t0dcH7K4PmXbsmZSO2s1Z1qmik2eOEaygAGbyKoCpeNAsNRjHfp1mgisaKyl4
yXj5exv19PxCt1eIr3MGZIh6Am3ZQJ/hoAnfwUpHw4/+zeEyrawAAAAAAAA=

------=_NextPart_000_078D_01D2BECE.6C368B20--
0
Steve
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=
esponse?

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=
 things").

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=
ategories:
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.
0
wizard
4/27/2017 11:04:18 AM
Reply: