Draft further questions for Symantec

[Gervase Markham]

I think it might be appropriate to have a further round of questions to
Symantec from Mozilla, to try and get some clarity on some outstanding
and concerning issues. Here are some _proposed_ questions; feel free to
suggest modifications or other questions, and I will decide what to send
officially to Symantec in a few days. Please focus on formulating
questions which would have an effect on Mozilla's view of Symantec or
our response to the recent issues.

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

Audits
------

8) Please explain how the Management Assertions for your December 2014
-> November 2015 audits contain documentation of issues ("Failure to
maintain physical security records for 7 years", "Failure to review
application and system logs" and "failure to refresh background checks
every 5 years") that, according to you, were only discovered in January
or February 2016[3]. Is it not the case that you submit Management
Assertions to your auditor and they then opine upon the correctness of
those assertions? What is the "last change date" of those management
assertions? What point in the audit cycle does that date correspond to?

Issue L
-------

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

?


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.

[Kurt Roeckx]

On 2017-05-08 14:24, Gervase Markham wrote:
>
> 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 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?

It has a duplicate "not" there.

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

I'm wondering if the intermediate CA certificates recently published in
CT should have it's own issue. As far as I know they should have been
disclosed much earlier. It seems that (at least now) they're all either
revoked by CRL on the 5th of May (but not disclosed as revoked) or
expired except for one (https://crt.sh/?id=132854209).

I think they're all from "VeriSign Class 3 SSP Intermediate CA", not G2
or G3, except that one that's not revoked.

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

The audit document says: "and the Symantec Non-Federal SSP – customer
specific CAs (collectively referred to as the “Non-Federal SSP CAs”)."

For which it then says that "our examination did not extend to the
controls of external registration authorities."

The management assertion also says:
"Controls have inherent limitations, including the possibility of human
error and the circumvention or overriding of controls. Accordingly, even
effective controls can provide only reasonable assurance with respect
to Symantec’s Non-Federal SSP CA operations. Furthermore, because of
changes in conditions, the effectiveness of controls may vary over time."


Kurt

[Alex Gaynor]

I'm not the best way to phrase this, so please forgive the bluntness, but I
think it'd be appropriate to ask at this point if Symantec has disclosed
all necessary intermediates (I believe this would be defined as: chain to
their roots in our trust store, are not expired, are not revoked, and are
not technically constrained), and would they be willing to state that if
new intermediate CAs are discovered beyond that point, it would reflect
either dishonesty or serious mismanagement of their PKI.

Alex

On Mon, May 8, 2017 at 9:20 AM, Kurt Roeckx via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 2017-05-08 14:24, Gervase Markham wrote:
>
>>

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

> It has a duplicate "not" there.
>

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

> I'm wondering if the intermediate CA certificates recently published in CT
> should have it's own issue. As far as I know they should have been
> disclosed much earlier. It seems that (at least now) they're all either
> revoked by CRL on the 5th of May (but not disclosed as revoked) or expired
> except for one (https://crt.sh/?id=132854209).
>
> I think they're all from "VeriSign Class 3 SSP Intermediate CA", not G2 or
> G3, except that one that's not revoked.
>

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

> The audit document says: "and the Symantec Non-Federal SSP – customer
> specific CAs (collectively referred to as the “Non-Federal SSP CAs”)."
>
> For which it then says that "our examination did not extend to the
> controls of external registration authorities."
>
> The management assertion also says:
> "Controls have inherent limitations, including the possibility of human
> error and the circumvention or overriding of controls. Accordingly, even
> effective controls can provide only reasonable assurance with respect to
> Symantec’s Non-Federal SSP CA operations. Furthermore, because of changes
> in conditions, the effectiveness of controls may vary over time."
>
>
> Kurt
>
>

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Kurt Roeckx]

On 2017-05-08 15:31, Alex Gaynor wrote:
> I'm not the best way to phrase this, so please forgive the bluntness, but I
> think it'd be appropriate to ask at this point if Symantec has disclosed
> all necessary intermediates (I believe this would be defined as: chain to
> their roots in our trust store, are not expired, are not revoked, and are
> not technically constrained), and would they be willing to state that if
> new intermediate CAs are discovered beyond that point, it would reflect
> either dishonesty or serious mismanagement of their PKI.

This was part of the March 2016 action 2. In
https://mozillacaprogram.secure.force.com/Communications/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00004
you can see that their response was "2016 Apr 18"

And confirmed in the April 2017 response to action 8, see:
https://mozillacaprogram.secure.force.com/Communications/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00020&QuestionIdForText=Q00026


Kurt

[Alex Gaynor]

Thanks Kurt.

Alex

On Mon, May 8, 2017 at 11:22 AM, Kurt Roeckx via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 2017-05-08 15:31, Alex Gaynor wrote:
>

>> I'm not the best way to phrase this, so please forgive the bluntness, but
>> I
>> think it'd be appropriate to ask at this point if Symantec has disclosed
>> all necessary intermediates (I believe this would be defined as: chain to
>> their roots in our trust store, are not expired, are not revoked, and are
>> not technically constrained), and would they be willing to state that if
>> new intermediate CAs are discovered beyond that point, it would reflect
>> either dishonesty or serious mismanagement of their PKI.
>>
>

> This was part of the March 2016 action 2. In
> https://mozillacaprogram.secure.force.com/Communications/CAC
> ommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00004
> you can see that their response was "2016 Apr 18"
>
> And confirmed in the April 2017 response to action 8, see:
> https://mozillacaprogram.secure.force.com/Communications/CAC
> ommRespWithTextAndTotalsReport?CommunicationId=a05o000003Wrz
> BC&QuestionId=Q00020&QuestionIdForText=Q00026
>
>
>

[uri...@gmail.com]

It may be necessary to expand that definition to intermediates that were capable of issuing certificates within the past year (or longer).

[richm...@gmail.com]

On Monday, May 8, 2017 at 1:24:28 PM UTC+1, Gervase Markham wrote:
> I think it might be appropriate to have a further round of questions to
> Symantec from Mozilla, to try and get some clarity on some outstanding
> and concerning issues. Here are some _proposed_ questions; feel free to
> suggest modifications or other questions, and I will decide what to send
> officially to Symantec in a few days. Please focus on formulating
> questions which would have an effect on Mozilla's view of Symantec or
> our response to the recent issues.

How about adding a catch all:

Are you aware of any information that might have an effect on Mozilla's view of Symantec, our response to the recent issues or any of any further issues that have not been disclosed to us so far?

Cheers

Rich.

[tmcque...@gmail.com]

In addition to requesting disclosure of intermediates that have been (even if not currently are) able to issue server certs, and the catchall, both of which seem excellent, I encourage Mozilla to consider asking these questions as part of an implemented remedy plan.

That is, put in motion Mozilla's plan of action given all the information available today, but note that certain modifications are possible should Symantec provide in responses to these queries additional information Mozilla considers useful and actionable.

For example, consider executing the planned phase out of all existing symantec certs by early next year, with distrust of all existing roots at that time, and a limit on new cert lifetimes of 13 months. But should symantec become a leader in reducing cert lifetimes with the stand up of a clean PKI (cf. Eric Mill's proposal), then Mozilla would strive to (a) include the new roots by next year, and (b) accept certs with lifetime of 27 months. Or, should symantec be able to verifiably demonstrate other things (e.g. a complete map of their PKI inter-relations, and all parts that are non-BR compliant and thus should be distrusted), then the old ones might not be removed.

Yes, this is harder on the coders (I sympthasize), but how much longer can the current situation (and the risks it does pose *today*) go on?

[Gervase Markham]

On 08/05/17 13:24, Gervase Markham wrote:
> 8) Please explain how the Management Assertions for your December 2014

<snip>

Strike this question; it's based on a misunderstanding of how audits are
done.

Let's add:

10) 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?

11) 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?

