AS207960 Cyfyngedig

13 Pen-y-lan Terrace Caerdydd CF23 9EU United Kingdom q@as207960.net q@magicalcodewit.ch https://magicalcodewit.ch

SEC acme tor hidden service onion service caa dns 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).

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
  • .  Requirements Language
• .  Identifier
• .  Identifier Validation Challenges
  • .  Existing Challenges
    • .  Existing: "dns-01" Challenge
    • .  Existing: http-01 Challenge
    • .  Existing tls-alpn-01 Challenge
  • .  New onion-csr-01 Challenge
• .  Client Authentication to Hidden Services
• .  ACME over Hidden Services
• .  Certification Authority Authorization (CAA)
  • .  Relevant Resource Record Set
  • .  When to Check CAA
  • .  Preventing Mis-Issuance by Unknown CAs
  • .  Alternative In-Band Presentation of CAA
    • .  ACME Servers Requiring In-Band CAA
    • .  Example In-Band CAA
• .  IANA Considerations
  • .  Validation Methods
  • .  Error Types
  • .  Directory Metadata Fields
• .  Security Considerations
  • .  Security of the onion-csr-01 Challenge
  • .  Use of the "dns" Identifier Type
    • .  http-01 Challenge
    • .  tls-alpn-01 Challenge
    • .  dns-01 Challenge
  • .  Key Authorization with onion-csr-01
  • .  Use of Tor for Domains That Are Not ".onion"
  • .  Redirects with http-01
  • .  Security of CAA Records
  • .  In-Band CAA
  • .  Access of the Tor Network
  • .  Anonymity of the ACME Client
    • .  Avoid Unnecessary Certificates
    • .  Obfuscate Subscriber Information
    • .  Separate ACME Account Keys
• .  References
  • .  Normative References
  • .  Informative References
• .  Discussion on the Use of the "dns" Identifier Type
• Acknowledgements
• Author's Address

Introduction The Tor network has the ability to host "Onion Services" only accessible via the Tor network. These services use the ".onion" Special-Use Domain Name to identify these services. These can be used as any other domain name could, but they do not form part of the DNS infrastructure. The Automated Certificate Management Environment (ACME) 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. 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 Domain Names. Additionally, this document defines an alternative to the DNS Certification Authority Authorization (CAA) Resource Record that can be used with ".onion" Special-Use Domain Names.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Identifier defines the "dns" identifier type. This identifier type MUST be used when requesting a certificate for a ".onion" Special-Use Domain Name. The value of the identifier MUST be the textual representation as defined in the "Special Hostnames in Tor - .onion" section of . The value MAY include subdomain labels. Version 2 addresses MUST NOT be used as these are now considered insecure. Example identifiers (line breaks have been added for readability only): { "type": "dns", "value": "bbcweb3hytmzhn5d532owbu6oqadra5z3ar726v q5kgwwn6aucdccrad.onion" } { "type": "dns", "value": "www.bbcweb3hytmzhn5d532owbu6oqadra5z3ar726v q5kgwwn6aucdccrad.onion" }

Identifier Validation Challenges The CA/Browser Forum Baseline Requirements define methods accepted by the CA industry for validation of ".onion" Special-Use Domain Names (see ). This document incorporates these methods into ACME challenges.

Existing Challenges

Existing: "dns-01" Challenge The existing "dns-01" challenge MUST NOT be used to validate ".onion" Special-Use Domain Names as these domains are not part of the DNS.

Existing: http-01 Challenge The http-01 challenge, as defined in , MAY be used to validate a ".onion" Special-Use Domain Name with the modifications defined in this document, namely those described in Sections and . 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. For example, clients might use redirects so that the response can be provided by a centralized certificate management server. See for security considerations on why a server might not want to follow redirects.

Existing tls-alpn-01 Challenge The tls-alpn-01 challenge, as defined in , MAY be used to validate a ".onion" Special-Use Domain Name with the modifications defined in this document, namely those described in Sections and .

