< draft-ietf-trans-rfc6962-bis-34.txt   draft-ietf-trans-rfc6962-bis-35.txt >
TRANS (Public Notary Transparency) B. Laurie TRANS (Public Notary Transparency) B. Laurie
Internet-Draft A. Langley Internet-Draft A. Langley
Obsoletes: 6962 (if approved) E. Kasper Obsoletes: 6962 (if approved) E. Kasper
Intended status: Experimental E. Messeri Intended status: Experimental E. Messeri
Expires: May 7, 2020 Google Expires: 26 September 2021 Google
R. Stradling R. Stradling
Sectigo Sectigo
November 04, 2019 25 March 2021
Certificate Transparency Version 2.0 Certificate Transparency Version 2.0
draft-ietf-trans-rfc6962-bis-34 draft-ietf-trans-rfc6962-bis-35
Abstract Abstract
This document describes version 2.0 of the Certificate Transparency This document describes version 2.0 of the Certificate Transparency
(CT) protocol for publicly logging the existence of Transport Layer (CT) protocol for publicly logging the existence of Transport Layer
Security (TLS) server certificates as they are issued or observed, in Security (TLS) server certificates as they are issued or observed, in
a manner that allows anyone to audit certification authority (CA) a manner that allows anyone to audit certification authority (CA)
activity and notice the issuance of suspect certificates as well as activity and notice the issuance of suspect certificates as well as
to audit the certificate logs themselves. The intent is that to audit the certificate logs themselves. The intent is that
eventually clients would refuse to honor certificates that do not eventually clients would refuse to honor certificates that do not
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 7, 2020. This Internet-Draft will expire on 26 September 2021.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 5 1.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 5
1.3. Major Differences from CT 1.0 . . . . . . . . . . . . . . 5 1.3. Major Differences from CT 1.0 . . . . . . . . . . . . . . 5
2. Cryptographic Components . . . . . . . . . . . . . . . . . . 7 2. Cryptographic Components . . . . . . . . . . . . . . . . . . 7
2.1. Merkle Hash Trees . . . . . . . . . . . . . . . . . . . . 7 2.1. Merkle Hash Trees . . . . . . . . . . . . . . . . . . . . 7
2.1.1. Definition of the Merkle Tree . . . . . . . . . . . . 7 2.1.1. Definition of the Merkle Tree . . . . . . . . . . . . 7
2.1.2. Verifying a Tree Head Given Entries . . . . . . . . . 8 2.1.2. Verifying a Tree Head Given Entries . . . . . . . . . 8
2.1.3. Merkle Inclusion Proofs . . . . . . . . . . . . . . . 9 2.1.3. Merkle Inclusion Proofs . . . . . . . . . . . . . . . 9
2.1.4. Merkle Consistency Proofs . . . . . . . . . . . . . . 10 2.1.4. Merkle Consistency Proofs . . . . . . . . . . . . . . 10
2.1.5. Example . . . . . . . . . . . . . . . . . . . . . . . 12 2.1.5. Example . . . . . . . . . . . . . . . . . . . . . . . 12
2.2. Signatures . . . . . . . . . . . . . . . . . . . . . . . 14 2.2. Signatures . . . . . . . . . . . . . . . . . . . . . . . 14
3. Submitters . . . . . . . . . . . . . . . . . . . . . . . . . 14 3. Submitters . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Certificates . . . . . . . . . . . . . . . . . . . . . . 14 3.1. Certificates . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Precertificates . . . . . . . . . . . . . . . . . . . . . 14 3.2. Precertificates . . . . . . . . . . . . . . . . . . . . . 15
3.2.1. Binding Intent to Issue . . . . . . . . . . . . . . . 16 3.2.1. Binding Intent to Issue . . . . . . . . . . . . . . . 17
4. Log Format and Operation . . . . . . . . . . . . . . . . . . 16 4. Log Format and Operation . . . . . . . . . . . . . . . . . . 17
4.1. Log Parameters . . . . . . . . . . . . . . . . . . . . . 17 4.1. Log Parameters . . . . . . . . . . . . . . . . . . . . . 18
4.2. Evaluating Submissions . . . . . . . . . . . . . . . . . 18 4.2. Evaluating Submissions . . . . . . . . . . . . . . . . . 19
4.2.1. Minimum Acceptance Criteria . . . . . . . . . . . . . 18 4.2.1. Minimum Acceptance Criteria . . . . . . . . . . . . . 19
4.2.2. Discretionary Acceptance Criteria . . . . . . . . . . 19 4.2.2. Discretionary Acceptance Criteria . . . . . . . . . . 20
4.3. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 19 4.3. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 21
4.4. Log ID . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.4. Log ID . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.5. TransItem Structure . . . . . . . . . . . . . . . . . . . 20 4.5. TransItem Structure . . . . . . . . . . . . . . . . . . . 21
4.6. Log Artifact Extensions . . . . . . . . . . . . . . . . . 21 4.6. Log Artifact Extensions . . . . . . . . . . . . . . . . . 22
4.7. Merkle Tree Leaves . . . . . . . . . . . . . . . . . . . 21 4.7. Merkle Tree Leaves . . . . . . . . . . . . . . . . . . . 23
4.8. Signed Certificate Timestamp (SCT) . . . . . . . . . . . 22 4.8. Signed Certificate Timestamp (SCT) . . . . . . . . . . . 24
4.9. Merkle Tree Head . . . . . . . . . . . . . . . . . . . . 23 4.9. Merkle Tree Head . . . . . . . . . . . . . . . . . . . . 25
4.10. Signed Tree Head (STH) . . . . . . . . . . . . . . . . . 24 4.10. Signed Tree Head (STH) . . . . . . . . . . . . . . . . . 25
4.11. Merkle Consistency Proofs . . . . . . . . . . . . . . . . 25 4.11. Merkle Consistency Proofs . . . . . . . . . . . . . . . . 26
4.12. Merkle Inclusion Proofs . . . . . . . . . . . . . . . . . 25 4.12. Merkle Inclusion Proofs . . . . . . . . . . . . . . . . . 27
4.13. Shutting down a log . . . . . . . . . . . . . . . . . . . 26 4.13. Shutting down a log . . . . . . . . . . . . . . . . . . . 27
5. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 26
5.1. Submit Entry to Log . . . . . . . . . . . . . . . . . . . 28 5. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 28
5.2. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 30 5.1. Submit Entry to Log . . . . . . . . . . . . . . . . . . . 30
5.2. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 32
5.3. Retrieve Merkle Consistency Proof between Two Signed Tree 5.3. Retrieve Merkle Consistency Proof between Two Signed Tree
Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.4. Retrieve Merkle Inclusion Proof from Log by Leaf Hash . . 31 5.4. Retrieve Merkle Inclusion Proof from Log by Leaf Hash . . 33
5.5. Retrieve Merkle Inclusion Proof, Signed Tree Head and 5.5. Retrieve Merkle Inclusion Proof, Signed Tree Head and
Consistency Proof by Leaf Hash . . . . . . . . . . . . . 32 Consistency Proof by Leaf Hash . . . . . . . . . . . . . 34
5.6. Retrieve Entries and STH from Log . . . . . . . . . . . . 33 5.6. Retrieve Entries and STH from Log . . . . . . . . . . . . 35
5.7. Retrieve Accepted Trust Anchors . . . . . . . . . . . . . 35 5.7. Retrieve Accepted Trust Anchors . . . . . . . . . . . . . 37
6. TLS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 35 6. TLS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.1. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . . 36 6.1. TLS Client Authentication . . . . . . . . . . . . . . . . 38
6.2. TransItemList Structure . . . . . . . . . . . . . . . . . 37 6.2. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . . 39
6.3. Presenting SCTs, inclusions proofs and STHs . . . . . . . 37 6.3. TransItemList Structure . . . . . . . . . . . . . . . . . 39
6.4. transparency_info TLS Extension . . . . . . . . . . . . . 37 6.4. Presenting SCTs, inclusions proofs and STHs . . . . . . . 40
7. Certification Authorities . . . . . . . . . . . . . . . . . . 38 6.5. transparency_info TLS Extension . . . . . . . . . . . . . 40
7.1. Transparency Information X.509v3 Extension . . . . . . . 38 7. Certification Authorities . . . . . . . . . . . . . . . . . . 40
7.1.1. OCSP Response Extension . . . . . . . . . . . . . . . 38 7.1. Transparency Information X.509v3 Extension . . . . . . . 41
7.1.2. Certificate Extension . . . . . . . . . . . . . . . . 38 7.1.1. OCSP Response Extension . . . . . . . . . . . . . . . 41
7.2. TLS Feature X.509v3 Extension . . . . . . . . . . . . . . 39 7.1.2. Certificate Extension . . . . . . . . . . . . . . . . 41
8. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 7.2. TLS Feature X.509v3 Extension . . . . . . . . . . . . . . 41
8.1. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 39 8. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.1.1. Receiving SCTs and inclusion proofs . . . . . . . . . 39 8.1. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 42
8.1.2. Reconstructing the TBSCertificate . . . . . . . . . . 39 8.1.1. Receiving SCTs and inclusion proofs . . . . . . . . . 42
8.1.3. Validating SCTs . . . . . . . . . . . . . . . . . . . 40 8.1.2. Reconstructing the TBSCertificate . . . . . . . . . . 42
8.1.4. Fetching inclusion proofs . . . . . . . . . . . . . . 40 8.1.3. Validating SCTs . . . . . . . . . . . . . . . . . . . 42
8.1.5. Validating inclusion proofs . . . . . . . . . . . . . 41 8.1.4. Fetching inclusion proofs . . . . . . . . . . . . . . 43
8.1.6. Evaluating compliance . . . . . . . . . . . . . . . . 41 8.1.5. Validating inclusion proofs . . . . . . . . . . . . . 43
8.2. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 41 8.1.6. Evaluating compliance . . . . . . . . . . . . . . . . 44
8.3. Auditing . . . . . . . . . . . . . . . . . . . . . . . . 42 8.2. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 44
9. Algorithm Agility . . . . . . . . . . . . . . . . . . . . . . 43 8.3. Auditing . . . . . . . . . . . . . . . . . . . . . . . . 45
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 9. Algorithm Agility . . . . . . . . . . . . . . . . . . . . . . 46
10.1. New Entry to the TLS ExtensionType Registry . . . . . . 44 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
10.2. Hash Algorithms . . . . . . . . . . . . . . . . . . . . 44 10.1. New Entry to the TLS ExtensionType Registry . . . . . . 47
10.2.1. Specification Required guidance . . . . . . . . . . 45 10.2. Hash Algorithms . . . . . . . . . . . . . . . . . . . . 47
10.3. Signature Algorithms . . . . . . . . . . . . . . . . . . 45 10.2.1. Specification Required guidance . . . . . . . . . . 47
10.3.1. Expert Review guidelines . . . . . . . . . . . . . . 46 10.3. Signature Algorithms . . . . . . . . . . . . . . . . . . 48
10.4. VersionedTransTypes . . . . . . . . . . . . . . . . . . 46 10.3.1. Expert Review guidelines . . . . . . . . . . . . . . 48
10.4.1. Specification Required guidance . . . . . . . . . . 47 10.4. VersionedTransTypes . . . . . . . . . . . . . . . . . . 49
10.5. Log Artifact Extension Registry . . . . . . . . . . . . 47 10.4.1. Specification Required guidance . . . . . . . . . . 49
10.5.1. Specification Required guidance . . . . . . . . . . 47 10.5. Log Artifact Extension Registry . . . . . . . . . . . . 50
10.6. Object Identifiers . . . . . . . . . . . . . . . . . . . 47 10.5.1. Specification Required guidance . . . . . . . . . . 50
10.6.1. Log ID Registry . . . . . . . . . . . . . . . . . . 47 10.6. Object Identifiers . . . . . . . . . . . . . . . . . . . 50
11. Security Considerations . . . . . . . . . . . . . . . . . . . 48 10.6.1. Log ID Registry . . . . . . . . . . . . . . . . . . 50
11.1. Misissued Certificates . . . . . . . . . . . . . . . . . 49 10.7. URN Sub-namespace for TRANS errors
11.2. Detection of Misissue . . . . . . . . . . . . . . . . . 49 (urn:ietf:params:trans:error) . . . . . . . . . . . . . 51
11.3. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 49 10.7.1. TRANS Error Types . . . . . . . . . . . . . . . . . 52
11.4. Preventing Tracking Clients . . . . . . . . . . . . . . 50 11. Security Considerations . . . . . . . . . . . . . . . . . . . 53
11.5. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . 50 11.1. Misissued Certificates . . . . . . . . . . . . . . . . . 54
11.6. Leakage of DNS Information . . . . . . . . . . . . . . . 50 11.2. Detection of Misissue . . . . . . . . . . . . . . . . . 54
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 11.3. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 54
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 11.4. Preventing Tracking Clients . . . . . . . . . . . . . . 55
13.1. Normative References . . . . . . . . . . . . . . . . . . 51 11.5. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . 55
13.2. Informative References . . . . . . . . . . . . . . . . . 52 11.6. Leakage of DNS Information . . . . . . . . . . . . . . . 55
Appendix A. Supporting v1 and v2 simultaneously . . . . . . . . 54 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
13.1. Normative References . . . . . . . . . . . . . . . . . . 56
13.2. Informative References . . . . . . . . . . . . . . . . . 57
Appendix A. Supporting v1 and v2 simultaneously . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60
1. Introduction 1. Introduction
Certificate Transparency aims to mitigate the problem of misissued Certificate Transparency aims to mitigate the problem of misissued
certificates by providing append-only logs of issued certificates. certificates by providing append-only logs of issued certificates.
The logs do not themselves prevent misissuance, but they ensure that The logs do not themselves prevent misissuance, but they ensure that
interested parties (particularly those named in certificates) can interested parties (particularly those named in certificates) can
detect such misissuance. Note that this is a general mechanism that detect such misissuance. Note that this is a general mechanism that
could be used for transparently logging any form of binary data, could be used for transparently logging any form of binary data,
subject to some kind of inclusion criteria. In this document, we subject to some kind of inclusion criteria. In this document, we
skipping to change at page 5, line 47 skipping to change at page 5, line 50
Data structures are defined and encoded according to the conventions Data structures are defined and encoded according to the conventions
laid out in Section 3 of [RFC8446]. laid out in Section 3 of [RFC8446].
1.3. Major Differences from CT 1.0 1.3. Major Differences from CT 1.0
This document revises and obsoletes the CT 1.0 [RFC6962] protocol, This document revises and obsoletes the CT 1.0 [RFC6962] protocol,
drawing on insights gained from CT 1.0 deployments and on feedback drawing on insights gained from CT 1.0 deployments and on feedback
from the community. The major changes are: from the community. The major changes are:
o Hash and signature algorithm agility: permitted algorithms are now * Hash and signature algorithm agility: permitted algorithms are now
specified in IANA registries. specified in IANA registries.
o Precertificate format: precertificates are now CMS objects rather * Precertificate format: precertificates are now CMS objects rather
than X.509 certificates, which avoids violating the certificate than X.509 certificates, which avoids violating the certificate
serial number uniqueness requirement in Section 4.1.2.2 of serial number uniqueness requirement in Section 4.1.2.2 of
[RFC5280]. [RFC5280].
o Removed precertificate signing certificates and the precertificate * Removed precertificate signing certificates and the precertificate
poison extension: the change of precertificate format means that poison extension: the change of precertificate format means that
these are no longer needed. these are no longer needed.
o Logs IDs: each log is now identified by an OID rather than by the * Logs IDs: each log is now identified by an OID rather than by the
hash of its public key. OID allocations are managed by an IANA hash of its public key. OID allocations are managed by an IANA
registry. registry.
o "TransItem" structure: this new data structure is used to * "TransItem" structure: this new data structure is used to
encapsulate most types of CT data. A "TransItemList", consisting encapsulate most types of CT data. A "TransItemList", consisting
of one or more "TransItem" structures, can be used anywhere that of one or more "TransItem" structures, can be used anywhere that
"SignedCertificateTimestampList" was used in [RFC6962]. "SignedCertificateTimestampList" was used in [RFC6962].
o Merkle tree leaves: the "MerkleTreeLeaf" structure has been * Merkle tree leaves: the "MerkleTreeLeaf" structure has been
replaced by the "TransItem" structure, which eases extensibility replaced by the "TransItem" structure, which eases extensibility
and simplifies the leaf structure by removing one layer of and simplifies the leaf structure by removing one layer of
abstraction. abstraction.
o Unified leaf format: the structure for both certificate and * Unified leaf format: the structure for both certificate and
precertificate entries now includes only the TBSCertificate precertificate entries now includes only the TBSCertificate
(whereas certificate entries in [RFC6962] included the entire (whereas certificate entries in [RFC6962] included the entire
certificate). certificate).
o Log Artifact Extensions: these are now typed and managed by an * Log Artifact Extensions: these are now typed and managed by an
IANA registry, and they can now appear not only in SCTs but also IANA registry, and they can now appear not only in SCTs but also
in STHs. in STHs.
o API outputs: complete "TransItem" structures are returned, rather * API outputs: complete "TransItem" structures are returned, rather
than the constituent parts of each structure. than the constituent parts of each structure.
o get-all-by-hash: new client API for obtaining an inclusion proof * get-all-by-hash: new client API for obtaining an inclusion proof
and the corresponding consistency proof at the same time. and the corresponding consistency proof at the same time.
o submit-entry: new client API, replacing add-chain and add-pre- * submit-entry: new client API, replacing add-chain and add-pre-
chain. chain.
o Presenting SCTs with proofs: TLS servers may present SCTs together * Presenting SCTs with proofs: TLS servers may present SCTs together
with the corresponding inclusion proofs using any of the with the corresponding inclusion proofs using any of the
mechanisms that [RFC6962] defined for presenting SCTs only. mechanisms that [RFC6962] defined for presenting SCTs only.
(Presenting SCTs only is still supported). (Presenting SCTs only is still supported).
o CT TLS extension: the "signed_certificate_timestamp" TLS extension * CT TLS extension: the "signed_certificate_timestamp" TLS extension
has been replaced by the "transparency_info" TLS extension. has been replaced by the "transparency_info" TLS extension.
o Verification algorithms: added detailed algorithms for verifying * Verification algorithms: added detailed algorithms for verifying
inclusion proofs, for verifying consistency between two STHs, and inclusion proofs, for verifying consistency between two STHs, and
for verifying a root hash given a complete list of the relevant for verifying a root hash given a complete list of the relevant
leaf input entries. leaf input entries.
o Extensive clarifications and editorial work. * Extensive clarifications and editorial work.
2. Cryptographic Components 2. Cryptographic Components
2.1. Merkle Hash Trees 2.1. Merkle Hash Trees
2.1.1. Definition of the Merkle Tree 2.1.1. Definition of the Merkle Tree
The log uses a binary Merkle Hash Tree for efficient auditing. The The log uses a binary Merkle Hash Tree for efficient auditing. The
hash algorithm used is one of the log's parameters (see Section 4.1). hash algorithm used is one of the log's parameters (see Section 4.1).
This document establishes a registry of acceptable hash algorithms This document establishes a registry of acceptable hash algorithms
skipping to change at page 7, line 45 skipping to change at page 7, line 45
MTH({d[0]}) = HASH(0x00 || d[0]). MTH({d[0]}) = HASH(0x00 || d[0]).
For n > 1, let k be the largest power of two smaller than n (i.e., k For n > 1, let k be the largest power of two smaller than n (i.e., k
< n <= 2k). The Merkle Tree Hash of an n-element list D_n is then < n <= 2k). The Merkle Tree Hash of an n-element list D_n is then
defined recursively as defined recursively as
MTH(D_n) = HASH(0x01 || MTH(D[0:k]) || MTH(D[k:n])), MTH(D_n) = HASH(0x01 || MTH(D[0:k]) || MTH(D[k:n])),
where: where:
o || denotes concatenation * || denotes concatenation
o : denotes concatenation of lists * : denotes concatenation of lists
o D[k1:k2] = D'_(k2-k1) denotes the list {d'[0] = d[k1], d'[1] = * D[k1:k2] = D'_(k2-k1) denotes the list {d'[0] = d[k1], d'[1] =
d[k1+1], ..., d'[k2-k1-1] = d[k2-1]} of length (k2 - k1). d[k1+1], ..., d'[k2-k1-1] = d[k2-1]} of length (k2 - k1).
Note that the hash calculations for leaves and nodes differ; this Note that the hash calculations for leaves and nodes differ; this
domain separation is required to give second preimage resistance. domain separation is required to give second preimage resistance.
Note that we do not require the length of the input list to be a Note that we do not require the length of the input list to be a
power of two. The resulting Merkle Tree may thus not be balanced; power of two. The resulting Merkle Tree may thus not be balanced;
however, its shape is uniquely determined by the number of leaves. however, its shape is uniquely determined by the number of leaves.
(Note: This Merkle Tree is essentially the same as the history tree (Note: This Merkle Tree is essentially the same as the history tree
[CrosbyWallach] proposal, except our definition handles non-full [CrosbyWallach] proposal, except our definition handles non-full
skipping to change at page 13, line 41 skipping to change at page 14, line 32
/ \ / \ / \ / \ / \ / \ / \ / \
/ \ e f / \ / \ / \ e f / \ / \
/ \ | | / \ / \ / \ | | / \ / \
g h d4 d5 g h i j g h d4 d5 g h i j
/ \ / \ / \ / \ / \ | / \ / \ / \ / \ / \ |
a b c d a b c d e f d6 a b c d a b c d e f d6
| | | | | | | | | | | | | | | | | | | |
d0 d1 d2 d3 d0 d1 d2 d3 d4 d5 d0 d1 d2 d3 d0 d1 d2 d3 d4 d5
The consistency proof between hash0 and hash is PROOF(3, D[7]) = [c, The consistency proof between hash0 and hash is PROOF(3, D[7]) = [c,
d, g, l]. c, g are used to verify hash0, and d, l are additionally d, g, l]. c, g are used to verify hash0, and d, l are additionally
used to show hash is consistent with hash0. used to show hash is consistent with hash0.
The consistency proof between hash1 and hash is PROOF(4, D[7]) = [l]. The consistency proof between hash1 and hash is PROOF(4, D[7]) = [l].
hash can be verified using hash1=k and l. hash can be verified using hash1=k and l.
The consistency proof between hash2 and hash is PROOF(6, D[7]) = [i, The consistency proof between hash2 and hash is PROOF(6, D[7]) = [i,
j, k]. k, i are used to verify hash2, and j is additionally used to j, k]. k, i are used to verify hash2, and j is additionally used to
show hash is consistent with hash2. show hash is consistent with hash2.
2.2. Signatures 2.2. Signatures
Various data structures Section 1.2 are signed. A log MUST use one Various data structures Section 1.2 are signed. A log MUST use one
of the signature algorithms defined in Section 10.3. of the signature algorithms defined in Section 10.3.
3. Submitters 3. Submitters
Submitters submit certificates or preannouncements of certificates Submitters submit certificates or preannouncements of certificates
skipping to change at page 14, line 49 skipping to change at page 15, line 44
precertificate (Section 5.1) that the log can use to create an entry precertificate (Section 5.1) that the log can use to create an entry
that will be valid against the issued certificate. The CA MAY that will be valid against the issued certificate. The CA MAY
incorporate the returned SCT in the issued certificate. One example incorporate the returned SCT in the issued certificate. One example
of where the returned SCT is not incorporated in the issued of where the returned SCT is not incorporated in the issued
certificate is when a CA sends the precertificate to multiple logs, certificate is when a CA sends the precertificate to multiple logs,
but only incorporates the SCTs that are returned first. but only incorporates the SCTs that are returned first.
A precertificate is a CMS [RFC5652] "signed-data" object that A precertificate is a CMS [RFC5652] "signed-data" object that
conforms to the following profile: conforms to the following profile:
o It MUST be DER encoded. * It MUST be DER encoded.
o "SignedData.version" MUST be v3(3). * "SignedData.version" MUST be v3(3).
o "SignedData.digestAlgorithms" MUST only include the * "SignedData.digestAlgorithms" MUST only include the
"SignerInfo.digestAlgorithm" OID value (see below). "SignerInfo.digestAlgorithm" OID value (see below).
o "SignedData.encapContentInfo": * "SignedData.encapContentInfo":
* "eContentType" MUST be the OID 1.3.101.78. - "eContentType" MUST be the OID 1.3.101.78.
* "eContent" MUST contain a TBSCertificate [RFC5280] that will be - "eContent" MUST contain a TBSCertificate [RFC5280] that will be
identical to the TBSCertificate in the issued certificate, identical to the TBSCertificate in the issued certificate,
except that the Transparency Information (Section 7.1) except that the Transparency Information (Section 7.1)
extension MUST be omitted. extension MUST be omitted.
o "SignedData.certificates" MUST be omitted. * "SignedData.certificates" MUST be omitted.
o "SignedData.crls" MUST be omitted. * "SignedData.crls" MUST be omitted.
o "SignedData.signerInfos" MUST contain one "SignerInfo": * "SignedData.signerInfos" MUST contain one "SignerInfo":
* "version" MUST be v3(3). - "version" MUST be v3(3).
* "sid" MUST use the "subjectKeyIdentifier" option. - "sid" MUST use the "subjectKeyIdentifier" option.
* "digestAlgorithm" MUST be one of the hash algorithm OIDs listed - "digestAlgorithm" MUST be one of the hash algorithm OIDs listed
in Section 10.2. in Section 10.2.
* "signedAttrs" MUST be present and MUST contain two attributes: - "signedAttrs" MUST be present and MUST contain two attributes:
+ A content-type attribute whose value is the same as o A content-type attribute whose value is the same as
"SignedData.encapContentInfo.eContentType". "SignedData.encapContentInfo.eContentType".
+ A message-digest attribute whose value is the message digest o A message-digest attribute whose value is the message digest
of "SignedData.encapContentInfo.eContent". of "SignedData.encapContentInfo.eContent".
* "signatureAlgorithm" MUST be the same OID as - "signatureAlgorithm" MUST be the same OID as
"TBSCertificate.signature". "TBSCertificate.signature".
* "signature" MUST be from the same (root or intermediate) CA - "signature" MUST be from the same (root or intermediate) CA
that intends to issue the corresponding certificate (see that intends to issue the corresponding certificate (see
Section 3.2.1). Section 3.2.1).
* "unsignedAttrs" MUST be omitted. - "unsignedAttrs" MUST be omitted.
"SignerInfo.signedAttrs" is included in the message digest "SignerInfo.signedAttrs" is included in the message digest
calculation process (see Section 5.4 of [RFC5652]), which ensures calculation process (see Section 5.4 of [RFC5652]), which ensures
that the "SignerInfo.signature" value will not be a valid X.509v3 that the "SignerInfo.signature" value will not be a valid X.509v3
signature that could be used in conjunction with the TBSCertificate signature that could be used in conjunction with the TBSCertificate
(from "SignedData.encapContentInfo.eContent") to construct a valid (from "SignedData.encapContentInfo.eContent") to construct a valid
certificate. certificate.
3.2.1. Binding Intent to Issue 3.2.1. Binding Intent to Issue
Under normal circumstances, there will be a short delay between Under normal circumstances, there will be a short delay between
precertificate submission and issuance of the corresponding precertificate submission and issuance of the corresponding
certificate. Longer delays are to be expected occasionally (e.g., certificate. Longer delays are to be expected occasionally (e.g.,
due to log server downtime), and in some cases the CA might not due to log server downtime), and in some cases the CA might not
actually issue the corresponding certificate. Nevertheless, a actually issue the corresponding certificate. Nevertheless, a
precertificate's "signature" indicates the CA's binding intent to precertificate's "signature" indicates the CA's binding intent to
issue the corresponding certificate, which means that: issue the corresponding certificate, which means that:
o Misissuance of a precertificate is considered equivalent to * Misissuance of a precertificate is considered equivalent to
misissuance of the corresponding certificate. The CA should misissuance of the corresponding certificate. The CA should
expect to be held to account, even if the corresponding expect to be held to account, even if the corresponding
certificate has not actually been issued. certificate has not actually been issued.
o Upon observing a precertificate, a client can reasonably presume * Upon observing a precertificate, a client can reasonably presume
that the corresponding certificate has been issued. A client may that the corresponding certificate has been issued. A client may
wish to obtain status information (e.g., by using the Online wish to obtain status information (e.g., by using the Online
Certificate Status Protocol [RFC6960] or by checking a Certificate Certificate Status Protocol [RFC6960] or by checking a Certificate
Revocation List [RFC5280]) about a certificate that is presumed to Revocation List [RFC5280]) about a certificate that is presumed to
exist, especially if there is evidence or suspicion that the exist, especially if there is evidence or suspicion that the
corresponding precertificate was misissued. corresponding precertificate was misissued.
o TLS clients may have policies that require CAs to be able to * TLS clients may have policies that require CAs to be able to
revoke, and to provide certificate status services for, each revoke, and to provide certificate status services for, each
certificate that is presumed to exist based on the existence of a certificate that is presumed to exist based on the existence of a
corresponding precertificate. corresponding precertificate.
4. Log Format and Operation 4. Log Format and Operation
A log is a single, append-only Merkle Tree of submitted certificate A log is a single, append-only Merkle Tree of submitted certificate
and precertificate entries. and precertificate entries.
When it receives and accepts a valid submission, the log MUST return When it receives and accepts a valid submission, the log MUST return
skipping to change at page 17, line 7 skipping to change at page 18, line 11
previously logged as a precertificate, then the precertificate's SCT previously logged as a precertificate, then the precertificate's SCT
of type "precert_sct_v2" would not be appropriate; instead, a fresh of type "precert_sct_v2" would not be appropriate; instead, a fresh
SCT of type "x509_sct_v2" should be generated. SCT of type "x509_sct_v2" should be generated.
An SCT is the log's promise to append to its Merkle Tree an entry for An SCT is the log's promise to append to its Merkle Tree an entry for
the accepted submission. Upon producing an SCT, the log MUST fulfil the accepted submission. Upon producing an SCT, the log MUST fulfil
this promise by performing the following actions within a fixed this promise by performing the following actions within a fixed
amount of time known as the Maximum Merge Delay (MMD), which is one amount of time known as the Maximum Merge Delay (MMD), which is one
of the log's parameters (see Section 4.1): of the log's parameters (see Section 4.1):
o Allocate a tree index to the entry representing the accepted * Allocate a tree index to the entry representing the accepted
submission. submission.
o Calculate the root of the tree. * Calculate the root of the tree.
o Sign the root of the tree (see Section 4.10). * Sign the root of the tree (see Section 4.10).
The log may append multiple entries before signing the root of the The log may append multiple entries before signing the root of the
tree. tree.
Log operators SHOULD NOT impose any conditions on retrieving or Log operators SHOULD NOT impose any conditions on retrieving or
sharing data from the log. sharing data from the log.
4.1. Log Parameters 4.1. Log Parameters
A log is defined by a collection of immutable parameters, which are A log is defined by a collection of immutable parameters, which are
skipping to change at page 18, line 44 skipping to change at page 19, line 47
certificates trusted by major browser vendors. certificates trusted by major browser vendors.
4.2.1. Minimum Acceptance Criteria 4.2.1. Minimum Acceptance Criteria
To ensure that logged certificates and precertificates are To ensure that logged certificates and precertificates are
attributable to an accepted trust anchor, and to set clear attributable to an accepted trust anchor, and to set clear
expectations for what monitors would find in the log, and to avoid expectations for what monitors would find in the log, and to avoid
being overloaded by invalid submissions, the log MUST reject a being overloaded by invalid submissions, the log MUST reject a
submission if any of the following conditions are not met: submission if any of the following conditions are not met:
o The "submission", "type" and "chain" inputs MUST be set as * The "submission", "type" and "chain" inputs MUST be set as
described in Section 5.1. The log MUST NOT accommodate misordered described in Section 5.1. The log MUST NOT accommodate misordered
CA certificates or use any other source of intermediate CA CA certificates or use any other source of intermediate CA
certificates to attempt certification path construction. certificates to attempt certification path construction.
o Each of the zero or more intermediate CA certificates in the chain * Each of the zero or more intermediate CA certificates in the chain
MUST have one or both of the following features: MUST have one or both of the following features:
* The Basic Constraints extension with the cA boolean asserted. - The Basic Constraints extension with the cA boolean asserted.
* The Key Usage extension with the keyCertSign bit asserted. - The Key Usage extension with the keyCertSign bit asserted.
o Each certificate in the chain MUST fall within the limits imposed * Each certificate in the chain MUST fall within the limits imposed
by the zero or more Basic Constraints pathLenConstraint values by the zero or more Basic Constraints pathLenConstraint values
found higher up the chain. found higher up the chain.
o Precertificate submissions MUST conform to all of the requirements * Precertificate submissions MUST conform to all of the requirements
in Section 3.2. in Section 3.2.
4.2.2. Discretionary Acceptance Criteria 4.2.2. Discretionary Acceptance Criteria
If the minimum acceptance criteria are met but the submission is not If the minimum acceptance criteria are met but the submission is not
fully valid according to [RFC5280] verification rules (e.g., the fully valid according to [RFC5280] verification rules (e.g., the
certificate or precertificate has expired, is not yet valid, has been certificate or precertificate has expired, is not yet valid, has been
revoked, exhibits ASN.1 DER encoding errors but the log can still revoked, exhibits ASN.1 DER encoding errors but the log can still
parse it, etc), then the acceptability of the submission is left to parse it, etc), then the acceptability of the submission is left to
the log's discretion. It is useful for logs to accept such the log's discretion. It is useful for logs to accept such
skipping to change at page 26, line 14 skipping to change at page 27, line 42
4.13. Shutting down a log 4.13. Shutting down a log
Log operators may decide to shut down a log for various reasons, such Log operators may decide to shut down a log for various reasons, such
as deprecation of the signature algorithm. If there are entries in as deprecation of the signature algorithm. If there are entries in
the log for certificates that have not yet expired, simply making TLS the log for certificates that have not yet expired, simply making TLS
clients stop recognizing that log will have the effect of clients stop recognizing that log will have the effect of
invalidating SCTs from that log. To avoid that, the following invalidating SCTs from that log. To avoid that, the following
actions are suggested: actions are suggested:
o Make it known to clients and monitors that the log will be frozen. * Make it known to clients and monitors that the log will be frozen.
o Stop accepting new submissions (the error code "shutdown" should * Stop accepting new submissions (the error code "shutdown" should
be returned for such requests). be returned for such requests).
o Once MMD from the last accepted submission has passed and all * Once MMD from the last accepted submission has passed and all
pending submissions are incorporated, issue a final STH and pending submissions are incorporated, issue a final STH and
publish it as one of the log's parameters. Having an STH with a publish it as one of the log's parameters. Having an STH with a
timestamp that is after the MMD has passed from the last SCT timestamp that is after the MMD has passed from the last SCT
issuance allows clients to audit this log regularly without issuance allows clients to audit this log regularly without
special handling for the final STH. At this point the log's special handling for the final STH. At this point the log's
private key is no longer needed and can be destroyed. private key is no longer needed and can be destroyed.
o Keep the log running until the certificates in all of its entries * Keep the log running until the certificates in all of its entries
have expired or exist in other logs (this can be determined by have expired or exist in other logs (this can be determined by
scanning other logs or connecting to domains mentioned in the scanning other logs or connecting to domains mentioned in the
certificates and inspecting the SCTs served). certificates and inspecting the SCTs served).
5. Log Client Messages 5. Log Client Messages
Messages are sent as HTTPS GET or POST requests. Parameters for Messages are sent as HTTPS GET or POST requests. Parameters for
POSTs and all responses are encoded as JavaScript Object Notation POSTs and all responses are encoded as JavaScript Object Notation
(JSON) objects [RFC8259]. Parameters for GETs are encoded as order- (JSON) objects [RFC8259]. Parameters for GETs are encoded as order-
independent key/value URL parameters, using the "application/x-www- independent key/value URL parameters, using the "application/x-www-
skipping to change at page 28, line 5 skipping to change at page 29, line 38
"type": "urn:ietf:params:trans:error:endBeforeStart", "type": "urn:ietf:params:trans:error:endBeforeStart",
"detail": "'start' cannot be greater than 'end'" "detail": "'start' cannot be greater than 'end'"
} }
Most error types are specific to the type of request and are defined Most error types are specific to the type of request and are defined
in the respective subsections below. The one exception is the in the respective subsections below. The one exception is the
"malformed" error type, which indicates that the log server could not "malformed" error type, which indicates that the log server could not
parse the client's request because it did not comply with this parse the client's request because it did not comply with this
document: document:
+-----------+----------------------------------+ +===========+==================================+
| type | detail | | type | detail |
+-----------+----------------------------------+ +===========+==================================+
| malformed | The request could not be parsed. | | malformed | The request could not be parsed. |
+-----------+----------------------------------+ +-----------+----------------------------------+
Table 1
Clients SHOULD treat "500 Internal Server Error" and "503 Service Clients SHOULD treat "500 Internal Server Error" and "503 Service
Unavailable" responses as transient failures and MAY retry the same Unavailable" responses as transient failures and MAY retry the same
request without modification at a later date. Note that as per request without modification at a later date. Note that as per
[RFC7231], in the case of a 503 response the log MAY include a [RFC7231], in the case of a 503 response the log MAY include a
"Retry-After:" header in order to request a minimum time for the "Retry-After:" header in order to request a minimum time for the
client to wait before retrying the request. client to wait before retrying the request.
5.1. Submit Entry to Log 5.1. Submit Entry to Log
POST <Base URL>/ct/v2/submit-entry POST <Base URL>/ct/v2/submit-entry
Inputs: Inputs: submission: The base64 encoded certificate or
precertificate.
submission: The base64 encoded certificate or precertificate.
type: The "VersionedTransType" integer value that indicates the type: The "VersionedTransType" integer value that indicates
type of the "submission": 1 for "x509_entry_v2", or 2 for the type of the "submission": 1 for "x509_entry_v2", or 2 for
"precert_entry_v2". "precert_entry_v2".
chain: An array of zero or more base64 encoded CA certificates. chain: An array of zero or more base64 encoded CA
The first element is the certifier of the "submission"; the certificates. The first element is the certifier of the
second certifies the first; etc. The last element of "chain" "submission"; the second certifies the first; etc. The last
(or, if "chain" is an empty array, the "submission") is element of "chain" (or, if "chain" is an empty array, the
certified by an accepted trust anchor. "submission") is certified by an accepted trust anchor.
Outputs:
sct: A base64 encoded "TransItem" of type "x509_sct_v2" or Outputs: sct: A base64 encoded "TransItem" of type "x509_sct_v2" or
"precert_sct_v2", signed by this log, that corresponds to the "precert_sct_v2", signed by this log, that corresponds to the
"submission". "submission".
If the submitted entry is immediately appended to (or already If the submitted entry is immediately appended to (or already
exists in) this log's tree, then the log SHOULD also output: exists in) this log's tree, then the log SHOULD also output:
sth: A base64 encoded "TransItem" of type "signed_tree_head_v2", sth: A base64 encoded "TransItem" of type "signed_tree_head_v2",
signed by this log. signed by this log.
inclusion: A base64 encoded "TransItem" of type inclusion: A base64 encoded "TransItem" of type
"inclusion_proof_v2" whose "inclusion_path" array of Merkle "inclusion_proof_v2" whose "inclusion_path" array of Merkle
Tree nodes proves the inclusion of the "submission" in the Tree nodes proves the inclusion of the "submission" in the
returned "sth". returned "sth".
Error codes: Error codes:
+----------------+--------------------------------------------------+ +================+==============================================+
| type | detail | | type | detail |
+----------------+--------------------------------------------------+ +================+==============================================+
| badSubmission | "submission" is neither a valid certificate nor | | badSubmission | "submission" is neither a valid certificate |
| | a valid precertificate. | | | nor a valid precertificate. |
| | | +----------------+----------------------------------------------+
| badType | "type" is neither 1 nor 2. | | badType | "type" is neither 1 nor 2. |
| | | +----------------+----------------------------------------------+
| badChain | The first element of "chain" is not the | | badChain | The first element of "chain" is not the |
| | certifier of the "submission", or the second | | | certifier of the "submission", or the second |
| | element does not certify the first, etc. | | | element does not certify the first, etc. |
| | | +----------------+----------------------------------------------+
| badCertificate | One or more certificates in the "chain" are not | | badCertificate | One or more certificates in the "chain" are |
| | valid (e.g., not properly encoded). | | | not valid (e.g., not properly encoded). |
| | | +----------------+----------------------------------------------+
| unknownAnchor | The last element of "chain" (or, if "chain" is | | unknownAnchor | The last element of "chain" (or, if "chain" |
| | an empty array, the "submission") both is not, | | | is an empty array, the "submission") both is |
| | and is not certified by, an accepted trust | | | not, and is not certified by, an accepted |
| | anchor. | | | trust anchor. |
| | | +----------------+----------------------------------------------+
| shutdown | The log is no longer accepting submissions. | | shutdown | The log is no longer accepting submissions. |
+----------------+--------------------------------------------------+ +----------------+----------------------------------------------+
Table 2
If the version of "sct" is not v2, then a v2 client may be unable to If the version of "sct" is not v2, then a v2 client may be unable to
verify the signature. It MUST NOT construe this as an error. This verify the signature. It MUST NOT construe this as an error. This
is to avoid forcing an upgrade of compliant v2 clients that do not is to avoid forcing an upgrade of compliant v2 clients that do not
use the returned SCTs. use the returned SCTs.
If a log detects bad encoding in a chain that otherwise verifies If a log detects bad encoding in a chain that otherwise verifies
correctly then the log MUST either log the certificate or return the correctly then the log MUST either log the certificate or return the
"bad certificate" error. If the certificate is logged, an SCT MUST "bad certificate" error. If the certificate is logged, an SCT MUST
be issued. Logging the certificate is useful, because monitors be issued. Logging the certificate is useful, because monitors
skipping to change at page 30, line 11 skipping to change at page 32, line 11
"sth" and "inclusion" (if returned) SHOULD also be provided to TLS "sth" and "inclusion" (if returned) SHOULD also be provided to TLS
clients (e.g., if "type" was 2 (for "precert_sct_v2") then all three clients (e.g., if "type" was 2 (for "precert_sct_v2") then all three
"TransItem"s could be embedded in the certificate). "TransItem"s could be embedded in the certificate).
5.2. Retrieve Latest Signed Tree Head 5.2. Retrieve Latest Signed Tree Head
GET <Base URL>/ct/v2/get-sth GET <Base URL>/ct/v2/get-sth
No inputs. No inputs.
Outputs: Outputs: sth: A base64 encoded "TransItem" of type
"signed_tree_head_v2", signed by this log, that is no older
sth: A base64 encoded "TransItem" of type "signed_tree_head_v2", than the log's MMD.
signed by this log, that is no older than the log's MMD.
5.3. Retrieve Merkle Consistency Proof between Two Signed Tree Heads 5.3. Retrieve Merkle Consistency Proof between Two Signed Tree Heads
GET <Base URL>/ct/v2/get-sth-consistency GET <Base URL>/ct/v2/get-sth-consistency
Inputs: Inputs: first: The tree_size of the older tree, in decimal.
first: The tree_size of the older tree, in decimal.
second: The tree_size of the newer tree, in decimal (optional). second: The tree_size of the newer tree, in decimal
(optional).
Both tree sizes must be from existing v2 STHs. However, because Both tree sizes must be from existing v2 STHs. However, because
of skew, the receiving front-end may not know one or both of the of skew, the receiving front-end may not know one or both of the
existing STHs. If both are known, then only the "consistency" existing STHs. If both are known, then only the "consistency"
output is returned. If the first is known but the second is not output is returned. If the first is known but the second is not
(or has been omitted), then the latest known STH is returned, (or has been omitted), then the latest known STH is returned,
along with a consistency proof between the first STH and the along with a consistency proof between the first STH and the
latest. If neither are known, then the latest known STH is latest. If neither are known, then the latest known STH is
returned without a consistency proof. returned without a consistency proof.
Outputs: Outputs: consistency: A base64 encoded "TransItem" of type
consistency: A base64 encoded "TransItem" of type
"consistency_proof_v2", whose "tree_size_1" MUST match the "consistency_proof_v2", whose "tree_size_1" MUST match the
"first" input. If the "sth" output is omitted, then "first" input. If the "sth" output is omitted, then
"tree_size_2" MUST match the "second" input. If "first" and "tree_size_2" MUST match the "second" input. If "first" and
"second" are equal and correspond to a known STH, the returned "second" are equal and correspond to a known STH, the returned
consistency proof MUST be empty (a "consistency_path" array consistency proof MUST be empty (a "consistency_path" array
with zero elements). with zero elements).
sth: A base64 encoded "TransItem" of type "signed_tree_head_v2", sth: A base64 encoded "TransItem" of type
signed by this log. "signed_tree_head_v2", signed by this log.
Note that no signature is required for the "consistency" output as Note that no signature is required for the "consistency" output as
it is used to verify the consistency between two STHs, which are it is used to verify the consistency between two STHs, which are
signed. signed.
Error codes: Error codes:
+-------------------+-----------------------------------------------+ +===================+======================================+
| type | detail | | type | detail |
+-------------------+-----------------------------------------------+ +===================+======================================+
| firstUnknown | "first" is before the latest known STH but is | | firstUnknown | "first" is before the latest known |
| | not from an existing STH. | | | STH but is not from an existing STH. |
| | | +-------------------+--------------------------------------+
| secondUnknown | "second" is before the latest known STH but | | secondUnknown | "second" is before the latest known |
| | is not from an existing STH. | | | STH but is not from an existing STH. |
| | | +-------------------+--------------------------------------+
| secondBeforeFirst | "second" is smaller than "first". | | secondBeforeFirst | "second" is smaller than "first". |
+-------------------+-----------------------------------------------+ +-------------------+--------------------------------------+
Table 3
See Section 2.1.4.2 for an outline of how to use the "consistency" See Section 2.1.4.2 for an outline of how to use the "consistency"
output. output.
5.4. Retrieve Merkle Inclusion Proof from Log by Leaf Hash 5.4. Retrieve Merkle Inclusion Proof from Log by Leaf Hash
GET <Base URL>/ct/v2/get-proof-by-hash GET <Base URL>/ct/v2/get-proof-by-hash
Inputs: Inputs: hash: A base64 encoded v2 leaf hash.
hash: A base64 encoded v2 leaf hash.
tree_size: The tree_size of the tree on which to base the proof, tree_size: The tree_size of the tree on which to base the
in decimal. proof, in decimal.
The "hash" must be calculated as defined in Section 4.7. The The "hash" must be calculated as defined in Section 4.7. The
"tree_size" must designate an existing v2 STH. Because of skew, "tree_size" must designate an existing v2 STH. Because of skew,
the front-end may not know the requested STH. In that case, it the front-end may not know the requested STH. In that case, it
will return the latest STH it knows, along with an inclusion proof will return the latest STH it knows, along with an inclusion proof
to that STH. If the front-end knows the requested STH then only to that STH. If the front-end knows the requested STH then only
"inclusion" is returned. "inclusion" is returned.
Outputs: Outputs: inclusion: A base64 encoded "TransItem" of type
inclusion: A base64 encoded "TransItem" of type
"inclusion_proof_v2" whose "inclusion_path" array of Merkle "inclusion_proof_v2" whose "inclusion_path" array of Merkle
Tree nodes proves the inclusion of the chosen certificate in Tree nodes proves the inclusion of the chosen certificate in
the selected STH. the selected STH.
sth: A base64 encoded "TransItem" of type "signed_tree_head_v2", sth: A base64 encoded "TransItem" of type
signed by this log. "signed_tree_head_v2", signed by this log.
Note that no signature is required for the "inclusion" output as Note that no signature is required for the "inclusion" output as
it is used to verify inclusion in the selected STH, which is it is used to verify inclusion in the selected STH, which is
signed. signed.
Error codes: Error codes:
+-----------------+-------------------------------------------------+ +=================+=====================================+
| type | detail | | type | detail |
+-----------------+-------------------------------------------------+ +=================+=====================================+
| hashUnknown | "hash" is not the hash of a known leaf (may be | | hashUnknown | "hash" is not the hash of a known |
| | caused by skew or by a known certificate not | | | leaf (may be caused by skew or by a |
| | yet merged). | | | known certificate not yet merged). |
| | | +-----------------+-------------------------------------+
| treeSizeUnknown | "hash" is before the latest known STH but is | | treeSizeUnknown | "hash" is before the latest known |
| | not from an existing STH. | | | STH but is not from an existing |
+-----------------+-------------------------------------------------+ | | STH. |
+-----------------+-------------------------------------+
Table 4
See Section 2.1.3.2 for an outline of how to use the "inclusion" See Section 2.1.3.2 for an outline of how to use the "inclusion"
output. output.
5.5. Retrieve Merkle Inclusion Proof, Signed Tree Head and Consistency 5.5. Retrieve Merkle Inclusion Proof, Signed Tree Head and Consistency
Proof by Leaf Hash Proof by Leaf Hash
GET <Base URL>/ct/v2/get-all-by-hash GET <Base URL>/ct/v2/get-all-by-hash
Inputs: Inputs: hash: A base64 encoded v2 leaf hash.
hash: A base64 encoded v2 leaf hash.
tree_size: The tree_size of the tree on which to base the proofs, tree_size: The tree_size of the tree on which to base the
in decimal. proofs, in decimal.
The "hash" must be calculated as defined in Section 4.7. The The "hash" must be calculated as defined in Section 4.7. The
"tree_size" must designate an existing v2 STH. "tree_size" must designate an existing v2 STH.
Because of skew, the front-end may not know the requested STH or the Because of skew, the front-end may not know the requested STH or the
requested hash, which leads to a number of cases: requested hash, which leads to a number of cases:
+--------------------+----------------------------------------------+ +================+=====================================+
| Case | Response | | Case | Response |
+--------------------+----------------------------------------------+ +================+=====================================+
| latest STH < | Return latest STH | | latest STH < | Return latest STH |
| requested STH | | | requested STH | |
| | | +----------------+-------------------------------------+
| latest STH > | Return latest STH and a consistency proof | | latest STH > | Return latest STH and a consistency |
| requested STH | between it and the requested STH (see | | requested STH | proof between it and the requested |
| | Section 5.3) | | | STH (see Section 5.3) |
| | | +----------------+-------------------------------------+
| index of requested | Return "inclusion" | | index of | Return "inclusion" |
| hash < latest STH | | | requested hash | |
+--------------------+----------------------------------------------+ | < latest STH | |
+----------------+-------------------------------------+
Table 5
Note that more than one case can be true, in which case the returned Note that more than one case can be true, in which case the returned
data is their union. It is also possible for none to be true, in data is their union. It is also possible for none to be true, in
which case the front-end MUST return an empty response. which case the front-end MUST return an empty response.
Outputs: Outputs: inclusion: A base64 encoded "TransItem" of type
inclusion: A base64 encoded "TransItem" of type
"inclusion_proof_v2" whose "inclusion_path" array of Merkle "inclusion_proof_v2" whose "inclusion_path" array of Merkle
Tree nodes proves the inclusion of the chosen certificate in Tree nodes proves the inclusion of the chosen certificate in
the returned STH. the returned STH.
sth: A base64 encoded "TransItem" of type "signed_tree_head_v2", sth: A base64 encoded "TransItem" of type
signed by this log. "signed_tree_head_v2", signed by this log.
consistency: A base64 encoded "TransItem" of type consistency: A base64 encoded "TransItem" of type
"consistency_proof_v2" that proves the consistency of the "consistency_proof_v2" that proves the consistency of the
requested STH and the returned STH. requested STH and the returned STH.
Note that no signature is required for the "inclusion" or Note that no signature is required for the "inclusion" or
"consistency" outputs as they are used to verify inclusion in and "consistency" outputs as they are used to verify inclusion in and
consistency of STHs, which are signed. consistency of STHs, which are signed.
Errors are the same as in Section 5.4. Errors are the same as in Section 5.4.
See Section 2.1.3.2 for an outline of how to use the "inclusion" See Section 2.1.3.2 for an outline of how to use the "inclusion"
output, and see Section 2.1.4.2 for an outline of how to use the output, and see Section 2.1.4.2 for an outline of how to use the
"consistency" output. "consistency" output.
5.6. Retrieve Entries and STH from Log 5.6. Retrieve Entries and STH from Log
GET <Base URL>/ct/v2/get-entries GET <Base URL>/ct/v2/get-entries
Inputs: Inputs: start: 0-based index of first entry to retrieve, in
decimal.
start: 0-based index of first entry to retrieve, in decimal.
end: 0-based index of last entry to retrieve, in decimal.
Outputs: end: 0-based index of last entry to retrieve, in decimal.
entries: An array of objects, each consisting of Outputs: entries: An array of objects, each consisting of
log_entry: The base64 encoded "TransItem" structure of type log_entry: The base64 encoded "TransItem" structure of type
"x509_entry_v2" or "precert_entry_v2" (see Section 4.3). "x509_entry_v2" or "precert_entry_v2" (see Section 4.3).
submitted_entry: JSON object representing the inputs that were submitted_entry: JSON object representing the inputs that were
submitted to "submit-entry", with the addition of the trust submitted to "submit-entry", with the addition of the trust
anchor to the "chain" field if the submission did not anchor to the "chain" field if the submission did not
include it. include it.
sct: The base64 encoded "TransItem" of type "x509_sct_v2" or sct: The base64 encoded "TransItem" of type "x509_sct_v2" or
"precert_sct_v2" corresponding to this log entry. "precert_sct_v2" corresponding to this log entry.
sth: A base64 encoded "TransItem" of type "signed_tree_head_v2", sth: A base64 encoded "TransItem" of type
signed by this log. "signed_tree_head_v2", signed by this log.
Note that this message is not signed -- the "entries" data can be Note that this message is not signed -- the "entries" data can be
verified by constructing the Merkle Tree Hash corresponding to a verified by constructing the Merkle Tree Hash corresponding to a
retrieved STH. All leaves MUST be v2. However, a compliant v2 retrieved STH. All leaves MUST be v2. However, a compliant v2
client MUST NOT construe an unrecognized TransItem type as an error. client MUST NOT construe an unrecognized TransItem type as an error.
This means it may be unable to parse some entries, but note that each This means it may be unable to parse some entries, but note that each
client can inspect the entries it does recognize as well as verify client can inspect the entries it does recognize as well as verify
the integrity of the data by treating unrecognized leaves as opaque the integrity of the data by treating unrecognized leaves as opaque
input to the tree. input to the tree.
skipping to change at page 35, line 10 skipping to change at page 37, line 23
empty "entries" array. empty "entries" array.
In any case, the log server MUST return the latest STH it knows In any case, the log server MUST return the latest STH it knows
about. about.
See Section 2.1.2 for an outline of how to use a complete list of See Section 2.1.2 for an outline of how to use a complete list of
"log_entry" entries to verify the "root_hash". "log_entry" entries to verify the "root_hash".
Error codes: Error codes:
+----------------+--------------------------------------------------+ +================+====================================+
| type | detail | | type | detail |
+----------------+--------------------------------------------------+ +================+====================================+
| startUnknown | "start" is greater than the number of entries in | | startUnknown | "start" is greater than the number |
| | the Merkle tree. | | | of entries in the Merkle tree. |
| | | +----------------+------------------------------------+
| endBeforeStart | "start" cannot be greater than "end". | | endBeforeStart | "start" cannot be greater than |
+----------------+--------------------------------------------------+ | | "end". |
+----------------+------------------------------------+
Table 6
5.7. Retrieve Accepted Trust Anchors 5.7. Retrieve Accepted Trust Anchors
GET <Base URL>/ct/v2/get-anchors GET <Base URL>/ct/v2/get-anchors
No inputs. No inputs.
Outputs: Outputs: certificates: An array of base64 encoded trust anchors
that are acceptable to the log.
certificates: An array of base64 encoded trust anchors that are
acceptable to the log.
max_chain_length: If the server has chosen to limit the length of max_chain_length: If the server has chosen to limit the
chains it accepts, this is the maximum number of certificates length of chains it accepts, this is the maximum number of
in the chain, in decimal. If there is no limit, this is certificates in the chain, in decimal. If there is no limit,
omitted. this is omitted.
6. TLS Servers 6. TLS Servers
CT-using TLS servers MUST use at least one of the three mechanisms CT-using TLS servers MUST use at least one of the mechanisms
listed below to present one or more SCTs from one or more logs to described below to present one or more SCTs from one or more logs to
each TLS client during full TLS handshakes, where each SCT each TLS client during full TLS handshakes, where each SCT
corresponds to the server certificate. They SHOULD also present corresponds to the server certificate. They SHOULD also present
corresponding inclusion proofs and STHs. corresponding inclusion proofs and STHs.
Three mechanisms are provided because they have different tradeoffs. A server can provide SCTs using a TLS 1.3 extension (Section 4.2 of
[RFC8446]) with type "transparency_info" (see Section 6.5). This
mechanism allows TLS servers to participate in CT without the
cooperation of CAs, unlike the other two mechanisms. It also allows
SCTs and inclusion proofs to be updated on the fly.
o A TLS extension (Section 4.2 of [RFC8446]) with type The server may also use an Online Certificate Status Protocol (OCSP)
"transparency_info" (see Section 6.4). This mechanism allows TLS [RFC6960] response extension (see Section 7.1.1), providing the OCSP
servers to participate in CT without the cooperation of CAs, response as part of the TLS handshake. Providing a response during a
unlike the other two mechanisms. It also allows SCTs and TLS handshake is popularly known as "OCSP stapling." For TLS 1.3,
inclusion proofs to be updated on the fly. the information is encoded as an extension in the "status_request"
extension data; see Section 4.4.2.1 of [RFC8446]. For TLS 1.2, the
information is encoded as an extension in the "CertificateStatus"
message; see Section 8 of [RFC6066]. Using stapling also allows SCTs
and inclusion proofs to be updated on the fly.
o An Online Certificate Status Protocol (OCSP) [RFC6960] response CT information can also be encoded as an extension in the X.509v3
extension (see Section 7.1.1), where the OCSP response is provided certificate (see Section 7.1.2). This mechanism allows the use of
in the "CertificateStatus" message, provided that the TLS client unmodified TLS servers, but the SCTs and inclusion proofs cannot be
included the "status_request" extension in the (extended) updated on the fly. Since the logs from which the SCTs and inclusion
"ClientHello" (Section 8 of [RFC6066]). This mechanism, popularly proofs originated won't necessarily be accepted by TLS clients for
known as OCSP stapling, is already widely (but not universally) the full lifetime of the certificate, there is a risk that TLS
implemented. It also allows SCTs and inclusion proofs to be clients may subsequently consider the certificate to be non-compliant
updated on the fly. and in need of re-issuance or the use of one of the other two methods
for delivering CT information.
o An X509v3 certificate extension (see Section 7.1.2). This 6.1. TLS Client Authentication
mechanism allows the use of unmodified TLS servers, but the SCTs
and inclusion proofs cannot be updated on the fly. Since the logs
from which the SCTs and inclusion proofs originated won't
necessarily be accepted by TLS clients for the full lifetime of
the certificate, there is a risk that TLS clients will
subsequently consider the certificate to be non-compliant and in
need of re-issuance.
6.1. Multiple SCTs This specification includes no description of how a TLS server can
use CT for TLS client certificates. While this may be useful, it is
not documented here for the following reasons:
* The greater security exposure is for clients to end up interacting
with an illegitimate server.
* In general, TLS client certificates are not expected to be
submitted to CT logs, particularly those intended for general
public use.
A future version could include such information.
6.2. Multiple SCTs
CT-using TLS servers SHOULD send SCTs from multiple logs, because: CT-using TLS servers SHOULD send SCTs from multiple logs, because:
o One or more logs may not have become acceptable to all CT-using * One or more logs may not have become acceptable to all CT-using
TLS clients. TLS clients.
o If a CA and a log collude, it is possible to temporarily hide * If a CA and a log collude, it is possible to temporarily hide
misissuance from clients. When a TLS client requires SCTs from misissuance from clients. When a TLS client requires SCTs from
multiple logs to be provided, it is more difficult to mount this multiple logs to be provided, it is more difficult to mount this
attack. attack.
o If a log misbehaves or suffers a key compromise, a consequence may * If a log misbehaves or suffers a key compromise, a consequence may
be that clients cease to trust it. Since the time an SCT may be be that clients cease to trust it. Since the time an SCT may be
in use can be considerable (several years is common in current in use can be considerable (several years is common in current
practice when embedded in a certificate), including SCTs from practice when embedded in a certificate), including SCTs from
multiple logs reduces the probability of the certificate being multiple logs reduces the probability of the certificate being
rejected by TLS clients. rejected by TLS clients.
o TLS clients may have policies related to the above risks requiring * TLS clients may have policies related to the above risks requiring
TLS servers to present multiple SCTs. For example, at the time of TLS servers to present multiple SCTs. For example, at the time of
writing, Chromium [Chromium.Log.Policy] requires multiple SCTs to writing, Chromium [Chromium.Log.Policy] requires multiple SCTs to
be presented with EV certificates in order for the EV indicator to be presented with EV certificates in order for the EV indicator to
be shown. be shown.
To select the logs from which to obtain SCTs, a TLS server can, for To select the logs from which to obtain SCTs, a TLS server can, for
example, examine the set of logs popular TLS clients accept and example, examine the set of logs popular TLS clients accept and
recognize. recognize.
6.2. TransItemList Structure 6.3. TransItemList Structure
Multiple SCTs, inclusion proofs, and indeed "TransItem" structures of Multiple SCTs, inclusion proofs, and indeed "TransItem" structures of
any type, are combined into a list as follows: any type, are combined into a list as follows:
opaque SerializedTransItem<1..2^16-1>; opaque SerializedTransItem<1..2^16-1>;
struct { struct {
SerializedTransItem trans_item_list<1..2^16-1>; SerializedTransItem trans_item_list<1..2^16-1>;
} TransItemList; } TransItemList;
Here, "SerializedTransItem" is an opaque byte string that contains Here, "SerializedTransItem" is an opaque byte string that contains
the serialized "TransItem" structure. This encoding ensures that TLS the serialized "TransItem" structure. This encoding ensures that TLS
clients can decode each "TransItem" individually (so, for example, if clients can decode each "TransItem" individually (so, for example, if
there is a version upgrade, out-of-date clients can still parse old there is a version upgrade, out-of-date clients can still parse old
"TransItem" structures while skipping over new "TransItem" structures "TransItem" structures while skipping over new "TransItem" structures
whose versions they don't understand). whose versions they don't understand).
6.3. Presenting SCTs, inclusions proofs and STHs 6.4. Presenting SCTs, inclusions proofs and STHs
In each "TransItemList" that is sent to a client during a TLS In each "TransItemList" that is sent to a client during a TLS
handshake, the TLS server MUST include a "TransItem" structure of handshake, the TLS server MUST include a "TransItem" structure of
type "x509_sct_v2" or "precert_sct_v2". type "x509_sct_v2" or "precert_sct_v2".
Presenting inclusion proofs and STHs in the TLS handshake helps to Presenting inclusion proofs and STHs in the TLS handshake helps to
protect the client's privacy (see Section 8.1.4) and reduces load on protect the client's privacy (see Section 8.1.4) and reduces load on
log servers. Therefore, if the TLS server can obtain them, it SHOULD log servers. Therefore, if the TLS server can obtain them, it SHOULD
also include "TransItem"s of type "inclusion_proof_v2" and also include "TransItem"s of type "inclusion_proof_v2" and
"signed_tree_head_v2" in the "TransItemList". "signed_tree_head_v2" in the "TransItemList".
6.4. transparency_info TLS Extension 6.5. transparency_info TLS Extension
Provided that a TLS client includes the "transparency_info" extension Provided that a TLS client includes the "transparency_info" extension
type in the ClientHello and the TLS server supports the type in the ClientHello and the TLS server supports the
"transparency_info" extension: "transparency_info" extension:
o The TLS server MUST verify that the received "extension_data" is * The TLS server MUST verify that the received "extension_data" is
empty. empty.
o The TLS server MUST construct a "TransItemList" of relevant * The TLS server MUST construct a "TransItemList" of relevant
"TransItem"s (see Section 6.3), which SHOULD omit any "TransItem"s "TransItem"s (see Section 6.4), which SHOULD omit any "TransItem"s
that are already embedded in the server certificate or the stapled that are already embedded in the server certificate or the stapled
OCSP response (see Section 7.1). If the constructed OCSP response (see Section 7.1). If the constructed
"TransItemList" is not empty, then the TLS server MUST include the "TransItemList" is not empty, then the TLS server MUST include the
"transparency_info" extension with the "extension_data" set to "transparency_info" extension with the "extension_data" set to
this "TransItemList". this "TransItemList".
TLS servers MUST only include this extension in the following TLS servers MUST only include this extension in the following
messages: messages:
o the ServerHello message (for TLS 1.2 or earlier). * the ServerHello message (for TLS 1.2 or earlier).
o the Certificate or CertificateRequest message (for TLS 1.3). * the Certificate or CertificateRequest message (for TLS 1.3).
TLS servers MUST NOT process or include this extension when a TLS TLS servers MUST NOT process or include this extension when a TLS
session is resumed, since session resumption uses the original session is resumed, since session resumption uses the original
session information. session information.
7. Certification Authorities 7. Certification Authorities
7.1. Transparency Information X.509v3 Extension 7.1. Transparency Information X.509v3 Extension
The Transparency Information X.509v3 extension, which has OID The Transparency Information X.509v3 extension, which has OID
1.3.101.75 and SHOULD be non-critical, contains one or more 1.3.101.75 and SHOULD be non-critical, contains one or more
"TransItem" structures in a "TransItemList". This extension MAY be "TransItem" structures in a "TransItemList". This extension MAY be
included in OCSP responses (see Section 7.1.1) and certificates (see included in OCSP responses (see Section 7.1.1) and certificates (see
Section 7.1.2). Since RFC5280 requires the "extnValue" field (an Section 7.1.2). Since RFC5280 requires the "extnValue" field (an
OCTET STRING) of each X.509v3 extension to include the DER encoding OCTET STRING) of each X.509v3 extension to include the DER encoding
of an ASN.1 value, a "TransItemList" MUST NOT be included directly. of an ASN.1 value, a "TransItemList" MUST NOT be included directly.
Instead, it MUST be wrapped inside an additional OCTET STRING, which Instead, it MUST be wrapped inside an additional OCTET STRING, which
skipping to change at page 39, line 36 skipping to change at page 42, line 20
8.1. TLS Client 8.1. TLS Client
8.1.1. Receiving SCTs and inclusion proofs 8.1.1. Receiving SCTs and inclusion proofs
TLS clients receive SCTs and inclusion proofs alongside or in TLS clients receive SCTs and inclusion proofs alongside or in
certificates. CT-using TLS clients MUST implement all of the three certificates. CT-using TLS clients MUST implement all of the three
mechanisms by which TLS servers may present SCTs (see Section 6). mechanisms by which TLS servers may present SCTs (see Section 6).
TLS clients that support the "transparency_info" TLS extension (see TLS clients that support the "transparency_info" TLS extension (see
Section 6.4) SHOULD include it in ClientHello messages, with empty Section 6.5) SHOULD include it in ClientHello messages, with empty
"extension_data". If a TLS server includes the "transparency_info" "extension_data". If a TLS server includes the "transparency_info"
TLS extension when resuming a TLS session, the TLS client MUST abort TLS extension when resuming a TLS session, the TLS client MUST abort
the handshake. the handshake.
8.1.2. Reconstructing the TBSCertificate 8.1.2. Reconstructing the TBSCertificate
Validation of an SCT for a certificate (where the "type" of the Validation of an SCT for a certificate (where the "type" of the
"TransItem" is "x509_sct_v2") uses the unmodified TBSCertificate "TransItem" is "x509_sct_v2") uses the unmodified TBSCertificate
component of the certificate. component of the certificate.
Before an SCT for a precertificate (where the "type" of the Before an SCT for a precertificate (where the "type" of the
"TransItem" is "precert_sct_v2") can be validated, the TBSCertificate "TransItem" is "precert_sct_v2") can be validated, the TBSCertificate
component of the precertificate needs to be reconstructed from the component of the precertificate needs to be reconstructed from the
TBSCertificate component of the certificate as follows: TBSCertificate component of the certificate as follows:
o Remove the Transparency Information extension (see Section 7.1). * Remove the Transparency Information extension (see Section 7.1).
o Remove embedded v1 SCTs, identified by OID 1.3.6.1.4.1.11129.2.4.2 * Remove embedded v1 SCTs, identified by OID 1.3.6.1.4.1.11129.2.4.2
(see section 3.3 of [RFC6962]). This allows embedded v1 and v2 (see section 3.3 of [RFC6962]). This allows embedded v1 and v2
SCTs to co-exist in a certificate (see Appendix A). SCTs to co-exist in a certificate (see Appendix A).
8.1.3. Validating SCTs 8.1.3. Validating SCTs
In order to make use of a received SCT, the TLS client MUST first In order to make use of a received SCT, the TLS client MUST first
validate it as follows: validate it as follows:
o Compute the signature input by constructing a "TransItem" of type * Compute the signature input by constructing a "TransItem" of type
"x509_entry_v2" or "precert_entry_v2", depending on the SCT's "x509_entry_v2" or "precert_entry_v2", depending on the SCT's
"TransItem" type. The "TimestampedCertificateEntryDataV2" "TransItem" type. The "TimestampedCertificateEntryDataV2"
structure is constructed in the following manner: structure is constructed in the following manner:
* "timestamp" is copied from the SCT. - "timestamp" is copied from the SCT.
* "tbs_certificate" is the reconstructed TBSCertificate portion - "tbs_certificate" is the reconstructed TBSCertificate portion
of the server certificate, as described in Section 8.1.2. of the server certificate, as described in Section 8.1.2.
* "issuer_key_hash" is computed as described in Section 4.7. - "issuer_key_hash" is computed as described in Section 4.7.
* "sct_extensions" is copied from the SCT. - "sct_extensions" is copied from the SCT.
o Verify the SCT's "signature" against the computed signature input * Verify the SCT's "signature" against the computed signature input
using the public key of the corresponding log, which is identified using the public key of the corresponding log, which is identified
by the "log_id". The required signature algorithm is one of the by the "log_id". The required signature algorithm is one of the
log's parameters. log's parameters.
If the TLS client does not have the corresponding log's parameters, If the TLS client does not have the corresponding log's parameters,
it cannot attempt to validate the SCT. When evaluating compliance it cannot attempt to validate the SCT. When evaluating compliance
(see Section 8.1.6), the TLS client will consider only those SCTs (see Section 8.1.6), the TLS client will consider only those SCTs
that it was able to validate. that it was able to validate.
Note that SCT validation is not a substitute for the normal Note that SCT validation is not a substitute for the normal
skipping to change at page 40, line 52 skipping to change at page 43, line 36
When a TLS client has validated a received SCT but does not yet When a TLS client has validated a received SCT but does not yet
possess a corresponding inclusion proof, the TLS client MAY request possess a corresponding inclusion proof, the TLS client MAY request
the inclusion proof directly from a log using "get-proof-by-hash" the inclusion proof directly from a log using "get-proof-by-hash"
(Section 5.4) or "get-all-by-hash" (Section 5.5). (Section 5.4) or "get-all-by-hash" (Section 5.5).
Note that fetching inclusion proofs directly from a log will disclose Note that fetching inclusion proofs directly from a log will disclose
to the log which TLS server the client has been communicating with. to the log which TLS server the client has been communicating with.
This may be regarded as a significant privacy concern, and so it is This may be regarded as a significant privacy concern, and so it is
preferable for the TLS server to send the inclusion proofs (see preferable for the TLS server to send the inclusion proofs (see
Section 6.3). Section 6.4).
8.1.5. Validating inclusion proofs 8.1.5. Validating inclusion proofs
When a TLS client has received, or fetched, an inclusion proof (and When a TLS client has received, or fetched, an inclusion proof (and
an STH), it SHOULD proceed to verifying the inclusion proof to the an STH), it SHOULD proceed to verifying the inclusion proof to the
provided STH. The TLS client SHOULD also verify consistency between provided STH. The TLS client SHOULD also verify consistency between
the provided STH and an STH it knows about. the provided STH and an STH it knows about.
If the TLS client holds an STH that predates the SCT, it MAY, in the If the TLS client holds an STH that predates the SCT, it MAY, in the
process of auditing, request a new STH from the log (Section 5.2), process of auditing, request a new STH from the log (Section 5.2),
skipping to change at page 43, line 5 skipping to change at page 45, line 40
8.3. Auditing 8.3. Auditing
Auditing ensures that the current published state of a log is Auditing ensures that the current published state of a log is
reachable from previously published states that are known to be good, reachable from previously published states that are known to be good,
and that the promises made by the log in the form of SCTs have been and that the promises made by the log in the form of SCTs have been
kept. Audits are performed by monitors or TLS clients. kept. Audits are performed by monitors or TLS clients.
In particular, there are four log behavior properties that should be In particular, there are four log behavior properties that should be
checked: checked:
o The Maximum Merge Delay (MMD). * The Maximum Merge Delay (MMD).
o The STH Frequency Count. * The STH Frequency Count.
o The append-only property. * The append-only property.
o The consistency of the log view presented to all query sources. * The consistency of the log view presented to all query sources.
A benign, conformant log publishes a series of STHs over time, each A benign, conformant log publishes a series of STHs over time, each
derived from the previous STH and the submitted entries incorporated derived from the previous STH and the submitted entries incorporated
into the log since publication of the previous STH. This can be into the log since publication of the previous STH. This can be
proven through auditing of STHs. SCTs returned to TLS clients can be proven through auditing of STHs. SCTs returned to TLS clients can be
audited by verifying against the accompanying certificate, and using audited by verifying against the accompanying certificate, and using
Merkle Inclusion Proofs, against the log's Merkle tree. Merkle Inclusion Proofs, against the log's Merkle tree.
The action taken by the auditor if an audit fails is not specified, The action taken by the auditor if an audit fails is not specified,
but note that in general if audit fails, the auditor is in possession but note that in general if audit fails, the auditor is in possession
skipping to change at page 44, line 33 skipping to change at page 47, line 28
IANA is asked to add an entry for "transparency_info(TBD)" to the IANA is asked to add an entry for "transparency_info(TBD)" to the
"TLS ExtensionType Values" registry defined in [RFC8446], setting the "TLS ExtensionType Values" registry defined in [RFC8446], setting the
"Recommended" value to "Y", setting the "TLS 1.3" value to "CH, CR, "Recommended" value to "Y", setting the "TLS 1.3" value to "CH, CR,
CT", and citing this document as the "Reference". CT", and citing this document as the "Reference".
10.2. Hash Algorithms 10.2. Hash Algorithms
IANA is asked to establish a registry of hash algorithm values, named IANA is asked to establish a registry of hash algorithm values, named
"CT Hash Algorithms", that initially consists of: "CT Hash Algorithms", that initially consists of:
+---------+------------+------------------------+-------------------+ +========+============+========================+===================+
| Value | Hash | OID | Reference / | | Value | Hash | OID | Reference / |
| | Algorithm | | Assignment Policy | | | Algorithm | | Assignment Policy |
+---------+------------+------------------------+-------------------+ +========+============+========================+===================+
| 0x00 | SHA-256 | 2.16.840.1.101.3.4.2.1 | [RFC6234] | | 0x00 | SHA-256 | 2.16.840.1.101.3.4.2.1 | [RFC6234] |
| | | | | +--------+------------+------------------------+-------------------+
| 0x01 - | Unassigned | | Specification | | 0x01 - | Unassigned | | Specification |
| 0xDF | | | Required | | 0xDF | | | Required |
| | | | | +--------+------------+------------------------+-------------------+
| 0xE0 - | Reserved | | Experimental Use | | 0xE0 - | Reserved | | Experimental Use |
| 0xEF | | | | | 0xEF | | | |
| | | | | +--------+------------+------------------------+-------------------+
| 0xF0 - | Reserved | | Private Use | | 0xF0 - | Reserved | | Private Use |
| 0xFF | | | | | 0xFF | | | |
+---------+------------+------------------------+-------------------+ +--------+------------+------------------------+-------------------+
Table 7
10.2.1. Specification Required guidance 10.2.1. Specification Required guidance
The appointed Expert should ensure that the proposed algorithm has a The appointed Expert should ensure that the proposed algorithm has a
public specification and is suitable for use as a cryptographic hash public specification and is suitable for use as a cryptographic hash
algorithm with no known preimage or collision attacks. These attacks algorithm with no known preimage or collision attacks. These attacks
can damage the integrity of the log. can damage the integrity of the log.
10.3. Signature Algorithms 10.3. Signature Algorithms
IANA is asked to establish a registry of signature algorithm values, IANA is asked to establish a registry of signature algorithm values,
named "CT Signature Algorithms", that initially consists of: named "CT Signature Algorithms", that initially consists of:
+--------------------------------+-------------------+--------------+ +================================+==================+==============+
| SignatureScheme Value | Signature | Reference / | | SignatureScheme Value | Signature | Reference / |
| | Algorithm | Assignment | | | Algorithm | Assignment |
| | | Policy | | | | Policy |
+--------------------------------+-------------------+--------------+ +================================+==================+==============+
| 0x0000 - 0x0402 | Unassigned | Expert | | 0x0000 - 0x0402 | Unassigned | Expert |
| | | Review | | | | Review |
| | | | +--------------------------------+------------------+--------------+
| ecdsa_secp256r1_sha256(0x0403) | ECDSA (NIST | [FIPS186-4] | | ecdsa_secp256r1_sha256(0x0403) | ECDSA (NIST | [FIPS186-4] |
| | P-256) with | | | | P-256) with | |
| | SHA-256 | | | | SHA-256 | |
| | | | +--------------------------------+------------------+--------------+
| ecdsa_secp256r1_sha256(0x0403) | Deterministic | [RFC6979] | | ecdsa_secp256r1_sha256(0x0403) | Deterministic | [RFC6979] |
| | ECDSA (NIST | | | | ECDSA (NIST | |
| | P-256) with HMAC- | | | | P-256) with | |
| | SHA256 | | | | HMAC-SHA256 | |
| | | | +--------------------------------+------------------+--------------+
| 0x0404 - 0x0806 | Unassigned | Expert | | 0x0404 - 0x0806 | Unassigned | Expert |
| | | Review | | | | Review |
| | | | +--------------------------------+------------------+--------------+
| ed25519(0x0807) | Ed25519 | [RFC8032] | | ed25519(0x0807) | Ed25519 | [RFC8032] |
| | (PureEdDSA with | | | | (PureEdDSA with | |
| | the edwards25519 | | | | the edwards25519 | |
| | curve) | | | | curve) | |
| | | | +--------------------------------+------------------+--------------+
| 0x0808 - 0xFDFF | Unassigned | Expert | | 0x0808 - 0xFDFF | Unassigned | Expert |
| | | Review | | | | Review |
| | | | +--------------------------------+------------------+--------------+
| 0xFE00 - 0xFEFF | Reserved | Experimental | | 0xFE00 - 0xFEFF | Reserved | Experimental |
| | | Use | | | | Use |
| | | | +--------------------------------+------------------+--------------+
| 0xFF00 - 0xFFFF | Reserved | Private Use | | 0xFF00 - 0xFFFF | Reserved | Private Use |
+--------------------------------+-------------------+--------------+ +--------------------------------+------------------+--------------+
Table 8
10.3.1. Expert Review guidelines 10.3.1. Expert Review guidelines
The appointed Expert should ensure that the proposed algorithm has a The appointed Expert should ensure that the proposed algorithm has a
public specification, has a value assigned to it in the TLS public specification, has a value assigned to it in the TLS
SignatureScheme Registry (that IANA is asked to establish in SignatureScheme Registry (that IANA is asked to establish in
[RFC8446]) and is suitable for use as a cryptographic signature [RFC8446]) and is suitable for use as a cryptographic signature
algorithm. algorithm.
10.4. VersionedTransTypes 10.4. VersionedTransTypes
IANA is asked to establish a registry of "VersionedTransType" values, IANA is asked to establish a registry of "VersionedTransType" values,
named "CT VersionedTransTypes", that initially consists of: named "CT VersionedTransTypes", that initially consists of:
+----------------+----------------------+---------------------------+ +==========+======================+===============================+
| Value | Type and Version | Reference / Assignment | | Value | Type and Version | Reference / Assignment Policy |
| | | Policy | +==========+======================+===============================+
+----------------+----------------------+---------------------------+ | 0x0000 | Reserved | [RFC6962] * |
| 0x0000 | Reserved | [RFC6962] (*) | +----------+----------------------+-------------------------------+
| | | | | 0x0001 | x509_entry_v2 | RFCXXXX |
| 0x0001 | x509_entry_v2 | RFCXXXX | +----------+----------------------+-------------------------------+
| | | | | 0x0002 | precert_entry_v2 | RFCXXXX |
| 0x0002 | precert_entry_v2 | RFCXXXX | +----------+----------------------+-------------------------------+
| | | | | 0x0003 | x509_sct_v2 | RFCXXXX |
| 0x0003 | x509_sct_v2 | RFCXXXX | +----------+----------------------+-------------------------------+
| | | | | 0x0004 | precert_sct_v2 | RFCXXXX |
| 0x0004 | precert_sct_v2 | RFCXXXX | +----------+----------------------+-------------------------------+
| | | | | 0x0005 | signed_tree_head_v2 | RFCXXXX |
| 0x0005 | signed_tree_head_v2 | RFCXXXX | +----------+----------------------+-------------------------------+
| | | | | 0x0006 | consistency_proof_v2 | RFCXXXX |
| 0x0006 | consistency_proof_v2 | RFCXXXX | +----------+----------------------+-------------------------------+
| | | | | 0x0007 | inclusion_proof_v2 | RFCXXXX |
| 0x0007 | inclusion_proof_v2 | RFCXXXX | +----------+----------------------+-------------------------------+
| | | | | 0x0008 - | Unassigned | Specification Required |
| 0x0008 - | Unassigned | Specification Required | | 0xDFFF | | |
| 0xDFFF | | | +----------+----------------------+-------------------------------+
| | | | | 0xE000 - | Reserved | Experimental Use |
| 0xE000 - | Reserved | Experimental Use | | 0xEFFF | | |
| 0xEFFF | | | +----------+----------------------+-------------------------------+
| | | | | 0xF000 - | Reserved | Private Use |
| 0xF000 - | Reserved | Private Use | | 0xFFFF | | |
| 0xFFFF | | | +----------+----------------------+-------------------------------+
+----------------+----------------------+---------------------------+
(*) The 0x0000 value is reserved so that v1 SCTs are distinguishable Table 9
* The 0x0000 value is reserved so that v1 SCTs are distinguishable
from v2 SCTs and other "TransItem" structures. from v2 SCTs and other "TransItem" structures.
[RFC Editor: please update 'RFCXXXX' to refer to this document, once [RFC Editor: please update 'RFCXXXX' to refer to this document, once
its RFC number is known.] its RFC number is known through the document.]
10.4.1. Specification Required guidance 10.4.1. Specification Required guidance
The appointed Expert should review the public specification to ensure The appointed Expert should review the public specification to ensure
that it is detailed enough to ensure implementation interoperability. that it is detailed enough to ensure implementation interoperability.
10.5. Log Artifact Extension Registry 10.5. Log Artifact Extension Registry
IANA is asked to establish a registry of "ExtensionType" values, IANA is asked to establish a registry of "ExtensionType" values,
named "CT Log Artifact Extensions", that initially consists of: named "CT Log Artifact Extensions", that initially consists of:
+-----------------+------------+-----+------------------------------+ +===============+============+=====+===============================+
| ExtensionType | Status | Use | Reference / Assignment | | ExtensionType | Status | Use | Reference / Assignment Policy |
| | | | Policy | +===============+============+=====+===============================+
+-----------------+------------+-----+------------------------------+ | 0x0000 - | Unassigned | n/a | Specification Required |
| 0x0000 - 0xDFFF | Unassigned | n/a | Specification Required | | 0xDFFF | | | |
| | | | | +---------------+------------+-----+-------------------------------+
| 0xE000 - 0xEFFF | Reserved | n/a | Experimental Use | | 0xE000 - | Reserved | n/a | Experimental Use |
| | | | | | 0xEFFF | | | |
| 0xF000 - 0xFFFF | Reserved | n/a | Private Use | +---------------+------------+-----+-------------------------------+
+-----------------+------------+-----+------------------------------+ | 0xF000 - | Reserved | n/a | Private Use |
| 0xFFFF | | | |
+---------------+------------+-----+-------------------------------+
Table 10
The "Use" column should contain one or both of the following values: The "Use" column should contain one or both of the following values:
o "SCT", for extensions specified for use in Signed Certificate * "SCT", for extensions specified for use in Signed Certificate
Timestamps. Timestamps.
o "STH", for extensions specified for use in Signed Tree Heads. * "STH", for extensions specified for use in Signed Tree Heads.
10.5.1. Specification Required guidance 10.5.1. Specification Required guidance
The appointed Expert should review the public specification to ensure The appointed Expert should review the public specification to ensure
that it is detailed enough to ensure implementation interoperability. that it is detailed enough to ensure implementation interoperability.
The Expert should also verify that the extension is appropriate to The Expert should also verify that the extension is appropriate to
the contexts in which it is specified to be used (SCT, STH, or both). the contexts in which it is specified to be used (SCT, STH, or both).
10.6. Object Identifiers 10.6. Object Identifiers
skipping to change at page 48, line 5 skipping to change at page 51, line 5
Section 4.4), the precertificate CMS "eContentType" (see Section 4.4), the precertificate CMS "eContentType" (see
Section 3.2), and X.509v3 extensions in certificates (see Section 3.2), and X.509v3 extensions in certificates (see
Section 7.1.2) and OCSP responses (see Section 7.1.1). The OIDs are Section 7.1.2) and OCSP responses (see Section 7.1.1). The OIDs are
defined in an arc that was selected due to its short encoding. defined in an arc that was selected due to its short encoding.
10.6.1. Log ID Registry 10.6.1. Log ID Registry
IANA is asked to establish a registry of Log IDs, named "CT Log ID IANA is asked to establish a registry of Log IDs, named "CT Log ID
Registry", that initially consists of: Registry", that initially consists of:
+---------------------+------------+------------+-------------------+ +================+==============+==============+===================+
| Log ID | Log Base | Log | Reference / | | Log ID | Log Base URL | Log Operator | Reference / |
| | URL | Operator | Assignment Policy | | | | | Assignment Policy |
+---------------------+------------+------------+-------------------+ +================+==============+==============+===================+
| 1.3.101.8192 - | Unassigned | Unassigned | First Come First | | 1.3.101.8192 - | Unassigned | Unassigned | First Come First |
| 1.3.101.16383 | | | Served | | 1.3.101.16383 | | | Served |
| | | | | +----------------+--------------+--------------+-------------------+
| 1.3.101.80.0 - | Unassigned | Unassigned | First Come First | | 1.3.101.80.0 - | Unassigned | Unassigned | First Come First |
| 1.3.101.80.* | | | Served | | 1.3.101.80.* | | | Served |
+---------------------+------------+------------+-------------------+ +----------------+--------------+--------------+-------------------+
Table 11
All OIDs in the range from 1.3.101.8192 to 1.3.101.16383 have been All OIDs in the range from 1.3.101.8192 to 1.3.101.16383 have been
reserved. This is a limited resource of 8,192 OIDs, each of which reserved. This is a limited resource of 8,192 OIDs, each of which
has an encoded length of 4 octets. has an encoded length of 4 octets.
The 1.3.101.80 arc has been delegated. This is an unlimited The 1.3.101.80 arc has been delegated. This is an unlimited
resource, but only the 128 OIDs from 1.3.101.80.0 to 1.3.101.80.127 resource, but only the 128 OIDs from 1.3.101.80.0 to 1.3.101.80.127
have an encoded length of only 4 octets. have an encoded length of only 4 octets.
Each application for the allocation of a Log ID MUST be accompanied Each application for the allocation of a Log ID MUST be accompanied
by: by:
o the Log's Base URL (see Section 4.1). * the Log's Base URL (see Section 4.1).
o the Log Operator's contact details. * the Log Operator's contact details.
IANA is asked to reject any request to update a Log ID or Log Base IANA is asked to reject any request to update a Log ID or Log Base
URL in this registry, because these fields are immutable (see URL in this registry, because these fields are immutable (see
Section 4.1). Section 4.1).
IANA is asked to accept requests from log operators to update their IANA is asked to accept requests from log operators to update their
contact details in this registry. contact details in this registry.
Since log operators can choose to not use this registry (see Since log operators can choose to not use this registry (see
Section 4.4), it is not expected to be a global directory of all Section 4.4), it is not expected to be a global directory of all
logs. logs.
10.7. URN Sub-namespace for TRANS errors (urn:ietf:params:trans:error)
IANA is requested to add a new entry in the "IETF URN Sub-namespace
for Registered Protocol Parameter Identifiers" registry, following
the template in [RFC3553]:
Registry name: trans:error
Specification: RFCXXXX
Repository: https://www.iana.org/assignments/trans
Index value: No transformation needed.
10.7.1. TRANS Error Types
IANA is requested to create a new registry for errors. Requirements
for this registry are Specification Required.
This registry should have the following three fields:
+============+========+===========+
| Field Name | Type | Reference |
+============+========+===========+
| identifier | string | RFCXXXX |
+------------+--------+-----------+
| meaning | string | RFCXXXX |
+------------+--------+-----------+
| reference | string | RFCXXXX |
+------------+--------+-----------+
Table 12
The initial values are as follows, taken from the text above:
+===================+===============================+===========+
| Identifier | Meaning | Reference |
+===================+===============================+===========+
| malformed | The request could not be | RFCXXXX |
| | parsed. | |
+-------------------+-------------------------------+-----------+
| badSubmission | "submission" is neither a | RFCXXXX |
| | valid certificate nor a valid | |
| | precertificate | |
+-------------------+-------------------------------+-----------+
| badType | "type" is neither 1 nor 2 | RFCXXXX |
+-------------------+-------------------------------+-----------+
| badChain | The first element of "chain" | RFCXXXX |
| | is not the certifier of the | |
| | "submission", or the second | |
| | element does not certify the | |
| | first, etc. | |
+-------------------+-------------------------------+-----------+
| badCertificate | One or more certificates in | RFCXXXX |
| | the "chain" are not valid | |
| | (e.g., not properly encoded) | |
+-------------------+-------------------------------+-----------+
| unknownAnchor | The last element of "chain" | RFCXXXX |
| | (or, if "chain" is an empty | |
| | array, the "submission") both | |
| | is not, and is not certified | |
| | by, an accepted trust anchor | |
+-------------------+-------------------------------+-----------+
| shutdown | The log is no longer | RFCXXXX |
| | accepting submissions | |
+-------------------+-------------------------------+-----------+
| firstUnknown | "first" is before the latest | RFCXXXX |
| | known STH but is not from an | |
| | existing STH. | |
+-------------------+-------------------------------+-----------+
| secondUnknown | "second" is before the latest | RFCXXXX |
| | known STH but is not from an | |
| | existing STH. | |
+-------------------+-------------------------------+-----------+
| secondBeforeFirst | "second" is smaller than | RFCXXXX |
| | "first". | |
+-------------------+-------------------------------+-----------+
| hashUnknown | "hash" is not the hash of a | RFCXXXX |
| | known leaf (may be caused by | |
| | skew or by a known | |
| | certificate not yet merged). | |
+-------------------+-------------------------------+-----------+
| treeSizeUnknown | "hash" is before the latest | RFCXXXX |
| | known STH but is not from an | |
| | existing STH. | |
+-------------------+-------------------------------+-----------+
| startUnknown | "start" is greater than the | RFCXXXX |
| | number of entries in the | |
| | Merkle tree. | |
+-------------------+-------------------------------+-----------+
| endBeforeStart | "start" cannot be greater | RFCXXXX |
| | than "end". | |
+-------------------+-------------------------------+-----------+
Table 13
11. Security Considerations 11. Security Considerations
With CAs, logs, and servers performing the actions described here, With CAs, logs, and servers performing the actions described here,
TLS clients can use logs and signed timestamps to reduce the TLS clients can use logs and signed timestamps to reduce the
likelihood that they will accept misissued certificates. If a server likelihood that they will accept misissued certificates. If a server
presents a valid signed timestamp for a certificate, then the client presents a valid signed timestamp for a certificate, then the client
knows that a log has committed to publishing the certificate. From knows that a log has committed to publishing the certificate. From
this, the client knows that monitors acting for the subject of the this, the client knows that monitors acting for the subject of the
certificate have had some time to notice the misissuance and take certificate have had some time to notice the misissuance and take
some action, such as asking a CA to revoke a misissued certificate. some action, such as asking a CA to revoke a misissued certificate.
skipping to change at page 50, line 21 skipping to change at page 55, line 24
calculated from a copy of the log, proving violation of the append- calculated from a copy of the log, proving violation of the append-
only property. only property.
11.4. Preventing Tracking Clients 11.4. Preventing Tracking Clients
Clients that gossip STHs or report back SCTs can be tracked or traced Clients that gossip STHs or report back SCTs can be tracked or traced
if a log produces multiple STHs or SCTs with the same timestamp and if a log produces multiple STHs or SCTs with the same timestamp and
data but different signatures. Logs SHOULD mitigate this risk by data but different signatures. Logs SHOULD mitigate this risk by
either: either:
o Using deterministic signature schemes, or * Using deterministic signature schemes, or
o Producing no more than one SCT for each distinct submission and no * Producing no more than one SCT for each distinct submission and no
more than one STH for each distinct tree_size. Each of these SCTs more than one STH for each distinct tree_size. Each of these SCTs
and STHs can be stored by the log and served to other clients that and STHs can be stored by the log and served to other clients that
submit the same certificate or request the same STH. submit the same certificate or request the same STH.
11.5. Multiple SCTs 11.5. Multiple SCTs
By requiring TLS servers to offer multiple SCTs, each from a By requiring TLS servers to offer multiple SCTs, each from a
different log, TLS clients reduce the effectiveness of an attack different log, TLS clients reduce the effectiveness of an attack
where a CA and a log collude (see Section 6.1). where a CA and a log collude (see Section 6.2).
11.6. Leakage of DNS Information 11.6. Leakage of DNS Information
Malicious monitors can use logs to learn about the existence of Malicious monitors can use logs to learn about the existence of
domain names that might not otherwise be easy to discover. Some domain names that might not otherwise be easy to discover. Some
subdomain labels may reveal information about the service and subdomain labels may reveal information about the service and
software for which the subdomain is used, which in turn might software for which the subdomain is used, which in turn might
facilitate targeted attacks. facilitate targeted attacks.
12. Acknowledgements 12. Acknowledgements
The authors would like to thank Erwann Abelea, Robin Alden, Andrew The authors would like to thank Erwann Abelea, Robin Alden, Andrew
Ayer, Richard Barnes, Al Cutter, David Drysdale, Francis Dupont, Adam Ayer, Richard Barnes, Al Cutter, David Drysdale, Francis Dupont, Adam
Eijdenberg, Stephen Farrell, Daniel Kahn Gillmor, Paul Hadfield, Brad Eijdenberg, Stephen Farrell, Daniel Kahn Gillmor, Paul Hadfield, Brad
Hill, Jeff Hodges, Paul Hoffman, Jeffrey Hutzelman, Kat Joyce, Hill, Jeff Hodges, Paul Hoffman, Jeffrey Hutzelman, Kat Joyce,
Stephen Kent, SM, Alexey Melnikov, Linus Nordberg, Chris Palmer, Stephen Kent, SM, Alexey Melnikov, Linus Nordberg, Chris Palmer,
Trevor Perrin, Pierre Phaneuf, Eric Rescorla, Melinda Shore, Ryan Trevor Perrin, Pierre Phaneuf, Eric Rescorla, Rich Salz, Melinda
Sleevi, Martin Smith, Carl Wallace and Paul Wouters for their Shore, Ryan Sleevi, Martin Smith, Carl Wallace and Paul Wouters for
valuable contributions. their valuable contributions.
A big thank you to Symantec for kindly donating the OIDs from the A big thank you to Symantec for kindly donating the OIDs from the
1.3.101 arc that are used in this document. 1.3.101 arc that are used in this document.
13. References 13. References
13.1. Normative References 13.1. Normative References
[FIPS186-4] [FIPS186-4]
NIST, "FIPS PUB 186-4", July 2013, NIST, "FIPS PUB 186-4", 1 July 2013,
<http://nvlpubs.nist.gov/nistpubs/FIPS/ <http://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.186-4.pdf>. NIST.FIPS.186-4.pdf>.
[HTML401] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 [HTML401] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01
Specification", World Wide Web Consortium Recommendation Specification", World Wide Web Consortium Recommendation
REC-html401-19991224, December 1999, REC-html401-19991224, 24 December 1999,
<http://www.w3.org/TR/1999/REC-html401-19991224>. <http://www.w3.org/TR/1999/REC-html401-19991224>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June
2003, <https://www.rfc-editor.org/info/rfc3553>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
skipping to change at page 52, line 36 skipping to change at page 57, line 42
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[UNIXTIME] [UNIXTIME] IEEE, "The Open Group Base Specifications Issue 7 IEEE Std
IEEE, "The Open Group Base Specifications Issue 7 IEEE Std 1003.1-2008, 2016 Edition", n.d.,
1003.1-2008, 2016 Edition", n.d., <http://pubs.opengroup.o <http://pubs.opengroup.org/
rg/onlinepubs/9699919799.2016edition/basedefs/ onlinepubs/9699919799.2016edition/basedefs/
V1_chap04.html#tag_04_16>. V1_chap04.html#tag_04_16>.
13.2. Informative References 13.2. Informative References
[Chromium.Log.Policy] [Chromium.Log.Policy]
The Chromium Projects, "Chromium Certificate Transparency The Chromium Projects, "Chromium Certificate Transparency
Log Policy", 2014, <http://www.chromium.org/Home/chromium- Log Policy", 2014, <http://www.chromium.org/Home/chromium-
security/certificate-transparency/log-policy>. security/certificate-transparency/log-policy>.
[Chromium.Policy] [Chromium.Policy]
skipping to change at page 53, line 13 skipping to change at page 58, line 23
chromium-security/certificate-transparency>. chromium-security/certificate-transparency>.
[CrosbyWallach] [CrosbyWallach]
Crosby, S. and D. Wallach, "Efficient Data Structures for Crosby, S. and D. Wallach, "Efficient Data Structures for
Tamper-Evident Logging", Proceedings of the 18th USENIX Tamper-Evident Logging", Proceedings of the 18th USENIX
Security Symposium, Montreal, August 2009, Security Symposium, Montreal, August 2009,
<http://static.usenix.org/event/sec09/tech/full_papers/ <http://static.usenix.org/event/sec09/tech/full_papers/
crosby.pdf>. crosby.pdf>.
[I-D.ietf-trans-gossip] [I-D.ietf-trans-gossip]
Nordberg, L., Gillmor, D., and T. Ritter, "Gossiping in Nordberg, L., Gillmor, D. K., and T. Ritter, "Gossiping in
CT", draft-ietf-trans-gossip-05 (work in progress), CT", Work in Progress, Internet-Draft, draft-ietf-trans-
January 2018. gossip-05, 14 January 2018,
<https://www.ietf.org/archive/id/draft-ietf-trans-gossip-
05.txt>.
[I-D.ietf-trans-threat-analysis] [I-D.ietf-trans-threat-analysis]
Kent, S., "Attack and Threat Model for Certificate Kent, S., "Attack and Threat Model for Certificate
Transparency", draft-ietf-trans-threat-analysis-16 (work Transparency", Work in Progress, Internet-Draft, draft-
in progress), October 2018. ietf-trans-threat-analysis-16, 5 October 2018,
<https://www.ietf.org/archive/id/draft-ietf-trans-threat-
analysis-16.txt>.
[JSON.Metadata] [JSON.Metadata]
The Chromium Projects, "Chromium Log Metadata JSON The Chromium Projects, "Chromium Log Metadata JSON
Schema", 2014, <https://www.gstatic.com/ct/log_list/ Schema", 2014, <https://www.gstatic.com/ct/log_list/
log_list_schema.json>. log_list_schema.json>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>. <https://www.rfc-editor.org/info/rfc6234>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<https://www.rfc-editor.org/info/rfc6962>. <https://www.rfc-editor.org/info/rfc6962>.
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <https://www.rfc-editor.org/info/rfc6979>. 2013, <https://www.rfc-editor.org/info/rfc6979>.
[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, [RFC7320] Nottingham, M., "URI Design and Ownership", RFC 7320,
RFC 7320, DOI 10.17487/RFC7320, July 2014, DOI 10.17487/RFC7320, July 2014,
<https://www.rfc-editor.org/info/rfc7320>. <https://www.rfc-editor.org/info/rfc7320>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
Appendix A. Supporting v1 and v2 simultaneously Appendix A. Supporting v1 and v2 simultaneously
Certificate Transparency logs have to be either v1 (conforming to Certificate Transparency logs have to be either v1 (conforming to
skipping to change at page 54, line 24 skipping to change at page 59, line 38
TLS, X.509 and OCSP extensions than v2 SCTs. TLS, X.509 and OCSP extensions than v2 SCTs.
v1 and v2 SCTs for X.509 certificates can be validated independently. v1 and v2 SCTs for X.509 certificates can be validated independently.
For precertificates, v2 SCTs should be embedded in the TBSCertificate For precertificates, v2 SCTs should be embedded in the TBSCertificate
before submission of the TBSCertificate (inside a v1 precertificate, before submission of the TBSCertificate (inside a v1 precertificate,
as described in Section 3.1. of [RFC6962]) to a v1 log so that TLS as described in Section 3.1. of [RFC6962]) to a v1 log so that TLS
clients conforming to [RFC6962] but not this document are oblivious clients conforming to [RFC6962] but not this document are oblivious
to the embedded v2 SCTs. An issuer can follow these steps to produce to the embedded v2 SCTs. An issuer can follow these steps to produce
an X.509 certificate with embedded v1 and v2 SCTs: an X.509 certificate with embedded v1 and v2 SCTs:
o Create a CMS precertificate as described in Section 3.2 and submit * Create a CMS precertificate as described in Section 3.2 and submit
it to v2 logs. it to v2 logs.
o Embed the obtained v2 SCTs in the TBSCertificate, as described in * Embed the obtained v2 SCTs in the TBSCertificate, as described in
Section 7.1.2. Section 7.1.2.
o Use that TBSCertificate to create a v1 precertificate, as * Use that TBSCertificate to create a v1 precertificate, as
described in Section 3.1. of [RFC6962] and submit it to v1 logs. described in Section 3.1. of [RFC6962] and submit it to v1 logs.
o Embed the v1 SCTs in the TBSCertificate, as described in * Embed the v1 SCTs in the TBSCertificate, as described in
Section 3.3 of [RFC6962]. Section 3.3 of [RFC6962].
o Sign that TBSCertificate (which now contains v1 and v2 SCTs) to * Sign that TBSCertificate (which now contains v1 and v2 SCTs) to
issue the final X.509 certificate. issue the final X.509 certificate.
Authors' Addresses Authors' Addresses
Ben Laurie Ben Laurie
Google UK Ltd. Google UK Ltd.
Email: benl@google.com Email: benl@google.com
Adam Langley Adam Langley
 End of changes. 155 change blocks. 
450 lines changed or deleted 579 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/