Require Certificate Transparency for Symantec-operated roots

Require Certificate Transparency for Symantec-operated roots

In line with
https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html
this CL requires that all Symantec-issued certificates
after 1 June 2016 be CT qualified, as defined by the
Certificate Transparency in Chrome Policy -
https://www.chromium.org/Home/chromium-security/certificate-transparency

Any certificates that are not CT qualified will cause
an interstitial with ERR_CERTIFICATE_TRANSPARENCY_REQUIRED.

BUG=620178
Committed: https://crrev.com/c77495f99003b06f5e9d6ac750b6ffb0afdb582a
Cr-Commit-Position: refs/heads/master@{#403328}

[Ryan Sleevi, 2016-06-29 22:03:25]

https://codereview.chromium.org/2109913004/diff/1/net/data/ssl/symantec/READM...
File net/data/ssl/symantec/README.md (right):

https://codereview.chromium.org/2109913004/diff/1/net/data/ssl/symantec/READM...
net/data/ssl/symantec/README.md:25: 
Symantec has sent the audit details directly, because Aetna didn't get a
WebTrust seal.

https://codereview.chromium.org/2109913004/diff/1/net/data/ssl/symantec/READM...
net/data/ssl/symantec/README.md:32: 
Yes, the omission of IST 1 and IST 3 are intentional (I don't know if an IST 1
exists, and it seems the audit didn't cover IST 3 which has never been used)

https://codereview.chromium.org/2109913004/diff/1/net/data/ssl/symantec/READM...
net/data/ssl/symantec/README.md:50: 
CPS & audit are still forthcoming; this may not make the final cut.

[Ryan Sleevi, 2016-06-29 22:14:15]

rsleevi@chromium.org changed reviewers:
+ eroman@chromium.org

[Ryan Sleevi, 2016-06-29 22:14:16]

Order of recommended reading:
- transport_security_state.cc changes to review the implementation
- The /symantec/README.md file to understand how the hashes were generated
- transport_security_state_ct_required.inc to compare the hashes and claims

For the hashes, you can match that the .inc file contains entries in the
subdirectories, nothing's excluded.

However, it's a bit of a rubberstamp for "Is this all of Symantec's Roots" or
"Is this all of the independent sub-CAs"

[eroman, 2016-06-29 23:22:22]

lgtm

https://codereview.chromium.org/2109913004/diff/1/net/data/ssl/symantec/READM...
File net/data/ssl/symantec/README.md (right):

https://codereview.chromium.org/2109913004/diff/1/net/data/ssl/symantec/READM...
net/data/ssl/symantec/README.md:8: For details about why, see
<https://security.googleblog.com/2015/10/sustaining-digital-certificate-securi...>
Here you are using the <...> notation, whereas in the other files you changed it
all to [](), presumably because gitiles doesn't linkdify the angle flavor.

Was using angle brackets intentional here?

https://codereview.chromium.org/2109913004/diff/1/net/data/ssl/symantec/READM...
net/data/ssl/symantec/README.md:16: The full set of roots are in the
[roots/](roots/) directory, organized by SHA-256 hash of the certificate file.
nit: The above lines look to be wrapped, whereas this one is longer.

https://codereview.chromium.org/2109913004/diff/1/net/data/ssl/symantec/roots...
File
net/data/ssl/symantec/roots/9e503738722e0a104cf659ff9f92f0b5b3662acd112d4664d1e7db93abf46a59.pem
(right):

https://codereview.chromium.org/2109913004/diff/1/net/data/ssl/symantec/roots...
net/data/ssl/symantec/roots/9e503738722e0a104cf659ff9f92f0b5b3662acd112d4664d1e7db93abf46a59.pem:13:
Public Key Algorithm: dsaEncryption
Do we support DSA for certs?

https://codereview.chromium.org/2109913004/diff/20001/net/http/transport_secu...
File net/http/transport_security_state.cc (right):

https://codereview.chromium.org/2109913004/diff/20001/net/http/transport_secu...
net/http/transport_security_state.cc:56: DCHECK(rhs.tag == HASH_VALUE_SHA256);
dcheck_eq (and below)

https://codereview.chromium.org/2109913004/diff/20001/net/http/transport_secu...
net/http/transport_security_state.cc:746: // The candidate cert is not be
subject to the CT policy, because it
Is there anything preventing re-issuing the target certificate with an earlier
notBefore to game this?

https://codereview.chromium.org/2109913004/diff/40001/net/http/transport_secu...
File net/http/transport_security_state.cc (right):

https://codereview.chromium.org/2109913004/diff/40001/net/http/transport_secu...
net/http/transport_security_state.cc:746: // The candidate cert is not be
subject to the CT policy, because it
wording

[Ryan Sleevi, 2016-06-30 00:03:21]

https://codereview.chromium.org/2109913004/diff/1/net/data/ssl/symantec/READM...
File net/data/ssl/symantec/README.md (right):

https://codereview.chromium.org/2109913004/diff/1/net/data/ssl/symantec/READM...
net/data/ssl/symantec/README.md:8: For details about why, see
<https://security.googleblog.com/2015/10/sustaining-digital-certificate-securi...>
On 2016/06/29 23:22:21, eroman wrote:
> Here you are using the <...> notation, whereas in the other files you changed
it
> all to [](), presumably because gitiles doesn't linkdify the angle flavor.
> 
> Was using angle brackets intentional here?

Yeah, Markdown syntax (which is why I fixed the blacklist) <> shows the URL,
while []() shows a description and linkifies

https://codereview.chromium.org/2109913004/diff/1/net/data/ssl/symantec/roots...
File
net/data/ssl/symantec/roots/9e503738722e0a104cf659ff9f92f0b5b3662acd112d4664d1e7db93abf46a59.pem
(right):

https://codereview.chromium.org/2109913004/diff/1/net/data/ssl/symantec/roots...
net/data/ssl/symantec/roots/9e503738722e0a104cf659ff9f92f0b5b3662acd112d4664d1e7db93abf46a59.pem:13:
Public Key Algorithm: dsaEncryption
On 2016/06/29 23:22:21, eroman wrote:
> Do we support DSA for certs?

It's complicated (that weird intersection of OS vs //net). BoringSSL does not,
however.

https://codereview.chromium.org/2109913004/diff/20001/net/http/transport_secu...
File net/http/transport_security_state.cc (right):

https://codereview.chromium.org/2109913004/diff/20001/net/http/transport_secu...
net/http/transport_security_state.cc:746: // The candidate cert is not be
subject to the CT policy, because it
On 2016/06/29 23:22:21, eroman wrote:
> Is there anything preventing re-issuing the target certificate with an earlier
> notBefore to game this?

Unfortunately, no, and that's legitimately my biggest concern (and what occupied
a lot of time in handling this). The answer is that we're going to address it in
the CA/Browser Forum, but Symantec's audits presently declare they haven't gamed
the system (in the past year). They totally have before though.

[Ryan Sleevi, 2016-06-30 19:29:45]

The CQ bit was checked by rsleevi@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-30 19:30:27]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-06-30 20:28:46]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-30 20:28:47]

