Symantec Test Cert Misissuance Incident

[Kathleen Wilson]

In September of this year, the CA Symantec revealed[0] that they had
mis-issued a number of certificates for domains that they did not own or
control, for testing purposes. After an “exhaustive review”, they issued
a Final Report[1] which documented 23 such certificates.

Yesterday, Symantec updated their final report[2] to indicate that the
problem was more extensive than they had at first believed. They said,
in part:

“While our current investigation is ongoing, so far we have found 164
additional instances where test certificates were inappropriately
issued. All of these test certificates have been revoked. These test
certificates were spread over 76 domain owners whom we are in the
process of contacting.”

In addition, they have identified 3073 test certificates which were
issued for domains which were (at the time) unregistered, since the
practice was banned (which happened at different times for EV certs and
other certs). They have provided two lists[3][4], one of the 164 certs
and another of the 3073.

They are continuing to search, and will update the Final Report again
when their investigations are complete.

The 164 certificates will be added to Mozilla’s OneCRL system[5]. (We do
not think the risk from the 3073 is significant enough to warrant this
step.)

This message has been posted to begin a discussion in the Mozilla
community as to what additional action, if any, Mozilla should take in
response to these events.

Kathleen, Gerv and Richard

[0]http://www.symantec.com/connect/blogs/tough-day-leaders
[1]https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report.pdf

[2]https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_10_12_2015.pdf
[3]https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportOwnedDomains.pdf
[4]https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportUnregistered.pdf
[5]https://bugzilla.mozilla.org/show_bug.cgi?id=1214321

[Michael Colburn]

Symantec's gone and updated [2] and [4] and both of those links are
404ing now. Updated links:

[2] https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_10_13_2015v3.pdf
[4] https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportUnregisteredv2.pdf

Michael

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

[Charles Reiss]

On 10/13/15 18:46, Kathleen Wilson wrote:
> In September of this year, the CA Symantec revealed[0] that they had mis-issued
> a number of certificates for domains that they did not own or control, for
> testing purposes. After an “exhaustive review”, they issued a Final Report[1]
> which documented 23 such certificates.
>
> Yesterday, Symantec updated their final report[2] to indicate that the problem
> was more extensive than they had at first believed. They said, in part:
>
> “While our current investigation is ongoing, so far we have found 164 additional
> instances where test certificates were inappropriately issued. All of these test
> certificates have been revoked. These test certificates were spread over 76
> domain owners whom we are in the process of contacting.”
>
> In addition, they have identified 3073 test certificates which were issued for
> domains which were (at the time) unregistered, since the practice was banned
> (which happened at different times for EV certs and other certs). They have
> provided two lists[3][4], one of the 164 certs and another of the 3073.

This list of test certs for owned domains contains an entry for
a cert with serial number 0xc222a issued by RapidSSL CA, valid from 05/18/2013
22:27:16 GMT to 06/20/2015 13:57:13 GMT (last entry of the owned domains PDF).
This appears to be this certificate https://crt.sh/?id=1990400 which has:

X509v3 Subject Alternative Name:
DNS:*.icns.com.au
DNS:icns.com.au

As of this writing, there appears to be a functional server at that
www.icns.com.au which presents that (expired and revoked) cert and to which
openssl s_client can successfully connect.

Is this entry an error?

In Symantec's initial incident report, they indicated 'the private keys
associated with the test certificates were all destroyed as part of the testing
tool that was used to enroll for the test certificates'. Are they still making
this claim for the test certificates found subsequently?

- Charles

[Gervase Markham]

On 13/10/15 23:58, Michael Colburn wrote:
> Symantec's gone and updated [2] and [4] and both of those links are
> 404ing now. Updated links:
>
> [2] https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_10_13_2015v3.pdf
> [4] https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportUnregisteredv2.pdf

The change seems to be to revise the figure for test certs for
unregistered domains down from 3073 to 2548.

Gerv

[Gervase Markham]

On 14/10/15 01:15, Charles Reiss wrote:
<snip>

> As of this writing, there appears to be a functional server at that
> www.icns.com.au which presents that (expired and revoked) cert and to which
> openssl s_client can successfully connect.
>
> Is this entry an error?

Thank you for doing this investigation. That's a good question; this
cert does not look like the other test certs. I will ask Symantec.

> In Symantec's initial incident report, they indicated 'the private keys
> associated with the test certificates were all destroyed as part of the testing
> tool that was used to enroll for the test certificates'. Are they still making
> this claim for the test certificates found subsequently?

