< draft-ietf-trans-rfc6962-bis-36.txt   draft-ietf-trans-rfc6962-bis-37.txt >
skipping to change at page 1, line 13 skipping to change at page 1, line 13
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: 14 November 2021 Google Expires: 14 November 2021 Google
R. Stradling R. Stradling
Sectigo Sectigo
13 May 2021 13 May 2021
Certificate Transparency Version 2.0 Certificate Transparency Version 2.0
draft-ietf-trans-rfc6962-bis-36 draft-ietf-trans-rfc6962-bis-37
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 3, line 39 skipping to change at page 3, line 39
8.1.1. Receiving SCTs and inclusion proofs . . . . . . . . . 42 8.1.1. Receiving SCTs and inclusion proofs . . . . . . . . . 42
8.1.2. Reconstructing the TBSCertificate . . . . . . . . . . 42 8.1.2. Reconstructing the TBSCertificate . . . . . . . . . . 42
8.1.3. Validating SCTs . . . . . . . . . . . . . . . . . . . 42 8.1.3. Validating SCTs . . . . . . . . . . . . . . . . . . . 42
8.1.4. Fetching inclusion proofs . . . . . . . . . . . . . . 43 8.1.4. Fetching inclusion proofs . . . . . . . . . . . . . . 43
8.1.5. Validating inclusion proofs . . . . . . . . . . . . . 43 8.1.5. Validating inclusion proofs . . . . . . . . . . . . . 43
8.1.6. Evaluating compliance . . . . . . . . . . . . . . . . 44 8.1.6. Evaluating compliance . . . . . . . . . . . . . . . . 44
8.2. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 44 8.2. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 44
8.3. Auditing . . . . . . . . . . . . . . . . . . . . . . . . 45 8.3. Auditing . . . . . . . . . . . . . . . . . . . . . . . . 45
9. Algorithm Agility . . . . . . . . . . . . . . . . . . . . . . 46 9. Algorithm Agility . . . . . . . . . . . . . . . . . . . . . . 46
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
10.1. New Entry to the TLS ExtensionType Registry . . . . . . 47 10.1. Additions to existing registries . . . . . . . . . . . . 47
10.2. Hash Algorithms . . . . . . . . . . . . . . . . . . . . 47 10.1.1. New Entry to the TLS ExtensionType Registry . . . . 47
10.2.1. Specification Required guidance . . . . . . . . . . 47 10.1.2. URN Sub-namespace for TRANS errors
10.3. Signature Algorithms . . . . . . . . . . . . . . . . . . 48 (urn:ietf:params:trans:error) . . . . . . . . . . . . 47
10.3.1. Expert Review guidelines . . . . . . . . . . . . . . 49 10.2. New CT-Related registries . . . . . . . . . . . . . . . 47
10.4. VersionedTransTypes . . . . . . . . . . . . . . . . . . 49 10.2.1. Hash Algorithms . . . . . . . . . . . . . . . . . . 47
10.5. Log Artifact Extension Registry . . . . . . . . . . . . 50 10.2.2. Signature Algorithms . . . . . . . . . . . . . . . . 48
10.5.1. Specification Required guidance . . . . . . . . . . 51 10.2.3. VersionedTransTypes . . . . . . . . . . . . . . . . 49
10.6. Object Identifiers . . . . . . . . . . . . . . . . . . . 51 10.2.4. Log Artifact Extension Registry . . . . . . . . . . 50
10.6.1. Log ID Registry . . . . . . . . . . . . . . . . . . 51 10.2.5. Object Identifiers . . . . . . . . . . . . . . . . . 51
10.7. URN Sub-namespace for TRANS errors 10.2.6. CT Error Types Registry . . . . . . . . . . . . . . 52
(urn:ietf:params:trans:error) . . . . . . . . . . . . . 52
10.7.1. TRANS Error Types . . . . . . . . . . . . . . . . . 53
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 . . . . . . . . . . . . . . . . . . . . . . . . . 57 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
13.1. Normative References . . . . . . . . . . . . . . . . . . 57 13.1. Normative References . . . . . . . . . . . . . . . . . . 56
13.2. Informative References . . . . . . . . . . . . . . . . . 59 13.2. Informative References . . . . . . . . . . . . . . . . . 59
Appendix A. Supporting v1 and v2 simultaneously (Informative) . 60 Appendix A. Supporting v1 and v2 simultaneously (Informative) . 60
Appendix B. An ASN.1 Module (Informative) . . . . . . . . . . . 61 Appendix B. An ASN.1 Module (Informative) . . . . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62
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 7, line 30 skipping to change at page 7, line 30
document. Briefly, it is a binary tree where each non-leaf node is a document. Briefly, it is a binary tree where each non-leaf node is a
hash of its children. For CT, the number of children is at most two. hash of its children. For CT, the number of children is at most two.
Additional information can be found in the Introduction and Reference Additional information can be found in the Introduction and Reference
section of [RFC8391]. section of [RFC8391].
2.1.1. Definition of the Merkle Tree 2.1.1. Definition of the Merkle Tree
The log uses a binary Merkle Hash Tree for efficient auditing. The The log uses a binary Merkle Hash Tree for efficient auditing. The
hash algorithm used is one of the log's parameters (see Section 4.1). hash algorithm used is one of the log's parameters (see Section 4.1).
This document establishes a registry of acceptable hash algorithms This document establishes a registry of acceptable hash algorithms
(see Section 10.2). Throughout this document, the hash algorithm in (see Section 10.2.1). Throughout this document, the hash algorithm
use is referred to as HASH and the size of its output in bytes as in use is referred to as HASH and the size of its output in bytes as
HASH_SIZE. The input to the Merkle Tree Hash is a list of data HASH_SIZE. The input to the Merkle Tree Hash is a list of data
entries; these entries will be hashed to form the leaves of the entries; these entries will be hashed to form the leaves of the
Merkle Hash Tree. The output is a single HASH_SIZE Merkle Tree Hash. Merkle Hash Tree. The output is a single HASH_SIZE Merkle Tree Hash.
Given an ordered list of n inputs, D_n = {d[0], d[1], ..., d[n-1]}, Given an ordered list of n inputs, D_n = {d[0], d[1], ..., d[n-1]},
the Merkle Tree Hash (MTH) is thus defined as follows: the Merkle Tree Hash (MTH) is thus defined as follows:
The hash of an empty list is the hash of an empty string: The hash of an empty list is the hash of an empty string:
MTH({}) = HASH(). MTH({}) = HASH().
skipping to change at page 14, line 46 skipping to change at page 14, line 46
hash can be verified using hash1=k and l. hash can be verified using hash1=k and l.
The consistency proof between hash2 and hash is PROOF(6, D[7]) = [i, The consistency proof between hash2 and hash is PROOF(6, D[7]) = [i,
j, k]. k, i are used to verify hash2, and j is additionally used to j, k]. k, i are used to verify hash2, and j is additionally used to
show hash is consistent with hash2. show hash is consistent with hash2.
2.2. Signatures 2.2. Signatures
When signing data structures, a log MUST use one of the signature When signing data structures, a log MUST use one of the signature
algorithms from the IANA CT Signature Algorithms registry, described algorithms from the IANA CT Signature Algorithms registry, described
in Section 10.3. in Section 10.2.2.
3. Submitters 3. Submitters
Submitters submit certificates or preannouncements of certificates Submitters submit certificates or preannouncements of certificates
prior to issuance (precertificates) to logs for public auditing, as prior to issuance (precertificates) to logs for public auditing, as
described below. In order to enable attribution of each logged described below. In order to enable attribution of each logged
certificate or precertificate to its issuer, each submission MUST be certificate or precertificate to its issuer, each submission MUST be
accompanied by all additional certificates required to verify the accompanied by all additional certificates required to verify the
chain up to an accepted trust anchor (Section 5.7). The trust anchor chain up to an accepted trust anchor (Section 5.7). The trust anchor
(a root or intermediate CA certificate) MAY be omitted from the (a root or intermediate CA certificate) MAY be omitted from the
skipping to change at page 16, line 24 skipping to change at page 16, line 24
* "SignedData.crls" MUST be omitted. * "SignedData.crls" MUST be omitted.
* "SignedData.signerInfos" MUST contain one "SignerInfo": * "SignedData.signerInfos" MUST contain one "SignerInfo":
- "version" MUST be v3(3). - "version" MUST be v3(3).
- "sid" MUST use the "subjectKeyIdentifier" option. - "sid" MUST use the "subjectKeyIdentifier" option.
- "digestAlgorithm" MUST be one of the hash algorithm OIDs listed - "digestAlgorithm" MUST be one of the hash algorithm OIDs listed
in the IANA CT Hash Algorithms Registry, described in in the IANA CT Hash Algorithms Registry, described in
Section 10.2. Section 10.2.1.
- "signedAttrs" MUST be present and MUST contain two attributes: - "signedAttrs" MUST be present and MUST contain two attributes:
o A content-type attribute whose value is the same as o A content-type attribute whose value is the same as
"SignedData.encapContentInfo.eContentType". "SignedData.encapContentInfo.eContentType".
o A message-digest attribute whose value is the message digest o 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
skipping to change at page 18, line 39 skipping to change at page 18, line 39
these parameters MUST be established before the log operator begins these parameters MUST be established before the log operator begins
to operate the log. to operate the log.
Base URL: The prefix used to construct URLs ([RFC3986]) for client Base URL: The prefix used to construct URLs ([RFC3986]) for client
messages (see Section 5). The base URL MUST be an "https" URL, 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 MAY contain a port, MAY contain a path with any number of path
segments, but MUST NOT contain a query string, fragment, or segments, but MUST NOT contain a query string, fragment, or
trailing "/". Example: https://ct.example.org/blue 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.1).
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.
Maximum Merge Delay: The MMD the log has committed to. This Maximum Merge Delay: The MMD the log has committed to. This
document deliberately does not specify any limits on the value, to document deliberately does not specify any limits on the value, to
skipping to change at page 21, line 17 skipping to change at page 21, line 17
"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.6.1). The only advantage of the registry is that the DER Section 10.2.5.1). The only advantage of the registry is that the
encoding can be small. (Recall that OID allocations do not require a DER encoding can be small. (Recall that OID allocations do not
central registration, although logs will most likely want to make require a central registration, although logs will most likely want
themselves known to potential clients through out of band means.) to make themselves known to potential clients through out of band
Various data structures include the DER encoding of this OID, means.) Various data structures include the DER encoding of this
excluding the ASN.1 tag and length bytes, in an opaque vector: OID, 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
in size (1 byte) and value, so the full DER encoding (including the in size (1 byte) and value, so the full DER encoding (including the
tag and length) of the OID can be reproduced simply by prepending an tag and length) of the OID can be reproduced simply by prepending an
OBJECT IDENTIFIER tag (0x06) to the opaque vector length and OBJECT IDENTIFIER tag (0x06) to the opaque vector length and
contents. contents.
The OID used to identify a log is limited such that the DER encoding The OID used to identify a log is limited such that the DER encoding
skipping to change at page 22, line 27 skipping to change at page 22, line 27
case x509_entry_v2: TimestampedCertificateEntryDataV2; case x509_entry_v2: TimestampedCertificateEntryDataV2;
case precert_entry_v2: TimestampedCertificateEntryDataV2; case precert_entry_v2: TimestampedCertificateEntryDataV2;
case x509_sct_v2: SignedCertificateTimestampDataV2; case x509_sct_v2: SignedCertificateTimestampDataV2;
case precert_sct_v2: SignedCertificateTimestampDataV2; case precert_sct_v2: SignedCertificateTimestampDataV2;
case signed_tree_head_v2: SignedTreeHeadDataV2; case signed_tree_head_v2: SignedTreeHeadDataV2;
case consistency_proof_v2: ConsistencyProofDataV2; case consistency_proof_v2: ConsistencyProofDataV2;
case inclusion_proof_v2: InclusionProofDataV2; case inclusion_proof_v2: InclusionProofDataV2;
} data; } data;
} TransItem; } TransItem;
"versioned_type" is a value from the IANA registry in Section 10.4 "versioned_type" is a value from the IANA registry in Section 10.2.3
that identifies the type of the encapsulated data structure and the that identifies the type of the encapsulated data structure and the
earliest version of this protocol to which it conforms. This earliest version of this protocol to which it conforms. This
document is v2. document is v2.
"data" is the encapsulated data structure. The various structures "data" is the encapsulated data structure. The various structures
named with the "DataV2" suffix are defined in later sections of this named with the "DataV2" suffix are defined in later sections of this
document. document.
Note that "VersionedTransType" combines the v1 [RFC6962] type Note that "VersionedTransType" combines the v1 [RFC6962] type
enumerations "Version", "LogEntryType", "SignatureType" and enumerations "Version", "LogEntryType", "SignatureType" and
skipping to change at page 23, line 20 skipping to change at page 23, line 20
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 Signed Certificate Timestamps (Section 4.8) and
Signed Tree Heads (Section 4.10). The interpretation of the Signed Tree Heads (Section 4.10). The interpretation of the
"extension_data" field is determined solely by the value of the "extension_data" field is determined solely by 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.5). Each registry for future "ExtensionType" values (see Section 10.2.4).
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
(see Section 4.3). Each leaf is the leaf hash (Section 2.1) of a (see Section 4.3). Each leaf is the leaf hash (Section 2.1) of a
"TransItem" structure of type "x509_entry_v2" or "precert_entry_v2", "TransItem" structure of type "x509_entry_v2" or "precert_entry_v2",
which encapsulates a "TimestampedCertificateEntryDataV2" structure. which encapsulates a "TimestampedCertificateEntryDataV2" structure.
Note that leaf hashes are calculated as HASH(0x00 || TransItem), Note that leaf hashes are calculated as HASH(0x00 || TransItem),
skipping to change at page 28, line 48 skipping to change at page 28, line 48
(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 according to section 4 of [HTML401]. Binary data is base64 encoded according to section 4 of
[RFC4648] as specified in the individual messages. [RFC4648] as specified in the individual messages.
Clients are configured with a log's base URL, which is one of the Clients are configured with a log's base URL, which is one of the
log's parameters. Clients construct URLs for requests by appending log's parameters. Clients construct URLs for requests by appending
suffixes to this base URL. This structure places some degree of suffixes to this base URL. This structure places some degree of
restriction on how log operators can deploy these services, as noted restriction on how log operators can deploy these services, as noted
in [RFC7320]. However, operational experience with version 1 of this in [RFC8820]. However, operational experience with version 1 of this
protocol has not indicated that these restrictions are a problem in protocol has not indicated that these restrictions are a problem in
practice. 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, to allow for experimentation. Any fields that are specified here, to allow for experimentation. Any fields that are
not understood SHOULD be ignored. not understood SHOULD be ignored.
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
skipping to change at page 47, line 16 skipping to change at page 47, line 16
live log, then the log MUST be frozen as specified in Section 4.13 live log, then the log MUST be frozen as specified in Section 4.13
and a new log SHOULD be started. Certificates in the frozen log that and a new log SHOULD be started. Certificates in the frozen log that
have not yet expired and require new SCTs SHOULD be submitted to the have not yet expired and require new SCTs SHOULD be submitted to the
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 [RFC8126]. policies outlined in [RFC8126].
10.1. New Entry to the TLS ExtensionType Registry 10.1. Additions to existing registries
This sub-section defines additions to existing registries.
10.1.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 [RFC8446], setting the "TLS ExtensionType Values" registry defined in [RFC8446], setting the
"Recommended" value to "Y", setting the "TLS 1.3" value to "CH, CR, "Recommended" value to "Y", setting the "TLS 1.3" value to "CH, CR,
CT", and citing this document as the "Reference". CT", and citing this document as the "Reference".
10.2. Hash Algorithms 10.1.2. URN Sub-namespace for TRANS errors
(urn:ietf:params:trans:error)
IANA is requested to add a new entry in the "IETF URN Sub-namespace
for Registered Protocol Parameter Identifiers" registry, following
the template in [RFC3553]:
Registry name: trans:error
Specification: RFCXXXX
Repository: https://www.iana.org/assignments/trans
Index value: No transformation needed.
10.2. New CT-Related registries
This sub-section defines new registries for CT. They should be made
available at https://www.iana.org/assignments/
10.2.1. Hash Algorithms
IANA is asked to establish a registry of hash algorithm values, named IANA is asked to establish a registry of hash algorithm values, named
"CT Hash Algorithms", that initially consists of: "CT Hash Algorithms", that initially consists of:
+========+============+========================+===================+ +========+============+========================+===================+
| Value | Hash | OID | Reference / | | Value | Hash | OID | Reference / |
| | Algorithm | | Assignment Policy | | | Algorithm | | Assignment Policy |
+========+============+========================+===================+ +========+============+========================+===================+
| 0x00 | SHA-256 | 2.16.840.1.101.3.4.2.1 | [RFC6234] | | 0x00 | SHA-256 | 2.16.840.1.101.3.4.2.1 | [RFC6234] |
+--------+------------+------------------------+-------------------+ +--------+------------+------------------------+-------------------+
skipping to change at page 47, line 46 skipping to change at page 48, line 23
+--------+------------+------------------------+-------------------+ +--------+------------+------------------------+-------------------+
| 0xE0 - | Reserved | | Experimental Use | | 0xE0 - | Reserved | | Experimental Use |
| 0xEF | | | | | 0xEF | | | |
+--------+------------+------------------------+-------------------+ +--------+------------+------------------------+-------------------+
| 0xF0 - | Reserved | | Private Use | | 0xF0 - | Reserved | | Private Use |
| 0xFF | | | | | 0xFF | | | |
+--------+------------+------------------------+-------------------+ +--------+------------+------------------------+-------------------+
Table 7 Table 7
10.2.1. Specification Required guidance The Designated Expert(s) should ensure that the proposed algorithm
has a public specification and is suitable for use as a cryptographic
The appointed Expert(s) should ensure that the proposed algorithm has
a public specification and is suitable for use as a cryptographic
hash algorithm with no known preimage or collision attacks. These hash algorithm with no known preimage or collision attacks. These
attacks can damage the integrity of the log. attacks can damage the integrity of the log.
10.3. Signature Algorithms 10.2.2. Signature Algorithms
IANA is asked to establish a registry of signature algorithm values, IANA is asked to establish a registry of signature algorithm values,
named "CT Signature Algorithms" named "CT Signature Algorithms".
The following notes should be added: The following notes should be added:
* This is a subset of the TLS SignatureScheme Registry, limited to * This is a subset of the TLS SignatureScheme Registry, limited to
those algorithms that are appropriate for CT. A major advantage those algorithms that are appropriate for CT. A major advantage
of this is leveraging the expertise of the TLS working group and of this is leveraging the expertise of the TLS working group and
its designated experts. its Designated Expert(s).
* The value "0x0403" appears twice. While this may be confusing, it * The value "0x0403" appears twice. While this may be confusing, it
is okay because the verification process is the same for both is okay because the verification process is the same for both
algorithms, and the choice of which to use when generating a algorithms, and the choice of which to use when generating a
signature is purely internal to the log server. signature is purely internal to the log server.
The registry should initially consist of: The registry should initially consist of:
+================================+==================+==============+ +================================+==================+==============+
| SignatureScheme Value | Signature | Reference / | | SignatureScheme Value | Signature | Reference / |
skipping to change at page 49, line 41 skipping to change at page 49, line 41
| | | Review | | | | Review |
+--------------------------------+------------------+--------------+ +--------------------------------+------------------+--------------+
| 0xFE00 - 0xFEFF | Reserved | Experimental | | 0xFE00 - 0xFEFF | Reserved | Experimental |
| | | Use | | | | Use |
+--------------------------------+------------------+--------------+ +--------------------------------+------------------+--------------+
| 0xFF00 - 0xFFFF | Reserved | Private Use | | 0xFF00 - 0xFFFF | Reserved | Private Use |
+--------------------------------+------------------+--------------+ +--------------------------------+------------------+--------------+
Table 8 Table 8
10.3.1. Expert Review guidelines The Designated Expert(s) should ensure that the proposed algorithm
has a public specification, has a value assigned to it in the TLS
The appointed Expert should ensure that the proposed algorithm has a
public specification, has a value assigned to it in the TLS
SignatureScheme Registry (that IANA is asked to establish in SignatureScheme Registry (that IANA is asked to establish in
[RFC8446]) and is suitable for use as a cryptographic signature [RFC8446]) and is suitable for use as a cryptographic signature
algorithm. algorithm.
10.4. VersionedTransTypes 10.2.3. 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 Policy | | Value | Type and Version | Reference / Assignment Policy |
+==========+======================+===============================+ +==========+======================+===============================+
| 0x0000 | Reserved | [RFC6962] * | | 0x0000 | Reserved | [RFC6962] * |
+----------+----------------------+-------------------------------+ +----------+----------------------+-------------------------------+
| 0x0001 | x509_entry_v2 | RFCXXXX | | 0x0001 | x509_entry_v2 | RFCXXXX |
skipping to change at page 50, line 37 skipping to change at page 50, line 37
| 0xE000 - | Reserved | Experimental Use | | 0xE000 - | Reserved | Experimental Use |
| 0xEFFF | | | | 0xEFFF | | |
+----------+----------------------+-------------------------------+ +----------+----------------------+-------------------------------+
| 0xF000 - | Reserved | Private Use | | 0xF000 - | Reserved | Private Use |
| 0xFFFF | | | | 0xFFFF | | |
+----------+----------------------+-------------------------------+ +----------+----------------------+-------------------------------+
Table 9 Table 9
* The 0x0000 value is reserved so that v1 SCTs are distinguishable * The 0x0000 value is reserved so that v1 SCTs are distinguishable
from v2 SCTs and other "TransItem" structures. ### Specification from v2 SCTs and other "TransItem" structures.
Required guidance
The appointed Expert should review the public specification to ensure The Designated Expert(s) should review the public specification to
that it is detailed enough to ensure implementation interoperability. ensure that it is detailed enough to ensure implementation
interoperability.
10.5. Log Artifact Extension Registry 10.2.4. Log Artifact Extension Registry
IANA is asked to establish a registry of "ExtensionType" values, IANA is asked to establish a registry of "ExtensionType" values,
named "CT Log Artifact Extensions", that initially consists of: named "CT Log Artifact Extensions", that initially consists of:
+===============+============+=====+===============================+ +===============+============+=====+===============================+
| ExtensionType | Status | Use | Reference / Assignment Policy | | ExtensionType | Status | Use | Reference / Assignment Policy |
+===============+============+=====+===============================+ +===============+============+=====+===============================+
| 0x0000 - | Unassigned | n/a | Specification Required | | 0x0000 - | Unassigned | n/a | Specification Required |
| 0xDFFF | | | | | 0xDFFF | | | |
+---------------+------------+-----+-------------------------------+ +---------------+------------+-----+-------------------------------+
skipping to change at page 51, line 27 skipping to change at page 51, line 27
Table 10 Table 10
The "Use" column should contain one or both of the following values: The "Use" column should contain one or both of the following values:
* "SCT", for extensions specified for use in Signed Certificate * "SCT", for extensions specified for use in Signed Certificate
Timestamps. Timestamps.
* "STH", for extensions specified for use in Signed Tree Heads. * "STH", for extensions specified for use in Signed Tree Heads.
10.5.1. Specification Required guidance The Designated Expert(s) should review the public specification to
ensure that it is detailed enough to ensure implementation
The appointed Expert should review the public specification to ensure interoperability. They should also verify that the extension is
that it is detailed enough to ensure implementation interoperability. appropriate to the contexts in which it is specified to be used (SCT,
The Expert should also verify that the extension is appropriate to STH, or both).
the contexts in which it is specified to be used (SCT, STH, or both).
10.6. Object Identifiers 10.2.5. Object Identifiers
This document uses object identifiers (OIDs) to identify Log IDs (see This document uses object identifiers (OIDs) to identify Log IDs (see
Section 4.4), the precertificate CMS "eContentType" (see Section 4.4), the precertificate CMS "eContentType" (see
Section 3.2), and X.509v3 extensions in certificates (see Section 3.2), and X.509v3 extensions in certificates (see
Section 7.1.2) and OCSP responses (see Section 7.1.1). The OIDs are Section 7.1.2) and OCSP responses (see Section 7.1.1). The OIDs are
defined in an arc that was selected due to its short encoding. defined in an arc that was selected due to its short encoding.
10.6.1. Log ID Registry 10.2.5.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:
+================+==============+==============+===================+ +================+==============+==============+===================+
| 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 |
skipping to change at page 52, line 44 skipping to change at page 52, line 44
URL in this registry, because these fields are immutable (see URL in this registry, because these fields are immutable (see
Section 4.1). Section 4.1).
IANA is asked to accept requests from log operators to update their IANA is asked to accept requests from log operators to update their
contact details in this registry. contact details in this registry.
Since log operators can choose to not use this registry (see 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 Section 4.4), it is not expected to be a global directory of all
logs. logs.
10.7. URN Sub-namespace for TRANS errors (urn:ietf:params:trans:error) 10.2.6. CT Error Types Registry
IANA is requested to add a new entry in the "IETF URN Sub-namespace
for Registered Protocol Parameter Identifiers" registry, following
the template in [RFC3553]:
Registry name: trans:error
Specification: RFCXXXX
Repository: https://www.iana.org/assignments/trans
Index value: No transformation needed.
10.7.1. TRANS Error Types IANA is requested to create a new registry for errors, the "CT Error
Types" registry.
IANA is requested to create a new registry for errors. Requirements Requirements for this registry are Specification Required.
for this registry are Specification Required.
This registry should have the following three fields: This registry should have the following three fields:
+============+========+===========+ +============+========+===========+
| Field Name | Type | Reference | | Field Name | Type | Reference |
+============+========+===========+ +============+========+===========+
| identifier | string | RFCXXXX | | identifier | string | RFCXXXX |
+------------+--------+-----------+ +------------+--------+-----------+
| meaning | string | RFCXXXX | | meaning | string | RFCXXXX |
+------------+--------+-----------+ +------------+--------+-----------+
skipping to change at page 60, line 9 skipping to change at page 59, line 49
[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>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<https://www.rfc-editor.org/info/rfc6962>. <https://www.rfc-editor.org/info/rfc6962>.
[RFC7320] Nottingham, M., "URI Design and Ownership", RFC 7320,
DOI 10.17487/RFC7320, July 2014,
<https://www.rfc-editor.org/info/rfc7320>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8820] Nottingham, M., "URI Design and Ownership", BCP 190,
RFC 8820, DOI 10.17487/RFC8820, June 2020,
<https://www.rfc-editor.org/info/rfc8820>.
Appendix A. Supporting v1 and v2 simultaneously (Informative) Appendix A. Supporting v1 and v2 simultaneously (Informative)
Certificate Transparency logs have to be either v1 (conforming to Certificate Transparency logs have to be either v1 (conforming to
[RFC6962]) or v2 (conforming to this document), as the data [RFC6962]) or v2 (conforming to this document), as the data
structures are incompatible and so a v2 log could not issue a valid structures are incompatible and so a v2 log could not issue a valid
v1 SCT. v1 SCT.
CT clients, however, can support v1 and v2 SCTs, for the same CT clients, however, can support v1 and v2 SCTs, for the same
certificate, simultaneously, as v1 SCTs are delivered in different certificate, simultaneously, as v1 SCTs are delivered in different
TLS, X.509 and OCSP extensions than v2 SCTs. TLS, X.509 and OCSP extensions than v2 SCTs.
 End of changes. 31 change blocks. 
79 lines changed or deleted 84 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/