]>

tjtncks@gmail.com

General ACME Working Group This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for Tor Project's onion V3 addresses.

Introduction While onion addresses are in form of DNS address, they aren't in part of ICANN hierarchy, and onion name's self-verifying construction warrants different verification, duce different identifier type for them is worth consider.

Terminology 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.

Onion Identifier only defines the identifier type "dns", that assumes it's on public CA/B hierarchy, so to make clear Onion addresses are not using normal DNS verification methods, we assign a new identifier type for onion v3 addresses, "onion-v3". This document only handles V3 version of onion address as defined in , identified by 56 letters base domain name ends with d. This document doesn't handle about verification of version 2 of onion addresses, as they are retired already An identifier for the onion address aeceulkebl5...4zcuv5hk7fqwad.onion would be formatted like:

Keep mind in CSR this address still treated as DNS.

Validation Challenges for Onion address Onion-v3 identifiers MAY be used with the existing "http-01" and "tls-alpn-01" challenges from Section 8.3 and Section 3 respectively. To use Onion identifiers with these challenges their initial DNS resolution step MUST be skipped and the appropriate Tor daemon that in control of CA MUST used to proxy such request. The existing "dns-01" challenge MUST NOT be used to validate onion addresses. In addition to challenges earlier RFC defined, This document create an additional challenge called "onion-v3-csr". This challenge can be used for wildcard subdomain of Onion address.

Identify Key Possession Challenge With onion-csr-01 validation, the client in an ACME transaction proves its control of an Onion address or subdomain of it by proving the possession of Onion hidden service's identity key. The ACME server challenges the client to sign CSR that includes the nonce it gave as challenge. The onion-csr-01 ACME challenge object has the following format:

type (required, string):

The string "onion-v3-csr"

token (required, string):

A random value that uniquely identifies the challenge. This value MUST have at least 128 bits of entropy. It MUST NOT contain any characters outside the base64url alphabet as described in Section 5. Trailing '=' padding characters MUST be stripped. See for additional information on randomness requirements.

The client prepares for validation by constructing a self-signed CSR that MUST contain an cabf caSigningNonce Attribute and a subjectAlternativeName extension . The subjectAlternativeName extension MUST contain a single dNSName entry where the value is the domain name being validated. The cabf caSigningNonce Attribute MUST contain the token string as ascii encoded for the challenge. The cabf caSigningNonce Attribute is identified by the cabf-caSigningNonce object identifier (OID) in the cabf arc . consult appendix B for how to construct CSR itself in detail.

A client fulfills this challenge by construct the challenge CSR from the "token" value provided in the challenge, then POST on challenge URL with crafted CSR as payload to request validated by the server.

On receiving this request from client, the server verifies client's control over the onion address by verify that CSR is crafted with expected properties: CSR is signed with private part of identity key the requested onion address made from. A caSigningNonce attribute that contains token Value that challenge object provided. existence of applicantSigningNonce attribute. This value SHOULD include random value from client side with at least 64bits of entropy, and CA MUST recommend to client do so, but servers are not expected verify such claim, as by nature it's impossible to verify such claim of randomness.

IANA Considerations

Identifier Types Adds a new type to the Identifier list in ACME Identifier Types with the label "onion-v3" and reference I-D.THISDOC.

Challenge Types in the ACME Validation Methods list: Adds the raw "onion-v3-csr" to the Validation Methods. Adds the value "onion-v3" to the Identifier Type column for the "http-01", "onion-challenge-csr", and "tls-alpn-01" challenges. , and reference I-D.THISDOC each of them.

Security Considerations As onion addresses are able to generated in massive quantity without financial cost, it bypasses the normal ratelimit CAs imposes. CAs SHOULD adapt some measure to prevent DoS of CA by create hugh amount of request for onion address. For example, imposing limit per ACME account or require order to have at least one non-onion domain.

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. Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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 memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document registers the ".onion" Special-Use Domain Name. 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. This document specifies a new challenge for the Automated Certificate Management Environment (ACME) protocol that allows for domain control validation using TLS.

Notes and Questions to reviews should this be about onion address, or all kind of alternative DNS systems? should identifier type and challenge type include or strip -v3 tag from its name? if we include that how about this doc name itself? http-01 and tls-alpn-01 over tor will work as well for like onion address V2 or V12, but csr challenge may not. but it's reasonable to ask same identifier type should give same set of challenges. should the as rigid as complying this will make comply CA/B Baseline requirement? while type onion domain name just full onion v3 name itself with example subdomain will exceed rfc line limit. but using ... doesn't right in context of domain name. any alternative to express truncated FQDN? would "example.onion" work while it wouldn't be valid onion name?