RE: [EXT] Re: Symantec Conclusions and Next Steps

[Steve Medin via dev-security-policy]

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of Ryan
> Sleevi via dev-security-policy
> Sent: Tuesday, April 25, 2017 6:50 PM
> To: Ryan Sleevi <r...@sleevi.com>
> Cc: mozilla-dev-security-policy  pol...@lists.mozilla.org>; Gervase Markham <g...@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/001o016Uc20 
https://mozillacacommunity.force.com/001o016Uc6M 

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/001o00p4Sf2 
New: https://mozillacacommunity.force.com/001o016UfuS 

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.


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Conclusions and Next Steps

[Alex Gaynor via dev-security-policy]

(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-security-policy@lists.mozilla.org> wrote:

> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> > Gervase Markham via dev-security-policy
> > Sent: Friday, April 21, 2017 6:17 AM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: Symantec Conclusions and Next Steps
> >
> [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 infrastr

Re: Symantec Conclusions and Next Steps

[Percy via dev-security-policy]

On Friday, April 28, 2017 at 1:19:01 AM UTC-7, Richard Wang wrote:
> 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.
> 

This is not what you said. You said "Mozilla’s sanctions are too severe" 
-https://www.wosign.com/english/News/announcement_about_Mozilla_Action_20161024.htm
> 
> 
> 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.
> 

Since all the certs are supposedly included in the cert transparency already, 
would you able to share what apps pinned your certs with the certs?  Of only a 
handful of banking related apps included in the apps, I haven't seen any 
failure because of pinning. In fact, why would the Chrome distrust cause the 
failure in pinning in the app? 
> 
> 
> 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.
> 

Could you point to a Microsoft announcement that points to removal of WoSign 
certs? In fact, Microsoft explicitly said WoSign/StartCom is trusted. 
https://social.technet.microsoft.com/wiki/contents/articles/37425.microsoft-trusted-root-certificate-program-participants-as-of-march-9-2017.aspx
 (as of March 9, 2017)

> 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 

Re: Symantec Conclusions and Next Steps

[Eric Mill via dev-security-policy]

On Fri, Apr 28, 2017 at 4:16 AM, Richard Wang via dev-security-policy <
dev-security-policy@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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Conclusions and Next Steps

[urijah--- via dev-security-policy]

ave 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:r...@sleevi.com]
> Sent: Thursday, April 27, 2017 8:38 PM
> To: Richard Wang <rich...@wosign.com>
> Cc: Steve Medin <steve_me...@symantec.com>; 
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Symantec Conclusions and Next Steps
> 
> 
> 
> Hi Richard,
> 
> 
> 
> On Thu, Apr 27, 2017 at 6:13 AM, Richard Wang via dev-security-policy 
> <dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@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.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Conclusions and Next Steps

[Gervase Markham via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Symantec Conclusions and Next Steps

[Richard Wang via dev-security-policy]

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:r...@sleevi.com]
Sent: Thursday, April 27, 2017 8:38 PM
To: Richard Wang <rich...@wosign.com>
Cc: Steve Medin <steve_me...@symantec.com>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Symantec Conclusions and Next Steps



Hi Richard,



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

   I like to share the exp

RE: Symantec Conclusions and Next Steps

[Jeremy Rowley via dev-security-policy]

Thanks Alex. Greatly appreciated.



From: Alex Gaynor [mailto:agay...@mozilla.com]
Sent: Thursday, April 27, 2017 2:05 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: Rob Stradling <rob.stradl...@comodo.com>; mozilla-dev-security-policy 
<mozilla-dev-security-pol...@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-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@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



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 
<mailto:dev-security-policy-bounces%2Bjeremy.rowley> 
=digicert.com@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-security-pol...@lists.mozilla.org 
<mailto:mozilla-dev-security-pol...@lists.mozilla.org> >
Subject: Re: Symantec Conclusions and Next Steps

On 26/04/17 21:21, Rob Stradling via dev-security-policy wrote:

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

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


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





smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Conclusions and Next Steps

[Alex Gaynor via dev-security-policy]

On Thu, Apr 27, 2017 at 3:52 PM, Jeremy Rowley via dev-security-policy <
dev-security-policy@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


> 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=
> digicert.com@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-security-pol...@lists.mozilla.org>
> Subject: Re: Symantec Conclusions and Next Steps
>
> On 26/04/17 21:21, Rob Stradling via dev-security-policy wrote:
> 
> > (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
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Symantec Conclusions and Next Steps

[Jeremy Rowley via 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=digicert.com@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-security-pol...@lists.mozilla.org>
Subject: Re: Symantec Conclusions and Next Steps

On 26/04/17 21:21, Rob Stradling via dev-security-policy wrote:

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Conclusions and Next Steps

[Ryan Sleevi via dev-security-policy]

Hi Richard,

On Thu, Apr 27, 2017 at 6:13 AM, Richard Wang via dev-security-policy <
dev-security-policy@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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Conclusions and Next Steps

[wizard--- via dev-security-policy]

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 

RE: Symantec Conclusions and Next Steps

[Inigo Barreira via 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.stradl...@comodo.com] 
Sent: jueves, 27 de abril de 2017 13:08
To: Inigo Barreira <in...@startcomca.com>; mozilla-dev-security-policy
<mozilla-dev-security-pol...@lists.mozilla.org>
Subject: Re: Symantec Conclusions and Next Steps

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.


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.

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



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Conclusions and Next Steps

[Rob Stradling via 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.



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.


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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Symantec Conclusions and Next Steps

[Inigo Barreira via 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

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Rob Stradling via dev-security-policy
Sent: jueves, 27 de abril de 2017 12:38
To: mozilla-dev-security-policy
<mozilla-dev-security-pol...@lists.mozilla.org>
Subject: Re: Symantec Conclusions and Next Steps

On 26/04/17 21:21, Rob Stradling via dev-security-policy wrote:

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Conclusions and Next Steps

[Rob Stradling via dev-security-policy]

On 26/04/17 21:21, Rob Stradling via dev-security-policy wrote:


(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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Symantec Conclusions and Next Steps

[Richard Wang via dev-security-policy]

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

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Steve Medin via dev-security-policy
Sent: Thursday, April 27, 2017 8:48 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Symantec Conclusions and Next Steps


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.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Symantec Conclusions and Next Steps

[Steve Medin via dev-security-policy]

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Friday, April 21, 2017 6:17 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Symantec Conclusions and Next Steps
> 
[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 interna

Re: Symantec Conclusions and Next Steps

[Rob Stradling via 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Conclusions and Next Steps

[Ryan Sleevi via dev-security-policy]

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?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Conclusions and Next Steps

[Ryan Sleevi via dev-security-policy]

On Tue, Apr 25, 2017 at 12:14 AM, Ryan Sleevi  wrote:

> 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=1384=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 )
>

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.

>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Conclusions and Next Steps

[Ryan Sleevi via dev-security-policy]

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=1384=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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Conclusions and Next Steps

[Kurt Roeckx via dev-security-policy]

On 2017-04-24 11:18, Gervase Markham wrote:

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?


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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Conclusions and Next Steps

[Gervase Markham via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Conclusions and Next Steps

[Ryan Sleevi via dev-security-policy]

On Fri, Apr 21, 2017 at 6:16 AM, Gervase Markham via dev-security-policy <
dev-security-policy@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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Conclusions and Next Steps

[Kurt Roeckx via dev-security-policy]

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Symantec Conclusions and Next Steps

[Gervase Markham via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy