[cabfpub] DV issuance for next-generation onion services

Fotis Loukos fotisl at ssl.com
Mon Nov 6 13:56:33 UTC 2017

On 06/11/2017 03:23 μμ, Ryan Sleevi wrote:
> On Sun, Nov 5, 2017 at 9:53 AM, Fotis Loukos via Public
> <public at cabforum.org <mailto:public at cabforum.org>> wrote:
>     On 03/11/2017 07:08 μμ, Seth David Schoen via Public wrote:
>     > Peter Bowen writes:
>     >
>     >> I’m honestly not a big fan of being limited to these three methods — they all are methods which have be completed by someone with access to the “backend” server but not necessarily the onion proxy.  What options might exist for validation that are closer to the DNS validation method for Internet names?  How could a CA confirm that they onion name “owner” has approved the request?
>     >
>     > You're right that none of these methods could be completed by someone
>     > with access to the onion proxy alone.  I think the closest analogy would
>     > indeed call for a new onion-specific method, which would probably
>     > involve signing a challenge with the onion key or with a key signed by
>     > the onion key.
>     >
>     Hello,
>     I think that we should start with one basic question, what does DV
>     validation mean? Does it mean that the applicant is the owner of the
>     domain name or does it mean that the applicant is in control of the web
>     server serving the content?
> DV allows for both.

Thank you, this solves the problem that I mentioned.

>     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.

>     However, in the tor
>     case this is different. For example, putting "HiddenServicePort 80
>     www.google.com:80 <http://www.google.com:80>" in my tor config
>     doesn't make me owner of google's
>     servers!
>     Trying to decipher the meaning, I checked appendix F of the EV SSL
>     guidelines where it states:
>     The CA MUST verify the Applicant’s control over the .onion Domain Name
>     using one of the following:
>     a. The CA MAY verify the Applicant’s control over the .onion service by
>     posting a specific value at a well-known URL under RFC5785.
>     b. The CA MAY verify the Applicant’s control over the .onion service by
>     having the Applicant provide a Certificate Request signed using the
>     .onion public key if the Attributes section of the
>     certificationRequestInfo contains:
>     ....
>     I am pretty confident that the former proves the applicant has control
>     over the web server serving the content while b proves that the
>     applicant is the owner of the onion name.
>     I propose that before continuing the discussion on DV issuance for NG
>     onion services (which I fully support), we should decide what DV
>     validation actually means, and also correct the EV SSL guidelines.
> I disagree that this is a necessary condition to solve. The BRs already
> permit both, the validation WG has spent 2+ years discussing it, and
> while we are certainly supportive of methods to improve this process and
> the scoping of authority, it doesn't seem necessary to gate acceptance
> on NG names for this.

I guess that this has already been solved, as you mentioned, so we don't
have to solve it again.

> 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.

>     My best guess is that DV (= Domain Validation) means that the applicant
>     is the owner of the domain name. I also consider this the correct and
>     needed interpretation since TLS provides confidentiality and integrity
>     over a connection between two endpoints. In the tor case, this means
>     that the connection between the user and the proxy is encrypted. The
>     user doesn't have any way of knowing if the connection between the proxy
>     and the web server is encrypted. Thus any information in the subject
>     should be related to the proxy and not to the webserver.
> I'm not sure your point here - the entire point of TLS in this regard is
> to provide a further level of assurance. I also think it's a misnomer to
> suggest that a proxy is involved here - are you discussing local client
> configuration (in which case, some UAs can directly interact with the
> Tor services)? Are you discussing the routing mode to non-HS nodes,
> which may egress any number of exit nodes? As it relates to NG names,
> you do have an assurance binding to the HS. 

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.

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, and 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.


Fotis Loukos, PhD
Director of Security Architecture
SSL Corp
e: fotisl at ssl.com
w: https://www.ssl.com

More information about the Public mailing list