<?xml version="1.0" encoding="utf-8"?>
<?xml-model href="rfc7991bis.rnc"?> encoding="UTF-8"?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

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

  <front>

<!-- [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 updated 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 &quot;.onion&quot;">Automated Certificate Management Environment (ACME) Extensions for ".onion"
      Special-Use Domain Names</title>
    <seriesInfo name="Internet-Draft" status="standard" value="draft-ietf-acme-onion-07"/> name="RFC" value="9799"/>
    <author fullname="Q Misell" initials="Q" role="editor" surname="Misell">
      <organization abbrev="AS207960">AS207960 Cyfyngedig</organization>
      <address>
        <postal>
          <street>13 Pen-y-lan Terrace</street>
          <city>Caerdydd</city>
          <code>CF23 9EU</code>
          <country>United Kingdom</country>
        </postal>
        <email>q@as207960.net</email>
        <email>q@magicalcodewit.ch</email>
        <uri>https://magicalcodewit.ch</uri>
      </address>
    </author>
    <area>sec</area>
    <workgroup>Automated Certificate Management Environment</workgroup>
    <date month="June" year="2025"/>

<!--[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>
      <t>The
      <t>This document defines extensions to the Automated Certificate Management Environment (ACME) to allow for the
        automatic issuance of certificates to Tor hidden services (".onion" Special-Use Domain Names).</t>
    </abstract>

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

  <middle>
    <section>
      <name>Introduction</name>
      <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"
        Special-Use Domain Name <xref target="RFC7686"/> to identify these services. These can be used as any other domain
        name could, but they do not form part of the DNS infrastructure.</t>
      <t>The Automated Certificate Management Environment (ACME) <xref target="RFC8555"/> defines challenges for
        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 ACME could be used on ".onion"
        Special-Use Domain Names.</t>
      <t>In order to allow ACME to be utilised utilized to issue certificates to ".onion" Special-Use Domain Names Names, this document
        specifies challenges suitable to validate control of these Special-Use Domain Names. Additionally, this document
        defines an alternative to the DNS Certification Authority Authorization (CAA) Resource Record
        <xref target="RFC8659"/> that can be used with ".onion" Special-Use Domain Names.</t>

      <section>
        <name>Requirements Language</name>
        <t>The
        <t>
    The key words <bcp14>MUST</bcp14>, <bcp14>MUST NOT</bcp14>, <bcp14>REQUIRED</bcp14>, <bcp14>SHALL</bcp14>,
          <bcp14>SHALL NOT</bcp14>, <bcp14>SHOULD</bcp14>, <bcp14>SHOULD NOT</bcp14>, <bcp14>RECOMMENDED</bcp14>,
          <bcp14>NOT RECOMMENDED</bcp14>, <bcp14>MAY</bcp14>, "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and <bcp14>OPTIONAL</bcp14> "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP&nbsp;14 <xref target="BCP14"/> (<xref target="RFC2119"/>, target="RFC2119"/> <xref target="RFC8174"/>) target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      </section>
    </section>

    <section>
      <name>Identifier</name>
      <t><xref target="RFC8555"/> defines the "dns" identifier type. This identifier type <bcp14>MUST</bcp14> be used
        when requesting a certificate for a ".onion" Special-Use Domain Name. The value of the identifier
        <bcp14>MUST</bcp14> be the textual representation as defined in
        <xref target="tor-spec" section="Special the <eref target="https://spec.torproject.org/address-spec.html#onion">"Special Hostnames in Tor - &quot;.onion&quot;" relative="#onion"/>. .onion"</eref> section of <xref target="tor-spec"/>.
        The value <bcp14>MAY</bcp14> include subdomain labels. Version 2 addresses <xref target="tor-rend-spec-v2"/>
        <bcp14>MUST NOT</bcp14> be used as these are now considered insecure.</t>
      <t>Example identifiers (linebreaks (line breaks have been added for readability only):</t>
      <sourcecode type="json"> type="json"><![CDATA[
{
  "type": "dns",
  "value": "bbcweb3hytmzhn5d532owbu6oqadra5z3ar726v
        q5kgwwn6aucdccrad.onion"
}
      </sourcecode>
]]></sourcecode>

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

    </section>

    <section>
      <name>Identifier Validation Challenges</name>
      <t>The CA/Browser Forum Baseline Requirements (<xref target="cabf-br" section="B.2" relative="#page=124" />) define methods accepted by the CA industry for validation of ".onion" Special-Use Domain Names. Names (see <xref target="cabf-br" section="B.2" relative="#page=124"/>).
        This document incorporates these methods into ACME challenges.</t>
      <section>
        <name>Existing challenges</name> Challenges</name>
        <section>
          <name>Existing
          <name>Existing: "dns-01" Challenge</name>
          <t>The existing "dns-01" challenge <bcp14>MUST NOT</bcp14> be used to validate ".onion" Special-Use Domain
            Names,
            Names as these domains are not part of the DNS.</t>
        </section>
        <section>
          <name>Existing
        <section anchor="http01">
          <name>Existing: "http-01" Challenge</name>
          <t>The "http-01" challenge challenge, as defined in <xref target="RFC8555" section="8.3"/> section="8.3"/>, <bcp14>MAY</bcp14> be used to
            validate a ".onion" Special-Use Domain Names, Name with the modifications defined in this document, namely those described in Sections
          <xref target="client-auth"/>, target="client-auth" format="counter"/> and <xref target="caa"/>.</t>
          <t>The target="caa" format="counter"/>.</t>

<!--[rfced] Please review our edits to the following text to ensure we
     have maintained your intent.

Original:
   The ACME server <bcp14>SHOULD</bcp14> SHOULD follow redirects; note that these <bcp14>MAY</bcp14> MAY be
   redirects to non-".onion" services, and the server <bcp14>SHOULD</bcp14> SHOULD honour
   these. Clients

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 these <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 redirects,
            for example, redirects so that the response can be provided by a centralized certificate management server. See
            <xref target="RFC8555" section="10.2"/> for security considerations on why a server might not want to
            follow redirects.</t>
        </section>
        <section>
        <section anchor="tlsalpn">
          <name>Existing "tls-alpn-01" Challenge</name>
          <t>The "tls-alpn-01" challenge challenge, as defined in <xref target="RFC8737"/> target="RFC8737"/>, <bcp14>MAY</bcp14> be used to validate
            a ".onion" Special-Use Domain Names, Name with the modifications defined in this document, namely those described in Sections
            <xref target="client-auth"/>, target="client-auth" format="counter"/> and <xref target="caa"/>.</t> target="caa" format="counter"/>.</t>
        </section>
      </section>
      <section>
        <name>New "onion-csr-01" Challenge</name>
        <t>Two

        <t>The two ACME-defined methods already defined in ACME and allowed by the CA/BF described in Sections <xref target="http01" format="counter"/> and <xref target="tlsalpn" format="counter"/>   ("http-01" and "tls-alpn-01") do not allow
          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
          all virtual hosts on their site. This new validation method incorporates the specially signed CSR Certificate Signing Request (CSR) (as defined by
          <xref target="cabf-br" section="B.2.b" relative="#page=124"/>) into ACME to allow for the issuance of
          wildcard certificates.</t>
        <t>To this end end, a new challenge type called "onion-csr-01" is defined, with the following fields:</t>
        <dl>
          <dt>type (required, string)</dt> string):</dt>
          <dd>The string <tt>"onion-csr-01"</tt></dd> <tt>"onion-csr-01".</tt></dd>
          <dt>nonce (required, string)</dt> string):</dt>
          <dd>A Base64 Base64-encoded nonce <xref target="RFC4648"/> encoded nonce, including padding characters.
            It <bcp14>MUST</bcp14> contain at least 64 bits of entropy. A response generated  using this nonce
            <bcp14>MUST NOT</bcp14> be accepted by the ACME server if the nonce used was generated by the server more
            than 30 days ago prior (as per <xref target="cabf-br" section="B.2.b" relative="#page=124"/>).</dd>
          <dt>authKey (optional, object)</dt> object):</dt>
          <dd>The ACME server's Ed25519 public key encoded as per <xref target="RFC8037"/>. This is further defined in
            <xref target="client-auth"/>.</dd>
        </dl>
        <sourcecode type="json"> type="json"><![CDATA[
{
  "type": "onion-csr-01",
  "url": "https://acme-server.example.onion/acme/chall/bbc625c5",
  "status": "pending",
  "nonce": "bI6/MRqV4gw=",
  "authKey": { ... }
}
        </sourcecode>
]]></sourcecode>