Another good question I will pass on :-)

Gerv

[Rob Stradling]

On 13/10/15 19:46, Kathleen Wilson wrote:
<snip>

> They have provided two lists[3][4], one of the 164 certs
> and another of the 3073.

<snip>

> [3]https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportOwnedDomains.pdf
>
> [4]https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportUnregistered.pdf

I count 184 certs in [3], not 164.

(There are actually 187 rows, but 3 certs are counted twice)

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Gervase Markham]

On 14/10/15 13:47, Rob Stradling wrote:
> (There are actually 187 rows, but 3 certs are counted twice)

And that's not perhaps because one copy is with a CT poison extension,
and the other is with an SCT?

Gerv

[Rick Andrews]

Thanks for your post.

Symantec does not own the icns.com.au domain, but we had authorization by the domain owner to use the domain for testing. This icns.com.au test certificate was properly authenticated, and was installed and used externally by the domain owner.

We included this certificate on our list of certificates associated with domains that we do not own, which is accurate. However, because we had authorization from the domain owner to issue the certificate, this certificate did not need to be on this list but was included for completeness.

[Rob Stradling]

On 14/10/15 18:16, Gervase Markham wrote:
> On 14/10/15 13:47, Rob Stradling wrote:

>> (There are actually 187 rows, but 3 certs are counted twice)
>

> And that's not perhaps because one copy is with a CT poison extension,
> and the other is with an SCT?

That's extremely unlikely.

None of those 3 are EV certs, none of them are in any of the known CT
logs, and (looking at the Issue Dates) it looks like they were all
issued before Symantec's CA systems had any support for CT.

The 3 duplicate rows are:

Serial Number: 27dc521a863f0921d023f5cda82b0000
Issuer: Thawte DV SSL CA
Issue Date: 02/13/2012 00:00:00 GMT
Expiry Date: 02/12/2013 23:59:59 GMT
Revoke Date: 10/09/15

Serial Number: 383b98e06ad18d776f2cd668200d9fef
Issuer: GeoTrust SSL CA - G2
Issue Date: 03/21/2014 00:00:00 GMT
Expiry Date: 03/21/2015 23:59:59 GMT
Revoke Date: 04/10/14

Serial Number: 402ad03afe8c3341d452a5ac6efa1462
Issuer: GeoTrust SSL CA - G2
Issue Date: 03/21/2014 00:00:00 GMT
Expiry Date: 03/21/2015 23:59:59 GMT
Revoke Date: 04/10/14

[Rob Stradling]

On 15/10/15 00:04, Rick Andrews wrote:
> On Tuesday, October 13, 2015 at 5:16:10 PM UTC-7, Charles Reiss wrote:

<snip>

>> This list of test certs for owned domains contains an entry for
>> a cert with serial number 0xc222a issued by RapidSSL CA, valid from 05/18/2013
>> 22:27:16 GMT to 06/20/2015 13:57:13 GMT (last entry of the owned domains PDF).
>> This appears to be this certificate https://crt.sh/?id=1990400 which has:

<snip>

> Thanks for your post.
>
> Symantec does not own the icns.com.au domain, but we had authorization by the domain owner to use the domain for testing. This icns.com.au test certificate was properly authenticated, and was installed and used externally by the domain owner.
>
> We included this certificate on our list of certificates associated with domains that we do not own, which is accurate. However, because we had authorization from the domain owner to issue the certificate, this certificate did not need to be on this list but was included for completeness.

Hi Rick.

Doesn't "installed and used externally" conflict with the following
statement from your report [1] (emphasis mine) ?
"Through a comprehensive internal review, we confirmed this incident
was limited only to the issuance of test certificates, which *at all
times were fully controlled within Symantec* and never posed any
threat to any user or organization."

BTW, [2] also lists another, older certificate for the same domain -
*.icns.com.au:
https://crt.sh/?id=658905


[1]
https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_10_13_2015v3.pdf

[2]
https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportOwnedDomains.pdf

[Rob Stradling]

Rick, your report [1] states that...

"...the certificates never left Symantec's secure test labs or the
QA test machine, and they were never visible to any end user...
One of these test certificates with a CN=www.google.com was an
Extended Validation (EV) test certificate and was logged to public
Certificate Transparency (CT) log servers"

IIUC, this statement claims that, out of all the certs/precerts listed
in [2], the www.google.com precertificate [3] is the only one that "left
Symantec's secure test labs".


