Re: [EXT] Re: Draft further questions for Symantec
On 15/05/17 22:08, Michael Casadevall wrote: > RA & EV: > Were all the certificates issued by the RAs uploaded to a CT log? If > not, what, if any, subsets were uploaded? > > I'm aware Symantec was required to upload certificates to CT or if it > was retroactive, but I'm unsure if that requirement was extended to the RAs. Google required Symantec to do this after a date in mid-2016. I would assume it extended to the RAs because otherwise their new certs would not be trusted in Chrome. There was no requirement on Symantec to CT-log all their previous certificates, either issued by themselves or their RAs. > I'm not sure if the green bar requires OIDs in all points along the > certificate chain or if this Florida CA could have issued an leaf > certificate by adding the OIDs there. It only requires the OID in the leaf. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: [EXT] Re: Draft further questions for Symantec
Replacement link: https://bugzilla.mozilla.org/attachment.cgi?id=8867892 Sorry, I had the PDF cached. > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of > urijah--- via dev-security-policy > Sent: Monday, May 15, 2017 3:41 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: [EXT] Re: Draft further questions for Symantec > > The link in footnote [1] > https://www.idmanagement.gov/IDM/servlet/fileField?entityId=ka0t > 000Gmi3AAC=File__Body__s > > gives me a 404 error. > > > On Monday, May 15, 2017 at 11:09:41 AM UTC-4, Steve Medin wrote: > > Gerv, > > > > Our response to the recent questions is posted at: > > https://bugzilla.mozilla.org/attachment.cgi?id=8867735 > > > > Kind regards, > > Steve > > > > > -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: Wednesday, May 10, 2017 7:06 AM > > > To: mozilla-dev-security-pol...@lists.mozilla.org > > > Subject: [EXT] Re: Draft further questions for Symantec > > > > > > On 08/05/17 13:24, Gervase Markham wrote: > > > > 8) Please explain how the Management Assertions for your December > > > > 2014 > > > > > > > > > Strike this question; it's based on a misunderstanding of how audits > > > are done. > > > > > > Let's add: > > > > > > 10) Do you agree that, during the period of time that Symantec > > > cross-signed the Federal PKI (Issue L), it was technically possible > > > for issuers inside the FPKI to issue EV certs by inserting Symantec's EV > OID? > > > > > > 11) If, in the Symantec Issues list or any other document relating > > > to this matter we may publish in future, we have drawn a conclusion > > > or inference about Symantec's PKI, actions or behaviour which is > > > incorrect, we expect you to draw that to our attention, even if the > > > truth is not as favourable to Symantec. Are there any incorrect > > > inferences or conclusions in the Issues List which need to be corrected? > > > > > > Gerv > > > ___ > > > 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 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: [EXT] Re: Draft further questions for Symantec
I took a stab at trying to grok this. I find I have more questions and a lot more concerns the more I read though. Please let me know if I'm not the only one having issues decoding the responses. Here's my first impressions: RA & EV: Were all the certificates issued by the RAs uploaded to a CT log? If not, what, if any, subsets were uploaded? I'm aware Symantec was required to upload certificates to CT or if it was retroactive, but I'm unsure if that requirement was extended to the RAs. Furthermore, based on what I'm reading, at least one of these certificates should be in the logs since it took place post 01/01/15. Issue Y: A simple yes or no answer for the questions would have been nice here. What I'm reading and my understanding suggests that the subCA certificates could have technically issued a certificate trusted by Mozilla, but system controls prevented them from being used that way. How these system controls work is at best unclear. It's worth noting that the subCA "State of Florida AHCA Medium Assurance CA" and several other fPKI subCAs chaining off "VeriSign Class 3 SSP Intermediate CA - G2" are listed in crt.sh is listed as trusted in Mozilla in crt.sh (https://crt.sh/?caid=1384), and based on my understanding thus could theoretically issue certificates as there's no EKU. I can't find any leaf certificates issued by these CAs in crt.sh to confirm this fact though. Here's a question for Symantec, how are they aware of what certificates these sub-subCAs have or have not issued? I'm not sure if the green bar requires OIDs in all points along the certificate chain or if this Florida CA could have issued an leaf certificate by adding the OIDs there. Issue L: Given that the cross-signature was doing by VeriSign, I've got more questions. As far as I can tell, the response suggests that Symantec was aware that the cross-signature allowed the FPKI to be trusted in places it otherwise wouldn't be, and decided to ignore it until it expired out in 2016. That sounds bad, but my other possible reading of this was: "We were unaware of the cross-signature until 2014, and we let it expire in 2016 since we didn't know what it did". ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [EXT] Re: Draft further questions for Symantec
The link in footnote [1] https://www.idmanagement.gov/IDM/servlet/fileField?entityId=ka0t000Gmi3AAC=File__Body__s gives me a 404 error. On Monday, May 15, 2017 at 11:09:41 AM UTC-4, Steve Medin wrote: > Gerv, > > Our response to the recent questions is posted at: > https://bugzilla.mozilla.org/attachment.cgi?id=8867735 > > Kind regards, > Steve > > > -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: Wednesday, May 10, 2017 7:06 AM > > To: mozilla-dev-security-pol...@lists.mozilla.org > > Subject: [EXT] Re: Draft further questions for Symantec > > > > On 08/05/17 13:24, Gervase Markham wrote: > > > 8) Please explain how the Management Assertions for your December 2014 > > > > > > Strike this question; it's based on a misunderstanding of how audits are > > done. > > > > Let's add: > > > > 10) Do you agree that, during the period of time that Symantec cross-signed > > the Federal PKI (Issue L), it was technically possible for issuers inside > > the FPKI > > to issue EV certs by inserting Symantec's EV OID? > > > > 11) If, in the Symantec Issues list or any other document relating to this > > matter we may publish in future, we have drawn a conclusion or inference > > about Symantec's PKI, actions or behaviour which is incorrect, we expect you > > to draw that to our attention, even if the truth is not as favourable to > > Symantec. Are there any incorrect inferences or conclusions in the Issues > > List > > which need to be corrected? > > > > Gerv > > ___ > > 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: [EXT] Re: Draft further questions for Symantec
Gerv, Our response to the recent questions is posted at: https://bugzilla.mozilla.org/attachment.cgi?id=8867735 Kind regards, Steve > -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: Wednesday, May 10, 2017 7:06 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: [EXT] Re: Draft further questions for Symantec > > On 08/05/17 13:24, Gervase Markham wrote: > > 8) Please explain how the Management Assertions for your December 2014 > > > Strike this question; it's based on a misunderstanding of how audits are > done. > > Let's add: > > 10) Do you agree that, during the period of time that Symantec cross-signed > the Federal PKI (Issue L), it was technically possible for issuers inside the > FPKI > to issue EV certs by inserting Symantec's EV OID? > > 11) If, in the Symantec Issues list or any other document relating to this > matter we may publish in future, we have drawn a conclusion or inference > about Symantec's PKI, actions or behaviour which is incorrect, we expect you > to draw that to our attention, even if the truth is not as favourable to > Symantec. Are there any incorrect inferences or conclusions in the Issues List > which need to be corrected? > > Gerv > ___ > 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
Questions for Symantec (2)
Dear Steve and Rick, This is an official communication from the Mozilla CA program requesting Symantec's answers to the following questions by close of business on Monday 15th May. Your answers will be posted in mozilla.dev.security.policy if you don't put them there yourselves. Your speedy attention is appreciated :-) RAs and EV -- 1) Did any of the RAs in your program (CrossCert and co.) have the technical ability to independently issue EV certificates? If they did not, given that they had issuance capability from intermediates which chained up to EV-enabled roots, what technical controls prevented them from having this capability? 2) We note that all four RAs advertised EV certificates on their websites during 2016[0]. If they did not have direct EV issuance capability, by what mechanism did they provide EV certificates to their customers, and what validation (if any) did Symantec do of data provided by the RAs? Issue Y --- 3) Does Symantec agree that "VeriSign Class 3 SSP Intermediate CA - G2" and "Symantec Class 3 SSP Intermediate CA - G3", can issue certs which are trusted for SSL/TLS in Mozilla products (by chaining up to "VeriSign Universal Root Certification Authority") and yet do not have BR audits? 4) These two intermediates have a number of sub-intermediates. Does Symantec agree that not all of these sub-intermediates are within the scope of even Symantec's NFSSP Webtrust for CAs audit?[1] If so, how many are in scope and how many are out of scope? If they are all in scope, why are they not listed in the audit document? 5) A statement from Symantec[2] suggests that customers of your NFSSP program can perform RA duties for the issuance of certs for Windows domain controllers and those RA activities are outside the scope of the audit entirely. Is that correct? Please list all companies or organizations which can issue publicly-trusted SSL/TLS certificates with no audit oversight. 6) "VeriSign Universal Root Certification Authority" is EV-enabled. Are there any mechanisms, technical or otherwise, which prevent NFSSP customers from issuing EV certs by including the Symantec EV OID? 7) Does Symantec agree that Issue Y is very serious? What are Symantec's plans to remedy this? Why have they not been communicated up to now? When will they be executed? Issue L --- 8) During the approximately five years that Symantec cross-signed the Federal PKI, thereby making any certificate within it have a path to trust in Mozilla browsers, which of the following best represented Symantec's understanding of the situation: a) Symantec didn't realise that your actions had the effect of making the entirety of the FPKI trusted in Mozilla browsers; or b) Symantec knew that your actions had the effect of making the entirety of the FPKI trusted in Mozilla browsers and didn't realise the implications for your own audits and disclosures and the WebPKI; or c) Symantec knew that your actions had the effect of making the entirety of the FPKI trusted in Mozilla browsers and did realise the implications, but didn't think it was necessary to tell Mozilla about it ? 9) Do you agree that, during the period of time that Symantec cross-signed the Federal PKI (Issue L), it was technically possible for issuers inside the FPKI to issue EV certs by inserting Symantec's EV OID? Other - 10) If, in the Symantec Issues list or any other document relating to this matter we may publish in future, we have drawn a conclusion or inference about Symantec's PKI, actions or behaviour which is incorrect, we expect you to draw that to our attention, even if the truth is not as favourable to Symantec. Are there any incorrect inferences or conclusions in the Issues List which need to be corrected? 11) As requested in an email to Steve Medin on 5th of May and noted again in an email to Quentin Liu on 10th May, please provide copies of all audits of any type relating to the Aetna and UniCredit GeoRoot intermediates. You may attach them to a Bugzilla bug or place them in another public location and provide the URL. Again, many thanks for your cooperation. Gerv [0] http://web.archive.org/web/20161223000146/http://www.crosscert.com/ http://web.archive.org/web/20160428051833/https://www.certsuperior.com/SecureSiteProEV.aspx http://web.archive.org/web/20161114232112/https://www.certisur.com/soluciones/sitios-seguros http://web.archive.org/web/2016110634/https://www.certisign.com.br/certificado-servidor/ssl-validacao-avancada [1] The following intermediates, at least, are not listed in that audit as being covered: https://crt.sh/?id=19602740 1, https://crt.sh/?id=19602709, https://crt.sh/?id=19602733 3, https://crt.sh/?id=19602720, https://crt.sh/?id=19602670 5, https://crt.sh/?id=19602679, https://crt.sh/?id=19602705 7, https://crt.sh/?id=19602730 . [2] https://bug1334377.bmoattachments.org/attachment.cgi?id=8860216 , section 2, first bullet numbered 2. [3]
Re: Draft further questions for Symantec
On 08/05/17 13:24, Gervase Markham wrote: > 8) Please explain how the Management Assertions for your December 2014 Strike this question; it's based on a misunderstanding of how audits are done. Let's add: 10) Do you agree that, during the period of time that Symantec cross-signed the Federal PKI (Issue L), it was technically possible for issuers inside the FPKI to issue EV certs by inserting Symantec's EV OID? 11) If, in the Symantec Issues list or any other document relating to this matter we may publish in future, we have drawn a conclusion or inference about Symantec's PKI, actions or behaviour which is incorrect, we expect you to draw that to our attention, even if the truth is not as favourable to Symantec. Are there any incorrect inferences or conclusions in the Issues List which need to be corrected? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Draft further questions for Symantec
In addition to requesting disclosure of intermediates that have been (even if not currently are) able to issue server certs, and the catchall, both of which seem excellent, I encourage Mozilla to consider asking these questions as part of an implemented remedy plan. That is, put in motion Mozilla's plan of action given all the information available today, but note that certain modifications are possible should Symantec provide in responses to these queries additional information Mozilla considers useful and actionable. For example, consider executing the planned phase out of all existing symantec certs by early next year, with distrust of all existing roots at that time, and a limit on new cert lifetimes of 13 months. But should symantec become a leader in reducing cert lifetimes with the stand up of a clean PKI (cf. Eric Mill's proposal), then Mozilla would strive to (a) include the new roots by next year, and (b) accept certs with lifetime of 27 months. Or, should symantec be able to verifiably demonstrate other things (e.g. a complete map of their PKI inter-relations, and all parts that are non-BR compliant and thus should be distrusted), then the old ones might not be removed. Yes, this is harder on the coders (I sympthasize), but how much longer can the current situation (and the risks it does pose *today*) go on? On Monday, May 8, 2017 at 1:08:27 PM UTC-4, richm...@gmail.com wrote: > On Monday, May 8, 2017 at 1:24:28 PM UTC+1, Gervase Markham wrote: > > I think it might be appropriate to have a further round of questions to > > Symantec from Mozilla, to try and get some clarity on some outstanding > > and concerning issues. Here are some _proposed_ questions; feel free to > > suggest modifications or other questions, and I will decide what to send > > officially to Symantec in a few days. Please focus on formulating > > questions which would have an effect on Mozilla's view of Symantec or > > our response to the recent issues. > > How about adding a catch all: > > Are you aware of any information that might have an effect on Mozilla's view > of Symantec, our response to the recent issues or any of any further issues > that have not been disclosed to us so far? > > Cheers > > Rich. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Draft further questions for Symantec
On Monday, May 8, 2017 at 1:24:28 PM UTC+1, Gervase Markham wrote: > I think it might be appropriate to have a further round of questions to > Symantec from Mozilla, to try and get some clarity on some outstanding > and concerning issues. Here are some _proposed_ questions; feel free to > suggest modifications or other questions, and I will decide what to send > officially to Symantec in a few days. Please focus on formulating > questions which would have an effect on Mozilla's view of Symantec or > our response to the recent issues. How about adding a catch all: Are you aware of any information that might have an effect on Mozilla's view of Symantec, our response to the recent issues or any of any further issues that have not been disclosed to us so far? Cheers Rich. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Draft further questions for Symantec
It may be necessary to expand that definition to intermediates that were capable of issuing certificates within the past year (or longer). On Monday, May 8, 2017 at 9:31:21 AM UTC-4, Alex Gaynor wrote: > I'm not the best way to phrase this, so please forgive the bluntness, but I > think it'd be appropriate to ask at this point if Symantec has disclosed > all necessary intermediates (I believe this would be defined as: chain to > their roots in our trust store, are not expired, are not revoked, and are > not technically constrained), and would they be willing to state that if > new intermediate CAs are discovered beyond that point, it would reflect > either dishonesty or serious mismanagement of their PKI. > > Alex > > > On Mon, May 8, 2017 at 9:20 AM, Kurt Roeckx via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On 2017-05-08 14:24, Gervase Markham wrote: > > > >> > >> 1) Did any of the RAs in your program (CrossCert and co.) have the > >> technical ability to independently issue EV certificates? If they did > >> not not, given that they had issuance capability from intermediates > >> which chained up to EV-enabled roots, what technical controls prevented > >> them from having this capability? > >> > > > > It has a duplicate "not" there. > > > > Issue Y > >> --- > >> > >> 3) Does Symantec agree that "VeriSign Class 3 SSP Intermediate CA - G2" > >> and "Symantec Class 3 SSP Intermediate CA - G3", can issue certs which > >> are trusted for SSL/TLS in Mozilla products (by chaining up to "VeriSign > >> Universal Root Certification Authority") and yet do not have BR audits? > >> > > > > I'm wondering if the intermediate CA certificates recently published in CT > > should have it's own issue. As far as I know they should have been > > disclosed much earlier. It seems that (at least now) they're all either > > revoked by CRL on the 5th of May (but not disclosed as revoked) or expired > > except for one (https://crt.sh/?id=132854209). > > > > I think they're all from "VeriSign Class 3 SSP Intermediate CA", not G2 or > > G3, except that one that's not revoked. > > > > 4) These two intermediates have a number of sub-intermediates. Does > >> Symantec agree that not all of these sub-intermediates are within the > >> scope of even Symantec's NFSSP Webtrust for CAs audit?[1] If so, how > >> many are in scope and how many are out of scope? If they are all in > >> scope, why are they not listed in the audit document? > >> > > > > The audit document says: "and the Symantec Non-Federal SSP – customer > > specific CAs (collectively referred to as the “Non-Federal SSP CAs”)." > > > > For which it then says that "our examination did not extend to the > > controls of external registration authorities." > > > > The management assertion also says: > > "Controls have inherent limitations, including the possibility of human > > error and the circumvention or overriding of controls. Accordingly, even > > effective controls can provide only reasonable assurance with respect to > > Symantec’s Non-Federal SSP CA operations. Furthermore, because of changes > > in conditions, the effectiveness of controls may vary over time." > > > > > > Kurt > > > > > > ___ > > 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: Draft further questions for Symantec
Thanks Kurt. Alex On Mon, May 8, 2017 at 11:22 AM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 2017-05-08 15:31, Alex Gaynor wrote: > >> I'm not the best way to phrase this, so please forgive the bluntness, but >> I >> think it'd be appropriate to ask at this point if Symantec has disclosed >> all necessary intermediates (I believe this would be defined as: chain to >> their roots in our trust store, are not expired, are not revoked, and are >> not technically constrained), and would they be willing to state that if >> new intermediate CAs are discovered beyond that point, it would reflect >> either dishonesty or serious mismanagement of their PKI. >> > > This was part of the March 2016 action 2. In > https://mozillacaprogram.secure.force.com/Communications/CAC > ommResponsesOnlyReport?CommunicationId=a05o00iHdtx=Q4 > you can see that their response was "2016 Apr 18" > > And confirmed in the April 2017 response to action 8, see: > https://mozillacaprogram.secure.force.com/Communications/CAC > ommRespWithTextAndTotalsReport?CommunicationId=a05o03Wrz > BC=Q00020=Q00026 > > > > Kurt > > ___ > 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: Draft further questions for Symantec
I'm not the best way to phrase this, so please forgive the bluntness, but I think it'd be appropriate to ask at this point if Symantec has disclosed all necessary intermediates (I believe this would be defined as: chain to their roots in our trust store, are not expired, are not revoked, and are not technically constrained), and would they be willing to state that if new intermediate CAs are discovered beyond that point, it would reflect either dishonesty or serious mismanagement of their PKI. Alex On Mon, May 8, 2017 at 9:20 AM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 2017-05-08 14:24, Gervase Markham wrote: > >> >> 1) Did any of the RAs in your program (CrossCert and co.) have the >> technical ability to independently issue EV certificates? If they did >> not not, given that they had issuance capability from intermediates >> which chained up to EV-enabled roots, what technical controls prevented >> them from having this capability? >> > > It has a duplicate "not" there. > > Issue Y >> --- >> >> 3) Does Symantec agree that "VeriSign Class 3 SSP Intermediate CA - G2" >> and "Symantec Class 3 SSP Intermediate CA - G3", can issue certs which >> are trusted for SSL/TLS in Mozilla products (by chaining up to "VeriSign >> Universal Root Certification Authority") and yet do not have BR audits? >> > > I'm wondering if the intermediate CA certificates recently published in CT > should have it's own issue. As far as I know they should have been > disclosed much earlier. It seems that (at least now) they're all either > revoked by CRL on the 5th of May (but not disclosed as revoked) or expired > except for one (https://crt.sh/?id=132854209). > > I think they're all from "VeriSign Class 3 SSP Intermediate CA", not G2 or > G3, except that one that's not revoked. > > 4) These two intermediates have a number of sub-intermediates. Does >> Symantec agree that not all of these sub-intermediates are within the >> scope of even Symantec's NFSSP Webtrust for CAs audit?[1] If so, how >> many are in scope and how many are out of scope? If they are all in >> scope, why are they not listed in the audit document? >> > > The audit document says: "and the Symantec Non-Federal SSP – customer > specific CAs (collectively referred to as the “Non-Federal SSP CAs”)." > > For which it then says that "our examination did not extend to the > controls of external registration authorities." > > The management assertion also says: > "Controls have inherent limitations, including the possibility of human > error and the circumvention or overriding of controls. Accordingly, even > effective controls can provide only reasonable assurance with respect to > Symantec’s Non-Federal SSP CA operations. Furthermore, because of changes > in conditions, the effectiveness of controls may vary over time." > > > Kurt > > > ___ > 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: Draft further questions for Symantec
On 2017-05-08 14:24, Gervase Markham wrote: 1) Did any of the RAs in your program (CrossCert and co.) have the technical ability to independently issue EV certificates? If they did not not, given that they had issuance capability from intermediates which chained up to EV-enabled roots, what technical controls prevented them from having this capability? It has a duplicate "not" there. Issue Y --- 3) Does Symantec agree that "VeriSign Class 3 SSP Intermediate CA - G2" and "Symantec Class 3 SSP Intermediate CA - G3", can issue certs which are trusted for SSL/TLS in Mozilla products (by chaining up to "VeriSign Universal Root Certification Authority") and yet do not have BR audits? I'm wondering if the intermediate CA certificates recently published in CT should have it's own issue. As far as I know they should have been disclosed much earlier. It seems that (at least now) they're all either revoked by CRL on the 5th of May (but not disclosed as revoked) or expired except for one (https://crt.sh/?id=132854209). I think they're all from "VeriSign Class 3 SSP Intermediate CA", not G2 or G3, except that one that's not revoked. 4) These two intermediates have a number of sub-intermediates. Does Symantec agree that not all of these sub-intermediates are within the scope of even Symantec's NFSSP Webtrust for CAs audit?[1] If so, how many are in scope and how many are out of scope? If they are all in scope, why are they not listed in the audit document? The audit document says: "and the Symantec Non-Federal SSP – customer specific CAs (collectively referred to as the “Non-Federal SSP CAs”)." For which it then says that "our examination did not extend to the controls of external registration authorities." The management assertion also says: "Controls have inherent limitations, including the possibility of human error and the circumvention or overriding of controls. Accordingly, even effective controls can provide only reasonable assurance with respect to Symantec’s Non-Federal SSP CA operations. Furthermore, because of changes in conditions, the effectiveness of controls may vary over time." Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Draft further questions for Symantec
I think it might be appropriate to have a further round of questions to
Symantec from Mozilla, to try and get some clarity on some outstanding
and concerning issues. Here are some _proposed_ questions; feel free to
suggest modifications or other questions, and I will decide what to send
officially to Symantec in a few days. Please focus on formulating
questions which would have an effect on Mozilla's view of Symantec or
our response to the recent issues.
RAs and EV
--
1) Did any of the RAs in your program (CrossCert and co.) have the
technical ability to independently issue EV certificates? If they did
not not, given that they had issuance capability from intermediates
which chained up to EV-enabled roots, what technical controls prevented
them from having this capability?
2) We note that all four RAs advertised EV certificates on their
websites during 2016[0]. If they did not have direct EV issuance
capability, by what mechanism did they provide EV certificates to their
customers, and what validation (if any) did Symantec do of data provided
by the RAs?
Issue Y
---
3) Does Symantec agree that "VeriSign Class 3 SSP Intermediate CA - G2"
and "Symantec Class 3 SSP Intermediate CA - G3", can issue certs which
are trusted for SSL/TLS in Mozilla products (by chaining up to "VeriSign
Universal Root Certification Authority") and yet do not have BR audits?
4) These two intermediates have a number of sub-intermediates. Does
Symantec agree that not all of these sub-intermediates are within the
scope of even Symantec's NFSSP Webtrust for CAs audit?[1] If so, how
many are in scope and how many are out of scope? If they are all in
scope, why are they not listed in the audit document?
5) A statement from Symantec[2] suggests that customers of your NFSSP
program can perform RA duties for the issuance of certs for Windows
domain controllers and those RA activities are outside the scope of the
audit entirely. Is that correct? Please list all companies or
organizations which can issue publicly-trusted SSL/TLS certificates with
no audit oversight.
6) "VeriSign Universal Root Certification Authority" is EV-enabled. Are
there any mechanisms, technical or otherwise, which prevent NFSSP
customers from issuing EV certs by including the Symantec EV OID?
7) Does Symantec agree that Issue Y is very serious? What are Symantec's
plans to remedy this? Why have they not been communicated up to now?
When will they be executed?
Audits
--
8) Please explain how the Management Assertions for your December 2014
-> November 2015 audits contain documentation of issues ("Failure to
maintain physical security records for 7 years", "Failure to review
application and system logs" and "failure to refresh background checks
every 5 years") that, according to you, were only discovered in January
or February 2016[3]. Is it not the case that you submit Management
Assertions to your auditor and they then opine upon the correctness of
those assertions? What is the "last change date" of those management
assertions? What point in the audit cycle does that date correspond to?
Issue L
---
9) During the approximately five years that Symantec cross-signed the
Federal PKI, thereby making any certificate within it have a path to
trust in Mozilla browsers, which of the following best represented
Symantec's understanding of the situation:
a) Symantec didn't realise that your actions had the effect of making
the entirety of the FPKI trusted in Mozilla browsers; or
b) Symantec knew that your actions had the effect of making the entirety
of the FPKI trusted in Mozilla browsers and didn't realise the
implications for your own audits and disclosures and the WebPKI; or
c) Symantec knew that your actions had the effect of making the entirety
of the FPKI trusted in Mozilla browsers and did realise the
implications, but didn't think it was necessary to tell Mozilla about it
?
Gerv
[0] http://web.archive.org/web/20161223000146/http://www.crosscert.com/
http://web.archive.org/web/20160428051833/https://www.certsuperior.com/SecureSiteProEV.aspx
http://web.archive.org/web/20161114232112/https://www.certisur.com/soluciones/sitios-seguros
http://web.archive.org/web/2016110634/https://www.certisign.com.br/certificado-servidor/ssl-validacao-avancada
[1] The following intermediates, at least, are not listed in that audit
as being covered: https://crt.sh/?id=19602740 1,
https://crt.sh/?id=19602709, https://crt.sh/?id=19602733 3,
https://crt.sh/?id=19602720, https://crt.sh/?id=19602670 5,
https://crt.sh/?id=19602679, https://crt.sh/?id=19602705 7,
https://crt.sh/?id=19602730 .
[2] https://bug1334377.bmoattachments.org/attachment.cgi?id=8860216 ,
section 2, first bullet numbered 2.
[3] https://bug1334377.bmoattachments.org/attachment.cgi?id=8860216 ,
section 5.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: [EXT] Re: Questions for Symantec
On Thu, Apr 27, 2017 at 6:50 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 21/04/17 18:19, Eric Mill wrote: > > The FPKI cross-signs at issue in Issue L are now expired (and so don't > show > > on the links above). They do show when expired certificates are included > -- > > there are 6 of them with OU=FPKI: > > https://crt.sh/?Identity=%25=1384 > > > > Each of those certificates lack a pathlen:0 constraint, and appear to be > > the only ones that do. Symantec noted that they are path length > constrained > > in their response, but since they also referenced Federal PKI policy OIDs > > (which are not respected by Web PKI clients), I thought it was worth > being > > explicit about the difference between the certificates referenced here > and > > those referenced in Issue L. > > In other words, the FPKI cross-signs weren't path length constrained and > so promulgated trust from the entire FPKI, but the Issue Y intermediates > are constrained and so the impact is less? > Depends on what you mean the impact being less? They were both "unaudited", unconstrained sub-CAs, the only difference is whether they could be used to issue new sub-CAs. But given the controls - and importantly, the capabilities which have been acknowledged with Issue Y regarding domain controllers - it's still virtually unlimited impact by arbitrary parties. However, it does mean you don't have the full FPKI in scope. However, that feels a bit like saying the unconstrained sub-CA was expired by the time the public discussion began, and thus the impact was less. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [EXT] Re: Questions for Symantec
On 21/04/17 18:19, Eric Mill wrote: > The FPKI cross-signs at issue in Issue L are now expired (and so don't show > on the links above). They do show when expired certificates are included -- > there are 6 of them with OU=FPKI: > https://crt.sh/?Identity=%25=1384 > > Each of those certificates lack a pathlen:0 constraint, and appear to be > the only ones that do. Symantec noted that they are path length constrained > in their response, but since they also referenced Federal PKI policy OIDs > (which are not respected by Web PKI clients), I thought it was worth being > explicit about the difference between the certificates referenced here and > those referenced in Issue L. In other words, the FPKI cross-signs weren't path length constrained and so promulgated trust from the entire FPKI, but the Issue Y intermediates are constrained and so the impact is less? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [EXT] Re: Questions for Symantec
On Thu, Apr 20, 2017 at 8:04 PM, Steve Medin via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > -Original Message- > > On 03/04/17 13:11, Gervase Markham wrote: > > > Hi Steve and Rick, > > > > Q9) Can you please tell us which audit covers the following two > intermediate > > CAs, which are subordinates of or cross-certified by VeriSign Universal > Root > > Certification Authority? > > These Intermediate CAs are sub-CAs under the Verisign Universal Root CA. > They are covered under Symantec’s Non-Fed SSP audits, and the latest > unqualified audits that we just received are being published. > > The customer-specific CAs (the subordinate ICAs) signed by these sub-CAs > are path length constrained and operate fully within Symantec’s > infrastructure. Under the Non-Federal SSP program, they are used to issue > certificates for Microsoft Windows domain controllers and IPSec endpoints. > End entity certificates issued under this program are designed only to > contain Federal PKI policy OIDs and to exclude any CA/B Forum required > policy OIDs. > For reference, the two links Gerv referenced were for unexpired certificates issued by these two sub-CAs: https://crt.sh/?Identity=%25=1384=expired https://crt.sh/?Identity=%25=12352=expired "pathlen:0" displays on crt.sh as a basic constraint for all certificates listed there. The FPKI cross-signs at issue in Issue L are now expired (and so don't show on the links above). They do show when expired certificates are included -- there are 6 of them with OU=FPKI: https://crt.sh/?Identity=%25=1384 Each of those certificates lack a pathlen:0 constraint, and appear to be the only ones that do. Symantec noted that they are path length constrained in their response, but since they also referenced Federal PKI policy OIDs (which are not respected by Web PKI clients), I thought it was worth being explicit about the difference between the certificates referenced here and those referenced in Issue L. -- Eric ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: [EXT] Re: Questions for Symantec
> -Original Message- > From: Gervase Markham [mailto:g...@mozilla.org] > Sent: Tuesday, April 11, 2017 6:42 AM > To: Steve Medin <steve_me...@symantec.com>; Rick Andrews > <rick_andr...@symantec.com>; mozilla-dev-security- > pol...@lists.mozilla.org > Subject: [EXT] Re: Questions for Symantec > > Hi Steve and Rick, > > Just to confirm: even after reviewing your extensive responses to the issues > list, I feel that all the 8 questions on my questions list are still > outstanding and > require answers. > > Thanks :-) > > Gerv Answer 1: A. See Symantec response for Issue V [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/Ga1bfOiJr70]. B. This was a continuation of the first paragraph, referring to Intel, Aetna, Unicredit, Google, & Apple. See issue V. C. For both the RA program and the GeoRoot program clarified in Issue V, KPMG focused on our receipt of audit reports from these third parties, continuity from previous periods, the audit opinions, and in the cases where there were issues identified, Symantec’s plan of action to remediate. In this case, Symantec and KPMG failed to note that we were missing some of the required audits. Answer 2: The start dates of our SSL/TLS RA partnerships are all prior to 2010 when Symantec acquired the Trust Services business from VeriSign and prior to the BRs going into effect. During the period of 2011-2014 we significantly reduced the number of these RA partners that could issue SSL/TLS certificates and restricted all but CrossCert, Certisur, Certisign, and CertSuperior to perform validation for SSL/TLS certificates. We imposed technical measures to prevent all SSL/TLS validation and issuance capabilities by all RA’s except for these four partners, In 2017 we took the additional step of removing the ability of these remaining four partners to issue SSL/TLS certificates which represented a complete wind-down of the SSL/TLS RA program. See Item W for more details of the RA program: [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/Ga1bfOiJr70]. The following affiliates operated as an RA for Symantec SSL/TLS certificates, conducting authentication and issuance activities. This list does not include additional partners who had been terminated prior to the acquisition of the Trust Services business from VeriSign, Inc. in August 2010 as there are no unexpired certificates issued by these former partners. The end date referenced below is the date of the last SSL/TLS authentication event by the affiliate within a customer’s Enterprise RA account. As of April 19, 2017 all certificates counted below were certificates issued out of domain-constrained Enterprise RA accounts originally authenticated by the affiliate. Numbers represent still active certificates issued using the authentication work by the affiliate. That issuance, subsequent to the affiliate SSL/TLS termination, has been possible leveraging the 39-month data validity rule for OV/DV certificates. End date in 2017: Audits at https://bugzilla.mozilla.org/show_bug.cgi?id=1334377 CrossCert End date: January 19, 2017 Active certificates: 10,603 CertSuperior End date: April 4, 2017 Active certificates: 4,430 CertiSign End date: April 11, 2017 Active certificates: 13,521 CertiSur End date: April 14, 2017 Active certificates: 2,935 - End date between 2011 - 2014: These RA for SSL/TLS relationships were wound down as the BR’s went into effect. We do not have audits for them. Note, while no longer authorized as affiliate RAs for SSL/TLS, many of these partners continue to offer SSL/TLS for sale as Symantec resellers. Adacom S.A. End date: November 15, 2012 Active certificates: 2 Comsign, Ltd End date: February 14, 2013 Active certificates: 15 e-Sign S.A. End date: March 4, 2013 Active certificates: 16 iTrusChina End date: January 11, 2013 Active certificates: 52 NamITech End date: November 7, 2012 Active certificates: 167 Telefonica S.A. End date: February 5, 2014 Active certificates: 88 * Note, in our response on issue T indicated that the RA program for SSL/TLS was wound down in 2013. That should have stated 2014 to reflect Telefonica. MSC Trustgate.com Sdn Bhd End date: February 8, 2013 No active certificates mySecureSign, Inc. End date: August 22, 2011 No active certificates Safescrypt Ltd End date: June 25, 2012 No active certificates NIFTeTrust End date: September 6, 2013 No active certificates With the exception of Telefonica, all previous org/domain validation data is now outside of the 39 month rule. In the case of Telefonica, we are disabling use of previously validated org/domain information otherwise still valid under the 39 month rule. After this update Symantec will solely authenticate new certificate issuance for all of these customer accounts originally authenticated by these partners. There were also questions
RE: [EXT] Re: Questions for Symantec
> -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: Tuesday, April 04, 2017 9:06 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: [EXT] Re: Questions for Symantec > > On 03/04/17 13:11, Gervase Markham wrote: > > Hi Steve and Rick, > > Q8) The accountant's letters for the 2015-2016 audits are dated February 28th > 2017. The audits were supplied to Mozilla, and published, on the 1st of April > 2017. Why the delay? > > Gerv Proofreading of the reports, corrections, and clarifications took an additional four weeks. KPMG provided an explanation of the delay in their explanatory letter which has been provided, and which centered on the large scope and resulting sheer volume of audits. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: [EXT] Re: Questions for Symantec
> -Original Message- > From: Gervase Markham [mailto:g...@mozilla.org] > Sent: Thursday, April 13, 2017 9:13 AM > To: Steve Medin <steve_me...@symantec.com>; Rick Andrews > <rick_andr...@symantec.com>; mozilla-dev-security- > pol...@lists.mozilla.org > Subject: [EXT] Re: Questions for Symantec > > On 03/04/17 13:11, Gervase Markham wrote: > > Hi Steve and Rick, > > Q9) Can you please tell us which audit covers the following two intermediate > CAs, which are subordinates of or cross-certified by VeriSign Universal Root > Certification Authority? > These Intermediate CAs are sub-CAs under the Verisign Universal Root CA. They are covered under Symantec’s Non-Fed SSP audits, and the latest unqualified audits that we just received are being published. The customer-specific CAs (the subordinate ICAs) signed by these sub-CAs are path length constrained and operate fully within Symantec’s infrastructure. Under the Non-Federal SSP program, they are used to issue certificates for Microsoft Windows domain controllers and IPSec endpoints. End entity certificates issued under this program are designed only to contain Federal PKI policy OIDs and to exclude any CA/B Forum required policy OIDs. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: [EXT] Re: Questions for Symantec
Gerv, In the interest of an easy to read set of responses to your questions and many submitted in response to our recent posts, we have prepared a PDF and attached it to the Bugzilla tracking this discussion. That PDF is available at https://bugzilla.mozilla.org/attachment.cgi?id=8860216. > -Original Message- > From: Gervase Markham [mailto:g...@mozilla.org] > Sent: Thursday, April 13, 2017 9:13 AM > To: Steve Medin <steve_me...@symantec.com>; Rick Andrews > <rick_andr...@symantec.com>; mozilla-dev-security- > pol...@lists.mozilla.org > Subject: [EXT] Re: Questions for Symantec > > On 03/04/17 13:11, Gervase Markham wrote: > > Hi Steve and Rick, > > Q9) Can you please tell us which audit covers the following two intermediate > CAs, which are subordinates of or cross-certified by VeriSign Universal Root > Certification Authority? > > VeriSign Class 3 SSP Intermediate CA - G2 > > Symantec Class 3 SSP Intermediate CA - G3 > > > The following period-of-time audit is the most recent one which covers the > VeriSign Universal Root Certification Authority: > https://www.symantec.com/content/en/us/about/media/repository/18_Sy > mantec_STN_WTCA_period_end_11-30-2016.pdf > However, these certificates are not on the accompanying list of > intermediates. > > Is it correct that these intermediates are unconstrained and fully capable of > issuing server authentication (SSL/TLS) certificates which are trusted by > Mozilla browsers? > > Thanks, > > Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Questions for Symantec
Hi Steve and Rick, Just to confirm: even after reviewing your extensive responses to the issues list, I feel that all the 8 questions on my questions list are still outstanding and require answers. Thanks :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Questions for Symantec
On 03/04/17 13:11, Gervase Markham wrote: > Hi Steve and Rick, Q8) The accountant's letters for the 2015-2016 audits are dated February 28th 2017. The audits were supplied to Mozilla, and published, on the 1st of April 2017. Why the delay? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Questions for Symantec
Hi Steve and Rick, You have told me that you are considering your response(s) to the Symantec issues list, which is fine. Based on the list and further discussions which have been happening in m.d.s.policy, and on your recent audit publication, I thought it would be helpful to give a few specific questions that we are seeking answers to. (This should in no way be seen as trying to limit what else Symantec may wish to say.) It would be most convenient if you were to post the answers as a reply message in m.d.s.policy. Q1) Symantec's audit for 2014-2015: https://www.symantec.com/content/en/us/about/media/repository/GeoTrust-WTBR-2015.pdf says on page 11: "We noted that audit reports were not obtained during the examination period for 2 of 5 external partner subordinate CAs signed by the GeoTrust Global CA and managed by contracted third parties as part of the GeoRoot service). In addition, the report obtained for 1 of 5 external partner subordinate CAs was not in accordance with permitted audit schemes. Furthermore, in lieu of third party audits completed by delegated third parties, no out-of-band mechanisms were used to confirm the authenticity of the certificate requests, or the information supporting the certificate and internal reviews were not performed by Symantec to determine third party compliance with baseline requirements. For the 2 external partners where reports were not obtained during the examination period, one external partner’s subordinate CA has since expired and Symantec subsequently received an audit report for the other. For the other external partner, Symantec reviewed the report obtained and requested that their next report be in accordance with permitted audit schemes." A) Can you please identify all of the companies referenced here, by putting names to each reference? B) When the second paragraph, beginning "Furthermore", refers to "delegated third parties", does it mean the same five subordinate CAs as the first paragraph, or does it refer to the RA program that you recently shut down? C) If it refers to the same subordinate CAs, can you explain how the RA audits for CrossCert, Certisign, Certsuperior, and Certisur featured in the 2014-2015 auditing process? Where they examined by KPMG? Q2) Please give the names of all companies who have been in your RA program recently enough that there still exist unexpired certificates which were issued by them, and their start and end dates in the program. Although we have had some of this information before, for completeness please provide links to all audits for each company. Q3) Please give the names of all companies who have been in your GeoRoot program recently enough that there still exist unexpired certificates which were issued by them, and their start and end dates in the program. Please provide links to all audits for each company. Q4) Are there any other programs Symantec runs or has run in the past five years, other than the recently-terminated RA program and the GeoRoot program, which puts either the power of domain ownership validation or the power of certificate issuance in the hands of an organization other than Symantec or its Affiliates? If so, please give details of the program, and lists of companies, dates and any applicable audits as outlined above. Q5) You have recently released your 2016 audits, split into two parts at June 16th (6.5 months into the 12-month period). The audits for the first six months contain almost all of the qualifications that the 2015 audits have. Please can you give exact or approximate dates for "start of issue", "discovery of issue" and "problem fixed/ceased" for each of the following issues which led to a qualification: A) Test certificates issued for domains Symantec did not own or control B) Failure to maintain physical security records for 7 years C) Unauthorized employees with access to certificate issuance capability D) Failure to review application and system logs E) Background checks not renewed for trusted personnel after 5 years Q6) The management assertions in the audits for neither the first-half nor the second-half of 2016 contain any qualification related to the audit status of either your GeoRoot or RA program partners. Does this indicate that Symantec felt that all partners in these programs were in good standing audit-wise during the period from December 1st 2015 to November 31st 2016? Q7) In your comments at the time on what is now labelled Issue D, the misissuance of test certificates, you wrote: "First, we continued to issue internal test certificates to unregistered domains after the April 2014 change in the Baseline Requirements that removed authorization to do so." By "the April 2014 change", do you mean by ballot 112? https://cabforum.org/2014/04/03/ballot-112-replace-definition-internal-server-name-internal-name/ If so, can you explain how you see this ballot as affecting the correctness or otherwise of issuing certificate for
