< draft-ietf-trans-rfc6962-bis-31.txt   draft-ietf-trans-rfc6962-bis-32.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: August 29, 2019 Google Expires: December 22, 2019 Google
R. Stradling R. Stradling
Sectigo Sectigo
February 25, 2019 June 20, 2019
Certificate Transparency Version 2.0 Certificate Transparency Version 2.0
draft-ietf-trans-rfc6962-bis-31 draft-ietf-trans-rfc6962-bis-32
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 August 29, 2019. This Internet-Draft will expire on December 22, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
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 . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . . 13 2.2. Signatures . . . . . . . . . . . . . . . . . . . . . . . 14
3. Submitters . . . . . . . . . . . . . . . . . . . . . . . . . 13 3. Submitters . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1. Certificates . . . . . . . . . . . . . . . . . . . . . . 14 3.1. Certificates . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Precertificates . . . . . . . . . . . . . . . . . . . . . 14 3.2. Precertificates . . . . . . . . . . . . . . . . . . . . . 14
4. Log Format and Operation . . . . . . . . . . . . . . . . . . 15 4. Log Format and Operation . . . . . . . . . . . . . . . . . . 16
4.1. Log Parameters . . . . . . . . . . . . . . . . . . . . . 16 4.1. Log Parameters . . . . . . . . . . . . . . . . . . . . . 16
4.2. Evaluating Submissions . . . . . . . . . . . . . . . . . 17 4.2. Evaluating Submissions . . . . . . . . . . . . . . . . . 17
4.2.1. Minimum Acceptance Criteria . . . . . . . . . . . . . 17 4.2.1. Minimum Acceptance Criteria . . . . . . . . . . . . . 18
4.2.2. Discretionary Acceptance Criteria . . . . . . . . . . 18 4.2.2. Discretionary Acceptance Criteria . . . . . . . . . . 18
4.3. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 18 4.3. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 19
4.4. Log ID . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.4. Log ID . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.5. TransItem Structure . . . . . . . . . . . . . . . . . . . 19 4.5. TransItem Structure . . . . . . . . . . . . . . . . . . . 19
4.6. Log Artifact Extensions . . . . . . . . . . . . . . . . . 20 4.6. Log Artifact Extensions . . . . . . . . . . . . . . . . . 20
4.7. Merkle Tree Leaves . . . . . . . . . . . . . . . . . . . 21 4.7. Merkle Tree Leaves . . . . . . . . . . . . . . . . . . . 21
4.8. Signed Certificate Timestamp (SCT) . . . . . . . . . . . 22 4.8. Signed Certificate Timestamp (SCT) . . . . . . . . . . . 22
4.9. Merkle Tree Head . . . . . . . . . . . . . . . . . . . . 23 4.9. Merkle Tree Head . . . . . . . . . . . . . . . . . . . . 23
4.10. Signed Tree Head (STH) . . . . . . . . . . . . . . . . . 23 4.10. Signed Tree Head (STH) . . . . . . . . . . . . . . . . . 23
4.11. Merkle Consistency Proofs . . . . . . . . . . . . . . . . 24 4.11. Merkle Consistency Proofs . . . . . . . . . . . . . . . . 24
4.12. Merkle Inclusion Proofs . . . . . . . . . . . . . . . . . 25 4.12. Merkle Inclusion Proofs . . . . . . . . . . . . . . . . . 25
4.13. Shutting down a log . . . . . . . . . . . . . . . . . . . 25 4.13. Shutting down a log . . . . . . . . . . . . . . . . . . . 25
5. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 26 5. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 26
5.1. Submit Entry to Log . . . . . . . . . . . . . . . . . . . 27 5.1. Submit Entry to Log . . . . . . . . . . . . . . . . . . . 27
5.2. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 30 5.2. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 29
5.3. Retrieve Merkle Consistency Proof between Two Signed Tree 5.3. Retrieve Merkle Consistency Proof between Two Signed Tree
Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4. Retrieve Merkle Inclusion Proof from Log by Leaf Hash . . 31 5.4. Retrieve Merkle Inclusion Proof from Log by Leaf Hash . . 30
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 . . . . . . . . . . . . . 31
5.6. Retrieve Entries and STH from Log . . . . . . . . . . . . 33 5.6. Retrieve Entries and STH from Log . . . . . . . . . . . . 33
5.7. Retrieve Accepted Trust Anchors . . . . . . . . . . . . . 35 5.7. Retrieve Accepted Trust Anchors . . . . . . . . . . . . . 34
6. TLS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 35 6. TLS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.1. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . . 36 6.1. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . . 35
6.2. TransItemList Structure . . . . . . . . . . . . . . . . . 37 6.2. TransItemList Structure . . . . . . . . . . . . . . . . . 36
6.3. Presenting SCTs, inclusions proofs and STHs . . . . . . . 37 6.3. Presenting SCTs, inclusions proofs and STHs . . . . . . . 36
6.4. transparency_info TLS Extension . . . . . . . . . . . . . 37 6.4. transparency_info TLS Extension . . . . . . . . . . . . . 37
7. Certification Authorities . . . . . . . . . . . . . . . . . . 38 7. Certification Authorities . . . . . . . . . . . . . . . . . . 37
7.1. Transparency Information X.509v3 Extension . . . . . . . 38 7.1. Transparency Information X.509v3 Extension . . . . . . . 37
7.1.1. OCSP Response Extension . . . . . . . . . . . . . . . 38 7.1.1. OCSP Response Extension . . . . . . . . . . . . . . . 38
7.1.2. Certificate Extension . . . . . . . . . . . . . . . . 38 7.1.2. Certificate Extension . . . . . . . . . . . . . . . . 38
7.2. TLS Feature X.509v3 Extension . . . . . . . . . . . . . . 39 7.2. TLS Feature X.509v3 Extension . . . . . . . . . . . . . . 38
8. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 8. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.1. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 39 8.1. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 38
8.1.1. Receiving SCTs and inclusion proofs . . . . . . . . . 39 8.1.1. Receiving SCTs and inclusion proofs . . . . . . . . . 38
8.1.2. Reconstructing the TBSCertificate . . . . . . . . . . 39 8.1.2. Reconstructing the TBSCertificate . . . . . . . . . . 39
8.1.3. Validating SCTs . . . . . . . . . . . . . . . . . . . 40 8.1.3. Validating SCTs . . . . . . . . . . . . . . . . . . . 39
8.1.4. Fetching inclusion proofs . . . . . . . . . . . . . . 40 8.1.4. Fetching inclusion proofs . . . . . . . . . . . . . . 40
8.1.5. Validating inclusion proofs . . . . . . . . . . . . . 41 8.1.5. Validating inclusion proofs . . . . . . . . . . . . . 40
8.1.6. Evaluating compliance . . . . . . . . . . . . . . . . 41 8.1.6. Evaluating compliance . . . . . . . . . . . . . . . . 40
8.2. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 41 8.2. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.3. Auditing . . . . . . . . . . . . . . . . . . . . . . . . 42 8.3. Auditing . . . . . . . . . . . . . . . . . . . . . . . . 42
9. Algorithm Agility . . . . . . . . . . . . . . . . . . . . . . 43 9. Algorithm Agility . . . . . . . . . . . . . . . . . . . . . . 43
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
10.1. New Entry to the TLS ExtensionType Registry . . . . . . 44 10.1. New Entry to the TLS ExtensionType Registry . . . . . . 43
10.2. Hash Algorithms . . . . . . . . . . . . . . . . . . . . 44 10.2. Hash Algorithms . . . . . . . . . . . . . . . . . . . . 43
10.2.1. Expert Review guidelines . . . . . . . . . . . . . . 45 10.2.1. Specification Required guidance . . . . . . . . . . 44
10.3. Signature Algorithms . . . . . . . . . . . . . . . . . . 45 10.3. Signature Algorithms . . . . . . . . . . . . . . . . . . 44
10.3.1. Expert Review guidelines . . . . . . . . . . . . . . 45 10.3.1. Expert Review guidelines . . . . . . . . . . . . . . 45
10.4. VersionedTransTypes . . . . . . . . . . . . . . . . . . 45 10.4. VersionedTransTypes . . . . . . . . . . . . . . . . . . 45
10.4.1. Expert Review guidelines . . . . . . . . . . . . . . 46 10.4.1. Specification Required guidance . . . . . . . . . . 46
10.5. Log Artifact Extension Registry . . . . . . . . . . . . 46 10.5. Log Artifact Extension Registry . . . . . . . . . . . . 46
10.5.1. Expert Review guidelines . . . . . . . . . . . . . . 47 10.5.1. Specification Required guidance . . . . . . . . . . 47
10.6. Object Identifiers . . . . . . . . . . . . . . . . . . . 47 10.6. Object Identifiers . . . . . . . . . . . . . . . . . . . 47
10.6.1. Log ID Registry . . . . . . . . . . . . . . . . . . 47 10.6.1. Log ID Registry . . . . . . . . . . . . . . . . . . 47
11. Security Considerations . . . . . . . . . . . . . . . . . . . 48 11. Security Considerations . . . . . . . . . . . . . . . . . . . 48
11.1. Misissued Certificates . . . . . . . . . . . . . . . . . 49 11.1. Misissued Certificates . . . . . . . . . . . . . . . . . 49
11.2. Detection of Misissue . . . . . . . . . . . . . . . . . 49 11.2. Detection of Misissue . . . . . . . . . . . . . . . . . 49
11.3. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 49 11.3. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 49
11.4. Preventing Tracking Clients . . . . . . . . . . . . . . 50 11.4. Preventing Tracking Clients . . . . . . . . . . . . . . 50
11.5. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . 50 11.5. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . 50
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
skipping to change at page 5, line 31 skipping to change at page 5, line 31
the log auditing mechanisms described in this document can be the log auditing mechanisms described in this document can be
circumvented by a misbehaving log that shows different, inconsistent circumvented by a misbehaving log that shows different, inconsistent
views of itself to different clients. Whilst it is anticipated that views of itself to different clients. Whilst it is anticipated that
additional mechanisms could be developed to address these additional mechanisms could be developed to address these
shortcomings and thereby avoid the need to blindly trust logs, such shortcomings and thereby avoid the need to blindly trust logs, such
mechanisms are outside the scope of this document. mechanisms are outside the scope of this document.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Data Structures 1.2. Data Structures
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 experimental CT 1.0 [RFC6962] This document revises and obsoletes the CT 1.0 [RFC6962] protocol,
protocol, drawing on insights gained from CT 1.0 deployments and on drawing on insights gained from CT 1.0 deployments and on feedback
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 o 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 o 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 o Removed precertificate signing certificates and the precertificate
skipping to change at page 7, line 15 skipping to change at page 7, line 20
o Extensive clarifications and editorial work. o 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).
We have established a registry of acceptable hash algorithms (see This document establishes a registry of acceptable hash algorithms
Section 10.2). Throughout this document, the hash algorithm in use (see Section 10.2). Throughout this document, the hash algorithm in
is referred to as HASH and the size of its output in bytes as use is referred to as HASH and the size of its output in bytes as
HASH_SIZE. The input to the Merkle Tree Hash is a list of data HASH_SIZE. The input to the Merkle Tree Hash is a list of data
entries; these entries will be hashed to form the leaves of the entries; these entries will be hashed to form the leaves of the
Merkle Hash Tree. The output is a single HASH_SIZE Merkle Tree Hash. Merkle Hash Tree. The output is a single HASH_SIZE Merkle Tree Hash.
Given an ordered list of n inputs, D_n = {d[0], d[1], ..., d[n-1]}, Given an ordered list of n inputs, D_n = {d[0], d[1], ..., d[n-1]},
the Merkle Tree Hash (MTH) is thus defined as follows: the Merkle Tree Hash (MTH) is thus defined as follows:
The hash of an empty list is the hash of an empty string: The hash of an empty list is the hash of an empty string:
MTH({}) = HASH(). MTH({}) = HASH().
The hash of a list with one entry (also known as a leaf hash) is: The hash of a list with one entry (also known as a leaf hash) is:
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 || is concatenation and D[k1:k2] = D'_(k2-k1) denotes the list where:
{d'[0] = d[k1], d'[1] = d[k1+1], ..., d'[k2-k1-1] = d[k2-1]} of
length (k2 - k1). (Note that the hash calculations for leaves and o || denotes concatenation
nodes differ; this domain separation is required to give second
preimage resistance). o : denotes concatenation of lists
o 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).
Note that the hash calculations for leaves and nodes differ; this
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
trees differently). trees differently).
2.1.2. Verifying a Tree Head Given Entries 2.1.2. Verifying a Tree Head Given Entries
skipping to change at page 16, line 37 skipping to change at page 16, line 49
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 parameters, which are used by A log is defined by a collection of parameters, which are used by
clients to communicate with the log and to verify log artifacts. clients to communicate with the log and to verify log artifacts.
Base URL: The URL to substitute for <log server> in Section 5. Base URL: The URL formed by populating the URL template [RFC6570]
"https://{host}/.well-known/ct/v2/{prefix}", where the "host" and
"prefix" fields are chosen by the log operator. The "host" field
MUST consist of only a domain name and optional port number, and
each log's Base URL MUST NOT be shared by any other log.
Hash Algorithm: The hash algorithm used for the Merkle Tree (see Hash Algorithm: The hash algorithm used for the Merkle Tree (see
Section 10.2). Section 10.2).
Signature Algorithm: The signature algorithm used (see Section 2.2). Signature Algorithm: The signature algorithm used (see Section 2.2).
Public Key: The public key used to verify signatures generated by Public Key: The public key used to verify signatures generated by
the log. A log MUST NOT use the same keypair as any other log. the log. A log MUST NOT use the same keypair as any other log.
Log ID: The OID that uniquely identifies the log. Log ID: The OID that uniquely identifies the log.
skipping to change at page 26, line 20 skipping to change at page 26, line 20
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-
form-urlencoded" format described in the "HTML 4.01 Specification" form-urlencoded" format described in the "HTML 4.01 Specification"
[HTML401]. Binary data is base64 encoded [RFC4648] as specified in [HTML401]. Binary data is base64 encoded [RFC4648] as specified in
the individual messages. the individual messages.
Clients are configured with a base URL for a log and construct URLs Clients are configured with a log's Base URL (see Section 4.1), and
for requests by appending suffixes to this base URL. This structure they construct URLs for requests by appending suffixes to this Base
places some degree of restriction on how log operators can deploy URL, as described in the subsections below.
these services, as noted in [RFC7320]. However, operational
experience with version 1 of this protocol has not indicated that
these restrictions are a problem in practice.
Note that JSON objects and URL parameters may contain fields not Note that JSON objects and URL parameters may contain fields not
specified here. These extra fields SHOULD be ignored. specified here. These extra fields SHOULD be ignored.
The <log server> prefix, which is one of the log's parameters, MAY
include a path as well as a server name and a port.
In practice, log servers may include multiple front-end machines. In practice, log servers may include multiple front-end machines.
Since it is impractical to keep these machines in perfect sync, Since it is impractical to keep these machines in perfect sync,
errors may occur that are caused by skew between the machines. Where errors may occur that are caused by skew between the machines. Where
such errors are possible, the front-end will return additional such errors are possible, the front-end will return additional
information (as specified below) making it possible for clients to information (as specified below) making it possible for clients to
make progress, if progress is possible. Front-ends MUST only serve make progress, if progress is possible. Front-ends MUST only serve
data that is free of gaps (that is, for example, no front-end will data that is free of gaps (that is, for example, no front-end will
respond with an STH unless it is also able to prove consistency from respond with an STH unless it is also able to prove consistency from
all log entries logged within that STH). all log entries logged within that STH).
skipping to change at page 27, line 19 skipping to change at page 27, line 11
type: A URN reference identifying the problem. To facilitate type: A URN reference identifying the problem. To facilitate
automated response to errors, this document defines a set of automated response to errors, this document defines a set of
standard tokens for use in the "type" field, within the URN standard tokens for use in the "type" field, within the URN
namespace of: "urn:ietf:params:trans:error:". namespace of: "urn:ietf:params:trans:error:".
detail: A human-readable string describing the error that prevented detail: A human-readable string describing the error that prevented
the log from processing the request, ideally with sufficient the log from processing the request, ideally with sufficient
detail to enable the error to be rectified. detail to enable the error to be rectified.
e.g., In response to a request of "/ct/v2/get- e.g., In response to a request of "get-entries?start=100&end=99", the
entries?start=100&end=99", the log would return a "400 Bad Request" log would return a "400 Bad Request" response code with a body
response code with a body similar to the following: similar to the following:
{ {
"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
skipping to change at page 27, line 49 skipping to change at page 27, line 41
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 https://<log server>/ct/v2/submit-entry POST https://{host}/.well-known/ct/v2/{prefix}/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 the
type of the "submission": 1 for "x509_entry_v2", or 2 for 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 certificates.
skipping to change at page 30, line 7 skipping to change at page 29, line 29
generate an SCT for a submission if it does not have access to the generate an SCT for a submission if it does not have access to the
issuer's public key. issuer's public key.
If the returned "sct" is intended to be provided to TLS clients, then If the returned "sct" is intended to be provided to TLS clients, then
"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 https://<log server>/ct/v2/get-sth GET https://{host}/.well-known/ct/v2/{prefix}/get-sth
No inputs. No inputs.
Outputs: Outputs:
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, that is no older 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 https://<log server>/ct/v2/get-sth-consistency GET https://{host}/.well-known/ct/v2/{prefix}/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"
skipping to change at page 31, line 22 skipping to change at page 30, line 45
| | is not from an existing STH. | | | is not from an existing STH. |
| | | | | |
| secondBeforeFirst | "second" is smaller than "first". | | secondBeforeFirst | "second" is smaller than "first". |
+-------------------+-----------------------------------------------+ +-------------------+-----------------------------------------------+
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 https://<log server>/ct/v2/get-proof-by-hash GET https://{host}/.well-known/ct/v2/{prefix}/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 proof,
in decimal. 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,
skipping to change at page 32, line 22 skipping to change at page 31, line 48
| treeSizeUnknown | "hash" is before the latest known STH but is | | treeSizeUnknown | "hash" is before the latest known STH but is |
| | not from an existing STH. | | | not from an existing STH. |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
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 https://<log server>/ct/v2/get-all-by-hash GET https://{host}/.well-known/ct/v2/{prefix}/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 proofs,
in decimal. 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.
skipping to change at page 33, line 34 skipping to change at page 33, line 11
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 https://<log server>/ct/v2/get-entries GET https://{host}/.well-known/ct/v2/{prefix}/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. end: 0-based index of last entry to retrieve, in decimal.
Outputs: Outputs:
entries: An array of objects, each consisting of entries: An array of objects, each consisting of
skipping to change at page 35, line 21 skipping to change at page 34, line 46
| type | detail | | type | detail |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| startUnknown | "start" is greater than the number of entries in | | startUnknown | "start" is greater than the number of entries in |
| | the Merkle tree. | | | the Merkle tree. |
| | | | | |
| endBeforeStart | "start" cannot be greater than "end". | | endBeforeStart | "start" cannot be greater than "end". |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
5.7. Retrieve Accepted Trust Anchors 5.7. Retrieve Accepted Trust Anchors
GET https://<log server>/ct/v2/get-anchors GET https://{host}/.well-known/ct/v2/{prefix}/get-anchors
No inputs. No inputs.
Outputs: Outputs:
certificates: An array of base64 encoded trust anchors that are certificates: An array of base64 encoded trust anchors that are
acceptable to the log. 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 length of
chains it accepts, this is the maximum number of certificates chains it accepts, this is the maximum number of certificates
skipping to change at page 44, line 33 skipping to change at page 44, line 5
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 and | | 0xDF | | | Required |
| | | | Expert Review | | | | | |
| | | | | | 0xE0 - | Reserved | | Experimental Use |
| 0xE0 - | Reserved | | Experimental Use | | 0xEF | | | |
| 0xEF | | | | | | | | |
| | | | | | 0xF0 - | Reserved | | Private Use |
| 0xF0 - | Reserved | | Private Use | | 0xFF | | | |
| 0xFF | | | | +---------+------------+------------------------+-------------------+
+--------+------------+------------------------+--------------------+
10.2.1. Expert Review guidelines 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 |
+--------------------------------+--------------------+-------------+ +--------------------------------+-------------------+--------------+
| ecdsa_secp256r1_sha256(0x0403) | ECDSA (NIST P-256) | [FIPS186-4] | | 0x0000 - 0x0402 | Unassigned | Expert |
| | with SHA-256 | | | | | Review |
| | | | | | | |
| ecdsa_secp256r1_sha256(0x0403) | Deterministic | [RFC6979] | | ecdsa_secp256r1_sha256(0x0403) | ECDSA (NIST | [FIPS186-4] |
| | ECDSA (NIST P-256) | | | | P-256) with | |
| | with HMAC-SHA256 | | | | SHA-256 | |
| | | | | | | |
| ed25519(0x0807) | Ed25519 (PureEdDSA | [RFC8032] | | ecdsa_secp256r1_sha256(0x0403) | Deterministic | [RFC6979] |
| | with the | | | | ECDSA (NIST | |
| | edwards25519 | | | | P-256) with HMAC- | |
| | curve) | | | | SHA256 | |
| | | | | | | |
| private_use(0xFE00..0xFFFF) | Reserved | Private Use | | 0x0404 - 0x0806 | Unassigned | Expert |
+--------------------------------+--------------------+-------------+ | | | Review |
| | | |
| ed25519(0x0807) | Ed25519 | [RFC8032] |
| | (PureEdDSA with | |
| | the edwards25519 | |
| | curve) | |
| | | |
| 0x0808 - 0xFDFF | Unassigned | Expert |
| | | Review |
| | | |
| 0xFE00 - 0xFEFF | Reserved | Experimental |
| | | Use |
| | | |
| 0xFF00 - 0xFFFF | Reserved | Private Use |
+--------------------------------+-------------------+--------------+
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 and | | 0x0008 - | Unassigned | Specification Required |
| 0xDFFF | | Expert Review | | 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 (*) 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.]
10.4.1. Expert Review guidelines 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 Policy | | ExtensionType | Status | Use | Reference / Assignment |
+---------------+------------+-----+--------------------------------+ | | | | Policy |
| 0x0000 - | Unassigned | n/a | Specification Required and | +-----------------+------------+-----+------------------------------+
| 0xDFFF | | | Expert Review | | 0x0000 - 0xDFFF | Unassigned | n/a | Specification Required |
| | | | | | | | | |
| 0xE000 - | Reserved | n/a | Experimental Use | | 0xE000 - 0xEFFF | Reserved | n/a | Experimental Use |
| 0xEFFF | | | | | | | | |
| | | | | | 0xF000 - 0xFFFF | Reserved | n/a | Private Use |
| 0xF000 - | Reserved | n/a | Private Use | +-----------------+------------+-----+------------------------------+
| 0xFFFF | | | |
+---------------+------------+-----+--------------------------------+
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 o "SCT", for extensions specified for use in Signed Certificate
Timestamps. Timestamps.
o "STH", for extensions specified for use in Signed Tree Heads. o "STH", for extensions specified for use in Signed Tree Heads.
10.5.1. Expert Review guidelines 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
This document uses object identifiers (OIDs) to identify Log IDs (see This document uses object identifiers (OIDs) to identify Log IDs (see
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:
+---------------------+------------+--------------------------------+ +---------------+------------+------------+------------+------------+
| Value | Log | Reference / Assignment Policy | | Value | Log Base | Contact | Owner | Reference |
+---------------------+------------+--------------------------------+ | | URL | | | / |
| 1.3.101.8192 - | Unassigned | Parameters Required and First | | | | | | Assignment |
| 1.3.101.16383 | | Come First Served | | | | | | Policy |
| | | | +---------------+------------+------------+------------+------------+
| 1.3.101.80.0 - | Unassigned | Parameters Required and First | | 1.3.101.8192 | Unassigned | Unassigned | Unassigned | First Come |
| 1.3.101.80.* | | Come First Served | | - | | | | First |
+---------------------+------------+--------------------------------+ | 1.3.101.16383 | | | | Served |
| | | | | |
| 1.3.101.80.0 | Unassigned | Unassigned | Unassigned | First Come |
| - | | | | First |
| 1.3.101.80.* | | | | Served |
+---------------+------------+------------+------------+------------+
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 should be accompanied Each application for the allocation of a Log ID MUST be accompanied
by all of the required parameters (except for the Log ID) listed in by: * the Log's Base URL (see Section 4.1). * a Contact (including
Section 4.1. contact information), from whom further information can be obtained.
* an Owner (including contact information), who is authorized to
change this Log ID allocation.
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
skipping to change at page 51, line 29 skipping to change at page 51, line 34
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>. <https://www.rfc-editor.org/info/rfc6066>.
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
and D. Orchard, "URI Template", RFC 6570,
DOI 10.17487/RFC6570, March 2012,
<https://www.rfc-editor.org/info/rfc6570>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP", Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013, RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/info/rfc6960>. <https://www.rfc-editor.org/info/rfc6960>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
skipping to change at page 52, line 5 skipping to change at page 52, line 14
[RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP [RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP
APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016,
<https://www.rfc-editor.org/info/rfc7807>. <https://www.rfc-editor.org/info/rfc7807>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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]
skipping to change at page 53, line 19 skipping to change at page 53, line 34
[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,
RFC 7320, DOI 10.17487/RFC7320, July 2014,
<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
[RFC6962]) or v2 (conforming to this document), as the data [RFC6962]) or v2 (conforming to this document), as the data
structures are incompatible and so a v2 log could not issue a valid structures are incompatible and so a v2 log could not issue a valid
 End of changes. 48 change blocks. 
162 lines changed or deleted 191 lines changed or added

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