Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Symantec Conclusions and Next Steps

1,696 views
Skip to first unread message

Gervase Markham

unread,
Apr 21, 2017, 6:17:14 AM4/21/17
to mozilla-dev-s...@lists.mozilla.org
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

Kurt Roeckx

unread,
Apr 21, 2017, 6:38:50 AM4/21/17
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
On Fri, Apr 21, 2017 at 11:16:56AM +0100, Gervase Markham via dev-security-policy wrote:
> Minor:
> Issue B: Issuance of 1024-bit Certificate Expiring After Deadline

I'm still concerned that they don't seem to have an idea of what
software they're all (still) running, and they didn't reply to any
question about it.


Kurt

Ryan Sleevi

unread,
Apr 21, 2017, 9:31:27 AM4/21/17
to Gervase Markham, mozilla-dev-security-policy
On Fri, Apr 21, 2017 at 6:16 AM, Gervase Markham via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

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

Gerv,

I would encourage you to talk to Kathleen before considering that matter
resolved, because it is different than the advice and requirements that
have been given to other CAs, and to the work required of them.

For example, as you know, Mozilla required that the Belgian subordinates
previously under the Verizon brands, now under Digicert, under go a BR
audit to attest that no SSL certificates have been issued. This is not the
only CA, but it was merely the most recent for which such a requirement was
made - of both the sub-CA and the parent CA. The conclusion to strike this
would thus be be an inconsistent application of Mozilla policy. I believe
you're on some of those threads.

The audits provided are also not consistent with the Mozilla Root Program
requirements, which define technical capability of issuance and the
appropriate audit standards. Specifically, section 5.3 of the policy
appears to provide unambiguous clarification that the audit scheme used for
these sub-CAs, and their sub-CAs, is not consistent with Mozilla policy,
and this non-consistency has been made clear to other CAs with a
requirement for remediation or revocation.

Gervase Markham

unread,
Apr 24, 2017, 5:18:31 AM4/24/17
to Kurt Roeckx
On 21/04/17 11:38, Kurt Roeckx wrote:
> I'm still concerned that they don't seem to have an idea of what
> software they're all (still) running, and they didn't reply to any
> question about it.

I'm sorry, I don't follow. Can you expand?

Gerv

Kurt Roeckx

unread,
Apr 24, 2017, 7:06:00 AM4/24/17
to mozilla-dev-s...@lists.mozilla.org
I confused some of the issues. It was about issue J. The reply
(https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/Jj9ZpMs-pWM)
talked about "deprecated, enterprise-only interface" and "historic
interface".

This seems to imply that either deprecated interfaces don't need to
follow the BR requirements or they have no overview of all the software
they are still running and so didn't check all of them to be in compliance.


Kurt

Ryan Sleevi

unread,
Apr 25, 2017, 12:14:31 AM4/25/17
to Ryan Sleevi, mozilla-dev-security-policy, Gervase Markham
Gerv,

Is there any update on
https://wiki.mozilla.org/CA:Symantec_Issues#STRUCK:_Issue_Y:_Unaudited_Unconstrained_Intermediates_.28December_2015_-_April_2017.29
?

I'm just wanting to understand how this relates to Mozilla's PKI policy and
expectations, and better understand why you struck it.

- The CP/CPS does not state adherence to the Baseline Requirements.
- The audit was only to "WebTrust Principles and Criteria for CAs v2.0" -
e.g. not BRs
- Seemingly excluded from scope of the audits are the following, for
https://crt.sh/?Identity=%25&iCAID=1384&exclude=expired , on the basis of
Footnote 1 in
https://www.symantec.com/content/en/us/about/media/repository/Symantec-NFSSP-WTCA_11-30-2016.pdf
- https://crt.sh/?id=19602740
- https://crt.sh/?id=19602709
- https://crt.sh/?id=19602733
- https://crt.sh/?id=19602720
- https://crt.sh/?id=19602670
- https://crt.sh/?id=19602679
- https://crt.sh/?id=19602705
- https://crt.sh/?id=19602730

