draft-ietf-trans-rfc6962-bis-37.txt   draft-ietf-trans-rfc6962-bis-38.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: 14 November 2021 Google Expires: 15 November 2021 Google
R. Stradling R. Stradling
Sectigo Sectigo
13 May 2021 14 May 2021
Certificate Transparency Version 2.0 Certificate Transparency Version 2.0
draft-ietf-trans-rfc6962-bis-37 draft-ietf-trans-rfc6962-bis-38
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 14 November 2021. This Internet-Draft will expire on 15 November 2021.
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
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 5 1.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 5
1.3. Major Differences from CT 1.0 . . . . . . . . . . . . . . 5 1.3. Major Differences from CT 1.0 . . . . . . . . . . . . . . 6
2. Cryptographic Components . . . . . . . . . . . . . . . . . . 7 2. Cryptographic Components . . . . . . . . . . . . . . . . . . 7
2.1. Merkle Hash Trees . . . . . . . . . . . . . . . . . . . . 7 2.1. Merkle Hash Trees . . . . . . . . . . . . . . . . . . . . 7
2.1.1. Definition of the Merkle Tree . . . . . . . . . . . . 7 2.1.1. Definition of the Merkle Tree . . . . . . . . . . . . 7
2.1.2. Verifying a Tree Head Given Entries . . . . . . . . . 8 2.1.2. Verifying a Tree Head Given Entries . . . . . . . . . 8
2.1.3. Merkle Inclusion Proofs . . . . . . . . . . . . . . . 9 2.1.3. Merkle Inclusion Proofs . . . . . . . . . . . . . . . 9
2.1.4. Merkle Consistency Proofs . . . . . . . . . . . . . . 10 2.1.4. Merkle Consistency Proofs . . . . . . . . . . . . . . 11
2.1.5. Example . . . . . . . . . . . . . . . . . . . . . . . 13 2.1.5. Example . . . . . . . . . . . . . . . . . . . . . . . 13
2.2. Signatures . . . . . . . . . . . . . . . . . . . . . . . 14 2.2. Signatures . . . . . . . . . . . . . . . . . . . . . . . 14
3. Submitters . . . . . . . . . . . . . . . . . . . . . . . . . 15 3. Submitters . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Certificates . . . . . . . . . . . . . . . . . . . . . . 15 3.1. Certificates . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Precertificates . . . . . . . . . . . . . . . . . . . . . 15 3.2. Precertificates . . . . . . . . . . . . . . . . . . . . . 15
3.2.1. Binding Intent to Issue . . . . . . . . . . . . . . . 17 3.2.1. Binding Intent to Issue . . . . . . . . . . . . . . . 17
4. Log Format and Operation . . . . . . . . . . . . . . . . . . 17 4. Log Format and Operation . . . . . . . . . . . . . . . . . . 17
4.1. Log Parameters . . . . . . . . . . . . . . . . . . . . . 18 4.1. Log Parameters . . . . . . . . . . . . . . . . . . . . . 18
4.2. Evaluating Submissions . . . . . . . . . . . . . . . . . 19 4.2. Evaluating Submissions . . . . . . . . . . . . . . . . . 19
4.2.1. Minimum Acceptance Criteria . . . . . . . . . . . . . 19 4.2.1. Minimum Acceptance Criteria . . . . . . . . . . . . . 19
skipping to change at page 3, line 44 skipping to change at page 3, line 44
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. 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 . . . . . . . . . . . . . . . . . . 47 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. Object Identifiers . . . . . . . . . . . . . . . . . 51 10.2.5. Log ID Registry . . . . . . . . . . . . . . . . . . 51
10.2.6. CT Error Types Registry . . . . . . . . . . . . . . 52 10.2.6. Error Types Registry . . . . . . . . . . . . . . . . 52
11. Security Considerations . . . . . . . . . . . . . . . . . . . 54 11. Security Considerations . . . . . . . . . . . . . . . . . . . 54
11.1. Misissued Certificates . . . . . . . . . . . . . . . . . 55 11.1. Misissued Certificates . . . . . . . . . . . . . . . . . 54
11.2. Detection of Misissue . . . . . . . . . . . . . . . . . 55 11.2. Detection of Misissue . . . . . . . . . . . . . . . . . 54
11.3. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 55 11.3. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 55
11.4. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . 56 11.4. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . 55
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
13.1. Normative References . . . . . . . . . . . . . . . . . . 56 13.1. Normative References . . . . . . . . . . . . . . . . . . 56
13.2. Informative References . . . . . . . . . . . . . . . . . 59 13.2. Informative References . . . . . . . . . . . . . . . . . 58
Appendix A. Supporting v1 and v2 simultaneously (Informative) . 60 Appendix A. Supporting v1 and v2 simultaneously (Informative) . 59
Appendix B. An ASN.1 Module (Informative) . . . . . . . . . . . 60 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
skipping to change at page 5, line 45 skipping to change at page 5, line 45
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
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 [RFC8446]. laid out in Section 3 of [RFC8446].
This document uses object identifiers (OIDs) to identify Log IDs (see
Section 4.4), the precertificate CMS "eContentType" (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
defined in an arc that was selected due to its short encoding.
1.3. Major Differences from CT 1.0 1.3. Major Differences from CT 1.0
This document revises and obsoletes the CT 1.0 [RFC6962] protocol, This document revises and obsoletes the CT 1.0 [RFC6962] protocol,
drawing on insights gained from CT 1.0 deployments and on feedback drawing on insights gained from CT 1.0 deployments and on feedback
from the community. The major changes are: from the community. The major changes are:
* Hash and signature algorithm agility: permitted algorithms are now * Hash and signature algorithm agility: permitted algorithms are now
specified in IANA registries. specified in IANA registries.
* Precertificate format: precertificates are now CMS objects rather * Precertificate format: precertificates are now CMS objects rather
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.2.5.1). The only advantage of the registry is that the Section 10.2.5). The only advantage of the registry is that the DER
DER encoding can be small. (Recall that OID allocations do not encoding can be small. (Recall that OID allocations do not require a
require a central registration, although logs will most likely want central registration, although logs will most likely want to make
to make themselves known to potential clients through out of band themselves known to potential clients through out of band means.)
means.) Various data structures include the DER encoding of this Various data structures include the DER encoding of this OID,
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
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 47, line 44 skipping to change at page 47, line 44
Registry name: trans:error Registry name: trans:error
Specification: RFCXXXX Specification: RFCXXXX
Repository: https://www.iana.org/assignments/trans Repository: https://www.iana.org/assignments/trans
Index value: No transformation needed. Index value: No transformation needed.
10.2. New CT-Related registries 10.2. New CT-Related registries
This sub-section defines new registries for CT. They should be made IANA is requested to add a new protocol registry, "Public Notary
available at https://www.iana.org/assignments/ Transparency", to the list that appears at https://www.iana.org/
assignments/
The rest of this section defines sub-registries to be created within
the new Public Notary Transparency registry.
10.2.1. Hash Algorithms 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: "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] |
+--------+------------+------------------------+-------------------+ +--------+------------+------------------------+-------------------+
| 0x01 - | Unassigned | | Specification | | 0x01 - | Unassigned | | Specification |
| 0xDF | | | Required | | 0xDF | | | Required |
+--------+------------+------------------------+-------------------+ +--------+------------+------------------------+-------------------+
skipping to change at page 48, line 31 skipping to change at page 48, line 36
Table 7 Table 7
The Designated Expert(s) should ensure that the proposed algorithm The Designated Expert(s) should ensure that the proposed algorithm
has a public specification and is suitable for use as a cryptographic 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.2.2. 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 "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 Expert(s). 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
skipping to change at page 49, line 43 skipping to change at page 49, line 43
| 0xFE00 - 0xFEFF | Reserved | Experimental | | 0xFE00 - 0xFEFF | Reserved | Experimental |
| | | Use | | | | Use |
+--------------------------------+------------------+--------------+ +--------------------------------+------------------+--------------+
| 0xFF00 - 0xFFFF | Reserved | Private Use | | 0xFF00 - 0xFFFF | Reserved | Private Use |
+--------------------------------+------------------+--------------+ +--------------------------------+------------------+--------------+
Table 8 Table 8
The Designated Expert(s) should ensure that the proposed algorithm The Designated Expert(s) should ensure that the proposed algorithm
has a public specification, has a value assigned to it in the TLS 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 was 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.2.3. 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 "VersionedTransTypes".
The following note should be added:
* The 0x0000 value is reserved so that v1 SCTs are distinguishable
from v2 SCTs and other "TransItem" structures.
The registry should initially consist 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 |
+----------+----------------------+-------------------------------+ +----------+----------------------+-------------------------------+
| 0x0002 | precert_entry_v2 | RFCXXXX | | 0x0002 | precert_entry_v2 | RFCXXXX |
+----------+----------------------+-------------------------------+ +----------+----------------------+-------------------------------+
| 0x0003 | x509_sct_v2 | RFCXXXX | | 0x0003 | x509_sct_v2 | RFCXXXX |
+----------+----------------------+-------------------------------+ +----------+----------------------+-------------------------------+
| 0x0004 | precert_sct_v2 | RFCXXXX | | 0x0004 | precert_sct_v2 | RFCXXXX |
+----------+----------------------+-------------------------------+ +----------+----------------------+-------------------------------+
| 0x0005 | signed_tree_head_v2 | RFCXXXX | | 0x0005 | signed_tree_head_v2 | RFCXXXX |
skipping to change at page 50, line 36 skipping to change at page 50, line 41
+----------+----------------------+-------------------------------+ +----------+----------------------+-------------------------------+
| 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
from v2 SCTs and other "TransItem" structures.
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. interoperability.
10.2.4. 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 "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 | | | |
+---------------+------------+-----+-------------------------------+ +---------------+------------+-----+-------------------------------+
| 0xE000 - | Reserved | n/a | Experimental Use | | 0xE000 - | Reserved | n/a | Experimental Use |
| 0xEFFF | | | | | 0xEFFF | | | |
+---------------+------------+-----+-------------------------------+ +---------------+------------+-----+-------------------------------+
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. Object Identifiers 10.2.5. Log ID Registry
This document uses object identifiers (OIDs) to identify Log IDs (see
Section 4.4), the precertificate CMS "eContentType" (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
defined in an arc that was selected due to its short encoding.
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 "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 |
+----------------+--------------+--------------+-------------------+ +----------------+--------------+--------------+-------------------+
| 1.3.101.80.0 - | Unassigned | Unassigned | First Come First | | 1.3.101.80.0 - | Unassigned | Unassigned | First Come First |
skipping to change at page 52, line 44 skipping to change at page 52, line 31
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.2.6. CT Error Types Registry 10.2.6. Error Types Registry
IANA is requested to create a new registry for errors, the "CT Error IANA is requested to create a new registry for errors, the "Error
Types" registry. Types" registry.
Requirements for this registry are Specification Required. Requirements 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 |
 End of changes. 25 change blocks. 
43 lines changed or deleted 49 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/