New onion-csr-01 Challenge The two ACME-defined methods allowed by CA/BF described in Sections and (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 Certificate Signing Request (CSR) (as defined by ) into ACME to allow for the issuance of wildcard certificates. To this end, a new challenge called onion-csr-01 is defined, with the following fields:

type (required, string):

The string onion-csr-01.

nonce (required, string):

A Base64-encoded nonce including padding characters. It MUST contain at least 64 bits of entropy. A response generated using this nonce MUST NOT be accepted by the ACME server if the nonce used was generated by the server more than 30 days prior (as per ).

authKey (optional, object):

The ACME server's Ed25519 public key encoded as per . This is further defined in .

{ "type": "onion-csr-01", "url": "https://acme-server.example.onion/acme/chall/bbc625c5", "status": "pending", "nonce": "bI6/MRqV4gw=", "authKey": { ... } } An onion-csr-01 challenge MUST NOT be used to issue certificates for Special-Use Domain Names that are not ".onion". Clients prove control over the key associated with the ".onion" service by generating a Certificate Request (CSR) with the following additional extension attributes and signing it with the private key of the ".onion" Special-Use Domain Name:

• A caSigningNonce attribute containing the nonce provided in the challenge. This MUST be raw bytes and not the base64 encoded value provided in the challenge object.
• An applicantSigningNonce attribute containing a nonce generated by the client. This MUST have at least 64 bits of entropy. This MUST be raw bytes.

These additional attributes have the following format 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 } } The subject of the CSR need not be meaningful and CAs MUST NOT validate its contents. The public key presented in this CSR MUST be the public key corresponding to the ".onion" Special-Use Domain Name being validated. It MUST NOT be the same public key presented in the CSR to finalize the order. Clients respond with the following object to validate the challenge:

csr (required, string):

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 Privacy Enhanced Mail (PEM).)

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" } When presented with the CSR, the server verifies it in the following manner:

1. The CSR is a well formatted PKCS#10 request.
2. The public key in the CSR corresponds to the ".onion" Special-Use Domain Name being validated.
3. The signature over the CSR validates with the ".onion" Special-Use Domain Name public key.
4. The caSigningNonce attribute is present and its contents match the nonce provided to the client.
5. The applicantSigningNonce attribute is present and contains at least 64 bits of entropy.

If all of the above are successful then validation succeeds, otherwise it has failed.

Client Authentication to Hidden Services 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, these services will not be able to obtain a certificate using http-01 or tls-alpn-01, nor enforce CAA with any validation method. 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 ) to authenticate itself when retrieving the Hidden Service Descriptor.

authKey (optional, object):

The ACME server's Ed25519 public key encoded as per .

ACME servers MUST NOT use the same public key with multiple Hidden Services. ACME servers MAY reuse public keys for re-validation of the same Hidden Service. There is no method to communicate to the CA that client authentication is necessary; instead, the ACME server MUST attempt to calculate its CLIENT-ID as per the "Client behavior" section of . If no auth-client line in the First Layer Hidden Service Descriptor matches the computed client-id, then the server MUST assume that the Hidden Service does not require client authentication and proceed accordingly. In the case in which the Ed25519 public key is novel to the client, it will have to resign and republish its Hidden Service Descriptor. It MUST wait some (indeterminate) amount of time for the new descriptor to propagate the Tor Hidden Service directory 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 MUST NOT expire challenges before a reasonable time to allow publication of the new descriptor. It is RECOMMENDED the server allow at least 30 minutes; however, it is entirely up to operator preference.

ACME over Hidden Services A CA offering certificates to ".onion" Special-Use Domain Names SHOULD make their ACME server available as a Tor Hidden Service. ACME clients SHOULD 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.

Certification Authority Authorization (CAA) ".onion" Special-Use Domain Names are not part of the DNS; as such, a variation on CAA is necessary to allow restrictions to be placed on certificate issuance. To this end, a new field is added to the Second Layer Hidden Service Descriptor, as defined in the "Second layer plaintext format" section of with the following format (defined using the notation from the "netdoc document meta-format" section of ): "caa" SP flags SP tag SP value NL [Any number of times] The presentation format is provided above purely for the convenience of the reader and implementors: the canonical version remains that defined in , or future updates to the same. The contents of "flags", "tag", and "value" are as per . Multiple CAA records MAY 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. A Hidden Service's Second Layer Descriptor using CAA could look something like the following (additional line breaks have been added for readability): 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= ...

Relevant Resource Record Set In the absence of the possibility for delegation of subdomains from a ".onion" Special-Use Domain Name, as there is in the 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 Top-Level Domain (TLD), as it does not exist in any form except as described in ; therefore, implementors MUST NOT look there either. 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":

• b.a.onion
• c.a.onion
• e.d.a.onion

but these do not:

• b.c.onion
• c.d.onion
• e.c.d.onion
• a.b.onion

When to Check CAA If the Hidden Service has client authentication enabled, then it will be impossible for the ACME server to decrypt the Second Layer Hidden Service Descriptor to read the CAA records until the ACME server's public key has been added to the First Layer Hidden Service Descriptor. To this end, an ACME server MUST wait until the client responds to an authorization before checking 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 Hidden Service Descriptor.

