< 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/