So, when I looked up all of the serial numbers in [2] in crt.sh, I was
surprised to find...

- 2 certs for *.icns.com.au (which you've explained already).

- 2 precertificates, and the corresponding 2 EV certificates, for
evgabrieltest.bbtest.com - see [4].

- an EV cert for symantec-waf01.scutum.jp - see [5].

- an EV cert for 123Symantec.com - see [6].


Also, when I looked for evidence of any of the other certs in [2] in
some of our historical SSL crawler logs, I was surprised to find that...

- the certificate with serial number 14c943, issued by "Equifax
Secure Certificate Authority", was in use when we accessed
https://avodcdn01-a.akamaihd.net on 9th June 2011 (IP address
184.86.230.82) and 25th June 2011 (IP address 95.101.190.82). This
certificate wasn't known to CT until I logged it just now - see [7].

- the certificate with serial number
1962f4d772f9e9c7ef2d09dd40d85a2c, issued by "VeriSign Class 3 Extended
Validation SSL SGC CA", was in use when we accessed
https://remote.tdsolutionscenter.com (IP address 96.243.213.32) on the
8th, 11th, 13th and 22nd January 2013. remote.tdsolutionscenter.com
still resolves to that IP address today. This certificate wasn't known
to CT until I logged it just now - see [8].


I also found a copy of the certificate with serial number 64b32, issued
by "GeoTrust DV SSL CA" (although for some reason I wasn't able to find
a record of where we discovered that cert). This certificate wasn't
known to CT until I logged it just now - see [9].

[1]
https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_10_13_2015v3.pdf

[2]
https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportOwnedDomains.pdf

[3] https://crt.sh/?id=9314698

[4] https://crt.sh/?q=evgabrieltest%2Ebbtest%2Ecom&iCAID=1454

[5] https://crt.sh/?id=5934504

[6] https://crt.sh/?id=9324337

[7] https://crt.sh/?id=10162388

[8] https://crt.sh/?id=10162533

[9] https://crt.sh/?id=10162537

[Gervase Markham]

On 15/10/15 10:54, Rob Stradling wrote:
> Rick, your report [1] states that...
>
> "...the certificates never left Symantec's secure test labs or the

A charitable reading of this might be "the private keys never left...".
But yes, it might help to have more details on what exactly is being
claimed here.

> QA test machine, and they were never visible to any end user...
> One of these test certificates with a CN=www.google.com was an
> Extended Validation (EV) test certificate and was logged to public
> Certificate Transparency (CT) log servers"
>
> IIUC, this statement claims that, out of all the certs/precerts listed
> in [2], the www.google.com precertificate [3] is the only one that "left
> Symantec's secure test labs".

It would be helpful to know if the test certificate generation software
logged the certs it generated to CT. If so, would we not expect more of
them to be there? If not, how did some of them end up there? Were they
placed there manually as part of the test?

> - an EV cert for 123Symantec.com - see [6].

Note that that cert has a SAN for "san2.com", which is a domain owned by
someone other than Symantec.

> Also, when I looked for evidence of any of the other certs in [2] in
> some of our historical SSL crawler logs, I was surprised to find that...

These findings are indeed surprising, although it seems more likely that
there are problems with Symantec's list than threats to the CA system.
Previous Symantec test certs I've seen have had Symantec in the O field,
which is not true for these.

Rick: how are you determining which certs to add to your list? Are the
ones Rob has found in the wild mistaken additions, or were they in fact
test certs which were supposed not to leave the lab?

Gerv

[Rick Andrews]

Rob, Gerv - Thanks for your input. We are collating all feedback and are planning to publish another update soon.

[Rick Andrews]

We are working hard on providing an update and responding to open questions. We will provide further information as soon as its available.

[Kathleen Wilson]

Google has blogged about this:

https://googleonlinesecurity.blogspot.com/2015/10/sustaining-digital-certificate-security.html

[Kathleen Wilson]

On 10/28/15 2:14 PM, Kathleen Wilson wrote:
> Google has blogged about this:
>
> https://googleonlinesecurity.blogspot.com/2015/10/sustaining-digital-certificate-security.html
>

All,

We should discuss what actions Mozilla should require of Symantec, and
what would be the penalty of not completing those actions.

Of course, we still do not have the final report from Symantec, which
may change things.

According to the article, here is what Google is requiring of Symantec:

1) as of June 1st, 2016, all certificates issued by Symantec itself will
be required to support Certificate Transparency

