[cabfpub] DV issuance for next-generation onion services

[Ryan Sleevi]

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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20171106/90c2a15b/attachment.html>