Preventing Mis-Issuance by Unknown CAs In the case of a Hidden Service requiring client 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 Hidden Service Descriptor. A method is necessary to signal that there are CAA records present (but not reveal their contents, which, in certain circumstances, would unwantedly disclose information about the Hidden Service operator). To this end, a new field is added to the First Layer Hidden Service Descriptor in the "First layer plaintext format" section of with the following format (defined using the notation from the "netdoc document meta-format" section of ): "caa-critical" NL [At most once] If an ACME server encounters this flag, it MUST NOT proceed with issuance until it can decrypt and parse the CAA records from the Second Layer Hidden Service Descriptor.

Alternative In-Band Presentation of CAA 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. If a Hidden Service does use this method to provide CAA records to an ACME server, it SHOULD still publish CAA records if its CAA record set includes "iodef", "contactemail", or "contactphone" so that this information is still publicly accessible. Additionally, a Hidden Service operator MAY not wish to publish a CAA record set in its Hidden Service Descriptor to avoid revealing information about the service operator. If an ACME server receives a validly signed CAA record set in the finalize request, it MAY proceed with issuance on the basis of the client-provided CAA record set only, without checking the CAA set in the Hidden Service. Alternatively, an ACME server MAY ignore the client provided record set and fetch the record set from the Hidden Service Descriptor. In any case, the server MAY fetch the record set from the Hidden Service Descriptor. If an ACME server receives a validly signed CAA record set in the finalize 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 CAA record set only. An ACME server MAY ignore the client-provided record set and is free to always fetch the record set from the Hidden Service Descriptor. A new field is defined in the ACME finalize endpoint to contain the Hidden Service's CAA record set for each ".onion" Special-Use Domain Name in the order.

onionCAA (optional, dictionary of objects):

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 fields described below.

The contents of the values of the "onionCAA" object are as follows:

caa (required, string or null):

The CAA record set as a string, encoded in the same way as if was included in the Hidden Service Descriptor. If the Hidden Service does not have a CAA record set, then this MUST be null.

expiry (required, integer):

The Unix timestamp at which this CAA record set will expire. This SHOULD NOT be more than 8 hours in the future. ACME servers MUST process this as at least a 64-bit integer to ensure functionality beyond 2038.

signature (required, string):

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.

The data that the signature is calculated over is the concatenation of the following, encoded in UTF-8 : "onion-caa|" || expiry || "|" || caa 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.

ACME Servers Requiring In-Band CAA If an ACME server does not support fetching a service's CAA record set from its Hidden 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. To support 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.

inBandOnionCAARequired (optional, boolean):

If true, the ACME server requires the client to provide the CAA record 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 manner.

A directory of such a CA could look like the following: 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 } }

Example In-Band CAA Given the following example CAA record set for 5anebu2glyc235wbbop3m2ukzlaptpkq333vdtdvcjpigyb7x2i2m2qd.onion (additional line breaks have been added for readability): caa 128 issue "acmeforonions.example; validationmethods=onion-csr-01" caa 0 iodef "mailto:example@example.com" The following would be submitted to the ACME server's finalize endpoint (additional line breaks have been added for readability): 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" }

IANA Considerations

Validation Methods One new entry has been added to the "ACME Validation Methods" registry that was defined in (). onion-csr-01 Validation Method

Label	Identifier Type	ACME	Reference
onion-csr-01	dns	Y	RFC 9799

Error Types One new entry has been added to the "ACME Error Types" registry that was defined in (). onionCAARequired Error Type

Type	Description	Reference
onionCAARequired	The CA only supports checking the CAA for Hidden Services in-band, but the client has not provided an in-band CAA	RFC 9799

Directory Metadata Fields One new entry has been added to the "ACME Directory Metadata Fields" registry that was defined in (). onionCAARequired Metadata Field

Field name	Field type	Reference
onionCAARequired	boolean	RFC 9799

Security Considerations

Security of the onion-csr-01 Challenge The security considerations of apply to issuance using the Certificate Request method.

Use of the "dns" Identifier Type The 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 . It is felt that there is little security concern in reuse of the "dns" identifier type with regard to the mis-issuance by CAs that are not aware of ".onion" Special-Use Domain Names as CAs would not be able to resolve the identifier in the DNS.

http-01 Challenge In the absence of knowledge of this document, a CA would follow the procedure set out in , 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 dereferencing will fail, disallowing issuance.

