rfc9847v1.md		rfc9847.md
	skipping to change at line 26 ¶		skipping to change at line 26 ¶
	date: 2025-10		date: 2025-10
	consensus: true		consensus: true
	stand_alone: yes		stand_alone: yes
	smart_quotes: no		smart_quotes: no
	pi: [toc, sortrefs, symrefs]		pi: [toc, sortrefs, symrefs]
	author:		author:
	-		-
	ins: J. Salowey		ins: J. Salowey
	name: Joe Salowey		name: Joe Salowey
	organization: Venafi		organization: CyberArk
	email: joe@salowey.net		email: joe@salowey.net
	-		-
	ins: S. Turner		ins: S. Turner
	name: Sean Turner		name: Sean Turner
	organization: sn3rd		organization: sn3rd
	email: sean@sn3rd.com		email: sean@sn3rd.com
	normative:		normative:
	informative:		informative:
	--- abstract		--- abstract
	<!-- [rfced] Note that we have updated the short title, which appears in the
	running header in the PDF output, as follows. Please let us know any objections.
	Original:
	(D)TLS IANA Registry Updates
	Current:
	TLS and DTLS IANA Registry Updates
	<!-- [rfced] Please insert any keywords (beyond those that appear in the title)
	for use on https://www.rfc-editor.org/search. -->
	<!-- [rfced] FYI - We will do the following when we convert the file to RFCXML:		<!-- [rfced] FYI - We will do the following when we convert the file to RFCXML:
	- Update relevant URLs to be clickable in the HTML and PDF outputs		- Update relevant URLs to be clickable in the HTML and PDF outputs
	-->		-->
	<!-- [rfced] Because this document updates RFC 8447, please
	review the errata reported for RFC 8447
	(https://www.rfc-editor.org/errata/rfc8447)
	and let us know if you confirm our opinion that none of them
	are relevant to the content of this document.
	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,		made in RFC 8447. It adds a new value, "D" for discouraged,
	to the "Recommended" column of the selected TLS registries and		to the "Recommended" column of the selected TLS registries and
	adds a "Comment" column to all active registries that do not		adds a "Comment" column to all active registries that do not
	already have a "Comment" column. Finally, it updates the		already have a "Comment" column. Finally, it updates the
	registration request instructions.		registration request instructions.
	This document updates RFC 8447.		This document updates RFC 8447.
	--- middle		--- middle
	skipping to change at line 93 ¶		skipping to change at line 73 ¶
	This specification adds a new value, "D" for discouraged, to the "Recommended"		This specification adds a new value, "D" for discouraged, to the "Recommended"
	column of the selected TLS registries and adds a "Comment" column to all		column of the selected TLS registries and adds a "Comment" column to all
	active registries that do not already have a "Comment" column.		active registries that do not already have a "Comment" column.
	This specification also updates the registration request instructions.		This specification also updates the registration request instructions.
	# Terminology		# Terminology
	{::boilerplate bcp14-tagged}		{::boilerplate bcp14-tagged}
	<!-- [rfced] In the sentence below, is the intention to have consensus
	to leave one item or multiple items marked?
	Original:
	The IETF might have consensus to leave an items marked as "N" on the
	basis of its having limited applicability or usage constraints.
	Perhaps (Singular):
	The IETF might have consensus to leave an item marked as "N" on the
	basis of the item having limited applicability or usage constraints.
	Or (Plural):
	The IETF might have consensus to leave items marked as "N" on the
	basis of the items having limited applicability or usage constraints.
	# Updating "Recommended" Column's Values		# Updating "Recommended" Column's Values
	The instructions in this document update the "Recommended" column,		The instructions in this document update the "Recommended" column,
	originally added in {{RFC8447}} to add a third value, "D",		originally added in {{RFC8447}} to add a third value, "D",
	indicating that a value is discouraged. The permitted values		indicating that a value is discouraged. The permitted values
	of the "Recommended" column are:		of the "Recommended" column are:
	Y:		Y:
	: Indicates that the IETF has consensus that the		: Indicates that the IETF has consensus that the
	item is RECOMMENDED. This only means that the associated		item is RECOMMENDED. This only means that the associated
	skipping to change at line 132 ¶		skipping to change at line 96 ¶
	The IETF could recommend mechanisms that have limited		The IETF could recommend mechanisms that have limited
	applicability but will provide applicability statements that		applicability but will provide applicability statements that
	describe any limitations of the mechanism or necessary constraints		describe any limitations of the mechanism or necessary constraints
	on its use.		on its use.
	N:		N:
	: Indicates that the item has not been evaluated by		: Indicates that the item has not been evaluated by
	the IETF and that the IETF has made no statement about the		the IETF and that the IETF has made no statement about the
	suitability of the associated mechanism. This does not necessarily		suitability of the associated mechanism. This does not necessarily
	mean that the mechanism is flawed, only that no consensus exists.		mean that the mechanism is flawed, only that no consensus exists.
	The IETF might have consensus to leave an items marked as "N" on		The IETF might have consensus to leave an item marked as "N" on
	the basis of its having limited applicability or usage constraints.		the basis of the item having limited applicability or usage constraints.
	D:		D:
	: Indicates that the item is discouraged. This marking could be used to identify		: Indicates that the item is discouraged. This marking could be used to identify
	mechanisms that might result in problems if they are used, such as		mechanisms that might result in problems if they are used, such as
	a weak cryptographic algorithm or a mechanism that might cause		a weak cryptographic algorithm or a mechanism that might cause
	interoperability problems in deployment. When marking a registry entry as		interoperability problems in deployment. When marking a registry entry as
	"D", either the "Reference" or the "Comment" column MUST include sufficient		"D", either the "Reference" or the "Comment" column MUST include sufficient
	information to determine why the marking has been applied. Implementers and		information to determine why the marking has been applied. Implementers and
	users SHOULD consult the linked references associated with the item to		users SHOULD consult the linked references associated with the item to
	determine the conditions under which the item SHOULD NOT or MUST NOT be used.		determine the conditions under which the item SHOULD NOT or MUST NOT be used.
	skipping to change at line 182 ¶		skipping to change at line 146 ¶
	Setting a value to "Y" or "D" or transitioning the value from		Setting a value to "Y" or "D" or transitioning the value from
	"Y" or "D" in the "Recommended" column requires		"Y" or "D" in the "Recommended" column requires
	IETF Standards Action with Expert Review or IESG Approval [RFC8126].		IETF Standards Action with Expert Review or IESG Approval [RFC8126].
	- Added a reference to this document under the reference heading.		- Added a reference to this document under the reference heading.
	- Updated the "Recommended" column with the changes listed below. Entries		- Updated the "Recommended" column with the changes listed below. Entries
	keep their existing "Y" and "N" entries except for the entries in the following tab le.		keep their existing "Y" and "N" entries except for the entries in the following tab le.
	IANA has added a reference to this document for these entries.		IANA has added a reference to this document for these entries.
	<!-- [rfced] FYI - We have reordered the values in Table 1 to reflect
	how they are listed in the "TLS ExtensionType Values" registry.
	|Value | Extension Name | Recommended |		|Value | Extension Name | Recommended |
	|:-----|:------------------------------------|------------:|		|:-----|:------------------------------------|------------:|
	|4 |truncated_hmac | D |		|4 |truncated_hmac | D |
	|40 |Reserved | D |		|40 |Reserved | D |
	|46 |Reserved | D |		|46 |Reserved | D |
	|53 |connection_id (deprecated) | D |		|53 |connection_id (deprecated) | D |
	- Updated the note on the "Recommended" column with text in {{rec-note}}.		- Updated the note on the "Recommended" column with text in {{rec-note}}.
	- For the truncated_hmac, added the following link to the "Reference" column: https:/ /www.iacr.org/archive/asiacrypt2011/70730368/70730368.pdf		- For the truncated_hmac, added the following link to the "Reference" column: https:/ /www.iacr.org/archive/asiacrypt2011/70730368/70730368.pdf
	skipping to change at line 367 ¶		skipping to change at line 327 ¶
	IETF Standards Action with Expert Review or IESG Approval [RFC8126].		IETF Standards Action with Expert Review or IESG Approval [RFC8126].
	- 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.		- Entries kept their existing "Recommended" column "Y" and "N" entries.
	- Updated the note on the "Recommended" column with text in {{rec-note}}.		- Updated the note on the "Recommended" column with text in {{rec-note}}.
	# TLS HashAlgorithm Registry		# TLS HashAlgorithm Registry
	TLS 1.0 and TLS 1.1 were deprecated {{!RFC8996}}, TLS 1.2 will		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"		be in use 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		Setting a value to "Y" or "D" or transitioning the value from
	"Y" or "D" in the "Recommended" column requires		"Y" or "D" in the "Recommended" column requires
	IETF Standards Action with Expert Review or IESG Approval [RFC8126].		IETF Standards Action with Expert Review or IESG Approval [RFC8126].
	skipping to change at line 524 ¶		skipping to change at line 484 ¶
	- TLS Heartbeat Message Types		- TLS Heartbeat Message Types
	- TLS Heartbeat Modes		- TLS Heartbeat Modes
	- TLS SignatureScheme		- TLS SignatureScheme
	- 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.
	<!--[rfced] May we remove this sentence from the end of Section 14?
	This action is already listed in Section 7.
	Original:
	IANA is requested to rename the "Note" column to "Comment" column in
	TLS Exporter Labels registry.
	IANA has renamed the "Note" column to "Comment" in the
	"TLS Exporter Labels" registry.
	# Expert Review of Current and Potential IETF and IRTF Documents		# Expert Review of Current and Potential IETF and IRTF Documents
	The intent of the Specification Required choice for TLS codepoints		The intent of the Specification Required choice for TLS codepoints
	is to allow for easy registration for codepoints associated with		is 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 inside		the IETF or IRTF. When TLS-based technologies are being developed inside
	the IETF or IRTF, they should be done in coordination with the TLS WG in		the IETF or IRTF, they should be done in coordination with the TLS WG in
	order to provide appropriate review. For this reason, unless the TLS WG		order to provide appropriate review. For this reason, unless the TLS WG
	Chairs indicate otherwise via email, designated		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 586 ¶		skipping to change at line 535 ¶
	endorsement of the cipher suite, extension, supported group, etc.		endorsement of the cipher suite, extension, supported group, etc.
	# IANA Considerations		# IANA Considerations
	This document is entirely about changes to TLS-related IANA registries.		This document is entirely about changes to TLS-related IANA registries.
	IANA has modified the note applied to all TLS Specification		IANA has modified the note applied to all TLS Specification
	Required registries instructing where to send registration requests as		Required registries instructing where to send registration requests as
	follows:		follows:
	<!--[rfced] IANA provided the following note when they notified us that their
	actions were complete:
	NOTE: Some text at the end of the IANA Considerations section concerning request
	submission needs to be removed or replaced. Details at the end of the list of
	actions.
	Per this note and to reflect what appears in the TLS-related IANA registries,
	we have updated the text as shown below. Please let us know if any changes are
	needed.
	Original:
	Requests for assignments from the registry's Specification Required
	range should be sent to the mailing list described in [This RFC,
	Section 16]. If approved, designated experts should notify IANA
	within three weeks. For assistance, please contact iana@iana.org.
	Current:
	| Note: Requests for registration in the "Specification Required"
	| [RFC8126] range should be sent to iana@iana.org or submitted via
	| IANA's application form, per [RFC 9847]. IANA will forward the
	| request to the expert mailing list described in [RFC8447],
	| Section 17 and track its progress. See the registration procedure
	| table below for more information.
	{:quote}		{:quote}
	> Note: Requests for registration in the "Specification Required" {{RFC8126}}		> Note: Requests for registration in the "Specification Required" {{RFC8126}}
	range should be sent to iana@iana.org or submitted via IANA's		range should be sent to iana@iana.org or submitted via IANA's
	application form, per [RFC 9847]. IANA will		application form, per [RFC9847]. IANA will
	forward the request to the expert mailing list described in		forward the request to the expert mailing list described in
	{{RFC8447, Section 17}} and track its progress. See the registration		{{RFC8447, Section 17}} and track its progress. See the registration
	procedure table below for more information.		procedure table below for more information.
	<!-- [rfced] FYI - We have added an expansion for the following abbreviation
	per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion
	in the document carefully to ensure correctness.
	International Data Encryption Algorithm (IDEA)
	<!-- [rfced] FYI - We have updated the following terms to the form on the
	right to match other documents in Cluster 430. Please let us know any objections.
	ciphersuite(s) > cipher suite(s)
	code points > codepoints
	<!-- [rfced] Please review the "Inclusive Language" portion of the online
	Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
	and let us know if any changes are needed. Updates of this nature typically
	result in more precise language, which is helpful for readers.
	Note that our script did not flag any words in particular, but this should
	still be reviewed as a best practice.
	--- back		--- back
End of changes. 11 change blocks.
	95 lines changed or deleted		5 lines changed or added
This html diff was produced by rfcdiff 1.48.