Gerv

[Steve Medin]

Gerv,

Our response to the recent questions is posted at: https://bugzilla.mozilla.org/attachment.cgi?id=8867735

Kind regards,
Steve

> -----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: Wednesday, May 10, 2017 7:06 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: [EXT] Re: Draft further questions for Symantec
>
> On 08/05/17 13:24, Gervase Markham wrote:

> > 8) Please explain how the Management Assertions for your December 2014

> <snip>
>
> Strike this question; it's based on a misunderstanding of how audits are
> done.
>
> Let's add:
>
> 10) 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?
>
> 11) 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?
>
> Gerv

[uri...@gmail.com]

The link in footnote [1]
https://www.idmanagement.gov/IDM/servlet/fileField?entityId=ka0t0000000Gmi3AAC&field=File__Body__s

gives me a 404 error.

[Michael Casadevall]

I took a stab at trying to grok this. I find I have more questions and a
lot more concerns the more I read though. Please let me know if I'm not
the only one having issues decoding the responses. Here's my first
impressions:

RA & EV:
Were all the certificates issued by the RAs uploaded to a CT log? If
not, what, if any, subsets were uploaded?

I'm aware Symantec was required to upload certificates to CT or if it
was retroactive, but I'm unsure if that requirement was extended to the RAs.

