rfc9729v1.md		rfc9729.md
	---		---
	title: The Concealed HTTP Authentication Scheme		title: The Concealed HTTP Authentication Scheme
	docname: draft-ietf-httpbis-unprompted-auth-latest		docname: draft-ietf-httpbis-unprompted-auth-latest
	submissiontype: IETF		submissiontype: IETF
	number: 9729		number: 9729
	date: 2025-01		date: 2025-02
	consensus: true		consensus: true
	v: 3		v: 3
	category: std		category: std
	wg: HTTPBIS		wg: HTTPBIS
	area: "Web and Internet Transport"		area: "Web and Internet Transport"
	keyword:		keyword:
	- secure		- secure
	- tunnels		- tunnels
	- masque		- masque
	- http-ng		- http-ng
	skipping to change at line 43 ¶		skipping to change at line 43 ¶
	uri: https://guardianproject.info		uri: https://guardianproject.info
	-		-
	ins: J. Hoyland		ins: J. Hoyland
	name: Jonathan Hoyland		name: Jonathan Hoyland
	org: Cloudflare Inc.		org: Cloudflare Inc.
	email: jonathan.hoyland@gmail.com		email: jonathan.hoyland@gmail.com
	normative:		normative:
	RFC8792:		RFC8792:
	X.690:		X.690:
			target: https://www.itu.int/rec/T-REC-X.690
	title: "Information technology - ASN.1 encoding Rules: Specification of Basi c Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encodin g Rules (DER)"		title: "Information technology - ASN.1 encoding Rules: Specification of Basi c Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encodin g Rules (DER)"
	date: 2021-02		date: 2021-02
	author:		author:
	org: ITU-T		org: ITU-T
	seriesinfo:		seriesinfo:
	ITU-T: Recommendation X690		ITU-T: Recommendation X690
	ISO/IEC: 8825-1:2021		ISO/IEC: 8825-1:2021
	informative:		informative:
	H2:		H2:
	skipping to change at line 130 ¶		skipping to change at line 131 ¶
	makes the origin probeable as it sends the challenge to unauthenticated		makes the origin probeable as it sends the challenge to unauthenticated
	clients. This document defines a new signature-based authentication scheme that		clients. This document defines a new signature-based authentication scheme that
	is not probeable.		is not probeable.
	## Conventions and Definitions {#conventions}		## Conventions and Definitions {#conventions}
	{::boilerplate bcp14-tagged}		{::boilerplate bcp14-tagged}
	This document uses the notation from {{Section 1.3 of !QUIC=RFC9000}}.		This document uses the notation from {{Section 1.3 of !QUIC=RFC9000}}.
	<!-- [rfced] FYI, we have added the following sentence to Section 1.1
	("Conventions and Definitions") in order to include a citation for RFC 8792 in
	the text. Please let us know of any objections.
	Current:
	Various examples in this document contain long lines that may be folded,
	as described in [RFC8792].
	Various examples in this document contain long lines that may be folded,		Various examples in this document contain long lines that may be folded,
	as described in [RFC8792].		as described in [RFC8792].
	<!--[rfced] Throughout the text, "Concealed HTTP authentication scheme" and
	# The Concealed HTTP Authentication Scheme		# The Concealed HTTP Authentication Scheme
	"Concealed authentication scheme" appear to be used inconsistently. Please
	review these occurrences and let us know if/how they be made consistent.
	Some examples are listed here:
	Original:
	When a client wishes to use the Concealed HTTP authentication scheme
	with a request, it SHALL compute the authentication proof using a TLS
	keying material exporter with the following parameters:
	...
	If a frontend is configured to check the Concealed authentication
	scheme, it will parse the Authorization (or Proxy-Authorization)
	header field.
	# The Concealed Authentication Scheme
	This document defines the "Concealed" HTTP authentication scheme. It uses		This document defines the "Concealed" HTTP authentication scheme. It uses
	asymmetric cryptography. Clients possess a key ID and a public/private key		asymmetric cryptography. Clients possess a key ID and a public/private key
	pair, and origin servers maintain a mapping of authorized key IDs to associated		pair, and origin servers maintain a mapping of authorized key IDs to associated
	public keys.		public keys.
	The client uses a TLS keying material exporter to generate data to be signed		The client uses a TLS keying material exporter to generate data to be signed
	(see {{client}}) then sends the signature using the Authorization (or		(see {{client}}) then sends the signature using the Authorization (or
	Proxy-Authorization) header field (see {{Section 11 of HTTP}}). The signature		Proxy-Authorization) header field (see {{Section 11 of HTTP}}). The signature
	and additional information are exchanged using authentication parameters (see		and additional information are exchanged using authentication parameters (see
	skipping to change at line 195 ¶		skipping to change at line 171 ¶
	Note that TLS 1.3 keying material exporters are defined in {{Section 7.5 of		Note that TLS 1.3 keying material exporters are defined in {{Section 7.5 of
	TLS}}, while TLS 1.2 keying material exporters are defined in		TLS}}, while TLS 1.2 keying material exporters are defined in
	{{!KEY-EXPORT=RFC5705}}.		{{!KEY-EXPORT=RFC5705}}.
	## Key Exporter Context {#context}		## Key Exporter Context {#context}
	The TLS key exporter context is described in {{fig-context}}, using the		The TLS key exporter context is described in {{fig-context}}, using the
	notation from {{Section 1.3 of QUIC}}:		notation from {{Section 1.3 of QUIC}}:
	<!-- [rfced] Please review sourcecode types within the markdown file, and
	let us know if they should be set and/or have been set correctly.
	The current list of preferred values for sourcecode types is available at
	<https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>.
	If the current list does not contain an applicable type, feel free to
	suggest additions for consideration. Note that it is also acceptable
	to leave the sourcecode type not set.
	~~~		~~~
	Signature Algorithm (16),		Signature Algorithm (16),
	Key ID Length (i),		Key ID Length (i),
	Key ID (..),		Key ID (..),
	Public Key Length (i),		Public Key Length (i),
	Public Key (..),		Public Key (..),
	Scheme Length (i),		Scheme Length (i),
	Scheme (..),		Scheme (..),
	Host Length (i),		Host Length (i),
	Host (..),		Host (..),
	skipping to change at line 227 ¶		skipping to change at line 193 ¶
	Realm (..),		Realm (..),
	~~~		~~~
	{: #fig-context title="Key Exporter Context Format"}		{: #fig-context title="Key Exporter Context Format"}
	The key exporter context contains the following fields:		The key exporter context contains the following fields:
	Signature Algorithm:		Signature Algorithm:
	: The signature scheme sent in the `s` Parameter (see {{parameter-s}}).		: The signature scheme sent in the `s` Parameter (see {{parameter-s}}).
	<!-- [rfced] We see that the capitalization of "Key ID" is inconsistent. Please
	let how we should update it.
	Key ID:		Key ID:
	: The key ID sent in the `k` Parameter (see {{parameter-k}}).		: The key ID sent in the `k` Parameter (see {{parameter-k}}).
	Public Key:		Public Key:
	: The public key used by the server to validate the signature provided by the		: The public key used by the server to validate the signature provided by the
	client. Its encoding is described in {{public-key-encoding}}.		client. Its encoding is described in {{public-key-encoding}}.
	Scheme:		Scheme:
	skipping to change at line 258 ¶		skipping to change at line 221 ¶
	Port:		Port:
	: The port for this request, encoded in network byte order. Note that the 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 port for the scheme in use;		is either included in the URI or is the default port for the scheme in use;
	see {{Section 3.2.3 of URI}}.		see {{Section 3.2.3 of URI}}.
	Realm:		Realm:
	: The realm of authentication that is sent in the realm authentication		: The realm of authentication that is sent in the realm authentication
	parameter ({{Section 11.5 of HTTP}}). If the realm authentication parameter is		parameter (see {{Section 11.5 of HTTP}}). If the realm authentication parameter is
	not present, this SHALL be empty. This document does not define a means for the		not present, this SHALL be empty. This document does not define a means for the
	origin to communicate a realm to the client. If a client is not configured to		origin to 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 send the realm		use a specific realm, it SHALL use an empty realm and SHALL NOT send the realm
	authentication parameter.		authentication parameter.
	The Signature Algorithm and Port fields are encoded as unsigned 16-bit integers		The Signature Algorithm and Port fields are encoded as unsigned 16-bit integers
	in network byte order. The Key ID, Public Key, Scheme, Host, and Realm fields		in network byte order. The Key ID, Public Key, Scheme, Host, and Realm fields
	are length-prefixed strings; they are preceded by a Length field that		are length-prefixed strings; they are preceded by a Length field that
	represents their length in bytes. These length fields are encoded using the		represents their length in bytes. These length fields are encoded using the
	variable-length integer encoding from {{Section 16 of QUIC}} and MUST be		variable-length integer encoding from {{Section 16 of QUIC}} and MUST be
	encoded in the minimum number of bytes necessary.		encoded in the minimum number of bytes necessary.
	### Public Key Encoding {#public-key-encoding}		### Public Key Encoding {#public-key-encoding}
	<!--[rfced] As "Signature Algorithm" is being used in a general way and not as
	a field name, may we make it lowercase in this sentence?
	Original:
	The encoding of the public key is determined by the Signature
	Algorithm in use as follows:
	Perhaps:
	The encoding of the public key is determined by the signature
	algorithm in use as follows:
	Both the "Public Key" field of the TLS key exporter context (see above) and the		Both the "Public Key" field of the TLS key exporter context (see above) and the
	`a` Parameter (see {{parameter-a}}) carry the same public key. The encoding of		`a` Parameter (see {{parameter-a}}) carry the same public key. The encoding of
	the public key is determined by the Signature Algorithm in use as follows:		the public key is determined by the signature algorithm in use as follows:
	<!--[rfced] For clarity, may we update "which" to "that" here? It depends on the
	intended meaning, as noted below.
	Original:
	The public key is an RSAPublicKey structure
	[PKCS1] encoded in DER [X.690]. BER encodings which are not DER
	MUST be rejected.
	Perhaps (restrictive "that", meaning some BER encodings):
	The public key is an RSAPublicKey structure
	[PKCS1] encoded in DER [X.690]. BER encodings that are not DER
	MUST be rejected.
	Or (nonrestrictive "which", meaning all BER encodings):
	The public key is an RSAPublicKey structure
	[PKCS1] encoded in DER [X.690]. BER encodings, which are not DER,
	MUST be rejected.
	RSASSA-PSS algorithms:		RSASSA-PSS algorithms:
	: The public key is an RSAPublicKey structure {{!PKCS1=RFC8017}} encoded in DER		: The public key is an RSAPublicKey structure {{!PKCS1=RFC8017}} encoded in DER
	{{X.690}}. BER encodings which are not DER MUST be rejected.		{{X.690}}. BER encodings that are not DER MUST be rejected.
	ECDSA algorithms:		ECDSA algorithms:
	: The public key is an UncompressedPointRepresentation structure defined in		: The public key is an UncompressedPointRepresentation structure defined in
	{{Section 4.2.8.2 of TLS}}, using the curve specified by the SignatureScheme.		{{Section 4.2.8.2 of TLS}}, using the curve specified by the SignatureScheme.
	EdDSA algorithms:		EdDSA algorithms:
	: The public key is the byte string encoding defined in {{!EdDSA=RFC8032}}.		: The public key is the byte string encoding defined in {{!EdDSA=RFC8032}}.
	skipping to change at line 412 ¶		skipping to change at line 344 ¶
	~~~ abnf		~~~ abnf
	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"
	~~~		~~~
	{: #fig-param title="Authentication Parameter Value ABNF"}		{: #fig-param title="Authentication Parameter Value ABNF"}
	## The k Parameter {#parameter-k}		## The k Parameter {#parameter-k}
	The REQUIRED "k" (key ID) Parameter is a byte sequence that identifies which		The REQUIRED "k" (key ID) Parameter is a byte sequence that identifies which
	key the client wishes to use to authenticate. This is used by the backend to		key the client wishes to use to authenticate. This is used by the backend to
	point to an entry in a server-side database of known keys; see {{backend}}.		point to an entry in a server-side database of known keys (see {{backend}}).
	## The a Parameter {#parameter-a}		## The a Parameter {#parameter-a}
	The REQUIRED "a" (public key) Parameter is a byte sequence that specifies the		The REQUIRED "a" (public key) Parameter is a byte sequence that specifies the
	public key used by the server to validate the signature provided by the client.		public key used by the server to validate the signature provided by the client.
	This avoids key confusion issues (see {{SEEMS-LEGIT}}). The encoding of the		This avoids key confusion issues (see {{SEEMS-LEGIT}}). The encoding of the
	public key is described in {{public-key-encoding}}.		public key is described in {{public-key-encoding}}.
	## The p Parameter {#parameter-p}		## The p Parameter {#parameter-p}
	The REQUIRED "p" (proof) Parameter is a byte sequence that specifies the proof		The REQUIRED "p" (proof) Parameter is a byte sequence that specifies the proof
	that the client provides to attest to possessing the credential that matches		that the client provides to attest to possessing the credential that matches
	its key ID.		its key ID.
	## The s Parameter {#parameter-s}		## The s Parameter {#parameter-s}
	The REQUIRED "s" (signature) Parameter is an integer that specifies the		The REQUIRED "s" (signature scheme) Parameter is an integer that specifies the
	signature scheme used to compute the proof transmitted in the `p` Parameter.		signature scheme used to compute the proof transmitted in the `p` Parameter.
	Its value is an integer between 0 and 65535 inclusive from the IANA "TLS		Its value is an integer between 0 and 65535 inclusive from the IANA "TLS
	SignatureScheme" registry maintained at		SignatureScheme" registry maintained at
	<[](https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-sig naturescheme)>.		<[](https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-sig naturescheme)>.
	## The v Parameter {#parameter-v}		## The v Parameter {#parameter-v}
	The REQUIRED "v" (verification) Parameter is a byte sequence that specifies the		The REQUIRED "v" (verification) Parameter is a byte sequence that specifies the
	verification that the client provides to attest to possessing the key exporter		verification that the client provides to attest to possessing the key exporter
	output (see {{output}} for details). This avoids issues with signature schemes		output (see {{output}} for details). This avoids issues with signature schemes
	where certain keys can generate signatures that are valid for multiple inputs		where certain keys can generate signatures that are valid for multiple inputs
	(see {{SEEMS-LEGIT}}).		(see {{SEEMS-LEGIT}}).
	# Example {#example}		# Example {#example}
	<!-- [rfced] We having difficulty parsing the following sentence.		For example, a client using the key ID "basement" and the signature algorithm
	Does the key ID authenticate or does the client?		Ed25519 {{?ED25519=RFC8410}} could produce the following header field:
	Current:
	For example, the key ID "basement" authenticating using Ed25519
	[ED25519] could produce the following header field
	Perhaps:
	For example, a client authenticating with the key ID "basement"
	and using Ed25519 [ED25519] could produce the following header
	field
	For example, the key ID "basement" authenticating using Ed25519
	{{?ED25519=RFC8410}} could produce the following header field:
	~~~ http-message		~~~ http-message
	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\
	skipping to change at line 492 ¶		skipping to change at line 411 ¶
	accepted key identifiers and public keys.		accepted key identifiers and public keys.
	In most deployments, we expect both the frontend and backend roles to be		In most deployments, we expect both the frontend and backend roles to be
	implemented in a single HTTP origin server (as defined in {{Section 3.6 of		implemented in a single HTTP origin server (as defined in {{Section 3.6 of
	HTTP}}). However, these roles can be split such that the frontend is an HTTP		HTTP}}). However, these roles can be split such that the frontend is an HTTP
	gateway (as defined in {{Section 3.7 of HTTP}}) and the backend is an HTTP		gateway (as defined in {{Section 3.7 of HTTP}}) and the backend is an HTTP
	origin server.		origin server.
	## Frontend Handling		## Frontend Handling
	If a frontend is configured to check the Concealed authentication scheme, it		If a frontend is configured to check the Concealed HTTP authentication scheme, i t
	will parse the Authorization (or Proxy-Authorization) header field. If the		will parse the Authorization (or Proxy-Authorization) header field. If the
	authentication scheme is set to "Concealed", the frontend MUST validate that		authentication scheme is set to "Concealed", the frontend MUST validate that
	all the required authentication parameters are present and can be parsed		all the required authentication parameters are present and can be parsed
	correctly as defined in {{auth-params}}. If any parameter is missing or fails		correctly as defined in {{auth-params}}. If any parameter is missing or fails
	to parse, the frontend MUST ignore the entire Authorization (or		to parse, the frontend MUST ignore the entire Authorization (or
	Proxy-Authorization) header field.		Proxy-Authorization) header field.
	The frontend then uses the data from these authentication parameters to compute		The frontend then uses the data from these authentication parameters to compute
	the key exporter output, as defined in {{output}}. The frontend then shares the		the key exporter output, as defined in {{output}}. The frontend then shares the
	header field and the key exporter output with the backend.		header field and the key exporter output with the backend.
	## Communication Between Frontend and Backend		## Communication Between Frontend and Backend
	If the frontend and backend roles are implemented in the same machine, this can		If the frontend and backend roles are implemented in the same machine, this can
	be handled by a simple function call.		be handled by a simple function call.
	<!-- [rfced] RFC 8941 has been obsoleted by RFC 9651. May we replace RFC
	8941 with RFC 9651?
	If the roles are split between two separate HTTP servers, then the backend		If the roles are split between two separate HTTP servers, then the backend
	won't be able to directly access the TLS keying material exporter from the TLS		won't be able to directly access the TLS keying material exporter from the TLS
	connection between the client and frontend, so the frontend needs to explicitly		connection between the client and frontend, so the frontend needs to explicitly
	send it. This document defines the "Concealed-Auth-Export" request header field		send it. This document defines the "Concealed-Auth-Export" request header field
	for this purpose. The Concealed-Auth-Export header field's value is a		for this purpose. The Concealed-Auth-Export header field's value is a
	Structured Field Byte Sequence (see {{Section 3.3.5 of		Structured Field Byte Sequence (see {{Section 3.3.5 of
	!STRUCTURED-FIELDS=RFC8941}}) that contains the 48-byte key exporter output		!STRUCTURED-FIELDS=RFC9651}}) that contains the 48-byte key exporter output
	(see {{output}}), without any parameters. Note that Structured Field Byte		(see {{output}}), without any parameters. Note that Structured Field Byte
	Sequences are encoded using the non-URL-safe variant of base64. For example:		Sequences are encoded using the non-URL-safe variant of base64. For example:
	~~~ http-message		~~~ http-message
	NOTE: '\' line wrapping per RFC 8792		NOTE: '\' line wrapping per RFC 8792
	Concealed-Auth-Export: :VGhpc+BleGFtcGxlIFRMU/BleHBvcn\		Concealed-Auth-Export: :VGhpc+BleGFtcGxlIFRMU/BleHBvcn\
	Rlc+BvdXRwdXQ/aXMgNDggYnl0ZXMgI/+h:		Rlc+BvdXRwdXQ/aXMgNDggYnl0ZXMgI/+h:
	~~~		~~~
	{: #fig-int-hdr-example title="Example Concealed-Auth-Export Header Field"}		{: #fig-int-hdr-example title="Example Concealed-Auth-Export Header Field"}
	skipping to change at line 610 ¶		skipping to change at line 525 ¶
	{{!TLS=RFC8446}}. This includes any use of HTTP over TLS as typically used for		{{!TLS=RFC8446}}. This includes any use of HTTP over TLS as typically used for
	HTTP/2 {{H2}}, or HTTP/3 {{H3}} where the transport protocol uses TLS as its		HTTP/2 {{H2}}, or HTTP/3 {{H3}} where the transport protocol uses TLS as its
	authentication and key exchange mechanism {{?QUIC-TLS=RFC9001}}.		authentication and key exchange mechanism {{?QUIC-TLS=RFC9001}}.
	Because the TLS keying material exporter is only secure for authentication when		Because the TLS keying material exporter is only secure for authentication when
	it is uniquely bound to the TLS session {{!RFC7627}}, the Concealed		it is uniquely bound to the TLS session {{!RFC7627}}, the Concealed
	authentication scheme requires either one of the following properties:		authentication scheme requires either one of 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}}.
	<!-- [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.
	* The TLS version in use is 1.2, and the extended master secret extension		* The TLS version in use is 1.2, and the extended master secret extension
	{{RFC7627}} has been negotiated.		{{RFC7627}} has been negotiated.
	Clients MUST NOT use the Concealed authentication scheme on connections that do		Clients MUST NOT use the Concealed HTTP authentication scheme on connections tha t do
	not meet one of the two properties above. If a server receives a request that		not meet one of the two properties above. If a server receives a request that
	uses this authentication scheme on a connection that meets neither of the above		uses this authentication scheme on a connection that meets neither of the above
	properties, the server MUST treat the request as if the authentication were not		properties, the server MUST treat the request as if the authentication were not
	present.		present.
	# Security Considerations {#security}		# Security Considerations {#security}
	The Concealed HTTP authentication scheme allows a client to authenticate to an		The Concealed HTTP authentication scheme allows a client to authenticate to an
	origin server while guaranteeing freshness and without the need for the server		origin server while guaranteeing freshness and without the need for the server
	to transmit a nonce to the client. This allows the server to accept		to transmit a nonce to the client. This allows the server to accept
	skipping to change at line 747 ¶		skipping to change at line 656 ¶
	{:numbered="false"}		{:numbered="false"}
	The authors would like to thank many members of the IETF community, as this		The authors would like to thank many members of the IETF community, as this
	document is the fruit of many hallway conversations. In particular, the authors		document is the fruit of many hallway conversations. In particular, the authors
	would like to thank {{{David Benjamin}}}, {{{Reese Enghardt}}}, {{{Nick		would like to thank {{{David Benjamin}}}, {{{Reese Enghardt}}}, {{{Nick
	Harper}}}, {{{Dennis Jackson}}}, {{{Ilari Liusvaara}}}, {{{François Michel}}},		Harper}}}, {{{Dennis Jackson}}}, {{{Ilari Liusvaara}}}, {{{François Michel}}},
	{{{Lucas Pardue}}}, {{{Justin Richer}}}, {{{Ben Schwartz}}}, {{{Martin		{{{Lucas Pardue}}}, {{{Justin Richer}}}, {{{Ben Schwartz}}}, {{{Martin
	Thomson}}}, and {{{Chris A. Wood}}} for their reviews and contributions. The		Thomson}}}, and {{{Chris A. Wood}}} for their reviews and contributions. The
	mechanism described in this document was originally part of the first iteration		mechanism described in this document was originally part of the first iteration
	of MASQUE {{?MASQUE-ORIGINAL=I-D.schinazi-masque-00}}.		of MASQUE {{?MASQUE-ORIGINAL=I-D.schinazi-masque-00}}.
	<!--[rfced] References. May we add the following URL to this reference for the e
	ase of the reader?
	https://www.itu.int/rec/T-REC-X.690
	Current:
	[X.690] ITU-T, "Information technology - ASN.1 encoding Rules:
	Specification of Basic Encoding Rules (BER), Canonical
	Encoding Rules (CER) and Distinguished Encoding Rules
	(DER)", ITU-T Recommendation X690, ISO/IEC 8825-1:2021,
	February 2021.
End of changes. 20 change blocks.
	95 lines changed or deleted		12 lines changed or added
This html diff was produced by rfcdiff 1.48.