<!--[rfced] Please review our updates to this text carefully and let
     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 non ".onion"
          Special-Use Domain Names.</t> Names that are not ".onion".</t>
        <t>Clients prove control over the key associated with the ".onion" service by generating a CSR
          <xref target="RFC2986"/> with the following additional extension attributes and signing it with the private
          key of the ".onion" Special-Use
          Domain Name:</t>
        <ul>
          <li>A <tt>caSigningNonce</tt> attribute containing the nonce provided in the challenge. This
            <bcp14>MUST</bcp14> be raw bytes, bytes and not the base64 encoded value provided in the challenge object.</li>
          <li>An <tt>applicantSigningNonce</tt> attribute containing a nonce generated by the client. This <bcp14>MUST</bcp14>
            have at least 64 bits of entropy. This <bcp14>MUST</bcp14> be raw bytes.</li>
        </ul>
        <t>These additional attributes have the following format</t>
        <sourcecode type="asn.1"> type="asn.1"><![CDATA[
cabf OBJECT IDENTIFIER ::=
  { joint-iso-itu-t(2) international-organizations(23)
    ca-browser-forum(140) }

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

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

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

applicantSigningNonce ATTRIBUTE ::= {
  WITH SYNTAX             OCTET STRING
  EQUALITY MATCHING RULE  octetStringMatch
  SINGLE VALUE            TRUE
  ID                      { cabf-applicantSigningNonce }
}
        </sourcecode>
]]></sourcecode>
        <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"
          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>
        <t>Clients respond with the following object to validate the challenge:</t>
        <dl>
          <dt>csr (required, string)</dt> string):</dt>
          <dd>
            The CSR in the base64url-encoded version of the DER format.
            (Note: Because this field uses base64url, and does not include headers, it is different from PEM.) Privacy Enhanced Mail (PEM).)
          </dd>
        </dl>

