Proposal for Bring Accessible TLS Supports to All Onion Services

Currently, it is difficult to create a TLS certificate for onion services, since all existing free CA is unwilling to issue certificate for onion service for various reasons. And existing CA that issue certificate to onion services are paid, so it is forcing a difficult decision on onion service operators when it comes to choosing between (security and features) or anonymity.

So, here is the proposal for a better certificate system for onion services:

Generate a CSR

To create a CSR, generate the private and public key pair as usual, and create normal certificate field and extensions for that certificate. SAN, subject name must equal to onion address. Use the onion key to sign the public key and extensions, then put this signature into the certificate sign request as a non-critical extension.

The valid onion address CSR created in this procedure is known as onion certificate seed.

Generate a Certificate

To generate a certificate, there are two possible routes:

Self sign the certificate

Copy all the extensions and self-sign directly.

Expand the certificate by expand the certificate at a CA

Send the onion certificate seed CSR to any CA, CA will check if the extension contains a valid signature, all extension are allowed, and SAN, subject name must equal to onion address. If so, issue a certificate. This CA can be setup by Tor Project, or another organization.

Verify the certificate

Tor Native Application Like Tor Browser

Do not trust any additional CA. Whenever encountered a leaf certificate with onion key signature, if the signature pass the check in the same way as expansion CA does, then it is considered to be issued by a trusted CA.

Other application that don't understand onion key signature extension

Add the root certificate of expansion CA (skip this step if the CA is already trusted by default), and verify normally.

Advantages

In this design, for Tor Native Application, there is no additional trust put in 3rd party as the certificate have embedded proof. The operator can choose any expansion CA or self-sign without worried about fail the verification.

For other application, the certificate can still be verified with standard logic by trusting the expansion CA. In the beginning, we can run an expansion CA that is not trusted by default to work with non-Tor native application. In the end, someone else can seamlessly use their trusted by default CA to issue certificate to onion services.

Comments are welcomed

Comparsion with onion-x509

onion-x509 attempt at solving this issue by converting the onion key into a CA that can be used to sign other certificates by anchor the trust at onion key. However, there is no easy way to get existing application to work with this system, like importing an expansion CA's root.