2) further update their public incident report with: A post-mortem
analysis that details why they did not detect the additional
certificates that we found. Details of each of the failures to uphold
the relevant Baseline Requirements and EV Guidelines and what they
believe the individual root cause was for each failure.

3) provide ... a detailed set of steps they will take to correct and
prevent each of the identified failures, as well as a timeline for when
they expect to complete such work. Symantec may consider this latter
information to be confidential and so we are not requesting that this be
made public.

4) undergo a Point-in-time Readiness Assessment and a third-party
security audit ... <to> establish Symantec’s conformance to each of
these standards: WebTrust CA, WebTrust BR, WebTrust EV

5) The third-party security audit must assess:
-- The veracity of Symantec’s claims that at no time private keys were
exposed to Symantec employees by the tool.
-- That Symantec employees could not use the tool in question to obtain
certificates for which the employee controlled the private key.
-- That Symantec’s audit logging mechanism is reasonably protected from
modification, deletion, or tampering, as described in Section 5.4.4 of
their CPS.


Do you all think we should simply require the same action items?

Is there need to duplicate all of these requirements?

Is there anything else we should require?

As always, I will appreciate your thoughtful and constructive input into
this discussion.

Kathleen

[Kurt Roeckx]

On 2015-10-28 22:30, Kathleen Wilson wrote:
> According to the article, here is what Google is requiring of Symantec:
>
> 1) as of June 1st, 2016, all certificates issued by Symantec itself will
> be required to support Certificate Transparency

I know this is directly copied from their blog about this, but I wonder
what it means for a certificate to support CT. Is the requirement
really that all certificates need to published in CT?

> 2) further update their public incident report with: A post-mortem
> analysis that details why they did not detect the additional
> certificates that we found. Details of each of the failures to uphold
> the relevant Baseline Requirements and EV Guidelines and what they
> believe the individual root cause was for each failure.

A few of the things that are currently unclear to me are:
- Could any of those certificates have been abused, as in was it
possible that the private key for any of those certificates was in the
hands of a person. There were indications that this might be the case
and I didn't see a reply about those.
- Are all certificates really found now and revoked? As above, the
current state is unclear.
- It says that they have a tool that "a limited number of privileged QA
personnel" can use and that this tool was misused (in this case). It
also talks about an "authentication team" that can issue test
certificates. Are this 2 different tools and does the "authentication
team" use the normal (non-QA) tools to issue test certificates but then
using a "specific review and approval process"?
- What is the difference between the "specific review and approval
process" and the normal process and why is this not the same?
- How is personnel trained?
- Why does the team training need to be changed if the tool does not
allow issuing certificates for non-Symantec domains?
- Why are those test certificates signed by a real CA and not a test CA?

> 5) The third-party security audit must assess:
> -- The veracity of Symantec’s claims that at no time private keys were
> exposed to Symantec employees by the tool.
> -- That Symantec employees could not use the tool in question to obtain
> certificates for which the employee controlled the private key.

It would also be nice to know that a 3rd party couldn't control the

private key.

> -- That Symantec’s audit logging mechanism is reasonably protected from
> modification, deletion, or tampering, as described in Section 5.4.4 of
> their CPS.

So this looks to be their current "final" report:
https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_10_13_2015v3b.pdf

It still conflicts with itself, it first says that there were 3
certificate that shouldn't have been issued while the next paragraph
talks that there were 23. And then you have to go to the addendum to
see yet different numbers.


Kurt

[Gervase Markham]

On 29/10/15 13:17, Kurt Roeckx wrote:
> I know this is directly copied from their blog about this, but I wonder
> what it means for a certificate to support CT. Is the requirement
> really that all certificates need to published in CT?

That's a good question. I suspect they mean "be published in CT";
however, we could be more clear about what we mean when/if we publish
our own requirements.

> - Are all certificates really found now and revoked? As above, the
> current state is unclear.

Presumably when Symantec issue a final "final report" then that will be
the sign that, to the best of their knowledge, they believe this to be true.

> - Why are those test certificates signed by a real CA and not a test CA?

Presumably because they want to test them in realistic scenarios with
standard root stores. That's not to say that they shouldn't have done
this in some cases.

> It still conflicts with itself, it first says that there were 3
> certificate that shouldn't have been issued while the next paragraph
> talks that there were 23. And then you have to go to the addendum to
> see yet different numbers.

I'm sure Rick will make sure that the final final report gets, at
minimum, a copyediting pass :-)

Gerv

[Rick Andrews]

