< draft-ietf-trans-rfc6962-bis-39.txt   draft-ietf-trans-rfc6962-bis-40.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: 18 November 2021 Google Expires: 29 January 2022 Google
R. Stradling R. Stradling
Sectigo Sectigo
17 May 2021 28 July 2021
Certificate Transparency Version 2.0 Certificate Transparency Version 2.0
draft-ietf-trans-rfc6962-bis-39 draft-ietf-trans-rfc6962-bis-40
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 2, line 4 skipping to change at page 2, line 4
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 18 November 2021. This Internet-Draft will expire on 29 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 8 skipping to change at page 3, line 8
4.6. Log Artifact Extensions . . . . . . . . . . . . . . . . . 22 4.6. Log Artifact Extensions . . . . . . . . . . . . . . . . . 22
4.7. Merkle Tree Leaves . . . . . . . . . . . . . . . . . . . 23 4.7. Merkle Tree Leaves . . . . . . . . . . . . . . . . . . . 23
4.8. Signed Certificate Timestamp (SCT) . . . . . . . . . . . 24 4.8. Signed Certificate Timestamp (SCT) . . . . . . . . . . . 24
4.9. Merkle Tree Head . . . . . . . . . . . . . . . . . . . . 25 4.9. Merkle Tree Head . . . . . . . . . . . . . . . . . . . . 25
4.10. Signed Tree Head (STH) . . . . . . . . . . . . . . . . . 26 4.10. Signed Tree Head (STH) . . . . . . . . . . . . . . . . . 26
4.11. Merkle Consistency Proofs . . . . . . . . . . . . . . . . 26 4.11. Merkle Consistency Proofs . . . . . . . . . . . . . . . . 26
4.12. Merkle Inclusion Proofs . . . . . . . . . . . . . . . . . 27 4.12. Merkle Inclusion Proofs . . . . . . . . . . . . . . . . . 27
4.13. Shutting down a log . . . . . . . . . . . . . . . . . . . 28 4.13. Shutting down a log . . . . . . . . . . . . . . . . . . . 28
5. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 28 5. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 28
5.1. Submit Entry to Log . . . . . . . . . . . . . . . . . . . 30 5.1. Submit Entry to Log . . . . . . . . . . . . . . . . . . . 30
5.2. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 32 5.2. Retrieve Latest STH . . . . . . . . . . . . . . . . . . . 32
5.3. Retrieve Merkle Consistency Proof between Two Signed Tree 5.3. Retrieve Merkle Consistency Proof between Two STHs . . . 32
Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.4. Retrieve Merkle Inclusion Proof from Log by Leaf Hash . . 33 5.4. Retrieve Merkle Inclusion Proof from Log by Leaf Hash . . 33
5.5. Retrieve Merkle Inclusion Proof, Signed Tree Head and 5.5. Retrieve Merkle Inclusion Proof, STH and Consistency Proof
Consistency Proof by Leaf Hash . . . . . . . . . . . . . 34 by Leaf Hash . . . . . . . . . . . . . . . . . . . . . . 34
5.6. Retrieve Entries and STH from Log . . . . . . . . . . . . 35 5.6. Retrieve Entries and STH from Log . . . . . . . . . . . . 35
5.7. Retrieve Accepted Trust Anchors . . . . . . . . . . . . . 37 5.7. Retrieve Accepted Trust Anchors . . . . . . . . . . . . . 37
6. TLS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 38 6. TLS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.1. TLS Client Authentication . . . . . . . . . . . . . . . . 38 6.1. TLS Client Authentication . . . . . . . . . . . . . . . . 38
6.2. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . . 39 6.2. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . . 39
6.3. TransItemList Structure . . . . . . . . . . . . . . . . . 39 6.3. TransItemList Structure . . . . . . . . . . . . . . . . . 39
6.4. Presenting SCTs, inclusions proofs and STHs . . . . . . . 40 6.4. Presenting SCTs, inclusions proofs and STHs . . . . . . . 40
6.5. transparency_info TLS Extension . . . . . . . . . . . . . 40 6.5. transparency_info TLS Extension . . . . . . . . . . . . . 40
7. Certification Authorities . . . . . . . . . . . . . . . . . . 41 7. Certification Authorities . . . . . . . . . . . . . . . . . . 41
7.1. Transparency Information X.509v3 Extension . . . . . . . 41 7.1. Transparency Information X.509v3 Extension . . . . . . . 41
skipping to change at page 3, line 48 skipping to change at page 3, line 47
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
10.1. Additions to existing registries . . . . . . . . . . . . 47 10.1. Additions to existing registries . . . . . . . . . . . . 47
10.1.1. New Entry to the TLS ExtensionType Registry . . . . 47 10.1.1. New Entry to the TLS ExtensionType Registry . . . . 47
10.1.2. URN Sub-namespace for TRANS errors 10.1.2. URN Sub-namespace for TRANS errors
(urn:ietf:params:trans:error) . . . . . . . . . . . . 47 (urn:ietf:params:trans:error) . . . . . . . . . . . . 47
10.2. New CT-Related registries . . . . . . . . . . . . . . . 47 10.2. New CT-Related registries . . . . . . . . . . . . . . . 47
10.2.1. Hash Algorithms . . . . . . . . . . . . . . . . . . 48 10.2.1. Hash Algorithms . . . . . . . . . . . . . . . . . . 48
10.2.2. Signature Algorithms . . . . . . . . . . . . . . . . 48 10.2.2. Signature Algorithms . . . . . . . . . . . . . . . . 48
10.2.3. VersionedTransTypes . . . . . . . . . . . . . . . . 49 10.2.3. VersionedTransTypes . . . . . . . . . . . . . . . . 49
10.2.4. Log Artifact Extension Registry . . . . . . . . . . 50 10.2.4. Log Artifact Extension Registry . . . . . . . . . . 50
10.2.5. Log ID Registry . . . . . . . . . . . . . . . . . . 51 10.2.5. Log IDs Registry . . . . . . . . . . . . . . . . . . 51
10.2.6. Error Types Registry . . . . . . . . . . . . . . . . 52 10.2.6. Error Types Registry . . . . . . . . . . . . . . . . 52
10.3. OID Assignment . . . . . . . . . . . . . . . . . . . . . 54 10.3. OID Assignment . . . . . . . . . . . . . . . . . . . . . 54
11. Security Considerations . . . . . . . . . . . . . . . . . . . 54 11. Security Considerations . . . . . . . . . . . . . . . . . . . 54
11.1. Misissued Certificates . . . . . . . . . . . . . . . . . 55 11.1. Misissued Certificates . . . . . . . . . . . . . . . . . 55
11.2. Detection of Misissue . . . . . . . . . . . . . . . . . 55 11.2. Detection of Misissue . . . . . . . . . . . . . . . . . 55
11.3. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 55 11.3. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 55
11.4. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . 56 11.4. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . 56
11.5. Leakage of DNS Information . . . . . . . . . . . . . . . 56 11.5. Leakage of DNS Information . . . . . . . . . . . . . . . 56
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
skipping to change at page 4, line 33 skipping to change at page 4, line 32
detect such misissuance. Note that this is a general mechanism that detect such misissuance. Note that this is a general mechanism that
could be used for transparently logging any form of binary data, could be used for transparently logging any form of binary data,
subject to some kind of inclusion criteria. In this document, we subject to some kind of inclusion criteria. In this document, we
only describe its use for public TLS server certificates (i.e., where only describe its use for public TLS server certificates (i.e., where
the inclusion criteria is a valid certificate issued by a public the inclusion criteria is a valid certificate issued by a public
certification authority (CA)). A typical definition of "public" can certification authority (CA)). A typical definition of "public" can
be found in [CABBR]. be found in [CABBR].
Each log contains certificate chains, which can be submitted by Each log contains certificate chains, which can be submitted by
anyone. It is expected that public CAs will contribute all their anyone. It is expected that public CAs will contribute all their
newly issued certificates to one or more logs; however certificate newly issued certificates to one or more logs; however, certificate
holders can also contribute their own certificate chains, as can holders can also contribute their own certificate chains, as can
third parties. In order to avoid logs being rendered useless by the third parties. In order to avoid logs being rendered useless by the
submission of large numbers of spurious certificates, it is required submission of large numbers of spurious certificates, it is required
that each chain ends with a trust anchor that is accepted by the log. that each chain ends with a trust anchor that is accepted by the log.
A log may also limit the length of the chain it is willing to accept; A log may also limit the length of the chain it is willing to accept;
such chains must also end with an acceptable trust anchor. When a such chains must also end with an acceptable trust anchor. When a
chain is accepted by a log, a signed timestamp is returned, which can chain is accepted by a log, a signed timestamp is returned, which can
later be used to provide evidence to TLS clients that the chain has later be used to provide evidence to TLS clients that the chain has
been submitted. TLS clients can thus require that all certificates been submitted. TLS clients can thus require that all certificates
they accept as valid are accompanied by signed timestamps. they accept as valid are accompanied by signed timestamps.
skipping to change at page 21, line 16 skipping to change at page 21, line 16
"sct_extensions" of the corresponding "sct_extensions" of the corresponding
"TimestampedCertificateEntryDataV2" structure. The "TransItem" can "TimestampedCertificateEntryDataV2" structure. The "TransItem" can
be reconstructed from these fields and the entire chain that the log be reconstructed from these fields and the entire chain that the log
used to verify the submission. used to verify the submission.
4.4. Log ID 4.4. Log ID
Each log is identified by an OID, which is one of the log's Each log is identified by an OID, which is one of the log's
parameters (see Section 4.1) and which MUST NOT be used to identify parameters (see Section 4.1) and which MUST NOT be used to identify
any other log. A log's operator MUST either allocate the OID any other log. A log's operator MUST either allocate the OID
themselves or request an OID from the Log ID Registry (see themselves or request an OID from the Log ID registry (see
Section 10.2.5). The only advantage of the registry is that the DER Section 10.2.5). The only advantage of the registry is that the DER
encoding can be small. (Recall that OID allocations do not require a encoding can be small. (Recall that OID allocations do not require a
central registration, although logs will most likely want to make central registration, although logs will most likely want to make
themselves known to potential clients through out of band means.) themselves known to potential clients through out of band means.)
Various data structures include the DER encoding of this OID, Various data structures include the DER encoding of this OID,
excluding the ASN.1 tag and length bytes, in an opaque vector: excluding the ASN.1 tag and length bytes, in an opaque vector:
opaque LogID<2..127>; opaque LogID<2..127>;
Note that the ASN.1 length and the opaque vector length are identical Note that the ASN.1 length and the opaque vector length are identical
skipping to change at page 23, line 14 skipping to change at page 23, line 14
enum { enum {
reserved(65535) reserved(65535)
} ExtensionType; } ExtensionType;
struct { struct {
ExtensionType extension_type; ExtensionType extension_type;
opaque extension_data<0..2^16-1>; opaque extension_data<0..2^16-1>;
} Extension; } Extension;
The "Extension" structure provides a generic extensibility for log The "Extension" structure provides a generic extensibility for log
artifacts, including Signed Certificate Timestamps (Section 4.8) and artifacts, including SCTs (Section 4.8) and STHs (Section 4.10). The
Signed Tree Heads (Section 4.10). The interpretation of the interpretation of the "extension_data" field is determined solely by
"extension_data" field is determined solely by the value of the the value of the "extension_type" field.
"extension_type" field.
This document does not define any extensions, but it does establish a This document does not define any extensions, but it does establish a
registry for future "ExtensionType" values (see Section 10.2.4). registry for future "ExtensionType" values (see Section 10.2.4).
Each document that registers a new "ExtensionType" must specify the Each document that registers a new "ExtensionType" must specify the
context in which it may be used (e.g., SCT, STH, or both) and context in which it may be used (e.g., SCT, STH, or both) and
describe how to interpret the corresponding "extension_data". describe how to interpret the corresponding "extension_data".
4.7. Merkle Tree Leaves 4.7. Merkle Tree Leaves
The leaves of a log's Merkle Tree correspond to the log's entries The leaves of a log's Merkle Tree correspond to the log's entries
skipping to change at page 25, line 27 skipping to change at page 25, line 27
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 date and time, using the format defined in "timestamp" is the current date and time, using the format defined in
{tree_leaves}. Section 4.7.
"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 24 skipping to change at page 26, line 24
unless there are new entries in the log; however, in the event that a unless there are new entries in the log; however, in the event that a
log does not accept any submissions during an MMD period, the log log does not accept any submissions during an MMD period, the log
MUST sign the same Merkle Tree Hash with a fresh timestamp. MUST sign the same Merkle Tree Hash with a fresh timestamp.
An STH is a "TransItem" structure of type "signed_tree_head_v2", An STH is a "TransItem" structure of type "signed_tree_head_v2",
which encapsulates a "SignedTreeHeadDataV2" structure: which encapsulates a "SignedTreeHeadDataV2" structure:
struct { struct {
LogID log_id; LogID log_id;
TreeHeadDataV2 tree_head; TreeHeadDataV2 tree_head;
opaque signature<0..2^16-1>; opaque signature<1..2^16-1>;
} SignedTreeHeadDataV2; } SignedTreeHeadDataV2;
"log_id" is this log's unique ID, encoded in an opaque vector as "log_id" is this log's unique ID, encoded in an opaque vector as
described in Section 4.4. described in Section 4.4.
The "timestamp" in "tree_head" MUST be at least as recent as the most The "timestamp" in "tree_head" MUST be at least as recent as the most
recent SCT timestamp in the tree. Each subsequent timestamp MUST be recent SCT timestamp in the tree. Each subsequent timestamp MUST be
more recent than the timestamp of the previous update. more recent than the timestamp of the previous update.
"tree_head" contains the latest tree head information (see "tree_head" contains the latest tree head information (see
skipping to change at page 27, line 20 skipping to change at page 27, line 20
} ConsistencyProofDataV2; } ConsistencyProofDataV2;
"log_id" is this log's unique ID, encoded in an opaque vector as "log_id" is this log's unique ID, encoded in an opaque vector as
described in Section 4.4. described in Section 4.4.
"tree_size_1" is the size of the older tree. "tree_size_1" is the size of the older tree.
"tree_size_2" is the size of the newer tree. "tree_size_2" is the size of the newer tree.
"consistency_path" is a vector of Merkle Tree nodes proving the "consistency_path" is a vector of Merkle Tree nodes proving the
consistency of two STHs as described in {consistency}. consistency of two STHs as described in Section 2.1.4.
4.12. Merkle Inclusion Proofs 4.12. Merkle Inclusion Proofs
To prepare a Merkle Inclusion Proof for distribution to clients, the To prepare a Merkle Inclusion Proof for distribution to clients, the
log produces a "TransItem" structure of type "inclusion_proof_v2", log produces a "TransItem" structure of type "inclusion_proof_v2",
which encapsulates an "InclusionProofDataV2" structure: which encapsulates an "InclusionProofDataV2" structure:
struct { struct {
LogID log_id; LogID log_id;
uint64 tree_size; uint64 tree_size;
skipping to change at page 27, line 46 skipping to change at page 27, line 46
described in Section 4.4. described in Section 4.4.
"tree_size" is the size of the tree on which this inclusion proof is "tree_size" is the size of the tree on which this inclusion proof is
based. based.
"leaf_index" is the 0-based index of the log entry corresponding to "leaf_index" is the 0-based index of the log entry corresponding to
this inclusion proof. this inclusion proof.
"inclusion_path" is a vector of Merkle Tree nodes proving the "inclusion_path" is a vector of Merkle Tree nodes proving the
inclusion of the chosen certificate or precertificate as described in inclusion of the chosen certificate or precertificate as described in
{merkle_inclusion_proof}. Section 2.1.3.
4.13. Shutting down a log 4.13. Shutting down a log
Log operators may decide to shut down a log for various reasons, such Log operators may decide to shut down a log for various reasons, such
as deprecation of the signature algorithm. If there are entries in as deprecation of the signature algorithm. If there are entries in
the log for certificates that have not yet expired, simply making TLS the log for certificates that have not yet expired, simply making TLS
clients stop recognizing that log will have the effect of clients stop recognizing that log will have the effect of
invalidating SCTs from that log. In order to avoid that, the invalidating SCTs from that log. In order to avoid that, the
following actions SHOULD be taken: following actions SHOULD be taken:
skipping to change at page 30, line 23 skipping to change at page 30, line 23
+===========+==================================+ +===========+==================================+
| malformed | The request could not be parsed. | | malformed | The request could not be parsed. |
+-----------+----------------------------------+ +-----------+----------------------------------+
Table 1 Table 1
Clients SHOULD treat "500 Internal Server Error" and "503 Service Clients SHOULD treat "500 Internal Server Error" and "503 Service
Unavailable" responses as transient failures and MAY retry the same Unavailable" responses as transient failures and MAY retry the same
request without modification at a later date. Note that as per request without modification at a later date. Note that as per
[RFC7231], in the case of a 503 response the log MAY include a [RFC7231], in the case of a 503 response the log MAY include a
"Retry-After:" header in order to request a minimum time for the "Retry-After:" header field in order to request a minimum time for
client to wait before retrying the request. In the absence of this the client to wait before retrying the request. In the absence of
header, this document does not specify a minimum. this header field, this document does not specify a minimum.
Clients SHOULD treat any 4xx error as a problem with the request and Clients SHOULD treat any 4xx error as a problem with the request and
not attempt to resubmit without some modification to the request. not attempt to resubmit without some modification to the request.
The full status code MAY provide additional details. The full status code MAY provide additional details.
This document deliberately does not provide more specific guidance on This document deliberately does not provide more specific guidance on
the use of HTTP status codes. the use of HTTP status codes.
5.1. Submit Entry to Log 5.1. Submit Entry to Log
skipping to change at page 32, line 23 skipping to change at page 32, line 23
neither an accepted trust anchor nor the first element of "chain", neither an accepted trust anchor nor the first element of "chain",
then the log MUST return the "unknown anchor" error. A log is not then the log MUST return the "unknown anchor" error. A log is not
able to generate an SCT for a submission if it does not have access able to generate an SCT for a submission if it does not have access
to the issuer's public key. to the 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. For example, if "type" was 2 (indicating "precert_sct_v2") clients. For example, if "type" was 2 (indicating "precert_sct_v2")
then all three "TransItem"s could be embedded in the certificate. then all three "TransItem"s could be embedded in the certificate.
5.2. Retrieve Latest Signed Tree Head 5.2. Retrieve Latest STH
GET <Base URL>/ct/v2/get-sth GET <Base URL>/ct/v2/get-sth
No inputs. No inputs.
Outputs: sth: A base64 encoded "TransItem" of type Outputs: sth: A base64 encoded "TransItem" of type
"signed_tree_head_v2", signed by this log, that is no older "signed_tree_head_v2", signed by this log, that is no older
than the log's MMD. than the log's MMD.
5.3. Retrieve Merkle Consistency Proof between Two Signed Tree Heads 5.3. Retrieve Merkle Consistency Proof between Two STHs
GET <Base URL>/ct/v2/get-sth-consistency GET <Base URL>/ct/v2/get-sth-consistency
Inputs: first: The tree_size of the older tree, in decimal. Inputs: first: The tree_size of the older tree, in decimal.
second: The tree_size of the newer tree, in decimal second: The tree_size of the newer tree, in decimal
(optional). (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
skipping to change at page 34, line 36 skipping to change at page 34, line 36
| treeSizeUnknown | "hash" is before the latest known | | treeSizeUnknown | "hash" is before the latest known |
| | STH but is not from an existing | | | STH but is not from an existing |
| | STH. | | | STH. |
+-----------------+-------------------------------------+ +-----------------+-------------------------------------+
Table 4 Table 4
See Section 2.1.3.2 for an outline of how to use the "inclusion" See Section 2.1.3.2 for an outline of how to use the "inclusion"
output. output.
5.5. Retrieve Merkle Inclusion Proof, Signed Tree Head and Consistency 5.5. Retrieve Merkle Inclusion Proof, STH and Consistency Proof by Leaf
Proof by Leaf Hash Hash
GET <Base URL>/ct/v2/get-all-by-hash GET <Base URL>/ct/v2/get-all-by-hash
Inputs: hash: A base64 encoded v2 leaf hash. Inputs: hash: A base64 encoded v2 leaf hash.
tree_size: The tree_size of the tree on which to base the tree_size: The tree_size of the tree on which to base the
proofs, in decimal. proofs, in decimal.
The "hash" must be calculated as defined in Section 4.7. A v2 STH The "hash" must be calculated as defined in Section 4.7. A v2 STH
must exist for the "tree_size". must exist for the "tree_size".
skipping to change at page 37, line 42 skipping to change at page 37, line 42
Table 6 Table 6
5.7. Retrieve Accepted Trust Anchors 5.7. Retrieve Accepted Trust Anchors
GET <Base URL>/ct/v2/get-anchors GET <Base URL>/ct/v2/get-anchors
No inputs. No inputs.
Outputs: certificates: An array of JSON strings, each of which is a Outputs: certificates: An array of JSON strings, each of which is a
base64 encoded CA certificate that is acceptable to the log. base64 encoded CA certificate that is acceptable to the log.
max_chain_length:
If the server has chosen to limit the length of chains it max_chain_length: If the server has chosen to limit the
accepts, this is the maximum number of certificates in the length of chains it accepts, this is the maximum number of
chain, in decimal. If there is no limit, this is omitted. certificates in the chain, in decimal. If there is no limit,
this is omitted.
This data is not signed and the protocol depends on the security This data is not signed and the protocol depends on the security
guarantees of TLS to ensure correctness. guarantees of TLS to ensure correctness.
6. TLS Servers 6. TLS Servers
CT-using TLS servers MUST use at least one of the mechanisms CT-using TLS servers MUST use at least one of the mechanisms
described below to present one or more SCTs from one or more logs to described below to present one or more SCTs from one or more logs to
each TLS client during full TLS handshakes, where each SCT each TLS client during full TLS handshakes, when requested by the
corresponds to the server certificate. (Of course, a server can only client, where each SCT corresponds to the server certificate. (Of
send a TLS extension if the client has specified it first.) Servers course, a server can only send a TLS extension if the client has
SHOULD also present corresponding inclusion proofs and STHs. specified it first.) Servers SHOULD also present corresponding
inclusion proofs and STHs.
A server can provide SCTs using a TLS 1.3 extension (Section 4.2 of A server can provide SCTs using a TLS 1.3 extension (Section 4.2 of
[RFC8446]) with type "transparency_info" (see Section 6.5). This [RFC8446]) with type "transparency_info" (see Section 6.5). This
mechanism allows TLS servers to participate in CT without the mechanism allows TLS servers to participate in CT without the
cooperation of CAs, unlike the other two mechanisms. It also allows cooperation of CAs, unlike the other two mechanisms. It also allows
SCTs and inclusion proofs to be updated on the fly. SCTs and inclusion proofs to be updated on the fly.
The server may also use an Online Certificate Status Protocol (OCSP) The server may also use an Online Certificate Status Protocol (OCSP)
[RFC6960] response extension (see Section 7.1.1), providing the OCSP [RFC6960] response extension (see Section 7.1.1), providing the OCSP
response as part of the TLS handshake. Providing a response during a response as part of the TLS handshake. Providing a response during a
TLS handshake is popularly known as "OCSP stapling." For TLS 1.3, TLS handshake is popularly known as "OCSP stapling." For TLS 1.3,
the information is encoded as an extension in the "status_request" the information is encoded as an extension in the "status_request"
extension data; see Section 4.4.2.1 of [RFC8446]. For TLS 1.2 extension data; see Section 4.4.2.1 of [RFC8446]. For TLS 1.2
([RFC5246]), the information is encoded as an extension in the ([RFC5246]), the information is encoded in the "CertificateStatus"
"CertificateStatus" message; see Section 8 of [RFC6066]. Using message; see Section 8 of [RFC6066]. Using stapling also allows SCTs
stapling also allows SCTs and inclusion proofs to be updated on the and inclusion proofs to be updated on the fly.
fly.
CT information can also be encoded as an extension in the X.509v3 CT information can also be encoded as an extension in the X.509v3
certificate (see Section 7.1.2). This mechanism allows the use of certificate (see Section 7.1.2). This mechanism allows the use of
unmodified TLS servers, but the SCTs and inclusion proofs cannot be unmodified TLS servers, but the SCTs and inclusion proofs cannot be
updated on the fly. Since the logs from which the SCTs and inclusion updated on the fly. Since the logs from which the SCTs and inclusion
proofs originated won't necessarily be accepted by TLS clients for proofs originated won't necessarily be accepted by TLS clients for
the full lifetime of the certificate, there is a risk that TLS the full lifetime of the certificate, there is a risk that TLS
clients may subsequently consider the certificate to be non-compliant clients may subsequently consider the certificate to be non-compliant
and in need of re-issuance or the use of one of the other two methods and in need of re-issuance or the use of one of the other two methods
for delivering CT information. for delivering CT information.
skipping to change at page 51, line 33 skipping to change at page 51, line 33
Timestamps. Timestamps.
* "STH", for extensions specified for use in Signed Tree Heads. * "STH", for extensions specified for use in Signed Tree Heads.
The Designated Expert(s) should review the public specification to The Designated Expert(s) should review the public specification to
ensure that it is detailed enough to ensure implementation ensure that it is detailed enough to ensure implementation
interoperability. They should also verify that the extension is interoperability. They should also verify that the extension is
appropriate to the contexts in which it is specified to be used (SCT, appropriate to the contexts in which it is specified to be used (SCT,
STH, or both). STH, or both).
10.2.5. Log ID Registry 10.2.5. Log IDs Registry
IANA is asked to establish a registry of Log IDs, named "Log ID IANA is asked to establish a registry of Log IDs, named "Log IDs",
Registry", that initially consists of: that initially consists of:
+================+==============+==============+===================+ +================+==============+==============+===================+
| Log ID | Log Base URL | Log Operator | Reference / | | Log ID | Log Base URL | Log Operator | Reference / |
| | | | Assignment Policy | | | | | Assignment Policy |
+================+==============+==============+===================+ +================+==============+==============+===================+
| 1.3.101.8192 - | Unassigned | Unassigned | First Come First | | 1.3.101.8192 - | Unassigned | Unassigned | First Come First |
| 1.3.101.16383 | | | Served | | 1.3.101.16383 | | | Served |
+----------------+--------------+--------------+-------------------+ +----------------+--------------+--------------+-------------------+
| 1.3.101.80.0 - | Unassigned | Unassigned | First Come First | | 1.3.101.80.0 - | Unassigned | Unassigned | First Come First |
| 1.3.101.80.* | | | Served | | 1.3.101.80.* | | | Served |
skipping to change at page 55, line 40 skipping to change at page 55, line 40
certificate. certificate.
Violation of the MMD contract is detected by log clients requesting a Violation of the MMD contract is detected by log clients requesting a
Merkle inclusion proof (Section 5.4) for each observed SCT. These Merkle inclusion proof (Section 5.4) for each observed SCT. These
checks can be asynchronous and need only be done once per checks can be asynchronous and need only be done once per
certificate. However, note that there may be privacy concerns (see certificate. However, note that there may be privacy concerns (see
Section 8.1.4). Section 8.1.4).
Violation of the append-only property or the STH issuance rate limit Violation of the append-only property or the STH issuance rate limit
can be detected by multiple clients comparing their instances of the can be detected by multiple clients comparing their instances of the
Signed Tree Heads. This technique, known as "gossip," is an active STHs. This technique, known as "gossip," is an active area of
area of research and not defined here. Proof of misbehavior in such research and not defined here. Proof of misbehavior in such cases
cases would be: a series of STHs that were issued too closely would be: a series of STHs that were issued too closely together,
together, proving violation of the STH issuance rate limit; or an STH proving violation of the STH issuance rate limit; or an STH with a
with a root hash that does not match the one calculated from a copy root hash that does not match the one calculated from a copy of the
of the log, proving violation of the append-only property. log, proving violation of the append-only property.
Clients that report back SCTs can be tracked or traced if a log Clients that report back SCTs can be tracked or traced if a log
produces multiple STHs or SCTs with the same timestamp and data but produces multiple STHs or SCTs with the same timestamp and data but
different signatures. Logs SHOULD mitigate this risk by either: different signatures. Logs SHOULD mitigate this risk by either:
* Using deterministic signature schemes, or * Using deterministic signature schemes, or
* Producing no more than one SCT for each distinct submission and no * Producing no more than one SCT for each distinct submission and no
more than one STH for each distinct tree_size. Each of these SCTs more than one STH for each distinct tree_size. Each of these SCTs
and STHs can be stored by the log and served to other clients that and STHs can be stored by the log and served to other clients that
submit the same certificate or request the same STH. submit the same certificate or request the same STH.
 End of changes. 25 change blocks. 
48 lines changed or deleted 46 lines changed or added

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