Re: [Acme] Onion address validation extension

[Sebastian Nielsen <[e-mail]>]

>>ACME protocol is not meant to proceed to CSR sending until after all
  names are validated. Breaking that would cause implementation
  problems.

Thats why there should be 2 validation types, so a client who support the new "skip ahead" validation type would know that it only needs to request onion-2 validation type, then it would immidiately skip ahead to CSR sending without checking if validation passed - since validation then occurs at CSR stage.

The reason validation is required inside ACME is because ACME (usually) needs to contact external resources to confirm your validations, which incurs a delay. If you can prove the ownership of the domain inside the actual validation response (ergo a self-validating response that can be verified "offline") theres no need to use the full blown ACME infrastructure, then you could just submit the response inside the final CSR.

Of course this wouldn't work for multiple domains, why the normal procedure with checking for validationa (onion-1) would be required.

>>The CSRs are assumed to be self-signed, which is a problem here:

Thats not a problem.
What I proposed, is that you create a CSR over the normal TLS certificate (with its signature belongning the TLS certificate's key) BUT you put your onion signature (a signature of the nonce made with the onion private key) inside the CSR field called "CSR Challenge Password".
 
So basically, you create a TOR signature with the TOR key, insert it in your final TLS CSR (as CSR Challenge Password), and then sign the TLS CSR with the TLS key.

Meaning, that the CSR *are* self-signed, and that they CONTAIN the TOR signature made with the TOR private key, making the CSR being dual-use - both validating the onion name AND also becomes the grounds for your certificate generation.