<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">Hi Shelikhoo,</div><div dir="ltr"><br></div><div dir="ltr">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.</div><div dir="ltr"><br></div><div dir="ltr">I suggest you take up your new method with the CA/BF for addition to their BR.</div><div dir="ltr"><br></div><div dir="ltr">Thanks,</div><div dir="ltr">Q</div><div dir="ltr"><br><blockquote type="cite">On 5 May 2023, at 15:56, Shelikhoo <shelikhoo@torproject.org> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div aria-live="assertive" id="magicdomid18" class="ace-line"><span class="author-a-1z83zz80zz71zqqz71zk0lz65z78z82zyu">Hi Q!</span></div>
<div aria-live="assertive" id="magicdomid20" class="ace-line"><br>
</div>
<div aria-live="assertive" id="magicdomid1435" class="ace-line"><span class="author-a-1z83zz80zz71zqqz71zk0lz65z78z82zyu">I have an
alternative design of public key infrastructure for onion
services that I would like you to consider. I have described it
on </span><span class="author-a-1z83zz80zz71zqqz71zk0lz65z78z82zyu url"><a href='https://e.as207960.net/w4bdyj/qVDXCquC' rel="noreferrer noopener" class="moz-txt-link-freetext">https://gitlab.torproject.org/tpo/core/torspec/-/issues/171</a></span><span class="author-a-1z83zz80zz71zqqz71zk0lz65z78z82zyu">, and here
is a rephrase of it.</span></div>
<div aria-live="assertive" id="magicdomid292" class="ace-line"><br>
</div>
<div aria-live="assertive" id="magicdomid2059" class="ace-line"><span class="author-a-1z83zz80zz71zqqz71zk0lz65z78z82zyu">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.</span></div>
<div aria-live="assertive" id="magicdomid1111" class="ace-line"><br>
</div>
<div aria-live="assertive" id="magicdomid1630" class="ace-line"><span class="author-a-1z83zz80zz71zqqz71zk0lz65z78z82zyu">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.</span></div>
<div aria-live="assertive" id="magicdomid1663" class="ace-line"><br>
</div>
<div aria-live="assertive" id="magicdomid6154" class="ace-line"><span class="author-a-1z83zz80zz71zqqz71zk0lz65z78z82zyu">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.</span></div>
<div aria-live="assertive" id="magicdomid2882" class="ace-line"><br>
</div>
<div aria-live="assertive" id="magicdomid6155" class="ace-line"><span class="author-a-1z83zz80zz71zqqz71zk0lz65z78z82zyu">It has the
following advantages compare to the plan mentioned in your
email: </span></div>
<div aria-live="assertive" id="magicdomid5467" class="ace-line"><span class="author-a-1z83zz80zz71zqqz71zk0lz65z78z82zyu">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)</span></div>
<div aria-live="assertive" id="magicdomid6157" class="ace-line"><span class="author-a-1z83zz80zz71zqqz71zk0lz65z78z82zyu">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.</span></div>
<div aria-live="assertive" id="magicdomid6156" class="ace-line"><span class="author-a-1z83zz80zz71zqqz71zk0lz65z78z82zyu">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.</span></div>
<div aria-live="assertive" id="magicdomid5910" class="ace-line"><span class="author-a-1z83zz80zz71zqqz71zk0lz65z78z82zyu">4. The onion
certificate seed can be generated offline, which allow it to be
stored in a secure/offline location.</span></div>
<div aria-live="assertive" id="magicdomid6219" class="ace-line"><span class="author-a-1z83zz80zz71zqqz71zk0lz65z78z82zyu">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.</span></div>
<div aria-live="assertive" id="magicdomid6163" class="ace-line"><br>
</div>
<div aria-live="assertive" id="magicdomid6172" class="ace-line"><span class="author-a-1z83zz80zz71zqqz71zk0lz65z78z82zyu">Shelikhoo</span></div>
<p></p>
<div class="moz-cite-prefix">On 25/4/2023 1:02 pm, Q Misell via
tor-dev wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAMEWqGtMVpksgroYUh+LQHOy=9Cb3PSnrDF-7HPredym9Pd6mg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Hi all,
<div><br>
</div>
<div>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 <a href='https://e.as207960.net/w4bdyj/AJF219Qf' moz-do-not-send="true">https://acmeforonions.org</a>.</div>
<div><br>
</div>
<div>Attached is my proposal for a change to the Tor Rendezvous
Specification to support the inclusion of CAA records in
hidden service descriptors.</div>
<div><br>
</div>
<div>My fork of Tor implementing publishing these records is
available at <a href='https://e.as207960.net/w4bdyj/NmgPwb3o' moz-do-not-send="true">https://github.com/as207960/tor</a>.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Q<br>
<div>
<div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">
<hr style="height:1px;background-color:#cbd5e0;margin-top:1rem;margin-bottom:1rem;border:0">
<p style="font-size:12px;color:#6c757d"> 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 № <a href='https://e.as207960.net/w4bdyj/grZU71IO' target="_blank" moz-do-not-send="true">12417574</a>.
ICO register №: <a href='https://e.as207960.net/w4bdyj/QuNjuAbX' target="_blank" moz-do-not-send="true">ZA782876</a>.
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.
</p>
</div>
</div>
</div>
</div>
<p class="ampimg" style="display:none;visibility:none;margin:0;padding:0;line-height:0;"><img src="https://e.as207960.net/img/w4bdyj/ioLGBYOE3iMf" alt="" moz-do-not-send="true" data-unique-identifier=""></p>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
tor-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a>
<a class="moz-txt-link-freetext" href='https://e.as207960.net/w4bdyj/LfTlGLyS'>https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a>
</pre>
</blockquote>
<span>_______________________________________________</span><br><span>tor-dev mailing list</span><br><span>tor-dev@lists.torproject.org</span><br><span>https://www.google.com/url?q=https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev&source=gmail-imap&ust=1683903406000000&usg=AOvVaw21rTr9V-e22BtvB4YoHDZ-</span><br></div></blockquote><p class='ampimg' style='display:none;visibility:none;margin:0;padding:0;line-height:0;'><img src='https://e.as207960.net/img/w4bdyj/kBBQYH5WxiaR' alt=''></p></body></html>