<!--[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"> type="http"><![CDATA[
POST /acme/chall/bbc625c5
Host: acme-server.example.onion
Content-Type: application/jose+json

{
  "protected": base64url({
    "alg": "ES256",
    "kid": "https://acme-server.example.onion/acme/acct/evOfKhNU60wg",
    "nonce": "UQI1PoRi5OuXzxuX7V7wL0",
    "url": "https://acme-server.example.onion/acme/chall/bbc625c5"
  }),
  "payload": base64url({
    "csr": "MIIBPTCBxAIBADBFMQ...FS6aKdZeGsysoCo4H9P"
  }),
  "signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4"
}
        </sourcecode>
]]></sourcecode>
        <t>When presented with the CSR CSR, the server verifies it in the following manner:</t>
        <ol>
          <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 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 match the nonce provided to the client.</li>
          <li>The applicantSigningNonce attribute is present and contains at least 64 bits of entropy.</li>
        </ol>
        <t>If all of the above are successful then validation succeeds, otherwise it has failed.</t>
      </section>
    </section>

    <section anchor="client-auth">
      <name>Client authentication Authentication to hidden services</name> Hidden Services</name>
      <t>Some hidden services do not wish to be accessible to the entire Tor network, and so they encrypt their hidden
        service descriptor with the keys of clients authorized to connect. Without a way for the CA to signal what key
        it will use to connect connect, these services will not be able to obtain a certificate using http-01 or tls-alpn-01,
        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
        Ed25519 public key it will use (as per
        <xref target="tor-spec" section="&quot;Authentication the <eref target="https://spec.torproject.org/rend-spec/introduction-protocol.html#INTRO-AUTH">"Authentication during the introduction phase&quot;" relative="#INTRO-AUTH" />) phase"</eref> section of
        <xref target="tor-spec"/>) to
        authenticate itself when retrieving the hidden service descriptor.</t>
      <dl>
        <dt>authKey (optional, object)</dt> object):</dt>
        <dd>The ACME server's Ed25519 public key encoded as per <xref target="RFC8037"/>.</dd>
      </dl>
      <t>ACME servers <bcp14>MUST NOT</bcp14> use the same public key with multiple hidden services.
        ACME servers <bcp14>MAY</bcp14> re-use reuse public keys for re-validation of the same hidden service.</t>
      <t>There is no method to communicate to the CA that client authentication is necessary; instead instead, the ACME server
        <bcp14>MUST</bcp14> attempt to calculate its CLIENT-ID as per the <eref target="https://spec.torproject.org/rend-spec/hsdesc-encrypt.html#FIRST-LAYER-CLIENT-BEHAVIOR">"Client behavior"</eref> section of
        <xref target="tor-spec" section="&quot;Client Behavior&quot;" relative="#FIRST-LAYER-CLIENT-BEHAVIOR"/>. target="tor-spec"/>.
        If no <tt>auth-client</tt> line in the first layer hidden service descriptor matches the computed client-id client-id,
        then the server <bcp14>MUST</bcp14> assume that the hidden service does not require client authentication and
        proceed accordingly.</t>
      <t>In the case in which the Ed25519 public key is novel to the client client, it will have to resign and republish its hidden service
        descriptor. It <bcp14>MUST</bcp14> wait some (indeterminate) amount of time for the new descriptor to
        propagate the Tor hidden service directory servers, servers before proceeding with 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
        operation of the Tor network can affect this propagation time in the future. ACME servers
        <bcp14>MUST NOT</bcp14> expire challenges before a reasonable time to allow publication of the new descriptor -
        it descriptor. It is <bcp14>RECOMMENDED</bcp14> the server allow at least 30 minutes; however however, it is entirely up to operator preference.</t>
    </section>

    <section>
      <name>ACME over hidden services</name> Hidden Services</name>
      <t>A CA offering certificates to ".onion" Special-Use Domain Names <bcp14>SHOULD</bcp14> make their
        ACME server available as a Tor hidden services. service. ACME clients <bcp14>SHOULD</bcp14> also support connecting to
        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 for ".onion" Special-Use Domain Names.</t>
    </section>

    <section anchor="caa">
      <name>Certification Authority Authorization (CAA)</name>
      <t>".onion" Special-Use Domain Name Names are not part of the DNS, and DNS; as such such, a variation on CAA <xref target="RFC8659"/>
        is necessary to allow restrictions to be placed on certificate issuance.</t>
      <t>To this end end, a new field is added to the second layer hidden service descriptor descriptor, as defined in
        <xref target="tor-spec" section="&quot;Second the <eref target="https://spec.torproject.org/rend-spec/hsdesc-encrypt.html#second-layer-plaintext">"Second layer plaintext format&quot;" relative="#second-layer-plaintext" /> format"</eref> section of
        <xref target="tor-spec"/>
        with the following format (defined using the notation from the <eref target="https://spec.torproject.org/dir-spec/netdoc.html">"netdoc document meta-format"</eref> section of
        <xref target="tor-spec" section="&quot;Document meta-format&quot;" relative="#metaformat"/>):</t>
      <sourcecode> target="tor-spec"/>):</t>
      <sourcecode><![CDATA[
"caa" SP flags SP tag SP value NL
[Any number of times]
      </sourcecode>
]]></sourcecode>
      <t>The presentation format is provided above purely for the convenience of the reader and implementors, implementors:
        the canonical version remains that defined in <xref target="RFC8659" section="4.1.1"/>,
        or future updates to the same.</t>
      <t>The

