< draft-schinazi-httpbis-transport-auth-00.txt		draft-schinazi-httpbis-transport-auth-01.txt >
	Network Working Group D. Schinazi		Network Working Group D. Schinazi
	Internet-Draft Google LLC		Internet-Draft Google LLC
	Intended status: Experimental July 08, 2019		Intended status: Experimental 8 January 2020
	Expires: January 9, 2020		Expires: 11 July 2020
	HTTP Transport Authentication		HTTP Transport Authentication
	draft-schinazi-httpbis-transport-auth-00		draft-schinazi-httpbis-transport-auth-01
	Abstract		Abstract
	The most common existing authentication mechanisms for HTTP are sent		The most common existing authentication mechanisms for HTTP are sent
	with each HTTP request, and authenticate that request instead of the		with each HTTP request, and authenticate that request instead of the
	underlying HTTP connection, or transport. While these mechanisms		underlying HTTP connection, or transport. While these mechanisms
	work well for existing uses of HTTP, they are not suitable for		work well for existing uses of HTTP, they are not suitable for
	emerging applications that multiplex non-HTTP traffic inside an HTTP		emerging applications that multiplex non-HTTP traffic inside an HTTP
	connection. This document describes the HTTP Transport		connection. This document describes the HTTP Transport
	Authentication Framework, a method of authenticating not only an HTTP		Authentication Framework, a method of authenticating not only an HTTP
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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 January 9, 2020.		This Internet-Draft will expire on 11 July 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2020 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		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Simplified BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3		1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3
	2. Computing the Authentication Proof . . . . . . . . . . . . . 3		2. Computing the Authentication Proof . . . . . . . . . . . . . 3
	3. Header Field Definition . . . . . . . . . . . . . . . . . . . 4		3. Header Field Definition . . . . . . . . . . . . . . . . . . . 3
	3.1. The u Directive . . . . . . . . . . . . . . . . . . . . . 4		3.1. The u Directive . . . . . . . . . . . . . . . . . . . . . 4
	3.2. The p Directive . . . . . . . . . . . . . . . . . . . . . 4		3.2. The p Directive . . . . . . . . . . . . . . . . . . . . . 4
	3.3. The a Directive . . . . . . . . . . . . . . . . . . . . . 4		3.3. The a Directive . . . . . . . . . . . . . . . . . . . . . 4
	4. Transport Authentication Schemes . . . . . . . . . . . . . . 4		4. Transport Authentication Schemes . . . . . . . . . . . . . . 4
	4.1. Signature . . . . . . . . . . . . . . . . . . . . . . . . 4		4.1. Signature . . . . . . . . . . . . . . . . . . . . . . . . 4
	4.2. HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . 5		4.2. HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	5. Proxy Considerations . . . . . . . . . . . . . . . . . . . . 5		5. Proxy Considerations . . . . . . . . . . . . . . . . . . . . 5
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 5		6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	7.1. Transport-Authentication Header Field . . . . . . . . . . 6		7.1. Transport-Authentication Header Field . . . . . . . . . . 6
	7.2. Transport Authentication Schemes Registry . . . . . . . . 6		7.2. Transport Authentication Schemes Registry . . . . . . . . 6
	7.3. TLS Keying Material Exporter Labels . . . . . . . . . . . 6		7.3. TLS Keying Material Exporter Labels . . . . . . . . . . . 6
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	8.1. Normative References . . . . . . . . . . . . . . . . . . 7		8.1. Normative References . . . . . . . . . . . . . . . . . . 7
	8.2. Informative References . . . . . . . . . . . . . . . . . 8		8.2. Informative References . . . . . . . . . . . . . . . . . 8
	8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	The most common existing authentication mechanisms for HTTP are sent		The most common existing authentication mechanisms for HTTP are sent
	with each HTTP request, and authenticate that request instead of the		with each HTTP request, and authenticate that request instead of the
	underlying HTTP connection, or transport. While these mechanisms		underlying HTTP connection, or transport. While these mechanisms
	work well for existing uses of HTTP, they are not suitable for		work well for existing uses of HTTP, they are not suitable for
	emerging applications that multiplex non-HTTP traffic inside an HTTP		emerging applications that multiplex non-HTTP traffic inside an HTTP
	skipping to change at page 4, line 10 ¶		skipping to change at page 4, line 5 ¶
	"EXPORTER-HTTP-Transport-Authentication-" (see Section 4 for the		"EXPORTER-HTTP-Transport-Authentication-" (see Section 4 for the
	labels and contexts used by each scheme). The TLS keying material		labels and contexts used by each scheme). The TLS keying material
	exporter is used to generate a 32-byte key which is then used as a		exporter is used to generate a 32-byte key which is then used as a
	nonce.		nonce.
	3. Header Field Definition		3. Header Field Definition
	The "Transport-Authentication" header allows a user agent to		The "Transport-Authentication" header allows a user agent to
	authenticate its transport connection with an origin server.		authenticate its transport connection with an origin server.
	Transport-Authentication = transp-auth-scheme *( OWS ";" OWS parameter )		Transport-Authentication = transp-auth-scheme *( OWS ";" OWS parameter )
	transp-auth-scheme = token		transp-auth-scheme = token
	parameter = token "=" ( token / quoted-string )		parameter = token "=" ( token / quoted-string )
	3.1. The u Directive		3.1. The u Directive
	The OPTIONAL "u" (user-id) directive specifies the user-id that the		The OPTIONAL "u" (user-id) directive specifies the user-id that the
	user agent wishes to authenticate. It is encoded using Base64		user agent wishes to authenticate. It is encoded using Base64
	(Section 4 of [RFC4648]).		(Section 4 of [RFC4648]).
	u = token68		u = token68
	3.2. The p Directive		3.2. The p Directive
	skipping to change at page 5, line 30 ¶		skipping to change at page 5, line 24 ¶
	associated secret key. When using this scheme, the "u", "p", and "a"		associated secret key. When using this scheme, the "u", "p", and "a"
	directives are REQUIRED. The TLS keying material export label for		directives are REQUIRED. The TLS keying material export label for
	this scheme is "EXPORTER-HTTP-Transport-Authentication-HMAC" and the		this scheme is "EXPORTER-HTTP-Transport-Authentication-HMAC" and the
	associated context is empty. The nonce is then HMACed using the		associated context is empty. The nonce is then HMACed using the
	selected HMAC algorithm and transmitted as the proof directive.		selected HMAC algorithm and transmitted as the proof directive.
	For example, the user-id "john.doe" authenticating using HMAC-SHA-512		For example, the user-id "john.doe" authenticating using HMAC-SHA-512
	[RFC6234] could produce the following header (lines are folded to		[RFC6234] could produce the following header (lines are folded to
	fit):		fit):
	Transport-Authentication: HMAC u="am9obi5kb2U=";a=2.16.840.1.101.3.4.2.3;		Transport-Authentication: HMAC u="am9obi5kb2U=";a=2.16.840.1.101.3.4.2.3;
	p="SW5zZXJ0IEhNQUMgb2Ygbm9uY2UgaGVyZSB3aGljaCB0YWtl		p="SW5zZXJ0IEhNQUMgb2Ygbm9uY2UgaGVyZSB3aGljaCB0YWtl
	cyA1MTIgYml0cyBmb3IgU0hBLTUxMiEhISEhIQ=="		cyA1MTIgYml0cyBmb3IgU0hBLTUxMiEhISEhIQ=="
	5. Proxy Considerations		5. Proxy Considerations
	Since Transport Authentication authenticates the underlying transport		Since Transport Authentication authenticates the underlying transport
	by leveraging TLS keying material exporters, it cannot be		by leveraging TLS keying material exporters, it cannot be
	transparently forwarded by proxies that terminate TLS. However it		transparently forwarded by proxies that terminate TLS. However it
	can be sent over proxied connections when TLS is performed end-to-end		can be sent over proxied connections when TLS is performed end-to-end
	(e.g., when using HTTP CONNECT proxies).		(e.g., when using HTTP CONNECT proxies).
	6. Security Considerations		6. Security Considerations
	skipping to change at page 6, line 6 ¶		skipping to change at page 6, line 4 ¶
	Transport Authentication allows a user-agent to authenticate to an		Transport Authentication allows a user-agent to authenticate to an
	origin server while guaranteeing freshness and without the need for		origin server while guaranteeing freshness and without the need for
	the server to transmit a nonce to the user agent. This allows the		the server to transmit a nonce to the user agent. This allows the
	server to accept authenticated clients without revealing that it		server to accept authenticated clients without revealing that it
	supports or expects authentication for some resources. It also		supports or expects authentication for some resources. It also
	allows authentication without the user agent leaking the presence of		allows authentication without the user agent leaking the presence of
	authentication to observers due to clear-text TLS Client Hello		authentication to observers due to clear-text TLS Client Hello
	extensions.		extensions.
	7. IANA Considerations		7. IANA Considerations
	7.1. Transport-Authentication Header Field		7.1. Transport-Authentication Header Field
	This document, if approved, requests IANA to register the "Transport-		This document, if approved, requests IANA to register the "Transport-
	Authentication" header in the "Permanent Message Header Field Names"		Authentication" header in the "Permanent Message Header Field Names"
	registry maintained at https://www.iana.org/assignments/message-		registry maintained at https://www.iana.org/assignments/message-
	headers/ [1].		headers/ (https://www.iana.org/assignments/message-headers/).
	+--------------------------+----------+--------------+---------------+		+--------------------------+----------+--------------+---------------+
	| Header Field Name | Protocol | Status | Reference |		| Header Field Name | Protocol | Status | Reference |
	+--------------------------+----------+--------------+---------------+		+--------------------------+----------+--------------+---------------+
	| Transport-Authentication | http | experimental | This document |		| Transport-Authentication | http | experimental | This document |
	+--------------------------+----------+--------------+---------------+		+--------------------------+----------+--------------+---------------+
	7.2. Transport Authentication Schemes Registry		7.2. Transport Authentication Schemes Registry
	This document, if approved, requests IANA to create a new HTTP		This document, if approved, requests IANA to create a new HTTP
	Transport Authentication Schemes Registry with the following entries:		Transport Authentication Schemes Registry with the following entries:
	+---------------------------------+---------------+		+---------------------------------+---------------+
	| Transport Authentication Scheme | Reference |		| Transport Authentication Scheme | Reference |
	+---------------------------------+---------------+		+---------------------------------+---------------+
	| Signature | This document |		| Signature | This document |
	+---------------------------------+---------------+		+---------------------------------+---------------+
	| HMAC | This document |		| HMAC | This document |
	+---------------------------------+---------------+		+---------------------------------+---------------+
	7.3. TLS Keying Material Exporter Labels		7.3. TLS Keying Material Exporter Labels
	This document, if approved, requests IANA to register the following		This document, if approved, requests IANA to register the following
	entries in the "TLS Exporter Labels" registry maintained at		entries in the "TLS Exporter Labels" registry maintained at
	https://www.iana.org/assignments/tls-parameters/tls-		https://www.iana.org/assignments/tls-parameters/tls-
	parameters.xhtml#exporter-labels [2]		parameters.xhtml#exporter-labels (https://www.iana.org/assignments/
			tls-parameters/tls-parameters.xhtml#exporter-labels)
	+--------------------------------------------------+		+--------------------------------------------------+
	| Value |		| Value |
	+--------------------------------------------------+		+--------------------------------------------------+
	| EXPORTER-HTTP-Transport-Authentication-Signature |		| EXPORTER-HTTP-Transport-Authentication-Signature |
	+--------------------------------------------------+		+--------------------------------------------------+
	| EXPORTER-HTTP-Transport-Authentication-HMAC |		| EXPORTER-HTTP-Transport-Authentication-HMAC |
	+--------------------------------------------------+		+--------------------------------------------------+
	Both of these entries are listed with the following qualifiers:		Both of these entries are listed with the following qualifiers:
	skipping to change at page 7, line 15 ¶		skipping to change at page 7, line 15 ¶
	+---------+-------------+---------------+		+---------+-------------+---------------+
	| DTLS-OK | Recommended | Reference |		| DTLS-OK | Recommended | Reference |
	+---------+-------------+---------------+		+---------+-------------+---------------+
	| N | Y | This document |		| N | Y | This document |
	+---------+-------------+---------------+		+---------+-------------+---------------+
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3061] Mealling, M., "A URN Namespace of Object Identifiers",
	RFC 3061, DOI 10.17487/RFC3061, February 2001,
	<https://www.rfc-editor.org/info/rfc3061>.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
	<https://www.rfc-editor.org/info/rfc4648>.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234,
	DOI 10.17487/RFC5234, January 2008,
	<https://www.rfc-editor.org/info/rfc5234>.
	[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
	Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
	March 2010, <https://www.rfc-editor.org/info/rfc5705>.
	[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Message Syntax and Routing",		Protocol (HTTP/1.1): Message Syntax and Routing",
	RFC 7230, DOI 10.17487/RFC7230, June 2014,		RFC 7230, DOI 10.17487/RFC7230, June 2014,
	<https://www.rfc-editor.org/info/rfc7230>.		<https://www.rfc-editor.org/info/rfc7230>.
			[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
			Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
			<https://www.rfc-editor.org/info/rfc8446>.
	[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Authentication", RFC 7235,		Protocol (HTTP/1.1): Authentication", RFC 7235,
	DOI 10.17487/RFC7235, June 2014,		DOI 10.17487/RFC7235, June 2014,
	<https://www.rfc-editor.org/info/rfc7235>.		<https://www.rfc-editor.org/info/rfc7235>.
	[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	RFC 7405, DOI 10.17487/RFC7405, December 2014,		Requirement Levels", BCP 14, RFC 2119,
	<https://www.rfc-editor.org/info/rfc7405>.		DOI 10.17487/RFC2119, March 1997,
			<https://www.rfc-editor.org/info/rfc2119>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Specifications: ABNF", STD 68, RFC 5234,
	<https://www.rfc-editor.org/info/rfc8446>.		DOI 10.17487/RFC5234, January 2008,
			<https://www.rfc-editor.org/info/rfc5234>.
	8.2. Informative References		[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
			RFC 7405, DOI 10.17487/RFC7405, December 2014,
			<https://www.rfc-editor.org/info/rfc7405>.
	[I-D.ietf-quic-http]		[RFC3061] Mealling, M., "A URN Namespace of Object Identifiers",
	Bishop, M., "Hypertext Transfer Protocol Version 3		RFC 3061, DOI 10.17487/RFC3061, February 2001,
	(HTTP/3)", draft-ietf-quic-http-20 (work in progress),		<https://www.rfc-editor.org/info/rfc3061>.
	April 2019.
	[I-D.ietf-quic-tls]		[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
	Thomson, M. and S. Turner, "Using TLS to Secure QUIC",		Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
	draft-ietf-quic-tls-20 (work in progress), April 2019.		March 2010, <https://www.rfc-editor.org/info/rfc5705>.
			[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
			Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
			<https://www.rfc-editor.org/info/rfc4648>.
			8.2. Informative References
	[I-D.ietf-quic-transport]		[I-D.ietf-quic-transport]
	Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed		Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
	and Secure Transport", draft-ietf-quic-transport-20 (work		and Secure Transport", Work in Progress, Internet-Draft,
	in progress), April 2019.		draft-ietf-quic-transport-24, 3 November 2019,
			<http://www.ietf.org/internet-drafts/draft-ietf-quic-
			transport-24.txt>.
			[I-D.ietf-quic-http]
			Bishop, M., "Hypertext Transfer Protocol Version 3
			(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
			quic-http-24, 4 November 2019, <http://www.ietf.org/
			internet-drafts/draft-ietf-quic-http-24.txt>.
	[I-D.pauly-quic-datagram]		[I-D.pauly-quic-datagram]
	Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable		Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable
	Datagram Extension to QUIC", draft-pauly-quic-datagram-03		Datagram Extension to QUIC", Work in Progress, Internet-
	(work in progress), July 2019.		Draft, draft-pauly-quic-datagram-05, 4 November 2019,
			<http://www.ietf.org/internet-drafts/draft-pauly-quic-
			datagram-05.txt>.
			[I-D.vvv-webtransport-http3]
			Vasiliev, V., "WebTransport over HTTP/3", Work in
			Progress, Internet-Draft, draft-vvv-webtransport-http3-01,
			3 November 2019, <http://www.ietf.org/internet-drafts/
			draft-vvv-webtransport-http3-01.txt>.
	[I-D.schinazi-masque]		[I-D.schinazi-masque]
	Schinazi, D., "The MASQUE Protocol", draft-schinazi-		Schinazi, D., "The MASQUE Protocol", Work in Progress,
	masque-00 (work in progress), February 2019.		Internet-Draft, draft-schinazi-masque-01, 8 July 2019,
			<http://www.ietf.org/internet-drafts/draft-schinazi-
			masque-01.txt>.
	[I-D.vvv-webtransport-http3]		[I-D.ietf-quic-tls]
	Vasiliev, V., "WebTransport over HTTP/3", draft-vvv-		Thomson, M. and S. Turner, "Using TLS to Secure QUIC",
	webtransport-http3-00 (work in progress), May 2019.		Work in Progress, Internet-Draft, draft-ietf-quic-tls-24,
			3 November 2019, <http://www.ietf.org/internet-drafts/
			draft-ietf-quic-tls-24.txt>.
			[RFC8410] Josefsson, S. and J. Schaad, "Algorithm Identifiers for
			Ed25519, Ed448, X25519, and X448 for Use in the Internet
			X.509 Public Key Infrastructure", RFC 8410,
			DOI 10.17487/RFC8410, August 2018,
			<https://www.rfc-editor.org/info/rfc8410>.
	[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms		[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
	(SHA and SHA-based HMAC and HKDF)", RFC 6234,		(SHA and SHA-based HMAC and HKDF)", RFC 6234,
	DOI 10.17487/RFC6234, May 2011,		DOI 10.17487/RFC6234, May 2011,
	<https://www.rfc-editor.org/info/rfc6234>.		<https://www.rfc-editor.org/info/rfc6234>.
	[RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in		[RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in
	the Internet Key Exchange Version 2 (IKEv2)", RFC 7427,		the Internet Key Exchange Version 2 (IKEv2)", RFC 7427,
	DOI 10.17487/RFC7427, January 2015,		DOI 10.17487/RFC7427, January 2015,
	<https://www.rfc-editor.org/info/rfc7427>.		<https://www.rfc-editor.org/info/rfc7427>.
	[RFC8410] Josefsson, S. and J. Schaad, "Algorithm Identifiers for
	Ed25519, Ed448, X25519, and X448 for Use in the Internet
	X.509 Public Key Infrastructure", RFC 8410,
	DOI 10.17487/RFC8410, August 2018,
	<https://www.rfc-editor.org/info/rfc8410>.
	8.3. URIs
	[1] https://www.iana.org/assignments/message-headers/
	[2] https://www.iana.org/assignments/tls-parameters/tls-
	parameters.xhtml#exporter-labels
	Acknowledgments		Acknowledgments
	The authors would like to thank many members of the IETF community,		The authors would like to thank many members of the IETF community,
	as this document is the fruit of many hallway conversations. Using		as this document is the fruit of many hallway conversations. Using
	the OID for the signature and HMAC algorithms was inspired by		the OID for the signature and HMAC algorithms was inspired by
	Signature Authentication in IKEv2 [RFC7427].		Signature Authentication in IKEv2 [RFC7427].
	Author's Address		Author's Address
	David Schinazi		David Schinazi
	Google LLC		Google LLC
	1600 Amphitheatre Parkway		1600 Amphitheatre Parkway
	Mountain View, California 94043		Mountain View, California 94043,
	United States of America		United States of America
	Email: dschinazi.ietf@gmail.com		Email: dschinazi.ietf@gmail.com
End of changes. 27 change blocks.
	89 lines changed or deleted		91 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/