rfc9261v2.txt		rfc9261.txt
	skipping to change at line 124 ¶		skipping to change at line 124 ¶
	the authentication boundaries of the higher-layer protocol. For		the authentication boundaries of the higher-layer protocol. For
	example, multiplexed connection protocols like HTTP/2 [RFC9113] do		example, multiplexed connection protocols like HTTP/2 [RFC9113] do
	not have a notion of which TLS record a given message is a part of.		not have a notion of which TLS record a given message is a part of.
	Exported Authenticators are meant to be used as a building block for		Exported Authenticators are meant to be used as a building block for
	application protocols. Mechanisms such as those required to		application protocols. Mechanisms such as those required to
	advertise support and handle authentication errors are not handled by		advertise support and handle authentication errors are not handled by
	TLS (or DTLS).		TLS (or DTLS).
	The minimum version of TLS and DTLS required to implement the		The minimum version of TLS and DTLS required to implement the
	mechanisms described in this document are TLS 1.2 [RFC6347] and DTLS		mechanisms described in this document are TLS 1.2 [RFC5246] and DTLS
	1.2 [RFC5246]		1.2 [RFC6347].
	2. Conventions and Terminology		2. Conventions and Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"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		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	This document uses terminology such as client, server, connection,		This document uses terminology such as client, server, connection,
	skipping to change at line 726 ¶		skipping to change at line 726 ¶
	<https://www.rfc-editor.org/info/rfc9113>.		<https://www.rfc-editor.org/info/rfc9113>.
	[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate		[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
	Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,		Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
	December 2021, <https://www.rfc-editor.org/info/rfc9162>.		December 2021, <https://www.rfc-editor.org/info/rfc9162>.
	[SIGMAC] Krawczyk, H., "A Unilateral-to-Mutual Authentication		[SIGMAC] Krawczyk, H., "A Unilateral-to-Mutual Authentication
	Compiler for Key Exchange (with Applications to Client		Compiler for Key Exchange (with Applications to Client
	Authentication in TLS 1.3)", Proceedings of the 2016 ACM		Authentication in TLS 1.3)", Proceedings of the 2016 ACM
	SIGSAC Conference on Computer and Communications Security,		SIGSAC Conference on Computer and Communications Security,
	DOI https://doi.org/10.1145/2976749.2978325, August 2016,		DOI 10.1145/2976749.2978325, August 2016,
	<https://eprint.iacr.org/2016/711.pdf>.		<https://eprint.iacr.org/2016/711.pdf>.
	Acknowledgements		Acknowledgements
	Comments on this proposal were provided by Martin Thomson.		Comments on this proposal were provided by Martin Thomson.
	Suggestions for Section 9 were provided by Karthikeyan Bhargavan.		Suggestions for Section 9 were provided by Karthikeyan Bhargavan.
	Author's Address		Author's Address
	Nick Sullivan		Nick Sullivan
End of changes. 2 change blocks.
	3 lines changed or deleted		3 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/