Questions for Symantec

[Gervase Markham]

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 unregistered domains?

Many thanks for your time and attention,

Gerv

[Gervase Markham]

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

[Gervase Markham]

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

[Gervase Markham]

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
(https://crt.sh/?Identity=%25&iCAID=1384&exclude=expired)
Symantec Class 3 SSP Intermediate CA - G3
(https://crt.sh/?Identity=%25&iCAID=12352&exclude=expired)

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

[Steve Medin]

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:ge...@mozilla.org]
> Sent: Thursday, April 13, 2017 9:13 AM
> To: Steve Medin <Steve...@symantec.com>; Rick Andrews
> <Rick_A...@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
>
>

[Steve Medin]

> -----Original Message-----
> From: Gervase Markham [mailto:ge...@mozilla.org]
> Sent: Thursday, April 13, 2017 9:13 AM
> To: Steve Medin <Steve...@symantec.com>; Rick Andrews
> <Rick_A...@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.

[Steve Medin]

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symant...@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Tuesday, April 04, 2017 9:06 AM
> To: mozilla-dev-s...@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.

[Steve Medin]

> -----Original Message-----
> From: Gervase Markham [mailto:ge...@mozilla.org]
> Sent: Tuesday, April 11, 2017 6:42 AM
> To: Steve Medin <Steve...@symantec.com>; Rick Andrews
> <Rick_A...@symantec.com>; mozilla-dev-security-
> pol...@lists.mozilla.org

> Subject: [EXT] Re: Questions for Symantec
>

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 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 Symantec.
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 roots.
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:
https://www.symantec.com/about/legal/repository.jsp?tab=Tab3

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.

[Eric Mill]

On Thu, Apr 20, 2017 at 8:04 PM, Steve Medin via dev-security-policy <
dev-secur...@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&iCAID=1384&exclude=expired
https://crt.sh/?Identity=%25&iCAID=12352&exclude=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&iCAID=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

[Gervase Markham]

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&iCAID=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

[Ryan Sleevi]

On Thu, Apr 27, 2017 at 6:50 AM, Gervase Markham via dev-security-policy <
dev-secur...@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&iCAID=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.