Of critical relevance:
- If you examine the CPS that was audited,
https://www.symantec.com/content/en/us/about/media/repository/nf-ssp-pki-cps.pdf,
it notes in Appendix A.5 that the profile includes issuing certificates
with dNSName and iPAddress SANs, with the anyExtendedKeyUsage (or the
presence of more specific EKUs)

- If you examine Symantec's statements on this matter in
https://bugzilla.mozilla.org/attachment.cgi?id=8860216 , they stated
"Under the Non-Federal SSP program, they are used to issue certificates for
Microsoft Windows domain controllers and IPSec endpoints." . A Windows
Domain controller requires that it have id-kp-serverAuth, with a dNSName
SAN (
https://support.microsoft.com/en-us/help/291010/requirements-for-domain-controller-certificates-from-a-third-party-ca
)

Thus, there is every indication that Symantec has issued certificates used
for SSL/TLS under these intermediates and failed to maintain the
appropriate audits, as required by Mozilla Policy.

Perhaps it might be useful to clarify, given that DigiCert and Verizon
have, since January, been operating under a different set of advice from
Mozilla: For a CA not "intended" to issue SSL/TLS certificates, but is
technically capable of doing so, and merely has not, what audits does
Mozilla expect around this? Further, does Mozilla expect a sampling audit
of 3% or a full audit of 100% with respect to whatever attestations are
made regarding the non-issuance of TLS certificates?

For your reference, this was
https://bugzilla.mozilla.org/show_bug.cgi?id=1335253 , and you can find the
thread titled "RE: Audit of Belgian subordinates" dated Jan 6 to several of
the CA peers, including yourself.

Ryan Sleevi

unread,
Apr 25, 2017, 12:20:09 AM4/25/17
to Ryan Sleevi, mozilla-dev-security-policy, Gervase Markham
I actually missed something in
https://bug1334377.bmoattachments.org/attachment.cgi?id=8860216

"With the wind-down of the SSL/TLS RA program, all authentication and
issuance of certificates chaining to Class 3 CAs is done by Symantec;
Google and Apple in the case of the GeoRoot sub-CAs; and customers of the
Non-Federal SSP program (in this case used to issue certificates for
Microsoft Windows domain controllers and IPSec endpoints). "

This would imply that customers of the NF SSP program can direct and
perform RA duties for the issuance of domain controller certificates, which
have the full capability of TLS server certificates, as directed above.

This would seem consistent with the audit findings in
https://www.symantec.com/content/en/us/about/media/repository/Symantec-NFSSP-WTCA_11-30-2016.pdf
which states

"Symantec makes use of external registration authorities for specific
subscriber registration activities for the Symantec Non-Federal SSP -
Customer Specific CAs and Symantec Healthcare CA ... Our examination did
not extend to the controls exercised by these external registration
authorities."