We have just posted an update to our test certificate incident report at https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_20151029.pdf. With regard to the questions on the certificates identified in this discussion, we have reviewed these and we see no anomalies with regard to logging:

[3] https://crt.sh/?id=9314698
> pre-cert logged as part of our internal testing

[4] https://crt.sh/?q=evgabrieltest%2Ebbtest%2Ecom&iCAID=1454
> cert logged as part of our internal testing

[5] https://crt.sh/?id=5934504
> this was a properly issued certificate

[6] https://crt.sh/?id=9324337
> pre-cert logged as part of internal testing

[7] https://crt.sh/?id=10162388
> this was a properly issued certificate

[8] https://crt.sh/?id=10162533
> this was a properly issued certificate

[9] https://crt.sh/?id=10162537
> this was a properly issued certificate

[Matt Palmer]

On Thu, Oct 29, 2015 at 02:17:35PM +0100, Kurt Roeckx wrote:
> On 2015-10-28 22:30, Kathleen Wilson wrote:

> >According to the article, here is what Google is requiring of Symantec:
> >
> >1) as of June 1st, 2016, all certificates issued by Symantec itself will
> >be required to support Certificate Transparency
>

> I know this is directly copied from their blog about this, but I wonder what
> it means for a certificate to support CT. Is the requirement really that
> all certificates need to published in CT?

Yes, I'd say that's the intention. Further, I'll wager that Chromium will
refuse to trust a certificate issued after the cutoff date which chains to a
Symantec root, unless it is presented with sufficient SCTs to qualify under
Chromium's CT policy. If Google's *really* playing hardball, they may
require all existing Symantec certs to be enumerated for a whitelist, and
will refuse to trust the notBefore date, similar to how existing EV certs
were grandfathered.

- Matt

--
Of course, I made the mistake of showing [a demo application] off to my boss,
who showed it off to his boss, and suddenly I couldn't reboot my desktop box
without getting a change control approved.
-- Derick Siddoway, in a place that doesn't exist

[oli...@omattos.com]

Extra requirement:

* Symantec must notify each of it's EV and DV certificate holders once prominently at renewal time that "During the period of your last certificate, Symantec has failed to fully uphold it's duties to the Webtrust Requirements required by many browser vendors. You understand that the validity of the certificates you buy here could be terminated early if Symantec misses further requirements."


Currently, customers are blissfully unaware of the potential benefits of one CA over another, or the potential cost to them if a CA has security issues, with most marketing based on who has the biggest golden padlock image on display. Text like this will help customers make an informed decision based on a CA's security history of technical success/failures.

[John Nagle]

> From: Kathleen Wilson <kwi...@mozilla.com>
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Symantec Test Cert Misissuance Incident

>
> On 10/28/15 2:14 PM, Kathleen Wilson wrote:
>> Google has blogged about this:
>>
>> https://googleonlinesecurity.blogspot.com/2015/10/sustaining-digital-certificate-security.html
>>

> We should discuss what actions Mozilla should require of Symantec, and
> what would be the penalty of not completing those actions.

Do we know which exactly root certs were misused in this way?
We will want to pull them from the list of certs SiteTruth trusts.

John Nagle
SiteTruth
"Know who you're dealing with."

[Charles Reiss]

On 10/28/15 21:30, Kathleen Wilson wrote:
> On 10/28/15 2:14 PM, Kathleen Wilson wrote:
>> Google has blogged about this:
>>
>> https://googleonlinesecurity.blogspot.com/2015/10/sustaining-digital-certificate-security.html
>>
>>
>
> All,
>
> We should discuss what actions Mozilla should require of Symantec, and what
> would be the penalty of not completing those actions.
>
> Of course, we still do not have the final report from Symantec, which may change
> things.
>
> According to the article, here is what Google is requiring of Symantec:
>
> 1) as of June 1st, 2016, all certificates issued by Symantec itself will be
> required to support Certificate Transparency
>
> 2) further update their public incident report with: A post-mortem analysis that
> details why they did not detect the additional certificates that we found.
> Details of each of the failures to uphold the relevant Baseline Requirements and
> EV Guidelines and what they believe the individual root cause was for each failure.

Based on the tone of Symantec's blog post, I fear such an assessment will have
root causes like "employees failed to follow written domain validation
procedures". Such a result would be unfortunate, because it would provide little
insight into how the BRs and Mozilla's policies can be changed to prevent
misissuance in the future.

