draft-ietf-trans-rfc6962-bis-28.txt   draft-ietf-trans-rfc6962-bis-29.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: Standards Track E. Messeri Intended status: Experimental E. Messeri
Expires: September 6, 2018 Google Expires: April 25, 2019 Google
R. Stradling R. Stradling
Comodo CA Comodo CA
March 05, 2018 October 22, 2018
Certificate Transparency Version 2.0 Certificate Transparency Version 2.0
draft-ietf-trans-rfc6962-bis-28 draft-ietf-trans-rfc6962-bis-29
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 45 skipping to change at page 1, line 45
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 September 6, 2018. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 52 skipping to change at page 2, line 52
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 . . . . . . . . . . . . . . . . . . . 20 4.7. Merkle Tree Leaves . . . . . . . . . . . . . . . . . . . 20
4.8. Signed Certificate Timestamp (SCT) . . . . . . . . . . . 21 4.8. Signed Certificate Timestamp (SCT) . . . . . . . . . . . 21
4.9. Merkle Tree Head . . . . . . . . . . . . . . . . . . . . 22 4.9. Merkle Tree Head . . . . . . . . . . . . . . . . . . . . 22
4.10. Signed Tree Head (STH) . . . . . . . . . . . . . . . . . 22 4.10. Signed Tree Head (STH) . . . . . . . . . . . . . . . . . 22
4.11. Merkle Consistency Proofs . . . . . . . . . . . . . . . . 23 4.11. Merkle Consistency Proofs . . . . . . . . . . . . . . . . 23
4.12. Merkle Inclusion Proofs . . . . . . . . . . . . . . . . . 24 4.12. Merkle Inclusion Proofs . . . . . . . . . . . . . . . . . 24
4.13. Shutting down a log . . . . . . . . . . . . . . . . . . . 24 4.13. Shutting down a log . . . . . . . . . . . . . . . . . . . 24
5. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 25 5. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 25
5.1. Submit Entry to Log . . . . . . . . . . . . . . . . . . . 26 5.1. Submit Entry to Log . . . . . . . . . . . . . . . . . . . 27
5.2. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 29 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4. Retrieve Merkle Inclusion Proof from Log by Leaf Hash . . 30 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 . . . . . . . . . . . . . 31 Consistency Proof by Leaf Hash . . . . . . . . . . . . . 31
5.6. Retrieve Entries and STH from Log . . . . . . . . . . . . 32 5.6. Retrieve Entries and STH from Log . . . . . . . . . . . . 32
5.7. Retrieve Accepted Trust Anchors . . . . . . . . . . . . . 34 5.7. Retrieve Accepted Trust Anchors . . . . . . . . . . . . . 34
6. TLS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 34 6. TLS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.1. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . . 35 6.1. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . . 35
6.2. TransItemList Structure . . . . . . . . . . . . . . . . . 35 6.2. TransItemList Structure . . . . . . . . . . . . . . . . . 36
6.3. Presenting SCTs, inclusions proofs and STHs . . . . . . . 36 6.3. Presenting SCTs, inclusions proofs and STHs . . . . . . . 36
6.4. transparency_info TLS Extension . . . . . . . . . . . . . 36 6.4. transparency_info TLS Extension . . . . . . . . . . . . . 36
6.5. cached_info TLS Extension . . . . . . . . . . . . . . . . 37 6.5. cached_info TLS Extension . . . . . . . . . . . . . . . . 37
7. Certification Authorities . . . . . . . . . . . . . . . . . . 37 7. Certification Authorities . . . . . . . . . . . . . . . . . . 37
7.1. Transparency Information X.509v3 Extension . . . . . . . 37 7.1. Transparency Information X.509v3 Extension . . . . . . . 37
7.1.1. OCSP Response Extension . . . . . . . . . . . . . . . 37 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 . . . . . . . . . . . . . . 38
8. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 8. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.1. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 38 8.1. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 38
8.1.1. Receiving SCTs and inclusion proofs . . . . . . . . . 38 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 . . . . . . . . . . . . . . . . . . . 39 8.1.3. Validating SCTs . . . . . . . . . . . . . . . . . . . 39
8.1.4. Fetching inclusion proofs . . . . . . . . . . . . . . 39 8.1.4. Fetching inclusion proofs . . . . . . . . . . . . . . 40
8.1.5. Validating inclusion proofs . . . . . . . . . . . . . 40 8.1.5. Validating inclusion proofs . . . . . . . . . . . . . 40
8.1.6. Evaluating compliance . . . . . . . . . . . . . . . . 40 8.1.6. Evaluating compliance . . . . . . . . . . . . . . . . 40
8.1.7. cached_info TLS Extension . . . . . . . . . . . . . . 40 8.1.7. cached_info TLS Extension . . . . . . . . . . . . . . 40
8.2. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 40 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 . . . . . . . . . . . . . . . . . . . . . 43
10.1. New Entry to the TLS ExtensionType Registry . . . . . . 43 10.1. New Entry to the TLS ExtensionType Registry . . . . . . 43
10.2. New Entry to the TLS CachedInformationType registry . . 43 10.2. New Entry to the TLS CachedInformationType registry . . 43
10.3. Hash Algorithms . . . . . . . . . . . . . . . . . . . . 44 10.3. Hash Algorithms . . . . . . . . . . . . . . . . . . . . 44
10.3.1. Expert Review guidelines . . . . . . . . . . . . . . 44 10.3.1. Expert Review guidelines . . . . . . . . . . . . . . 44
10.4. Signature Algorithms . . . . . . . . . . . . . . . . . . 44 10.4. Signature Algorithms . . . . . . . . . . . . . . . . . . 44
10.4.1. Expert Review guidelines . . . . . . . . . . . . . . 45 10.4.1. Expert Review guidelines . . . . . . . . . . . . . . 45
10.5. VersionedTransTypes . . . . . . . . . . . . . . . . . . 45 10.5. VersionedTransTypes . . . . . . . . . . . . . . . . . . 45
skipping to change at page 5, line 37 skipping to change at page 5, line 37
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
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 [I-D.ietf-tls-tls13]. 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 experimental CT 1.0 [RFC6962]
protocol, drawing on insights gained from CT 1.0 deployments and on protocol, drawing on insights gained from CT 1.0 deployments and on
feedback from the community. The major changes are: feedback 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.
skipping to change at page 17, line 27 skipping to change at page 17, line 27
the client should know the final valid STH in the log to ensure no the client should know the final valid STH in the log to ensure no
new entries can be added without detection. The final STH should new entries can be added without detection. The final STH should
be provided in the form of a TransItem of type be provided in the form of a TransItem of type
"signed_tree_head_v2". "signed_tree_head_v2".
[JSON.Metadata] is an example of a metadata format which includes the [JSON.Metadata] is an example of a metadata format which includes the
above elements. above elements.
4.2. Accepting Submissions 4.2. Accepting Submissions
To set clear expectations for what monitors would find in a log, and To ensure that logged certificates and precertificates are
to avoid being overloaded by invalid submissions, the log MUST NOT attributable to a known trust anchor, and to set clear expectations
accept any submission until it has verified that the submitted for what monitors would find in a log, and to avoid being overloaded
certificate or precertificate chains to an accepted trust anchor. by invalid submissions, the log MUST NOT accept any submission until
While there are no security implications to a log accepting a it has verified that the submitted certificate or precertificate
submission that does not chain to one of its accepted trust anchors, chains to an accepted trust anchor.
doing so would put additional burden on monitors that inspect log
entries. Additionally, there are no provisions in the protocol for a
log to indicate that a particular submission was erroneously
accepted.
The log MUST NOT use other sources of intermediate CA certificates to The log MUST NOT use other sources of intermediate CA certificates to
attempt certification path construction; instead, it MUST only use attempt certification path construction; instead, it MUST only use
the intermediate CA certificates provided in the submission, in the the intermediate CA certificates provided in the submission, in the
order provided. order provided.
Logs SHOULD accept certificates and precertificates that are fully Logs SHOULD accept certificates and precertificates that are fully
valid according to RFC 5280 [RFC5280] verification rules and are valid according to RFC 5280 [RFC5280] verification rules and are
submitted with such a chain. (A log may decide, for example, to submitted with such a chain. (A log may decide, for example, to
temporarily reject valid submissions to protect itself against temporarily reject valid submissions to protect itself against
skipping to change at page 20, line 48 skipping to change at page 20, line 46
opaque TBSCertificate<1..2^24-1>; opaque TBSCertificate<1..2^24-1>;
struct { struct {
uint64 timestamp; uint64 timestamp;
opaque issuer_key_hash<32..2^8-1>; opaque issuer_key_hash<32..2^8-1>;
TBSCertificate tbs_certificate; TBSCertificate tbs_certificate;
Extension sct_extensions<0..2^16-1>; Extension sct_extensions<0..2^16-1>;
} TimestampedCertificateEntryDataV2; } TimestampedCertificateEntryDataV2;
"timestamp" is the NTP Time [RFC5905] at which the certificate or "timestamp" is the date and time at which the certificate or
precertificate was accepted by the log, measured in milliseconds precertificate was accepted by the log, in the form of a 64-bit
since the epoch (January 1, 1970, 00:00 UTC), ignoring leap seconds. unsigned number of milliseconds elapsed since the Unix Epoch (1
January 1970 00:00:00 UTC - see [UNIXTIME]), ignoring leap seconds,
Note that the leaves of a log's Merkle Tree are not required to be in in network byte order. Note that the leaves of a log's Merkle Tree
strict chronological order. are not required to be in strict chronological order.
"issuer_key_hash" is the HASH of the public key of the CA that issued "issuer_key_hash" is the HASH of the public key of the CA that issued
the certificate or precertificate, calculated over the DER encoding the certificate or precertificate, calculated over the DER encoding
of the key represented as SubjectPublicKeyInfo [RFC5280]. This is of the key represented as SubjectPublicKeyInfo [RFC5280]. This is
needed to bind the CA to the certificate or precertificate, making it needed to bind the CA to the certificate or precertificate, making it
impossible for the corresponding SCT to be valid for any other impossible for the corresponding SCT to be valid for any other
certificate or precertificate whose TBSCertificate matches certificate or precertificate whose TBSCertificate matches
"tbs_certificate". The length of the "issuer_key_hash" MUST match "tbs_certificate". The length of the "issuer_key_hash" MUST match
HASH_SIZE. HASH_SIZE.
skipping to change at page 22, line 26 skipping to change at page 22, line 23
struct { struct {
uint64 timestamp; uint64 timestamp;
uint64 tree_size; uint64 tree_size;
NodeHash root_hash; NodeHash root_hash;
Extension sth_extensions<0..2^16-1>; Extension sth_extensions<0..2^16-1>;
} TreeHeadDataV2; } TreeHeadDataV2;
The length of NodeHash MUST match HASH_SIZE of the log. The length of NodeHash MUST match HASH_SIZE of the log.
"timestamp" is the current NTP Time [RFC5905], measured in "timestamp" is the current date and time, in the form of a 64-bit
milliseconds since the epoch (January 1, 1970, 00:00 UTC), ignoring unsigned number of milliseconds elapsed since the Unix Epoch (1
leap seconds. January 1970 00:00:00 UTC - see [UNIXTIME]), ignoring leap seconds,
in network byte order.
"tree_size" is the number of entries currently in the log's Merkle "tree_size" is the number of entries currently in the log's Merkle
Tree. Tree.
"root_hash" is the root of the Merkle Hash Tree. "root_hash" is the root of the Merkle Hash Tree.
"sth_extensions" is a vector of 0 or more STH extensions. This "sth_extensions" is a vector of 0 or more STH extensions. This
vector MUST NOT include more than one extension with the same vector MUST NOT include more than one extension with the same
"extension_type". The extensions in the vector MUST be ordered by "extension_type". The extensions in the vector MUST be ordered by
the value of the "extension_type" field, smallest value first. If an the value of the "extension_type" field, smallest value first. If an
skipping to change at page 26, line 10 skipping to change at page 26, line 10
the case where it is unaware of both, it will return the latest STH the case where it is unaware of both, it will return the latest STH
it is aware of. Where it is aware of the first but not the second, it is aware of. Where it is aware of the first but not the second,
it will return the latest STH it is aware of and a consistency proof it will return the latest STH it is aware of and a consistency proof
from the first STH to the returned STH. The case where it knows the from the first STH to the returned STH. The case where it knows the
second but not the first should not arise (see the "no gaps" second but not the first should not arise (see the "no gaps"
requirement above). requirement above).
If the log is unable to process a client's request, it MUST return an If the log is unable to process a client's request, it MUST return an
HTTP response code of 4xx/5xx (see [RFC7231]), and, in place of the HTTP response code of 4xx/5xx (see [RFC7231]), and, in place of the
responses outlined in the subsections below, the body SHOULD be a responses outlined in the subsections below, the body SHOULD be a
JSON structure containing at least the following field: JSON Problem Details Object (see [RFC7807] Section 3), containing:
error_message: A human-readable string describing the error which
prevented the log from processing the request.
In the case of a malformed request, the string SHOULD provide
sufficient detail for the error to be rectified.
error_code: An error code readable by the client. Other than the type: A URN reference identifying the problem. To facilitate
generic codes detailed here, each error code is specific to the automated response to errors, this document defines a set of
type of request. Specific errors are specified in the respective standard tokens for use in the "type" field, within the URN
sections below. Error codes are fixed text strings. namespace of: "urn:ietf:params:trans:error:".
+---------------+---------------------------------------------+ detail: A human-readable string describing the error that prevented
| Error Code | Meaning | the log from processing the request, ideally with sufficient
+---------------+---------------------------------------------+ detail to enable the error to be rectified.
| not compliant | The request is not compliant with this RFC. |
+---------------+---------------------------------------------+
e.g., In response to a request of "/ct/v2/get- e.g., In response to a request of "/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:
{ {
"error_message": "'start' cannot be greater than 'end'", "type": "urn:ietf:params:trans:error:endBeforeStart",
"error_code": "not compliant", "detail": "'start' cannot be greater than 'end'"
} }
Most error types are specific to the type of request and are defined
in the respective subsections below. The one exception is the
"malformed" error type, which indicates that the log server could not
parse the client's request because it did not comply with this
document:
+-----------+----------------------------------+
| type | detail |
+-----------+----------------------------------+
| malformed | The request could not be parsed. |
+-----------+----------------------------------+
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://<log server>/ct/v2/submit-entry
skipping to change at page 28, line 5 skipping to change at page 28, line 5
sth: A base64 encoded "TransItem" of type "signed_tree_head_v2", sth: A base64 encoded "TransItem" of type "signed_tree_head_v2",
signed by this log. signed by this log.
inclusion: A base64 encoded "TransItem" of type inclusion: A base64 encoded "TransItem" of type
"inclusion_proof_v2" whose "inclusion_path" array of Merkle "inclusion_proof_v2" whose "inclusion_path" array of Merkle
Tree nodes proves the inclusion of the "submission" in the Tree nodes proves the inclusion of the "submission" in the
returned "sth". returned "sth".
Error codes: Error codes:
+-------------+-----------------------------------------------------+ +----------------+--------------------------------------------------+
| Error Code | Meaning | | type | detail |
+-------------+-----------------------------------------------------+ +----------------+--------------------------------------------------+
| bad | "submission" is neither a valid certificate nor a | | badSubmission | "submission" is neither a valid certificate nor |
| submission | valid precertificate. | | | a valid precertificate. |
| | | | | |
| bad type | "type" is neither 1 nor 2. | | badType | "type" is neither 1 nor 2. |
| | | | | |
| bad chain | The first element of "chain" is not the certifier | | badChain | The first element of "chain" is not the |
| | of the "submission", or the second element does not | | | certifier of the "submission", or the second |
| | certify the first, etc. | | | element does not certify the first, etc. |
| | | | | |
| bad | One or more certificates in the "chain" are not | | badCertificate | One or more certificates in the "chain" are not |
| certificate | valid (e.g., not properly encoded). | | | valid (e.g., not properly encoded). |
| | | | | |
| unknown | The last element of "chain" (or, if "chain" is an | | unknownAnchor | The last element of "chain" (or, if "chain" is |
| anchor | empty array, the "submission") both is not, and is | | | an empty array, the "submission") both is not, |
| | not certified by, an accepted trust anchor. | | | and is not certified by, an accepted trust |
| | | | | anchor. |
| shutdown | The log is no longer accepting submissions. | | | |
+-------------+-----------------------------------------------------+ | shutdown | The log is no longer accepting submissions. |
+----------------+--------------------------------------------------+
If the version of "sct" is not v2, then a v2 client may be unable to If the version of "sct" is not v2, then a v2 client may be unable to
verify the signature. It MUST NOT construe this as an error. This verify the signature. It MUST NOT construe this as an error. This
is to avoid forcing an upgrade of compliant v2 clients that do not is to avoid forcing an upgrade of compliant v2 clients that do not
use the returned SCTs. use the returned SCTs.
If a log detects bad encoding in a chain that otherwise verifies If a log detects bad encoding in a chain that otherwise verifies
correctly then the log MUST either log the certificate or return the correctly then the log MUST either log the certificate or return the
"bad certificate" error. If the certificate is logged, an SCT MUST "bad certificate" error. If the certificate is logged, an SCT MUST
be issued. Logging the certificate is useful, because monitors be issued. Logging the certificate is useful, because monitors
skipping to change at page 30, line 5 skipping to change at page 30, line 5
sth: A base64 encoded "TransItem" of type "signed_tree_head_v2", sth: A base64 encoded "TransItem" of type "signed_tree_head_v2",
signed by this log. signed by this log.
Note that no signature is required for the "consistency" output as Note that no signature is required for the "consistency" output as
it is used to verify the consistency between two STHs, which are it is used to verify the consistency between two STHs, which are
signed. signed.
Error codes: Error codes:
+-------------+-----------------------------------------------------+ +-------------------+-----------------------------------------------+
| Error Code | Meaning | | type | detail |
+-------------+-----------------------------------------------------+ +-------------------+-----------------------------------------------+
| first | "first" is before the latest known STH but is not | | firstUnknown | "first" is before the latest known STH but is |
| unknown | from an existing STH. | | | not from an existing STH. |
| | | | | |
| second | "second" is before the latest known STH but is not | | secondUnknown | "second" is before the latest known STH but |
| unknown | from an existing STH. | | | is not from an existing STH. |
+-------------+-----------------------------------------------------+ | | |
| 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://<log server>/ct/v2/get-proof-by-hash
Inputs: Inputs:
skipping to change at page 31, line 5 skipping to change at page 31, line 5
sth: A base64 encoded "TransItem" of type "signed_tree_head_v2", sth: A base64 encoded "TransItem" of type "signed_tree_head_v2",
signed by this log. signed by this log.
Note that no signature is required for the "inclusion" output as Note that no signature is required for the "inclusion" output as
it is used to verify inclusion in the selected STH, which is it is used to verify inclusion in the selected STH, which is
signed. signed.
Error codes: Error codes:
+-----------+-------------------------------------------------------+ +-----------------+-------------------------------------------------+
| Error | Meaning | | type | detail |
| Code | | +-----------------+-------------------------------------------------+
+-----------+-------------------------------------------------------+ | hashUnknown | "hash" is not the hash of a known leaf (may be |
| hash | "hash" is not the hash of a known leaf (may be caused | | | caused by skew or by a known certificate not |
| unknown | by skew or by a known certificate not yet merged). | | | yet merged). |
| | | | | |
| tree_size | "hash" is before the latest known STH but is not from | | treeSizeUnknown | "hash" is before the latest known STH but is |
| unknown | 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://<log server>/ct/v2/get-all-by-hash
Inputs: Inputs:
skipping to change at page 34, line 8 skipping to change at page 34, line 8
Because of skew, it is possible the log server will not have any Because of skew, it is possible the log server will not have any
entries between "start" and "end". In this case it MUST return an entries between "start" and "end". In this case it MUST return an
empty "entries" array. empty "entries" array.
In any case, the log server MUST return the latest STH it knows In any case, the log server MUST return the latest STH it knows
about. about.
See Section 2.1.2 for an outline of how to use a complete list of See Section 2.1.2 for an outline of how to use a complete list of
"log_entry" entries to verify the "root_hash". "log_entry" entries to verify the "root_hash".
Error codes:
+----------------+--------------------------------------------------+
| type | detail |
+----------------+--------------------------------------------------+
| startUnknown | "start" is greater than the number of entries in |
| | the Merkle tree. |
| | |
| 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://<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.
skipping to change at page 34, line 34 skipping to change at page 34, line 45
6. TLS Servers 6. TLS Servers
CT-using TLS servers MUST use at least one of the three mechanisms CT-using TLS servers MUST use at least one of the three mechanisms
listed below to present one or more SCTs from one or more logs to listed below to present one or more SCTs from one or more logs to
each TLS client during full TLS handshakes, where each SCT each TLS client during full TLS handshakes, where each SCT
corresponds to the server certificate. They SHOULD also present corresponds to the server certificate. They SHOULD also present
corresponding inclusion proofs and STHs. corresponding inclusion proofs and STHs.
Three mechanisms are provided because they have different tradeoffs. Three mechanisms are provided because they have different tradeoffs.
o A TLS extension (Section 7.4.1.4 of [RFC5246]) with type o A TLS extension (Section 4.2 of [RFC8446]) with type
"transparency_info" (see Section 6.4). This mechanism allows TLS "transparency_info" (see Section 6.4). This mechanism allows TLS
servers to participate in CT without the cooperation of CAs, servers to participate in CT without the cooperation of CAs,
unlike the other two mechanisms. It also allows SCTs and unlike the other two mechanisms. It also allows SCTs and
inclusion proofs to be updated on the fly. inclusion proofs to be updated on the fly.
o An Online Certificate Status Protocol (OCSP) [RFC6960] response o An Online Certificate Status Protocol (OCSP) [RFC6960] response
extension (see Section 7.1.1), where the OCSP response is provided extension (see Section 7.1.1), where the OCSP response is provided
in the "CertificateStatus" message, provided that the TLS client in the "CertificateStatus" message, provided that the TLS client
included the "status_request" extension in the (extended) included the "status_request" extension in the (extended)
"ClientHello" (Section 8 of [RFC6066]). This mechanism, popularly "ClientHello" (Section 8 of [RFC6066]). This mechanism, popularly
skipping to change at page 43, line 38 skipping to change at page 43, line 43
new log and the SCTs from that log used instead. new log and the SCTs from that log used instead.
10. IANA Considerations 10. IANA Considerations
The assignment policy criteria mentioned in this section refer to the The assignment policy criteria mentioned in this section refer to the
policies outlined in [RFC5226]. policies outlined in [RFC5226].
10.1. New Entry to the TLS ExtensionType Registry 10.1. New Entry to the TLS ExtensionType Registry
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 [I-D.ietf-tls-tls13], "TLS ExtensionType Values" registry defined in [RFC8446], setting the
citing this document as the "Reference" and setting the "Recommended" "Recommended" value to "Y", setting the "TLS 1.3" value to "CH, CR,
value to "Yes". CT", and citing this document as the "Reference".
10.2. New Entry to the TLS CachedInformationType registry 10.2. New Entry to the TLS CachedInformationType registry
IANA is asked to add an entry for "ct_compliant(TBD)" to the "TLS IANA is asked to add an entry for "ct_compliant(TBD)" to the "TLS
CachedInformationType Values" registry defined in [RFC7924], citing CachedInformationType Values" registry defined in [RFC7924], citing
this document as the "Reference". this document as the "Reference".
10.3. Hash Algorithms 10.3. 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
skipping to change at page 45, line 30 skipping to change at page 45, line 30
| | curve) | | | | curve) | |
| | | | | | | |
| private_use(0xFE00..0xFFFF) | Reserved | Private Use | | private_use(0xFE00..0xFFFF) | Reserved | Private Use |
+--------------------------------+--------------------+-------------+ +--------------------------------+--------------------+-------------+
10.4.1. Expert Review guidelines 10.4.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
[I-D.ietf-tls-tls13]) and is suitable for use as a cryptographic [RFC8446]) and is suitable for use as a cryptographic signature
signature algorithm. algorithm.
10.5. VersionedTransTypes 10.5. 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 |
+-------------+----------------------+------------------------------+ +-------------+----------------------+------------------------------+
skipping to change at page 51, line 5 skipping to change at page 51, line 5
[FIPS186-4] [FIPS186-4]
NIST, "FIPS PUB 186-4", July 2013, NIST, "FIPS PUB 186-4", July 2013,
<http://nvlpubs.nist.gov/nistpubs/FIPS/ <http://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.186-4.pdf>. NIST.FIPS.186-4.pdf>.
[HTML401] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 [HTML401] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01
Specification", World Wide Web Consortium Recommendation Specification", World Wide Web Consortium Recommendation
REC-html401-19991224, December 1999, REC-html401-19991224, December 1999,
<http://www.w3.org/TR/1999/REC-html401-19991224>. <http://www.w3.org/TR/1999/REC-html401-19991224>.
[I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-26 (work in progress),
March 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[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>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[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, <https://www.rfc- DOI 10.17487/RFC6066, January 2011, <https://www.rfc-
editor.org/info/rfc6066>. editor.org/info/rfc6066>.
[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>.
skipping to change at page 52, line 23 skipping to change at page 52, line 5
[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, <https://www.rfc- DOI 10.17487/RFC7231, June 2014, <https://www.rfc-
editor.org/info/rfc7231>. editor.org/info/rfc7231>.
[RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS) [RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS)
Feature Extension", RFC 7633, DOI 10.17487/RFC7633, Feature Extension", RFC 7633, DOI 10.17487/RFC7633,
October 2015, <https://www.rfc-editor.org/info/rfc7633>. October 2015, <https://www.rfc-editor.org/info/rfc7633>.
[RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP
APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016,
<https://www.rfc-editor.org/info/rfc7807>.
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", RFC 7924, (TLS) Cached Information Extension", RFC 7924,
DOI 10.17487/RFC7924, July 2016, <https://www.rfc- DOI 10.17487/RFC7924, July 2016, <https://www.rfc-
editor.org/info/rfc7924>. editor.org/info/rfc7924>.
[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, <https://www.rfc- DOI 10.17487/RFC8032, January 2017, <https://www.rfc-
editor.org/info/rfc8032>. editor.org/info/rfc8032>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[UNIXTIME]
IEEE, "The Open Group Base Specifications Issue 7 IEEE Std
1003.1-2008, 2016 Edition", n.d., <http://pubs.opengroup.o
rg/onlinepubs/9699919799.2016edition/basedefs/
V1_chap04.html#tag_04_16>.
13.2. Informative References 13.2. Informative References
[Chromium.Log.Policy] [Chromium.Log.Policy]
The Chromium Projects, "Chromium Certificate Transparency The Chromium Projects, "Chromium Certificate Transparency
Log Policy", 2014, <http://www.chromium.org/Home/chromium- Log Policy", 2014, <http://www.chromium.org/Home/chromium-
security/certificate-transparency/log-policy>. security/certificate-transparency/log-policy>.
[Chromium.Policy] [Chromium.Policy]
The Chromium Projects, "Chromium Certificate The Chromium Projects, "Chromium Certificate
Transparency", 2014, <http://www.chromium.org/Home/ Transparency", 2014, <http://www.chromium.org/Home/
skipping to change at page 53, line 12 skipping to change at page 53, line 7
<http://static.usenix.org/event/sec09/tech/full_papers/ <http://static.usenix.org/event/sec09/tech/full_papers/
crosby.pdf>. crosby.pdf>.
[I-D.ietf-trans-gossip] [I-D.ietf-trans-gossip]
Nordberg, L., Gillmor, D., and T. Ritter, "Gossiping in Nordberg, L., Gillmor, D., and T. Ritter, "Gossiping in
CT", draft-ietf-trans-gossip-05 (work in progress), CT", draft-ietf-trans-gossip-05 (work in progress),
January 2018. January 2018.
[I-D.ietf-trans-threat-analysis] [I-D.ietf-trans-threat-analysis]
Kent, S., "Attack and Threat Model for Certificate Kent, S., "Attack and Threat Model for Certificate
Transparency", draft-ietf-trans-threat-analysis-12 (work Transparency", draft-ietf-trans-threat-analysis-16 (work
in progress), October 2017. in progress), October 2018.
[JSON.Metadata] [JSON.Metadata]
The Chromium Projects, "Chromium Log Metadata JSON The Chromium Projects, "Chromium Log Metadata JSON
Schema", 2014, <https://www.gstatic.com/ct/log_list/ Schema", 2014, <https://www.gstatic.com/ct/log_list/
log_list_schema.json>. log_list_schema.json>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, <https://www.rfc- DOI 10.17487/RFC5226, May 2008, <https://www.rfc-
editor.org/info/rfc5226>. editor.org/info/rfc5226>.
skipping to change at page 55, line 7 skipping to change at page 55, line 7
Email: ekasper@google.com Email: ekasper@google.com
Eran Messeri Eran Messeri
Google UK Ltd. Google UK Ltd.
Email: eranm@google.com Email: eranm@google.com
Rob Stradling Rob Stradling
Comodo CA Ltd. Comodo CA Ltd.
Email: rob.stradling@comodoca.com Email: rob@comodoca.com
 End of changes. 32 change blocks. 
111 lines changed or deleted 125 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/