Hi Q!
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.
Attached is my proposal for a change to the
Tor Rendezvous Specification to support the inclusion of
CAA records in hidden service descriptors.
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.
ICO register №: ZA782876.
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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://www.google.com/url?q=https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev&source=gmail-imap&ust=1683903406000000&usg=AOvVaw21rTr9V-e22BtvB4YoHDZ-