[tor-dev] New Proposal - CAA Extensions for the Tor Rendezvous Specification

Mon May 8 15:32:44 UTC 2023

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 at 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 at lists.torproject.org
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>> _______________________________________________
>> tor-dev mailing list
>> tor-dev at lists.torproject.org
>> https://www.google.com/url?q=https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev&source=gmail-imap&ust=1683903406000000&usg=AOvVaw21rTr9V-e22BtvB4YoHDZ-
>
>
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20230508/e3d0cd1a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20230508/e3d0cd1a/attachment-0001.sig>