<!--[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="RFC8659" section="4.1.1"/>.
        Multiple CAA records <bcp14>MAY</bcp14> be present, as is the case in the DNS. CAA records in a hidden service
        descriptor are to be treated the same by CAs as if they had been in the DNS for the ".onion" Special-Use Domain Name.</t>
      <t>A hidden service's second layer descriptor using CAA could look something like the following
        (additional linebreaks line breaks have been added for readability):</t>
      <sourcecode>
      <sourcecode><![CDATA[
create2-formats 2
single-onion-service
caa 128 issue "acmeforonions.example;validationmethods=onion-csr-01"
caa 0 iodef "mailto:security@example.com"
introduction-point AwAGsAk5nSMpAhRqhMHbTFCTSlfhP8f5PqUhe6DatgMgk7kSL3
        KHCZUZ3C6tXDeRfM9SyNY0DlgbF8q+QSaGKCs=
...
      </sourcecode>
]]></sourcecode>
      <section>
        <name>Relevant Resource Record Set</name>
        <t>In the absence of the possibility for delegation of subdomains from a ".onion" Special-Use Domain Name Name, as
          there is in the DNS DNS, there is no need, nor indeed any method available, to search up the DNS tree for a
          relevant CAA record set. Similarly, it is also impossible to check CAA records on the "onion" Special-Use TLD, Top-Level Domain (TLD),
          as it does not exist in any form except as described in <xref target="RFC7686"/>, so target="RFC7686"/>; therefore, implementors
          <bcp14>MUST NOT</bcp14> look here there either.</t>
        <t>Instead
        <t>Instead, all subdomains under a ".onion" Special-Use Domain Name share the same CAA record set. That is,
          all of these share a CAA record set with "a.onion":</t>
        <ul>
          <li>b.a.onion</li>
          <li>c.a.onion</li>
          <li>e.d.a.onion</li>
        </ul>
        <t>but these do not:</t>
        <ul>
          <li>b.c.onion</li>
          <li>c.d.onion</li>
          <li>e.c.d.onion</li>
          <li>a.b.onion</li>
        </ul>
      </section>
      <section>
        <name>When to check Check CAA</name>
        <t>If the hidden service has client authentication enabled enabled, then it will 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
          to the first layer descriptor. To this end end, an ACME server <bcp14>MUST</bcp14> wait until the client responds
          to an authorization before checking CAA, the CAA and treat this response as an indication that their public key has been
          added and that the ACME server will be able to decrypt the second layer descriptor.</t>
      </section>
      <section>
        <name>Preventing mis-issuance Mis-Issuance by unknown Unknown CAs</name>
        <t>In the case of a hidden service requiring client authentication authentication, the CA will be unable to read the hidden
          service's CAA records without the hidden service trusting an ACME server's public key - -- as the CAA records are
          in the second layer descriptor. A method is necessary to signal that there are CAA records present
          (but not reveal their contents which - contents, which, in certain circumstances - circumstances, would unwantedly disclose information
          about the hidden service operator).</t>
        <t>To this end end, a new field is added to the first layer hidden service descriptor
          <xref target="tor-spec" section="&quot;First in the <eref target="https://spec.torproject.org/rend-spec/hsdesc-encrypt.html#first-layer-plaintext">"First layer plaintext format&quot;" relative="#first-layer-plaintext" /> format"</eref> section of
          <xref target="tor-spec"/>
          with the following format (defined using the notation from the <eref target="https://spec.torproject.org/dir-spec/netdoc.html">"netdoc document meta-format"</eref> section of
        <xref target="tor-spec" section="&quot;Document meta-format&quot;" relative="#metaformat"/>):</t>
        <sourcecode> target="tor-spec"/>):</t>
        <sourcecode><![CDATA[
"caa-critical" NL
[At most once]
        </sourcecode>
]]></sourcecode>
        <t>If an ACME server encounters this flag flag, it <bcp14>MUST NOT</bcp14> proceed with issuance until it can decrypt
          and parse the CAA records from the second layer descriptor.</t>
      </section>
      <section>
        <name>Alternative in-band presentation In-Band Presentation of CAA</name>
        <t>An ACME server might be unwilling to operate the infrastructure required 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
          of ACME is defined.</t>
        <t>If a hidden service does use this method to provide CAA records to an ACME server server, it <bcp14>SHOULD</bcp14>
          still publish CAA records if its CAA record set includes "iodef", "contactemail", or "contactphone" so that
          this information is still publicly accessible. A hidden service operator <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>
        <t>If an ACME server receives a validly signed CAA record set in the finalize request request, it <bcp14>MAY</bcp14>
          proceed with issuance on the basis of the client provided client-provided CAA record set only only, without checking the CAA set in
          the hidden service. Alternatively, an ACME server <bcp14>MAY</bcp14> ignore the client provided record set and fetch the record set from
	  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.
          If an ACME server receives a validly signed CAA record set in the finalize request request, it need not check the CAA
          set in the hidden service descriptor and can proceed with issuance on the basis of the client provided client-provided CAA
          record set only. An ACME server <bcp14>MAY</bcp14> ignore the client provided client-provided record set, set and is free to
          always fetch the record set from the service descriptor.</t>
        <t>A new field is defined in the ACME finalize endpoint to contain the hidden service's CAA record set for each
          ".onion" Special-Use Domain Name in the order.</t>
        <dl>
          <dt>onionCAA (optional, dictionary of objects)</dt> objects):</dt>
          <dd>
            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 following fields. fields described below.
          </dd>

        </dl>
        <t>The contents of the values of the "onionCAA" object are:</t> are as follows:</t>
        <dl>
          <dt>caa (required, string or null)</dt> null):</dt>
          <dd>
            The CAA record set as a string, encoded in the same way as if was included in the hidden service descriptor.
            If the hidden service does not have a CAA record set set, then this <bcp14>MUST</bcp14> be null.
          </dd>
          <dt>expiry (required, integer)</dt> integer):</dt>
          <dd>
            The Unix timestamp at which this CAA record set will expire. This <bcp14>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
            functionality beyond 2038.
          </dd>
          <dt>signature (required, string)</dt> string):</dt>
          <dd>
            The Ed25519 signature of the CAA record set using the private key corresponding to the ".onion"
            Special-Use Domain Name, encoded using base64url. The signature is defined below.
          </dd>
        </dl>
        <t>The data that the signature is calculated over is the concatenation of the following,
          encoded in UTF-8 <xref target="RFC3629"/>:</t>
        <sourcecode>"onion-caa|"
        <sourcecode><![CDATA["onion-caa|" || expiry || "|" || caa</sourcecode> caa]]></sourcecode>

        <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 null, it is represented as an empty string in the signature calculation.</t>
        <section>
          <name>ACME servers requiring in-band Servers Requiring In-Band CAA</name>
          <t>If