Furthermore, based on what I'm reading, at least one of these
certificates should be in the logs since it took place post 01/01/15.

Issue Y:
A simple yes or no answer for the questions would have been nice here.

What I'm reading and my understanding suggests that the subCA
certificates could have technically issued a certificate trusted by
Mozilla, but system controls prevented them from being used that way.
How these system controls work is at best unclear.

It's worth noting that the subCA "State of Florida AHCA Medium Assurance
CA" and several other fPKI subCAs chaining off "VeriSign Class 3 SSP
Intermediate CA - G2" are listed in crt.sh is listed as trusted in
Mozilla in crt.sh (https://crt.sh/?caid=1384), and based on my
understanding thus could theoretically issue certificates as there's no EKU.

I can't find any leaf certificates issued by these CAs in crt.sh to
confirm this fact though. Here's a question for Symantec, how are they
aware of what certificates these sub-subCAs have or have not issued?

I'm not sure if the green bar requires OIDs in all points along the
certificate chain or if this Florida CA could have issued an leaf
certificate by adding the OIDs there.

Issue L:
Given that the cross-signature was doing by VeriSign, I've got more
questions. As far as I can tell, the response suggests that Symantec was
aware that the cross-signature allowed the FPKI to be trusted in places
it otherwise wouldn't be, and decided to ignore it until it expired out
in 2016.

That sounds bad, but my other possible reading of this was: "We were
unaware of the cross-signature until 2014, and we let it expire in 2016
since we didn't know what it did".

[Steve Medin]

Replacement link: https://bugzilla.mozilla.org/attachment.cgi?id=8867892

Sorry, I had the PDF cached.

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symant...@lists.mozilla.org] On Behalf Of

> urijah--- via dev-security-policy
> Sent: Monday, May 15, 2017 3:41 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: [EXT] Re: Draft further questions for Symantec
>
> The link in footnote [1]
> https://www.idmanagement.gov/IDM/servlet/fileField?entityId=ka0t0000
> 000Gmi3AAC&field=File__Body__s
>
> gives me a 404 error.
>
>
> On Monday, May 15, 2017 at 11:09:41 AM UTC-4, Steve Medin wrote:

[Gervase Markham]

On 15/05/17 22:08, Michael Casadevall wrote:
> RA & EV:
> Were all the certificates issued by the RAs uploaded to a CT log? If
> not, what, if any, subsets were uploaded?
>
> I'm aware Symantec was required to upload certificates to CT or if it
> was retroactive, but I'm unsure if that requirement was extended to the RAs.

Google required Symantec to do this after a date in mid-2016. I would
assume it extended to the RAs because otherwise their new certs would
not be trusted in Chrome.

There was no requirement on Symantec to CT-log all their previous
certificates, either issued by themselves or their RAs.

> I'm not sure if the green bar requires OIDs in all points along the
> certificate chain or if this Florida CA could have issued an leaf
> certificate by adding the OIDs there.

It only requires the OID in the leaf.

Gerv