[cabfpub] DV issuance for next-generation onion services
sleevi at google.com
Mon Nov 6 14:30:35 UTC 2017
On Mon, Nov 6, 2017 at 8:56 AM, Fotis Loukos <fotisl at ssl.com> 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
> > 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 126.96.36.199.6, 188.8.131.52.9 and
> 184.108.40.206.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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public