So the audit, the CPS, and Symantec's own statements seem to indicate that
external RAs had the capability of issuing domain controller certificates,
which would minimally include id-kp-serverAuth, id-kp-clientAuth, and
dNSName SANs, from an intermediate that was and is enabled for TLS server
authentication at the request of VeriSign (
https://bugzilla.mozilla.org/show_bug.cgi?id=515470 ) and as maintained by
Symantec.

>

Gervase Markham

unread,
Apr 25, 2017, 9:15:16 AM4/25/17
to ry...@sleevi.com
On 21/04/17 14:30, Ryan Sleevi wrote:
> I would encourage you to talk to Kathleen before considering that matter
> resolved, because it is different than the advice and requirements that
> have been given to other CAs, and to the work required of them.

Thank you for these points. It could be that my resolution of the issue
was premature. I have un-struck Issue Y pending further investigation.

Gerv

Ryan Sleevi

unread,
Apr 25, 2017, 6:50:36 PM4/25/17
to Ryan Sleevi, mozilla-dev-security-policy, Gervase Markham
Continuing to look through the audits, I happened to notice a few other
things that stood out, some more pressing than others.

More pressing:
I can find no disclosure with Salesforce or crt.sh of at least two CAs that
are listed 'in scope' of the audit report, as part of
https://www.symantec.com/content/en/us/about/media/
repository/Symantec-NFSSP-WTCA_11-30-2016.pdf

This audit report identifies the "SureID Inc. CA2" and "SureID Inc. Device
CA2" as within scope for this audit. It would be useful to understand their
lack of disclosure, relative to the audits and to Section 5.3.2 of the
inclusion policy.

Less pressing (as it relates to e-mail):
One other question with disclosing audits: My understanding of
https://www.mozilla.org/en-US/about/governance/policies/
security-group/certs/policy/ , particularly Section 5.3.2 and Section
3.1.2.1, is that for CA certificates that are enabled for the email trust
bit, the CA, and all subordinate CAs capable of issuing e-mail
certificates, must have a WebTrust for CAs audit, and must be publicly
disclosed, is that correct?

Looking through CAs such as https://crt.sh/?caid=598 , which is disclosed (
https://crt.sh/?id=68409 ), it seems there are a substantial number of
subordinate CAs capable of issuing e-mail certificates that are not
disclosed. I thought this might be due to scaling the CCADB, but I note
that Microsoft's Trusted Root Requirements have required the same audits (
https://social.technet.microsoft.com/wiki/contents/articles/31635.microsoft-
trusted-root-certificate-program-audit-requirements.aspx#A_WebTrust_Audits )
for some time. Do you or Kathleen know the status of these disclosures and
audits?

Rob Stradling

unread,
Apr 26, 2017, 4:21:28 PM4/26/17
to ry...@sleevi.com, Gervase Markham, mozilla-dev-security-policy
On 25/04/17 23:50, Ryan Sleevi via dev-security-policy wrote:
> Continuing to look through the audits, I happened to notice a few other
> things that stood out, some more pressing than others.
>
> More pressing:
> I can find no disclosure with Salesforce or crt.sh of at least two CAs that
> are listed 'in scope' of the audit report, as part of
> https://www.symantec.com/content/en/us/about/media/
> repository/Symantec-NFSSP-WTCA_11-30-2016.pdf

Hi Ryan. Today I went hunting for missing intermediate certificates. I
produced a list of all the AIA:caIssuers URLs from all certs known to
crt.sh. Then I downloaded and parsed all of them, attempting to decode
each file as DER cert, PEM cert, DER PKCS#7 and PEM PKCS#7. Then I
submitted the previously unseen certs to CT.

> This audit report identifies the "SureID Inc. CA2" and "SureID Inc. Device
> CA2" as within scope for this audit. It would be useful to understand their
> lack of disclosure, relative to the audits and to Section 5.3.2 of the
> inclusion policy.

Those two now appear here:
https://crt.sh/?id=129400172
https://crt.sh/?id=129400151

https://crt.sh/mozilla-disclosures#undisclosed currently lists these two
SureID intermediates plus a further VeriSign intermediate
(https://crt.sh/?id=129148836) that should've been disclosed to CCADB
some time ago.

(Note: A few of the non-Symantec entries currently listed by
https://crt.sh/mozilla-disclosures#undisclosed are false positives, I
think. It looks like Kathleen has marked some roots as "Removed" on
CCADB ahead of the corresponding certdata.txt update on mozilla-central).

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

Steve Medin

unread,
Apr 26, 2017, 8:48:46 PM4/26/17
to mozilla-dev-s...@lists.mozilla.org
> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symant...@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Friday, April 21, 2017 6:17 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Symantec Conclusions and Next Steps
>
[snip]
>
> 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 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.

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

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/CA%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.

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

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.

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

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.

Richard Wang

unread,
Apr 27, 2017, 6:16:24 AM4/27/17
to Steve Medin, mozilla-dev-s...@lists.mozilla.org
I like to share the experience we suffered from distrust, it is disastrous for CA and its customers to replace the certificate that exceed your imagination that we are still working for this since October 2016 that nearly six months now.

Due to the quantity of Symantec customers is more than WoSign and most companies are bigger than WoSign's customers, I am sure that the interoperability and compatibility failures could bring big problem to Symantec, to Symantec customers and the Browser users.

I think Symantec's proposal is good and will benefit its customers that it will not make the world mess.

Thanks.

Best Regards,

Richard

Rob Stradling

unread,
Apr 27, 2017, 6:38:52 AM4/27/17
to mozilla-dev-security-policy
On 26/04/17 21:21, Rob Stradling via dev-security-policy wrote:
<snip>
> (Note: A few of the non-Symantec entries currently listed by
> https://crt.sh/mozilla-disclosures#undisclosed are false positives, I
> think. It looks like Kathleen has marked some roots as "Removed" on
> CCADB ahead of the corresponding certdata.txt update on mozilla-central).

Ah, I take that back. The March certdata.txt update did hit
mozilla-central on 11th April, but I missed an alert. I've just pushed
that update to crt.sh.

https://crt.sh/mozilla-disclosures#undisclosed is currently free of
false positives. It shows that DigiCert, StartCom and Symantec are
currently out-of-compliance with Mozilla's disclosure requirement.

Inigo Barreira

unread,
Apr 27, 2017, 6:56:49 AM4/27/17
to Rob Stradling, mozilla-dev-security-policy
Good to know that our new certs are there :-)
Regarding StartCom, these are the new certs we´ve generated and will be used
to apply for inclusion in the Mozilla root program. Nothing to disclose at
the moment I guess. We´ve not been audited yet nor applied.

Best regards

Iñigo Barreira
CEO
StartCom CA Limited
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Rob Stradling

unread,
Apr 27, 2017, 7:08:27 AM4/27/17
to Inigo Barreira, mozilla-dev-security-policy
On 27/04/17 11:56, Inigo Barreira wrote:
> Good to know that our new certs are there :-)
> Regarding StartCom, these are the new certs we´ve generated and will be used
> to apply for inclusion in the Mozilla root program. Nothing to disclose at
> the moment I guess. We´ve not been audited yet nor applied.
<snip>

