Diff: rfc9799.original.xml

	rfc9799.original.xml	rfc9799.xml

	<?xml version="1.0" encoding="utf-8"?>	<?xml version="1.0" encoding="UTF-8"?>
	<?xml-model href="rfc7991bis.rnc"?>
	<!DOCTYPE rfc [	<!DOCTYPE rfc [
	<!ENTITY nbsp " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">
	]>	]>


	<rfc xmlns:xi="http://www.w3.org/2001/XInclude"	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" submissionType
	ipr="trust200902" submissionType="IETF" category="std" version="3" docName=	="IETF" category="std" version="3" docName="draft-ietf-acme-onion-07" number="97
	"draft-ietf-acme-onion-07"	99" consensus="true" updates="" obsoletes="" xml:lang="en" tocInclude="true" sym
	consensus="true">	Refs="true" sortRefs="false" >

	<front>	<front>

	<title abbrev="ACME for .onion">Automated Certificate Management Environment
	(ACME) Extensions for ".onion"	<!-- [rfced] Please note that the title of the document has been
		updated as follows:

		The short title that appears in the running header of the pdf output has been up
		dated to use double quotes around ".onion" to match the use in the full title.

		Original:

		ACME for .onion
		Current:
		ACME for ".onion"
		-->

		<title abbrev="ACME for ".onion"">Automated Certificate Management
		Environment (ACME) Extensions for ".onion"
	Special-Use Domain Names</title>	Special-Use Domain Names</title>

	<seriesInfo name="Internet-Draft" status="standard" value="draft-ietf-acme-o nion-07"/>	<seriesInfo name="RFC" value="9799"/>
	<author fullname="Q Misell" initials="Q" role="editor" surname="Misell">	<author fullname="Q Misell" initials="Q" role="editor" surname="Misell">
	<organization abbrev="AS207960">AS207960 Cyfyngedig</organization>	<organization abbrev="AS207960">AS207960 Cyfyngedig</organization>
	<address>	<address>
	<postal>	<postal>
	<street>13 Pen-y-lan Terrace</street>	<street>13 Pen-y-lan Terrace</street>
	<city>Caerdydd</city>	<city>Caerdydd</city>
	<code>CF23 9EU</code>	<code>CF23 9EU</code>
	<country>United Kingdom</country>	<country>United Kingdom</country>
	</postal>	</postal>
	<email>q@as207960.net</email>	<email>q@as207960.net</email>
	<email>q@magicalcodewit.ch</email>	<email>q@magicalcodewit.ch</email>
	<uri>https://magicalcodewit.ch</uri>	<uri>https://magicalcodewit.ch</uri>
	</address>	</address>
	</author>	</author>

	<area>sec</area>	<date month="June" year="2025"/>
	<workgroup>Automated Certificate Management Environment</workgroup>
		<!--[rfced] Q - currently our tooling does not support the request to
		remove the period from following your first name. Please see
		https://github.com/ietf-tools/xml2rfc/issues/1204. We have
		commented on this issue to raise awareness that you document is
		now in AUTH48 and publication is nearing.

		-->

		<area>SEC</area>
		<workgroup>acme</workgroup>

		<!-- [rfced] Please insert any keywords (beyond those that appear in
		the title) for use on https://www.rfc-editor.org/search. -->

		<keyword>example</keyword>

	<abstract>	<abstract>

	<t>The document defines extensions to the Automated Certificate Management Environment (ACME) to allow for the	<t>This document defines extensions to the Automated Certificate Managemen t Environment (ACME) to allow for the
	automatic issuance of certificates to Tor hidden services (".onion" Spec ial-Use Domain Names).</t>	automatic issuance of certificates to Tor hidden services (".onion" Spec ial-Use Domain Names).</t>
	</abstract>	</abstract>

	<note removeInRFC="true">	<note removeInRFC="true">
	<name>Discussion</name>	<name>Discussion</name>
	<t>Source for this draft and an issue tracker can be found at	<t>Source for this draft and an issue tracker can be found at
	<eref target="https://github.com/AS207960/acme-onion"/>.</t>	<eref target="https://github.com/AS207960/acme-onion"/>.</t>
	<t>The project website and a reference implementation can be found at	<t>The project website and a reference implementation can be found at
	<eref target="https://acmeforonions.org"/>.</t>	<eref target="https://acmeforonions.org"/>.</t>
	</note>	</note>
	</front>	</front>

	<middle>	<middle>
	<section>	<section>
	<name>Introduction</name>	<name>Introduction</name>
	<t>The Tor network has the ability to host "Onion Services" <xref target=" tor-spec"/> only accessible via the	<t>The Tor network has the ability to host "Onion Services" <xref target=" tor-spec"/> only accessible via the
	Tor network. These services use the ".onion"	Tor network. These services use the ".onion"
	Special-Use Domain Name <xref target="RFC7686"/> to identify these servi ces. These can be used as any other domain	Special-Use Domain Name <xref target="RFC7686"/> to identify these servi ces. These can be used as any other domain

	name could, but do not form part of the DNS infrastructure.</t>	name could, but they do not form part of the DNS infrastructure.</t>
	<t>The Automated Certificate Management Environment (ACME) <xref target="R FC8555"/> defines challenges for	<t>The Automated Certificate Management Environment (ACME) <xref target="R FC8555"/> defines challenges for
	validating control of DNS identifiers, and whilst a ".onion" Special-Use Domain Name may appear as a DNS name,	validating control of DNS identifiers, and whilst a ".onion" Special-Use Domain Name may appear as a DNS name,
	it requires special consideration to validate control of one such that A CME could be used on ".onion"	it requires special consideration to validate control of one such that A CME could be used on ".onion"
	Special-Use Domain Names.</t>	Special-Use Domain Names.</t>

	<t>In order to allow ACME to be utilised to issue certificates to ".onion" Special-Use Domain Names this document	<t>In order to allow ACME to be utilized to issue certificates to ".onion" Special-Use Domain Names, this document
	specifies challenges suitable to validate control of these Special-Use D omain Names. Additionally, this document	specifies challenges suitable to validate control of these Special-Use D omain Names. Additionally, this document
	defines an alternative to the DNS Certification Authority Authorization (CAA) Resource Record	defines an alternative to the DNS Certification Authority Authorization (CAA) Resource Record
	<xref target="RFC8659"/> that can be used with ".onion" Special-Use Doma in Names.</t>	<xref target="RFC8659"/> that can be used with ".onion" Special-Use Doma in Names.</t>

	<section>	<section>
	<name>Requirements Language</name>	<name>Requirements Language</name>

	<t>The key words <bcp14>MUST</bcp14>, <bcp14>MUST NOT</bcp14>, <bcp14>RE	<t>
	QUIRED</bcp14>, <bcp14>SHALL</bcp14>,	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	<bcp14>SHALL NOT</bcp14>, <bcp14>SHOULD</bcp14>, <bcp14>SHOULD NOT</bc	IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	p14>, <bcp14>RECOMMENDED</bcp14>,	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	<bcp14>NOT RECOMMENDED</bcp14>, <bcp14>MAY</bcp14>, and <bcp14>OPTIONA	RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	L</bcp14> in this document are to be	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	interpreted as described in <xref target="BCP14"/> (<xref target="RFC2	be interpreted as
	119"/>, <xref target="RFC8174"/>) when,	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
	and only when, they appear in all capitals, as shown here.</t>	when, and only when, they appear in all capitals, as shown here.
		</t>
	</section>	</section>
	</section>	</section>

	<section>	<section>
	<name>Identifier</name>	<name>Identifier</name>
	<t><xref target="RFC8555"/> defines the "dns" identifier type. This identi fier type <bcp14>MUST</bcp14> be used	<t><xref target="RFC8555"/> defines the "dns" identifier type. This identi fier type <bcp14>MUST</bcp14> be used

	when requesting a certificate for a ".onion" Special-Use Domain Name. Th	when requesting a certificate for a ".onion" Special-Use Domain Name. Th
	e value of identifier	e value of the identifier
	<bcp14>MUST</bcp14> be the textual representation as defined in	<bcp14>MUST</bcp14> be the textual representation as defined in the <ere
	<xref target="tor-spec" section="Special Hostnames in Tor - ".onion	f target="https://spec.torproject.org/address-spec.html#onion">"Special Hostname
	"" relative="#onion"/>.	s in Tor - .onion"</eref> section of <xref target="tor-spec"/>.
	The value <bcp14>MAY</bcp14> include subdomain labels. Version 2 address es <xref target="tor-rend-spec-v2"/>	The value <bcp14>MAY</bcp14> include subdomain labels. Version 2 address es <xref target="tor-rend-spec-v2"/>
	<bcp14>MUST NOT</bcp14> be used as these are now considered insecure.</t >	<bcp14>MUST NOT</bcp14> be used as these are now considered insecure.</t >

	<t>Example identifiers (linebreaks have been added for readability only):<	<t>Example identifiers (line breaks have been added for readability only):
	/t>	</t>
	<sourcecode type="json">	<sourcecode type="json"><![CDATA[
	{	{
	"type": "dns",	"type": "dns",
	"value": "bbcweb3hytmzhn5d532owbu6oqadra5z3ar726v	"value": "bbcweb3hytmzhn5d532owbu6oqadra5z3ar726v
	q5kgwwn6aucdccrad.onion"	q5kgwwn6aucdccrad.onion"
	}	}

	</sourcecode>	]]></sourcecode>
	<sourcecode type="json">
		<sourcecode type="json"><![CDATA[
	{	{
	"type": "dns",	"type": "dns",
	"value": "www.bbcweb3hytmzhn5d532owbu6oqadra5z3ar726v	"value": "www.bbcweb3hytmzhn5d532owbu6oqadra5z3ar726v
	q5kgwwn6aucdccrad.onion"	q5kgwwn6aucdccrad.onion"
	}	}

	</sourcecode>	]]></sourcecode>

	</section>	</section>

	<section>	<section>
	<name>Identifier Validation Challenges</name>	<name>Identifier Validation Challenges</name>

	<t>The CA/Browser Forum Baseline Requirements (<xref target="cabf-br" sect	<t>The CA/Browser Forum Baseline Requirements define methods accepted by t
	ion="B.2" relative="#page=124" />)	he CA industry for validation of ".onion" Special-Use Domain Names (see <xref ta
	define methods accepted by the CA industry for validation of ".onion" Sp	rget="cabf-br" section="B.2" relative="#page=124"/>).
	ecial-Use Domain Names.
	This document incorporates these methods into ACME challenges.</t>	This document incorporates these methods into ACME challenges.</t>
	<section>	<section>

	<name>Existing challenges</name>	<name>Existing Challenges</name>
	<section>	<section>

	<name>Existing "dns-01" Challenge</name>	<name>Existing: "dns-01" Challenge</name>
	<t>The existing "dns-01" challenge <bcp14>MUST NOT</bcp14> be used to validate ".onion" Special-Use Domain	<t>The existing "dns-01" challenge <bcp14>MUST NOT</bcp14> be used to validate ".onion" Special-Use Domain

	Names, as these domains are not part of the DNS.</t>	Names as these domains are not part of the DNS.</t>
	</section>	</section>

	<section>	<section anchor="http01">
	<name>Existing "http-01" Challenge</name>	<name>Existing: "http-01" Challenge</name>
	<t>The "http-01" challenge as defined in <xref target="RFC8555" sectio	<t>The "http-01" challenge, as defined in <xref target="RFC8555" secti
	n="8.3"/> <bcp14>MAY</bcp14> be used to	on="8.3"/>, <bcp14>MAY</bcp14> be used to
	validate a ".onion" Special-Use Domain Names, with the modifications	validate a ".onion" Special-Use Domain Name with the modifications d
	defined in this document, namely	efined in this document, namely those described in Sections
	<xref target="client-auth"/>, and <xref target="caa"/>.</t>	<xref target="client-auth" format="counter"/> and <xref target="caa" f
	<t>The ACME server <bcp14>SHOULD</bcp14> follow redirects; note that t	ormat="counter"/>.</t>
	hese <bcp14>MAY</bcp14> be redirects to
	non-".onion" services, and the server <bcp14>SHOULD</bcp14> honour t	<!--[rfced] Please review our edits to the following text to ensure we
	hese. Clients might use redirects,	have maintained your intent.
	for example, so that the response can be provided by a centralized c
	ertificate management server. See	Original:
		The ACME server SHOULD follow redirects; note that these MAY be
		redirects to non-".onion" services, and the server SHOULD honour
		these.

		Current:
		The ACME server SHOULD follow redirects. Note that these MAY be
		redirects to services that are not ".onion" and that the server
		SHOULD honor these.

		-->

		<t>The ACME server <bcp14>SHOULD</bcp14> follow redirects. Note that t
		hese <bcp14>MAY</bcp14> be redirects to services that are not ".onion" and that
		the server <bcp14>SHOULD</bcp14> honor these. For example, clients might use red
		irects so that the response can be provided by a centralized certificate managem
		ent server. See
	<xref target="RFC8555" section="10.2"/> for security considerations on why a server might not want to	<xref target="RFC8555" section="10.2"/> for security considerations on why a server might not want to
	follow redirects.</t>	follow redirects.</t>
	</section>	</section>

	<section>	<section anchor="tlsalpn">
	<name>Existing "tls-alpn-01" Challenge</name>	<name>Existing "tls-alpn-01" Challenge</name>

	<t>The "tls-alpn-01" challenge as defined in <xref target="RFC8737"/>	<t>The "tls-alpn-01" challenge, as defined in <xref target="RFC8737"/>
	<bcp14>MAY</bcp14> be used to validate	, <bcp14>MAY</bcp14> be used to validate
	a ".onion" Special-Use Domain Names, with the modifications defined	a ".onion" Special-Use Domain Name with the modifications defined in
	in this document, namely	this document, namely those described in Sections
	<xref target="client-auth"/>, and <xref target="caa"/>.</t>	<xref target="client-auth" format="counter"/> and <xref target="caa"
		format="counter"/>.</t>
	</section>	</section>
	</section>	</section>
	<section>	<section>
	<name>New "onion-csr-01" Challenge</name>	<name>New "onion-csr-01" Challenge</name>

	<t>Two methods already defined in ACME and allowed by the CA/BF ("http-0
	1" and "tls-alpn-01") do not allow	<t>The two ACME-defined methods allowed by CA/BF described in Sections <
		xref target="http01" format="counter"/> and <xref target="tlsalpn" format="count
		er"/> ("http-01" and "tls-alpn-01") do not allow
	issuance of wildcard certificates. A ".onion" Special-Use Domain Name can have subdomains	issuance of wildcard certificates. A ".onion" Special-Use Domain Name can have subdomains
	(just like any other domain in the DNS), and a site operator may find it useful to have one certificate for	(just like any other domain in the DNS), and a site operator may find it useful to have one certificate for

	all virtual hosts on their site. This new validation method incorporat es the specially signed CSR (as defined by	all virtual hosts on their site. This new validation method incorporat es the specially signed Certificate Signing Request (CSR) (as defined by
	<xref target="cabf-br" section="B.2.b" relative="#page=124"/>) into AC ME to allow for the issuance of	<xref target="cabf-br" section="B.2.b" relative="#page=124"/>) into AC ME to allow for the issuance of
	wildcard certificates.</t>	wildcard certificates.</t>

	<t>To this end a new challenge type called "onion-csr-01" is defined, wi th the following fields:</t>	<t>To this end, a new challenge called "onion-csr-01" is defined, with t he following fields:</t>
	<dl>	<dl>

	<dt>type (required, string)</dt>	<dt>type (required, string):</dt>
	<dd>The string <tt>"onion-csr-01"</tt></dd>	<dd>The string <tt>"onion-csr-01".</tt></dd>
	<dt>nonce (required, string)</dt>	<dt>nonce (required, string):</dt>
	<dd>A Base64 <xref target="RFC4648"/> encoded nonce, including padding	<dd>A Base64-encoded nonce <xref target="RFC4648"/> including padding
	characters.	characters.
	It <bcp14>MUST</bcp14> contain at least 64 bits of entropy. A respon se generated using this nonce	It <bcp14>MUST</bcp14> contain at least 64 bits of entropy. A respon se generated using this nonce
	<bcp14>MUST NOT</bcp14> be accepted by the ACME server if the nonce used was generated by the server more	<bcp14>MUST NOT</bcp14> be accepted by the ACME server if the nonce used was generated by the server more

	than 30 days ago (as per <xref target="cabf-br" section="B.2.b" rela	than 30 days prior (as per <xref target="cabf-br" section="B.2.b" re
	tive="#page=124"/>).</dd>	lative="#page=124"/>).</dd>
	<dt>authKey (optional, object)</dt>	<dt>authKey (optional, object):</dt>
	<dd>The ACME server's Ed25519 public key encoded as per <xref target=" RFC8037"/>. This is further defined in	<dd>The ACME server's Ed25519 public key encoded as per <xref target=" RFC8037"/>. This is further defined in
	<xref target="client-auth"/>.</dd>	<xref target="client-auth"/>.</dd>
	</dl>	</dl>

	<sourcecode type="json">	<sourcecode type="json"><![CDATA[
	{	{
	"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": { ... }
	}	}

	</sourcecode>	]]></sourcecode>
	<t>An "onion-csr-01" <bcp14>MUST NOT</bcp14> be used to issue certificat
	es for non ".onion"	<!--[rfced] Please review our updates to this text carefully and let
	Special-Use Domain Names.</t>	us know any objections.

		Original:

		An "onion-csr-01" MUST NOT be used to issue certificates for non
		".onion" Special-Use Domain Names.

		Current:
		An "onion-csr-01" challenge MUST NOT be used to issue certificates for
		Special-Use Domain Names that are not ".onion".
		-->

		<t>An "onion-csr-01" challenge <bcp14>MUST NOT</bcp14> be used to issue
		certificates for
		Special-Use Domain Names that are not ".onion".</t>
	<t>Clients prove control over the key associated with the ".onion" servi ce by generating a CSR	<t>Clients prove control over the key associated with the ".onion" servi ce by generating a CSR
	<xref target="RFC2986"/> with the following additional extension attri butes and signing it with the private	<xref target="RFC2986"/> with the following additional extension attri butes and signing it with the private
	key of the ".onion" Special-Use	key of the ".onion" Special-Use
	Domain Name:</t>	Domain Name:</t>
	<ul>	<ul>
	<li>A <tt>caSigningNonce</tt> attribute containing the nonce provided in the challenge. This	<li>A <tt>caSigningNonce</tt> attribute containing the nonce provided in the challenge. This

	<bcp14>MUST</bcp14> be raw bytes, and not the base64 encoded value p	<bcp14>MUST</bcp14> be raw bytes and not the base64 encoded value pr
	rovided in the challenge object.</li>	ovided in the challenge object.</li>
	<li>An <tt>applicantSigningNonce</tt> containing a nonce generated by	<li>An <tt>applicantSigningNonce</tt> attribute containing a nonce gen
	the client. This <bcp14>MUST</bcp14>	erated by the client. This <bcp14>MUST</bcp14>
	have at least 64 bits of entropy. This <bcp14>MUST</bcp14> be raw by tes.</li>	have at least 64 bits of entropy. This <bcp14>MUST</bcp14> be raw by tes.</li>
	</ul>	</ul>
	<t>These additional attributes have the following format</t>	<t>These additional attributes have the following format</t>

	<sourcecode type="asn.1">	<sourcecode type="asn.1"><![CDATA[
	cabf OBJECT IDENTIFIER ::=	cabf OBJECT IDENTIFIER ::=
	{ joint-iso-itu-t(2) international-organizations(23)	{ joint-iso-itu-t(2) international-organizations(23)
	ca-browser-forum(140) }	ca-browser-forum(140) }

	cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 }	cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 }

	caSigningNonce ATTRIBUTE ::= {	caSigningNonce ATTRIBUTE ::= {
	WITH SYNTAX OCTET STRING	WITH SYNTAX OCTET STRING
	EQUALITY MATCHING RULE octetStringMatch	EQUALITY MATCHING RULE octetStringMatch
	SINGLE VALUE TRUE	SINGLE VALUE TRUE

	skipping to change at line 194 ¶	skipping to change at line 252 ¶
	}	}

	cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 }	cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 }

	applicantSigningNonce ATTRIBUTE ::= {	applicantSigningNonce ATTRIBUTE ::= {
	WITH SYNTAX OCTET STRING	WITH SYNTAX OCTET STRING
	EQUALITY MATCHING RULE octetStringMatch	EQUALITY MATCHING RULE octetStringMatch
	SINGLE VALUE TRUE	SINGLE VALUE TRUE
	ID { cabf-applicantSigningNonce }	ID { cabf-applicantSigningNonce }
	}	}

	</sourcecode>	]]></sourcecode>
	<t>The subject of the CSR need not be meaningful and CAs <bcp14>MUST NOT </bcp14> validate its contents.	<t>The subject of the CSR need not be meaningful and CAs <bcp14>MUST NOT </bcp14> validate its contents.
	The public key presented in this CSR <bcp14>MUST</bcp14> be the public key corresponding to the ".onion"	The public key presented in this CSR <bcp14>MUST</bcp14> be the public key corresponding to the ".onion"
	Special-Use Domain Name being validated. It <bcp14>MUST NOT</bcp14> be the same public key presented in the	Special-Use Domain Name being validated. It <bcp14>MUST NOT</bcp14> be the same public key presented in the
	CSR to finalize the order.</t>	CSR to finalize the order.</t>
	<t>Clients respond with the following object to validate the challenge:< /t>	<t>Clients respond with the following object to validate the challenge:< /t>
	<dl>	<dl>

	<dt>csr (required, string)</dt>	<dt>csr (required, string):</dt>
	<dd>	<dd>
	The CSR in the base64url-encoded version of the DER format.	The CSR in the base64url-encoded version of the DER format.

	(Note: Because this field uses base64url, and does not include heade rs, it is different from PEM.)	(Note: Because this field uses base64url, and does not include heade rs, it is different from Privacy Enhanced Mail (PEM).)
	</dd>	</dd>
	</dl>	</dl>

	<sourcecode type="http">
		<!--[rfced] Please note that sourcecode elements in this document
		exceed our character limit (see
		https://authors.ietf.org/en/drafting-in-plaintext for the 69
		character limit on sourcecode elements). Please review
		throughout the document and let us know how these may be changed
		(or feel free to update/replace in the edited XML file yourself
		if this is more convenient).-->

		<sourcecode type="http"><![CDATA[
	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"
	}	}

	</sourcecode>	]]></sourcecode>
	<t>When presented with the CSR the server verifies it in the following m	<t>When presented with the CSR, the server verifies it in the following
	anner:</t>	manner:</t>
	<ol>	<ol>
	<li>The CSR is a well formatted PKCS#10 request.</li>	<li>The CSR is a well formatted PKCS#10 request.</li>
	<li>The public key in the CSR corresponds to the ".onion" Special-Use Domain Name being validated.</li>	<li>The public key in the CSR corresponds to the ".onion" Special-Use Domain Name being validated.</li>
	<li>The signature over the CSR validates with the ".onion" Special-Use Domain Name public key.</li>	<li>The signature over the CSR validates with the ".onion" Special-Use Domain Name public key.</li>

	<li>The caSigningNonce attribute is present and its contents matches t he nonce provided to the client.</li>	<li>The caSigningNonce attribute is present and its contents match the nonce provided to the client.</li>
	<li>The applicantSigningNonce attribute is present and contains at lea st 64 bits of entropy.</li>	<li>The applicantSigningNonce attribute is present and contains at lea st 64 bits of entropy.</li>
	</ol>	</ol>
	<t>If all of the above are successful then validation succeeds, otherwis e it has failed.</t>	<t>If all of the above are successful then validation succeeds, otherwis e it has failed.</t>
	</section>	</section>
	</section>	</section>

	<section anchor="client-auth">	<section anchor="client-auth">

	<name>Client authentication to hidden services</name>	<name>Client Authentication to Hidden Services</name>
	<t>Some hidden services do not wish to be accessible to the entire Tor net	<t>Some hidden services do not wish to be accessible to the entire Tor net
	work, and so encrypt their hidden	work, and so they encrypt their hidden
	service descriptor with the keys of clients authorized to connect. Witho ut a way for the CA to signal what key	service descriptor with the keys of clients authorized to connect. Witho ut a way for the CA to signal what key

	it will use to connect these services will not be able to obtain a certi ficate using http-01 or tls-alpn-01,	it will use to connect, these services will not be able to obtain a cert ificate using http-01 or tls-alpn-01,
	nor enforce CAA with any validation method.</t>	nor enforce CAA with any validation method.</t>
	<t>To this end, an additional field in the challenge object is defined to allow the ACME server to advertise the	<t>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 use (as per	Ed25519 public key it will use (as per the <eref target="https://spec.to
	<xref target="tor-spec" section=""Authentication during the introdu	rproject.org/rend-spec/introduction-protocol.html#INTRO-AUTH">"Authentication du
	ction phase"" relative="#INTRO-AUTH" />) to	ring the introduction phase"</eref> section of
		<xref target="tor-spec"/>) to
	authenticate itself when retrieving the hidden service descriptor.</t>	authenticate itself when retrieving the hidden service descriptor.</t>
	<dl>	<dl>

	<dt>authKey (optional, object)</dt>	<dt>authKey (optional, object):</dt>
	<dd>The ACME server's Ed25519 public key encoded as per <xref target="RF C8037"/>.</dd>	<dd>The ACME server's Ed25519 public key encoded as per <xref target="RF C8037"/>.</dd>
	</dl>	</dl>
	<t>ACME servers <bcp14>MUST NOT</bcp14> use the same public key with multi ple hidden services.	<t>ACME servers <bcp14>MUST NOT</bcp14> use the same public key with multi ple hidden services.

	ACME servers <bcp14>MAY</bcp14> re-use public keys for re-validation of	ACME servers <bcp14>MAY</bcp14> reuse public keys for re-validation of t
	the same hidden service.</t>	he same hidden service.</t>
	<t>There is no method to communicate to the CA that client authentication	<t>There is no method to communicate to the CA that client authentication
	is necessary; instead the ACME server	is necessary; instead, the ACME server
	<bcp14>MUST</bcp14> attempt to calculate its CLIENT-ID as per	<bcp14>MUST</bcp14> attempt to calculate its CLIENT-ID as per the <eref
	<xref target="tor-spec" section=""Client Behavior"" relative="	target="https://spec.torproject.org/rend-spec/hsdesc-encrypt.html#FIRST-LAYER-CL
	#FIRST-LAYER-CLIENT-BEHAVIOR"/>.	IENT-BEHAVIOR">"Client behavior"</eref> section of
	If no <tt>auth-client</tt> line in the first layer hidden service descri	<xref target="tor-spec"/>.
	ptor matches the computed client-id	If no <tt>auth-client</tt> line in the first layer hidden service descri
		ptor matches the computed client-id,
	then the server <bcp14>MUST</bcp14> assume that the hidden service does not require client authentication and	then the server <bcp14>MUST</bcp14> assume that the hidden service does not require client authentication and
	proceed accordingly.</t>	proceed accordingly.</t>

	<t>In the case the Ed25519 public key is novel to the client it will have to resign and republish its hidden service	<t>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 <bcp14>MUST</bcp14> wait some (indeterminate) amount of t ime for the new descriptor to	descriptor. It <bcp14>MUST</bcp14> wait some (indeterminate) amount of t ime for the new descriptor to

	propagate the Tor hidden service directory servers, before proceeding wi th responding to the challenge.	propagate the Tor hidden service directory servers before proceeding wit h responding to the challenge.
	This should take no more than a few minutes. This specification does not set a fixed time as changes in the	This should take 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 propagation time in the fut ure. ACME servers	operation of the Tor network can affect this propagation time in the fut ure. ACME servers

	<bcp14>MUST NOT</bcp14> expire challenges before a reasonable time to al	<bcp14>MUST NOT</bcp14> expire challenges before a reasonable time to al
	low publication of the new descriptor -	low publication of the new descriptor. It is <bcp14>RECOMMENDED</bcp14> the serv
	it is <bcp14>RECOMMENDED</bcp14> the server allow at least 30 minutes; h	er allow at least 30 minutes; however, it is entirely up to operator preference.
	owever it is entirely up to operator preference.</t>	</t>
	</section>	</section>

	<section>	<section>

	<name>ACME over hidden services</name>	<name>ACME over Hidden Services</name>
	<t>A CA offering certificates to ".onion" Special-Use Domain Names <bcp14> SHOULD</bcp14> make their	<t>A CA offering certificates to ".onion" Special-Use Domain Names <bcp14> SHOULD</bcp14> make their

	ACME server available as a Tor hidden services. ACME clients <bcp14>SHOU LD</bcp14> also support connecting to	ACME server available as a Tor hidden service. ACME clients <bcp14>SHOUL D</bcp14> also support connecting to
	ACME servers over Tor, regardless of their support of "onion-csr-01", as their existing "http-01"	ACME servers over Tor, regardless of their support of "onion-csr-01", as their existing "http-01"
	and "tls-alpn-01" implementations could be used to obtain certificates f or ".onion" Special-Use Domain Names.</t>	and "tls-alpn-01" implementations could be used to obtain certificates f or ".onion" Special-Use Domain Names.</t>
	</section>	</section>

	<section anchor="caa">	<section anchor="caa">
	<name>Certification Authority Authorization (CAA)</name>	<name>Certification Authority Authorization (CAA)</name>

	<t>".onion" Special-Use Domain Name are not part of the DNS, and as such a variation on CAA <xref target="RFC8659"/>	<t>".onion" Special-Use Domain Names are not part of the DNS; as such, a v ariation on CAA <xref target="RFC8659"/>
	is necessary to allow restrictions to be placed on certificate issuance. </t>	is necessary to allow restrictions to be placed on certificate issuance. </t>

	<t>To this end a new field is added to the second layer hidden service des	<t>To this end, a new field is added to the second layer hidden service de
	criptor as defined in	scriptor, as defined in the <eref target="https://spec.torproject.org/rend-spec/
	<xref target="tor-spec" section=""Second layer plaintext format&quo	hsdesc-encrypt.html#second-layer-plaintext">"Second layer plaintext format"</ere
	t;" relative="#second-layer-plaintext" />	f> section of
	with the following format (defined using the notation from	<xref target="tor-spec"/>
	<xref target="tor-spec" section=""Document meta-format"" relat	with the following format (defined using the notation from the <eref tar
	ive="#metaformat"/>):</t>	get="https://spec.torproject.org/dir-spec/netdoc.html">"netdoc document meta-for
	<sourcecode>	mat"</eref> section of
		<xref target="tor-spec"/>):</t>
		<sourcecode><![CDATA[
	"caa" SP flags SP tag SP value NL	"caa" SP flags SP tag SP value NL
	[Any number of times]	[Any number of times]

	</sourcecode>	]]></sourcecode>
	<t>The presentation format is provided above purely for the convenience of	<t>The presentation format is provided above purely for the convenience of
	the reader and implementors,	the reader and implementors:
	the canonical version remains that defined in <xref target="RFC8659" sec tion="4.1.1"/>,	the canonical version remains that defined in <xref target="RFC8659" sec tion="4.1.1"/>,
	or future updates to the same.</t>	or future updates to the same.</t>

	<t>The contents of "flag", "tag", and "value" are as per <xref target="RFC
	8659" section="4.1.1"/>.	<!--[rfced] Please note that we have updated to use "flags" (plural)
		to match the use in Section 4.1.1 of RFC 8659. Please let us
		know any objections.

		Original:
		The contents of "flag", "tag", and "value" are as per Section 4.1.1
		of [RFC8659].

		Current:
		The contents of "flags", "tag", and "value" are as per Section 4.1.1
		of [RFC8659].

		-->
		<t>The contents of "flags", "tag", and "value" are as per <xref target="RF
		C8659" section="4.1.1"/>.
	Multiple CAA records <bcp14>MAY</bcp14> be present, as is the case in th e DNS. CAA records in a hidden service	Multiple CAA records <bcp14>MAY</bcp14> be present, as is the case in th e 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 ".onion" Special-Use Domain Name.</t>	descriptor are to be treated the same by CAs as if they had been in the DNS for the ".onion" Special-Use Domain Name.</t>
	<t>A hidden service's second layer descriptor using CAA could look somethi ng like the following	<t>A hidden service's second layer descriptor using CAA could look somethi ng like the following

	(additional linebreaks have been added for readability):</t>	(additional line breaks have been added for readability):</t>
	<sourcecode>	<sourcecode><![CDATA[
	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=
	...	...

	</sourcecode>	]]></sourcecode>
	<section>	<section>
	<name>Relevant Resource Record Set</name>	<name>Relevant Resource Record Set</name>

	<t>In the absence of the possibility for delegation of subdomains from a	<t>In the absence of the possibility for delegation of subdomains from a
	".onion" Special-Use Domain Name as	".onion" Special-Use Domain Name, as
	there is in the DNS there is no need, nor indeed any method available,	there is in the DNS, there is no need, nor indeed any method available
	to search up the DNS tree for a	, to search up the DNS tree for a
	relevant CAA record set. Similarly, it is also impossible to check CAA	relevant CAA record set. Similarly, it is also impossible to check CAA
	records on the "onion" Special-Use TLD,	records on the "onion" Special-Use Top-Level Domain (TLD),
	as it does not exist in any form except as described in <xref target="	as it does not exist in any form except as described in <xref target="
	RFC7686"/>, so implementors	RFC7686"/>; therefore, implementors
	<bcp14>MUST NOT</bcp14> look here either.</t>	<bcp14>MUST NOT</bcp14> look there either.</t>
	<t>Instead all subdomains under a ".onion" Special-Use Domain Name share	<t>Instead, all subdomains under a ".onion" Special-Use Domain Name shar
	the same CAA record set. That is,	e the same CAA record set. That is,
	all of these share a CAA record set with "a.onion":</t>	all of these share a CAA record set with "a.onion":</t>
	<ul>	<ul>
	<li>b.a.onion</li>	<li>b.a.onion</li>
	<li>c.a.onion</li>	<li>c.a.onion</li>
	<li>e.d.a.onion</li>	<li>e.d.a.onion</li>
	</ul>	</ul>
	<t>but these do not:</t>	<t>but these do not:</t>
	<ul>	<ul>
	<li>b.c.onion</li>	<li>b.c.onion</li>
	<li>c.d.onion</li>	<li>c.d.onion</li>
	<li>e.c.d.onion</li>	<li>e.c.d.onion</li>
	<li>a.b.onion</li>	<li>a.b.onion</li>
	</ul>	</ul>
	</section>	</section>
	<section>	<section>

	<name>When to check CAA</name>	<name>When to Check CAA</name>
	<t>If the hidden service has client authentication enabled then it will	<t>If the hidden service has client authentication enabled, then it will
	be impossible for the ACME server to	be impossible for the ACME server to
	decrypt the second layer descriptor to read the CAA records until the ACME server's public key has been added	decrypt the second layer descriptor to read the CAA records until the ACME server's public key has been added

	to the first layer descriptor. To this end an ACME server <bcp14>MUST<	to the first layer descriptor. To this end, an ACME server <bcp14>MUST
	/bcp14> wait until the client responds	</bcp14> wait until the client responds
	to an authorization before checking CAA, and treat this response as in	to an authorization before checking the CAA and treat this response as
	dication that their public key has been	an indication that their public key has been
	added and that the ACME server will be able to decrypt the second laye r descriptor.</t>	added and that the ACME server will be able to decrypt the second laye r descriptor.</t>
	</section>	</section>
	<section>	<section>

	<name>Preventing mis-issuance by unknown CAs</name>	<name>Preventing Mis-Issuance by Unknown CAs</name>
	<t>In the case of a hidden service requiring client authentication the C	<t>In the case of a hidden service requiring client authentication, the
	A will be unable to read the hidden	CA will be unable to read the hidden
	service's CAA records without the hidden service trusting an ACME serv	service's CAA records without the hidden service trusting an ACME serv
	er's public key - as the CAA records are	er's public key -- as the CAA records are
	in the second layer descriptor. A method is necessary to signal that t here are CAA records present	in the second layer descriptor. A method is necessary to signal that t here are CAA records present

	(but not reveal their contents which - in certain circumstances - woul d unwantedly disclose information	(but not reveal their contents, which, in certain circumstances, would unwantedly disclose information
	about the hidden service operator).</t>	about the hidden service operator).</t>

	<t>To this end a new field is added to the first layer hidden service de	<t>To this end, a new field is added to the first layer hidden service d
	scriptor	escriptor in the <eref target="https://spec.torproject.org/rend-spec/hsdesc-encr
	<xref target="tor-spec" section=""First layer plaintext format&qu	ypt.html#first-layer-plaintext">"First layer plaintext format"</eref> section of
	ot;" relative="#first-layer-plaintext" />	<xref target="tor-spec"/>
	with the following format (defined using the notation from	with the following format (defined using the notation from the <eref t
	<xref target="tor-spec" section=""Document meta-format"" relat	arget="https://spec.torproject.org/dir-spec/netdoc.html">"netdoc document meta-f
	ive="#metaformat"/>):</t>	ormat"</eref> section of
	<sourcecode>	<xref target="tor-spec"/>):</t>
		<sourcecode><![CDATA[
	"caa-critical" NL	"caa-critical" NL
	[At most once]	[At most once]

	</sourcecode>	]]></sourcecode>
	<t>If an ACME server encounters this flag it <bcp14>MUST NOT</bcp14> pro	<t>If an ACME server encounters this flag, it <bcp14>MUST NOT</bcp14> pr
	ceed with issuance until it can decrypt	oceed with issuance until it can decrypt
	and parse the CAA records from the second layer descriptor.</t>	and parse the CAA records from the second layer descriptor.</t>
	</section>	</section>
	<section>	<section>

	<name>Alternative in-band presentation of CAA</name>	<name>Alternative In-Band Presentation of CAA</name>
	<t>An ACME server might be unwilling to operate the infrastructure requi red to fetch, decode, and verify Tor	<t>An ACME server might be unwilling to operate the infrastructure requi red to fetch, decode, and verify Tor
	hidden service descriptors in order to check CAA records. To this end a method to signal CAA policies in-band	hidden service descriptors in order to check CAA records. To this end a method to signal CAA policies in-band
	of ACME is defined.</t>	of ACME is defined.</t>

	<t>If a hidden service does use this method to provide CAA records to an ACME server it <bcp14>SHOULD</bcp14>	<t>If a hidden service does use this method to provide CAA records to an ACME server, it <bcp14>SHOULD</bcp14>
	still publish CAA records if its CAA record set includes "iodef", "con tactemail", or "contactphone" so that	still publish CAA records if its CAA record set includes "iodef", "con tactemail", or "contactphone" so that
	this information is still publicly accessible. A hidden service operat or <bcp14>MAY</bcp14> also not wish to	this information is still publicly accessible. A hidden service operat or <bcp14>MAY</bcp14> also not wish to
	publish a CAA record set in its service descriptor to avoid revealing information about the service operator.</t>	publish a CAA record set in its service descriptor to avoid revealing information about the service operator.</t>

	<t>If an ACME server receives a validly signed CAA record set in the fin	<t>If an ACME server receives a validly signed CAA record set in the fin
	alize request it <bcp14>MAY</bcp14>	alize request, it <bcp14>MAY</bcp14>
	proceed with issuance on the basis of the client provided CAA record s	proceed with issuance on the basis of the client-provided CAA record s
	et only without checking the CAA set in	et only, without checking the CAA set in
	the hidden service. Alternatively, an ACME server <bcp14>MAY</bcp14> i gnore the client provided record set and fetch the record set from	the hidden service. Alternatively, an ACME server <bcp14>MAY</bcp14> i gnore the client provided record set and fetch the record set from

	the service descriptor. In any case, the server always MAY fetch	the service descriptor.

		<!--[rfced] In the following instances, please review the use of the
		BCP 14 keyword with the surrounding text (i.e., also and always
		specifically).

		Original:

		A hidden service operator MAY also not wish to publish a CAA record
		set in its service descriptor to avoid revealing information about the
		service operator.

		Perhaps:
		Also, a hidden service operator MAY not wish to publish a CAA record
		set in its service descriptor to avoid revealing information about the
		service operator.

		Original:
		In any case, the server always MAY fetch the record set from the
		service descriptor.

		Perhaps:
		In any case, the server MAY fetch the record set from the
		service descriptor.

		-->
		In any case, the server always <bcp14>MAY</bcp14> fetch
	the record set from the service descriptor.	the record set from the service descriptor.

	If an ACME server receives a validly signed CAA record set in the fina	If an ACME server receives a validly signed CAA record set in the fina
	lize request it need not check the CAA	lize request, it need not check the CAA
	set in the hidden service descriptor and can proceed with issuance on	set in the hidden service descriptor and can proceed with issuance on
	the basis of the client provided CAA	the basis of the client-provided CAA
	record set only. An ACME server <bcp14>MAY</bcp14> ignore the client p	record set only. An ACME server <bcp14>MAY</bcp14> ignore the client-p
	rovided record set, and is free to	rovided record set and is free to
	always fetch the record set from the service descriptor.</t>	always fetch the record set from the service descriptor.</t>
	<t>A new field is defined in the ACME finalize endpoint to contain the h idden service's CAA record set for each	<t>A new field is defined in the ACME finalize endpoint to contain the h idden service's CAA record set for each
	".onion" Special-Use Domain Name in the order.</t>	".onion" Special-Use Domain Name in the order.</t>
	<dl>	<dl>

	<dt>onionCAA (optional, dictionary of objects)</dt>	<dt>onionCAA (optional, dictionary of objects):</dt>
	<dd>	<dd>
	The CAA record set for each ".onion" Special-Use Domain Name in the order. The key is the ".onion"	The CAA record set for each ".onion" Special-Use Domain Name in the order. The key is the ".onion"

	Special-Use Domain Name, and the value is an object with the followi ng fields.	Special-Use Domain Name, and the value is an object with the fields described below.
	</dd>	</dd>


	</dl>	</dl>

	<t>The contents of the values of the "onionCAA" object are:</t>	<t>The contents of the values of the "onionCAA" object are as follows:</ t>
	<dl>	<dl>

	<dt>caa (required, string or null)</dt>	<dt>caa (required, string or null):</dt>
	<dd>	<dd>
	The CAA record set as a string, encoded in the same way as if was in cluded in the hidden service descriptor.	The CAA record set as a string, encoded in the same way as if was in cluded in the hidden service descriptor.

	If the hidden service does not have a CAA record set then this <bcp1 4>MUST</bcp14> be null.	If the hidden service does not have a CAA record set, then this <bcp 14>MUST</bcp14> be null.
	</dd>	</dd>

	<dt>expiry (required, integer)</dt>	<dt>expiry (required, integer):</dt>
	<dd>	<dd>
	The Unix timestamp at which this CAA record set will expire. This <b cp14>SHOULD NOT</bcp14> be more than	The Unix timestamp at which this CAA record set will expire. This <b cp14>SHOULD NOT</bcp14> be more than
	8 hours in the future. ACME servers <bcp14>MUST</bcp14> process this as at least a 64-bit integer to ensure	8 hours in the future. ACME servers <bcp14>MUST</bcp14> process this as at least a 64-bit integer to ensure
	functionality beyond 2038.	functionality beyond 2038.
	</dd>	</dd>

	<dt>signature (required, string)</dt>	<dt>signature (required, string):</dt>
	<dd>	<dd>
	The Ed25519 signature of the CAA record set using the private key co rresponding to the ".onion"	The Ed25519 signature of the CAA record set using the private key co rresponding to the ".onion"
	Special-Use Domain Name, encoded using base64url. The signature is d efined below.	Special-Use Domain Name, encoded using base64url. The signature is d efined below.
	</dd>	</dd>
	</dl>	</dl>
	<t>The data that the signature is calculated over is the concatenation o f the following,	<t>The data that the signature is calculated over is the concatenation o f the following,
	encoded in UTF-8 <xref target="RFC3629"/>:</t>	encoded in UTF-8 <xref target="RFC3629"/>:</t>

	<sourcecode>"onion-caa\|" \|\| expiry \|\| "\|" \|\| caa</sourcecode>	<sourcecode><![CDATA["onion-caa\|" \|\| expiry \|\| "\|" \|\| caa]]></sourcecode
		>

	<t>Where "\|" is the ASCII character 0x7C, and expiry is the expiry field as a decimal string with no	<t>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 it is represented as an empty string in the signature calculation.</t>	leading zeros. If the caa field is null, it is represented as an empty string in the signature calculation.</t>
	<section>	<section>

	<name>ACME servers requiring in-band CAA</name>	<name>ACME Servers Requiring In-Band CAA</name>
	<t>If an ACME server does not support fetching a service's CAA record
	set from its service descriptor it,	<!--[rfced] We have deleted the "it" before the comma in this
	and the ACME client does not provide an "onionCAA" object in its fin	sentence. Please let us know if some other rephrase was
	alize request the ACME server	intended.

		Original:
		If an ACME server does not support fetching a service's CAA record
		set from its service descriptor it, and the ACME client does not
		provide an "onionCAA" object in its finalize request the ACME server
		MUST respond with an "onionCAARequired" error to indicate this.

		Current:
		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 an "onionCAA" object in its finalize request, the ACME server
		MUST respond with an "onionCAARequired" error to indicate this.

		-->

		<t>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 an "onionCAA" object in its fin
		alize request, the ACME server
	<bcp14>MUST</bcp14> respond with an "onionCAARequired" error to indi cate this.</t>	<bcp14>MUST</bcp14> respond with an "onionCAARequired" error to indi cate this.</t>

	<t>To support signalling the server's support for fetching CAA record sets over Tor,	<t>To support signaling the server's support for fetching CAA record s ets over Tor,
	a new field is defined in the directory "meta" object to signal this .</t>	a new field is defined in the directory "meta" object to signal this .</t>
	<dl>	<dl>

	<dt>inBandOnionCAARequired (optional, boolean)</dt>	<dt>inBandOnionCAARequired (optional, boolean):</dt>
	<dd>	<dd>
	If true, the ACME server requires the client to provide the CAA re cord set in the finalize request.	If true, the ACME server requires the client to provide the CAA re cord set in the finalize request.

	If false or absent the ACME server does not require the client to provide the CAA record set is this	If false or absent, the ACME server does not require the client to provide the CAA record set is this
	manner.</dd>	manner.</dd>
	</dl>	</dl>

	<t>A directory of such a CA could look like</t>	<t>A directory of such a CA could look like the following:</t>
	<sourcecode type="http">	<sourcecode type="http"><![CDATA[
	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
	}	}
	}	}

	</sourcecode>	]]></sourcecode>
	</section>	</section>
	<section>	<section>

	<name>Example in-band CAA</name>	<name>Example In-Band CAA</name>
	<t>Given the following example CAA record set for 5anebu2glyc235wbbop3 m2ukzlaptpkq333vdtdvcjpigyb7x2i2m2qd.onion	<t>Given the following example CAA record set for 5anebu2glyc235wbbop3 m2ukzlaptpkq333vdtdvcjpigyb7x2i2m2qd.onion

	(additional linebreaks have been added for readability):</t>	(additional line breaks have been added for readability):</t>
	<sourcecode>	<sourcecode><![CDATA[
	caa 128 issue "acmeforonions.example;	caa 128 issue "acmeforonions.example;
	validationmethods=onion-csr-01"	validationmethods=onion-csr-01"
	caa 0 iodef "mailto:example@example.com"	caa 0 iodef "mailto:example@example.com"

	</sourcecode>	]]></sourcecode>
	<t>The following would be submitted to the ACME server's finalize endp oint	<t>The following would be submitted to the ACME server's finalize endp oint

	(additional linebreaks have been added for readability):</t>	(additional line breaks have been added for readability):</t>
	<sourcecode type="http">	<sourcecode type="http"><![CDATA[
	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"

	skipping to change at line 477 ¶	skipping to change at line 604 ¶
	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,
	"signature": "u_iP6JZ4JZBrzQUKH6lSrWejjRfeQmkTuehc0_FaaTNP	"signature": "u_iP6JZ4JZBrzQUKH6lSrWejjRfeQmkTuehc0_FaaTNP
	AV0RVxpUz9r44DRdy6kgy0ofnx18KIhMrP7N1wpxAA=="	AV0RVxpUz9r44DRdy6kgy0ofnx18KIhMrP7N1wpxAA=="
	}	}
	}	}
	}),	}),
	"signature": "uOrUfIIk5RyQ...nw62Ay1cl6AB"	"signature": "uOrUfIIk5RyQ...nw62Ay1cl6AB"
	}	}

	</sourcecode>	]]></sourcecode>
	</section>	</section>
	</section>	</section>
	</section>	</section>

	<section anchor="IANA">	<section anchor="IANA">
	<name>IANA Considerations</name>	<name>IANA Considerations</name>


		<!--[rfced] Please note that any changes affecting IANA registries
		will be communicated to IANA by the RPC once AUTH48 completes.-->

	<section>	<section>
	<name>Validation Methods</name>	<name>Validation Methods</name>

	<t>Per this document, one new entry has been added to the "ACME Validati
	on Methods" registry defined in	<t>One new entry has been added to the "ACME Validation Methods" registr
		y that was defined in
	<xref target="RFC8555" section="9.7.8"/>	<xref target="RFC8555" section="9.7.8"/>

	(<eref target="https://www.iana.org/assignments/acme/acme.xhtml#acme-v	(<eref brackets="angle" target="https://www.iana.org/assignments/acme"
	alidation-methods"/>).	/>).</t>
	This entry is defined below:</t>
	<table>	<table>

	<name>New entry</name>	<name>onion-csr-01 Validation Method</name>
	<thead>	<thead>
	<tr>	<tr>
	<th>Label</th>	<th>Label</th>
	<th>Identifier Type</th>	<th>Identifier Type</th>
	<th>ACME</th>	<th>ACME</th>
	<th>Reference</th>	<th>Reference</th>
	</tr>	</tr>
	</thead>	</thead>
	<tbody>	<tbody>
	<tr>	<tr>
	<td>onion-csr-01</td>	<td>onion-csr-01</td>
	<td>dns</td>	<td>dns</td>
	<td>Y</td>	<td>Y</td>
	<td>This document</td>	<td>This document</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>
	</section>	</section>
	<section>	<section>
	<name>Error Types</name>	<name>Error Types</name>

	<t>Per this document, one new entry has been added to the "ACME Error Ty
	pes" registry defined in	<!-- [rfced] Please note that we believe Section 9.7.8 should actually
	<xref target="RFC8555" section="9.7.8"/>	read 9.8.4 in the following. Please review and confirm our
	(<eref target="https://www.iana.org/assignments/acme/acme.xhtml#acme-e	update.
	rror-types"/>).
	This entry is defined below:</t>	Original:
		Per this document, one new entry has been added to the "ACME
		Validation Methods" registry defined in Section 9.7.8 of [RFC8555]...

		Current:
		Per this document, one new entry has been added to the "ACME
		Validation Methods" registry defined in Section 9.7.4 of [RFC8555]...

		-->
		<t>One new entry has been added to the "ACME Error Types" registry that
		was defined in
		<xref target="RFC8555" section="9.7.4"/>
		(<eref brackets="angle" target="https://www.iana.org/assignments/acme"
		/>).</t>
	<table>	<table>

	<name>New entry</name>	<name>onionCAARequired Error Type</name>
	<thead>	<thead>
	<tr>	<tr>
	<th>Type</th>	<th>Type</th>
	<th>Description</th>	<th>Description</th>
	<th>Reference</th>	<th>Reference</th>
	</tr>	</tr>
	</thead>	</thead>
	<tbody>	<tbody>
	<tr>	<tr>
	<td>onionCAARequired</td>	<td>onionCAARequired</td>

	<td>The CA only supports checking CAA for hidden services in-band, but the client has not provided an	<td>The CA only supports checking the CAA for hidden services in-b and, but the client has not provided an
	in-band CAA</td>	in-band CAA</td>
	<td>This document</td>	<td>This document</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>
	</section>	</section>
	<section>	<section>
	<name>Directory Metadata Fields</name>	<name>Directory Metadata Fields</name>

	<t>Per this document, one new entry has been added to the "ACME Director
	y Metadata Fields" registry defined in	<!-- [rfced] We believe "ACME Directory Metadata Fields" registry is
	<xref target="RFC8555" section="9.7.8"/>	defined in Section 9.7.6 of [RFC8555], not Section 9.7.8. Please
	(<eref target="https://www.iana.org/assignments/acme/acme.xhtml#acme-d	confirm our update.
	irectory-metadata-fields"/>).	-->
	This entry is defined below:</t>
		<t>One new entry has been added to the "ACME Directory Metadata Fields"
		registry that was defined in
		<xref target="RFC8555" section="9.7.6"/>
		(<eref brackets="angle" target="https://www.iana.org/assignments/acme"
		/>).</t>
	<table>	<table>

	<name>New entry</name>	<name>onionCAARequired Metadata Field</name>
	<thead>	<thead>
	<tr>	<tr>
	<th>Field name</th>	<th>Field name</th>
	<th>Field type</th>	<th>Field type</th>
	<th>Reference</th>	<th>Reference</th>
	</tr>	</tr>
	</thead>	</thead>
	<tbody>	<tbody>
	<tr>	<tr>
	<td>onionCAARequired</td>	<td>onionCAARequired</td>

	skipping to change at line 564 ¶	skipping to change at line 713 ¶
	<td>This document</td>	<td>This document</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>
	</section>	</section>
	</section>	</section>

	<section anchor="Security">	<section anchor="Security">
	<name>Security Considerations</name>	<name>Security Considerations</name>
	<section>	<section>

	<name>Security of the "onion-csr-01" challenge</name>	<name>Security of the "onion-csr-01" Challenge</name>
	<t>The security considerations of <xref target="cabf-br"/> apply to issu ance using the CSR method.</t>	<t>The security considerations of <xref target="cabf-br"/> apply to issu ance using the CSR method.</t>
	</section>	</section>
	<section anchor="security-id-dns">	<section anchor="security-id-dns">

	<name>Use of "dns" identifier type</name>	<name>Use of the "dns" Identifier Type</name>
	<t>The re-use of the "dns" identifier type for a Special-Use Domain Name	<t>The reuse of the "dns" identifier type for a Special-Use Domain Name
	not actually in the DNS infrastructure	not actually in the DNS infrastructure
	raises questions regarding its suitability. The reasons to pursue this path in the first place are detailed in	raises questions regarding its suitability. The reasons to pursue this path in the first place are detailed in
	<xref target="use-of-id-dns"/>. It is felt that there is little securi ty concern in reuse of the "dns"	<xref target="use-of-id-dns"/>. It is felt that there is little securi ty concern in reuse of the "dns"

	identifier type with regards the mis-issuance by CAs that are not awar	identifier type with regard to the mis-issuance by CAs that are not aw
	e of ".onion"	are of ".onion"
	Special-Use Domain Names, as CAs would not be able to resolve the iden	Special-Use Domain Names as CAs would not be able to resolve the ident
	tifier in the DNS.</t>	ifier in the DNS.</t>
	<section>	<section>
	<name>"http-01" Challenge</name>	<name>"http-01" Challenge</name>

	<t>In the absence of knowledge of this document a CA would follow the	<t>In the absence of knowledge of this document, a CA would follow the
	procedure set out in	procedure set out in
	<xref target="RFC8555" section="8.3"/> which specifies that the CA s	<xref target="RFC8555" section="8.3"/>, which specifies that the CA
	hould "Dereference the URL using an	should "Dereference the URL using an
	HTTP GET request". Given that ".onion" Special-Use Domain Names requ ire special handling to dereference,	HTTP GET request". Given that ".onion" Special-Use Domain Names requ ire special handling to dereference,

	this de-referencing will fail, disallowing issuance.</t>	this dereferencing will fail, disallowing issuance.</t>
	</section>	</section>
	<section>	<section>
	<name>"tls-alpn-01" Challenge</name>	<name>"tls-alpn-01" Challenge</name>

	<t>In the absence of knowledge of this document a CA would follow the	<t>In the absence of knowledge of this document, a CA would follow the
	procedure set out in	procedure set out in
	<xref target="RFC8737" section="3"/> which specifies that the CA "re	<xref target="RFC8737" section="3"/>, which specifies that the CA "r
	solves the domain name being validated	esolves the domain name being validated
	and chooses one of the IP addresses returned for validation". Given that ".onion" Special-Use Domain Names	and chooses one of the IP addresses returned for validation". Given that ".onion" Special-Use Domain Names

	are not resolvable to IP addresses, this de-referencing will fail, d isallowing issuance.</t>	are not resolvable to IP addresses, this dereferencing will fail, di sallowing issuance.</t>
	</section>	</section>
	<section>	<section>
	<name>"dns-01" Challenge</name>	<name>"dns-01" Challenge</name>

	<t>In the absence of knowledge of this document a CA would follow the	<t>In the absence of knowledge of this document, a CA would follow the
	procedure set out in	procedure set out in
	<xref target="RFC8555" section="8.4"/> which specifies that the CA s	<xref target="RFC8555" section="8.4"/>, which specifies that the CA
	hould "query for TXT records for the	should "query for TXT records for the
	validation domain name". Given that ".onion" Special-Use Domain Name s are not present in the DNS	validation domain name". Given that ".onion" Special-Use Domain Name s are not present in the DNS
	infrastructure, this query will fail, disallowing issuance.</t>	infrastructure, this query will fail, disallowing issuance.</t>
	</section>	</section>
	</section>	</section>
	<section>	<section>
	<name>Key Authorization with "onion-csr-01"</name>	<name>Key Authorization with "onion-csr-01"</name>
	<t>The "onion-csr-01" challenge does not make use of the key authorizati on string defined in	<t>The "onion-csr-01" challenge does not make use of the key authorizati on string defined in
	<xref target="RFC8555" section="8.1"/>. This does not weaken the integ rity of authorizations.</t>	<xref target="RFC8555" section="8.1"/>. This does not weaken the integ rity of authorizations.</t>

	<t>The key authorization exists to ensure that whilst an attacker observ ing the validation channel can observe	<t>The key authorization exists to ensure that, whilst an attacker obser ving the validation channel can observe
	the correct validation response, they cannot compromise the integrity of authorizations as the response	the correct validation response, they cannot compromise the integrity of authorizations as the response
	can only be used with the account key for which it was generated. As t he validation channel for this challenge	can only be used with the account key for which it was generated. As t he validation channel for this challenge
	is ACME itself, and ACME already requires that the request be signed b y the account, the key authorization is	is ACME itself, and ACME already requires that the request be signed b y the account, the key authorization is
	not necessary.</t>	not necessary.</t>
	</section>	</section>
	<section>	<section>

	<name>Use of Tor for non-".onion" domains</name>	<name>Use of Tor for Domains That Are Not ".onion"</name>
	<t>An ACME server <bcp14>MUST NOT</bcp14> utilise Tor for the validation	<t>An ACME server <bcp14>MUST NOT</bcp14> utilize Tor for the validation
	of non-".onion" domains, due to the	of domains that are not ".onion", due to the
	risk of exit hijacking <xref target="spoiled-onions"/>.</t>	risk of exit hijacking <xref target="spoiled-onions"/>.</t>
	</section>	</section>
	<section>	<section>
	<name>Redirects with "http-01"</name>	<name>Redirects with "http-01"</name>
	<t>A site <bcp14>MAY</bcp14> redirect to another site when completing va lidation using the "http-01" challenge.	<t>A site <bcp14>MAY</bcp14> redirect to another site when completing va lidation using the "http-01" challenge.

	This redirect <bcp14>MAY</bcp14> be to either another ".onion" Special	This redirect <bcp14>MAY</bcp14> be to either another ".onion" Special
	-Use Domain Name, or to a domain in the public DNS.	-Use Domain Name or a domain in the public DNS.
	A site operator <bcp14>MUST</bcp14> consider the privacy implications	A site operator <bcp14>MUST</bcp14> consider the privacy implications
	of redirecting to a non-".onion"	of redirecting to a site that is not ".onion" -- namely that the ACME server ope
	site - namely that the ACME server operator will then be able to learn	rator will then be able to learn information about the site they were redirected
	information about the site redirected to	to
	that they would not if accessed via a ".onion" Special-Use Domain Name	that they would not have if accessed via a ".onion" Special-Use Domain
	, such as its IP address. If the site	Name, such as its IP address. If the site
	redirected to is on the same or an adjacent host to the ".onion" Speci	redirected to is on the same or an adjacent host to the ".onion" Speci
	al-Use Domain Name this reveals	al-Use Domain Name, this reveals
	information <xref target="tor-spec" section="Tor Rendezvous Specificat	information that the <eref target="https://spec.torproject.org/rend-sp
	ion - Version 3" relative="#tor-rendezvous-specification---version-3"/> was othe	ec/index.html">"Tor Rendezvous Specification - Version 3"</eref> secion of <xref
	rwise designed to protect.</t>	target="tor-spec"/> was otherwise designed to protect.</t>
	<t>If an ACME server receives a redirect to a domain in the public DNS i	<t>If an ACME server receives a redirect to a domain in the public DNS,
	t <bcp14>MUST NOT</bcp14> utilise Tor	it <bcp14>MUST NOT</bcp14> utilize Tor
	to make a connection to it, due to the risk of exit hijacking.</t>	to make a connection to it due to the risk of exit hijacking.</t>
	</section>	</section>
	<section>	<section>

	<name>Security of CAA records</name>	<name>Security of CAA Records</name>
	<t>The second layer descriptor is signed, encrypted and MACed in a way t
	hat only a party with access to the	<!--[rfced] Please review our update to this text to expand MAC and
		avoid using an abbreviation as a verb (see
		https://www.rfc-editor.org/styleguide/part2/#abbrev_as_verb). If
		this does not correctly capture your intent, please let us know
		how we may rephrase.

		Original:
		The second layer descriptor is signed, encrypted and MACed in a way
		that only a party with access to the secret key of the hidden service
		could manipulate what is published there.

		Current:
		The second layer descriptor is signed, encrypted, and encoded using
		Message Authentication Code (MAC) in a way that only a party with
		access to the secret key of the hidden service could manipulate
		what is published there.

		-->

		<t>The second layer descriptor is signed, encrypted, and encoded using M
		essage Authentication Code (MAC) in a way that only a party with access to the
	secret key of the hidden service could manipulate what is published th ere. For more information about this	secret key of the hidden service could manipulate what is published th ere. For more information about this

	process see <xref target="tor-spec" section=""Hidden service desc riptors: encryption format"" relative="#HS-DESC-ENC" />.</t>	process, see the <eref target="https://spec.torproject.org/rend-spec/h sdesc-encrypt.html">"Hidden service descriptors: encryption format"</eref> secti on of <xref target="tor-spec"/>.</t>
	</section>	</section>
	<section>	<section>

	<name>In-band CAA</name>	<name>In-Band CAA</name>
	<t>Tor directory servers are inherently untrusted entities, and as such
	there is no difference in the security	<!--[rfced] These sentences seem redundant. Please review.

		Original:

		Tor directory servers are inherently untrusted entities, and as such
		there is no difference in the security model for accepting CAA
		records directly from the ACME client or fetching them over Tor.
		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
		case.
		-->

		<t>Tor directory servers are inherently untrusted entities; as such, the
		re is no difference in the security
	model for accepting CAA records directly from the ACME client or fetch ing them over Tor. There is no	model for accepting CAA records directly from the ACME client or fetch ing them over Tor. There is no
	difference in the security model between accepting CAA records directl y from the ACME client and fetching them	difference in the security model between accepting CAA records directl y from the ACME client and fetching them
	over Tor; the CAA records are verified using the same hidden service k ey in either case.</t>	over Tor; the CAA records are verified using the same hidden service k ey in either case.</t>
	</section>	</section>
	<section>	<section>

	<name>Access of the Tor network</name>	<name>Access of the Tor Network</name>
	<t>The ACME server <bcp14>MUST</bcp14> make its own connection to the hi	<t>The ACME server <bcp14>MUST</bcp14> make its own connection to the hi
	dden service via the Tor network,	dden service via the Tor network
	and <bcp14>MUST NOT</bcp14> outsource this to a third-party service, s	and <bcp14>MUST NOT</bcp14> outsource this to a third-party service, s
	uch as by using Tor2Web.</t>	uch as Tor2Web.</t>
	</section>	</section>
	<section>	<section>

	<name>Anonymity of the ACME client</name>	<name>Anonymity of the ACME Client</name>
	<t>ACME clients requesting certificates for ".onion" Special-Use Domain Names not over the Tor network can	<t>ACME clients requesting certificates for ".onion" Special-Use Domain Names not over the Tor network can

	inadvertently expose to unintended parties the existence of a hidden s	inadvertently expose the existence of a hidden service on the host req
	ervice on the host requesting	uesting
	certificates to unintended parties - even when features such as ECH <x	certificates to unintended parties; this is true even when features su
	ref target="I-D.ietf-tls-esni"/> are	ch as Encrypted ClientHello (ECH) <xref target="I-D.ietf-tls-esni"/> are
	utilised, as the IP addresses of ACME servers are generally well-known	utilized, as the IP addresses of ACME servers are generally well-known
	, static, and not used for any other	, static, and not used for any other
	purpose.</t>	purpose.</t>
	<t>ACME clients <bcp14>SHOULD</bcp14> connect to ACME servers over the T or network to alleviate this, preferring	<t>ACME clients <bcp14>SHOULD</bcp14> connect to ACME servers over the T or network to alleviate this, preferring
	a hidden service endpoint if the CA provides such a service.</t>	a hidden service endpoint if the CA provides such a service.</t>

	<t>If an ACME client requests a publicly trusted WebPKI certificate it w ill expose the existence of the Hidden	<t>If an ACME client requests a publicly trusted WebPKI certificate, it will expose the existence of the Hidden
	Service publicly due to its inclusion in Certificate Transparency logs <xref target="RFC9162"/>. Hidden Service	Service publicly due to its inclusion in Certificate Transparency logs <xref target="RFC9162"/>. Hidden Service
	operators <bcp14>MUST</bcp14> consider the privacy implications of thi s before requesting WebPKI	operators <bcp14>MUST</bcp14> consider the privacy implications of thi s before requesting WebPKI

	certificates. ACME client developers <bcp14>SHOULD</bcp14> warn users about the risks of CT logged	certificates. ACME client developers <bcp14>SHOULD</bcp14> warn users about the risks of CT-logged
	certificates for hidden services.</t>	certificates for hidden services.</t>
	<section>	<section>

	<name>Avoid unnecessary certificates</name>	<name>Avoid Unnecessary Certificates</name>
	<t>Not all services will need a publicly trusted WebPKI certificate; f or internal or non-public services,	<t>Not all services will need a publicly trusted WebPKI certificate; f or internal or non-public services,

	operators <bcp14>SHOULD</bcp14> consider using self-signed or privat ely-trusted certificates that aren't	operators <bcp14>SHOULD</bcp14> consider using self-signed or privat ely trusted certificates that aren't
	logged to certificate transparency.</t>	logged to certificate transparency.</t>
	</section>	</section>
	<section>	<section>

	<name>Obfuscate subscriber information</name>	<name>Obfuscate Subscriber Information</name>
	<t>When an ACME client is registering to an ACME server it <bcp14>SHOU	<t>When an ACME client is registering with an ACME server, it <bcp14>S
	LD</bcp14> provide minimal or obfuscated	HOULD</bcp14> provide minimal or obfuscated
	subscriber details to the CA such as a pseudonymous email address, i	subscriber details to the CA, such as a pseudonymous email address,
	f at all possible.</t>	if at all possible.</t>
	</section>	</section>
	<section>	<section>

	<name>Separate ACME account keys</name>	<name>Separate ACME Account Keys</name>
	<t>If a hidden service operator does not want their different hidden s	<t>If a hidden service operator does not want their different hidden s
	ervices to be correlated by a CA they	ervices to be correlated by a CA, they
	<bcp14>MUST</bcp14> use separate ACME account keys for each hidden s ervice.</t>	<bcp14>MUST</bcp14> use separate ACME account keys for each hidden s ervice.</t>
	</section>	</section>
	</section>	</section>
	</section>	</section>
	</middle>	</middle>

	<back>	<back>

		<displayreference target="I-D.ietf-tls-esni" to="tls-esni"/>
	<references>	<references>
	<name>References</name>	<name>References</name>
	<references>	<references>
	<name>Normative References</name>	<name>Normative References</name>


	<referencegroup anchor="BCP14" target="https://www.rfc-editor.org/info/b	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	cp14">	119.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	.2119.xml"/>	986.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	.8174.xml"/>	648.xml"/>
	</referencegroup>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2	686.xml"/>
	986.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4	037.xml"/>
	648.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7	e.RFC.8174.xml"/>
	686.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8	555.xml"/>
	037.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8	659.xml"/>
	555.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8	737.xml"/>
	659.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8	629.xml"/>
	737.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3
	629.xml"/>


	<reference anchor="tor-spec" target="https://spec.torproject.org/print.h tml">	<reference anchor="tor-spec" target="https://spec.torproject.org">
	<front>	<front>
	<title>Tor Specifications</title>	<title>Tor Specifications</title>
	<author>	<author>
	<organization>The Tor Project</organization>	<organization>The Tor Project</organization>
	</author>	</author>
	</front>	</front>
	</reference>	</reference>

	<reference anchor="tor-rend-spec-v2" target="https://spec.torproject.org /rend-spec-v2">	<reference anchor="tor-rend-spec-v2" target="https://spec.torproject.org /rend-spec-v2">
	<front>	<front>
	<title>Tor Rendezvous Specification - Version 2</title>	<title>Tor Rendezvous Specification - Version 2</title>
	<author>	<author>
	<organization>The Tor Project</organization>	<organization>The Tor Project</organization>
	</author>	</author>
	</front>	</front>

		<refcontent>commit 2437d19c</refcontent>
	</reference>	</reference>

	<reference anchor="cabf-br" target="https://cabforum.org/working-groups/ server/baseline-requirements/documents/CA-Browser-Forum-TLS-BR-2.0.6.pdf">	<reference anchor="cabf-br" target="https://cabforum.org/working-groups/ server/baseline-requirements/documents/CA-Browser-Forum-TLS-BR-2.0.6.pdf">
	<front>	<front>

	<title>Baseline Requirements for the Issuance and Management of Publ icly-Trusted Certificates</title>	<title>Baseline Requirements for the Issuance and Management of Publ icly-Trusted TLS Server Certificates</title>
	<author>	<author>
	<organization>CA/Browser Forum</organization>	<organization>CA/Browser Forum</organization>
	</author>	</author>

		<date day="5" month="August" year="2024"/>
	</front>	</front>

		<refcontent>Version 2.0.6</refcontent>
	</reference>	</reference>

	</references>	</references>
	<references>	<references>
	<name>Informative References</name>	<name>Informative References</name>

	<reference anchor="onion-services-setup" target="https://community.torpr oject.org/onion-services/setup/">	<reference anchor="onion-services-setup" target="https://community.torpr oject.org/onion-services/setup/">
	<front>	<front>
	<title>Set Up Your Onion Service</title>	<title>Set Up Your Onion Service</title>
	<author>	<author>
	<organization>The Tor Project</organization>	<organization>The Tor Project</organization>
	</author>	</author>
	</front>	</front>
	</reference>	</reference>


	<reference anchor="spoiled-onions" target="https://rdcu.be/d1ZRp">	<!-- [rfced] Please note that we have changed the URL of the
		[spoiled-onions] reference to point use the DOI rather than the
		original URL, which took the reader to a preview page that they
		couldn't back out of. Please review.

		Original:
		https://rdcu.be/d1ZRp

		Current:
		https://doi.org/10.1007/978-3-319-08506-7_16

		-->

		<reference anchor="spoiled-onions">
	<front>	<front>
	<title>Spoiled Onions: Exposing Malicious Tor Exit Relays</title>	<title>Spoiled Onions: Exposing Malicious Tor Exit Relays</title>

	<seriesInfo name="DOI" value="10.1007/978-3-319-08506-7_16"/>
	<author fullname="Philipp Winter"/>	<author fullname="Philipp Winter"/>
	<author fullname="Richard Köwer"/>	<author fullname="Richard Köwer"/>
	<author fullname="Martin Mulazzani"/>	<author fullname="Martin Mulazzani"/>
	<author fullname="Markus Huber"/>	<author fullname="Markus Huber"/>
	<author fullname="Sebastian Schrittwieser"/>	<author fullname="Sebastian Schrittwieser"/>
	<author fullname="Stefan Lindskog"/>	<author fullname="Stefan Lindskog"/>
	<author fullname="Edgar Weippl"/>	<author fullname="Edgar Weippl"/>

	<date>2014</date>	<date year="2014"/>
	</front>	</front>

		<refcontent>Privacy Enhancing Technologies (PETS 2014), Lecture Notes
		in Computer Science, vol. 8555, pp. 304-331</refcontent>
		<seriesInfo name="DOI" value="10.1007/978-3-319-08506-7_16"/>
	</reference>	</reference>


		<!-- [rfced] Please review. We found an open-access version of
		[spoiled-onions] on arXiv. The information appears to match the
		current reference; however, some author names are missing. Would you
		prefer to use this open-access version of this reference? -->

		<!--Note to Editor: XML for arXiv version of this reference:

		<reference anchor="spoiled-onions">
		<front>
		<title>Spoiled Onions: Exposing Malicious Tor Exit Relays</title>
		<author fullname="Philipp Winter"/>
		<author fullname="Stefan Lindskog"/>
		<date year="2014"/>
		</front>
		<seriesInfo name="arXiv:" value="1401.4917"/>
		<seriesInfo name="DOI" value="10.48550/arXiv.1401.4917"/>
		</reference>

		-->

		<!-- [I-D.ietf-tls-esni] draft-ietf-tls-esni-22
		IESG State: AD Evaluation::AD Followup as of 02/19/25.
		-->
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D. ietf-tls-esni.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D. ietf-tls-esni.xml"/>

	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9
	162.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		162.xml"/>
	</references>	</references>
	</references>	</references>

	<section anchor="use-of-id-dns">	<section anchor="use-of-id-dns">

	<name>Discussion on the use of the "dns" identifier type</name>	<name>Discussion on the Use of the "dns" Identifier Type</name>
	<t>The reasons for utilising the "dns" identifier type in ACME and not def	<t>The reasons for utilizing the "dns" identifier type in ACME and not def
	ining a new identifier type for	ining a new identifier type for
	".onion"s may not seem obvious at first glance. After all, ".onion" Spec	".onion" may not seem obvious at first glance. After all, ".onion" Speci
	ial-Use Domain	al-Use Domain
	Names are not part of the DNS infrastructure and as such why should they	Names are not part of the DNS infrastructure and, as such, why should th
	use the "dns" identifier type?</t>	ey use the "dns" identifier type?</t>
	<t><xref target="cabf-br" section="B.2.a.ii" relative="#page=124"/> define s, and this document allows,	<t><xref target="cabf-br" section="B.2.a.ii" relative="#page=124"/> define s, and this document allows,
	using the "http-01" or "tls-alpn-01" validation methods already present in ACME (with some considerations).	using the "http-01" or "tls-alpn-01" validation methods already present in ACME (with some considerations).

	Given the situation of a web server placed behind a Tor terminating prox y (as per the setup suggested by the	Given the situation of a web server placed behind a Tor-terminating prox y (as per the setup suggested by the
	Tor project <xref target="onion-services-setup"/>), existing ACME toolin g can be blind to the fact that a	Tor project <xref target="onion-services-setup"/>), existing ACME toolin g can be blind to the fact that a

	".onion" Special-Use Domain Name is being utilised, as they simply recei	".onion" Special-Use Domain Name is being utilized, as they simply recei
	ve an incoming TCP connection as they	ve an incoming TCP connection as they
	would regardless (albeit from the Tor terminating proxy).</t>	would regardless (albeit from the Tor-terminating proxy).</t>
	<t>An example of this would be Certbot placing the ACME challenge response file in the webroot of an NGINX web	<t>An example of this would be Certbot placing the ACME challenge response file in the webroot of an NGINX web
	server. Neither Certbot nor NGINX would require any modification to be a ware of any special handling for	server. Neither Certbot nor NGINX would require any modification to be a ware of any special handling for
	".onion" Special-Use Domain Names.</t>	".onion" Special-Use Domain Names.</t>

	<t>This does raise some questions regarding security within existing imple mentations, however the authors believe	<t>This does raise some questions regarding security within existing imple mentations; however, the authors believe
	this is of little concern, as per <xref target="security-id-dns"/>.</t>	this is of little concern, as per <xref target="security-id-dns"/>.</t>
	</section>	</section>

	<section anchor="Acknowledgements" numbered="false">	<section anchor="Acknowledgements" numbered="false">
	<name>Acknowledgements</name>	<name>Acknowledgements</name>
	<t>With thanks to the Open Technology Fund for funding the work that went into this document.</t>	<t>With thanks to the Open Technology Fund for funding the work that went into this document.</t>
	<t>The authors also wish to thank the following for their input on this do cument:</t>	<t>The authors also wish to thank the following for their input on this do cument:</t>
	<ul>	<ul>

	<li>Iain Learmonth</li>	<li><t><contact fullname="Iain Learmonth"/></t></li>
	<li>Jan-Frederik Rieckers</li>	<li><t><contact fullname="Jan-Frederik Rieckers"/></t></li>
	</ul>	</ul>
	</section>	</section>
	</back>	</back>


		<!--[rfced] We have the following questions related to terminology
		used throughout the document:

		a) We assume ".onion" is pronounced as "dot onion" and have thus left
		instances of "a ".onion" as they were. If this is incorrect, please
		let us know and we can update to "an ".onion"" as necessary.

		b) We see the following similar terms used. Please let us know if these should
		be made uniform or if they should remain distinct terms:

		first layer hidden service descriptor vs. first layer descriptor
		second layer hidden service descriptor vs. second layer descriptor
		Hidden Service vs. hidden service
		".onion" service vs. "Onion Services"
		http-01 vs. "http-01"
		tls-alpn-01 vs. "tls-alpn-01"

		c) We note that <tt> tags were used to enclose the following terms in
		this document. Please review use for consistency as we note they were
		not used on every occurrence. Please also review the output of the
		<tt> tags in all formats (html, pdf, text) to ensure satisfaction.

		<tt>applicantSigningNonce</tt>
		<tt>auth-client</tt>
		<tt>caSigningNonce</tt>
		<tt>"onion-csr-01".</tt>
		-->

		<!--[rfced] Please review the following questions/comments regarding
		abbreviation use in this document:

		a) Please note we have expanded these abbreviations as follows (per
		the reference in parentheses when applicable). Please review and let
		us know any objections/corrections:

		CSR - Certificate Signing Request (RFC 8555)
		PEM - Privacy Enhanced Mail (RFC 4648)
		TLD - Top-Level Domain
		ECH - Encrypted ClientHello (draft-ietf-tls-esni-24)

		b) Please note that CSR (the abbreviation at least) is not used in
		either Appendix B.2.b of [cabf-br] or [RFC2986]. Please review the
		citations in this document and let us know if any updates are
		necessary/desirable.

		-->

		<!--[rfced] We note that the original xml file submitted used <eref>
		to point to specific sections in the [tor-spec]. Please review
		if these links should remain with the following in mind:

		1) These links make a difference in the output formats as follows:

		html (where the section names are linked):
		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 use (as per the "Authen
		tication during the introduction phase" section of [tor-spec]) to authenticate i
		tself when retrieving the hidden service descriptor.

		txt (where the link appears in-line):
		To this end, a new field is added to the second layer hidden service
		descriptor, as defined in the "Second layer plaintext format"
		(https://spec.torproject.org/rend-spec/hsdesc-encrypt.html#second-
		layer-plaintext) section of [tor-spec] with the following format
		(defined using the notation from the "netdoc document meta-format"
		(https://spec.torproject.org/dir-spec/netdoc.html) section of
		[tor-spec]):

		2) These links may become stale quickly as [tor-spec] mentions an
		upcoming reorganization and that it is a living document.

		An alternative would be to remove the links but include the section
		names in the text itself (i.e., not use <eref>) and allow the reader
		to simply navigate to the section from the main [tor-spec] link. This
		would allow the html and text versions to be the same.

		Please let us know how you would like to proceed.
		-->

		<!-- [rfced] Please consider whether the “type" attribute of any
		sourcecode element should be set and/or has been set correctly.

		The current list of preferred values for "type" 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 "type" attribute not set.
		-->

		<!-- [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.

		Note that our script did not flag any words in particular, but this
		should still be reviewed as a best practice.

		-->

	</rfc>	</rfc>

End of changes. 135 change blocks.
	345 lines changed or deleted	684 lines changed or added
This html diff was produced by rfcdiff 1.48.