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