Hi Iñigo. The old StartCom roots still have the SSL trust bit enabled
in NSS, and you've used one of those old roots to cross-sign the new
StartCom roots. AFAICT, that means that these new StartCom
intermediates do need to be disclosed to the CCADB.

Inigo Barreira

unread,
Apr 27, 2017, 7:12:23 AM4/27/17
to Rob Stradling, mozilla-dev-security-policy
No problem at all. I thought that while distrusted no needed to follow nor
update the CCADB. Will do asap.

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-----Original Message-----
From: Rob Stradling [mailto:rob.st...@comodo.com]
Sent: jueves, 27 de abril de 2017 13:08
To: Inigo Barreira <in...@startcomca.com>; mozilla-dev-security-policy
<mozilla-dev-s...@lists.mozilla.org>
Subject: Re: Symantec Conclusions and Next Steps

tmcque...@gmail.com

unread,
Apr 27, 2017, 7:13:11 AM4/27/17
to mozilla-dev-s...@lists.mozilla.org
I don't know about others, but I am quite disappointed by Symantec's proposed remediation plan. Intentional or not, these response seems to indicate they don't really understand the potential consequences of many of their past 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 actions, including allowing various third parties carte blanche to issue certs chaining to publicly trusted roots without meaningful oversight (issues L, W, and Y). This is compounded by apparent institutional difficulties with properly identifying the scope of problems and resolving them (e.g. why did SHA-1 Issue H not lead to procedures so Issue J didn't happen; on Issue D, why 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 the significant lack of oversight (intentional or not) even in cases where they *knew* there were problems (e.g. Issues P,Q,T,V).

