Merge Nov 2020 CT Policy changes to master (#32)
Merging Nov 2020 CT Policy changes from the branch currently serving the current CT Policy (https://chromium.github.io/ct-policy/ct_policy.html) that's hosted on `draft-policy-changes-2020q4` now that the previous text has been archived on branch `archived-pre-nov-2020-ct-policy` Co-authored-by: Andrew Whalley <awhalley@google.com>
This commit is contained in:
Родитель
004eaa1a94
Коммит
4fa79451e0
|
@ -1,4 +1,4 @@
|
|||
# How to contribute
|
||||
# How to Contribute
|
||||
|
||||
We'd love to accept your patches and contributions to this project. There are
|
||||
just a few small guidelines you need to follow.
|
||||
|
@ -6,13 +6,14 @@ just a few small guidelines you need to follow.
|
|||
## Contributor License Agreement
|
||||
|
||||
Contributions to this project must be accompanied by a Contributor License
|
||||
Agreement. You (or your employer) retain the copyright to your contribution,
|
||||
this simply gives us permission to use and redistribute your contributions as
|
||||
part of the project. Head over to <https://cla.developers.google.com/> to see
|
||||
your current agreements on file or to sign a new one.
|
||||
Agreement (CLA). You (or your employer) retain the copyright to your
|
||||
contribution; this simply gives us permission to use and redistribute your
|
||||
contributions as part of the project. Head over to
|
||||
<https://cla.developers.google.com/> to see your current agreements on file or
|
||||
to sign a new one.
|
||||
|
||||
You generally only need to submit a CLA once, so if you've already submitted
|
||||
one (even if it was for a different project), you probably don't need to do it
|
||||
You generally only need to submit a CLA once, so if you've already submitted one
|
||||
(even if it was for a different project), you probably don't need to do it
|
||||
again.
|
||||
|
||||
## Code reviews
|
||||
|
@ -21,3 +22,8 @@ All submissions, including submissions by project members, require review. We
|
|||
use GitHub pull requests for this purpose. Consult
|
||||
[GitHub Help](https://help.github.com/articles/about-pull-requests/) for more
|
||||
information on using pull requests.
|
||||
|
||||
## Community Guidelines
|
||||
|
||||
This project follows
|
||||
[Google's Open Source Community Guidelines](https://opensource.google/conduct/).
|
||||
|
|
3
LICENSE
3
LICENSE
|
@ -1,3 +1,4 @@
|
|||
|
||||
Apache License
|
||||
Version 2.0, January 2004
|
||||
http://www.apache.org/licenses/
|
||||
|
@ -198,4 +199,4 @@
|
|||
distributed under the License is distributed on an "AS IS" BASIS,
|
||||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
||||
See the License for the specific language governing permissions and
|
||||
limitations under the License.
|
||||
limitations under the License.
|
|
@ -0,0 +1,202 @@
|
|||
|
||||
Apache License
|
||||
Version 2.0, January 2004
|
||||
http://www.apache.org/licenses/
|
||||
|
||||
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
||||
|
||||
1. Definitions.
|
||||
|
||||
"License" shall mean the terms and conditions for use, reproduction,
|
||||
and distribution as defined by Sections 1 through 9 of this document.
|
||||
|
||||
"Licensor" shall mean the copyright owner or entity authorized by
|
||||
the copyright owner that is granting the License.
|
||||
|
||||
"Legal Entity" shall mean the union of the acting entity and all
|
||||
other entities that control, are controlled by, or are under common
|
||||
control with that entity. For the purposes of this definition,
|
||||
"control" means (i) the power, direct or indirect, to cause the
|
||||
direction or management of such entity, whether by contract or
|
||||
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
||||
outstanding shares, or (iii) beneficial ownership of such entity.
|
||||
|
||||
"You" (or "Your") shall mean an individual or Legal Entity
|
||||
exercising permissions granted by this License.
|
||||
|
||||
"Source" form shall mean the preferred form for making modifications,
|
||||
including but not limited to software source code, documentation
|
||||
source, and configuration files.
|
||||
|
||||
"Object" form shall mean any form resulting from mechanical
|
||||
transformation or translation of a Source form, including but
|
||||
not limited to compiled object code, generated documentation,
|
||||
and conversions to other media types.
|
||||
|
||||
"Work" shall mean the work of authorship, whether in Source or
|
||||
Object form, made available under the License, as indicated by a
|
||||
copyright notice that is included in or attached to the work
|
||||
(an example is provided in the Appendix below).
|
||||
|
||||
"Derivative Works" shall mean any work, whether in Source or Object
|
||||
form, that is based on (or derived from) the Work and for which the
|
||||
editorial revisions, annotations, elaborations, or other modifications
|
||||
represent, as a whole, an original work of authorship. For the purposes
|
||||
of this License, Derivative Works shall not include works that remain
|
||||
separable from, or merely link (or bind by name) to the interfaces of,
|
||||
the Work and Derivative Works thereof.
|
||||
|
||||
"Contribution" shall mean any work of authorship, including
|
||||
the original version of the Work and any modifications or additions
|
||||
to that Work or Derivative Works thereof, that is intentionally
|
||||
submitted to Licensor for inclusion in the Work by the copyright owner
|
||||
or by an individual or Legal Entity authorized to submit on behalf of
|
||||
the copyright owner. For the purposes of this definition, "submitted"
|
||||
means any form of electronic, verbal, or written communication sent
|
||||
to the Licensor or its representatives, including but not limited to
|
||||
communication on electronic mailing lists, source code control systems,
|
||||
and issue tracking systems that are managed by, or on behalf of, the
|
||||
Licensor for the purpose of discussing and improving the Work, but
|
||||
excluding communication that is conspicuously marked or otherwise
|
||||
designated in writing by the copyright owner as "Not a Contribution."
|
||||
|
||||
"Contributor" shall mean Licensor and any individual or Legal Entity
|
||||
on behalf of whom a Contribution has been received by Licensor and
|
||||
subsequently incorporated within the Work.
|
||||
|
||||
2. Grant of Copyright License. Subject to the terms and conditions of
|
||||
this License, each Contributor hereby grants to You a perpetual,
|
||||
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
||||
copyright license to reproduce, prepare Derivative Works of,
|
||||
publicly display, publicly perform, sublicense, and distribute the
|
||||
Work and such Derivative Works in Source or Object form.
|
||||
|
||||
3. Grant of Patent License. Subject to the terms and conditions of
|
||||
this License, each Contributor hereby grants to You a perpetual,
|
||||
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
||||
(except as stated in this section) patent license to make, have made,
|
||||
use, offer to sell, sell, import, and otherwise transfer the Work,
|
||||
where such license applies only to those patent claims licensable
|
||||
by such Contributor that are necessarily infringed by their
|
||||
Contribution(s) alone or by combination of their Contribution(s)
|
||||
with the Work to which such Contribution(s) was submitted. If You
|
||||
institute patent litigation against any entity (including a
|
||||
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
||||
or a Contribution incorporated within the Work constitutes direct
|
||||
or contributory patent infringement, then any patent licenses
|
||||
granted to You under this License for that Work shall terminate
|
||||
as of the date such litigation is filed.
|
||||
|
||||
4. Redistribution. You may reproduce and distribute copies of the
|
||||
Work or Derivative Works thereof in any medium, with or without
|
||||
modifications, and in Source or Object form, provided that You
|
||||
meet the following conditions:
|
||||
|
||||
(a) You must give any other recipients of the Work or
|
||||
Derivative Works a copy of this License; and
|
||||
|
||||
(b) You must cause any modified files to carry prominent notices
|
||||
stating that You changed the files; and
|
||||
|
||||
(c) You must retain, in the Source form of any Derivative Works
|
||||
that You distribute, all copyright, patent, trademark, and
|
||||
attribution notices from the Source form of the Work,
|
||||
excluding those notices that do not pertain to any part of
|
||||
the Derivative Works; and
|
||||
|
||||
(d) If the Work includes a "NOTICE" text file as part of its
|
||||
distribution, then any Derivative Works that You distribute must
|
||||
include a readable copy of the attribution notices contained
|
||||
within such NOTICE file, excluding those notices that do not
|
||||
pertain to any part of the Derivative Works, in at least one
|
||||
of the following places: within a NOTICE text file distributed
|
||||
as part of the Derivative Works; within the Source form or
|
||||
documentation, if provided along with the Derivative Works; or,
|
||||
within a display generated by the Derivative Works, if and
|
||||
wherever such third-party notices normally appear. The contents
|
||||
of the NOTICE file are for informational purposes only and
|
||||
do not modify the License. You may add Your own attribution
|
||||
notices within Derivative Works that You distribute, alongside
|
||||
or as an addendum to the NOTICE text from the Work, provided
|
||||
that such additional attribution notices cannot be construed
|
||||
as modifying the License.
|
||||
|
||||
You may add Your own copyright statement to Your modifications and
|
||||
may provide additional or different license terms and conditions
|
||||
for use, reproduction, or distribution of Your modifications, or
|
||||
for any such Derivative Works as a whole, provided Your use,
|
||||
reproduction, and distribution of the Work otherwise complies with
|
||||
the conditions stated in this License.
|
||||
|
||||
5. Submission of Contributions. Unless You explicitly state otherwise,
|
||||
any Contribution intentionally submitted for inclusion in the Work
|
||||
by You to the Licensor shall be under the terms and conditions of
|
||||
this License, without any additional terms or conditions.
|
||||
Notwithstanding the above, nothing herein shall supersede or modify
|
||||
the terms of any separate license agreement you may have executed
|
||||
with Licensor regarding such Contributions.
|
||||
|
||||
6. Trademarks. This License does not grant permission to use the trade
|
||||
names, trademarks, service marks, or product names of the Licensor,
|
||||
except as required for reasonable and customary use in describing the
|
||||
origin of the Work and reproducing the content of the NOTICE file.
|
||||
|
||||
7. Disclaimer of Warranty. Unless required by applicable law or
|
||||
agreed to in writing, Licensor provides the Work (and each
|
||||
Contributor provides its Contributions) on an "AS IS" BASIS,
|
||||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
||||
implied, including, without limitation, any warranties or conditions
|
||||
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
||||
PARTICULAR PURPOSE. You are solely responsible for determining the
|
||||
appropriateness of using or redistributing the Work and assume any
|
||||
risks associated with Your exercise of permissions under this License.
|
||||
|
||||
8. Limitation of Liability. In no event and under no legal theory,
|
||||
whether in tort (including negligence), contract, or otherwise,
|
||||
unless required by applicable law (such as deliberate and grossly
|
||||
negligent acts) or agreed to in writing, shall any Contributor be
|
||||
liable to You for damages, including any direct, indirect, special,
|
||||
incidental, or consequential damages of any character arising as a
|
||||
result of this License or out of the use or inability to use the
|
||||
Work (including but not limited to damages for loss of goodwill,
|
||||
work stoppage, computer failure or malfunction, or any and all
|
||||
other commercial damages or losses), even if such Contributor
|
||||
has been advised of the possibility of such damages.
|
||||
|
||||
9. Accepting Warranty or Additional Liability. While redistributing
|
||||
the Work or Derivative Works thereof, You may choose to offer,
|
||||
and charge a fee for, acceptance of support, warranty, indemnity,
|
||||
or other liability obligations and/or rights consistent with this
|
||||
License. However, in accepting such obligations, You may act only
|
||||
on Your own behalf and on Your sole responsibility, not on behalf
|
||||
of any other Contributor, and only if You agree to indemnify,
|
||||
defend, and hold each Contributor harmless for any liability
|
||||
incurred by, or claims asserted against, such Contributor by reason
|
||||
of your accepting any such warranty or additional liability.
|
||||
|
||||
END OF TERMS AND CONDITIONS
|
||||
|
||||
APPENDIX: How to apply the Apache License to your work.
|
||||
|
||||
To apply the Apache License to your work, attach the following
|
||||
boilerplate notice, with the fields enclosed by brackets "[]"
|
||||
replaced with your own identifying information. (Don't include
|
||||
the brackets!) The text should be enclosed in the appropriate
|
||||
comment syntax for the file format. We also recommend that a
|
||||
file or class name and description of purpose be included on the
|
||||
same "printed page" as the copyright notice for easier
|
||||
identification within third-party archives.
|
||||
|
||||
Copyright [yyyy] [name of copyright owner]
|
||||
|
||||
Licensed under the Apache License, Version 2.0 (the "License");
|
||||
you may not use this file except in compliance with the License.
|
||||
You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing, software
|
||||
distributed under the License is distributed on an "AS IS" BASIS,
|
||||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
||||
See the License for the specific language governing permissions and
|
||||
limitations under the License.
|
115
README.md
115
README.md
|
@ -1,105 +1,20 @@
|
|||
# Chromium Certificate Transparency Policy
|
||||
# Certificate Transparency in Chrome
|
||||
|
||||
This repository contains documents related Chromium's Certificate Transparency
|
||||
policies, such as the [Certificate Transparency Log Policy](log_policy.md).
|
||||
## Overview
|
||||
|
||||
Their contents can be discussed in the
|
||||
[ct-policy@chromium.org](https://groups.google.com/a/chromium.org/forum/#!forum/ct-policy)
|
||||
forum.
|
||||
Certificate Transparency (CT) is a protocol designed to fix several structural
|
||||
flaws in the SSL/TLS certificate ecosystem. Described in
|
||||
[RFC 6962](https://tools.ietf.org/html/rfc6962), it provides a public,
|
||||
append-only data structure that can log certificates that are issued by
|
||||
[certificate authorities](https://en.wikipedia.org/wiki/Certificate_authority) (CAs).
|
||||
|
||||
## For Certificate Authorities
|
||||
By logging certificates, it becomes possible for the public to see what
|
||||
certificates have been issued by a given CA. This allows site operators to
|
||||
detect when a certificate has been issued for their domains, allowing them to
|
||||
check for unauthorized issuance. It also allows browsers and root stores, and
|
||||
the broader community, to examine the certificates a CA has issued and ensure
|
||||
that the CA is complying with their expected or disclosed practices.
|
||||
|
||||
In order to help protect users of the Chromium Projects, CAs are expected to
|
||||
support Certificate Transparency. This allows users, the Chromium Authors, and
|
||||
the public to verifiably audit that CAs are conforming to the policies set out
|
||||
in Chromium's [Root Certificate Policy](https://www.chromium.org/Home/chromium-security/root-ca-policy).
|
||||
For more information about how Certificate Transparency works and its role in supporting the web PKI, you can find a helpful introduction to CT at [https://certificate.transparency.dev](https://certificate.transparency.dev/).
|
||||
|
||||
Chromium requires all publicly-trusted TLS certificates issued after April 30, 2018 to support CT as described in the [Certificate Transparency in Chrome Policy](ct_policy.md). Extended Validation (EV) TLS certificates issued before this date are also required to support CT in order to be recognized as an EV certificate in Chromium.
|
||||
|
||||
## For Log Operators
|
||||
|
||||
In order for a Log to be included within Chromium, it must meet the
|
||||
requirements of the [Certificate Transparency Log Policy](log_policy.md). The
|
||||
Log Policy describes the steps for Log Operators to submit Logs for inclusion
|
||||
within Chromium.
|
||||
|
||||
## Recognized Logs
|
||||
|
||||
The following table includes information about the Certificate Transparency Logs
|
||||
that are recognized by Chromium. It includes information about who operates the
|
||||
log, the name the log has been given, and the URL that can be used for logging
|
||||
certificates or inspecting the certificates that have been logged.
|
||||
|
||||
**_Note: The authoritative list is maintained in the [Chromium code base](https://cs.chromium.org/chromium/src/components/certificate_transparency/data/log_list.json). This is merely informational._**
|
||||
|
||||
### Qualified Logs
|
||||
|
||||
| Log Operator | Log Name | Log URL | MMD | Qualified In | Current State |
|
||||
|-------------------------------------------|-----------------------------------------|--------------------------------------------|----------|---------------------------------------|---------------|
|
||||
| [Google](https://www.google.com/) | Google 'Aviator' Log | https://ct.googleapis.com/aviator | 24 hours | [Chrome 35](https://crrev.com/237785) | Read Only |
|
||||
| [Google](https://www.google.com/) | Google 'Pilot' Log | https://ct.googleapis.com/pilot/ | 24 hours | [Chrome 35](https://crrev.com/237785) | Usable |
|
||||
| [DigiCert](https://www.digicert.com/) | DigiCert's Certificate Transparency log | https://ct1.digicert-ct.com/log/ | 24 hours | [Chrome 41](https://crrev.com/309831) | Usable |
|
||||
| [Google](https://www.google.com/) | Google 'Rocketeer' Log | https://ct.googleapis.com/rocketeer | 24 hours | [Chrome 43](https://crrev.com/325382) | Usable |
|
||||
| [Google](https://www.google.com/) | Google 'Icarus' Log | https://ct.googleapis.com/icarus/ | 24 hours | [Chrome 55](https://crrev.com/429670) | Usable |
|
||||
| [Google](https://www.google.com/) | Google 'Skydiver' Log | https://ct.googleapis.com/skydiver/ | 24 hours | [Chrome 55](https://crrev.com/429670) | Usable |
|
||||
| [Sectigo](https://sectigo.com/) | Sectigo 'Mammoth' Log | https://mammoth.ct.comodo.com/ | 24 hours | [Chrome 60](https://crrev.com/482145) | Usable |
|
||||
| [Sectigo](https://sectigo.com/) | Sectigo 'Sabre' Log | https://sabre.ct.comodo.com/ | 24 hours | [Chrome 60](https://crrev.com/482145) | Usable |
|
||||
| [Cloudflare](https://www.cloudflare.com/) | Cloudflare 'Nimbus2020' Log | https://ct.cloudflare.com/logs/nimbus2020/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Usable |
|
||||
| [Cloudflare](https://www.cloudflare.com/) | Cloudflare 'Nimbus2021' Log | https://ct.cloudflare.com/logs/nimbus2021/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Usable |
|
||||
| [Google](https://www.google.com/) | Google 'Argon2020' Log | https://ct.googleapis.com/logs/argon2020/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Usable |
|
||||
| [Google](https://www.google.com/) | Google 'Argon2021' Log | https://ct.googleapis.com/logs/argon2021/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Usable |
|
||||
| [DigiCert](https://www.digicert.com/) | DigiCert 'Yeti2020' Log | https://yeti2020.ct.digicert.com/log/ | 24 hours | [Chrome 67](https://crrev.com/559734) | Usable |
|
||||
| [DigiCert](https://www.digicert.com/) | DigiCert 'Yeti2021' Log | https://yeti2021.ct.digicert.com/log/ | 24 hours | [Chrome 67](https://crrev.com/559734) | Usable |
|
||||
| [DigiCert](https://www.digicert.com/) | DigiCert 'Yeti2022' Log | https://yeti2022.ct.digicert.com/log/ | 24 hours | [Chrome 67](https://crrev.com/559734) | Usable |
|
||||
| [DigiCert](https://www.digicert.com/) | DigiCert 'Nessie2020' Log | https://nessie2020.ct.digicert.com/log/ | 24 hours | [Chrome 72](https://crrev.com/620903) | Usable |
|
||||
| [DigiCert](https://www.digicert.com/) | DigiCert 'Nessie2021' Log | https://nessie2021.ct.digicert.com/log/ | 24 hours | [Chrome 72](https://crrev.com/620903) | Usable |
|
||||
| [DigiCert](https://www.digicert.com/) | DigiCert 'Nessie2022' Log | https://nessie2022.ct.digicert.com/log/ | 24 hours | [Chrome 72](https://crrev.com/620903) | Usable |
|
||||
| [Google](https://www.google.com/) | Google 'Xenon2020' Log | https://ct.googleapis.com/logs/xenon2020/ | 24 hours | [Chrome 73](https://crrev.com/634940) | Usable |
|
||||
| [Google](https://www.google.com/) | Google 'Xenon2021' Log | https://ct.googleapis.com/logs/xenon2021/ | 24 hours | [Chrome 73](https://crrev.com/634940) | Usable |
|
||||
| [Google](https://www.google.com/) | Google 'Xenon2022' Log | https://ct.googleapis.com/logs/xenon2022/ | 24 hours | [Chrome 73](https://crrev.com/634940) | Usable |
|
||||
| [Cloudflare](https://www.cloudflare.com/) | Cloudflare 'Nimbus2022' Log | https://ct.cloudflare.com/logs/nimbus2022/ | 24 hours | [Chrome 76](https://crrev.com/666475) | Usable |
|
||||
| [Cloudflare](https://www.cloudflare.com/) | Cloudflare 'Nimbus2023' Log | https://ct.cloudflare.com/logs/nimbus2023/ | 24 hours | [Chrome 76](https://crrev.com/666475) | Usable |
|
||||
| [DigiCert](https://www.digicert.com/) | DigiCert 'Nessie2023' Log | https://nessie2023.ct.digicert.com/log/ | 24 hours | [Chrome 76](https://crrev.com/666475) | Usable |
|
||||
| [DigiCert](https://www.digicert.com/) | DigiCert 'Yeti2023' Log | https://yeti2023.ct.digicert.com/log/ | 24 hours | [Chrome 76](https://crrev.com/666475) | Usable |
|
||||
| [Google](https://www.google.com/) | Google 'Xenon2023' Log | https://ct.googleapis.com/logs/xenon2023/ | 24 hours | [Chrome 77](https://crrev.com/689620) | Usable |
|
||||
| [Google](https://www.google.com/) | Google 'Argon2022' Log | https://ct.googleapis.com/logs/argon2022/ | 24 hours | [Chrome 77](https://crrev.com/689620) | Usable |
|
||||
| [Google](https://www.google.com/) | Google 'Argon2023' Log | https://ct.googleapis.com/logs/argon2023/ | 24 hours | [Chrome 77](https://crrev.com/689620) | Usable |
|
||||
| [Let's Encrypt](https://letsencrypt.org/) | Let's Encrypt 'Oak2020' Log | https://oak.ct.letsencrypt.org/2020/ | 24 hours | [Chrome 78](https://crrev.com/703880) | Usable |
|
||||
| [Let's Encrypt](https://letsencrypt.org/) | Let's Encrypt 'Oak2021' Log | https://oak.ct.letsencrypt.org/2021/ | 24 hours | [Chrome 78](https://crrev.com/703880) | Usable |
|
||||
| [Let's Encrypt](https://letsencrypt.org/) | Let's Encrypt 'Oak2022' Log | https://oak.ct.letsencrypt.org/2022/ | 24 hours | [Chrome 78](https://crrev.com/703880) | Usable |
|
||||
| [Let's Encrypt](https://letsencrypt.org/) | Let's Encrypt 'Oak2023' Log | https://oak.ct.letsencrypt.org/2023/ | 24 hours | [Chrome 87](https://crrev.com/800599) | Qualified |
|
||||
| [TrustAsia](https://trustasia.com) | TrustAsia 'Log2020' | https://ct.trustasia.com/log2020/ | 24 hours | [Chrome 87](https://crrev.com/800599) | Qualified |
|
||||
| [TrustAsia](https://trustasia.com) | TrustAsia 'Log2021' | https://ct.trustasia.com/log2021/ | 24 hours | [Chrome 87](https://crrev.com/800599) | Qualified |
|
||||
| [TrustAsia](https://trustasia.com) | TrustAsia 'Log2022' | https://ct.trustasia.com/log2022/ | 24 hours | [Chrome 87](https://crrev.com/800599) | Qualified |
|
||||
| [TrustAsia](https://trustasia.com) | TrustAsia 'Log2023' | https://ct.trustasia.com/log2023/ | 24 hours | [Chrome 87](https://crrev.com/800599) | Qualified |
|
||||
|
||||
|
||||
### Once, but no longer, Qualified Logs
|
||||
|
||||
| Log Operator | Name | Log URL | MMD | Qualified In | Last Accepted SCT |
|
||||
|-------------------------------------------|-----------------------------|--------------------------------------------|----------|---------------------------------------|------------------------------|
|
||||
| [Certly](https://certly.io/) | Certly.IO Log | https://log.certly.io | 24 hours | [Chrome 43](https://crrev.com/325382) | 15 April 2016 00:00:00 UTC. |
|
||||
| [Izenpe](https://www.izenpe.com/) | Izenpe Log | https://ct.izenpe.com | 24 hours | [Chrome 44](https://crrev.com/326301) | 30 May 2016 00:00:00 UTC. |
|
||||
| [Venafi](https://www.venafi.com/) | Venafi CT Log Server | https://ctlog.api.venafi.com/ct/v1 | 24 hours | [Chrome 47](https://crrev.com/349170) | 28 Feb 2017 18:42:26 UTC. |
|
||||
| [WoSign](https://www.wosign.com/) | WoSign Log | https://ctlog.wosign.com/ | 24 hours | [Chrome 54](https://crrev.com/414378) | 12 Feb 2018 23:59:59 UTC. |
|
||||
| [StartCom](https://www.startssl.com/) | StartCom CT Log | https://ct.startssl.com/ | 24 hours | [Chrome 54](https://crrev.com/414440) | 12 Feb 2018 23:59:59 UTC. |
|
||||
| [CNNIC](https://cnnic.cn/) | CNNIC CT Log | https://ctserver.cnnic.cn/ | 24 hours | [Chrome 53](https://crrev.com/396817) | 18 Sep 2018 00:00:00 UTC. |
|
||||
| [DigiCert](https://www.digicert.com/) | Symantec Log | https://ct.ws.symantec.com | 24 hours | [Chrome 45](https://crrev.com/483625) | 16 Feb 2019 00:00:00 UTC. |
|
||||
| [DigiCert](https://www.digicert.com/) | Symantec 'Vega' Log | https://vega.ws.symantec.com/ | 24 hours | [Chrome 50](https://crrev.com/376143) | 16 Feb 2019 00:00:00 UTC. |
|
||||
| [DigiCert](https://www.digicert.com/) | Symantec 'Sirius' Log | https://sirius.ws.symantec.com/ | 24 hours | [Chrome 60](https://crrev.com/481160) | 16 Feb 2019 00:00:00 UTC. |
|
||||
| [Google](https://www.google.com/) | Google 'Argon2018' Log | https://ct.googleapis.com/logs/argon2018/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Rejected - Shard Expired |
|
||||
| [Cloudflare](https://www.cloudflare.com/) | Cloudflare 'Nimbus2018' Log | https://ct.cloudflare.com/logs/nimbus2018/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Rejected - Shard Expired |
|
||||
| [DigiCert](https://www.digicert.com/) | DigiCert 'Yeti2018' Log | https://yeti2018.ct.digicert.com/log/ | 24 hours | [Chrome 67](https://crrev.com/559734) | Rejected - Shard Expired |
|
||||
| [DigiCert](https://www.digicert.com/) | DigiCert 'Nessie2018' Log | https://nessie2018.ct.digicert.com/log/ | 24 hours | [Chrome 72](https://crrev.com/620903) | Rejected - Shard Expired |
|
||||
| [Cloudflare](https://www.cloudflare.com/) | Cloudflare 'Nimbus2019' Log | https://ct.cloudflare.com/logs/nimbus2019/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Rejected - Shard Expired |
|
||||
| [DigiCert](https://www.digicert.com/) | DigiCert 'Yeti2019' Log | https://yeti2019.ct.digicert.com/log/ | 24 hours | [Chrome 67](https://crrev.com/559734) | Rejected - Shard Expired |
|
||||
| [DigiCert](https://www.digicert.com/) | DigiCert 'Nessie2019' Log | https://nessie2019.ct.digicert.com/log/ | 24 hours | [Chrome 72](https://crrev.com/620903) | Rejected - Shard Expired |
|
||||
| [Google](https://www.google.com/) | Google 'Argon2019' Log | https://ct.googleapis.com/logs/argon2019/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Rejected - Shard Expired |
|
||||
| [Google](https://www.google.com/) | Google 'Xenon2019' Log | https://ct.googleapis.com/logs/xenon2019/ | 24 hours | [Chrome 73](https://crrev.com/634940) | Rejected - Shard Expired |
|
||||
| [Let's Encrypt](https://letsencrypt.org/) | Let's Encrypt 'Oak2019' Log | https://oak.ct.letsencrypt.org/2019/ | 24 hours | [Chrome 78](https://crrev.com/703880) | Rejected - Shard Expired |
|
||||
| [Venafi](https://www.venafi.com/) | Venafi Gen2 CT log | https://ctlog-gen2.api.venafi.com/ | 24 hours | [Chrome 59](https://crrev.com/471318) | Rejected - All Certs Expired |
|
||||
| [DigiCert](https://www.digicert.com/) | DigiCert Log Server 2 | https://ct2.digicert-ct.com/log/ | 24 hours | [Chrome 60](https://crrev.com/481160) | 04 May 2020 00:00:40 UTC |
|
||||
|
||||
|
||||
## Policy Version
|
||||
Chromium Certificate Transparency Policy Version 1.0
|
||||
Chrome requires all publicly-trusted TLS certificates issued after April 30, 2018 to support CT in order to be recognized as valid. This site provides details on what is required. Any questions should be directed to the [ct-policy@chromium.org](https://groups.google.com/a/chromium.org/forum/#!forum/ct-policy) list.
|
||||
|
|
|
@ -0,0 +1,2 @@
|
|||
theme: jekyll-theme-minimal
|
||||
baseurl: /ct-policy
|
|
@ -0,0 +1,44 @@
|
|||
<!DOCTYPE html>
|
||||
<html lang="{{ site.lang | default: "en-US" }}">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta http-equiv="X-UA-Compatible" content="IE=edge">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
|
||||
{% seo %}
|
||||
<link rel="stylesheet" href="{{ "/assets/css/style.css?v=" | append: site.github.build_revision | relative_url }}">
|
||||
<!--[if lt IE 9]>
|
||||
<script src="https://cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv.min.js"></script>
|
||||
<![endif]-->
|
||||
</head>
|
||||
<body>
|
||||
<div class="wrapper">
|
||||
<header>
|
||||
<h1><a href="{{ "/" | absolute_url }}">Certificate Transparency<br>in Chrome</a></h1>
|
||||
|
||||
<h2 class="menu">Policies</h2>
|
||||
|
||||
<p class="menu"><a href="/ct-policy/ct_policy.html">Chrome CT Policy</a></p>
|
||||
<p class="menu"><a href="/ct-policy/log_policy.html">Chrome CT Log Policy</a></p>
|
||||
|
||||
<h2 class="menu">Reference Material</h2>
|
||||
|
||||
<p class="menu"><a href="/ct-policy/log_states.html">Lifecycle of a CT Log</a></p>
|
||||
<p class="menu"><a href="/ct-policy/site_operators.html">Information for site operators</a></p>
|
||||
<p class="menu"><a href="/ct-policy/enterprises.html">Information for enterprises</a></p>
|
||||
<p class="menu"><a href="/ct-policy/log_list.html">List of recognized CT Logs</a></p>
|
||||
<!-- <p class="menu"><a href="/glossary.html">Glossary of CT Terms</a></p> -->
|
||||
|
||||
</header>
|
||||
<section>
|
||||
|
||||
{{ content }}
|
||||
|
||||
</section>
|
||||
<footer>
|
||||
<p><a href="/ct-policy/CONTRIBUTING.md">contributing</a> | <a href="/ct-policy/LICENSE.txt">license</a></p>
|
||||
</footer>
|
||||
</div>
|
||||
<script src="{{ "/assets/js/scale.fix.js" | relative_url }}"></script>
|
||||
</body>
|
||||
</html>
|
|
@ -0,0 +1,86 @@
|
|||
---
|
||||
---
|
||||
|
||||
@import '{{ site.theme }}';
|
||||
|
||||
body {
|
||||
padding: 10px;
|
||||
}
|
||||
|
||||
.wrapper {
|
||||
width: unset;
|
||||
margin: unset;
|
||||
}
|
||||
|
||||
a:hover,
|
||||
a:focus {
|
||||
font-weight: inherit;
|
||||
text-decoration: underline;
|
||||
}
|
||||
|
||||
p.menu {
|
||||
padding-left: 1em;
|
||||
margin: 0 0 5px;
|
||||
}
|
||||
|
||||
h2.menu {
|
||||
font-size: medium;
|
||||
margin: 20px 0 5px;
|
||||
}
|
||||
|
||||
li > ul {
|
||||
margin: 0 0 0;
|
||||
}
|
||||
|
||||
header {
|
||||
width: 275px;
|
||||
float: left;
|
||||
position: fixed;
|
||||
left: 25px;
|
||||
}
|
||||
|
||||
section {
|
||||
float: none;
|
||||
width: 800px;
|
||||
margin-left: 300px;
|
||||
}
|
||||
|
||||
footer {
|
||||
width: 275px;
|
||||
left: 25px;
|
||||
float: left;
|
||||
position: fixed;
|
||||
bottom: 25px;
|
||||
}
|
||||
|
||||
@media print, screen and (max-width: 1175px) {
|
||||
div.wrapper {
|
||||
width: auto;
|
||||
margin: 0;
|
||||
}
|
||||
|
||||
header,
|
||||
section,
|
||||
footer {
|
||||
float: none;
|
||||
position: static;
|
||||
width: auto;
|
||||
}
|
||||
|
||||
section {
|
||||
border: 1px solid #e5e5e5;
|
||||
border-width: 1px 0;
|
||||
padding: 20px 0;
|
||||
margin: 0 0 20px;
|
||||
}
|
||||
|
||||
header a small {
|
||||
display: inline;
|
||||
}
|
||||
|
||||
header ul {
|
||||
position: absolute;
|
||||
right: 50px;
|
||||
top: 52px;
|
||||
}
|
||||
}
|
|
@ -0,0 +1,28 @@
|
|||
### Chrome Policies
|
||||
|
||||
Chrome has gradually required Certificate Transparency for more and more
|
||||
publicly-trusted certificates over the past few years.
|
||||
|
||||
* [Since 1 January 2015](https://github.com/chromium/ct-policy/blob/master/ct_policy.md),
|
||||
Chrome has required that all Extended Validation certificates be disclosed via
|
||||
Certificate Transparency. Certificates that were not properly disclosed would
|
||||
be [stripped of their EV status](https://news.netcraft.com/archives/2015/08/24/thousands-short-changed-by-ev-certificates-that-dont-display-correctly-in-chrome.html),
|
||||
but no warnings would be shown to visitors to sites that did not comply.
|
||||
|
||||
* [Since 1 June 2016](https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html),
|
||||
Chrome has required that all new certificates issued by the set of root
|
||||
certificates owned by Symantec Corporation are disclosed via Certificate
|
||||
Transparency. Certificates that were not disclosed, or which were not disclosed
|
||||
in a way consistent with RFC 6962, would be rejected as untrusted.
|
||||
|
||||
* For all new certificates issued after 30 April 2018, [Chrome will require that
|
||||
the certificate be disclosed via Certificate
|
||||
Transparency](https://groups.google.com/a/chromium.org/d/msg/ct-policy/wHILiYf31DE/iMFmpMEkAQAJ).
|
||||
If a certificate is issued after this date and neither the certificate nor
|
||||
the site supports CT, then these certificates will be rejected as untrusted, and
|
||||
the connection will be blocked. In the case of a main page load, the user will
|
||||
see a full page certificate warning page, with the error code
|
||||
`net::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED`. If you receive this error, this
|
||||
indicates that your CA has not taken steps to make sure your certificate
|
||||
supports CT, and you should contact your CA's sales or support team to ensure
|
||||
you can get a replacement certificate that works.
|
123
ct_policy.md
123
ct_policy.md
|
@ -1,91 +1,72 @@
|
|||
# Certificate Transparency in Chrome
|
||||
_Questions: [ct-policy@chromium.org](https://groups.google.com/a/chromium.org/forum/#!forum/ct-policy)_
|
||||
# Chrome Certificate Transparency Policy
|
||||
_Please direct any questions about this Policy to the CT Policy forum: [ct-policy@chromium.org](https://groups.google.com/a/chromium.org/forum/#!forum/ct-policy)_
|
||||
|
||||
This document details the criteria for a certificate to be considered
|
||||
*CT Qualified*.
|
||||
When a website’s TLS certificate is validated in modern versions of Chrome, it is
|
||||
evaluated for compliance against the Chrome CT Policy, except in rare circumstances where [certain](https://cloud.google.com/docs/chrome-enterprise/policies/?policy=CertificateTransparencyEnforcementDisabledForCas) [enterprise](https://cloud.google.com/docs/chrome-enterprise/policies/?policy=CertificateTransparencyEnforcementDisabledForLegacyCas) [policies](https://cloud.google.com/docs/chrome-enterprise/policies/?policy=CertificateTransparencyEnforcementDisabledForUrls) are set by an administrator. Certificates that are accompanied by SCTs that satisfy this Policy are said to be *CT Compliant*.
|
||||
|
||||
Google Chrome requires that all Extended Validation (EV) certificates
|
||||
issued after 1 Jan 2015 be CT Qualified in order to be recognized as EV,
|
||||
and that all publicly-trusted TLS certificates issued after 30 April 2018
|
||||
be CT Qualified in order to be recognized as valid.
|
||||
CT Compliance is achieved by a certificate and set of accompanying SCTs meeting a set of technical requirements enforced by the Chrome browser during certificate validation, which are defined in this Policy. The issuance of certificates that are not CT compliant is **not** considered mis-issuance or a violation of Chrome’s root program; such certificates will simply fail to validate in CT-enforcing versions of Chrome.
|
||||
|
||||
In addition, Google Chrome allows for site operators to indicate that they
|
||||
expect all publicly-trusted certificates for their domain, regardless of when
|
||||
they were issued, be CT Qualified in order to be trusted.
|
||||
---
|
||||
|
||||
Chrome’s current Certificate Transparency implementation is as follows:
|
||||
## CT Log States
|
||||
CT Compliance in Chrome is determined by evaluating SCTs from CT Logs and ensuring that these Logs are in the correct state(s) at time of check. The set of possible states a CT Log can be in is:
|
||||
* `Pending`,
|
||||
* `Qualified`,
|
||||
* `Usable`,
|
||||
* `ReadOnly`,
|
||||
* `Retired`, and
|
||||
* `Rejected`
|
||||
|
||||
1. Google runs three geographically diverse CT logs which accept all
|
||||
certificates issued by CAs accepted by any major browser.
|
||||
1. Google continues to invite other organisations to deploy CT logs in order
|
||||
to improve robustness.
|
||||
1. On 1 Jan 2015 Chrome created an allowlist of certificates that contained
|
||||
EV policy OIDs included or pending inclusion in Chrome, that were logged
|
||||
in a qualifying log, and that would not qualify via SCTs embedded in the
|
||||
certificate (see below).
|
||||
1. In March 2015 Chrome for desktop platforms ceased to show the EV
|
||||
indicator for certificates not in the allowlist and not CT qualified
|
||||
according to the criteria below.
|
||||
In order to assist with understanding the requirements for CT compliance in Chrome, the definition of these states, the requirements of Logs in each state, as well as how these states impact Chrome behavior are described in detail in the [CT Log Lifecycle Explainer](log_states.md).
|
||||
|
||||
## Qualifying Logs
|
||||
---
|
||||
|
||||
The criteria for qualifying logs can be found [here](log_policy.md).
|
||||
|
||||
## Qualifying Certificate
|
||||
|
||||
A certificate is “CT qualified” if it meets one of the following criteria:
|
||||
|
||||
1. An SCT from a log qualified at the time of check is presented via the TLS
|
||||
extension OR is embedded within a stapled OCSP response;
|
||||
## CT Compliant Certificates
|
||||
A TLS certificate is *CT Compliant* if it is accompanied by a set of SCTs that satisfies at least one of the criteria defined below, depending on how the SCTs are delivered to Chrome. In CT-enforcing versions of Chrome, TLS certificates are required to be CT Compliant to successfully validate; however, certificates that are not logged to CT or have insufficient SCTs are not considered to be mis-issued or in violation of Chrome’s root program.
|
||||
|
||||
**AND** there is at least one SCT from a Google Log, qualified at the time
|
||||
of check, presented via any method;
|
||||
When evaluating a certificate for CT Compliance, Chrome considers several factors including how many SCTs are present, who operates the CT Log that issued the SCT, and what state the CT Log that issued the SCT was in, both at the time the certificate is being validated, and at the time the SCT was created by the CT Log.
|
||||
|
||||
**AND** there is at least one SCT from a non-Google Log, qualified at time
|
||||
of check, presented via any method.
|
||||
1. An Embedded SCT from a log qualified at the time of check is presented;
|
||||
**CT Compliance is required in the following circumstances:**
|
||||
* EV TLS certificates issued on-or-after 1 January 2015 are required to be CT Compliant in order to be recognized as EV in Chrome
|
||||
* All TLS certificates issued on-or-after 1 May 2018 are required to be CT Compliant in order to successfully validate in Chrome
|
||||
* TLS certificates, regardless of issuance date, for sites whose operators have opted into Expect-CT enforcement are required to be CT compliant to successfully validate in Chrome after first navigating to the site and caching the Expect-CT enforcement setting.
|
||||
|
||||
**AND** there is at least one Embedded SCT from a Google Log, once or
|
||||
currently qualified;
|
||||
Depending on how the SCTs are presented to Chrome, CT compliance can be achieved by meeting one of the following two criteria:
|
||||
|
||||
**AND** there is at least one Embedded SCT from a non-Google Log, once or
|
||||
currently qualified;
|
||||
**Embedded SCTs:**
|
||||
1. At least one Embedded SCT from a CT Log that was `Qualified`, `Usable` or `ReadOnly` at the time of check; and
|
||||
2. At least one Embedded SCT from a Google CT Log that was `Qualified`, `Usable`, `ReadOnly`, or `Retired` at the time of check; and
|
||||
3. At least one Embedded SCT from a non-Google CT Log that was `Qualified`, `Usable`, `ReadOnly`, or `Retired` at the time of check; and
|
||||
4. There are SCTs from at least N distinct CT Logs that were `Qualified`, `Usable`, `ReadOnly`, or `Retired` at the time of check, where N is defined in the following table:
|
||||
|
||||
**AND** there are Embedded SCTs from AT LEAST the number of logs once or
|
||||
currently qualified shown in Table 1.
|
||||
|
||||
"Once or currently qualified" means that the log was qualified or pending
|
||||
qualification at the time of certificate issuance, that the log was accepted
|
||||
prior to the time of check, but that the log may have been disqualified
|
||||
following acceptance, prior to the time of check.
|
||||
|
||||
"Embedded SCT" means an SCT delivered via an X.509v3 extension within the
|
||||
certificate.
|
||||
|
||||
**Table 1**
|
||||
|
||||
| Lifetime of Certificate | Number of SCTs from distinct logs |
|
||||
| Certificate Lifetime | Number of SCTs from distinct CT Logs |
|
||||
|:---:|:---:|
|
||||
| < 15 months | 2 |
|
||||
| >= 15, <= 27 months | 3 |
|
||||
| > 27, <= 39 months | 4<sup>[1](#footnote1)</sup> |
|
||||
| >= 15 and <= 27 months | 3 |
|
||||
| > 27 and <= 39 months | 4 |
|
||||
| > 39 months | 5 |
|
||||
|
||||
<a name="footnote1"><sup>1</sup></a> EV certificates should never have a
|
||||
lifetime over 27 months.
|
||||
**SCTs delivered via OCSP or TLS:**
|
||||
1. At least one SCT from a Google CT Log that was `Qualified`, `Usable`, or `ReadOnly` at the time of check; and
|
||||
2. At least one SCT from a non-Google CT Log that was `Qualified`, `Usable`, or `ReadOnly` at time of check.
|
||||
|
||||
Note that, so long as one of the above conditions is met by some combination
|
||||
of SCTs presented in the handshake, additional SCTs, regardless of the status
|
||||
of the SCT, will not affect the CT Qualification status positively or
|
||||
negatively.
|
||||
|
||||
**Important note: many TLS servers do not support OCSP Stapling or the TLS
|
||||
extension, so CAs should be prepared to insert SCTs into issued EV
|
||||
certificates to maintain the EV indication.**
|
||||
### Important Notes
|
||||
So long as one of the above CT Compliance criteria is met by some combination of SCTs presented in the handshake, additional SCTs, regardless of the status of the SCT, will not affect a certificate’s CT Compliance status positively or negatively.
|
||||
|
||||
## Timeouts
|
||||
In order to contribute to a certificate’s CT Compliance, an SCT must have been issued before the Log’s `Retired` timestamp, if one exists. Chrome uses the earliest SCT among all SCTs presented to evaluate CT compliance against CT Log `Retired` timestamps. This accounts for edge cases in which a CT Log becomes `Retired` during the process of submitting certificate logging requests.
|
||||
|
||||
The list of qualifying and once qualifying logs will be periodically refreshed
|
||||
during regular Chrome releases. If the installed version of Chrome has not
|
||||
applied security updates for a significant amount of time then CT checking
|
||||
will be disabled.
|
||||
"Embedded SCT" means an SCT delivered via the SignedCertificateTimestampList
|
||||
X.509v3 extension within the certificate itself. Many TLS servers do not support OCSP Stapling or the TLS extension, so CAs should be prepared to embed SCTs into issued certificates to ensure successful validation and/or EV treatment in Chrome.
|
||||
|
||||
---
|
||||
|
||||
## How CT Logs are added to Chrome
|
||||
The criteria for how CT Logs can become `Qualified`, as well as what circumstances can cause them to become `Retired`, can be found in the [Chrome CT Log Policy](log_policy.md).
|
||||
|
||||
---
|
||||
|
||||
## CT Enforcement Timeout
|
||||
The list of CT Logs included in Chrome will be periodically refreshed during regular Chrome releases. If the installed version of Chrome has not applied security updates for 70 days (10 weeks) or more, then CT enforcement will be disabled.
|
||||
|
||||
This timeout provides a critical assurance to the CT ecosystem that new CT Logs are able to transition to `Usable` within a fixed amount of time after becoming `Qualified`. All CT-enforcing user agents are strongly encouraged to implement a similar enforcement timeout to maximize compatibility with the existing ecosystem.
|
||||
|
|
|
@ -0,0 +1,153 @@
|
|||
# Certificate Transparency for Enterprises
|
||||
|
||||
## Locally-trusted CAs
|
||||
|
||||
Certificate Transparency only applies to CAs that are publicly-trusted - that
|
||||
is, CAs that are supported by your browser or device out of the box, without
|
||||
any additional configuration steps.
|
||||
|
||||
For CAs that have been manually installed, provided those certificates are not
|
||||
or have not been publicly-trusted, it's not necessary to enable support for
|
||||
Certificate Transparency. Further, Certificate Transparency Logs will not
|
||||
accept certificates from those CAs, thus it's not possible to support CT.
|
||||
|
||||
In some cases, an Enterprise may have a locally-trusted CA that has been
|
||||
manually installed, but it was previously publicly-trusted. For example, this
|
||||
CA may have been removed by a browser or an OS for not complying with the
|
||||
root store policies, but the Enterprise may still have a dependency on
|
||||
trusting this CA. In these cases, the Enterprise can use
|
||||
[Enterprise Policies](#Enterprise-Policies) to configure how Certificate
|
||||
Transparency will be enforced for those CAs.
|
||||
|
||||
## Private Domain Names
|
||||
|
||||
For Enterprises that have domain names that are internal to their organization,
|
||||
and do not need to be publicly-trusted by default, several options exist to
|
||||
enable these domains to be kept private, while allowing the certificates to
|
||||
still be used, without error, for users in their organization.
|
||||
|
||||
The recommended option is to no longer rely on publicly-trusted certificates
|
||||
to serve these domains, as they are organization specific. For example, such
|
||||
organizations can use a private CA, which [several](https://aws.amazon.com/certificate-manager/private-certificate-authority/)
|
||||
[CAs](https://www.digicert.com/private-pki/) [offer](https://www.comodo.com/business-security/pki-management/certificate-manager.php).
|
||||
Using a hosted, managed PKI may help organizations more rapidly respond to
|
||||
change in the TLS ecosystem, such as changes to certificate algorithms or
|
||||
support for new protocols.
|
||||
|
||||
Another option is to request that the publicly-trusted CA not log the
|
||||
certificate. This will prevent this certificate from being trusted by default,
|
||||
but organizations that manage their devices or users can override this through
|
||||
[Enterprise Policies](#Enterprise-Policies) to enable these certificates to be
|
||||
trusted for users in their Enterprise.
|
||||
|
||||
Finally, organizations may manage their own PKI in-house, using CA
|
||||
software such as [CFSSL](https://github.com/cloudflare/cfssl), [Boulder](https://github.com/letsencrypt/boulder),
|
||||
[EJBCA](https://www.ejbca.org/) or
|
||||
[Active Directory Certificate Services](https://msdn.microsoft.com/en-us/library/ff630887.aspx).
|
||||
Managing certificates in-house may be more complex and security risky, but
|
||||
offers an alternative solution to partnering with a certificate provider.
|
||||
|
||||
## Legacy CAs
|
||||
|
||||
Some Enterprises rely on Certificate Authorities that have not been audited to
|
||||
the same standard as other CAs or been operated to the same security
|
||||
requirements. These CAs would not be trusted in new products, nor other root
|
||||
programs, but may be trusted on one or more platforms that Chrome runs on.
|
||||
Because they are trusted by default, they are subject to the Chrome's policies
|
||||
on requiring CT, but due to their legacy status, may not be prepared. While the
|
||||
requirement to disclose new certificates via Certificate Transparency has been
|
||||
communicated, some may not do so, causing their new certificates to not be
|
||||
trusted. This is most common with CAs run by governments, as they rarely meet the
|
||||
required security standards of a widely-trusted CA.
|
||||
|
||||
Organizations that need to use certificates from these CAs should be aware
|
||||
that their certificates will not be trusted if they do not support CT, and so
|
||||
should look for CAs that do support CT. Alternatively, supporting CT via TLS
|
||||
may be the only way to ensure these certificates continue to work, but that
|
||||
requires the Enterprise constantly keep track of changes regarding Certificate
|
||||
Transparency.
|
||||
|
||||
Organizations that need to trust certificates from these CAs, such as when
|
||||
talking to other organizations that need to use these CAs, can configure
|
||||
[Enterprise Policies](#Enterprise-Policy) for users in their organization,
|
||||
which will allow trust in these certificates. As these only apply to Enterprise
|
||||
users, these policies are not suitable for making these certificates trusted
|
||||
more widely.
|
||||
|
||||
## Enterprise Policies
|
||||
|
||||
Several Chrome-specific policies exist that allow Enterprises to configure
|
||||
their machines or users to disable Certificate Transparency for certain cases.
|
||||
These policies are documented in the
|
||||
[master policy list](https://cloud.google.com/docs/chrome-enterprise/policies),
|
||||
but detailed further below.
|
||||
|
||||
### CertificateTransparencyEnforcementDisabledForUrls
|
||||
|
||||
This [policy](https://cloud.google.com/docs/chrome-enterprise/policies/?policy=CertificateTransparencyEnforcementDisabledForUrls)
|
||||
has been available since Chrome 53, and allows for disabling Certificate
|
||||
Transparency enforcement for a certain set of domains or subdomains, without
|
||||
disabling Certificate Transparency altogether.
|
||||
|
||||
If you wish to disable CT for a given hostname, and all of its subdomains, then
|
||||
the domain is simply entered into the list. For example, `example.com` will
|
||||
disable CT for `example.com` and all subdomains.
|
||||
|
||||
If you wish to disable CT only for a given hostname, but wish to ensure that
|
||||
subdomains will still have CT enabled, then prefix the domain with a leading
|
||||
dot. For example, `.example.com` will disable CT for `example.com` exactly,
|
||||
while leaving it enabled for subdomains.
|
||||
|
||||
### CertificateTransparencyEnforcementDisabledForCas
|
||||
|
||||
This [policy](https://cloud.google.com/docs/chrome-enterprise/policies/?policy=CertificateTransparencyEnforcementDisabledForCas),
|
||||
available since Chrome 57, allows for disabling Certificate Transparency
|
||||
enforcement if certain conditions are met in the trusted certificate chain.
|
||||
This allows disabling CT without having to list all of the domain names, but
|
||||
only for certificates issued to a specific organization.
|
||||
|
||||
Certificates are specified in this policy by applying Base64 to a hash of their
|
||||
subjectPublicKeyInformation, as well as specifying the hash algorithm used.
|
||||
This format is very similar to that used by
|
||||
[HTTP Public Key Pinning](https://tools.ietf.org/html/rfc7469) (HPKP), so that
|
||||
sites can use the same [examples](https://tools.ietf.org/html/rfc7469#appendix-A)
|
||||
or [tools](https://report-uri.com/home/pubkey_hash) used to generate HPKP
|
||||
hashes to determine how to configure the policy. Note that while both use
|
||||
Base64, an HPKP hash will be in the form `pin-sha256="hash"`, while the policy
|
||||
will be in the form `sha256/hash`.
|
||||
|
||||
To disable Certificate Transparency for these certificates, the certificate
|
||||
must match one of the following conditions:
|
||||
|
||||
1. The hash specified is of the server certificate's subjectPublicKeyInfo.
|
||||
2. The hash specified is of an intermediate CA, and that intermediate CA has
|
||||
a nameConstraints extension with one or more directoryNames in the
|
||||
permittedSubtrees of that extension.
|
||||
3. The hash specified is of an intermediate CA, that intermediate CA contains
|
||||
one or more organizationName (O) attribute in the subject, and the server
|
||||
certificate's has the same number of organizationName attributes, with
|
||||
byte-for-byte identical values, in the same exact order.
|
||||
|
||||
### CertificateTransparencyEnforcementDisabledForLegacyCas
|
||||
|
||||
This [policy](https://cloud.google.com/docs/chrome-enterprise/policies/?policy=CertificateTransparencyEnforcementDisabledForLegacyCas),
|
||||
available since Chrome 67, allows for disabling Certificate Transparency
|
||||
enforcement for certain legacy CAs that have not adopted modern security and
|
||||
audit requirements required of publicly-trusted CAs. This is particularly
|
||||
tailored towards CAs that are trusted on some platforms that Chrome runs on,
|
||||
but are not trusted on ChromeOS or Android, due to not meeting the necessary
|
||||
security requirements.
|
||||
|
||||
CAs are specified in this policy by applying Base64 to a hash of their
|
||||
subjectPublicKeyInformation, the same as in
|
||||
[CertificateTransparencyEnforcementDisabledForCAs](#CertificateTransparencyEnforcementDisabledForCas).
|
||||
However, these CAs must also be recognized as Legacy CAs in the
|
||||
[`/net/data/ssl/root_stores/root_stores.json`](/net/data/ssl/root_stores/root_stores.json)
|
||||
file, which means that they are not trusted on ChromeOS or Android, but are
|
||||
trusted on another platform that Chrome runs on.
|
||||
|
||||
This policy is the riskiest of the three Enterprise policies, in that such
|
||||
legacy CAs can represent the greatest security threat to an organization, as
|
||||
they lack either the audits or compliance with industry best practice and root
|
||||
store requirements. Enterprises should only enable this policy if no other
|
||||
option meets their needs.
|
|
@ -0,0 +1,24 @@
|
|||
# Glossary of CT Terms
|
||||
The folloiwing is a list of commonly-used terms used in the Chrome CT Policy, Chrome Log Policy, and RFC 6962:
|
||||
|
||||
**Signed Certificate Timestamp (SCT):**
|
||||
|
||||
**Maximum Merge Delay (MMD):**
|
||||
|
||||
**CT Log:**
|
||||
|
||||
**Log Operator:**
|
||||
|
||||
**CT-enforcing User Agent:**
|
||||
|
||||
**Certification Authority (CA):**
|
||||
|
||||
**CT Log Operator Bug:** All CT Log Operators are required to file a CT Log Operator bug on the Chromium issue tracker in order to apply for inclusion of their CT Log(s) to Chrome. This bug tracks all state changes for all CT Logs operated by this organization.
|
||||
|
||||
**CT Log States:**
|
||||
|
||||
**CT Compliance:**
|
||||
|
||||
**Temporal Sharding:** CT Logs that specify a certificate expiry range and reject logging submissions for certificates that expire outside of this range are said to be temporally sharded. To provide for ecosystem agility and limit CT Log size, all new CT Logs are required to be temporally sharded to be added to Chrome.
|
||||
|
||||
**Logging Submission:**
|
|
@ -0,0 +1,70 @@
|
|||
# Recognized Logs
|
||||
|
||||
The following table includes information about the Certificate Transparency Logs
|
||||
that are recognized by Chromium. It includes information about who operates the
|
||||
log, the name the log has been given, and the URL that can be used for logging
|
||||
certificates or inspecting the certificates that have been logged.
|
||||
|
||||
**_Note: The authoritative list is maintained in the [Chromium code base](https://cs.chromium.org/chromium/src/components/certificate_transparency/data/log_list.json). This is merely informational._**
|
||||
|
||||
## Qualified Logs
|
||||
|
||||
| Log Operator | Log Name | Log URL | MMD | Qualified In | Current State |
|
||||
| ----------------------------------------- | --------------------------------------- | ------------------------------------------ | -------- | ------------------------------------- | ------------- |
|
||||
| [Google](https://www.google.com/) | Google 'Aviator' Log | https://ct.googleapis.com/aviator | 24 hours | [Chrome 35](https://crrev.com/237785) | Read Only |
|
||||
| [Google](https://www.google.com/) | Google 'Pilot' Log | https://ct.googleapis.com/pilot/ | 24 hours | [Chrome 35](https://crrev.com/237785) | Usable |
|
||||
| [DigiCert](https://www.digicert.com/) | DigiCert's Certificate Transparency log | https://ct1.digicert-ct.com/log/ | 24 hours | [Chrome 41](https://crrev.com/309831) | Usable |
|
||||
| [Google](https://www.google.com/) | Google 'Rocketeer' Log | https://ct.googleapis.com/rocketeer | 24 hours | [Chrome 43](https://crrev.com/325382) | Usable |
|
||||
| [Google](https://www.google.com/) | Google 'Icarus' Log | https://ct.googleapis.com/icarus/ | 24 hours | [Chrome 55](https://crrev.com/429670) | Usable |
|
||||
| [Google](https://www.google.com/) | Google 'Skydiver' Log | https://ct.googleapis.com/skydiver/ | 24 hours | [Chrome 55](https://crrev.com/429670) | Usable |
|
||||
| [Sectigo](https://sectigo.com/) | Sectigo 'Mammoth' Log | https://mammoth.ct.comodo.com/ | 24 hours | [Chrome 60](https://crrev.com/482145) | Usable |
|
||||
| [Sectigo](https://sectigo.com/) | Sectigo 'Sabre' Log | https://sabre.ct.comodo.com/ | 24 hours | [Chrome 60](https://crrev.com/482145) | Usable |
|
||||
| [Cloudflare](https://www.cloudflare.com/) | Cloudflare 'Nimbus2020' Log | https://ct.cloudflare.com/logs/nimbus2020/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Usable |
|
||||
| [Cloudflare](https://www.cloudflare.com/) | Cloudflare 'Nimbus2021' Log | https://ct.cloudflare.com/logs/nimbus2021/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Usable |
|
||||
| [Google](https://www.google.com/) | Google 'Argon2020' Log | https://ct.googleapis.com/logs/argon2020/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Usable |
|
||||
| [Google](https://www.google.com/) | Google 'Argon2021' Log | https://ct.googleapis.com/logs/argon2021/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Usable |
|
||||
| [DigiCert](https://www.digicert.com/) | DigiCert 'Yeti2020' Log | https://yeti2020.ct.digicert.com/log/ | 24 hours | [Chrome 67](https://crrev.com/559734) | Usable |
|
||||
| [DigiCert](https://www.digicert.com/) | DigiCert 'Yeti2021' Log | https://yeti2021.ct.digicert.com/log/ | 24 hours | [Chrome 67](https://crrev.com/559734) | Usable |
|
||||
| [DigiCert](https://www.digicert.com/) | DigiCert 'Yeti2022' Log | https://yeti2022.ct.digicert.com/log/ | 24 hours | [Chrome 67](https://crrev.com/559734) | Usable |
|
||||
| [DigiCert](https://www.digicert.com/) | DigiCert 'Nessie2020' Log | https://nessie2020.ct.digicert.com/log/ | 24 hours | [Chrome 72](https://crrev.com/620903) | Usable |
|
||||
| [DigiCert](https://www.digicert.com/) | DigiCert 'Nessie2021' Log | https://nessie2021.ct.digicert.com/log/ | 24 hours | [Chrome 72](https://crrev.com/620903) | Usable |
|
||||
| [DigiCert](https://www.digicert.com/) | DigiCert 'Nessie2022' Log | https://nessie2022.ct.digicert.com/log/ | 24 hours | [Chrome 72](https://crrev.com/620903) | Usable |
|
||||
| [Google](https://www.google.com/) | Google 'Xenon2020' Log | https://ct.googleapis.com/logs/xenon2020/ | 24 hours | [Chrome 73](https://crrev.com/634940) | Usable |
|
||||
| [Google](https://www.google.com/) | Google 'Xenon2021' Log | https://ct.googleapis.com/logs/xenon2021/ | 24 hours | [Chrome 73](https://crrev.com/634940) | Usable |
|
||||
| [Google](https://www.google.com/) | Google 'Xenon2022' Log | https://ct.googleapis.com/logs/xenon2022/ | 24 hours | [Chrome 73](https://crrev.com/634940) | Usable |
|
||||
| [Cloudflare](https://www.cloudflare.com/) | Cloudflare 'Nimbus2022' Log | https://ct.cloudflare.com/logs/nimbus2022/ | 24 hours | [Chrome 76](https://crrev.com/666475) | Usable |
|
||||
| [Cloudflare](https://www.cloudflare.com/) | Cloudflare 'Nimbus2023' Log | https://ct.cloudflare.com/logs/nimbus2023/ | 24 hours | [Chrome 76](https://crrev.com/666475) | Usable |
|
||||
| [DigiCert](https://www.digicert.com/) | DigiCert 'Nessie2023' Log | https://nessie2023.ct.digicert.com/log/ | 24 hours | [Chrome 76](https://crrev.com/666475) | Usable |
|
||||
| [DigiCert](https://www.digicert.com/) | DigiCert 'Yeti2023' Log | https://yeti2023.ct.digicert.com/log/ | 24 hours | [Chrome 76](https://crrev.com/666475) | Usable |
|
||||
| [Google](https://www.google.com/) | Google 'Xenon2023' Log | https://ct.googleapis.com/logs/xenon2023/ | 24 hours | [Chrome 77](https://crrev.com/689620) | Usable |
|
||||
| [Google](https://www.google.com/) | Google 'Argon2022' Log | https://ct.googleapis.com/logs/argon2022/ | 24 hours | [Chrome 77](https://crrev.com/689620) | Usable |
|
||||
| [Google](https://www.google.com/) | Google 'Argon2023' Log | https://ct.googleapis.com/logs/argon2023/ | 24 hours | [Chrome 77](https://crrev.com/689620) | Usable |
|
||||
| [Let's Encrypt](https://letsencrypt.org/) | Let's Encrypt 'Oak2020' Log | https://oak.ct.letsencrypt.org/2020/ | 24 hours | [Chrome 78](https://crrev.com/703880) | Usable |
|
||||
| [Let's Encrypt](https://letsencrypt.org/) | Let's Encrypt 'Oak2021' Log | https://oak.ct.letsencrypt.org/2021/ | 24 hours | [Chrome 78](https://crrev.com/703880) | Usable |
|
||||
| [Let's Encrypt](https://letsencrypt.org/) | Let's Encrypt 'Oak2022' Log | https://oak.ct.letsencrypt.org/2022/ | 24 hours | [Chrome 78](https://crrev.com/703880) | Usable |
|
||||
|
||||
### Once, but no longer, Qualified Logs
|
||||
|
||||
| Log Operator | Name | Log URL | MMD | Qualified In | Last Accepted SCT |
|
||||
| ----------------------------------------- | --------------------------- | ------------------------------------------ | -------- | ------------------------------------- | ---------------------------- |
|
||||
| [Certly](https://certly.io/) | Certly.IO Log | https://log.certly.io | 24 hours | [Chrome 43](https://crrev.com/325382) | 15 April 2016 00:00:00 UTC. |
|
||||
| [Izenpe](https://www.izenpe.com/) | Izenpe Log | https://ct.izenpe.com | 24 hours | [Chrome 44](https://crrev.com/326301) | 30 May 2016 00:00:00 UTC. |
|
||||
| [Venafi](https://www.venafi.com/) | Venafi CT Log Server | https://ctlog.api.venafi.com/ct/v1 | 24 hours | [Chrome 47](https://crrev.com/349170) | 28 Feb 2017 18:42:26 UTC. |
|
||||
| [WoSign](https://www.wosign.com/) | WoSign Log | https://ctlog.wosign.com/ | 24 hours | [Chrome 54](https://crrev.com/414378) | 12 Feb 2018 23:59:59 UTC. |
|
||||
| [StartCom](https://www.startssl.com/) | StartCom CT Log | https://ct.startssl.com/ | 24 hours | [Chrome 54](https://crrev.com/414440) | 12 Feb 2018 23:59:59 UTC. |
|
||||
| [CNNIC](https://cnnic.cn/) | CNNIC CT Log | https://ctserver.cnnic.cn/ | 24 hours | [Chrome 53](https://crrev.com/396817) | 18 Sep 2018 00:00:00 UTC. |
|
||||
| [DigiCert](https://www.digicert.com/) | Symantec Log | https://ct.ws.symantec.com | 24 hours | [Chrome 45](https://crrev.com/483625) | 16 Feb 2019 00:00:00 UTC. |
|
||||
| [DigiCert](https://www.digicert.com/) | Symantec 'Vega' Log | https://vega.ws.symantec.com/ | 24 hours | [Chrome 50](https://crrev.com/376143) | 16 Feb 2019 00:00:00 UTC. |
|
||||
| [DigiCert](https://www.digicert.com/) | Symantec 'Sirius' Log | https://sirius.ws.symantec.com/ | 24 hours | [Chrome 60](https://crrev.com/481160) | 16 Feb 2019 00:00:00 UTC. |
|
||||
| [Google](https://www.google.com/) | Google 'Argon2018' Log | https://ct.googleapis.com/logs/argon2018/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Rejected - Shard Expired |
|
||||
| [Cloudflare](https://www.cloudflare.com/) | Cloudflare 'Nimbus2018' Log | https://ct.cloudflare.com/logs/nimbus2018/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Rejected - Shard Expired |
|
||||
| [DigiCert](https://www.digicert.com/) | DigiCert 'Yeti2018' Log | https://yeti2018.ct.digicert.com/log/ | 24 hours | [Chrome 67](https://crrev.com/559734) | Rejected - Shard Expired |
|
||||
| [DigiCert](https://www.digicert.com/) | DigiCert 'Nessie2018' Log | https://nessie2018.ct.digicert.com/log/ | 24 hours | [Chrome 72](https://crrev.com/620903) | Rejected - Shard Expired |
|
||||
| [Cloudflare](https://www.cloudflare.com/) | Cloudflare 'Nimbus2019' Log | https://ct.cloudflare.com/logs/nimbus2019/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Rejected - Shard Expired |
|
||||
| [DigiCert](https://www.digicert.com/) | DigiCert 'Yeti2019' Log | https://yeti2019.ct.digicert.com/log/ | 24 hours | [Chrome 67](https://crrev.com/559734) | Rejected - Shard Expired |
|
||||
| [DigiCert](https://www.digicert.com/) | DigiCert 'Nessie2019' Log | https://nessie2019.ct.digicert.com/log/ | 24 hours | [Chrome 72](https://crrev.com/620903) | Rejected - Shard Expired |
|
||||
| [Google](https://www.google.com/) | Google 'Argon2019' Log | https://ct.googleapis.com/logs/argon2019/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Rejected - Shard Expired |
|
||||
| [Google](https://www.google.com/) | Google 'Xenon2019' Log | https://ct.googleapis.com/logs/xenon2019/ | 24 hours | [Chrome 73](https://crrev.com/634940) | Rejected - Shard Expired |
|
||||
| [Let's Encrypt](https://letsencrypt.org/) | Let's Encrypt 'Oak2019' Log | https://oak.ct.letsencrypt.org/2019/ | 24 hours | [Chrome 78](https://crrev.com/703880) | Rejected - Shard Expired |
|
||||
| [Venafi](https://www.venafi.com/) | Venafi Gen2 CT log | https://ctlog-gen2.api.venafi.com/ | 24 hours | [Chrome 59](https://crrev.com/471318) | Rejected - All Certs Expired |
|
||||
| [DigiCert](https://www.digicert.com/) | DigiCert Log Server 2 | https://ct2.digicert-ct.com/log/ | 24 hours | [Chrome 60](https://crrev.com/481160) | 04 May 2020 00:00:40 UTC |
|
157
log_policy.md
157
log_policy.md
|
@ -1,110 +1,83 @@
|
|||
# Certificate Transparency Log Policy
|
||||
As specified by [RFC 6962](https://tools.ietf.org/html/rfc6962), Certificate Transparency includes a multi-party protocol for providing cryptographically-verifiable proofs to audit the issuance and security practices of Certificate Authorities.
|
||||
|
||||
To improve trust and security when communicating with secure services,
|
||||
Chromium-derived products, such as Google Chrome, will require certificates
|
||||
presented by servers to be publicly audited using Certificate Transparency.
|
||||
As specified by [RFC 6962](https://tools.ietf.org/html/rfc6962), Certificate
|
||||
Transparency includes a multi-party protocol for providing
|
||||
cryptographically-verifiable proofs to audit the issuance and security
|
||||
practices of Certificate Authorities.
|
||||
To support such auditing, Chrome includes a list of Logs that have passed an application process and are recognized to be operating in the public interest. This Certificate Transparency Log Policy ("Policy") sets forth how a Certificate Transparency Log Operator may have its Log recognized within Chrome as well as the ongoing expectations of these Log Operators. This policy may be updated by Google from time to time.
|
||||
|
||||
To support such auditing, Chromium-derived products include a list of Logs
|
||||
that are recognized to be operating in the public interest. This Certificate
|
||||
Transparency Log Policy ("Policy") sets forth how a Certificate Transparency
|
||||
Log Operator may have its Log recognized within Chromium, ongoing expectations
|
||||
of Log Operators, and how Chromium developers may preserve the integrity of
|
||||
recognized Logs. This policy may be updated by Google from time to time.
|
||||
---
|
||||
|
||||
When a Log is recognized, Signed Certificate Timestamps (SCT) issued by that
|
||||
Log will be granted special treatment within the Chromium user interfaces,
|
||||
such as by indicating that the associated certificate certified by the SCT has
|
||||
been publicly noted by the Log Operator.
|
||||
## Application Process
|
||||
Before applying for their first CT Logs to be added to Chrome, new CT Log Operators should first read and fully comprehend the ongoing requirements for CT Logs specified in this Policy. Once a Log Operator is confident they can meet these requirements and has deployed a set of temporally-sharded CT Logs ready for application, they should follow the below process for adding these Logs to Chrome.
|
||||
|
||||
## Application
|
||||
### New CT Log Operators
|
||||
New CT Log Operators should begin their application process by first [filing a new CT Log Operator bug](https://bugs.chromium.org/p/chromium/issues/entry) on the Chromium Issue Tracker, and provide:
|
||||
* Contact Information for the Log Operator, including:
|
||||
* An email or e-mail alias that is continuously monitored by the Log Operator
|
||||
* A list of person(s) authorized to represent the Log Operator when communicating with the Chrome team
|
||||
|
||||
To apply for a Log to be included within Chromium, the Log Operator must
|
||||
[file a new bug](https://bugs.chromium.org/p/chromium/issues/entry) on the
|
||||
Chromium Issue Tracker, and provide:
|
||||
* Contact Information for the Log Operator, including:
|
||||
* An email or e-mail alias that is continuously monitored by the Log
|
||||
Operator
|
||||
* A phone number
|
||||
* A list of person(s) authorized to represent the Log Operator
|
||||
* A public HTTP endpoint that responds to all Log Client Messages indicated
|
||||
in RFC 6962, Section 4
|
||||
* The Log's public key, attached as a binary file containing the DER
|
||||
encoding of the SubjectPublicKeyInfo ASN.1 structure
|
||||
* A description of the Log, including applicable policies or requirements
|
||||
for logging certificates
|
||||
* The Maximum Merge Delay (MMD) of the Log
|
||||
* All of the Accepted Root Certificates of the Log
|
||||
* Whether the Log will reject certificate logging requests based on any of the Permissible Logging Rejection Criteria and if so, which criteria will be used as a basis for rejection by this Log.
|
||||
This bug will be used to track all CT Logs operated by this Log Operator for as long as any Logs operated by this organization are `Pending`, `Qualified`, `Usable`, `ReadOnly`, or `Retired`. By creating a new CT Log Operator bug, applicants are asserting they are organizationally independent from all existing CT Log Operators, which can be observed in the [log_list.json](https://www.gstatic.com/ct/log_list/v2/log_list.json) file hosted by Google. If an organizational change occurs that alters this independence, CT Log Operators are required to notify Chrome at chrome-certificate-transparency@google.com as soon as possible.
|
||||
|
||||
After acceptance, Google will monitor the Log, including random compliance
|
||||
testing, prior to its inclusion within Chromium. Such compliance testing will
|
||||
include, but is not limited to, verifying the Log’s conformance to RFC 6962,
|
||||
and confirming the Log's uptime meets the requirements of this Policy and
|
||||
confirming the Log is append-only and consistent from every point of view.
|
||||
### Existing CT Log Operators
|
||||
Once the Chrome team has confirmed the Log Operator’s contact information, or if an existing Log Operator is applying for additional CT Logs to be added to Chrome, the CT Log Operator must next provide the following information about the new CT Logs in their existing CT Log Operator bug:
|
||||
* Public HTTP endpoints that respond to all Log Client Messages indicated in RFC 6962, Section 4
|
||||
* The Logs’ public keys, attached as a binary file containing the DER encoding of the SubjectPublicKeyInfo ASN.1 structure
|
||||
* A description of the Logs, including applicable policies or requirements for logging certificates
|
||||
* The Maximum Merge Delay (MMD) of the Logs
|
||||
* The set of Accepted Root Certificates of the Logs
|
||||
* The expiry ranges of each Log in the form [rangeBegin, rangeEnd).
|
||||
* Certificate expiry ranges for a set of Logs must be contiguous, with no gaps, and each expiry range should be between 6 and 12 months.
|
||||
* Whether the Logs will reject logging submissions for expired or revoked certificates.
|
||||
|
||||
To enable monitoring, log operators are asked to include Google's
|
||||
["Merge Delay Monitor Root"](mmd_monitor_root.crt) in the set of Accepted Root
|
||||
Certificates of their logs.
|
||||
After acceptance, Google will monitor the Logs, including random compliance testing, prior to its inclusion within Chrome. Such compliance testing will include, but is not limited to, verifying the Logs’ conformance to RFC 6962, confirming the Logs’ availability meets the requirements of this Policy, and confirming the Logs are append-only and consistent from every point of view.
|
||||
|
||||
To enable compliance monitoring, Log Operators will be asked to include Google's Merge Delay Monitor Root certificate in the set of accepted root certificates of their Logs.
|
||||
|
||||
---
|
||||
|
||||
## Ongoing Requirements of Included Logs
|
||||
In order for their Logs to remain included within Chrome after first becoming `Qualified`, Log Operators must continue to operate these Logs in accordance with this Policy. Log Operators must:
|
||||
* Monitor the [ct-policy@chromium.org](https://groups.google.com/a/chromium.org/forum/#!forum/ct-policy) group for relevant updates to policy or requirements for CT Log Operators
|
||||
* Have no outage that exceeds an MMD of more than 24 hours. Outages include, but are not limited to: network level outages, expiration of the Log’s SSL certificate, a failure to accept new Certificates to be logged (with the exception of the conditions defined in the Logging Submission Acceptance section below), HTTP response status codes other than 200, or responses that include data that does not conform to RFC 6962.
|
||||
* Conform to RFC 6962, including the implementation of all API endpoints defined within Section 4 of RFC 6962
|
||||
* Not impose conditions on retrieving or sharing data from the Logs
|
||||
* Maintain Log availability of 99% or above, with no outage lasting longer than the MMD (as measured by Google)
|
||||
* Not present two or more conflicting views of the Merkle Tree at different times and/or to different parties.
|
||||
* Incorporate a certificate for which an SCT has been issued by the Log within the MMD.
|
||||
* When Logs receive a logging submission for an already-incorporated certificate, Logs must either return an existing SCT or, if creating a new one, add another certificate entry within the MMD such that the new SCT can be verified using the APIs specified in RFC 6962.
|
||||
* Accept certificates issued by Google’s Merge Delay Monitor Root to enable Google to monitor the Log’s compliance to these policies.
|
||||
* Operate their Logs in good faith, including, but not limited to each Log Operator:
|
||||
* Verifiably incorporating all certificates into the Log for which SCTs have been issued, within the Log’s MMD
|
||||
* Maintaining the append-only property of the Log by providing consistent views of the Merkle Tree at all times and to all parties.
|
||||
* Notify the Chrome team of any and all changes to information gathered during the Log Inclusion by detailing such changes in an update to the CT Log Operator bug on the [Chromium Issue Tracker](https://bugs.chromium.org/p/chromium/issues/list?q=component%3AInternals%3ENetwork%3ECertTrans) in which they requested Log Inclusion.
|
||||
|
||||
To remain included within Chromium-derived projects, Log Operators must
|
||||
operate the Log in accordance with this Policy. Log Operators must:
|
||||
Google will notify Log Operators of changes to these requirements as well as effective dates for those changes via announcements to the [ct-policy@chromium.org](https://groups.google.com/a/chromium.org/forum/#!forum/ct-policy). Log Operators that fail to meet these requirements will be in violation of this Policy, which may result in removal of the Log(s) from Chrome.
|
||||
|
||||
* Have no outage that exceeds an MMD of more than 24 hours.
|
||||
Outages include, but are not limited to: network level outages, expiration
|
||||
of the Log’s SSL certificate, a failure to accept new Certificates to be
|
||||
logged (with the exception of the Permissible Logging Rejection Criteria defined below), HTTP response status codes other than 200, or responses that
|
||||
include data that does not conform to RFC 6962.
|
||||
* Conform to RFC 6962, including the implementation of all API endpoints
|
||||
defined within Section 4 of RFC 6962
|
||||
* Not impose conditions on retrieving or sharing data from the Log
|
||||
* Have 99% uptime, with no outage lasting longer than the MMD (as measured
|
||||
by Google)
|
||||
* Not present two or more conflicting views of the Merkle Tree at different
|
||||
times and/or to different parties.
|
||||
* Incorporate a certificate for which an SCT has been issued by the Log
|
||||
within the MMD.
|
||||
* If requested, accept certificates issued by a test CA run by Google to
|
||||
enable Google to monitor the log’s compliance to these policies.
|
||||
* Be operated in good faith, including, but not limited to each Log
|
||||
Operator:
|
||||
* Verifiably logging all certificates within the Log for which SCTs have
|
||||
been issued within the MMD
|
||||
* Maintaining the append-only property of the of the Log by providing
|
||||
consistent views of the Merkle Tree at all times and to all parties.
|
||||
* Notify the Chromium developers of any and all changes to information
|
||||
gathered during the Log Inclusion by detailing such changes in an update
|
||||
to the bug on the [Chromium Issue Tracker](https://bugs.chromium.org/p/chromium/issues/list?q=component%3AInternals%3ENetwork%3ECertTrans)
|
||||
in which they requested Log Inclusion.
|
||||
---
|
||||
|
||||
Google will notify Log Operators, via announcements to the
|
||||
[Chromium CT Policy Group](https://groups.google.com/a/chromium.org/forum/#!forum/ct-policy),
|
||||
of changes to these requirements. Log Operators that fail to meet these
|
||||
requirements will be in violation of the Log Inclusion Policy, which may
|
||||
result in removal of the Log from the Chromium projects.
|
||||
## Logging Submission Policy
|
||||
### Accepted Root Certificates
|
||||
In order to maintain broad utility to Chrome and its users, CT Logs are expected to accept logging submissions from CAs that are trusted by default in Chrome across all its supported platforms, including ChromeOS, Android, Linux, Windows, macOS, iOS. If a Log Operator plans to restrict the set of Accepted Root Certificates, this should be clearly stated in the CT Log Operator Application as well as the rationale for this restriction. **Note:** This restriction may prevent a CT Log from being accepted by Chrome for inclusion.
|
||||
|
||||
## Permissible Logging Rejection Criteria
|
||||
### Rejecting Logging Submissions
|
||||
CT Logs are permitted to reject logging submissions for certificates that meet certain conditions, such as being expired or revoked at the time the submission was made. A logging rejection means that the CT Log will not incorporate a given certificate entry into the Merkle Tree even if the certificate chains to an Accepted Root Certificate. Rejected logging submissions **must not** be issued an SCT by the CT Log.
|
||||
|
||||
Under certain circumstances, it is permissible for a Log to reject logging requests for certain classes of certificates. A logging rejection means that the Log will not incorporate a given certificate entry into the Merkle Tree even if the certificate chains to an Accepted Root Certificate. In accordance with this policy, rejected logging requests must not be issued an SCT by the Log.
|
||||
|
||||
If specified within the Log's Chromium Application, a Log may reject requests to log certificates that chain up to an Accepted Root Certificate based on one or more of the following bases:
|
||||
|
||||
* **Revocation Status**: If the Log determines that a certificate has been revoked by the issuing CA, it may reject the logging request. If the Log is unable to determine revocation status, it must accept the logging request and incorporate the entry into the Merkle Tree within the Log's MMD.
|
||||
* **Certificate Expired**: If a logging request includes a certificate whose notAfter timestamp represents a point in time before the logging request is made, the Log may refuse to log the certificate entry.
|
||||
* **Certificate Lifetime**: In order to control the growth of a Log’s size, a Log Operator may specify a certificate expiry range for that Log, which must be included in the Log’s Chromium Application in the form of two dates: [rangeBegin, rangeEnd). The certificate expiry range allows a Log to reject logging requests for certificates whose notAfter timestamp falls outside of this range, thus partitioning the set of publicly-trusted certificates that the Log will accept. In the spirit of operating Logs in the public interest, Log Operators who take advantage of this limitation are strongly encouraged to operate multiple Logs with staggered certificate expiry ranges to allow for logging of all currently valid publicly-trusted certificates.
|
||||
If specified within the Application, a Log may reject submission to log certificates that chain up to an Accepted Root Certificate based on one or more of the following conditions:
|
||||
* **Certificate Revoked:** If the Log determines that a certificate has been revoked by the issuing CA, it may reject the logging submission. If the Log is unable to determine revocation status, it must accept the logging submission and incorporate the entry into the Merkle Tree within the Log's MMD.
|
||||
* **Certificate Expired:** If a logging submission includes a certificate whose notAfter timestamp represents a point in time before the logging submission was made, the Log may refuse to log the certificate entry. This criteria may be used even by legacy non-sharded CT Logs that do not set certificate expiry ranges.
|
||||
|
||||
The primary purpose of the permissible rejection criteria is to provide Log Operators with greater control over the growth and operation of a given Log instance while still performing the core functions of a trusted CT Log. Additionally, these criteria allow logs to be shielded from certain types of Denial of Service such as being spammed with the corpus of all expired certificates and being unable to respond to legitimate logging requests.
|
||||
The primary purpose of allowing rejection of certain logging submissions is to provide Log Operators with greater control over the growth and operation of their Logs while still performing their core function. Additionally, these criteria allow Logs to be shielded from certain types of Denial of Service such as being spammed with the corpus of all expired certificates and being unable to respond to legitimate logging submissions.
|
||||
|
||||
### Temporal Sharding
|
||||
In order to provide ecosystem agility and to control the growth of CT Log sizes, new CT Logs must be *temporally sharded*, defining a *certificate expiry range* denoted in the form of two dates: [rangeBegin, rangeEnd). The certificate expiry range allows a Log to reject otherwise valid logging submissions for certificates that expire before or after this defined range, thus partitioning the set of publicly-trusted certificates that each Log will accept.
|
||||
|
||||
In order to have their Logs accepted for inclusion, Log Operators should deploy and operate their Logs according to the following:
|
||||
* The certificate expiry ranges for CT Logs must be no longer than one calendar year and should be no shorter than six months
|
||||
* CT Logs must reject logging submissions for certificates whose notAfter timestamp falls outside the certificate expiry range
|
||||
* Log Operators should deploy enough sharded CT Logs so that their certificate expiry ranges cover a contiguous period of time, spanning from the current time to 3-4 years in the future
|
||||
* Many Log Operators find it convenient to define these ranges on the calendar year, so an application in 2020 would include e.g. Log2020, Log2021, Log2022, Log2023.
|
||||
* CT Logs will be removed from Chrome once their certificate expiry range has passed. When Log Operators in good standing have one of their Logs removed in this manner, they should stand up a new CT Log whose expiry range extends the set of contiguous expiry ranges
|
||||
* Following the example from above, when Log2020 is removed in early 2021, the Log Operator should stand up Log2024 and apply for its inclusion, following the Application Process defined above.
|
||||
|
||||
---
|
||||
|
||||
## Policy Violations
|
||||
|
||||
The Chromium developers include Logs at their sole discretion, to further
|
||||
public auditability of Certificate Authorities. Upon learning of a Log’s
|
||||
potential violation of this Policy, the Chromium Authors will review the
|
||||
information and may take corrective actions to preserve the integrity of its
|
||||
Log program. The Chromium Authors may remove Logs at any time, and for any
|
||||
reason.
|
||||
The Chrome team includes CT Logs at their sole discretion, to further public auditability of Certificate Authorities. Upon learning of a Log’s potential violation of this Policy, they will review the information and may take corrective actions to preserve the integrity of its CT Log program. CT Logs may be removed from Chrome at any time, and for any reason.
|
||||
|
|
|
@ -0,0 +1,147 @@
|
|||
# Certificate Transparency Log Lifecycle
|
||||
## Introduction
|
||||
Certificate Transparency (CT) is a technology and an ecosystem designed to ensure that TLS certificates issued by publicly-trusted Certification Authorities (CAs) are detectable by website operators shortly after they are first able to validate in CT-enforcing user agents, such as Chrome. In order to achieve this goal, user agents rely on organizations called Log Operators to stand up and operate infrastructure called CT Logs and apply for inclusion to be recognized by these user agents.
|
||||
The purpose of this document is to describe the lifecycle of a CT Log, represented by a set of states and state transitions, and explain what these states mean for Log Operators, CAs, CT Monitors, Site Operators, and Chrome.
|
||||
|
||||
---
|
||||
|
||||
## CT Log State Machine
|
||||
When the JSON schema for CT Log Lists was updated to [v2](https://www.gstatic.com/ct/log_list/v2/log_list_schema.json) in 2019, several CT Log states were formalized that did not exist when the CT enforcement logic in Chrome was implemented. Some of these states are related to CT enforcement, others represent a stage of the CT Log application process, while others still are external signals to CAs and CT Monitors.
|
||||
|
||||
```
|
||||
+------------------------+
|
||||
| |
|
||||
| V
|
||||
PENDING ---> QUALIFIED ---> USABLE ---> READONLY----+
|
||||
| | | | | | |
|
||||
| | | | | V |
|
||||
| | +--------|---+----> RETIRED |
|
||||
| | | | V
|
||||
+-----------+------------+-------------+----> REJECTED
|
||||
```
|
||||
|
||||
In the above state machine, the nodes represent all possible CT Log states and the directional edges represent possible state transitions. The remainder of this document describes how CT Logs transition into and out of these states, what is expected of CT Logs in these states, and finally, how the CT Log states map to Chrome behavior.
|
||||
|
||||
---
|
||||
|
||||
## `Pending`
|
||||
When a Log Operator requests for a CT Log to be added to Chrome, the CT Log is first placed into the `Pending` state. While the Log undergoes its initial compliance monitoring period, it remains in the `Pending` state until it is either added to Chrome or a determination is made to reject the application.
|
||||
|
||||
**How `Pending` CT Logs transition to other states:**
|
||||
* `Pending` CT Logs transition to `Qualified` when they are first added to Chrome after a successful compliance monitoring period.
|
||||
* `Pending` CT Logs transition to `Rejected` if serious or sustained violations of RFC 6962 or the [CT Log Policy](log_policy.md) are detected during the application process, or if the Log Operator indicates they are withdrawing the application for inclusion in Chrome.
|
||||
|
||||
**Expected Log Behavior:**
|
||||
|
||||
While in the `Pending` state, CT Logs are expected to abide by all ongoing requirements defined in the [Certificate Transparency Log Policy](log_policy.md), including availability requirements, RFC compliance, and timely notification of changes to Log Operation.
|
||||
|
||||
**Chrome Behavior:**
|
||||
|
||||
`Pending` Logs are not included in the CT Log List in Chrome. When evaluated in CT-enforcing versions of Chrome, SCTs from CT Logs in the `Pending` state at time of check do not contribute towards CT Compliance for either the Embedded SCT or the OCSP/TLS SCT criteria.
|
||||
|
||||
---
|
||||
|
||||
## `Qualified`
|
||||
CT Logs that successfully pass the initial compliance monitoring period are placed in the `Qualified` state if there are no major issues observed during this period. `Qualified` CT Logs are added to the list checked into Chromium and get included in a future version of Chrome. `Qualified` CT Logs must meet an ongoing set of compliance and availability requirements in order to remain included in Chrome.
|
||||
|
||||
**How `Qualified` CT Logs transition to other states:**
|
||||
* `Qualified` CT Logs transition to `Usable` within a fixed period of time after becoming `Qualified`, so long as they continue to comply with the [CT Log Policy](log_policy.md).
|
||||
* `Qualified` CT Logs transition to `Retired` if they demonstrate a serious or sustained pattern of CT Policy or RFC compliance issues, or if the Log Operator ceases operation of their CT Log(s). Due to the inability for Chrome to distinguish between intentional and accidental non-compliance, such issues are treated as highest possible severity, which results in the CT Log being `Retired`.
|
||||
* `Qualified` CT Logs transition to `Rejected` if all certificates contained therein are expired or if it is past the end of their certificate expiry range specified in their Chromium CT Log application. Notably, the `Qualified` to `Rejected` transition is not used as a more severe response to a CT Log’s compliance issues.
|
||||
|
||||
**Expected Log Behavior:**
|
||||
|
||||
While in the `Qualified` state, CT Logs are expected to abide by all ongoing requirements defined in the [Certificate Transparency Log Policy](log_policy.md), including availability requirements, RFC compliance, and timely notification of changes to Log Operation.
|
||||
|
||||
**Chrome Behavior:**
|
||||
|
||||
`Qualified` CT Logs are periodically imported to the list of CT Logs recognized by Chrome. When evaluated in CT-enforcing versions of Chrome, SCTs from CT Logs in the `Qualified` state at time of check contribute towards CT Compliance for both the Embedded SCT and the OCSP/TLS SCT criteria.
|
||||
|
||||
---
|
||||
|
||||
## `Usable`
|
||||
Once a CT Log becomes `Qualified`, there will be a period of time in which older versions of Chrome are still enforcing CT but are not yet aware of this newly `Qualified` CT Log. Certificates accompanied by SCTs from such a newly-`Qualified` CT Log would fail validation in these non-updated clients, so the `Qualified` Log state is insufficient on its own to indicate safeness for production CT Logging. The `Usable` Log state captures this notion of safety by indicating to CAs and site operators that all CT-enforcing versions of Chrome now recognize a given newly-`Qualified` CT Log.
|
||||
|
||||
Newly-`Qualified` CT Logs become `Usable` when they have been added to the CT Log List for all CT-enforcing versions of Chrome. This is achieved either by Chrome clients updating to a version in which this CT Log has been added or by older clients becoming 10 or more weeks out-of-date and thus disabling CT enforcement. Rather than being a distinct state recognized by any given Chrome client, the `Usable` state can be thought of as a signal to the CT ecosystem, representing the distributed state of all CT-enforcing user agents now recognizing these CT Logs.
|
||||
|
||||
**How `Usable` CT Logs transition to other states:**
|
||||
* `Usable` CT Logs transition to `Retired` if they demonstrate a serious or sustained pattern of CT Policy or RFC compliance issues, or if the Log Operator ceases operation of their CT Log(s). Due to the inability for Chrome to distinguish between intentional and accidental non-compliance, such issues are treated as highest possible severity, which results in the CT Log being `Retired`.
|
||||
* `Usable` CT Logs transition to `Rejected` if all certificates contained therein are expired or if it is past the end of their certificate expiry range specified in their CT Log application. Notably, the `Usable` to `Rejected` transition is not used as a more severe response to a CT Log’s compliance issues.
|
||||
|
||||
**Expected Log Behavior:**
|
||||
|
||||
While in the `Usable` state, CT Logs are expected to abide by all ongoing requirements defined in the [Certificate Transparency Log Policy](log_policy.md), including availability requirements, RFC compliance, and timely notification of changes to Log Operation.
|
||||
|
||||
**Chrome Behavior:**
|
||||
|
||||
The `Usable` state is not a state that is specifically recognized by Chrome clients and is functionally equivalent to `Qualified` and `ReadOnly` in terms of SCTs from such Logs contributing towards CT compliance.
|
||||
|
||||
`Usable` CT Logs are imported to the list of CT Logs recognized by Chrome, usually from when they first became `Qualified`. When evaluated in CT-enforcing versions of Chrome, SCTs from CT Logs in the `Usable` state at time of check contribute towards CT Compliance for both the Embedded SCT and the OCSP/TLS SCT criteria.
|
||||
|
||||
---
|
||||
|
||||
## `ReadOnly`
|
||||
If a Log Operator wishes to cease accepting certificate logging requests, they may request that their `Qualified` or `Usable` CT Log(s) be placed in the `ReadOnly` state. CT Logs that become `ReadOnly` mode are making an assertion that they will stop issuing new SCTs, but will continue to operate the CT Log in accordance with the [Certificate Transparency Log Policy](log_policy.md).
|
||||
|
||||
When a Log becomes `ReadOnly`, the final tree size is published to the Google-hosted [CT Log List](https://www.gstatic.com/ct/log_list/v2/log_list.json) to signal that this Log should not grow past this point. To help ensure this behavior, CT Monitors should continue monitoring `ReadOnly` Logs until they become `Retired` or `Rejected`.
|
||||
|
||||
**How `ReadOnly` CT Logs transition to other states:**
|
||||
* `ReadOnly` CT Logs transition to `Retired` if they demonstrate a serious or sustained pattern of CT Policy or RFC compliance issues, or if the Log Operator ceases operation of their CT Log(s). Due to the inability for Chrome to distinguish between intentional and accidental non-compliance, such issues are treated as highest possible severity, which results in the CT Log being `Retired`.
|
||||
* `ReadOnly` CT Logs transition to `Rejected` if all certificates contained therein are expired or if it is past the end of their certificate expiry range specified in their CT Log application. Notably, the `ReadOnly` to `Rejected` transition is not used as a more severe response to a CT Log’s compliance issues.
|
||||
|
||||
**Expected Log Behavior:**
|
||||
|
||||
While in the `ReadOnly` state, CT Logs are expected to abide by all ongoing requirements defined in the [Certificate Transparency Log Policy](log_policy.md), including availability requirements, RFC compliance, and timely notification of changes to Log Operation.
|
||||
|
||||
**Chrome Behavior:**
|
||||
|
||||
The `ReadOnly` state is not a state that is directly recognized by Chrome clients, but rather is treated as functionally equivalent to `Qualified` and `Usable` in terms of CT enforcement.
|
||||
|
||||
`ReadOnly` CT Logs are imported to the list of CT Logs recognized by Chrome, usually from when they first became `Qualified`. When evaluated in CT-enforcing versions of Chrome, SCTs from CT Logs in the `ReadOnly` state at time of check contribute towards CT Compliance for both the Embedded SCT and the OCSP/TLS SCT criteria.
|
||||
|
||||
---
|
||||
|
||||
## `Retired`
|
||||
A `Retired` Log is one that was at one point `Qualified`, but has stopped being relied upon for the creation of new SCTs. CT Logs usually enter the `Retired` state due to a failure to adhere to the ongoing requirements outlined in the [Certificate Transparency Log Policy](log_policy.md).
|
||||
|
||||
To increase the CT ecosystem’s resilience against CT Log failure, existing certificates relying on embedded SCTs that were issued before a Log’s Retirement timestamp can still contribute to CT Compliance for certificates using Embedded SCTs. However, since they can be modified without certificate re-issuance, SCTs delivered via OCSP or TLS must come from CT Logs that are `Qualified`, `Usable`, or `ReadOnly` at time of check.
|
||||
|
||||
**How `Retired` CT Logs transition to other states:**
|
||||
* `ReadOnly` CT Logs transition to `Rejected` if all certificates contained therein are expired or if it is past the end of their certificate expiry range specified in their CT Log application. Notably, the `ReadOnly` to `Rejected` transition is not used as a more severe response to a CT Log’s compliance issues.
|
||||
|
||||
**Expected Log Behavior:**
|
||||
|
||||
Once a CT Log becomes `Retired`, there are no longer any expectations that it continues operation. Log Operators are encouraged to turn down `Retired` CT Logs and securely delete the Log key.
|
||||
|
||||
**Chrome Behavior:**
|
||||
|
||||
`Retired` Logs are included in the [CT Log List](https://cs.chromium.org/chromium/src/components/certificate_transparency/data/log_list.json) that is shipped in Chrome, but include both an indicator that the Log is now `Retired` as well as the corresponding Retirement timestamp.
|
||||
|
||||
Embedded SCTs from `Retired` Logs count towards certain requirements for CT compliance; however, as outlined in [Chrome CT Policy](ct_policy.md), in order for a certificate to be CT Compliant, SCTs from `Retired` Logs must be accompanied by at least one SCT from a Log that was `Qualified`, `Usable`, or `ReadOnly` at time of check.
|
||||
|
||||
SCTs from `Retired` Logs that are delivered via OCSP or TLS do not contribute towards CT Compliance, and failure to include sufficient SCTs from `Qualified`, `Usable`, or `ReadOnly` CT Logs at time of check will result in certificate validation failure in CT-enforcing versions of Chrome.
|
||||
|
||||
---
|
||||
|
||||
## `Rejected`
|
||||
When all certificates contained in a CT Log have expired and the CT Log is no longer issuing new SCTs in response to logging requests, it will transition into the `Rejected` state. Additionally, if a CT Log fails its initial compliance monitoring period, it will skip straight to the `Rejected` state, since there should be no still-valid certificates relying on SCTs from this Log.
|
||||
|
||||
SCTs from `Rejected` CT Logs do not contribute in any way towards CT Compliance and should not be embedded in new certificates or delivered via OCSP or TLS.
|
||||
|
||||
Despite the fact that `Rejected` CT Logs are not included in either the CT Log List shipped in Chrome or the Log List hosted by Google, they are tracked internally to ensure that keys are not reused in future CT Logs applying for inclusion.
|
||||
|
||||
**How `Rejected` CT Logs transition to other states:**
|
||||
* The `Rejected` state is the terminal state of the CT Log Lifecycle state machine. Once a CT Log enters the `Rejected` state, it can no longer transition to any of the other defined states.
|
||||
|
||||
**Expected Log Behavior:**
|
||||
|
||||
Once a CT Log becomes `Rejected`, there are no longer any expectations that it continues operation. Log Operators are encouraged to turn down `Rejected` CT Logs and securely delete the Log key.
|
||||
|
||||
**Chrome Behavior:**
|
||||
|
||||
`Rejected` Logs are not included in the CT Log List in Chrome. When evaluated in CT-enforcing versions of Chrome, SCTs from CT Logs in the `Rejected` state at time of check do not contribute towards CT Compliance for either the Embedded SCT or the OCSP/TLS SCT criteria.
|
||||
|
||||
---
|
||||
|
||||
## Considerations for Chromium Embedders and other CT User Agents
|
||||
With these high-level Log state descriptions in mind, each CT-enforcing user agent may wish to further specify additional context for any of these states; however, it is important that user agent CT Policies remain compatible with one another to ensure CAs and site operators can continue to issue and serve certificates that will successfully validate across multiple user agents. We welcome discussion and feedback about CT Log state definitions in the ct-policy@chromium.org discussion forum.
|
|
@ -0,0 +1,110 @@
|
|||
# Certificate Transparency Log Policy
|
||||
|
||||
To improve trust and security when communicating with secure services,
|
||||
Chromium-derived products, such as Google Chrome, will require certificates
|
||||
presented by servers to be publicly audited using Certificate Transparency.
|
||||
As specified by [RFC 6962](https://tools.ietf.org/html/rfc6962), Certificate
|
||||
Transparency includes a multi-party protocol for providing
|
||||
cryptographically-verifiable proofs to audit the issuance and security
|
||||
practices of Certificate Authorities.
|
||||
|
||||
To support such auditing, Chromium-derived products include a list of Logs
|
||||
that are recognized to be operating in the public interest. This Certificate
|
||||
Transparency Log Policy ("Policy") sets forth how a Certificate Transparency
|
||||
Log Operator may have its Log recognized within Chromium, ongoing expectations
|
||||
of Log Operators, and how Chromium developers may preserve the integrity of
|
||||
recognized Logs. This policy may be updated by Google from time to time.
|
||||
|
||||
When a Log is recognized, Signed Certificate Timestamps (SCT) issued by that
|
||||
Log will be granted special treatment within the Chromium user interfaces,
|
||||
such as by indicating that the associated certificate certified by the SCT has
|
||||
been publicly noted by the Log Operator.
|
||||
|
||||
## Application
|
||||
|
||||
To apply for a Log to be included within Chromium, the Log Operator must
|
||||
[file a new bug](https://bugs.chromium.org/p/chromium/issues/entry) on the
|
||||
Chromium Issue Tracker, and provide:
|
||||
* Contact Information for the Log Operator, including:
|
||||
* An email or e-mail alias that is continuously monitored by the Log
|
||||
Operator
|
||||
* A phone number
|
||||
* A list of person(s) authorized to represent the Log Operator
|
||||
* A public HTTP endpoint that responds to all Log Client Messages indicated
|
||||
in RFC 6962, Section 4
|
||||
* The Log's public key, attached as a binary file containing the DER
|
||||
encoding of the SubjectPublicKeyInfo ASN.1 structure
|
||||
* A description of the Log, including applicable policies or requirements
|
||||
for logging certificates
|
||||
* The Maximum Merge Delay (MMD) of the Log
|
||||
* All of the Accepted Root Certificates of the Log
|
||||
* Whether the Log will reject certificate logging requests based on any of the Permissible Logging Rejection Criteria and if so, which criteria will be used as a basis for rejection by this Log.
|
||||
|
||||
After acceptance, Google will monitor the Log, including random compliance
|
||||
testing, prior to its inclusion within Chromium. Such compliance testing will
|
||||
include, but is not limited to, verifying the Log’s conformance to RFC 6962,
|
||||
and confirming the Log's uptime meets the requirements of this Policy and
|
||||
confirming the Log is append-only and consistent from every point of view.
|
||||
|
||||
To enable monitoring, log operators are asked to include Google's
|
||||
["Merge Delay Monitor Root"](mmd_monitor_root.crt) in the set of Accepted Root
|
||||
Certificates of their logs.
|
||||
|
||||
## Ongoing Requirements of Included Logs
|
||||
|
||||
To remain included within Chromium-derived projects, Log Operators must
|
||||
operate the Log in accordance with this Policy. Log Operators must:
|
||||
|
||||
* Have no outage that exceeds an MMD of more than 24 hours.
|
||||
Outages include, but are not limited to: network level outages, expiration
|
||||
of the Log’s SSL certificate, a failure to accept new Certificates to be
|
||||
logged (with the exception of the Permissible Logging Rejection Criteria defined below), HTTP response status codes other than 200, or responses that
|
||||
include data that does not conform to RFC 6962.
|
||||
* Conform to RFC 6962, including the implementation of all API endpoints
|
||||
defined within Section 4 of RFC 6962
|
||||
* Not impose conditions on retrieving or sharing data from the Log
|
||||
* Have 99% uptime, with no outage lasting longer than the MMD (as measured
|
||||
by Google)
|
||||
* Not present two or more conflicting views of the Merkle Tree at different
|
||||
times and/or to different parties.
|
||||
* Incorporate a certificate for which an SCT has been issued by the Log
|
||||
within the MMD.
|
||||
* If requested, accept certificates issued by a test CA run by Google to
|
||||
enable Google to monitor the log’s compliance to these policies.
|
||||
* Be operated in good faith, including, but not limited to each Log
|
||||
Operator:
|
||||
* Verifiably logging all certificates within the Log for which SCTs have
|
||||
been issued within the MMD
|
||||
* Maintaining the append-only property of the of the Log by providing
|
||||
consistent views of the Merkle Tree at all times and to all parties.
|
||||
* Notify the Chromium developers of any and all changes to information
|
||||
gathered during the Log Inclusion by detailing such changes in an update
|
||||
to the bug on the [Chromium Issue Tracker](https://bugs.chromium.org/p/chromium/issues/list?q=component%3AInternals%3ENetwork%3ECertTrans)
|
||||
in which they requested Log Inclusion.
|
||||
|
||||
Google will notify Log Operators, via announcements to the
|
||||
[Chromium CT Policy Group](https://groups.google.com/a/chromium.org/forum/#!forum/ct-policy),
|
||||
of changes to these requirements. Log Operators that fail to meet these
|
||||
requirements will be in violation of the Log Inclusion Policy, which may
|
||||
result in removal of the Log from the Chromium projects.
|
||||
|
||||
## Permissible Logging Rejection Criteria
|
||||
|
||||
Under certain circumstances, it is permissible for a Log to reject logging requests for certain classes of certificates. A logging rejection means that the Log will not incorporate a given certificate entry into the Merkle Tree even if the certificate chains to an Accepted Root Certificate. In accordance with this policy, rejected logging requests must not be issued an SCT by the Log.
|
||||
|
||||
If specified within the Log's Chromium Application, a Log may reject requests to log certificates that chain up to an Accepted Root Certificate based on one or more of the following bases:
|
||||
|
||||
* **Revocation Status**: If the Log determines that a certificate has been revoked by the issuing CA, it may reject the logging request. If the Log is unable to determine revocation status, it must accept the logging request and incorporate the entry into the Merkle Tree within the Log's MMD.
|
||||
* **Certificate Expired**: If a logging request includes a certificate whose notAfter timestamp represents a point in time before the logging request is made, the Log may refuse to log the certificate entry.
|
||||
* **Certificate Lifetime**: In order to control the growth of a Log’s size, a Log Operator may specify a certificate expiry range for that Log, which must be included in the Log’s Chromium Application in the form of two dates: [rangeBegin, rangeEnd). The certificate expiry range allows a Log to reject logging requests for certificates whose notAfter timestamp falls outside of this range, thus partitioning the set of publicly-trusted certificates that the Log will accept. In the spirit of operating Logs in the public interest, Log Operators who take advantage of this limitation are strongly encouraged to operate multiple Logs with staggered certificate expiry ranges to allow for logging of all currently valid publicly-trusted certificates.
|
||||
|
||||
The primary purpose of the permissible rejection criteria is to provide Log Operators with greater control over the growth and operation of a given Log instance while still performing the core functions of a trusted CT Log. Additionally, these criteria allow logs to be shielded from certain types of Denial of Service such as being spammed with the corpus of all expired certificates and being unable to respond to legitimate logging requests.
|
||||
|
||||
## Policy Violations
|
||||
|
||||
The Chromium developers include Logs at their sole discretion, to further
|
||||
public auditability of Certificate Authorities. Upon learning of a Log’s
|
||||
potential violation of this Policy, the Chromium Authors will review the
|
||||
information and may take corrective actions to preserve the integrity of its
|
||||
Log program. The Chromium Authors may remove Logs at any time, and for any
|
||||
reason.
|
|
@ -0,0 +1,125 @@
|
|||
# Certificate Transparency for Site Operators
|
||||
|
||||
## Basics
|
||||
|
||||
We say that a certificate supports Certificate Transparency if it comes with
|
||||
CT information that demonstrates it has been logged in several CT logs. This
|
||||
CT information must comply with the
|
||||
[Certificate Transparency in Chrome](https://github.com/chromium/ct-policy/blob/master/ct_policy.md)
|
||||
policy. We sometimes refer to a site that "supports" CT as using a certificate
|
||||
that is "CT qualified" or "disclosed via CT."
|
||||
|
||||
In general, a site operator does not need to take special action to
|
||||
support Certificate Transparency. This is because RFC 6962 defines three ways
|
||||
of providing the necessary information for CT: within the certificate, within
|
||||
a stapled OCSP response, or directly by the TLS server. Nearly every CA
|
||||
supports CT through the first method, meaning that when you get a certificate,
|
||||
it will already support CT and require no further configuration. If you are
|
||||
using a cloud provider to terminate your TLS connections, the cloud provider
|
||||
may also support CT via TLS, requiring no further action on your part.
|
||||
|
||||
Supporting CT within the certificate itself is the preferred and recommended
|
||||
way to enable CT support. If you obtain a certificate from your CA and it does
|
||||
not support CT, then that generally indicates that your CA is not following
|
||||
industry best practice, and you should probably look for another CA to provide
|
||||
certificates for your sites.
|
||||
|
||||
Configuring support for CT via the TLS extension is not recommended for most
|
||||
site operators. This is because supporting CT via this method requires
|
||||
constant monitoring of the CT ecosystem, such as for changes in the list of
|
||||
trusted logs or testing compatibility with various CT-supporting clients. This
|
||||
method works well for organizations with the ability to dedicate resources to
|
||||
that, such as hosting and cloud providers. If you are hosting your own website,
|
||||
you should try to ensure that your certificates support CT, and avoid supporting
|
||||
CT via the TLS extension. Supporting CT via the TLS extension may require rapid
|
||||
changes to your configuration, and thus may be riskier for organizations
|
||||
without staff dedicated to this.
|
||||
|
||||
If you are getting longer-lived certificates (for example, 1 year), it's
|
||||
possible that changes in the CT ecosystem may mean that the CT information may
|
||||
expire before the certificate expires. If your CA also supports delivering CT
|
||||
via OCSP responses, then supporting OCSP stapling on your server may allow
|
||||
fresh CT information to be provided without having to replace the certificate.
|
||||
Alternatively, if your server does not support OCSP stapling, or your CA does
|
||||
not support CT in their OCSP responses, you may need to replace your certificate.
|
||||
|
||||
These policies only apply to publicly-trusted CAs - that is, CAs that your
|
||||
browser or device trust without any additional configuration. For organizations
|
||||
using their own CAs, or for locally installed CAs, see
|
||||
[Certificate Transparency for Enterprises](#Certificate-Transparency-For-Enterprises).
|
||||
|
||||
## Domain Privacy
|
||||
|
||||
Supporting CT by disclosing the certificate to a CT Log means that the full
|
||||
contents of the certificate will be publicly accessible and viewable. In
|
||||
particular, this means that the domains a certificate are for will be included
|
||||
in the Certificate Transparency log, as well as the organization they are
|
||||
affiliated with, if they are validated to a level higher than Domain
|
||||
Validation or issued from an organization-specific CA.
|
||||
|
||||
For most certificates, this is no different than what is already available.
|
||||
Publicly-trusted certificates have been subject to aggregation for public
|
||||
analysis for some time, such as through products and tools such as
|
||||
[Censys](https://censys.io/) or [scans.io](https://scans.io/). While
|
||||
Certificate Transparency provides an interoperable protocol for exchanging
|
||||
these datasets, in many cases, the certificate details and domains were already
|
||||
publicly detectable.
|
||||
|
||||
Requiring that the full certificate be disclosed if it was issued by a
|
||||
publicly-trusted CA is an important part of the security goals of Certificate
|
||||
Transparency. Permitting some of the information to be hidden from
|
||||
certificates allows for both attackers and untrustworthy CAs to hide
|
||||
certificates that could be used to compromise users. Certificate Transparency
|
||||
has detected issues at a large
|
||||
[number of CAs](https://wiki.mozilla.org/CA/Incident_Dashboard), many that the
|
||||
CAs themselves were not even aware of, and so public disclosure is critical
|
||||
to keeping all users safe.
|
||||
|
||||
While proposals for hiding domain names were presented during the development
|
||||
of Certificate Transparency, none of them were able to balance the needs of
|
||||
site operators that did not need to hide their domains, those that did, and the
|
||||
security risks that users would face.
|
||||
|
||||
Because of this, Chrome does not support any method for hiding domain names or
|
||||
other information within publicly-trusted certificates, nor are there any plans
|
||||
to support such mechanisms. Domain operators that wish to hide their
|
||||
certificates, enabling security risks and attacks, have two options:
|
||||
|
||||
1. **Wildcard Certificates** - Wildcard certificates allow a single certificate
|
||||
to be used for multiple hostnames, by putting a `*` as the most specific
|
||||
DNS label (for example, `*.internal.example.com` is valid for
|
||||
`mail.internal.example.com` and `wiki.internal.example.com`, but not for
|
||||
`www.example.com` or `two.levels.internal.example.com`). Wildcard
|
||||
certificates require greater care by the site operator to protect their
|
||||
private key, but also can have their issuance controlled via technologies
|
||||
such as [CAA (RFC 6844)](https://tools.ietf.org/html/rfc6844). This still
|
||||
requires the certificate be disclosed, but can limit how much of the domain
|
||||
is disclosed.
|
||||
2. **Enterprise-specific configuration** - If the domains being accessed are
|
||||
not intended to be used on the public internet, or not on machines or by
|
||||
users that are not part of a single enterprise, then that enterprise can
|
||||
use the options in the
|
||||
[Certificate Transparency for Enterprises](#Certificate-Transparency-For-Enterprises).
|
||||
This allows the enterprise to not reveal any information about the
|
||||
certificate, but these certificates will **only** be trusted by their
|
||||
members.
|
||||
|
||||
## What to do if your certificate does not work
|
||||
|
||||
As noted in [Chrome Policies](#Chrome-Policies), all certificates issued after
|
||||
30 April 2018 are expected to be disclosed via Certificate Transparency in a
|
||||
way that is compliant with the Certificate Transparency in Chrome policy.
|
||||
Virtually all publicly-trusted CAs have committed to supporting CT for their
|
||||
customers by default by this date, meaning that site operators should not have
|
||||
to do anything special and can continue getting certificates that just work on
|
||||
1 May 2018.
|
||||
|
||||
However, there's still a chance that a CA may not have adopted Certificate
|
||||
Transparency, may have an infrastructure issue, or may not have communicated
|
||||
to their partners, such as resellers or subordinate CAs, to ensure that the
|
||||
transition would be as smooth as possible for their customers.
|
||||
|
||||
If you're receiving a `net::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED` error
|
||||
message, the best thing to do is to contact your CA's support or sales team
|
||||
to diagnose the error with them. They will most likely need to replace your
|
||||
certificate with a new one that properly supports CT.
|
Загрузка…
Ссылка в новой задаче