Support for FQDNs under .onion

Background

Historically the CABF baseline requirements have considered FQDNs with .onion as the rightmost label "internal names" because the TLD is not registered in IANA's root zone database:

Internal Name: A string of characters (not an IP address) in a Common Name or Subject Alternative Name field of a Certificate that cannot be verified as globally unique within the public DNS at the time of certificate issuance because it does not end with a Top Level Domain registered in IANA’s Root Zone Database.

To support HTTPS for .onion sites the "Extended Validation Certificate Guidelines" specify a carve-out that allows issuing EV certificates for .onion FQDNs if extra steps specified in an Appendix are followed:

For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant’s control
over the .onion Domain Name in accordance with Appendix F.

The EV requirement and the additional cabf-TorServiceDescriptor certificate extension in Appendix F were largely intended to address weak cryptography used by tor v2 .onion addresses. Since the v3 address specification addresses those weaknesses there is now a proposal in the CABF validation working group in the works by Wayne Thayer of Mozilla to change the CABF baseline requirements to allow DV issuance for .onion FQDNs that are implemented with the "v3" .onion address specification.

Implementation notes

If a ballot based on this proposal were to be approved Let's Encrypt/Boulder could in theory issue for .onion domains. This issue is to track some of the things we'd need to figure out to support that. It isn't a commitment to implement, but a collection of notes particularly focused on some challenges we would face.

Domain control

From an operational perspective adding a tor daemon adjacent to each of our VA instances to allow outbound tor communication to .onion sites to verify an agreed upon change to a website (via HTTP-01) is a substantial burden. It's a complex daemon in a memory unsafe language and we would need new monitoring and a lot of general SRE work to deploy it.

We would probably prefer to implement proof of domain control support based on the "CSR validation" method described in Wayne's draft ballot since there would be no requirement to make an outbound connection to the .onion FQDN. Probably implementing the CSR validation properly would require the definition of a new ACME challenge type since there is a need to relay and verify additional information in the CSR (the caSigningNonce and the applicantSigningNonce).

Rate limits

Our rate limits are primarily based around the notion that folks can't create infinite eTLD+1's because of the cost associated with domain registration. In contrast .onion names can be minted infinitely without any substantial cost. We would need to think of a way to apply fair rate limits for .onion names in order to ensure fair distribution of our resources.

We could have a global rate limit for .onion names but that invites DoSing the availability of these certificates for others by continually issuing until the global rate limit is reached. Making the rate limit per-account would shift the burden to the new registration per IP rate limit which today is quite generous. Similarly we could affect a rate limit by requester IP but this would also be generous (and IPv6 addresses are cheap/plentiful).

Gauging demand

It's difficult to gauge subscriber demand for .onion certificates because to date the requirement for EV certificates with a custom extension meant only ~1 commercial CA implemented support and the cost was likely prohibitive for most users. Without knowing the demand it's difficult to make a decision on how important allocating resources to the work required is.

Start by reviewing the linked CABF proposal and the issue’s Domain control and Rate limits sections; no implementation entry point, file, or test is identified. Done is not defined: the issue records unresolved choices around CSR validation, a possible new ACME challenge type, rate limits, and demand rather than a bounded change.