< draft-ietf-trans-rfc6962-bis-38.txt		draft-ietf-trans-rfc6962-bis-39.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: 15 November 2021 Google		Expires: 18 November 2021 Google
	R. Stradling		R. Stradling
	Sectigo		Sectigo
	14 May 2021		17 May 2021
	Certificate Transparency Version 2.0		Certificate Transparency Version 2.0
	draft-ietf-trans-rfc6962-bis-38		draft-ietf-trans-rfc6962-bis-39
	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 15 November 2021.		This Internet-Draft will expire on 18 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
	skipping to change at page 3, line 50 ¶		skipping to change at page 3, line 50 ¶
	10.1.1. New Entry to the TLS ExtensionType Registry . . . . 47		10.1.1. New Entry to the TLS ExtensionType Registry . . . . 47
	10.1.2. URN Sub-namespace for TRANS errors		10.1.2. URN Sub-namespace for TRANS errors
	(urn:ietf:params:trans:error) . . . . . . . . . . . . 47		(urn:ietf:params:trans:error) . . . . . . . . . . . . 47
	10.2. New CT-Related registries . . . . . . . . . . . . . . . 47		10.2. New CT-Related registries . . . . . . . . . . . . . . . 47
	10.2.1. Hash Algorithms . . . . . . . . . . . . . . . . . . 48		10.2.1. Hash Algorithms . . . . . . . . . . . . . . . . . . 48
	10.2.2. Signature Algorithms . . . . . . . . . . . . . . . . 48		10.2.2. Signature Algorithms . . . . . . . . . . . . . . . . 48
	10.2.3. VersionedTransTypes . . . . . . . . . . . . . . . . 49		10.2.3. VersionedTransTypes . . . . . . . . . . . . . . . . 49
	10.2.4. Log Artifact Extension Registry . . . . . . . . . . 50		10.2.4. Log Artifact Extension Registry . . . . . . . . . . 50
	10.2.5. Log ID Registry . . . . . . . . . . . . . . . . . . 51		10.2.5. Log ID Registry . . . . . . . . . . . . . . . . . . 51
	10.2.6. Error Types Registry . . . . . . . . . . . . . . . . 52		10.2.6. Error Types Registry . . . . . . . . . . . . . . . . 52
			10.3. OID Assignment . . . . . . . . . . . . . . . . . . . . . 54
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 54		11. Security Considerations . . . . . . . . . . . . . . . . . . . 54
	11.1. Misissued Certificates . . . . . . . . . . . . . . . . . 54		11.1. Misissued Certificates . . . . . . . . . . . . . . . . . 55
	11.2. Detection of Misissue . . . . . . . . . . . . . . . . . 54		11.2. Detection of Misissue . . . . . . . . . . . . . . . . . 55
	11.3. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 55		11.3. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 55
	11.4. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . 55		11.4. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . 56
	11.5. Leakage of DNS Information . . . . . . . . . . . . . . . 56		11.5. Leakage of DNS Information . . . . . . . . . . . . . . . 56
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 56		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
	13.1. Normative References . . . . . . . . . . . . . . . . . . 56		13.1. Normative References . . . . . . . . . . . . . . . . . . 56
	13.2. Informative References . . . . . . . . . . . . . . . . . 58		13.2. Informative References . . . . . . . . . . . . . . . . . 59
	Appendix A. Supporting v1 and v2 simultaneously (Informative) . 59		Appendix A. Supporting v1 and v2 simultaneously (Informative) . 60
	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 47, line 22 ¶		skipping to change at page 47, line 22 ¶
	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. Additions to existing registries		10.1. Additions to existing registries
	This sub-section defines additions to existing registries.		This sub-section defines additions to existing registries.
	10.1.1. New Entry to the TLS ExtensionType Registry		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 the following entry to the "TLS ExtensionType
	"TLS ExtensionType Values" registry defined in [RFC8446], setting the		Values" registry defined in [RFC8446], with an assigned Value:
	"Recommended" value to "Y", setting the "TLS 1.3" value to "CH, CR,
	CT", and citing this document as the "Reference".		+=======+===================+============+=============+===========+
			| Value | Extension Name | TLS 1.3 | Recommended | Reference |
			+=======+===================+============+=============+===========+
			| TBD | transparency_info | CH, CR, CT | Y | RFCXXXX |
			+-------+-------------------+------------+-------------+-----------+
			Table 7
	10.1.2. URN Sub-namespace for TRANS errors		10.1.2. URN Sub-namespace for TRANS errors
	(urn:ietf:params:trans:error)		(urn:ietf:params:trans:error)
	IANA is requested to add a new entry in the "IETF URN Sub-namespace		IANA is requested to add a new entry in the "IETF URN Sub-namespace
	for Registered Protocol Parameter Identifiers" registry, following		for Registered Protocol Parameter Identifiers" registry, following
	the template in [RFC3553]:		the template in [RFC3553]:
	Registry name: trans:error		Registry name: trans:error
	skipping to change at page 48, line 26 ¶		skipping to change at page 48, line 28 ¶
	| 0x01 - | Unassigned | | Specification |		| 0x01 - | Unassigned | | Specification |
	| 0xDF | | | Required |		| 0xDF | | | Required |
	+--------+------------+------------------------+-------------------+		+--------+------------+------------------------+-------------------+
	| 0xE0 - | Reserved | | Experimental Use |		| 0xE0 - | Reserved | | Experimental Use |
	| 0xEF | | | |		| 0xEF | | | |
	+--------+------------+------------------------+-------------------+		+--------+------------+------------------------+-------------------+
	| 0xF0 - | Reserved | | Private Use |		| 0xF0 - | Reserved | | Private Use |
	| 0xFF | | | |		| 0xFF | | | |
	+--------+------------+------------------------+-------------------+		+--------+------------+------------------------+-------------------+
	Table 7		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 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 "Signature Algorithms".		named "Signature Algorithms".
	skipping to change at page 49, line 39 ¶		skipping to change at page 49, line 41 ¶
	+--------------------------------+------------------+--------------+		+--------------------------------+------------------+--------------+
	| 0x0808 - 0xFDFF | Unassigned | Expert |		| 0x0808 - 0xFDFF | Unassigned | Expert |
	| | | 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 9
	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 was 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,
	skipping to change at page 50, line 39 ¶		skipping to change at page 50, line 41 ¶
	| 0x0008 - | Unassigned | Specification Required |		| 0x0008 - | Unassigned | Specification Required |
	| 0xDFFF | | |		| 0xDFFF | | |
	+----------+----------------------+-------------------------------+		+----------+----------------------+-------------------------------+
	| 0xE000 - | Reserved | Experimental Use |		| 0xE000 - | Reserved | Experimental Use |
	| 0xEFFF | | |		| 0xEFFF | | |
	+----------+----------------------+-------------------------------+		+----------+----------------------+-------------------------------+
	| 0xF000 - | Reserved | Private Use |		| 0xF000 - | Reserved | Private Use |
	| 0xFFFF | | |		| 0xFFFF | | |
	+----------+----------------------+-------------------------------+		+----------+----------------------+-------------------------------+
	Table 9		Table 10
	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 "Log Artifact Extensions", that initially consists of:		named "Log Artifact Extensions", that initially consists of:
	skipping to change at page 51, line 18 ¶		skipping to change at page 51, line 18 ¶
	| 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 | | | |
	+---------------+------------+-----+-------------------------------+		+---------------+------------+-----+-------------------------------+
	| 0xF000 - | Reserved | n/a | Private Use |		| 0xF000 - | Reserved | n/a | Private Use |
	| 0xFFFF | | | |		| 0xFFFF | | | |
	+---------------+------------+-----+-------------------------------+		+---------------+------------+-----+-------------------------------+
	Table 10		Table 11
	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.
	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
	skipping to change at page 51, line 49 ¶		skipping to change at page 51, line 49 ¶
	| Log ID | Log Base URL | Log Operator | Reference / |		| Log ID | Log Base URL | Log Operator | Reference / |
	| | | | Assignment Policy |		| | | | Assignment Policy |
	+================+==============+==============+===================+		+================+==============+==============+===================+
	| 1.3.101.8192 - | Unassigned | Unassigned | First Come First |		| 1.3.101.8192 - | Unassigned | Unassigned | First Come First |
	| 1.3.101.16383 | | | Served |		| 1.3.101.16383 | | | Served |
	+----------------+--------------+--------------+-------------------+		+----------------+--------------+--------------+-------------------+
	| 1.3.101.80.0 - | Unassigned | Unassigned | First Come First |		| 1.3.101.80.0 - | Unassigned | Unassigned | First Come First |
	| 1.3.101.80.* | | | Served |		| 1.3.101.80.* | | | Served |
	+----------------+--------------+--------------+-------------------+		+----------------+--------------+--------------+-------------------+
	Table 11		Table 12
	All OIDs in the range from 1.3.101.8192 to 1.3.101.16383 have been		All OIDs in the range from 1.3.101.8192 to 1.3.101.16383 have been
	set aside for Log IDs. This is a limited resource of 8,192 OIDs,		set aside for Log IDs. This is a limited resource of 8,192 OIDs,
	each of which has an encoded length of 4 octets.		each of which has an encoded length of 4 octets.
	The 1.3.101.80 arc has also been set assigned for LogIDs. This is an		The 1.3.101.80 arc has also been set assigned for LogIDs. This is an
	unlimited resource, but only the 128 OIDs from 1.3.101.80.0 to		unlimited resource, but only the 128 OIDs from 1.3.101.80.0 to
	1.3.101.80.127 have an encoded length of only 4 octets.		1.3.101.80.127 have an encoded length of only 4 octets.
	Each application for the allocation of a Log ID MUST be accompanied		Each application for the allocation of a Log ID MUST be accompanied
	skipping to change at page 52, line 50 ¶		skipping to change at page 52, line 50 ¶
	+============+========+===========+		+============+========+===========+
	| Field Name | Type | Reference |		| Field Name | Type | Reference |
	+============+========+===========+		+============+========+===========+
	| identifier | string | RFCXXXX |		| identifier | string | RFCXXXX |
	+------------+--------+-----------+		+------------+--------+-----------+
	| meaning | string | RFCXXXX |		| meaning | string | RFCXXXX |
	+------------+--------+-----------+		+------------+--------+-----------+
	| reference | string | RFCXXXX |		| reference | string | RFCXXXX |
	+------------+--------+-----------+		+------------+--------+-----------+
	Table 12		Table 13
	The initial values are as follows, taken from the text above:		The initial values are as follows, taken from the text above:
	+===================+===============================+===========+		+===================+===============================+===========+
	| Identifier | Meaning | Reference |		| Identifier | Meaning | Reference |
	+===================+===============================+===========+		+===================+===============================+===========+
	| malformed | The request could not be | RFCXXXX |		| malformed | The request could not be | RFCXXXX |
	| | parsed. | |		| | parsed. | |
	+-------------------+-------------------------------+-----------+		+-------------------+-------------------------------+-----------+
	| badSubmission | "submission" is neither a | RFCXXXX |		| badSubmission | "submission" is neither a | RFCXXXX |
	skipping to change at page 54, line 15 ¶		skipping to change at page 54, line 15 ¶
	| | existing STH. | |		| | existing STH. | |
	+-------------------+-------------------------------+-----------+		+-------------------+-------------------------------+-----------+
	| startUnknown | "start" is greater than the | RFCXXXX |		| startUnknown | "start" is greater than the | RFCXXXX |
	| | number of entries in the | |		| | number of entries in the | |
	| | Merkle tree. | |		| | Merkle tree. | |
	+-------------------+-------------------------------+-----------+		+-------------------+-------------------------------+-----------+
	| endBeforeStart | "start" cannot be greater | RFCXXXX |		| endBeforeStart | "start" cannot be greater | RFCXXXX |
	| | than "end". | |		| | than "end". | |
	+-------------------+-------------------------------+-----------+		+-------------------+-------------------------------+-----------+
	Table 13		Table 14
			10.3. OID Assignment
			IANA is asked to assign one object identifier from the "SMI Security
			for PKIX Module Identifier" registry to identify the ASN.1 module in
			Appendix B of this document with an assigned Decimal value.
			+=========+=========================+============+
			| Decimal | Description | References |
			+=========+=========================+============+
			| TBD | id-mod-public-notary-v2 | RFCXXXX |
			+---------+-------------------------+------------+
			Table 15
	11. Security Considerations		11. Security Considerations
	With CAs, logs, and servers performing the actions described here,		With CAs, logs, and servers performing the actions described here,
	TLS clients can use logs and signed timestamps to reduce the		TLS clients can use logs and signed timestamps to reduce the
	likelihood that they will accept misissued certificates. If a server		likelihood that they will accept misissued certificates. If a server
	presents a valid signed timestamp for a certificate, then the client		presents a valid signed timestamp for a certificate, then the client
	knows that a log has committed to publishing the certificate. From		knows that a log has committed to publishing the certificate. From
	this, the client knows that monitors acting for the subject of the		this, the client knows that monitors acting for the subject of the
	certificate have had some time to notice the misissuance and take		certificate have had some time to notice the misissuance and take
End of changes. 16 change blocks.
	20 lines changed or deleted		41 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/