rfc9847v1.txt		rfc9847.txt
	Internet Engineering Task Force (IETF) J. Salowey		Internet Engineering Task Force (IETF) J. Salowey
	Request for Comments: 9847 Venafi		Request for Comments: 9847 CyberArk
	Updates: 8447 S. Turner		Updates: 8447 S. Turner
	Category: Standards Track sn3rd		Category: Standards Track sn3rd
	ISSN: 2070-1721 October 2025		ISSN: 2070-1721 October 2025
	IANA Registry Updates for TLS and DTLS		IANA Registry Updates for TLS and DTLS
	Abstract		Abstract
	This document updates the changes to the TLS and DTLS IANA registries		This document updates the changes to the TLS and DTLS IANA registries
	made in RFC 8447. It adds a new value, "D" for discouraged, to the		made in RFC 8447. It adds a new value, "D" for discouraged, to the
	skipping to change at line 117 ¶		skipping to change at line 117 ¶
	documentation for the mechanism is necessary to understand the		documentation for the mechanism is necessary to understand the
	applicability of that mechanism. The IETF could recommend		applicability of that mechanism. The IETF could recommend
	mechanisms that have limited applicability but will provide		mechanisms that have limited applicability but will provide
	applicability statements that describe any limitations of the		applicability statements that describe any limitations of the
	mechanism or necessary constraints on its use.		mechanism or necessary constraints on its use.
	N: Indicates that the item has not been evaluated by the IETF and		N: Indicates that the item has not been evaluated by the IETF and
	that the IETF has made no statement about the suitability of the		that the IETF has made no statement about the suitability of the
	associated mechanism. This does not necessarily mean that the		associated mechanism. This does not necessarily mean that the
	mechanism is flawed, only that no consensus exists. The IETF		mechanism is flawed, only that no consensus exists. The IETF
	might have consensus to leave an items marked as "N" on the basis		might have consensus to leave an item marked as "N" on the basis
	of its having limited applicability or usage constraints.		of the item having limited applicability or usage constraints.
	D: Indicates that the item is discouraged. This marking could be		D: Indicates that the item is discouraged. This marking could be
	used to identify mechanisms that might result in problems if they		used to identify mechanisms that might result in problems if they
	are used, such as a weak cryptographic algorithm or a mechanism		are used, such as a weak cryptographic algorithm or a mechanism
	that might cause interoperability problems in deployment. When		that might cause interoperability problems in deployment. When
	marking a registry entry as "D", either the "Reference" or the		marking a registry entry as "D", either the "Reference" or the
	"Comment" column MUST include sufficient information to determine		"Comment" column MUST include sufficient information to determine
	why the marking has been applied. Implementers and users SHOULD		why the marking has been applied. Implementers and users SHOULD
	consult the linked references associated with the item to		consult the linked references associated with the item to
	determine the conditions under which the item SHOULD NOT or MUST		determine the conditions under which the item SHOULD NOT or MUST
	skipping to change at line 432 ¶		skipping to change at line 432 ¶
	* Added a reference to this document under the reference heading.		* Added a reference to this document under the reference heading.
	* Entries kept their existing "Recommended" column "Y" and "N"		* Entries kept their existing "Recommended" column "Y" and "N"
	entries.		entries.
	* Updated the note on the "Recommended" column with text in		* Updated the note on the "Recommended" column with text in
	Section 3.1.		Section 3.1.
	9. TLS HashAlgorithm Registry		9. TLS HashAlgorithm Registry
	TLS 1.0 and TLS 1.1 were deprecated [RFC8996], TLS 1.2 will be in use		TLS 1.0 and TLS 1.1 were deprecated [RFC8996]; TLS 1.2 will be in use
	for some time. In order to reflect the changes in the "Recommended"		for some time. In order to reflect the changes in the "Recommended"
	column allocation, IANA has updated the "TLS HashAlgorithm" registry		column allocation, IANA has updated the "TLS HashAlgorithm" registry
	as follows:		as follows:
	* Updated the registration procedure to include:		* Updated the registration procedure to include:
	Setting a value to "Y" or "D" or transitioning the value from "Y"		Setting a value to "Y" or "D" or transitioning the value from "Y"
	or "D" in the "Recommended" column requires IETF Standards Action		or "D" in the "Recommended" column requires IETF Standards Action
	with Expert Review or IESG Approval [RFC8126].		with Expert Review or IESG Approval [RFC8126].
	skipping to change at line 649 ¶		skipping to change at line 649 ¶
	* TLS PskKeyExchangeMode		* TLS PskKeyExchangeMode
	* TLS KDF Identifiers		* TLS KDF Identifiers
	* TLS SSLKEYLOGFILE Labels		* TLS SSLKEYLOGFILE Labels
	This list of registries is all registries that do not already have a		This list of registries is all registries that do not already have a
	"Comment" or "Note" column or that were not orphaned by TLS 1.3.		"Comment" or "Note" column or that were not orphaned by TLS 1.3.
	IANA has renamed the "Note" column to "Comment" in the "TLS Exporter
	Labels" registry.
	15. Expert Review of Current and Potential IETF and IRTF Documents		15. Expert Review of Current and Potential IETF and IRTF Documents
	The intent of the Specification Required choice for TLS codepoints is		The intent of the Specification Required choice for TLS codepoints is
	to allow for easy registration for codepoints associated with		to allow for easy registration for codepoints associated with
	protocols and algorithms that are not being actively developed inside		protocols and algorithms that are not being actively developed inside
	the IETF or IRTF. When TLS-based technologies are being developed		the IETF or IRTF. When TLS-based technologies are being developed
	inside the IETF or IRTF, they should be done in coordination with the		inside the IETF or IRTF, they should be done in coordination with the
	TLS WG in order to provide appropriate review. For this reason,		TLS WG in order to provide appropriate review. For this reason,
	unless the TLS WG Chairs indicate otherwise via email, designated		unless the TLS WG Chairs indicate otherwise via email, designated
	experts should decline codepoint registrations for documents that		experts should decline codepoint registrations for documents that
	skipping to change at line 708 ¶		skipping to change at line 705 ¶
	This document is entirely about changes to TLS-related IANA		This document is entirely about changes to TLS-related IANA
	registries.		registries.
	IANA has modified the note applied to all TLS Specification Required		IANA has modified the note applied to all TLS Specification Required
	registries instructing where to send registration requests as		registries instructing where to send registration requests as
	follows:		follows:
	| Note: Requests for registration in the "Specification Required"		| Note: Requests for registration in the "Specification Required"
	| [RFC8126] range should be sent to iana@iana.org or submitted via		| [RFC8126] range should be sent to iana@iana.org or submitted via
	| IANA's application form, per [RFC 9847]. IANA will forward the		| IANA's application form, per [RFC9847]. IANA will forward the
	| request to the expert mailing list described in [RFC8447],		| request to the expert mailing list described in [RFC8447],
	| Section 17 and track its progress. See the registration procedure		| Section 17 and track its progress. See the registration procedure
	| table below for more information.		| table below for more information.
	19. Normative References		19. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	skipping to change at line 758 ¶		skipping to change at line 755 ¶
	<https://www.rfc-editor.org/info/rfc8996>.		<https://www.rfc-editor.org/info/rfc8996>.
	[RFC9155] Velvindron, L., Moriarty, K., and A. Ghedini, "Deprecating		[RFC9155] Velvindron, L., Moriarty, K., and A. Ghedini, "Deprecating
	MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 1.2",		MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 1.2",
	RFC 9155, DOI 10.17487/RFC9155, December 2021,		RFC 9155, DOI 10.17487/RFC9155, December 2021,
	<https://www.rfc-editor.org/info/rfc9155>.		<https://www.rfc-editor.org/info/rfc9155>.
	Authors' Addresses		Authors' Addresses
	Joe Salowey		Joe Salowey
	Venafi		CyberArk
	Email: joe@salowey.net		Email: joe@salowey.net
	Sean Turner		Sean Turner
	sn3rd		sn3rd
	Email: sean@sn3rd.com		Email: sean@sn3rd.com
End of changes. 6 change blocks.
	9 lines changed or deleted		6 lines changed or added
This html diff was produced by rfcdiff 1.48.