<!--[rfced] We have deleted the "it" before the comma in this
     sentence.  Please let us know if some other rephrase was
     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 finalize request, the ACME server
            <bcp14>MUST</bcp14> respond with an "onionCAARequired" error to indicate this.</t>
          <t>To support signalling signaling the server's support for fetching CAA record sets over Tor,
            a new field is defined in the directory "meta" object to signal this.</t>
          <dl>
            <dt>inBandOnionCAARequired (optional, boolean)</dt> boolean):</dt>
            <dd>
              If true, the ACME server requires the client to provide the CAA record set in the finalize request.
              If false or absent absent, the ACME server does not require the client to provide the CAA record set is this
              manner.</dd>
          </dl>
          <t>A directory of such a CA could look like</t> like the following:</t>
          <sourcecode type="http"> type="http"><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/json

{
  "newNonce": "https://acme-server.example.onion/acme/new-nonce",
  "newAccount": "https://acme-server.example.onion/acme/new-account",
  "newOrder": "https://acme-server.example.onion/acme/new-order",
  "revokeCert": "https://acme-server.example.onion/acme/revoke-cert",
  "keyChange": "https://acme-server.example.onion/acme/key-change",
  "meta": {
    "termsOfService": "https://acme-server.example.onion/acme/terms/2023-10-13",
    "website": "https://acmeforonions.example/",
    "caaIdentities": ["acmeforonions.example"],
    "inBandOnionCAARequired": true
  }
}
          </sourcecode>
]]></sourcecode>
        </section>
        <section>
          <name>Example in-band In-Band CAA</name>
          <t>Given the following example CAA record set for 5anebu2glyc235wbbop3m2ukzlaptpkq333vdtdvcjpigyb7x2i2m2qd.onion
            (additional linebreaks line breaks have been added for readability):</t>
          <sourcecode>
          <sourcecode><![CDATA[
caa 128 issue "acmeforonions.example;
            validationmethods=onion-csr-01"
caa 0 iodef "mailto:example@example.com"
          </sourcecode>
]]></sourcecode>
          <t>The following would be submitted to the ACME server's finalize endpoint
            (additional linebreaks line breaks have been added for readability):</t>
          <sourcecode type="http"> type="http"><![CDATA[
POST /acme/order/TOlocE8rfgo/finalize
Host: acme-server.example.onion
Content-Type: application/jose+json

{
  "protected": base64url({
    "alg": "ES256",
    "kid": "https://acme-server.example.onion/acme/acct/evOfKhNU60wg",
    "nonce": "MSF2j2nawWHPxxkE3ZJtKQ",
    "url": "https://acme-server.example.onion/acme/order/TOlocE8rfgo/finalize"
  }),
  "payload": base64url({
    "csr": "MIIBPTCBxAIBADBFMQ...FS6aKdZeGsysoCo4H9P",
    "onionCAA": {
      "5anebu2glyc235wbbop3m2ukzlaptpkq333vdtdvcjpi
            gyb7x2i2m2qd.onion": {
        "caa": "caa 128 issue \"acmeforonions.example;
            validationmethods=onion-csr-01\"\n
            caa 0 iodef \"mailto:example@example.com\"",
        "expiry": 1697210719,
        "signature": "u_iP6JZ4JZBrzQUKH6lSrWejjRfeQmkTuehc0_FaaTNP
            AV0RVxpUz9r44DRdy6kgy0ofnx18KIhMrP7N1wpxAA=="
      }
    }
  }),
  "signature": "uOrUfIIk5RyQ...nw62Ay1cl6AB"
}
          </sourcecode>
]]></sourcecode>
        </section>
      </section>
    </section>

    <section anchor="IANA">
      <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>
        <name>Validation Methods</name>
        <t>Per this document, one

        <t>One new entry has been added to the "ACME Validation Methods" registry that was defined in
          <xref target="RFC8555" section="9.7.8"/>
          (<eref target="https://www.iana.org/assignments/acme/acme.xhtml#acme-validation-methods"/>).
          This entry is defined below:</t> brackets="angle" target="https://www.iana.org/assignments/acme"/>).</t>
        <table>
          <name>New entry</name>
          <name>onion-csr-01 Validation Method</name>
          <thead>
            <tr>
              <th>Label</th>
              <th>Identifier Type</th>
              <th>ACME</th>
              <th>Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td>onion-csr-01</td>
              <td>dns</td>
              <td>Y</td>
              <td>This document</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section>
        <name>Error Types</name>
        <t>Per

