Re: [EXT] Re: Questions for Symantec

2017-04-27 Thread Ryan Sleevi via dev-security-policy
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

2017-04-27 Thread Gervase Markham via dev-security-policy
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

2017-04-21 Thread Eric Mill via dev-security-policy
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

2017-04-20 Thread Steve Medin via dev-security-policy

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

2017-04-20 Thread Steve Medin via dev-security-policy

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: 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

2017-04-20 Thread Steve Medin via dev-security-policy

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

2017-04-20 Thread Steve Medin via dev-security-policy
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