RE: [EXT] Re: Symantec Conclusions and Next Steps
> -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 > Cc: mozilla-dev-security-policy pol...@lists.mozilla.org>; Gervase Markham > 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
(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 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 enga
Re: Symantec Conclusions and Next Steps
On 4/28/17, Eric Mill via dev-security-policy wrote: > 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. 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 ___ 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
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
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
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 > Cc: Steve Medin ; > 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 > 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
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
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 Cc: Steve Medin ; 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 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 certi
RE: Symantec Conclusions and Next Steps
Thanks Alex. Greatly appreciated. From: Alex Gaynor [mailto:agay...@mozilla.com] Sent: Thursday, April 27, 2017 2:05 PM To: Jeremy Rowley Cc: Rob Stradling ; mozilla-dev-security-policy Subject: Re: Symantec Conclusions and Next Steps On Thu, Apr 27, 2017 at 3:52 PM, Jeremy Rowley via dev-security-policy 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 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
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 > > 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
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 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
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
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 a
RE: Symantec Conclusions and Next Steps
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 ; mozilla-dev-security-policy 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
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
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 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
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
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
> -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 internal and external resources. In many cases the applications being used are pinned to Symantec certificates. - Some large organ
Re: Symantec Conclusions and Next Steps
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
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
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 ___ 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
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&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 ) > 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
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. ___ 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
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
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
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
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