tls-alpn-01 Challenge In the absence of knowledge of this document, a CA would follow the procedure set out in , 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 dereferencing will fail, disallowing issuance.

dns-01 Challenge In the absence of knowledge of this document, a CA would follow the procedure set out in , 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.

Key Authorization with onion-csr-01 The onion-csr-01 challenge does not make use of the key authorization string defined in . This does not weaken the integrity of authorizations. The key authorization exists to ensure 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.

Use of Tor for Domains That Are Not ".onion" An ACME server MUST NOT utilize Tor for the validation of domains that are not ".onion", due to the risk of exit hijacking .

Redirects with http-01 A site MAY redirect to another site when completing validation using the http-01 challenge. This redirect MAY be to either another ".onion" Special-Use Domain Name or a domain in the public DNS. A site operator MUST consider the privacy implications of redirecting to a 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, this reveals information that the "Tor Rendezvous Specification - Version 3" section of was otherwise designed to protect. If an ACME server receives a redirect to a domain in the public DNS, it MUST NOT utilize Tor to make a connection to it due to the risk of exit hijacking.

Security of CAA Records The Second Layer Hidden Service Descriptor is signed, encrypted, and encoded using a 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, see the "Hidden service descriptors: encryption format" section of .

In-Band CAA 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: the CAA records are verified using the same hidden service key in either case.

Access of the Tor Network The ACME server MUST make its own connection to the Hidden Service via the Tor network and MUST NOT outsource this to a third-party service, such as Tor2Web.

Anonymity of the ACME Client ACME clients requesting certificates for ".onion" Special-Use Domain Names not over the Tor network can inadvertently expose the existence of a Hidden Service on the host requesting certificates to unintended parties; this is true even when features such as Encrypted ClientHello (ECH) are utilized, as the IP addresses of ACME servers are generally well-known, static, and not used for any other purpose. ACME clients SHOULD connect to ACME servers over the Tor network to alleviate this, preferring a Hidden Service endpoint if the CA provides such a service. If an ACME client requests a publicly trusted WebPKI certificate, it will expose the existence of the Hidden Service publicly due to its inclusion in Certificate Transparency logs . Hidden Service operators MUST consider the privacy implications of this before requesting WebPKI certificates. ACME client developers SHOULD warn users about the risks of CT-logged certificates for Hidden Services.

Avoid Unnecessary Certificates Not all services will need a publicly trusted WebPKI certificate; for internal or non-public services, operators SHOULD consider using self-signed or privately trusted certificates that aren't logged to certificate transparency.

Obfuscate Subscriber Information When an ACME client is registering with an ACME server, it SHOULD provide minimal or obfuscated subscriber details to the CA, such as a pseudonymous email address, if at all possible.

Separate ACME Account Keys If a Hidden Service operator does not want their different Hidden Services to be correlated by a CA, they MUST use separate ACME account keys for each Hidden Service.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Internet community. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] This document registers the ".onion" Special-Use Domain Name. This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE). RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. CAA Resource Records allow a public CA to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by CAs. This document obsoletes RFC 6844. This document specifies a new challenge for the Automated Certificate Management Environment (ACME) protocol that allows for domain control validation using TLS. ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279. The Tor Project The Tor Project commit 2437d19c CA/Browser Forum Version 2.0.6 Informative References The Tor Project Privacy Enhancing Technologies (PETS 2014), Lecture Notes in Computer Science, vol. 8555, pp. 304-331 Independent Fastly Cryptography Consulting LLC Cloudflare This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tlswg/draft-ietf-tls-esni (https://github.com/tlswg/draft-ietf-tls-esni). Work in Progress This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.

Discussion on the Use of the "dns" Identifier Type The reasons for utilizing the "dns" identifier type in ACME and not defining a new identifier type for ".onion" may not seem obvious at first glance. After all, ".onion" Special-Use Domain Names are not part of the DNS infrastructure and, as such, why should they use the "dns" identifier type? 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 proxy (as per the setup suggested by the Tor project ), existing ACME tooling can be blind to the fact that a ".onion" Special-Use Domain Name is being utilized, as they simply receive an incoming TCP connection as they would regardless (albeit from the Tor-terminating proxy). 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. This does raise some questions regarding security within existing implementations; however, the authors believe this is of little concern, as per .

Acknowledgements With thanks to the Open Technology Fund for funding the work that went into this document. The authors also wish to thank the following for their input on this document:

Author's Address AS207960 Cyfyngedig

13 Pen-y-lan Terrace Caerdydd CF23 9EU United Kingdom q@as207960.net q@magicalcodewit.ch https://magicalcodewit.ch