Dry run: Try jobs failed on following builders:
  ios-simulator-gn on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-gn/...)

[Ryan Sleevi, 2016-06-30 21:01:50]

The CQ bit was checked by rsleevi@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-30 21:02:32]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-06-30 21:40:05]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-30 21:40:06]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Ryan Sleevi, 2016-06-30 21:54:03]

The CQ bit was checked by rsleevi@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-30 21:54:35]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-06-30 23:05:17]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-30 23:05:18]

Dry run: This issue passed the CQ dry run.

[Ryan Sleevi, 2016-06-30 23:07:04]

The CQ bit was checked by rsleevi@chromium.org

[Ryan Sleevi, 2016-06-30 23:07:04]

The patchset sent to the CQ was uploaded after l-g-t-m from eroman@chromium.org
Link to the patchset: https://codereview.chromium.org/2109913004/#ps160001
(title: "NaCL")

[commit-bot: I haz the power, 2016-06-30 23:07:47]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-06-30 23:15:40]

Committed patchset #9 (id:160001)

[commit-bot: I haz the power, 2016-06-30 23:15:54]

CQ bit was unchecked.

[commit-bot: I haz the power, 2016-06-30 23:17:27]

Description was changed from

==========
Require Certificate Transparency for Symantec-operated roots

In line with
https://security.googleblog.com/2015/10/sustaining-digital-certificate-securi...
this CL requires that all Symantec-issued certificates
after 1 June 2016 be CT qualified, as defined by the
Certificate Transparency in Chrome Policy -
https://www.chromium.org/Home/chromium-security/certificate-transparency

Any certificates that are not CT qualified will cause
an interstitial with ERR_CERTIFICATE_TRANSPARENCY_REQUIRED.

BUG=620178
==========

to

==========
Require Certificate Transparency for Symantec-operated roots

In line with
https://security.googleblog.com/2015/10/sustaining-digital-certificate-securi...
this CL requires that all Symantec-issued certificates
after 1 June 2016 be CT qualified, as defined by the
Certificate Transparency in Chrome Policy -
https://www.chromium.org/Home/chromium-security/certificate-transparency

Any certificates that are not CT qualified will cause
an interstitial with ERR_CERTIFICATE_TRANSPARENCY_REQUIRED.

BUG=620178

Committed: https://crrev.com/c77495f99003b06f5e9d6ac750b6ffb0afdb582a
Cr-Commit-Position: refs/heads/master@{#403328}
==========

[commit-bot: I haz the power, 2016-06-30 23:17:29]

Patchset 9 (id:??) landed as
https://crrev.com/c77495f99003b06f5e9d6ac750b6ffb0afdb582a
Cr-Commit-Position: refs/heads/master@{#403328}