On Mon, Nov 6, 2017 at 8:56 AM, Fotis Loukos <[email protected]> wrote: > > > > > In the classic WebPKI case, this is the same thing. > > > > > > I would not say that's a fair conclusion - in the Web PKI case, as > > permitted by the BRs, the entity in control of the content may be > > different than the domain operator. Indeed, this is why methods such as > > relying on webserver content have been moving to whitelisted sets more > > in line with privileged control, rather than the existing set of "anyone > > with control" > > In the classic WebPKI case there is no proxy (even though you can bypass > this), while tor hidden services are just proxies and do not serve any > content. That's what I meant before. >
This is not a correct description of Tor hidden services then. They are not proxies. > > Could you explain why you believe NG names are materially different, in > > this respect, then what is permitted under the BRs? > > NG names are not materially different, the operating structure of hidden > services is. A hidden service is a proxy to something else, usually a > web server. > As noted above, as it seems the crux of the objection rests here, then we can put this to bed as incorrect. > I think that both of us should agree that after successful connection > establishment, messages are routed through relay nodes to the HS node, > which then forwards them over a stream connection outside the tor > network, and without this being part of the tor protocol. This can > either be over a local unix socket (I'm not going into details on old vs > new tor versions), or a normal tcp socket to localhost or some other > host. I think that since the HS node acts as an intermediary that > forwards requests to some other server, it can qualify as a proxy. > 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. However, since we have clarified that DV means either control over the > domain name or the web server serving the content, there is nothing > stopping us moving forward with the issuance of DV certificates for NG > .onion addresses. > > I agree with Seth Schoen's proposal for using 3.2.2.4.6, 3.2.2.4.9 and > 3.2.2.4.10 since these methods prove control of the web server serving > the content. I would also like to suggest adding a tor specific method > that proves possession of the private key corresponding to the NG .onion > address, such as b from EV SSL guidelines appendix F. 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.
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
