rfc9729v1.txt		rfc9729.txt
	Internet Engineering Task Force (IETF) D. Schinazi		Internet Engineering Task Force (IETF) D. Schinazi
	Request for Comments: 9729 Google LLC		Request for Comments: 9729 Google LLC
	Category: Standards Track D. Oliver		Category: Standards Track D. Oliver
	ISSN: 2070-1721 Guardian Project		ISSN: 2070-1721 Guardian Project
	J. Hoyland		J. Hoyland
	Cloudflare Inc.		Cloudflare Inc.
	January 2025		February 2025
	The Concealed HTTP Authentication Scheme		The Concealed HTTP Authentication Scheme
	Abstract		Abstract
	Most HTTP authentication schemes are probeable in the sense that it		Most HTTP authentication schemes are probeable in the sense that it
	is possible for an unauthenticated client to probe whether an origin		is possible for an unauthenticated client to probe whether an origin
	serves resources that require authentication. It is possible for an		serves resources that require authentication. It is possible for an
	origin to hide the fact that it requires authentication by not		origin to hide the fact that it requires authentication by not
	generating Unauthorized status codes; however, that only works with		generating Unauthorized status codes; however, that only works with
	skipping to change at line 59 ¶		skipping to change at line 59 ¶
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Revised BSD License text as described in Section 4.e of the		include Revised BSD License text as described in Section 4.e of the
	Trust Legal Provisions and are provided without warranty as described		Trust Legal Provisions and are provided without warranty as described
	in the Revised BSD License.		in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction		1. Introduction
	1.1. Conventions and Definitions		1.1. Conventions and Definitions
	2. The Concealed Authentication Scheme		2. The Concealed HTTP Authentication Scheme
	3. Client Handling		3. Client Handling
	3.1. Key Exporter Context		3.1. Key Exporter Context
	3.1.1. Public Key Encoding		3.1.1. Public Key Encoding
	3.2. Key Exporter Output		3.2. Key Exporter Output
	3.3. Signature Computation		3.3. Signature Computation
	4. Authentication Parameters		4. Authentication Parameters
	4.1. The k Parameter		4.1. The k Parameter
	4.2. The a Parameter		4.2. The a Parameter
	4.3. The p Parameter		4.3. The p Parameter
	4.4. The s Parameter		4.4. The s Parameter
	skipping to change at line 131 ¶		skipping to change at line 131 ¶
	"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 the notation from Section 1.3 of [QUIC].		This document uses the notation from Section 1.3 of [QUIC].
	Various examples in this document contain long lines that may be		Various examples in this document contain long lines that may be
	folded, as described in [RFC8792].		folded, as described in [RFC8792].
	2. The Concealed Authentication Scheme		2. The Concealed HTTP Authentication Scheme
	This document defines the "Concealed" HTTP authentication scheme. It		This document defines the "Concealed" HTTP authentication scheme. It
	uses asymmetric cryptography. Clients possess a key ID and a public/		uses asymmetric cryptography. Clients possess a key ID and a public/
	private key pair, and origin servers maintain a mapping of authorized		private key pair, and origin servers maintain a mapping of authorized
	key IDs to associated public keys.		key IDs to associated public keys.
	The client uses a TLS keying material exporter to generate data to be		The client uses a TLS keying material exporter to generate data to be
	signed (see Section 3) then sends the signature using the		signed (see Section 3) then sends the signature using the
	Authorization (or Proxy-Authorization) header field (see Section 11		Authorization (or Proxy-Authorization) header field (see Section 11
	of [HTTP]). The signature and additional information are exchanged		of [HTTP]). The signature and additional information are exchanged
	skipping to change at line 206 ¶		skipping to change at line 206 ¶
	scheme portion of a URI as defined in Section 3.1 of [URI].		scheme portion of a URI as defined in Section 3.1 of [URI].
	Host: The host for this request, encoded using the format of the		Host: The host for this request, encoded using the format of the
	host portion of a URI as defined in Section 3.2.2 of [URI].		host portion of a URI as defined in Section 3.2.2 of [URI].
	Port: The port for this request, encoded in network byte order.		Port: The port for this request, encoded in network byte order.
	Note that the port is either included in the URI or is the default		Note that the port is either included in the URI or is the default
	port for the scheme in use; see Section 3.2.3 of [URI].		port for the scheme in use; see Section 3.2.3 of [URI].
	Realm: The realm of authentication that is sent in the realm		Realm: The realm of authentication that is sent in the realm
	authentication parameter (Section 11.5 of [HTTP]). If the realm		authentication parameter (see Section 11.5 of [HTTP]). If the
	authentication parameter is not present, this SHALL be empty.		realm authentication parameter is not present, this SHALL be
	This document does not define a means for the origin to		empty. This document does not define a means for the origin to
	communicate a realm to the client. If a client is not configured		communicate a realm to the client. If a client is not configured
	to use a specific realm, it SHALL use an empty realm and SHALL NOT		to use a specific realm, it SHALL use an empty realm and SHALL NOT
	send the realm authentication parameter.		send the realm authentication parameter.
	The Signature Algorithm and Port fields are encoded as unsigned		The Signature Algorithm and Port fields are encoded as unsigned
	16-bit integers in network byte order. The Key ID, Public Key,		16-bit integers in network byte order. The Key ID, Public Key,
	Scheme, Host, and Realm fields are length-prefixed strings; they are		Scheme, Host, and Realm fields are length-prefixed strings; they are
	preceded by a Length field that represents their length in bytes.		preceded by a Length field that represents their length in bytes.
	These length fields are encoded using the variable-length integer		These length fields are encoded using the variable-length integer
	encoding from Section 16 of [QUIC] and MUST be encoded in the minimum		encoding from Section 16 of [QUIC] and MUST be encoded in the minimum
	number of bytes necessary.		number of bytes necessary.
	3.1.1. Public Key Encoding		3.1.1. Public Key Encoding
	Both the "Public Key" field of the TLS key exporter context (see		Both the "Public Key" field of the TLS key exporter context (see
	above) and the a Parameter (see Section 4.2) carry the same public		above) and the a Parameter (see Section 4.2) carry the same public
	key. The encoding of the public key is determined by the Signature		key. The encoding of the public key is determined by the signature
	Algorithm in use as follows:		algorithm in use as follows:
	RSASSA-PSS algorithms: The public key is an RSAPublicKey structure		RSASSA-PSS algorithms: The public key is an RSAPublicKey structure
	[PKCS1] encoded in DER [X.690]. BER encodings which are not DER		[PKCS1] encoded in DER [X.690]. BER encodings that are not DER
	MUST be rejected.		MUST be rejected.
	ECDSA algorithms: The public key is an		ECDSA algorithms: The public key is an
	UncompressedPointRepresentation structure defined in		UncompressedPointRepresentation structure defined in
	Section 4.2.8.2 of [TLS], using the curve specified by the		Section 4.2.8.2 of [TLS], using the curve specified by the
	SignatureScheme.		SignatureScheme.
	EdDSA algorithms: The public key is the byte string encoding defined		EdDSA algorithms: The public key is the byte string encoding defined
	in [EdDSA].		in [EdDSA].
	skipping to change at line 329 ¶		skipping to change at line 329 ¶
	concealed-byte-sequence-param-value = *( ALPHA / DIGIT / "-" / "_" )		concealed-byte-sequence-param-value = *( ALPHA / DIGIT / "-" / "_" )
	concealed-integer-param-value = %x31-39 1*4( DIGIT ) / "0"		concealed-integer-param-value = %x31-39 1*4( DIGIT ) / "0"
	Figure 4: Authentication Parameter Value ABNF		Figure 4: Authentication Parameter Value ABNF
	4.1. The k Parameter		4.1. The k Parameter
	The REQUIRED "k" (key ID) Parameter is a byte sequence that		The REQUIRED "k" (key ID) Parameter is a byte sequence that
	identifies which key the client wishes to use to authenticate. This		identifies which key the client wishes to use to authenticate. This
	is used by the backend to point to an entry in a server-side database		is used by the backend to point to an entry in a server-side database
	of known keys; see Section 6.3.		of known keys (see Section 6.3).
	4.2. The a Parameter		4.2. The a Parameter
	The REQUIRED "a" (public key) Parameter is a byte sequence that		The REQUIRED "a" (public key) Parameter is a byte sequence that
	specifies the public key used by the server to validate the signature		specifies the public key used by the server to validate the signature
	provided by the client. This avoids key confusion issues (see		provided by the client. This avoids key confusion issues (see
	[SEEMS-LEGIT]). The encoding of the public key is described in		[SEEMS-LEGIT]). The encoding of the public key is described in
	Section 3.1.1.		Section 3.1.1.
	4.3. The p Parameter		4.3. The p Parameter
	The REQUIRED "p" (proof) Parameter is a byte sequence that specifies		The REQUIRED "p" (proof) Parameter is a byte sequence that specifies
	the proof that the client provides to attest to possessing the		the proof that the client provides to attest to possessing the
	credential that matches its key ID.		credential that matches its key ID.
	4.4. The s Parameter		4.4. The s Parameter
	The REQUIRED "s" (signature) Parameter is an integer that specifies		The REQUIRED "s" (signature scheme) Parameter is an integer that
	the signature scheme used to compute the proof transmitted in the p		specifies the signature scheme used to compute the proof transmitted
	Parameter. Its value is an integer between 0 and 65535 inclusive		in the p Parameter. Its value is an integer between 0 and 65535
	from the IANA "TLS SignatureScheme" registry maintained at		inclusive from the IANA "TLS SignatureScheme" registry maintained at
	<https://www.iana.org/assignments/tls-parameters/tls-		<https://www.iana.org/assignments/tls-parameters>.
	parameters.xhtml#tls-signaturescheme>.
	4.5. The v Parameter		4.5. The v Parameter
	The REQUIRED "v" (verification) Parameter is a byte sequence that		The REQUIRED "v" (verification) Parameter is a byte sequence that
	specifies the verification that the client provides to attest to		specifies the verification that the client provides to attest to
	possessing the key exporter output (see Section 3.2 for details).		possessing the key exporter output (see Section 3.2 for details).
	This avoids issues with signature schemes where certain keys can		This avoids issues with signature schemes where certain keys can
	generate signatures that are valid for multiple inputs (see		generate signatures that are valid for multiple inputs (see
	[SEEMS-LEGIT]).		[SEEMS-LEGIT]).
	5. Example		5. Example
	For example, the key ID "basement" authenticating using Ed25519		For example, a client using the key ID "basement" and the signature
	[ED25519] could produce the following header field:		algorithm Ed25519 [ED25519] could produce the following header field:
	NOTE: '\' line wrapping per RFC 8792		NOTE: '\' line wrapping per RFC 8792
	Authorization: Concealed \		Authorization: Concealed \
	k=YmFzZW1lbnQ, \		k=YmFzZW1lbnQ, \
	a=VGhpcyBpcyBh-HB1YmxpYyBrZXkgaW4gdXNl_GhlcmU, \		a=VGhpcyBpcyBh-HB1YmxpYyBrZXkgaW4gdXNl_GhlcmU, \
	s=2055, \		s=2055, \
	v=dmVyaWZpY2F0aW9u_zE2Qg, \		v=dmVyaWZpY2F0aW9u_zE2Qg, \
	p=QzpcV2luZG93c_xTeXN0ZW0zMlxkcml2ZXJz-ENyb3dkU\		p=QzpcV2luZG93c_xTeXN0ZW0zMlxkcml2ZXJz-ENyb3dkU\
	3RyaWtlXEMtMDAwMDAwMDAyOTEtMD-wMC0w_DAwLnN5cw		3RyaWtlXEMtMDAwMDAwMDAyOTEtMD-wMC0w_DAwLnN5cw
	skipping to change at line 398 ¶		skipping to change at line 397 ¶
	database of accepted key identifiers and public keys.		database of accepted key identifiers and public keys.
	In most deployments, we expect both the frontend and backend roles to		In most deployments, we expect both the frontend and backend roles to
	be implemented in a single HTTP origin server (as defined in		be implemented in a single HTTP origin server (as defined in
	Section 3.6 of [HTTP]). However, these roles can be split such that		Section 3.6 of [HTTP]). However, these roles can be split such that
	the frontend is an HTTP gateway (as defined in Section 3.7 of [HTTP])		the frontend is an HTTP gateway (as defined in Section 3.7 of [HTTP])
	and the backend is an HTTP origin server.		and the backend is an HTTP origin server.
	6.1. Frontend Handling		6.1. Frontend Handling
	If a frontend is configured to check the Concealed authentication		If a frontend is configured to check the Concealed HTTP
	scheme, it will parse the Authorization (or Proxy-Authorization)		authentication scheme, it will parse the Authorization (or Proxy-
	header field. If the authentication scheme is set to "Concealed",		Authorization) header field. If the authentication scheme is set to
	the frontend MUST validate that all the required authentication		"Concealed", the frontend MUST validate that all the required
	parameters are present and can be parsed correctly as defined in		authentication parameters are present and can be parsed correctly as
	Section 4. If any parameter is missing or fails to parse, the		defined in Section 4. If any parameter is missing or fails to parse,
	frontend MUST ignore the entire Authorization (or Proxy-		the frontend MUST ignore the entire Authorization (or Proxy-
	Authorization) header field.		Authorization) header field.
	The frontend then uses the data from these authentication parameters		The frontend then uses the data from these authentication parameters
	to compute the key exporter output, as defined in Section 3.2. The		to compute the key exporter output, as defined in Section 3.2. The
	frontend then shares the header field and the key exporter output		frontend then shares the header field and the key exporter output
	with the backend.		with the backend.
	6.2. Communication Between Frontend and Backend		6.2. Communication Between Frontend and Backend
	If the frontend and backend roles are implemented in the same		If the frontend and backend roles are implemented in the same
	skipping to change at line 523 ¶		skipping to change at line 522 ¶
	Because the TLS keying material exporter is only secure for		Because the TLS keying material exporter is only secure for
	authentication when it is uniquely bound to the TLS session		authentication when it is uniquely bound to the TLS session
	[RFC7627], the Concealed authentication scheme requires either one of		[RFC7627], the Concealed authentication scheme requires either one of
	the following properties:		the following properties:
	* The TLS version in use is greater than or equal to 1.3 [TLS].		* The TLS version in use is greater than or equal to 1.3 [TLS].
	* The TLS version in use is 1.2, and the extended master secret		* The TLS version in use is 1.2, and the extended master secret
	extension [RFC7627] has been negotiated.		extension [RFC7627] has been negotiated.
	Clients MUST NOT use the Concealed authentication scheme on		Clients MUST NOT use the Concealed HTTP authentication scheme on
	connections that do not meet one of the two properties above. If a		connections that do not meet one of the two properties above. If a
	server receives a request that uses this authentication scheme on a		server receives a request that uses this authentication scheme on a
	connection that meets neither of the above properties, the server		connection that meets neither of the above properties, the server
	MUST treat the request as if the authentication were not present.		MUST treat the request as if the authentication were not present.
	8. Security Considerations		8. Security Considerations
	The Concealed HTTP authentication scheme allows a client to		The Concealed HTTP authentication scheme allows a client to
	authenticate to an origin server while guaranteeing freshness and		authenticate to an origin server while guaranteeing freshness and
	without the need for the server to transmit a nonce to the client.		without the need for the server to transmit a nonce to the client.
	skipping to change at line 586 ¶		skipping to change at line 585 ¶
	http-authschemes>:		http-authschemes>:
	Authentication Scheme Name: Concealed		Authentication Scheme Name: Concealed
	Reference: RFC 9729		Reference: RFC 9729
	Notes: None		Notes: None
	9.2. TLS Keying Material Exporter Labels		9.2. TLS Keying Material Exporter Labels
	IANA has registered the following entry in the "TLS Exporter Labels"		IANA has registered the following entry in the "TLS Exporter Labels"
	registry maintained at <https://www.iana.org/assignments/tls-		registry maintained at <https://www.iana.org/assignments/tls-
	parameters#exporter-labels>:		parameters>:
	Value: EXPORTER-HTTP-Concealed-Authentication		Value: EXPORTER-HTTP-Concealed-Authentication
	DTLS-OK: N		DTLS-OK: N
	Recommended: Y		Recommended: Y
	Reference: RFC 9729		Reference: RFC 9729
	9.3. HTTP Field Name		9.3. HTTP Field Name
	IANA has registered the following entry in the "Hypertext Transfer		IANA has registered the following entry in the "Hypertext Transfer
	Protocol (HTTP) Field Name Registry" maintained at		Protocol (HTTP) Field Name Registry" maintained at
	<https://www.iana.org/assignments/http-fields/http-fields.xhtml>:		<https://www.iana.org/assignments/http-fields>:
	Field Name: Concealed-Auth-Export		Field Name: Concealed-Auth-Export
	Status: permanent		Status: permanent
	Structured Type: Item		Structured Type: Item
	Reference: RFC 9729		Reference: RFC 9729
	Comments: None		Comments: None
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234,		Specifications: ABNF", STD 68, RFC 5234,
	DOI 10.17487/RFC5234, January 2008,		DOI 10.17487/RFC5234, January 2008,
	<https://www.rfc-editor.org/rfc/rfc5234>.		<https://www.rfc-editor.org/info/rfc5234>.
	[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data		[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,		Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
	<https://www.rfc-editor.org/rfc/rfc4648>.		<https://www.rfc-editor.org/info/rfc4648>.
	[EdDSA] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital		[EdDSA] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
	Signature Algorithm (EdDSA)", RFC 8032,		Signature Algorithm (EdDSA)", RFC 8032,
	DOI 10.17487/RFC8032, January 2017,		DOI 10.17487/RFC8032, January 2017,
	<https://www.rfc-editor.org/rfc/rfc8032>.		<https://www.rfc-editor.org/info/rfc8032>.
	[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "HTTP Semantics", STD 97, RFC 9110,		Ed., "HTTP Semantics", STD 97, RFC 9110,
	DOI 10.17487/RFC9110, June 2022,		DOI 10.17487/RFC9110, June 2022,
	<https://www.rfc-editor.org/rfc/rfc9110>.		<https://www.rfc-editor.org/info/rfc9110>.
	[KEY-EXPORT]		[KEY-EXPORT]
	Rescorla, E., "Keying Material Exporters for Transport		Rescorla, E., "Keying Material Exporters for Transport
	Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,		Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
	March 2010, <https://www.rfc-editor.org/rfc/rfc5705>.		March 2010, <https://www.rfc-editor.org/info/rfc5705>.
	[PKCS1] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,		[PKCS1] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
	"PKCS #1: RSA Cryptography Specifications Version 2.2",		"PKCS #1: RSA Cryptography Specifications Version 2.2",
	RFC 8017, DOI 10.17487/RFC8017, November 2016,		RFC 8017, DOI 10.17487/RFC8017, November 2016,
	<https://www.rfc-editor.org/rfc/rfc8017>.		<https://www.rfc-editor.org/info/rfc8017>.
	[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based		[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
	Multiplexed and Secure Transport", RFC 9000,		Multiplexed and Secure Transport", RFC 9000,
	DOI 10.17487/RFC9000, May 2021,		DOI 10.17487/RFC9000, May 2021,
	<https://www.rfc-editor.org/rfc/rfc9000>.		<https://www.rfc-editor.org/info/rfc9000>.
	[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/rfc/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,		[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
	Langley, A., and M. Ray, "Transport Layer Security (TLS)		Langley, A., and M. Ray, "Transport Layer Security (TLS)
	Session Hash and Extended Master Secret Extension",		Session Hash and Extended Master Secret Extension",
	RFC 7627, DOI 10.17487/RFC7627, September 2015,		RFC 7627, DOI 10.17487/RFC7627, September 2015,
	<https://www.rfc-editor.org/rfc/rfc7627>.		<https://www.rfc-editor.org/info/rfc7627>.
	[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/rfc/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,		[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
	"Handling Long Lines in Content of Internet-Drafts and		"Handling Long Lines in Content of Internet-Drafts and
	RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,		RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
	<https://www.rfc-editor.org/rfc/rfc8792>.		<https://www.rfc-editor.org/info/rfc8792>.
	[STRUCTURED-FIELDS]		[STRUCTURED-FIELDS]
	Nottingham, M. and P. Kamp, "Structured Field Values for		Nottingham, M. and P. Kamp, "Structured Field Values for
	HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,		HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,
	<https://www.rfc-editor.org/rfc/rfc8941>.		<https://www.rfc-editor.org/info/rfc9651>.
	[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/rfc/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, DOI 10.17487/RFC3986, January 2005,		RFC 3986, DOI 10.17487/RFC3986, January 2005,
	<https://www.rfc-editor.org/rfc/rfc3986>.		<https://www.rfc-editor.org/info/rfc3986>.
	[X.690] ITU-T, "Information technology - ASN.1 encoding Rules:		[X.690] ITU-T, "Information technology - ASN.1 encoding Rules:
	Specification of Basic Encoding Rules (BER), Canonical		Specification of Basic Encoding Rules (BER), Canonical
	Encoding Rules (CER) and Distinguished Encoding Rules		Encoding Rules (CER) and Distinguished Encoding Rules
	(DER)", ITU-T Recommendation X690, ISO/IEC 8825-1:2021,		(DER)", ITU-T Recommendation X690, ISO/IEC 8825-1:2021,
	February 2021.		February 2021, <https://www.itu.int/rec/T-REC-X.690>.
	10.2. Informative References		10.2. Informative References
	[ED25519] Josefsson, S. and J. Schaad, "Algorithm Identifiers for		[ED25519] Josefsson, S. and J. Schaad, "Algorithm Identifiers for
	Ed25519, Ed448, X25519, and X448 for Use in the Internet		Ed25519, Ed448, X25519, and X448 for Use in the Internet
	X.509 Public Key Infrastructure", RFC 8410,		X.509 Public Key Infrastructure", RFC 8410,
	DOI 10.17487/RFC8410, August 2018,		DOI 10.17487/RFC8410, August 2018,
	<https://www.rfc-editor.org/rfc/rfc8410>.		<https://www.rfc-editor.org/info/rfc8410>.
	[HOBA] Farrell, S., Hoffman, P., and M. Thomas, "HTTP Origin-		[HOBA] Farrell, S., Hoffman, P., and M. Thomas, "HTTP Origin-
	Bound Authentication (HOBA)", RFC 7486,		Bound Authentication (HOBA)", RFC 7486,
	DOI 10.17487/RFC7486, March 2015,		DOI 10.17487/RFC7486, March 2015,
	<https://www.rfc-editor.org/rfc/rfc7486>.		<https://www.rfc-editor.org/info/rfc7486>.
	[HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,		[HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
	DOI 10.17487/RFC9113, June 2022,		DOI 10.17487/RFC9113, June 2022,
	<https://www.rfc-editor.org/rfc/rfc9113>.		<https://www.rfc-editor.org/info/rfc9113>.
	[HTTP/3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,		[HTTP/3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
	June 2022, <https://www.rfc-editor.org/rfc/rfc9114>.		June 2022, <https://www.rfc-editor.org/info/rfc9114>.
	[MASQUE-ORIGINAL]		[MASQUE-ORIGINAL]
	Schinazi, D., "The MASQUE Protocol", Work in Progress,		Schinazi, D., "The MASQUE Protocol", Work in Progress,
	Internet-Draft, draft-schinazi-masque-00, 28 February		Internet-Draft, draft-schinazi-masque-00, 28 February
	2019, <https://datatracker.ietf.org/doc/html/draft-		2019, <https://datatracker.ietf.org/doc/html/draft-
	schinazi-masque-00>.		schinazi-masque-00>.
	[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure		[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
	QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,		QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
	<https://www.rfc-editor.org/rfc/rfc9001>.		<https://www.rfc-editor.org/info/rfc9001>.
	[SEEMS-LEGIT]		[SEEMS-LEGIT]
	Jackson, D., Cremers, C., Cohn-Gordon, K., and R. Sasse,		Jackson, D., Cremers, C., Cohn-Gordon, K., and R. Sasse,
	"Seems Legit: Automated Analysis of Subtle Attacks on		"Seems Legit: Automated Analysis of Subtle Attacks on
	Protocols That Use Signatures", CCS '19: Proceedings of		Protocols That Use Signatures", CCS '19: Proceedings of
	the 2019 ACM SIGSAC Conference on Computer and		the 2019 ACM SIGSAC Conference on Computer and
	Communications Security, pp. 2165-2180,		Communications Security, pp. 2165-2180,
	DOI 10.1145/3319535.3339813, November 2019,		DOI 10.1145/3319535.3339813, November 2019,
	<https://doi.org/10.1145/3319535.3339813>.		<https://doi.org/10.1145/3319535.3339813>.
End of changes. 33 change blocks.
	49 lines changed or deleted		48 lines changed or added
This html diff was produced by rfcdiff 1.48.