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/20161101111634/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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
