draft-ietf-trans-rfc6962-bis-32.txt   draft-ietf-trans-rfc6962-bis-33.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: December 22, 2019 Google Expires: March 21, 2020 Google
R. Stradling R. Stradling
Sectigo Sectigo
June 20, 2019 September 18, 2019
Certificate Transparency Version 2.0 Certificate Transparency Version 2.0
draft-ietf-trans-rfc6962-bis-32 draft-ietf-trans-rfc6962-bis-33
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 December 22, 2019. This Internet-Draft will expire on March 21, 2020.
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 3, line 7 skipping to change at page 3, line 7
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 . . . . . . . . . . . . 29 5.2. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 30
5.3. Retrieve Merkle Consistency Proof between Two Signed Tree 5.3. Retrieve Merkle Consistency Proof between Two Signed Tree
Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.4. Retrieve Merkle Inclusion Proof from Log by Leaf Hash . . 30 5.4. Retrieve Merkle Inclusion Proof from Log by Leaf Hash . . 31
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 . . . . . . . . . . . . . 31 Consistency Proof by Leaf Hash . . . . . . . . . . . . . 32
5.6. Retrieve Entries and STH from Log . . . . . . . . . . . . 33 5.6. Retrieve Entries and STH from Log . . . . . . . . . . . . 33
5.7. Retrieve Accepted Trust Anchors . . . . . . . . . . . . . 34 5.7. Retrieve Accepted Trust Anchors . . . . . . . . . . . . . 35
6. TLS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 35 6. TLS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.1. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . . 35 6.1. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . . 36
6.2. TransItemList Structure . . . . . . . . . . . . . . . . . 36 6.2. TransItemList Structure . . . . . . . . . . . . . . . . . 37
6.3. Presenting SCTs, inclusions proofs and STHs . . . . . . . 36 6.3. Presenting SCTs, inclusions proofs and STHs . . . . . . . 37
6.4. transparency_info TLS Extension . . . . . . . . . . . . . 37 6.4. transparency_info TLS Extension . . . . . . . . . . . . . 37
7. Certification Authorities . . . . . . . . . . . . . . . . . . 37 7. Certification Authorities . . . . . . . . . . . . . . . . . . 38
7.1. Transparency Information X.509v3 Extension . . . . . . . 37 7.1. Transparency Information X.509v3 Extension . . . . . . . 38
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 . . . . . . . . . . . . . . 38 7.2. TLS Feature X.509v3 Extension . . . . . . . . . . . . . . 39
8. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 8. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.1. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 38 8.1. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 39
8.1.1. Receiving SCTs and inclusion proofs . . . . . . . . . 38 8.1.1. Receiving SCTs and inclusion proofs . . . . . . . . . 39
8.1.2. Reconstructing the TBSCertificate . . . . . . . . . . 39 8.1.2. Reconstructing the TBSCertificate . . . . . . . . . . 39
8.1.3. Validating SCTs . . . . . . . . . . . . . . . . . . . 39 8.1.3. Validating SCTs . . . . . . . . . . . . . . . . . . . 40
8.1.4. Fetching inclusion proofs . . . . . . . . . . . . . . 40 8.1.4. Fetching inclusion proofs . . . . . . . . . . . . . . 40
8.1.5. Validating inclusion proofs . . . . . . . . . . . . . 40 8.1.5. Validating inclusion proofs . . . . . . . . . . . . . 41
8.1.6. Evaluating compliance . . . . . . . . . . . . . . . . 40 8.1.6. Evaluating compliance . . . . . . . . . . . . . . . . 41
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 . . . . . . . . . . . . . . . . . . . . . 43 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
10.1. New Entry to the TLS ExtensionType Registry . . . . . . 43 10.1. New Entry to the TLS ExtensionType Registry . . . . . . 44
10.2. Hash Algorithms . . . . . . . . . . . . . . . . . . . . 43 10.2. Hash Algorithms . . . . . . . . . . . . . . . . . . . . 44
10.2.1. Specification Required guidance . . . . . . . . . . 44 10.2.1. Specification Required guidance . . . . . . . . . . 45
10.3. Signature Algorithms . . . . . . . . . . . . . . . . . . 44 10.3. Signature Algorithms . . . . . . . . . . . . . . . . . . 45
10.3.1. Expert Review guidelines . . . . . . . . . . . . . . 45 10.3.1. Expert Review guidelines . . . . . . . . . . . . . . 46
10.4. VersionedTransTypes . . . . . . . . . . . . . . . . . . 45 10.4. VersionedTransTypes . . . . . . . . . . . . . . . . . . 46
10.4.1. Specification Required guidance . . . . . . . . . . 46 10.4.1. Specification Required guidance . . . . . . . . . . 47
10.5. Log Artifact Extension Registry . . . . . . . . . . . . 46 10.5. Log Artifact Extension Registry . . . . . . . . . . . . 47
10.5.1. Specification Required guidance . . . . . . . . . . 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
skipping to change at page 16, line 49 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 formed by populating the URL template [RFC6570] Base URL: The URL to substitute for <log server> in Section 5.
"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 log's Base URL (see Section 4.1), and Clients are configured with a base URL for a log and construct URLs
they construct URLs for requests by appending suffixes to this Base for requests by appending suffixes to this base URL. This structure
URL, as described in the subsections below. places some degree of restriction on how log operators can deploy
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 11 skipping to change at page 27, line 19
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 "get-entries?start=100&end=99", the e.g., In response to a request of "/ct/v2/get-
log would return a "400 Bad Request" response code with a body entries?start=100&end=99", the log would return a "400 Bad Request"
similar to the following: response code with a body 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 41 skipping to change at page 27, line 49
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://{host}/.well-known/ct/v2/{prefix}/submit-entry POST https://<log server>/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 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 29, line 29 skipping to change at page 30, line 7
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://{host}/.well-known/ct/v2/{prefix}/get-sth GET https://<log server>/ct/v2/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://{host}/.well-known/ct/v2/{prefix}/get-sth-consistency GET https://<log server>/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"
skipping to change at page 30, line 45 skipping to change at page 31, line 22
| | 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://{host}/.well-known/ct/v2/{prefix}/get-proof-by-hash GET https://<log server>/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 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 31, line 48 skipping to change at page 32, line 22
| 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://{host}/.well-known/ct/v2/{prefix}/get-all-by-hash GET https://<log server>/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 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 11 skipping to change at page 33, line 34
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://{host}/.well-known/ct/v2/{prefix}/get-entries GET https://<log server>/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. 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 34, line 46 skipping to change at page 35, line 21
| 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://{host}/.well-known/ct/v2/{prefix}/get-anchors GET https://<log server>/ct/v2/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 51, line 34 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 53, line 34 skipping to change at page 53, line 29
[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. 27 change blocks. 
53 lines changed or deleted 54 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/