Hi Q and others,

I have opened an issue about this proposal at https://github.com/cabforum/servercert/issues/433 and let's see how it goes.

In this version I added that the onion certificate seed can also include nonce from CA and ACME client, so that it would have the same proof online key possession propriety of the current version of baseline requirement.

Shelikhoo

On 5/5/2023 8:39 pm, Q via tor-dev wrote:

Hi Shelikhoo,

Your suggestion seems sound, and I’d like to see it progress further. However it is not in the CA/BF BR, so is unusable by CAs, and therefore out of scope of my project.

I suggest you take up your new method with the CA/BF for addition to their BR.

Thanks, Q

...

On 5 May 2023, at 15:56, Shelikhoo shelikhoo@torproject.org wrote:

 Hi Q!

I have an alternative design of public key infrastructure for onion services that I would like you to consider. I have described it on https://gitlab.torproject.org/tpo/core/torspec/-/issues/171, and here is a rephrase of it.

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 expiry date, Subject Common Name) and extensions (like key usage)] with their onion service private key, and place the signature and a copy of signed data as non-critical extension 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.

For Onion Native Application (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.

It has the following advantages compare to the plan mentioned in your email:

1. Since the certificate public key and expiry date is covered by

onion key's signature, Certification Authority Authorization record is not necessary, as attacker could not generate a certificate under the attacker's control, since attacker have no access to the public key. This also allow certificate authority to issue certificate without the need to have access to the Tor network or the onion service. (CA don't wish to change the design of their airtight certificate issuing environment, don't force them) 2. For Onion Native Application, this design works on day 1 without the need of any cooperative CA. Since currently a lot of onion service is access with Tor Browser, it will allow Tor Browser to push the adaption of this design with its weight. CA hates to break thing, this design gets things rolling to force trusted CAs to adapt it. 3. For Onion Native Application, this design allows valid certificate to be generated without contacting third party and publishing the onion service address. This would allow sensitive onion service to use TLS encryption without revealing its address to third party or public. 4. The onion certificate seed can be generated offline, which allow it to be stored in a secure/offline location. 5. It does not require any change to the C-Tor/Arti implementation, since it does not require either CA or even the hidden service request certificate itself connected to the Tor network.

Shelikhoo On 25/4/2023 1:02 pm, Q Misell via tor-dev wrote:

...

Hi all,

I've spent some time working on ACME for Tor hidden services (you may have seen discussion of this work on the onion-advisors mailing list). Full details of the project are available at https://acmeforonions.org https://e.as207960.net/w4bdyj/AJF219Qf.

Attached is my proposal for a change to the Tor Rendezvous Specification to support the inclusion of CAA records in hidden service descriptors.

My fork of Tor implementing publishing these records is available at https://github.com/as207960/tor https://e.as207960.net/w4bdyj/NmgPwb3o.

Thanks, Q

---

Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 https://e.as207960.net/w4bdyj/grZU71IO. ICO register №: ZA782876 https://e.as207960.net/w4bdyj/QuNjuAbX. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively.

---

tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

---

tor-dev mailing list tor-dev@lists.torproject.org https://www.google.com/url?q=https://lists.torproject.org/cgi-bin/mailman/li...

---

tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev