<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 6, 2017 at 8:56 AM, Fotis Loukos <span dir="ltr"><<a href="mailto:fotisl@ssl.com" target="_blank">fotisl@ssl.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
><br>
>     In the classic WebPKI case, this is the same thing.<br>
><br>
><br>
> I would not say that's a fair conclusion - in the Web PKI case, as<br>
> permitted by the BRs, the entity in control of the content may be<br>
> different than the domain operator. Indeed, this is why methods such as<br>
> relying on webserver content have been moving to whitelisted sets more<br>
> in line with privileged control, rather than the existing set of "anyone<br>
> with control"<br>
<br>
</span>In the classic WebPKI case there is no proxy (even though you can bypass<br>
this), while tor hidden services are just proxies and do not serve any<br>
content. That's what I meant before.<br></blockquote><div><br></div><div>This is not a correct description of Tor hidden services then. They are not proxies.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Could you explain why you believe NG names are materially different, in<br>
> this respect, then what is permitted under the BRs?<br>
<br>
</span>NG names are not materially different, the operating structure of hidden<br>
services is. A hidden service is a proxy to something else, usually a<br>
web server.<br></blockquote><div><br></div><div>As noted above, as it seems the crux of the objection rests here, then we can put this to bed as incorrect. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think that both of us should agree that after successful connection<br>
establishment, messages are routed through relay nodes to the HS node,<br>
which then forwards them over a stream connection outside the tor<br>
network, and without this being part of the tor protocol. This can<br>
either be over a local unix socket (I'm not going into details on old vs<br>
new tor versions), or a normal tcp socket to localhost or some other<br>
host. I think that since the HS node acts as an intermediary that<br>
forwards requests to some other server, it can qualify as a proxy.<br></blockquote><div><br></div><div>Using this logic, for what it's worth, implies every firewall and router is also "a proxy". For example, the common practice of placing a firewall or router in front of a server and rewriting the source/destination IPs (e.g. NAT) would, by your definition, constitute a proxy.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
However, since we have clarified that DV means either control over the<br>
domain name or the web server serving the content, there is nothing<br>
stopping us moving forward with the issuance of DV certificates for NG<br>
.onion addresses.<br>
<br>
I agree with Seth Schoen's proposal for using 3.2.2.4.6, 3.2.2.4.9 and<br>
3.2.2.4.10 since these methods prove control of the web server serving<br>
the content. I would also like to suggest adding a tor specific method<br>
that proves possession of the private key corresponding to the NG .onion<br>
address, such as b from EV SSL guidelines appendix F.</blockquote><div><br></div><div>Indeed; it seems structurally better to avoid introducing additional dependencies (e.g. a proper functioning Tor implementation), and the EVG's method of proof of possession provides such a strong guarantee without supplemental dependency. </div></div><br></div></div>