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

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

End date: January 19, 2017
Active certificates: 10,603

End date: April 4, 2017
Active certificates: 4,430

End date: April 11, 2017
Active certificates: 13,521

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

End date: January 11, 2013 
Active certificates: 52

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

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 regarding issuance controls on RA certificates. In 
our infrastructure there are a few different cases:

For Publicly Trusted Class 3 CAs: These include CAs that can be used for 
multiple purposes, including server authentication, as defined in our CPS.

1. With the exception of the GeoRoot CAs, all Class 3 CAs and sub-CAs are 
operated out of Symantec controlled infrastructure.
2. 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). 
3. The GeoRoot sub-CAs operated by Google and Apple are fully controlled by 
those organizations and audited.

For Publicly Trusted Class 1 & 2 CAs: These include CAs that can be used for 
multiple purposes, excluding server authentication, as defined in our CPS. 

1. Class 1 & 2 sub-CAs are operated out of Symantec’s infrastructure, and 
separately out of (non-TLS) RA infrastructure using software provided by 
2. Symantec limits issuance of public TLS server authentication certificates 
chaining to Class 1 & 2 CAs through both its own software configuration and 
(non-TLS) RA software configuration.
3. Symantec authorizes (non-TLS) RAs to have access to publicly trusted sub-CAs 
dedicated exclusively to their use, compartmentalizing each affiliate. These 
are only signed by Class 1 & 2 Symantec sub-CAs that chain up to Class 1 & 2 
4. Browser vendors control the trust bits assigned to roots. We have verified 
in the cases of Microsoft and Mozilla that those controls do not grant server 
authentication trust for our public Class 1 and Class 2 roots or any sub-CAs 
operated under them, in accordance with our CPS.

In addition to the actions we have already taken, we are currently conducting a 
thorough review of the non-TLS RA program.

Answer 3:

Apple and Google are the only remaining active GeoRoot program partners. Audit 
information for both are accessible via the Mozilla Common CA Database.

Intel, Aetna, and Unicredit CAs have all expired or been revoked.

Answer 4:

There are no other such programs related to SSL/TLS issuance nor third parties 
in the RA and GeoRoot programs that have not been previously disclosed. For 
clarity, NTT DoCoMo is covered under the scope of Symantec’s WTCA & WTBR 
audits, as stated in issue V. As stated in issue X, Symantec operates an RA 
program for non-SSL/TLS certificates.

Answer 5:

A1. For test certificates to registered domains: 
Start of issue: Jan 2, 2009 
Discovery of issue: Sep 16, 2015 [Externally reported]
Problem ceased (last issuance): Sep 15, 2015 
Problem fixed: (last revocation of all identified related certs): Mar 16, 2016

While inappropriate use of registered domains for testing stopped during the 
course of our 2014-2015 audits, we did not complete the ID and revocation of 
all certificates until Mar 2016, and so the finding remained in our first-half 
Dec 1, 2015-Jun 15, 2016 audits.

A2. For test certificates to un-registered domains: 
Start of issue: Apr 14, 2009 
Discovery of issue: Approximately Oct 2015 during test certificate investigation
Problem ceased (last issuance): Oct 6, 2015 
Discovery of additional instance involving approved domains in a test account 
resulting in 6 additional issued certificates: Approximately Mar 2016
Problem ceased (last issuance): Mar 7, 2016 
Problem fixed: (last revocation of all identified related certs): Mar 16, 2016

B. Failure to maintain physical security records for 7 years started in 
September 2015. It was identified and immediately corrected in January 2016.

C. The test tool referred to in our 2015 test certificate disclosures was 
created in 2006. We identified the issue with use of that tool outside of its 
intended purpose on September 16, 2015, and it was remediated in October 2015. 
Over the following months, we conducted a comprehensive review of access 
privileges across systems and put in place enhanced monitoring. During the 
course of that work, we addressed any cases where we determined that the 
principle of least privilege was not fully enforced. That work was completed in 
June 2016. 

D. Failure to review application and system logs started in Sep 2015. It was 
identified and immediately resolved in Jan 2016.

E. The failure to refresh background checks every 5 years began in Oct 2015. We 
identified this issue in Feb 2016 and fully remediated it by June 2016. The 
approximately 4-month remediation involved working within local government 
regulations and HR guidelines in each of our locations, and reorganizing the 
internal teams responsible for this work. 

Answer 6:

No, as we shared in our response to issue V, we acknowledge there were 
deficiencies in audits for both the GeoRoot and RA programs. The plan for the 
GeoRoot deficiencies was communicated in the cover letter accompanying our 
Point in Time audit (see issue V) and for the RA program, in the cover letter 
to browsers with our 2015-2016 audits: 

Answer 7:

Yes. That change struck the parenthetical “(which may or may not include an 
Unregistered Domain Name).” The term UDN is not referenced in any other part of 
the BR. For clarity, our disclosure of mis-issued test certificates was based 
on the following:

1. Any EV test certificates ever issued to unregistered domains, and 
2. Any OV/DV test certificates issued after April 3, 2014 (the effective date 
of BR version 1.1.7, incorporating ballot 112).

Answers to questions 8 and 9 were attached to their respective messages.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

dev-security-policy mailing list

Reply via email to