In light of this history (as well as related history for other CAs discussed 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 response?

It seems to me the existing Symantec PKI is a mess and any steps short of complete distrust of all existing roots leaves relying parties exposed to significant risk.

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

The problem of course is compatibility (Symantec's own plan essentially says "yes, many bad architectural decisions were made by us and our (mostly large 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 existing 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.

This may seem more extreme, but with one addition there are some attractive features that actually reduce compatibility risks (especially to non-browser facing systems), allows symantec to rearchitect their public PKI to follow practices that should help avoid complete distrusts in the future, and gives 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 allows the various root programs to clearly articulate requirements under which these new roots operate (eg mandatory disclosure and auditing of all subCAs and cross-signed roots (and their subCAs) *technically capable* (even if administratively constrained or constrained by technical means not recognized by public web PKI browsers) of issuing browser trusted certificates, CT logging, validation methods, certificate validity limits, etc). Since these new roots don't have legacy baggage, any violations of root program policy 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 categories:
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 Symantec'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 to 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 compatibility issues by giving enterprises flexibility in planning their internal certificate changes (vs the original Google proposal where the not distrusted 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 requires 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 non-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 in 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 more frequently changed browser-accessed ones. Further,there are pure server-side solutions that could address these cases if absolutely required (cf cloudflare sha1 serving to legacy clients).

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

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 EV for a long long time, as their policy seems to have been: what their customer wants, their customer gets.

Ryan Sleevi

unread,
Apr 27, 2017, 8:38:08 AM4/27/17
to Richard Wang, mozilla-dev-s...@lists.mozilla.org, Steve Medin
Hi Richard,

On Thu, Apr 27, 2017 at 6:13 AM, Richard Wang via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> I like to share the experience we suffered from distrust, it is disastrous
> for CA and its customers to replace the certificate that exceed your
> imagination that we are still working for this since October 2016 that
> nearly six months now.
>

Yes, when an organization demonstrates its willingness to be operated in a
non-trustworthy manner, knowingly and with actively deceptive processes, it
can be very difficult for them to regain trust.


>
> Due to the quantity of Symantec customers is more than WoSign and most
> companies are bigger than WoSign's customers, I am sure that the
> interoperability and compatibility failures could bring big problem to
> Symantec, to Symantec customers and the Browser users.


Do you believe that, during the discussions about how to respond to
WoSign's issues, the scope of impact was underestimated? If so, can you
share how? That might be a more productive and fruitful contribution, if
people trust the response.

Jeremy Rowley

unread,
Apr 27, 2017, 3:53:23 PM4/27/17
to Rob Stradling, mozilla-dev-security-policy
Your post made me realize that we never publicly posted the status of these
last few CAs. Sorry about that. Here's the plan:

1. ABB - ABB was supposed to be technically constrained (and is restricted
to certain names). However, the technical constraints were added incorrectly
and didn't exclude IPv6. We're working with them to update the intermediate
with a properly constrained sub CA.

2. Bechtel - The Bechtel intermediates are scheduled for revocation the last
day of April.

3. Nets Norway - This intermediate lacked an EKU but was constrained to
certain domain names under Nets Norway's control. Nets Norway is no longer
using the intermediate but would like to leave the intermediate active until
the certs expire. I'm not sure what to do on this one. Any thoughts?

4. Belgium Roots - The Belgium roots have audits now. We are waiting on the
audit report publication to change the status. The reports were provided to
the browsers but aren't available publicly yet. The Belgium CAs only issue
client certificates.

Jeremy



-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Rob Stradling via dev-security-policy
Sent: Thursday, April 27, 2017 4:38 AM
To: mozilla-dev-security-policy
<mozilla-dev-s...@lists.mozilla.org>
Subject: Re: Symantec Conclusions and Next Steps

On 26/04/17 21:21, Rob Stradling via dev-security-policy wrote:
<snip>
> (Note: A few of the non-Symantec entries currently listed by
> https://crt.sh/mozilla-disclosures#undisclosed are false positives, I
> think. It looks like Kathleen has marked some roots as "Removed" on
> CCADB ahead of the corresponding certdata.txt update on mozilla-central).

Ah, I take that back. The March certdata.txt update did hit mozilla-central
on 11th April, but I missed an alert. I've just pushed that update to
crt.sh.

https://crt.sh/mozilla-disclosures#undisclosed is currently free of false
positives. It shows that DigiCert, StartCom and Symantec are currently
out-of-compliance with Mozilla's disclosure requirement.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

Alex Gaynor

unread,
Apr 27, 2017, 4:05:24 PM4/27/17
to Jeremy Rowley, Rob Stradling, mozilla-dev-security-policy
On Thu, Apr 27, 2017 at 3:52 PM, Jeremy Rowley via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Your post made me realize that we never publicly posted the status of these
> last few CAs. Sorry about that. Here's the plan:
>
> 1. ABB - ABB was supposed to be technically constrained (and is restricted
> to certain names). However, the technical constraints were added
> incorrectly
> and didn't exclude IPv6. We're working with them to update the
> intermediate
> with a properly constrained sub CA.
>
> 2. Bechtel - The Bechtel intermediates are scheduled for revocation the
> last
> day of April.
>
> 3. Nets Norway - This intermediate lacked an EKU but was constrained to
> certain domain names under Nets Norway's control. Nets Norway is no longer
> using the intermediate but would like to leave the intermediate active
> until
> the certs expire. I'm not sure what to do on this one. Any thoughts?
>
>
To save everyone else 3 minutes of search crt.sh, the oldest cert that I
saw under this intermediate was November 2019.

Alex

Jeremy Rowley

unread,
Apr 27, 2017, 4:06:21 PM4/27/17
to Alex Gaynor, Rob Stradling, mozilla-dev-security-policy
Thanks Alex. Greatly appreciated.



From: Alex Gaynor [mailto:aga...@mozilla.com]
Sent: Thursday, April 27, 2017 2:05 PM
To: Jeremy Rowley <jeremy...@digicert.com>
Cc: Rob Stradling <rob.st...@comodo.com>; mozilla-dev-security-policy
<mozilla-dev-s...@lists.mozilla.org>
Subject: Re: Symantec Conclusions and Next Steps







On Thu, Apr 27, 2017 at 3:52 PM, Jeremy Rowley via dev-security-policy
<dev-secur...@lists.mozilla.org
<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy


_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy



Richard Wang

unread,
Apr 28, 2017, 4:19:01 AM4/28/17
to ry...@sleevi.com, mozilla-dev-s...@lists.mozilla.org, Steve Medin
Hi Ryan,



For your question “Do you believe that, during the discussions about how to respond to WoSign's issues, the scope of impact was underestimated?”, the answer is YES.



After Oct 21 2016, WoSign stopped to issue SSL certificates from WoSign root (to be exactly, maybe few in October, but all replaced), we know our customers don’t accept the problem of interoperability and compatibility failures, so we cooperated with other Trusted CAs to sell their certificates to our customers since Nov 21 2016, to replace the affected SSL certificates and code signing certificates for our charged customers for FREE, to renew and order certificates for current customers and new customers to keep our business continuity till we have our own new trusted roots.



WoSign appreciated Mozilla’s decision: trust the certificates that issued before Oct 20 2016, and similarly rule for Apple and Microsoft, and we also promised to our customers for this, this decision don’t bring any troubles to our issued certificate customers, very good.



But Google start to distrust WoSign certificates unless the site is in the Alexa Top 1M site list since Chrome 57, this bring many problems to us and to our customers, to provide best service to our customers, we provide FREE replacement for our charged customers that we must pay the cost to the Partner (Trusted CA). Till now, we replaced 596 certificates for our customers for free, and there are 97 orders ask for refund instead of replacement. This Google decision’s problem is some big websites used a domain that not listed in Alexa 1M suffered disruption, for example, Qihoo 360’s search site and online gaming sites used a domain in CDN for pictures that not listed in Top 1M, there are more than 500M users suffered the untrusted warning and 360 need to replace the certificates for thousands of servers.



The problem also come from the WoSign Root CA pinned for some payment gateway from online payment service providers and from some online banking APPs, even we replaced the certificate for them for free, they need to update the gateway/API software to accept the new trusted root, and need to update the bank APP to recognize the new certificate and new root, this is terrible that all those customers curse us and very angry.



For affected 2417 Code Signing certificates, there are many customers signed the code, but distrusted by Microsoft that customers ask for full refund and need to buy the new code signing cert from other CA that need to sign the software again that installed in billions system, this is also a disaster to customers and its software users.

We can’t image the result in the future for “In subsequent Chrome releases, these exceptions will be reduced and ultimately removed, culminating in the full distrust of WoSign”, this means all WoSign issued SSL certificates in the last three years need to be replaced, including the 2845 valid certificates for Microsoft Azure and Office 365 that Microsoft Sumedh said “any outage of an Azure service that lasts more than a few minutes gets escalated to our executives.”

The total valid SSL certificates is 173,886, and the charged valid certificates is 10,368 that we need to pay money to other CA for free replacement (if US$100 per certificate, the total cost is over US$ One Million!), I think this is not only money problem, but it also will bring huge work to us and to our customers to replace the certificate. This is the next BIG disaster if Chrome distrust all WoSign certificates that issued before Oct. 20 2016.



So, I wish Google can reconsider the plan that change to distrust all WoSign issued free SSL certificates, but keep to trust the charged one (DV SSL/IV SSL/OV SSL/EV SSL) that don’t have any mis-issuance problem, those charged certificates is used for many big eCommerce websites, many government websites, many bank systems, many securities systems, many cloud service providers like Azure that used by the world biggest companies. Thanks.



So, this is why I said some words for Symantec to let browsers to consider the distrust result seriously. The Web Ecosystem players not just browsers, but also the CAs, and also the website owners (certificate subscribers), we all have the responsibility for the global Internet security, but we need to balance all related party’s benefit and negotiate an acceptable solution for any problem that happened.

Thanks.



Best Regards,



Richard



From: Ryan Sleevi [mailto:ry...@sleevi.com]
Sent: Thursday, April 27, 2017 8:38 PM
To: Richard Wang <ric...@wosign.com>
Cc: Steve Medin <Steve...@symantec.com>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Symantec Conclusions and Next Steps



Hi Richard,

Gervase Markham

unread,
Apr 28, 2017, 5:15:15 AM4/28/17
to mozilla-dev-s...@lists.mozilla.org
If the Nets Norway intermediate is technically constrained only to
domains that Nets Norway own or control, I have no problem with leaving
it active.

Gerv

uri...@gmail.com

unread,
Apr 28, 2017, 11:50:10 AM4/28/17
to mozilla-dev-s...@lists.mozilla.org
Richard,

Did you communicate to your customers over the last 6 months that their existing certificates may become distrusted? Or did they find out when their sites stopped working in Chrome?

Eric Mill

unread,
Apr 28, 2017, 1:28:17 PM4/28/17
to Richard Wang, ry...@sleevi.com, Steve Medin, mozilla-dev-s...@lists.mozilla.org
On Fri, Apr 28, 2017 at 4:16 AM, Richard Wang via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> This Google decision’s problem is some big websites used a domain that not
> listed in Alexa 1M suffered disruption, for example, Qihoo 360’s search
> site and online gaming sites used a domain in CDN for pictures that not
> listed in Top 1M,
>

That's a plausible and interesting point about gauging impact to the Alexa
Top 1M. If the goal is to avoid affecting them, analyzing the resources
they pull from other origins has to be part of that.

-- Eric
Message has been deleted

Lee

unread,
Apr 29, 2017, 11:18:57 AM4/29/17
to Eric Mill, mozilla-dev-s...@lists.mozilla.org
On 4/28/17, Eric Mill via dev-security-policy
I think the goal is still full distrust - see
https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html
Beginning with Chrome 56, certificates issued by WoSign and
StartCom after October 21, 2016 00:00:00 UTC will not be trusted.
<.. snip ..>
In subsequent Chrome releases, these exceptions will be reduced
and ultimately removed, culminating in the full distrust of these CAs.
This staged approach is solely to ensure sites have the opportunity to
transition to other Certificate Authorities that are still trusted in
Google Chrome, thus minimizing disruption to users of these sites.

Lee

Alex Gaynor

unread,
May 1, 2017, 9:52:50 AM5/1/17
to Steve Medin, mozilla-dev-s...@lists.mozilla.org
(I work for Mozilla, but this email doesn't necessarily reflect the views
of Mozilla).

Hi Steve,

I appreciate Symantec taking the time to put this together. There's a lot
of unpack here, so I wanted to zoom in on one portion of it.

When discussing the feedback you received from enterprise customers, and
the impact that Google's proposed change would have, one of the challenges
you highlight is for customers who have pinned certificates, from mobile
apps to embedded devices.

I find this a bit perplexing, Google's current proposal does not remove
trust in the existing Symantec roots, it merely accelerates the expiration
of existing end-entity certs, and caps the lifetime of future certs.

While I'm happy to grant that re-issuance can be a time consuming procedure
for large organizations which have failed to automate certificate issuance
and deployment (hopefully this is something they're working on!), this
challenge is more or less unrelated to needing to change pinned roots/trust
stores.

In short, Symantec appears to be describing potential fallout from a total
distrust, which is not what Google's Intent to Deprecate thread proposed.
Can you speak to why Symantec chose to focus on this issue?

Thanks,
Alex

On Wed, Apr 26, 2017 at 8:48 PM, Steve Medin via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> > -----Original Message-----
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>

Steve Medin

unread,
May 15, 2017, 11:24:40 AM5/15/17
to ry...@sleevi.com, Gervase Markham, mozilla-dev-security-policy
> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symant...@lists.mozilla.org] On Behalf Of Ryan
> Sleevi via dev-security-policy
> Sent: Tuesday, April 25, 2017 6:50 PM
> To: Ryan Sleevi <ry...@sleevi.com>
> Cc: mozilla-dev-security-policy <mozilla-dev-security-
> pol...@lists.mozilla.org>; Gervase Markham <ge...@mozilla.org>
> Subject: [EXT] Re: Symantec Conclusions and Next Steps
>
> Continuing to look through the audits, I happened to notice a few other
> things that stood out, some more pressing than others.
>
> More pressing:
> I can find no disclosure with Salesforce or crt.sh of at least two CAs
that are
> listed 'in scope' of the audit report, as part of
> https://www.symantec.com/content/en/us/about/media/
> repository/Symantec-NFSSP-WTCA_11-30-2016.pdf
>
> This audit report identifies the "SureID Inc. CA2" and "SureID Inc. Device
CA2"
> as within scope for this audit. It would be useful to understand their
lack of
> disclosure, relative to the audits and to Section 5.3.2 of the inclusion
policy.
>

The two SureID CAs are now disclosed. They were inadvertently omitted.

https://mozillacacommunity.force.com/001o0000016Uc20
https://mozillacacommunity.force.com/001o0000016Uc6M

Based on https://crt.sh/mozilla-disclosures#undisclosedsummary, we also
disclosed an additional version of the CSC Device CA - G2. Both versions are
signed by the VeriSign Class 3 SSP Intermediate CA - G2. The previously
disclosed CSC Device CA - G2 expires on August 14, 2021.

Existing: https://mozillacacommunity.force.com/001o000000p4Sf2
New: https://mozillacacommunity.force.com/001o0000016UfuS

We further updated CCADB to ensure it mirrors the PKI Map we are creating.
As part of that effort we posted:

- 39 entries that chain to roots no longer trusted by Mozilla
- 10 which chain to the revoked VeriSign Class 3 SSP Intermediate CA
- 13 which are either technically constrained by EKU or software
constrained in Symantec operated systems, limiting issuance to code signing
or time stamping authority certificates.
- Additional entries to capture different versions of the same subCA,
even in cases where the versions were never deployed and/or never issued end
entity certificates.
0 new messages