<!-- [rfced] Please note that we believe Section 9.7.8 should actually
     read 9.8.4 in the following.  Please review and confirm our
     update.

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.8"/> section="9.7.4"/>
          (<eref target="https://www.iana.org/assignments/acme/acme.xhtml#acme-error-types"/>).
          This entry is defined below:</t> brackets="angle" target="https://www.iana.org/assignments/acme"/>).</t>
        <table>
          <name>New entry</name>
          <name>onionCAARequired Error Type</name>
          <thead>
            <tr>
              <th>Type</th>
              <th>Description</th>
              <th>Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td>onionCAARequired</td>
              <td>The CA only supports checking the CAA for hidden services in-band, but the client has not provided an
                in-band CAA</td>
              <td>This document</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section>
        <name>Directory Metadata Fields</name>
        <t>Per this document, one

<!-- [rfced] We believe "ACME Directory Metadata Fields" registry is
     defined in Section 9.7.6 of [RFC8555], not Section 9.7.8. Please
     confirm our update.
	-->

        <t>One new entry has been added to the "ACME Directory Metadata Fields" registry that was defined in
          <xref target="RFC8555" section="9.7.8"/> section="9.7.6"/>
          (<eref target="https://www.iana.org/assignments/acme/acme.xhtml#acme-directory-metadata-fields"/>).
          This entry is defined below:</t> brackets="angle" target="https://www.iana.org/assignments/acme"/>).</t>
        <table>
          <name>New entry</name>
          <name>onionCAARequired Metadata Field</name>
          <thead>
            <tr>
              <th>Field name</th>
              <th>Field type</th>
              <th>Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td>onionCAARequired</td>
              <td>boolean</td>
              <td>This document</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>

    <section anchor="Security">
      <name>Security Considerations</name>
      <section>
        <name>Security of the "onion-csr-01" challenge</name> Challenge</name>
        <t>The security considerations of <xref target="cabf-br"/> apply to issuance using the CSR method.</t>
      </section>
      <section anchor="security-id-dns">
        <name>Use of the "dns" identifier type</name> Identifier Type</name>
        <t>The re-use reuse of the "dns" identifier type for a Special-Use Domain Name not actually in the DNS infrastructure
          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 security concern in reuse of the "dns"
          identifier type with regards regard to the mis-issuance by CAs that are not aware of ".onion"
          Special-Use Domain Names, Names as CAs would not be able to resolve the identifier in the DNS.</t>
        <section>
          <name>"http-01" Challenge</name>
          <t>In the absence of knowledge of this document document, a CA would follow the procedure set out in
            <xref target="RFC8555" section="8.3"/> section="8.3"/>, which specifies that the CA should "Dereference the URL using an
            HTTP GET request". Given that ".onion" Special-Use Domain Names require special handling to dereference,
            this de-referencing dereferencing will fail, disallowing issuance.</t>
        </section>
        <section>
          <name>"tls-alpn-01" Challenge</name>
          <t>In the absence of knowledge of this document document, a CA would follow the procedure set out in
            <xref target="RFC8737" section="3"/> section="3"/>, which specifies that the CA "resolves the domain name being validated
            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 dereferencing will fail, disallowing issuance.</t>
        </section>
        <section>
          <name>"dns-01" Challenge</name>
          <t>In the absence of knowledge of this document document, a CA would follow the procedure set out in
            <xref target="RFC8555" section="8.4"/> section="8.4"/>, which specifies that the CA should "query for TXT records for the
            validation domain name". Given that ".onion" Special-Use Domain Names are not present in the DNS
            infrastructure, this query will fail, disallowing issuance.</t>
        </section>
      </section>
      <section>
        <name>Key Authorization with "onion-csr-01"</name>
        <t>The "onion-csr-01" challenge does not make use of the key authorization string defined in
          <xref target="RFC8555" section="8.1"/>. This does not weaken the integrity of authorizations.</t>
        <t>The key authorization exists to ensure that that, whilst an attacker observing the validation channel can observe
          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 the validation channel for this challenge
          is ACME itself, and ACME already requires that the request be signed by the account, the key authorization is
          not necessary.</t>
      </section>
      <section>
        <name>Use of Tor for non-".onion" domains</name> Domains That Are Not ".onion"</name>
        <t>An ACME server <bcp14>MUST NOT</bcp14> utilise utilize Tor for the validation of non-".onion" domains, domains that are not ".onion", due to the
          risk of exit hijacking <xref target="spoiled-onions"/>.</t>
      </section>
      <section>
        <name>Redirects with "http-01"</name>
        <t>A site <bcp14>MAY</bcp14> redirect to another site when completing validation using the "http-01" challenge.
          This redirect <bcp14>MAY</bcp14> be to either another ".onion" Special-Use Domain Name, Name or to a domain in the public DNS.
          A site operator <bcp14>MUST</bcp14> consider the privacy implications of redirecting to a non-".onion" site - that is not ".onion" -- namely that the ACME server operator will then be able to learn information about the site they were redirected to
          that they would not have if accessed via a ".onion" Special-Use Domain Name, such as its IP address. If the site
          redirected to is on the same or an adjacent host to the ".onion" Special-Use Domain Name Name, this reveals
          information <xref target="tor-spec" section="Tor that the <eref target="https://spec.torproject.org/rend-spec/index.html">"Tor Rendezvous Specification - Version 3" relative="#tor-rendezvous-specification---version-3"/> 3"</eref> secion of <xref target="tor-spec"/> was otherwise designed to protect.</t>
        <t>If an ACME server receives a redirect to a domain in the public DNS DNS, it <bcp14>MUST NOT</bcp14> utilise utilize Tor
          to make a connection to it, it due to the risk of exit hijacking.</t>
      </section>
      <section>
        <name>Security of CAA records</name>
        <t>The Records</name>

