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 "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<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" <title abbrev="ACME for &quot;.onion&quot;">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 <seriesInfo name="RFC" value="9799"/>
nion-07"/> <author fullname="Q Misell" 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>
<area>SEC</area>
<workgroup>acme</workgroup>
<keyword>tor</keyword>
<keyword>hidden service</keyword>
<keyword>onion service</keyword>
<keyword>caa</keyword>
<keyword>dns</keyword>
<abstract> <abstract>
<t>The document defines extensions to the Automated Certificate Management <t>This document defines extensions to the Automated Certificate Managemen
Environment (ACME) to allow for the t Environment (ACME) to allow for the
automatic issuance of certificates to Tor hidden services (".onion" Spec automatic issuance of certificates to Tor Hidden Services (".onion" Spec
ial-Use Domain Names).</t> 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&nbsp;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 "Spe
<xref target="tor-spec" section="Special Hostnames in Tor - &quot;.onion cial Hostnames in Tor - .onion" section of <xref target="tor-spec"/>.
&quot;" relative="#onion"/>.
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: <tt>http-01</tt> Challenge</name>
<t>The "http-01" challenge as defined in <xref target="RFC8555" sectio <t>The <tt>http-01</tt> challenge, as defined in <xref target="RFC8555
n="8.3"/> <bcp14>MAY</bcp14> be used to " section="8.3"/>, <bcp14>MAY</bcp14>
validate a ".onion" Special-Use Domain Names, with the modifications be used to validate a ".onion" Special-Use Domain Name with the modi
defined in this document, namely fications defined in this document,
<xref target="client-auth"/>, and <xref target="caa"/>.</t> namely those described in Sections
<t>The ACME server <bcp14>SHOULD</bcp14> follow redirects; note that t <xref target="client-auth" format="counter"/> and <xref target="caa" f
hese <bcp14>MAY</bcp14> be redirects to ormat="counter"/>.</t>
non-".onion" services, and the server <bcp14>SHOULD</bcp14> honour t <t>The ACME server <bcp14>SHOULD</bcp14> follow redirects. Note that t
hese. Clients might use redirects, hese <bcp14>MAY</bcp14> be redirects to services that are not ".onion" and that
for example, so that the response can be provided by a centralized c the server <bcp14>SHOULD</bcp14> honor these. For example, clients might use red
ertificate management server. See 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 <tt>tls-alpn-01</tt> Challenge</name>
<t>The "tls-alpn-01" challenge as defined in <xref target="RFC8737"/> <t>The <tt>tls-alpn-01</tt> challenge, as defined in <xref target="RFC
<bcp14>MAY</bcp14> be used to validate 8737"/>, <bcp14>MAY</bcp14> be used to
a ".onion" Special-Use Domain Names, with the modifications defined validate a ".onion" Special-Use Domain Name with the modifications d
in this document, namely efined in this document, namely those
<xref target="client-auth"/>, and <xref target="caa"/>.</t> described in Sections <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 <tt>onion-csr-01</tt> Challenge</name>
<t>Two methods already defined in ACME and allowed by the CA/BF ("http-0 <t>The two ACME-defined methods allowed by CA/BF described in Sections <
1" and "tls-alpn-01") do not allow xref target="http01" format="counter"/> and <xref target="tlsalpn" format="count
issuance of wildcard certificates. A ".onion" Special-Use Domain Name er"/>
can have subdomains (<tt>http-01</tt> and <tt>tls-alpn-01</tt>) do not allow issuance of w
(just like any other domain in the DNS), and a site operator may find ildcard certificates.
it useful to have one certificate for A ".onion" Special-Use Domain Name can have subdomains (just like any
all virtual hosts on their site. This new validation method incorporat other domain in the DNS), and a site
es the specially signed CSR (as defined by operator may find it useful to have one certificate for all virtual ho
sts on their site. This new validation
method incorporates 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 <tt>onion-csr-01</tt> is defined, with the 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 <t>An <tt>onion-csr-01</tt> challenge <bcp14>MUST NOT</bcp14> be used to
es for non ".onion" issue certificates for
Special-Use Domain Names.</t> Special-Use Domain Names that are not ".onion".</t>
<t>Clients prove control over the key associated with the ".onion" servi <t>Clients prove control over the key associated with the ".onion" servi
ce by generating a CSR ce by generating a
<xref target="RFC2986"/> with the following additional extension attri Certificate Request (CSR) <xref target="RFC2986"/> with the following
butes and signing it with the private additional extension attributes and
key of the ".onion" Special-Use signing it with the private key of the ".onion" Special-Use Domain Nam
Domain Name:</t> e:</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 203
} }
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"> <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 <li>The <tt>caSigningNonce</tt> attribute is present and its contents
he nonce provided to the client.</li> match the nonce provided to the client.</li>
<li>The applicantSigningNonce attribute is present and contains at lea <li>The <tt>applicantSigningNonce</tt> attribute is present and contai
st 64 bits of entropy.</li> ns at least 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 Service Descriptor with the keys of clients authorized to connect. Witho
ut a way for the CA to signal what key 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 it will use to connect, these services will not be able to obtain a cert
ficate using http-01 or tls-alpn-01, ificate using <tt>http-01</tt> or
nor enforce CAA with any validation method.</t> <tt>tls-alpn-01</tt>, 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 "Authentication during the in
<xref target="tor-spec" section="&quot;Authentication during the introdu troduction phase" section of
ction phase&quot;" relative="#INTRO-AUTH" />) to <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 <t>ACME servers <bcp14>MUST NOT</bcp14> use the same public key with multi
ple hidden services. 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 "Clien
<xref target="tor-spec" section="&quot;Client Behavior&quot;" relative=" t behavior" section of
#FIRST-LAYER-CLIENT-BEHAVIOR"/>. <xref target="tor-spec"/>.
If no <tt>auth-client</tt> line in the first layer hidden service descri If no <tt>auth-client</tt> line in the First Layer Hidden Service Descri
ptor matches the computed client-id ptor matches the computed client-id,
then the server <bcp14>MUST</bcp14> assume that the hidden service does then the server <bcp14>MUST</bcp14> assume that the Hidden Service does
not require client authentication and 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 <t>In the case in which the Ed25519 public key is novel to the client, it
to resign and republish its hidden service will have to resign and republish its Hidden Service
descriptor. It <bcp14>MUST</bcp14> wait some (indeterminate) amount of t Descriptor. It <bcp14>MUST</bcp14> wait some (indeterminate) amount of t
ime for the new descriptor to ime for the new descriptor to
propagate the Tor hidden service directory servers, before proceeding wi propagate the Tor Hidden Service directory servers before proceeding wit
th responding to the challenge. 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 ACME server available as a Tor Hidden Service. ACME clients <bcp14>SHOUL
LD</bcp14> also support connecting to D</bcp14> also support connecting to
ACME servers over Tor, regardless of their support of "onion-csr-01", as ACME servers over Tor, regardless of their support of <tt>onion-csr-01</
their existing "http-01" tt>, as their existing <tt>http-01</tt>
and "tls-alpn-01" implementations could be used to obtain certificates f and <tt>tls-alpn-01</tt> implementations could be used to obtain certifi
or ".onion" Special-Use Domain Names.</t> cates for ".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 "Second layer plaintext format" section of
<xref target="tor-spec" section="&quot;Second layer plaintext format&quo <xref target="tor-spec"/>
t;" relative="#second-layer-plaintext" /> with the following format (defined using the notation from the "netdoc d
with the following format (defined using the notation from ocument meta-format" section of
<xref target="tor-spec" section="&quot;Document meta-format&quot;" relat <xref target="tor-spec"/>):</t>
ive="#metaformat"/>):</t> <sourcecode><![CDATA[
<sourcecode>
"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 <t>The contents of "flags", "tag", and "value" are as per <xref target="RF
8659" section="4.1.1"/>. C8659" section="4.1.1"/>.
Multiple CAA records <bcp14>MAY</bcp14> be present, as is the case in th Multiple CAA records <bcp14>MAY</bcp14> be present, as is the case in th
e DNS. CAA records in a hidden service e DNS. CAA records in a Hidden Service
descriptor are to be treated the same by CAs as if they had been in the 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> DNS for the ".onion" Special-Use
<t>A hidden service's second layer descriptor using CAA could look somethi Domain Name.</t>
ng like the following <t>A Hidden Service's Second Layer Descriptor using CAA could look somethi
(additional linebreaks have been added for readability):</t> ng like the following
<sourcecode> (additional line breaks have been added for readability):</t>
<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 decrypt the Second Layer Hidden Service Descriptor to read the CAA rec
ACME server's public key has been added ords 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 Hidden Service Descriptor. To this end, an ACME ser
/bcp14> wait until the client responds ver <bcp14>MUST</bcp14> wait until the
to an authorization before checking CAA, and treat this response as in client responds to an authorization before checking the CAA and treat
dication that their public key has been this response as an indication that
added and that the ACME server will be able to decrypt the second laye their public key has been added and that the ACME server will be able
r descriptor.</t> to decrypt the Second Layer Hidden
Service 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 in the Second Layer Hidden Service Descriptor. A method is necessary t
here are CAA records present o signal that there are CAA records
(but not reveal their contents which - in certain circumstances - woul present (but not reveal their contents, which, in certain circumstance
d unwantedly disclose information s, 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 "First layer plaintext format" section of
<xref target="tor-spec" section="&quot;First layer plaintext format&qu <xref target="tor-spec"/>
ot;" relative="#first-layer-plaintext" /> with the following format (defined using the notation from the "netdoc
with the following format (defined using the notation from document meta-format" section of
<xref target="tor-spec" section="&quot;Document meta-format&quot;" relat <xref target="tor-spec"/>):</t>
ive="#metaformat"/>):</t> <sourcecode><![CDATA[
<sourcecode>
"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 Hidden Service Descrip
tor.</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 this information is still publicly accessible. Additionally, a Hidden
or <bcp14>MAY</bcp14> also not wish to Service operator <bcp14>MAY</bcp14>
publish a CAA record set in its service descriptor to avoid revealing not wish to publish a CAA record set in its Hidden Service Descriptor
information about the service operator.</t> to avoid revealing information about the
<t>If an ACME server receives a validly signed CAA record set in the fin service operator.</t>
alize request it <bcp14>MAY</bcp14> <t>If an ACME server receives a validly signed CAA record set in the fin
proceed with issuance on the basis of the client provided CAA record s alize request, it <bcp14>MAY</bcp14>
et only without checking the CAA set in proceed with issuance on the basis of the client-provided CAA record s
the hidden service. Alternatively, an ACME server <bcp14>MAY</bcp14> i et only, without checking the CAA set in
gnore the client provided record set and fetch the record set from the Hidden Service. Alternatively, an ACME server <bcp14>MAY</bcp14> i
the service descriptor. In any case, the server always MAY fetch gnore the client provided record set and
the record set from the service descriptor. fetch the record set from the Hidden Service Descriptor. In any case,
If an ACME server receives a validly signed CAA record set in the fina the server <bcp14>MAY</bcp14> fetch the
lize request it need not check the CAA record set from the Hidden Service Descriptor. If an ACME server recei
set in the hidden service descriptor and can proceed with issuance on ves a validly signed CAA record set in
the basis of the client provided CAA the finalize request, it need not check the CAA set in the Hidden Serv
record set only. An ACME server <bcp14>MAY</bcp14> ignore the client p ice Descriptor and can proceed with
rovided record set, and is free to issuance on the basis of the client-provided CAA record set only. An A
always fetch the record set from the service descriptor.</t> CME server <bcp14>MAY</bcp14> ignore the
<t>A new field is defined in the ACME finalize endpoint to contain the h client-provided record set and is free to always fetch the record set
idden service's CAA record set for each from the Hidden 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
".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 The CAA record set as a string, encoded in the same way as if was in
cluded in the hidden service descriptor. cluded in the Hidden Service Descriptor.
If the hidden service does not have a CAA record set then this <bcp1 If the Hidden Service does not have a CAA record set, then this <bcp
4>MUST</bcp14> be null. 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 <t>If an ACME server does not support fetching a service's CAA record
set from its service descriptor it, set from its Hidden Service Descriptor,
and the ACME client does not provide an "onionCAA" object in its fin and the ACME client does not provide an "onionCAA" object in its fin
alize request the ACME server 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"
}), }),
"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,
"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>
<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 <t>One new entry has been added to the "ACME Error Types" registry that
pes" registry defined in was defined in
<xref target="RFC8555" section="9.7.8"/> <xref target="RFC8555" section="9.7.4"/>
(<eref target="https://www.iana.org/assignments/acme/acme.xhtml#acme-e (<eref brackets="angle" target="https://www.iana.org/assignments/acme"
rror-types"/>). />).</t>
This entry is defined below:</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 <t>One new entry has been added to the "ACME Directory Metadata Fields"
y Metadata Fields" registry defined in registry that was defined in
<xref target="RFC8555" section="9.7.8"/> <xref target="RFC8555" section="9.7.6"/>
(<eref target="https://www.iana.org/assignments/acme/acme.xhtml#acme-d (<eref brackets="angle" target="https://www.iana.org/assignments/acme"
irectory-metadata-fields"/>). />).</t>
This entry is defined below:</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 576
<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 <tt>onion-csr-01</tt> Challenge</name>
<t>The security considerations of <xref target="cabf-br"/> apply to issu <t>The security considerations of <xref target="cabf-br"/> apply to issu
ance using the CSR method.</t> ance using the Certificate Request 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><tt>http-01</tt> 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><tt>tls-alpn-01</tt> 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><tt>dns-01</tt> 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 <tt>onion-csr-01</tt></name>
<t>The "onion-csr-01" challenge does not make use of the key authorizati <t>The <tt>onion-csr-01</tt> challenge does not make use of the key auth
on string defined in orization 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 <tt>http-01</tt></name>
<t>A site <bcp14>MAY</bcp14> redirect to another site when completing va <t>A site <bcp14>MAY</bcp14> redirect to another site when completing va
lidation using the "http-01" challenge. lidation using the <tt>http-01</tt>
This redirect <bcp14>MAY</bcp14> be to either another ".onion" Special challenge. This redirect <bcp14>MAY</bcp14> be to either another ".oni
-Use Domain Name, or to a domain in the public DNS. on" Special-Use Domain Name or a domain
A site operator <bcp14>MUST</bcp14> consider the privacy implications in the public DNS. A site operator <bcp14>MUST</bcp14> consider the pr
of redirecting to a non-".onion" ivacy implications of redirecting to a
site - namely that the ACME server operator will then be able to learn site that is not ".onion" -- namely that the ACME server operator will
information about the site redirected to then be able to learn information about
that they would not if accessed via a ".onion" Special-Use Domain Name the site they were redirected to that they would not have if accessed
, such as its IP address. If the site via a ".onion" Special-Use Domain Name,
redirected to is on the same or an adjacent host to the ".onion" Speci such as its IP address. If the site redirected to is on the same or an
al-Use Domain Name this reveals adjacent host to the ".onion"
information <xref target="tor-spec" section="Tor Rendezvous Specificat Special-Use Domain Name, this reveals information that the "Tor Rendez
ion - Version 3" relative="#tor-rendezvous-specification---version-3"/> was othe vous Specification - Version 3" secion of <xref target="tor-spec"/> was otherwis
rwise designed to protect.</t> e 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 <t>The Second Layer Hidden Service Descriptor is signed, encrypted, and
hat only a party with access to the encoded using a Message Authentication
secret key of the hidden service could manipulate what is published th Code (MAC) in a way that only a party with access to the secret key of
ere. For more information about this the Hidden Service could manipulate
process see <xref target="tor-spec" section="&quot;Hidden service desc what is published there. For more information about this process, see
riptors: encryption format&quot;" relative="#HS-DESC-ENC" />.</t> the
"Hidden service descriptors: encryption format" section of <xref targe
t="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 <t>Tor directory servers are inherently untrusted entities. As such, the
there is no difference in the security re is no difference in the security model for accepting CAA records directly fro
model for accepting CAA records directly from the ACME client or fetch m the ACME client or fetching them over Tor: the CAA records are verified using
ing them over Tor. There is no the same hidden service key in either case.</t>
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>
</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 <t>If an ACME client requests a publicly trusted WebPKI certificate, it
ill expose the existence of the Hidden 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 certificates. ACME client developers <bcp14>SHOULD</bcp14> warn users
about the risks of CT logged 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 <bcp14>MUST</bcp14> use separate ACME account keys for each Hidden S
ervice.</t> 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">
<reference anchor="spoiled-onions" target="https://rdcu.be/d1ZRp">
<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>
<!-- [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 using the <tt>http-01</tt> or <tt>tls-alpn-01</tt> validation methods al
in ACME (with some considerations). ready present in ACME (with some
Given the situation of a web server placed behind a Tor terminating prox considerations). Given the situation of a web server placed behind a Tor
y (as per the setup suggested by the -terminating proxy (as per the setup
Tor project <xref target="onion-services-setup"/>), existing ACME toolin suggested by the Tor project <xref target="onion-services-setup"/>), exi
g can be blind to the fact that a sting ACME tooling can be blind to the
".onion" Special-Use Domain Name is being utilised, as they simply recei fact that a ".onion" Special-Use Domain Name is being utilized, as they
ve an incoming TCP connection as they simply receive an incoming TCP
would regardless (albeit from the Tor terminating proxy).</t> connection as they would regardless (albeit from the Tor-terminating pro
xy).</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>
</rfc> </rfc>
 End of changes. 126 change blocks. 
448 lines changed or deleted 472 lines changed or added

This html diff was produced by rfcdiff 1.48.