draft-ietf-trans-rfc6962-bis-33.txt   draft-ietf-trans-rfc6962-bis-34.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: March 21, 2020 Google Expires: May 7, 2020 Google
R. Stradling R. Stradling
Sectigo Sectigo
September 18, 2019 November 04, 2019
Certificate Transparency Version 2.0 Certificate Transparency Version 2.0
draft-ietf-trans-rfc6962-bis-33 draft-ietf-trans-rfc6962-bis-34
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 March 21, 2020. This Internet-Draft will expire on May 7, 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 2, line 37 skipping to change at page 2, line 37
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 . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1. Certificates . . . . . . . . . . . . . . . . . . . . . . 14 3.1. Certificates . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Precertificates . . . . . . . . . . . . . . . . . . . . . 14 3.2. Precertificates . . . . . . . . . . . . . . . . . . . . . 14
3.2.1. Binding Intent to Issue . . . . . . . . . . . . . . . 16
4. Log Format and Operation . . . . . . . . . . . . . . . . . . 16 4. Log Format and Operation . . . . . . . . . . . . . . . . . . 16
4.1. Log Parameters . . . . . . . . . . . . . . . . . . . . . 16 4.1. Log Parameters . . . . . . . . . . . . . . . . . . . . . 17
4.2. Evaluating Submissions . . . . . . . . . . . . . . . . . 17 4.2. Evaluating Submissions . . . . . . . . . . . . . . . . . 18
4.2.1. Minimum Acceptance Criteria . . . . . . . . . . . . . 18 4.2.1. Minimum Acceptance Criteria . . . . . . . . . . . . . 18
4.2.2. Discretionary Acceptance Criteria . . . . . . . . . . 18 4.2.2. Discretionary Acceptance Criteria . . . . . . . . . . 19
4.3. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 19 4.3. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 19
4.4. Log ID . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.4. Log ID . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.5. TransItem Structure . . . . . . . . . . . . . . . . . . . 19 4.5. TransItem Structure . . . . . . . . . . . . . . . . . . . 20
4.6. Log Artifact Extensions . . . . . . . . . . . . . . . . . 20 4.6. Log Artifact Extensions . . . . . . . . . . . . . . . . . 21
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) . . . . . . . . . . . . . . . . . 24
4.11. Merkle Consistency Proofs . . . . . . . . . . . . . . . . 24 4.11. Merkle Consistency Proofs . . . . . . . . . . . . . . . . 25
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 . . . . . . . . . . . . . . . . . . . 26
5. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 26 5. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 26
5.1. Submit Entry to Log . . . . . . . . . . . . . . . . . . . 27 5.1. Submit Entry to Log . . . . . . . . . . . . . . . . . . . 28
5.2. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 30 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.4. Retrieve Merkle Inclusion Proof from Log by Leaf Hash . . 31 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 . . . . . . . . . . . . . 32 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 . . . . . . . . . . . . . 35 5.7. Retrieve Accepted Trust Anchors . . . . . . . . . . . . . 35
6. TLS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 35 6. TLS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.1. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . . 36 6.1. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . . 36
skipping to change at page 4, line 5 skipping to change at page 4, line 6
10.5. Log Artifact Extension Registry . . . . . . . . . . . . 47 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
11.6. Leakage of DNS Information . . . . . . . . . . . . . . . 50
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
13.1. Normative References . . . . . . . . . . . . . . . . . . 50 13.1. Normative References . . . . . . . . . . . . . . . . . . 51
13.2. Informative References . . . . . . . . . . . . . . . . . 52 13.2. Informative References . . . . . . . . . . . . . . . . . 52
Appendix A. Supporting v1 and v2 simultaneously . . . . . . . . 53 Appendix A. Supporting v1 and v2 simultaneously . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
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,
skipping to change at page 15, line 42 skipping to change at page 15, line 42
+ A content-type attribute whose value is the same as + 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 + 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 will ultimately issue the certificate. This signature that intends to issue the corresponding certificate (see
indicates the CA's intent to issue the certificate. This Section 3.2.1).
intent is considered binding (i.e., misissuance of the
precertificate is considered equivalent to misissuance of the
corresponding certificate).
* "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
Under normal circumstances, there will be a short delay between
precertificate submission and issuance of the corresponding
certificate. Longer delays are to be expected occasionally (e.g.,
due to log server downtime), and in some cases the CA might not
actually issue the corresponding certificate. Nevertheless, a
precertificate's "signature" indicates the CA's binding intent to
issue the corresponding certificate, which means that:
o Misissuance of a precertificate is considered equivalent to
misissuance of the corresponding certificate. The CA should
expect to be held to account, even if the corresponding
certificate has not actually been issued.
o Upon observing a precertificate, a client can reasonably presume
that the corresponding certificate has been issued. A client may
wish to obtain status information (e.g., by using the Online
Certificate Status Protocol [RFC6960] or by checking a Certificate
Revocation List [RFC5280]) about a certificate that is presumed to
exist, especially if there is evidence or suspicion that the
corresponding precertificate was misissued.
o TLS clients may have policies that require CAs to be able to
revoke, and to provide certificate status services for, each
certificate that is presumed to exist based on the existence of a
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
an SCT that corresponds to the submitted certificate or an SCT that corresponds to the submitted certificate or
precertificate. If the log has previously seen this valid precertificate. If the log has previously seen this valid
submission, it SHOULD return the same SCT as it returned before (to submission, it SHOULD return the same SCT as it returned before (to
reduce the ability to track clients as described in Section 11.4). reduce the ability to track clients as described in Section 11.4).
skipping to change at page 16, line 46 skipping to change at page 17, line 22
o Sign the root of the tree (see Section 4.10). o 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 parameters, which are used by A log is defined by a collection of immutable parameters, which are
clients to communicate with the log and to verify log artifacts. used by clients to communicate with the log and to verify log
artifacts. Except for the Final Signed Tree Head (STH), each of
these parameters MUST be established before the log operator begins
to operate the log.
Base URL: The URL to substitute for <log server> in Section 5. Base URL: The prefix used to construct URLs for client messages (see
Section 5). The base URL MUST be an "https" URL, MAY contain a
port, MAY contain a path with any number of path segments, but
MUST NOT contain a query string, fragment, or trailing "/".
Example: https://ct.example.org/blue
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 42
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, which is one of the
for requests by appending suffixes to this base URL. This structure log's parameters. Clients construct URLs for requests by appending
places some degree of restriction on how log operators can deploy suffixes to this base URL. This structure places some degree of
these services, as noted in [RFC7320]. However, operational restriction on how log operators can deploy these services, as noted
experience with version 1 of this protocol has not indicated that in [RFC7320]. However, operational experience with version 1 of this
these restrictions are a problem in practice. 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 38
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 "<Base URL>/ct/v2/get-
entries?start=100&end=99", the log would return a "400 Bad Request" entries?start=100&end=99", the log would return a "400 Bad Request"
response code with a body 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
skipping to change at page 27, line 49 skipping to change at page 28, line 20
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 <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 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 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://<log server>/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", 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 <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"
skipping to change at page 31, line 22 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://<log server>/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 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 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://<log server>/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 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 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://<log server>/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. 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 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://<log server>/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 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 48, line 5 skipping to change at page 48, 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:
+---------------+------------+------------+------------+------------+ +---------------------+------------+------------+-------------------+
| Value | Log Base | Contact | Owner | Reference | | Log ID | Log Base | Log | Reference / |
| | URL | | | / | | | URL | Operator | Assignment Policy |
| | | | | Assignment | +---------------------+------------+------------+-------------------+
| | | | | Policy | | 1.3.101.8192 - | Unassigned | Unassigned | First Come First |
+---------------+------------+------------+------------+------------+ | 1.3.101.16383 | | | Served |
| 1.3.101.8192 | Unassigned | Unassigned | Unassigned | First Come | | | | | |
| - | | | | First | | 1.3.101.80.0 - | Unassigned | Unassigned | First Come First |
| 1.3.101.16383 | | | | Served | | 1.3.101.80.* | | | 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 MUST be accompanied Each application for the allocation of a Log ID MUST be accompanied
by: * the Log's Base URL (see Section 4.1). * a Contact (including by:
contact information), from whom further information can be obtained.
* an Owner (including contact information), who is authorized to o the Log's Base URL (see Section 4.1).
change this Log ID allocation.
o the Log Operator's contact details.
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
Section 4.1).
IANA is asked to accept requests from log operators to update their
contact details in this registry.
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
logs.
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 50, line 27 skipping to change at page 50, line 34
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.1).
11.6. Leakage of DNS Information
Malicious monitors can use logs to learn about the existence of
domain names that might not otherwise be easy to discover. Some
subdomain labels may reveal information about the service and
software for which the subdomain is used, which in turn might
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, Melinda Shore, Ryan
Sleevi, Martin Smith, Carl Wallace and Paul Wouters for their Sleevi, Martin Smith, Carl Wallace and Paul Wouters for their
valuable contributions. valuable contributions.
 End of changes. 31 change blocks. 
61 lines changed or deleted 108 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/