If the root cause is going to be "human error" of that sort, Mozilla should try
to obtain an understanding of Symantec's procedures that should have prevented
it (training, policy compliance monitoring, automation/UX provided by
certificate issuance tools, availability of test CAs, etc.).

[snip]

> Do you all think we should simply require the same action items?
>
> Is there need to duplicate all of these requirements?
>
> Is there anything else we should require?

On an different issue, I am curious whether any of the misissued certificates
were reviewed as part of the quarterly self-audit of a 3% random sample of
certificates required by the BRs.

[Peter Kurrasch]

As the perennial bad guy, I look forward to Symantec (and others) publishing certs with CT. I can data-mine the logs to get a list of their customers and target them for any number of purposes. One possibility I'm considering:

"Dear Symantec Customer: Did you hear about Symantec's recent trouble with certificate mis-issuance? We care deeply about your security, so please click on this link to verify that your own certificates have not been compromised...."

The linked site, of course, will infect the person's PC with malware. Or maybe it will be a site that tries to steal their business from Symantec. I haven't decided yet.


  Original Message  
From: Matt Palmer
Sent: Thursday, October 29, 2015 3:49 PM‎

On Thu, Oct 29, 2015 at 02:17:35PM +0100, Kurt Roeckx wrote:
> On 2015-10-28 22:30, Kathleen Wilson wrote:

> >According to the article, here is what Google is requiring of Symantec:
> >
> >1) as of June 1st, 2016, all certificates issued by Symantec itself will
> >be required to support Certificate Transparency
>

> I know this is directly copied from their blog about this, but I wonder what
> it means for a certificate to support CT. Is the requirement really that
> all certificates need to published in CT?

Yes, I'd say that's the intention. Further, I'll wager that Chromium will
refuse to trust a certificate issued after the cutoff date which chains to a
Symantec root, unless it is presented with sufficient SCTs to qualify under
Chromium's CT policy. If Google's *really* playing hardball, they may
require all existing Symantec certs to be enumerated for a whitelist, and
will refuse to trust the notBefore date, similar to how existing EV certs

were grandfathered.‎

[Kathleen Wilson]

On 10/28/15 2:30 PM, Kathleen Wilson wrote:
> On 10/28/15 2:14 PM, Kathleen Wilson wrote:
>> Google has blogged about this:
>>
>> https://googleonlinesecurity.blogspot.com/2015/10/sustaining-digital-certificate-security.html
>>
>>
>
> All,
>
> We should discuss what actions Mozilla should require of Symantec, and
> what would be the penalty of not completing those actions.

Thanks to all of you who have been providing thoughtful and constructive
input into these discussions.

I think we should create a Bugzilla bug with the following requirements:

1) Finish helping us update OneCRL with the appropriate records
https://bugzilla.mozilla.org/show_bug.cgi?id=1214321#c20

2) Provide a set of steps Symantec will take (or has taken) to correct

and prevent each of the identified failures, as well as a timeline for
when they expect to complete such work.

3) The third-party security audit (may be part of the annual audits)
must assess:

- The veracity of Symantec’s claims that at no time private keys were
exposed to Symantec employees by the tool.
- That Symantec employees could not use the tool in question to obtain
certificates for which the employee controlled the private key.
- That Symantec’s audit logging mechanism is reasonably protected from
modification, deletion, or tampering, as described in Section 5.4.4 of
their CPS.

4) As of June 1st, 2016, all certificates issued by Symantec itself will
be required to support Certificate Transparency and be published in CT.

Other suggested action items I don't think we need to track:
- They already updated their incident report. I doubt we'll get any more
in that regard.
- Their annual audit is probably happening about now or soon, so
requiring a separate point-in-time assessment or another type of
assessment is probably duplicate effort.
- Notify all their cert holders about this incident -- I don't think
that's actually a reasonable requirement, and I don't think it improves
security, because there is no real action to suggest for the customers
-- I don't think switching to a different CA guarantees better security.

Thanks,
Kathleen

[Kathleen Wilson]

I filed the bug for tracking Symantec's action items regarding this
incident:
https://bugzilla.mozilla.org/show_bug.cgi?id=1229445

Kathleen

[Eric Mill]

On Wed, Nov 25, 2015 at 12:15 PM, Kathleen Wilson <kwi...@mozilla.com>
wrote:

>
>> 4) As of June 1st, 2016, all certificates issued by Symantec itself will
> be required to support Certificate Transparency and be published in CT.
>

Is this something Mozilla sees implemented as a technical measure within
Firefox, or something Mozilla plans to measure or audit in other ways?

-- Eric