rfc9799v1.txt		rfc9799.txt
	Internet Engineering Task Force (IETF) Q. Misell, Ed.		Internet Engineering Task Force (IETF) Q Misell, Ed.
	Request for Comments: 9799 AS207960		Request for Comments: 9799 AS207960
	Category: Standards Track June 2025		Category: Standards Track June 2025
	ISSN: 2070-1721		ISSN: 2070-1721
	Automated Certificate Management Environment (ACME) Extensions for		Automated Certificate Management Environment (ACME) Extensions for
	".onion" Special-Use Domain Names		".onion" Special-Use Domain Names
	Abstract		Abstract
	This document defines extensions to the Automated Certificate		This document defines extensions to the Automated Certificate
	Management Environment (ACME) to allow for the automatic issuance of		Management Environment (ACME) to allow for the automatic issuance of
	certificates to Tor hidden services (".onion" Special-Use Domain		certificates to Tor Hidden Services (".onion" Special-Use Domain
	Names).		Names).
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This is an Internet Standards Track document.
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on		Internet Engineering Steering Group (IESG). Further information on
	skipping to change at line 54 ¶		skipping to change at line 54 ¶
	in the Revised BSD License.		in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction		1. Introduction
	1.1. Requirements Language		1.1. Requirements Language
	2. Identifier		2. Identifier
	3. Identifier Validation Challenges		3. Identifier Validation Challenges
	3.1. Existing Challenges		3.1. Existing Challenges
	3.1.1. Existing: "dns-01" Challenge		3.1.1. Existing: "dns-01" Challenge
	3.1.2. Existing: "http-01" Challenge		3.1.2. Existing: http-01 Challenge
	3.1.3. Existing "tls-alpn-01" Challenge		3.1.3. Existing tls-alpn-01 Challenge
	3.2. New "onion-csr-01" Challenge		3.2. New onion-csr-01 Challenge
	4. Client Authentication to Hidden Services		4. Client Authentication to Hidden Services
	5. ACME over Hidden Services		5. ACME over Hidden Services
	6. Certification Authority Authorization (CAA)		6. Certification Authority Authorization (CAA)
	6.1. Relevant Resource Record Set		6.1. Relevant Resource Record Set
	6.2. When to Check CAA		6.2. When to Check CAA
	6.3. Preventing Mis-Issuance by Unknown CAs		6.3. Preventing Mis-Issuance by Unknown CAs
	6.4. Alternative In-Band Presentation of CAA		6.4. Alternative In-Band Presentation of CAA
	6.4.1. ACME Servers Requiring In-Band CAA		6.4.1. ACME Servers Requiring In-Band CAA
	6.4.2. Example In-Band CAA		6.4.2. Example In-Band CAA
	7. IANA Considerations		7. IANA Considerations
	7.1. Validation Methods		7.1. Validation Methods
	7.2. Error Types		7.2. Error Types
	7.3. Directory Metadata Fields		7.3. Directory Metadata Fields
	8. Security Considerations		8. Security Considerations
	8.1. Security of the "onion-csr-01" Challenge		8.1. Security of the onion-csr-01 Challenge
	8.2. Use of the "dns" Identifier Type		8.2. Use of the "dns" Identifier Type
	8.2.1. "http-01" Challenge		8.2.1. http-01 Challenge
	8.2.2. "tls-alpn-01" Challenge		8.2.2. tls-alpn-01 Challenge
	8.2.3. "dns-01" Challenge		8.2.3. dns-01 Challenge
	8.3. Key Authorization with "onion-csr-01"		8.3. Key Authorization with onion-csr-01
	8.4. Use of Tor for Domains That Are Not ".onion"		8.4. Use of Tor for Domains That Are Not ".onion"
	8.5. Redirects with "http-01"		8.5. Redirects with http-01
	8.6. Security of CAA Records		8.6. Security of CAA Records
	8.7. In-Band CAA		8.7. In-Band CAA
	8.8. Access of the Tor Network		8.8. Access of the Tor Network
	8.9. Anonymity of the ACME Client		8.9. Anonymity of the ACME Client
	8.9.1. Avoid Unnecessary Certificates		8.9.1. Avoid Unnecessary Certificates
	8.9.2. Obfuscate Subscriber Information		8.9.2. Obfuscate Subscriber Information
	8.9.3. Separate ACME Account Keys		8.9.3. Separate ACME Account Keys
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	9.2. Informative References		9.2. Informative References
	skipping to change at line 128 ¶		skipping to change at line 128 ¶
	"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.
	2. Identifier		2. Identifier
	[RFC8555] defines the "dns" identifier type. This identifier type		[RFC8555] defines the "dns" identifier type. This identifier type
	MUST be used when requesting a certificate for a ".onion" Special-Use		MUST be used when requesting a certificate for a ".onion" Special-Use
	Domain Name. The value of the identifier MUST be the textual		Domain Name. The value of the identifier MUST be the textual
	representation as defined in the "Special Hostnames in Tor - .onion"		representation as defined in the "Special Hostnames in Tor - .onion"
	(https://spec.torproject.org/address-spec.html#onion) section of		section of [tor-spec]. The value MAY include subdomain labels.
	[tor-spec]. The value MAY include subdomain labels. Version 2		Version 2 addresses [tor-rend-spec-v2] MUST NOT be used as these are
	addresses [tor-rend-spec-v2] MUST NOT be used as these are now		now considered insecure.
	considered insecure.
	Example identifiers (line breaks have been added for readability		Example identifiers (line breaks have been added for readability
	only):		only):
	{		{
	"type": "dns",		"type": "dns",
	"value": "bbcweb3hytmzhn5d532owbu6oqadra5z3ar726v		"value": "bbcweb3hytmzhn5d532owbu6oqadra5z3ar726v
	q5kgwwn6aucdccrad.onion"		q5kgwwn6aucdccrad.onion"
	}		}
	skipping to change at line 162 ¶		skipping to change at line 161 ¶
	(see Appendix B.2 of [cabf-br]). This document incorporates these		(see Appendix B.2 of [cabf-br]). This document incorporates these
	methods into ACME challenges.		methods into ACME challenges.
	3.1. Existing Challenges		3.1. Existing Challenges
	3.1.1. Existing: "dns-01" Challenge		3.1.1. Existing: "dns-01" Challenge
	The existing "dns-01" challenge MUST NOT be used to validate ".onion"		The existing "dns-01" challenge MUST NOT be used to validate ".onion"
	Special-Use Domain Names as these domains are not part of the DNS.		Special-Use Domain Names as these domains are not part of the DNS.
	3.1.2. Existing: "http-01" Challenge		3.1.2. Existing: http-01 Challenge
	The "http-01" challenge, as defined in Section 8.3 of [RFC8555], MAY		The http-01 challenge, as defined in Section 8.3 of [RFC8555], MAY be
	be used to validate a ".onion" Special-Use Domain Name with the		used to validate a ".onion" Special-Use Domain Name with the
	modifications defined in this document, namely those described in		modifications defined in this document, namely those described in
	Sections 4 and 6.		Sections 4 and 6.
	The ACME server SHOULD follow redirects. Note that these MAY be		The ACME server SHOULD follow redirects. Note that these MAY be
	redirects to services that are not ".onion" and that the server		redirects to services that are not ".onion" and that the server
	SHOULD honor these. For example, clients might use redirects so that		SHOULD honor these. For example, clients might use redirects so that
	the response can be provided by a centralized certificate management		the response can be provided by a centralized certificate management
	server. See Section 10.2 of [RFC8555] for security considerations on		server. See Section 10.2 of [RFC8555] for security considerations on
	why a server might not want to follow redirects.		why a server might not want to follow redirects.
	3.1.3. Existing "tls-alpn-01" Challenge		3.1.3. Existing tls-alpn-01 Challenge
	The "tls-alpn-01" challenge, as defined in [RFC8737], MAY be used to		The tls-alpn-01 challenge, as defined in [RFC8737], MAY be used to
	validate a ".onion" Special-Use Domain Name with the modifications		validate a ".onion" Special-Use Domain Name with the modifications
	defined in this document, namely those described in Sections 4 and 6.		defined in this document, namely those described in Sections 4 and 6.
	3.2. New "onion-csr-01" Challenge		3.2. New onion-csr-01 Challenge
	The two ACME-defined methods allowed by CA/BF described in Sections		The two ACME-defined methods allowed by CA/BF described in Sections
	3.1.2 and 3.1.3 ("http-01" and "tls-alpn-01") do not allow issuance		3.1.2 and 3.1.3 (http-01 and tls-alpn-01) do not allow issuance of
	of wildcard certificates. A ".onion" Special-Use Domain Name can		wildcard certificates. A ".onion" Special-Use Domain Name can have
	have subdomains (just like any other domain in the DNS), and a site		subdomains (just like any other domain in the DNS), and a site
	operator may find it useful to have one certificate for all virtual		operator may find it useful to have one certificate for all virtual
	hosts on their site. This new validation method incorporates the		hosts on their site. This new validation method incorporates the
	specially signed Certificate Signing Request (CSR) (as defined by		specially signed Certificate Signing Request (CSR) (as defined by
	Appendix B.2.b of [cabf-br]) into ACME to allow for the issuance of		Appendix B.2.b of [cabf-br]) into ACME to allow for the issuance of
	wildcard certificates.		wildcard certificates.
	To this end, a new challenge called "onion-csr-01" is defined, with		To this end, a new challenge called onion-csr-01 is defined, with the
	the following fields:		following fields:
	type (required, string): The string "onion-csr-01".		type (required, string): The string onion-csr-01.
	nonce (required, string): A Base64-encoded nonce [RFC4648] including		nonce (required, string): A Base64-encoded nonce [RFC4648] including
	padding characters. It MUST contain at least 64 bits of entropy.		padding characters. It MUST contain at least 64 bits of entropy.
	A response generated using this nonce MUST NOT be accepted by the		A response generated using this nonce MUST NOT be accepted by the
	ACME server if the nonce used was generated by the server more		ACME server if the nonce used was generated by the server more
	than 30 days prior (as per Appendix B.2.b of [cabf-br]).		than 30 days prior (as per Appendix B.2.b of [cabf-br]).
	authKey (optional, object): The ACME server's Ed25519 public key		authKey (optional, object): The ACME server's Ed25519 public key
	encoded as per [RFC8037]. This is further defined in Section 4.		encoded as per [RFC8037]. This is further defined in Section 4.
	{		{
	"type": "onion-csr-01",		"type": "onion-csr-01",
	"url": "https://acme-server.example.onion/acme/chall/bbc625c5",		"url": "https://acme-server.example.onion/acme/chall/bbc625c5",
	"status": "pending",		"status": "pending",
	"nonce": "bI6/MRqV4gw=",		"nonce": "bI6/MRqV4gw=",
	"authKey": { ... }		"authKey": { ... }
	}		}
	An "onion-csr-01" challenge MUST NOT be used to issue certificates		An onion-csr-01 challenge MUST NOT be used to issue certificates for
	for Special-Use Domain Names that are not ".onion".		Special-Use Domain Names that are not ".onion".
	Clients prove control over the key associated with the ".onion"		Clients prove control over the key associated with the ".onion"
	service by generating a CSR [RFC2986] with the following additional		service by generating a Certificate Request (CSR) [RFC2986] with the
	extension attributes and signing it with the private key of the		following additional extension attributes and signing it with the
	".onion" Special-Use Domain Name:		private key of the ".onion" Special-Use Domain Name:
	* A caSigningNonce attribute containing the nonce provided in the		* A caSigningNonce attribute containing the nonce provided in the
	challenge. This MUST be raw bytes and not the base64 encoded		challenge. This MUST be raw bytes and not the base64 encoded
	value provided in the challenge object.		value provided in the challenge object.
	* An applicantSigningNonce attribute containing a nonce generated by		* An applicantSigningNonce attribute containing a nonce generated by
	the client. This MUST have at least 64 bits of entropy. This		the client. This MUST have at least 64 bits of entropy. This
	MUST be raw bytes.		MUST be raw bytes.
	These additional attributes have the following format		These additional attributes have the following format
	skipping to change at line 276 ¶		skipping to change at line 275 ¶
	does not include headers, it is different from Privacy Enhanced		does not include headers, it is different from Privacy Enhanced
	Mail (PEM).)		Mail (PEM).)
	POST /acme/chall/bbc625c5		POST /acme/chall/bbc625c5
	Host: acme-server.example.onion		Host: acme-server.example.onion
	Content-Type: application/jose+json		Content-Type: application/jose+json
	{		{
	"protected": base64url({		"protected": base64url({
	"alg": "ES256",		"alg": "ES256",
	"kid": "https://acme-server.example.onion/acme/acct/evOfKhNU60wg",		"kid":
			"https://acme-server.example.onion/acme/acct/evOfKhNU60wg",
	"nonce": "UQI1PoRi5OuXzxuX7V7wL0",		"nonce": "UQI1PoRi5OuXzxuX7V7wL0",
	"url": "https://acme-server.example.onion/acme/chall/bbc625c5"		"url": "https://acme-server.example.onion/acme/chall/bbc625c5"
	}),		}),
	"payload": base64url({		"payload": base64url({
	"csr": "MIIBPTCBxAIBADBFMQ...FS6aKdZeGsysoCo4H9P"		"csr": "MIIBPTCBxAIBADBFMQ...FS6aKdZeGsysoCo4H9P"
	}),		}),
	"signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4"		"signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4"
	}		}
	When presented with the CSR, the server verifies it in the following		When presented with the CSR, the server verifies it in the following
	skipping to change at line 308 ¶		skipping to change at line 308 ¶
	the nonce provided to the client.		the nonce provided to the client.
	5. The applicantSigningNonce attribute is present and contains at		5. The applicantSigningNonce attribute is present and contains at
	least 64 bits of entropy.		least 64 bits of entropy.
	If all of the above are successful then validation succeeds,		If all of the above are successful then validation succeeds,
	otherwise it has failed.		otherwise it has failed.
	4. Client Authentication to Hidden Services		4. Client Authentication to Hidden Services
	Some hidden services do not wish to be accessible to the entire Tor		Some Hidden Services do not wish to be accessible to the entire Tor
	network, and so they encrypt their hidden service descriptor with the		network, and so they encrypt their Hidden Service Descriptor with the
	keys of clients authorized to connect. Without a way for the CA to		keys of clients authorized to connect. Without a way for the CA to
	signal what key it will use to connect, these services will not be		signal what key it will use to connect, these services will not be
	able to obtain a certificate using http-01 or tls-alpn-01, nor		able to obtain a certificate using http-01 or tls-alpn-01, nor
	enforce CAA with any validation method.		enforce CAA with any validation method.
	To this end, an additional field in the challenge object is defined		To this end, an additional field in the challenge object is defined
	to allow the ACME server to advertise the Ed25519 public key it will		to allow the ACME server to advertise the Ed25519 public key it will
	use (as per the "Authentication during the introduction phase"		use (as per the "Authentication during the introduction phase"
	(https://spec.torproject.org/rend-spec/introduction-		section of [tor-spec]) to authenticate itself when retrieving the
	protocol.html#INTRO-AUTH) section of [tor-spec]) to authenticate		Hidden Service Descriptor.
	itself when retrieving the hidden service descriptor.
	authKey (optional, object): The ACME server's Ed25519 public key		authKey (optional, object): The ACME server's Ed25519 public key
	encoded as per [RFC8037].		encoded as per [RFC8037].
	ACME servers MUST NOT use the same public key with multiple hidden		ACME servers MUST NOT use the same public key with multiple Hidden
	services. ACME servers MAY reuse public keys for re-validation of		Services. ACME servers MAY reuse public keys for re-validation of
	the same hidden service.		the same Hidden Service.
	There is no method to communicate to the CA that client		There is no method to communicate to the CA that client
	authentication is necessary; instead, the ACME server MUST attempt to		authentication is necessary; instead, the ACME server MUST attempt to
	calculate its CLIENT-ID as per the "Client behavior"		calculate its CLIENT-ID as per the "Client behavior" section of
	(https://spec.torproject.org/rend-spec/hsdesc-encrypt.html#FIRST-		[tor-spec]. If no auth-client line in the First Layer Hidden Service
	LAYER-CLIENT-BEHAVIOR) section of [tor-spec]. If no auth-client line		Descriptor matches the computed client-id, then the server MUST
	in the first layer hidden service descriptor matches the computed		assume that the Hidden Service does not require client authentication
	client-id, then the server MUST assume that the hidden service does		and proceed accordingly.
	not require client authentication and proceed accordingly.
	In the case in which the Ed25519 public key is novel to the client,		In the case in which the Ed25519 public key is novel to the client,
	it will have to resign and republish its hidden service descriptor.		it will have to resign and republish its Hidden Service Descriptor.
	It MUST wait some (indeterminate) amount of time for the new		It MUST wait some (indeterminate) amount of time for the new
	descriptor to propagate the Tor hidden service directory servers		descriptor to propagate the Tor Hidden Service directory servers
	before proceeding with responding to the challenge. This should take		before proceeding with responding to the challenge. This should take
	no more than a few minutes. This specification does not set a fixed		no more than a few minutes. This specification does not set a fixed
	time as changes in the operation of the Tor network can affect this		time as changes in the operation of the Tor network can affect this
	propagation time in the future. ACME servers MUST NOT expire		propagation time in the future. ACME servers MUST NOT expire
	challenges before a reasonable time to allow publication of the new		challenges before a reasonable time to allow publication of the new
	descriptor. It is RECOMMENDED the server allow at least 30 minutes;		descriptor. It is RECOMMENDED the server allow at least 30 minutes;
	however, it is entirely up to operator preference.		however, it is entirely up to operator preference.
	5. ACME over Hidden Services		5. ACME over Hidden Services
	A CA offering certificates to ".onion" Special-Use Domain Names		A CA offering certificates to ".onion" Special-Use Domain Names
	SHOULD make their ACME server available as a Tor hidden service.		SHOULD make their ACME server available as a Tor Hidden Service.
	ACME clients SHOULD also support connecting to ACME servers over Tor,		ACME clients SHOULD also support connecting to ACME servers over Tor,
	regardless of their support of "onion-csr-01", as their existing		regardless of their support of onion-csr-01, as their existing
	"http-01" and "tls-alpn-01" implementations could be used to obtain		http-01 and tls-alpn-01 implementations could be used to obtain
	certificates for ".onion" Special-Use Domain Names.		certificates for ".onion" Special-Use Domain Names.
	6. Certification Authority Authorization (CAA)		6. Certification Authority Authorization (CAA)
	".onion" Special-Use Domain Names are not part of the DNS; as such, a		".onion" Special-Use Domain Names are not part of the DNS; as such, a
	variation on CAA [RFC8659] is necessary to allow restrictions to be		variation on CAA [RFC8659] is necessary to allow restrictions to be
	placed on certificate issuance.		placed on certificate issuance.
	To this end, a new field is added to the second layer hidden service		To this end, a new field is added to the Second Layer Hidden Service
	descriptor, as defined in the "Second layer plaintext format"		Descriptor, as defined in the "Second layer plaintext format" section
	(https://spec.torproject.org/rend-spec/hsdesc-encrypt.html#second-		of [tor-spec] with the following format (defined using the notation
	layer-plaintext) section of [tor-spec] with the following format		from the "netdoc document meta-format" section of [tor-spec]):
	(defined using the notation from the "netdoc document meta-format"
	(https://spec.torproject.org/dir-spec/netdoc.html) section of
	[tor-spec]):
	"caa" SP flags SP tag SP value NL		"caa" SP flags SP tag SP value NL
	[Any number of times]		[Any number of times]
	The presentation format is provided above purely for the convenience		The presentation format is provided above purely for the convenience
	of the reader and implementors: the canonical version remains that		of the reader and implementors: the canonical version remains that
	defined in Section 4.1.1 of [RFC8659], or future updates to the same.		defined in Section 4.1.1 of [RFC8659], or future updates to the same.
	The contents of "flags", "tag", and "value" are as per Section 4.1.1		The contents of "flags", "tag", and "value" are as per Section 4.1.1
	of [RFC8659]. Multiple CAA records MAY be present, as is the case in		of [RFC8659]. Multiple CAA records MAY be present, as is the case in
	the DNS. CAA records in a hidden service descriptor are to be		the DNS. CAA records in a Hidden Service Descriptor are to be
	treated the same by CAs as if they had been in the DNS for the		treated the same by CAs as if they had been in the DNS for the
	".onion" Special-Use Domain Name.		".onion" Special-Use Domain Name.
	A hidden service's second layer descriptor using CAA could look		A Hidden Service's Second Layer Descriptor using CAA could look
	something like the following (additional line breaks have been added		something like the following (additional line breaks have been added
	for readability):		for readability):
	create2-formats 2		create2-formats 2
	single-onion-service		single-onion-service
	caa 128 issue "acmeforonions.example;validationmethods=onion-csr-01"		caa 128 issue "acmeforonions.example;validationmethods=onion-csr-01"
	caa 0 iodef "mailto:security@example.com"		caa 0 iodef "mailto:security@example.com"
	introduction-point AwAGsAk5nSMpAhRqhMHbTFCTSlfhP8f5PqUhe6DatgMgk7kSL3		introduction-point AwAGsAk5nSMpAhRqhMHbTFCTSlfhP8f5PqUhe6DatgMgk7kSL3
	KHCZUZ3C6tXDeRfM9SyNY0DlgbF8q+QSaGKCs=		KHCZUZ3C6tXDeRfM9SyNY0DlgbF8q+QSaGKCs=
	...		...
	skipping to change at line 430 ¶		skipping to change at line 425 ¶
	* b.c.onion		* b.c.onion
	* c.d.onion		* c.d.onion
	* e.c.d.onion		* e.c.d.onion
	* a.b.onion		* a.b.onion
	6.2. When to Check CAA		6.2. When to Check CAA
	If the hidden service has client authentication enabled, then it will		If the Hidden Service has client authentication enabled, then it will
	be impossible for the ACME server to decrypt the second layer		be impossible for the ACME server to decrypt the Second Layer Hidden
	descriptor to read the CAA records until the ACME server's public key		Service Descriptor to read the CAA records until the ACME server's
	has been added to the first layer descriptor. To this end, an ACME		public key has been added to the First Layer Hidden Service
	server MUST wait until the client responds to an authorization before		Descriptor. To this end, an ACME server MUST wait until the client
	checking the CAA and treat this response as an indication that their		responds to an authorization before checking the CAA and treat this
	public key has been added and that the ACME server will be able to		response as an indication that their public key has been added and
	decrypt the second layer descriptor.		that the ACME server will be able to decrypt the Second Layer Hidden
			Service Descriptor.
	6.3. Preventing Mis-Issuance by Unknown CAs		6.3. Preventing Mis-Issuance by Unknown CAs
	In the case of a hidden service requiring client authentication, the		In the case of a Hidden Service requiring client authentication, the
	CA will be unable to read the hidden service's CAA records without		CA will be unable to read the hidden service's CAA records without
	the hidden service trusting an ACME server's public key -- as the CAA		the Hidden Service trusting an ACME server's public key -- as the CAA
	records are in the second layer descriptor. A method is necessary to		records are in the Second Layer Hidden Service Descriptor. A method
	signal that there are CAA records present (but not reveal their		is necessary to signal that there are CAA records present (but not
	contents, which, in certain circumstances, would unwantedly disclose		reveal their contents, which, in certain circumstances, would
	information about the hidden service operator).		unwantedly disclose information about the Hidden Service operator).
	To this end, a new field is added to the first layer hidden service		To this end, a new field is added to the First Layer Hidden Service
	descriptor in the "First layer plaintext format"		Descriptor in the "First layer plaintext format" section of
	(https://spec.torproject.org/rend-spec/hsdesc-encrypt.html#first-		[tor-spec] with the following format (defined using the notation from
	layer-plaintext) section of [tor-spec] with the following format		the "netdoc document meta-format" section of [tor-spec]):
	(defined using the notation from the "netdoc document meta-format"
	(https://spec.torproject.org/dir-spec/netdoc.html) section of
	[tor-spec]):
	"caa-critical" NL		"caa-critical" NL
	[At most once]		[At most once]
	If an ACME server encounters this flag, it MUST NOT proceed with		If an ACME server encounters this flag, it MUST NOT proceed with
	issuance until it can decrypt and parse the CAA records from the		issuance until it can decrypt and parse the CAA records from the
	second layer descriptor.		Second Layer Hidden Service Descriptor.
	6.4. Alternative In-Band Presentation of CAA		6.4. Alternative In-Band Presentation of CAA
	An ACME server might be unwilling to operate the infrastructure		An ACME server might be unwilling to operate the infrastructure
	required to fetch, decode, and verify Tor hidden service descriptors		required to fetch, decode, and verify Tor Hidden Service Descriptors
	in order to check CAA records. To this end a method to signal CAA		in order to check CAA records. To this end a method to signal CAA
	policies in-band of ACME is defined.		policies in-band of ACME is defined.
	If a hidden service does use this method to provide CAA records to an		If a Hidden Service does use this method to provide CAA records to an
	ACME server, it SHOULD still publish CAA records if its CAA record		ACME server, it SHOULD still publish CAA records if its CAA record
	set includes "iodef", "contactemail", or "contactphone" so that this		set includes "iodef", "contactemail", or "contactphone" so that this
	information is still publicly accessible. A hidden service operator		information is still publicly accessible. Additionally, a Hidden
	MAY also not wish to publish a CAA record set in its service		Service operator MAY not wish to publish a CAA record set in its
	descriptor to avoid revealing information about the service operator.		Hidden Service Descriptor to avoid revealing information about the
			service operator.
	If an ACME server receives a validly signed CAA record set in the		If an ACME server receives a validly signed CAA record set in the
	finalize request, it MAY proceed with issuance on the basis of the		finalize request, it MAY proceed with issuance on the basis of the
	client-provided CAA record set only, without checking the CAA set in		client-provided CAA record set only, without checking the CAA set in
	the hidden service. Alternatively, an ACME server MAY ignore the		the Hidden Service. Alternatively, an ACME server MAY ignore the
	client provided record set and fetch the record set from the service		client provided record set and fetch the record set from the Hidden
	descriptor. In any case, the server always MAY fetch the record set		Service Descriptor. In any case, the server MAY fetch the record set
	from the service descriptor. If an ACME server receives a validly		from the Hidden Service Descriptor. If an ACME server receives a
	signed CAA record set in the finalize request, it need not check the		validly signed CAA record set in the finalize request, it need not
	CAA set in the hidden service descriptor and can proceed with		check the CAA set in the Hidden Service Descriptor and can proceed
	issuance on the basis of the client-provided CAA record set only. An		with issuance on the basis of the client-provided CAA record set
	ACME server MAY ignore the client-provided record set and is free to		only. An ACME server MAY ignore the client-provided record set and
	always fetch the record set from the service descriptor.		is free to always fetch the record set from the Hidden Service
			Descriptor.
	A new field is defined in the ACME finalize endpoint to contain the		A new field is defined in the ACME finalize endpoint to contain the
	hidden service's CAA record set for each ".onion" Special-Use Domain		Hidden Service's CAA record set for each ".onion" Special-Use Domain
	Name in the order.		Name in the order.
	onionCAA (optional, dictionary of objects): The CAA record set for		onionCAA (optional, dictionary of objects): The CAA record set for
	each ".onion" Special-Use Domain Name in the order. The key is		each ".onion" Special-Use Domain Name in the order. The key is
	the ".onion" Special-Use Domain Name, and the value is an object		the ".onion" Special-Use Domain Name, and the value is an object
	with the fields described below.		with the fields described below.
	The contents of the values of the "onionCAA" object are as follows:		The contents of the values of the "onionCAA" object are as follows:
	caa (required, string or null): The CAA record set as a string,		caa (required, string or null): The CAA record set as a string,
	encoded in the same way as if was included in the hidden service		encoded in the same way as if was included in the Hidden Service
	descriptor. If the hidden service does not have a CAA record set,		Descriptor. If the Hidden Service does not have a CAA record set,
	then this MUST be null.		then this MUST be null.
	expiry (required, integer): The Unix timestamp at which this CAA		expiry (required, integer): The Unix timestamp at which this CAA
	record set will expire. This SHOULD NOT be more than 8 hours in		record set will expire. This SHOULD NOT be more than 8 hours in
	the future. ACME servers MUST process this as at least a 64-bit		the future. ACME servers MUST process this as at least a 64-bit
	integer to ensure functionality beyond 2038.		integer to ensure functionality beyond 2038.
	signature (required, string): The Ed25519 signature of the CAA		signature (required, string): The Ed25519 signature of the CAA
	record set using the private key corresponding to the ".onion"		record set using the private key corresponding to the ".onion"
	Special-Use Domain Name, encoded using base64url. The signature		Special-Use Domain Name, encoded using base64url. The signature
	skipping to change at line 529 ¶		skipping to change at line 524 ¶
	"onion-caa|" || expiry || "|" || caa		"onion-caa|" || expiry || "|" || caa
	Where "|" is the ASCII character 0x7C, and expiry is the expiry field		Where "|" is the ASCII character 0x7C, and expiry is the expiry field
	as a decimal string with no leading zeros. If the caa field is null,		as a decimal string with no leading zeros. If the caa field is null,
	it is represented as an empty string in the signature calculation.		it is represented as an empty string in the signature calculation.
	6.4.1. ACME Servers Requiring In-Band CAA		6.4.1. ACME Servers Requiring In-Band CAA
	If an ACME server does not support fetching a service's CAA record		If an ACME server does not support fetching a service's CAA record
	set from its service descriptor, and the ACME client does not provide		set from its Hidden Service Descriptor, and the ACME client does not
	an "onionCAA" object in its finalize request, the ACME server MUST		provide an "onionCAA" object in its finalize request, the ACME server
	respond with an "onionCAARequired" error to indicate this.		MUST respond with an "onionCAARequired" error to indicate this.
	To support signaling the server's support for fetching CAA record		To support signaling the server's support for fetching CAA record
	sets over Tor, a new field is defined in the directory "meta" object		sets over Tor, a new field is defined in the directory "meta" object
	to signal this.		to signal this.
	inBandOnionCAARequired (optional, boolean): If true, the ACME server		inBandOnionCAARequired (optional, boolean): If true, the ACME server
	requires the client to provide the CAA record set in the finalize		requires the client to provide the CAA record set in the finalize
	request. If false or absent, the ACME server does not require the		request. If false or absent, the ACME server does not require the
	client to provide the CAA record set is this manner.		client to provide the CAA record set is this manner.
	skipping to change at line 554 ¶		skipping to change at line 549 ¶
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Type: application/json		Content-Type: application/json
	{		{
	"newNonce": "https://acme-server.example.onion/acme/new-nonce",		"newNonce": "https://acme-server.example.onion/acme/new-nonce",
	"newAccount": "https://acme-server.example.onion/acme/new-account",		"newAccount": "https://acme-server.example.onion/acme/new-account",
	"newOrder": "https://acme-server.example.onion/acme/new-order",		"newOrder": "https://acme-server.example.onion/acme/new-order",
	"revokeCert": "https://acme-server.example.onion/acme/revoke-cert",		"revokeCert": "https://acme-server.example.onion/acme/revoke-cert",
	"keyChange": "https://acme-server.example.onion/acme/key-change",		"keyChange": "https://acme-server.example.onion/acme/key-change",
	"meta": {		"meta": {
	"termsOfService": "https://acme-server.example.onion/acme/terms/2023-10-13",		"termsOfService":
			"https://acme-server.example.onion/acme/terms/2023-10-13",
	"website": "https://acmeforonions.example/",		"website": "https://acmeforonions.example/",
	"caaIdentities": ["acmeforonions.example"],		"caaIdentities": ["acmeforonions.example"],
	"inBandOnionCAARequired": true		"inBandOnionCAARequired": true
	}		}
	}		}
	6.4.2. Example In-Band CAA		6.4.2. Example In-Band CAA
	Given the following example CAA record set for		Given the following example CAA record set for
	5anebu2glyc235wbbop3m2ukzlaptpkq333vdtdvcjpigyb7x2i2m2qd.onion		5anebu2glyc235wbbop3m2ukzlaptpkq333vdtdvcjpigyb7x2i2m2qd.onion
	skipping to change at line 581 ¶		skipping to change at line 577 ¶
	The following would be submitted to the ACME server's finalize		The following would be submitted to the ACME server's finalize
	endpoint (additional line breaks have been added for readability):		endpoint (additional line breaks have been added for readability):
	POST /acme/order/TOlocE8rfgo/finalize		POST /acme/order/TOlocE8rfgo/finalize
	Host: acme-server.example.onion		Host: acme-server.example.onion
	Content-Type: application/jose+json		Content-Type: application/jose+json
	{		{
	"protected": base64url({		"protected": base64url({
	"alg": "ES256",		"alg": "ES256",
	"kid": "https://acme-server.example.onion/acme/acct/evOfKhNU60wg",		"kid":
			"https://acme-server.example.onion/acme/acct/evOfKhNU60wg",
	"nonce": "MSF2j2nawWHPxxkE3ZJtKQ",		"nonce": "MSF2j2nawWHPxxkE3ZJtKQ",
	"url": "https://acme-server.example.onion/acme/order/TOlocE8rfgo/finalize"		"url": "https://acme-server.example.onion/acme/order/
			TOlocE8rfgo/finalize"
	}),		}),
	"payload": base64url({		"payload": base64url({
	"csr": "MIIBPTCBxAIBADBFMQ...FS6aKdZeGsysoCo4H9P",		"csr": "MIIBPTCBxAIBADBFMQ...FS6aKdZeGsysoCo4H9P",
	"onionCAA": {		"onionCAA": {
	"5anebu2glyc235wbbop3m2ukzlaptpkq333vdtdvcjpi		"5anebu2glyc235wbbop3m2ukzlaptpkq333vdtdvcjpi
	gyb7x2i2m2qd.onion": {		gyb7x2i2m2qd.onion": {
	"caa": "caa 128 issue \"acmeforonions.example;		"caa": "caa 128 issue \"acmeforonions.example;
	validationmethods=onion-csr-01\"\n		validationmethods=onion-csr-01\"\n
	caa 0 iodef \"mailto:example@example.com\"",		caa 0 iodef \"mailto:example@example.com\"",
	"expiry": 1697210719,		"expiry": 1697210719,
	skipping to change at line 628 ¶		skipping to change at line 626 ¶
	7.2. Error Types		7.2. Error Types
	One new entry has been added to the "ACME Error Types" registry that		One new entry has been added to the "ACME Error Types" registry that
	was defined in Section 9.7.4 of [RFC8555]		was defined in Section 9.7.4 of [RFC8555]
	(<https://www.iana.org/assignments/acme>).		(<https://www.iana.org/assignments/acme>).
	+==================+===============================+===========+		+==================+===============================+===========+
	| Type | Description | Reference |		| Type | Description | Reference |
	+==================+===============================+===========+		+==================+===============================+===========+
	| onionCAARequired | The CA only supports checking | This |		| onionCAARequired | The CA only supports checking | This |
	| | the CAA for hidden services | document |		| | the CAA for Hidden Services | document |
	| | in-band, but the client has | |		| | in-band, but the client has | |
	| | not provided an in-band CAA | |		| | not provided an in-band CAA | |
	+------------------+-------------------------------+-----------+		+------------------+-------------------------------+-----------+
	Table 2: onionCAARequired Error Type		Table 2: onionCAARequired Error Type
	7.3. Directory Metadata Fields		7.3. Directory Metadata Fields
	One new entry has been added to the "ACME Directory Metadata Fields"		One new entry has been added to the "ACME Directory Metadata Fields"
	registry that was defined in Section 9.7.6 of [RFC8555]		registry that was defined in Section 9.7.6 of [RFC8555]
	skipping to change at line 651 ¶		skipping to change at line 649 ¶
	+==================+============+===============+		+==================+============+===============+
	| Field name | Field type | Reference |		| Field name | Field type | Reference |
	+==================+============+===============+		+==================+============+===============+
	| onionCAARequired | boolean | This document |		| onionCAARequired | boolean | This document |
	+------------------+------------+---------------+		+------------------+------------+---------------+
	Table 3: onionCAARequired Metadata Field		Table 3: onionCAARequired Metadata Field
	8. Security Considerations		8. Security Considerations
	8.1. Security of the "onion-csr-01" Challenge		8.1. Security of the onion-csr-01 Challenge
	The security considerations of [cabf-br] apply to issuance using the		The security considerations of [cabf-br] apply to issuance using the
	CSR method.		Certificate Request method.
	8.2. Use of the "dns" Identifier Type		8.2. Use of the "dns" Identifier Type
	The reuse of the "dns" identifier type for a Special-Use Domain Name		The reuse of the "dns" identifier type for a Special-Use Domain Name
	not actually in the DNS infrastructure raises questions regarding its		not actually in the DNS infrastructure raises questions regarding its
	suitability. The reasons to pursue this path in the first place are		suitability. The reasons to pursue this path in the first place are
	detailed in Appendix A. It is felt that there is little security		detailed in Appendix A. It is felt that there is little security
	concern in reuse of the "dns" identifier type with regard to the mis-		concern in reuse of the "dns" identifier type with regard to the mis-
	issuance by CAs that are not aware of ".onion" Special-Use Domain		issuance by CAs that are not aware of ".onion" Special-Use Domain
	Names as CAs would not be able to resolve the identifier in the DNS.		Names as CAs would not be able to resolve the identifier in the DNS.
	8.2.1. "http-01" Challenge		8.2.1. http-01 Challenge
	In the absence of knowledge of this document, a CA would follow the		In the absence of knowledge of this document, a CA would follow the
	procedure set out in Section 8.3 of [RFC8555], which specifies that		procedure set out in Section 8.3 of [RFC8555], which specifies that
	the CA should "Dereference the URL using an HTTP GET request". Given		the CA should "Dereference the URL using an HTTP GET request". Given
	that ".onion" Special-Use Domain Names require special handling to		that ".onion" Special-Use Domain Names require special handling to
	dereference, this dereferencing will fail, disallowing issuance.		dereference, this dereferencing will fail, disallowing issuance.
	8.2.2. "tls-alpn-01" Challenge		8.2.2. tls-alpn-01 Challenge
	In the absence of knowledge of this document, a CA would follow the		In the absence of knowledge of this document, a CA would follow the
	procedure set out in Section 3 of [RFC8737], which specifies that the		procedure set out in Section 3 of [RFC8737], which specifies that the
	CA "resolves the domain name being validated and chooses one of the		CA "resolves the domain name being validated and chooses one of the
	IP addresses returned for validation". Given that ".onion" Special-		IP addresses returned for validation". Given that ".onion" Special-
	Use Domain Names are not resolvable to IP addresses, this		Use Domain Names are not resolvable to IP addresses, this
	dereferencing will fail, disallowing issuance.		dereferencing will fail, disallowing issuance.
	8.2.3. "dns-01" Challenge		8.2.3. dns-01 Challenge
	In the absence of knowledge of this document, a CA would follow the		In the absence of knowledge of this document, a CA would follow the
	procedure set out in Section 8.4 of [RFC8555], which specifies that		procedure set out in Section 8.4 of [RFC8555], which specifies that
	the CA should "query for TXT records for the validation domain name".		the CA should "query for TXT records for the validation domain name".
	Given that ".onion" Special-Use Domain Names are not present in the		Given that ".onion" Special-Use Domain Names are not present in the
	DNS infrastructure, this query will fail, disallowing issuance.		DNS infrastructure, this query will fail, disallowing issuance.
	8.3. Key Authorization with "onion-csr-01"		8.3. Key Authorization with onion-csr-01
	The "onion-csr-01" challenge does not make use of the key		The onion-csr-01 challenge does not make use of the key authorization
	authorization string defined in Section 8.1 of [RFC8555]. This does		string defined in Section 8.1 of [RFC8555]. This does not weaken the
	not weaken the integrity of authorizations.		integrity of authorizations.
	The key authorization exists to ensure that, whilst an attacker		The key authorization exists to ensure that, whilst an attacker
	observing the validation channel can observe the correct validation		observing the validation channel can observe the correct validation
	response, they cannot compromise the integrity of authorizations as		response, they cannot compromise the integrity of authorizations as
	the response can only be used with the account key for which it was		the response can only be used with the account key for which it was
	generated. As the validation channel for this challenge is ACME		generated. As the validation channel for this challenge is ACME
	itself, and ACME already requires that the request be signed by the		itself, and ACME already requires that the request be signed by the
	account, the key authorization is not necessary.		account, the key authorization is not necessary.
	8.4. Use of Tor for Domains That Are Not ".onion"		8.4. Use of Tor for Domains That Are Not ".onion"
	An ACME server MUST NOT utilize Tor for the validation of domains		An ACME server MUST NOT utilize Tor for the validation of domains
	that are not ".onion", due to the risk of exit hijacking		that are not ".onion", due to the risk of exit hijacking
	[spoiled-onions].		[spoiled-onions].
	8.5. Redirects with "http-01"		8.5. Redirects with http-01
	A site MAY redirect to another site when completing validation using		A site MAY redirect to another site when completing validation using
	the "http-01" challenge. This redirect MAY be to either another		the http-01 challenge. This redirect MAY be to either another
	".onion" Special-Use Domain Name or a domain in the public DNS. A		".onion" Special-Use Domain Name or a domain in the public DNS. A
	site operator MUST consider the privacy implications of redirecting		site operator MUST consider the privacy implications of redirecting
	to a site that is not ".onion" -- namely that the ACME server		to a site that is not ".onion" -- namely that the ACME server
	operator will then be able to learn information about the site they		operator will then be able to learn information about the site they
	were redirected to that they would not have if accessed via a		were redirected to that they would not have if accessed via a
	".onion" Special-Use Domain Name, such as its IP address. If the		".onion" Special-Use Domain Name, such as its IP address. If the
	site redirected to is on the same or an adjacent host to the ".onion"		site redirected to is on the same or an adjacent host to the ".onion"
	Special-Use Domain Name, this reveals information that the "Tor		Special-Use Domain Name, this reveals information that the "Tor
	Rendezvous Specification - Version 3" (https://spec.torproject.org/		Rendezvous Specification - Version 3" section of [tor-spec] was
	rend-spec/index.html) secion of [tor-spec] was otherwise designed to		otherwise designed to protect.
	protect.
	If an ACME server receives a redirect to a domain in the public DNS,		If an ACME server receives a redirect to a domain in the public DNS,
	it MUST NOT utilize Tor to make a connection to it due to the risk of		it MUST NOT utilize Tor to make a connection to it due to the risk of
	exit hijacking.		exit hijacking.
	8.6. Security of CAA Records		8.6. Security of CAA Records
	The second layer descriptor is signed, encrypted, and encoded using		The Second Layer Hidden Service Descriptor is signed, encrypted, and
	Message Authentication Code (MAC) in a way that only a party with		encoded using a Message Authentication Code (MAC) in a way that only
	access to the secret key of the hidden service could manipulate what		a party with access to the secret key of the Hidden Service could
	is published there. For more information about this process, see the		manipulate what is published there. For more information about this
	"Hidden service descriptors: encryption format"		process, see the "Hidden service descriptors: encryption format"
	(https://spec.torproject.org/rend-spec/hsdesc-encrypt.html) section		section of [tor-spec].
	of [tor-spec].
	8.7. In-Band CAA		8.7. In-Band CAA
	Tor directory servers are inherently untrusted entities; as such,		Tor directory servers are inherently untrusted entities. As such,
	there is no difference in the security model for accepting CAA		there is no difference in the security model for accepting CAA
	records directly from the ACME client or fetching them over Tor.		records directly from the ACME client or fetching them over Tor: the
	There is no difference in the security model between accepting CAA
	records directly from the ACME client and fetching them over Tor; the
	CAA records are verified using the same hidden service key in either		CAA records are verified using the same hidden service key in either
	case.		case.
	8.8. Access of the Tor Network		8.8. Access of the Tor Network
	The ACME server MUST make its own connection to the hidden service		The ACME server MUST make its own connection to the Hidden Service
	via the Tor network and MUST NOT outsource this to a third-party		via the Tor network and MUST NOT outsource this to a third-party
	service, such as Tor2Web.		service, such as Tor2Web.
	8.9. Anonymity of the ACME Client		8.9. Anonymity of the ACME Client
	ACME clients requesting certificates for ".onion" Special-Use Domain		ACME clients requesting certificates for ".onion" Special-Use Domain
	Names not over the Tor network can inadvertently expose the existence		Names not over the Tor network can inadvertently expose the existence
	of a hidden service on the host requesting certificates to unintended		of a Hidden Service on the host requesting certificates to unintended
	parties; this is true even when features such as Encrypted		parties; this is true even when features such as Encrypted
	ClientHello (ECH) [tls-esni] are utilized, as the IP addresses of		ClientHello (ECH) [tls-esni] are utilized, as the IP addresses of
	ACME servers are generally well-known, static, and not used for any		ACME servers are generally well-known, static, and not used for any
	other purpose.		other purpose.
	ACME clients SHOULD connect to ACME servers over the Tor network to		ACME clients SHOULD connect to ACME servers over the Tor network to
	alleviate this, preferring a hidden service endpoint if the CA		alleviate this, preferring a Hidden Service endpoint if the CA
	provides such a service.		provides such a service.
	If an ACME client requests a publicly trusted WebPKI certificate, it		If an ACME client requests a publicly trusted WebPKI certificate, it
	will expose the existence of the Hidden Service publicly due to its		will expose the existence of the Hidden Service publicly due to its
	inclusion in Certificate Transparency logs [RFC9162]. Hidden Service		inclusion in Certificate Transparency logs [RFC9162]. Hidden Service
	operators MUST consider the privacy implications of this before		operators MUST consider the privacy implications of this before
	requesting WebPKI certificates. ACME client developers SHOULD warn		requesting WebPKI certificates. ACME client developers SHOULD warn
	users about the risks of CT-logged certificates for hidden services.		users about the risks of CT-logged certificates for Hidden Services.
	8.9.1. Avoid Unnecessary Certificates		8.9.1. Avoid Unnecessary Certificates
	Not all services will need a publicly trusted WebPKI certificate; for		Not all services will need a publicly trusted WebPKI certificate; for
	internal or non-public services, operators SHOULD consider using		internal or non-public services, operators SHOULD consider using
	self-signed or privately trusted certificates that aren't logged to		self-signed or privately trusted certificates that aren't logged to
	certificate transparency.		certificate transparency.
	8.9.2. Obfuscate Subscriber Information		8.9.2. Obfuscate Subscriber Information
	When an ACME client is registering with an ACME server, it SHOULD		When an ACME client is registering with an ACME server, it SHOULD
	provide minimal or obfuscated subscriber details to the CA, such as a		provide minimal or obfuscated subscriber details to the CA, such as a
	pseudonymous email address, if at all possible.		pseudonymous email address, if at all possible.
	8.9.3. Separate ACME Account Keys		8.9.3. Separate ACME Account Keys
	If a hidden service operator does not want their different hidden		If a Hidden Service operator does not want their different Hidden
	services to be correlated by a CA, they MUST use separate ACME		Services to be correlated by a CA, they MUST use separate ACME
	account keys for each hidden service.		account keys for each Hidden Service.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[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/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	skipping to change at line 879 ¶		skipping to change at line 873 ¶
	Winter, P., Köwer, R., Mulazzani, M., Huber, M.,		Winter, P., Köwer, R., Mulazzani, M., Huber, M.,
	Schrittwieser, S., Lindskog, S., and E. Weippl, "Spoiled		Schrittwieser, S., Lindskog, S., and E. Weippl, "Spoiled
	Onions: Exposing Malicious Tor Exit Relays", Privacy		Onions: Exposing Malicious Tor Exit Relays", Privacy
	Enhancing Technologies (PETS 2014), Lecture Notes in		Enhancing Technologies (PETS 2014), Lecture Notes in
	Computer Science, vol. 8555, pp. 304-331,		Computer Science, vol. 8555, pp. 304-331,
	DOI 10.1007/978-3-319-08506-7_16, 2014,		DOI 10.1007/978-3-319-08506-7_16, 2014,
	<https://doi.org/10.1007/978-3-319-08506-7_16>.		<https://doi.org/10.1007/978-3-319-08506-7_16>.
	[tls-esni] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS		[tls-esni] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
	Encrypted Client Hello", Work in Progress, Internet-Draft,		Encrypted Client Hello", Work in Progress, Internet-Draft,
	draft-ietf-tls-esni-24, 20 March 2025,		draft-ietf-tls-esni-25, 14 June 2025,
	<https://datatracker.ietf.org/doc/html/draft-ietf-tls-		<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
	esni-24>.		esni-25>.
	[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>.
	Appendix A. Discussion on the Use of the "dns" Identifier Type		Appendix A. Discussion on the Use of the "dns" Identifier Type
	The reasons for utilizing the "dns" identifier type in ACME and not		The reasons for utilizing the "dns" identifier type in ACME and not
	defining a new identifier type for ".onion" may not seem obvious at		defining a new identifier type for ".onion" may not seem obvious at
	first glance. After all, ".onion" Special-Use Domain Names are not		first glance. After all, ".onion" Special-Use Domain Names are not
	part of the DNS infrastructure and, as such, why should they use the		part of the DNS infrastructure and, as such, why should they use the
	"dns" identifier type?		"dns" identifier type?
	Appendix B.2.a.ii of [cabf-br] defines, and this document allows,		Appendix B.2.a.ii of [cabf-br] defines, and this document allows,
	using the "http-01" or "tls-alpn-01" validation methods already		using the http-01 or tls-alpn-01 validation methods already present
	present in ACME (with some considerations). Given the situation of a		in ACME (with some considerations). Given the situation of a web
	web server placed behind a Tor-terminating proxy (as per the setup		server placed behind a Tor-terminating proxy (as per the setup
	suggested by the Tor project [onion-services-setup]), existing ACME		suggested by the Tor project [onion-services-setup]), existing ACME
	tooling can be blind to the fact that a ".onion" Special-Use Domain		tooling can be blind to the fact that a ".onion" Special-Use Domain
	Name is being utilized, as they simply receive an incoming TCP		Name is being utilized, as they simply receive an incoming TCP
	connection as they would regardless (albeit from the Tor-terminating		connection as they would regardless (albeit from the Tor-terminating
	proxy).		proxy).
	An example of this would be Certbot placing the ACME challenge		An example of this would be Certbot placing the ACME challenge
	response file in the webroot of an NGINX web server. Neither Certbot		response file in the webroot of an NGINX web server. Neither Certbot
	nor NGINX would require any modification to be aware of any special		nor NGINX would require any modification to be aware of any special
	handling for ".onion" Special-Use Domain Names.		handling for ".onion" Special-Use Domain Names.
End of changes. 66 change blocks.
	144 lines changed or deleted		138 lines changed or added
This html diff was produced by rfcdiff 1.48.