<!--[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 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. For more information about this
          process
          process, see <xref target="tor-spec" section="&quot;Hidden the <eref target="https://spec.torproject.org/rend-spec/hsdesc-encrypt.html">"Hidden service descriptors: encryption format&quot;" relative="#HS-DESC-ENC" />.</t> format"</eref> section of <xref target="tor-spec"/>.</t>
      </section>
      <section>
        <name>In-band
        <name>In-Band CAA</name>
        <t>Tor

<!--[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, 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>
      </section>
      <section>
        <name>Access of the Tor network</name> Network</name>
        <t>The ACME server <bcp14>MUST</bcp14> make its own connection to the hidden service via the Tor network, network
          and <bcp14>MUST NOT</bcp14> outsource this to a third-party service, such as by using Tor2Web.</t>
      </section>
      <section>
        <name>Anonymity of the ACME client</name> Client</name>
        <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 service on the host requesting
          certificates to unintended parties - parties; this is true even when features such as ECH Encrypted ClientHello (ECH) <xref target="I-D.ietf-tls-esni"/> are
          utilised,
          utilized, as the IP addresses of ACME servers are generally well-known, static, and not used for any other
          purpose.</t>
        <t>ACME clients <bcp14>SHOULD</bcp14> connect to ACME servers over the Tor network to alleviate this, preferring
        a hidden service endpoint if the CA provides such a service.</t>
        <t>If an ACME client requests a publicly trusted WebPKI certificate certificate, it will expose the existence of the Hidden
          Service publicly due to its inclusion in Certificate Transparency logs <xref target="RFC9162"/>. Hidden Service
          operators <bcp14>MUST</bcp14> consider the privacy implications of this before requesting WebPKI
          certificates. ACME client developers <bcp14>SHOULD</bcp14> warn users about the risks of CT logged CT-logged
          certificates for hidden services.</t>
        <section>
          <name>Avoid unnecessary certificates</name> Unnecessary Certificates</name>
          <t>Not all services will need a publicly trusted WebPKI certificate; for internal or non-public services,
            operators <bcp14>SHOULD</bcp14> consider using self-signed or privately-trusted privately trusted certificates that aren't
            logged to certificate transparency.</t>
        </section>
        <section>
          <name>Obfuscate subscriber information</name> Subscriber Information</name>
          <t>When an ACME client is registering to with an ACME server server, it <bcp14>SHOULD</bcp14> provide minimal or obfuscated
            subscriber details to the CA CA, such as a pseudonymous email address, if at all possible.</t>
        </section>
        <section>
          <name>Separate ACME account keys</name> Account Keys</name>
          <t>If a hidden service operator does not want their different hidden services to be correlated by a CA CA, they
            <bcp14>MUST</bcp14> use separate ACME account keys for each hidden service.</t>
        </section>
      </section>
    </section>
  </middle>

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

        <referencegroup anchor="BCP14" target="https://www.rfc-editor.org/info/bcp14">

        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2119.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8174.xml"/>
        </referencegroup> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2986.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2986.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4648.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7686.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7686.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8037.xml"/>
	        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8037.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8555.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8555.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8659.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8659.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8737.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8737.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3629.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/>

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

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

        <reference anchor="cabf-br" target="https://cabforum.org/working-groups/server/baseline-requirements/documents/CA-Browser-Forum-TLS-BR-2.0.6.pdf">
          <front>
            <title>Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates</title>
            <author>
              <organization>CA/Browser Forum</organization>
            </author>
            <date day="5" month="August" year="2024"/>
          </front>
          <refcontent>Version 2.0.6</refcontent>
        </reference>

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

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

<!-- [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" target="https://rdcu.be/d1ZRp"> anchor="spoiled-onions">
          <front>
            <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="Richard Köwer"/>
            <author fullname="Martin Mulazzani"/>
            <author fullname="Markus Huber"/>
            <author fullname="Sebastian Schrittwieser"/>
            <author fullname="Stefan Lindskog"/>
            <author fullname="Edgar Weippl"/>
            <date>2014</date>
            <date year="2014"/>
          </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>

<!-- [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://www.rfc-editor.org/refs/bibxml/reference.RFC.9162.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9162.xml"/>
      </references>
    </references>

    <section anchor="use-of-id-dns">
      <name>Discussion on the use Use of the "dns" identifier type</name> Identifier Type</name>
      <t>The reasons for utilising utilizing the "dns" identifier type in ACME and not defining a new identifier type for
        ".onion"s
        ".onion" may not seem obvious at first glance. After all, ".onion" Special-Use Domain
        Names are not part of the DNS infrastructure and and, as such such, why should they use the "dns" identifier type?</t>
      <t><xref target="cabf-br" section="B.2.a.ii" relative="#page=124"/> defines, and this document allows,
        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 Tor-terminating proxy (as per the setup suggested by the
        Tor project <xref target="onion-services-setup"/>), existing ACME tooling can be blind to the fact that a
        ".onion" Special-Use Domain Name is being utilised, utilized, as they simply receive an incoming TCP connection as they
        would regardless (albeit from the Tor terminating 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
        server. Neither Certbot nor NGINX would require any modification to be aware of any special handling for
        ".onion" Special-Use Domain Names.</t>
      <t>This does raise some questions regarding security within existing implementations, however implementations; however, the authors believe
        this is of little concern, as per <xref target="security-id-dns"/>.</t>
    </section>

    <section anchor="Acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <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 document:</t>
      <ul>
        <li>Iain Learmonth</li>
        <li>Jan-Frederik Rieckers</li>
        <li><t><contact fullname="Iain Learmonth"/></t></li>
        <li><t><contact fullname="Jan-Frederik Rieckers"/></t></li>
      </ul>
    </section>
  </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 "Authentication during the introduction phase" section of [tor-spec]) to authenticate itself 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>