Proposal for automated onion service certificate issuance based on fully qualified onion service key signed certificate request

[xiaokangwang]

Hi! I would like to discuss the possibility of inclusion of issuing domain verified certificate for onion service(.onion) domain based on fully qualified onion service key signed certificate request (aka "onion certificate seed") into baseline requirement.

Present state of onion service certificate issuance automation

Currently, there is no trusted by default certificate authority issuing TLS certificate to onion service in an automated way(like ACME). The inclusion of onion certificate into current ACME system face the difficulty of requiring the certificate authority's ACME to connect to Tor network for checking http-01, tls-alpn-01and CAA of onion-csr-01 proposal. This is difficult with current secured setup of the certificate authority's ACME issuing environment.

Proposal

In order to prove the ownership of an onion address and create a certificate, the onion service operator generate public and private key as usual, and sign [certificate public key, certificate fields (like not before, expiry date, Subject Common Name) and extensions (like key usage), (optional, subject to discussion: nonce from ACME Issuer and ACME Client)] with their onion service private key, and place the signature and a copy of signed data as non-critical extension request of a CSR known as onion certificate seed .

This onion certificate seed can be either self-signed or submitted to certificate authority to become a full certificate. It can be submitted to certificate authority over ACME for certificate issuance. The onion key signature and signed data is copied to the final certificate as non-critical extension after validation.

Both CA and Onion Native Application (like Tor Browser) verify onion certificate seed before issuance/trust by make sure:

1. The onion key signature is valid.
2. The onion key corresponds to the ".onion" domain being validated.
3. The certificate/the certificate being signed's public key, certificate fields, extensions matches their copy in onion key signed data.
4. All critical extension, important fields&extensions(subject to further definition) are included the onion key signed data.
5. (optional, subject to discussion) The certificate valid for 7 days or less. Because Onion Native Application is not required to check revocation for certificate trusted based on onion certificate seed.
6. (optional, subject to discussion) If the certificate is being checked by an ACME CA, then check if issuer nonce included in the onion key signed data match the one supplied by ACME CA, and client nonce have 64 bits of entropy.

For Onion Native Applications (like Tor Browser), a TLS certificate is trusted if it is issued by a trusted CA, or it has a valid onion certificate seed extension. This means this certificate issue model does not absolutely need any cooperative CA to work, so long as Tor Browser and other Tor Native application supported it by default, it would work as expected. For some application designed specifically for Tor, a onion service without a valid onion certificate seed extension may be rejected. For non-Onion-Native applications, a certificate issued by certificate authority will be necessary for it to pass validation.

Pros

1. For certificate authorities, this proposal allows certificate issuance without ever connecting their certificate issuance environment to Tor network for validation, removing a major obstacle. This is still safe since all important certificate field, including public key is signed by onion service key associated with the onion service domain name and an attacker without control of onion service key could not produce such a signature for a certificate public key chosen by attacker.
2. For Onion Native Applications, this proposal can be immediately implemented and put into usage without the need of waiting for any certificate authority implement it.
3. For Onion Native Applications consider valid onion certificate seed extension critical for onion service, certificate mis-issuance has no effect on user security(but still should not happen).

This proposal is also discussed in https://forum.torproject.net/t/tor-dev-new-proposal-caa-extensions-for-the-tor-rendezvous-specification/7433/5?u=shelikhoo, https://gitlab.torproject.org/tpo/core/torspec/-/issues/171. These are earlier version written for a different perspective.

The author of this proposal is a paid employee of The Tor Project, volunteer maintainer of V2Ray for conflict of interest disclosure purpose, and this post have not been approved by author's employer or affiliated organization.

[barrini]

Hi, if you want to participate and/or contrinute to the CAB Forum, one option could be to become an Interested Party, see https://cabforum.org/interested-parties/ Meanwhile we´ll leave this issue open for some time Regards

[barrini]

Xiaokang applied for Interested Party so will keep this issue open for a while and see if there´s any action forward.