<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 5, 2017 at 9:53 AM, Fotis Loukos via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 03/11/2017 07:08 μμ, Seth David Schoen via Public wrote:<br>
> Peter Bowen writes:<br>
><br>
>> 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?<br>
><br>
> You're right that none of these methods could be completed by someone<br>
> with access to the onion proxy alone.  I think the closest analogy would<br>
> indeed call for a new onion-specific method, which would probably<br>
> involve signing a challenge with the onion key or with a key signed by<br>
> the onion key.<br>
><br>
<br>
</span>Hello,<br>
<br>
I think that we should start with one basic question, what does DV<br>
validation mean? Does it mean that the applicant is the owner of the<br>
domain name or does it mean that the applicant is in control of the web<br>
server serving the content?<br></blockquote><div><br></div><div>DV allows for both.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In the classic WebPKI case, this is the same thing. </blockquote><div><br></div><div>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"</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">However, in the tor<br>
case this is different. For example, putting "HiddenServicePort 80<br>
<a href="http://www.google.com:80" rel="noreferrer" target="_blank">www.google.com:80</a>" in my tor config doesn't make me owner of google's<br>
servers!<br>
<br>
Trying to decipher the meaning, I checked appendix F of the EV SSL<br>
guidelines where it states:<br>
<br>
The CA MUST verify the Applicant’s control over the .onion Domain Name<br>
using one of the following:<br>
a. The CA MAY verify the Applicant’s control over the .onion service by<br>
posting a specific value at a well-known URL under RFC5785.<br>
b. The CA MAY verify the Applicant’s control over the .onion service by<br>
having the Applicant provide a Certificate Request signed using the<br>
.onion public key if the Attributes section of the<br>
certificationRequestInfo contains:<br>
....<br>
<br>
I am pretty confident that the former proves the applicant has control<br>
over the web server serving the content while b proves that the<br>
applicant is the owner of the onion name.<br>
<br>
I propose that before continuing the discussion on DV issuance for NG<br>
onion services (which I fully support), we should decide what DV<br>
validation actually means, and also correct the EV SSL guidelines.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Could you explain why you believe NG names are materially different, in this respect, then what is permitted under the BRs?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My best guess is that DV (= Domain Validation) means that the applicant<br>
is the owner of the domain name. I also consider this the correct and<br>
needed interpretation since TLS provides confidentiality and integrity<br>
over a connection between two endpoints. In the tor case, this means<br>
that the connection between the user and the proxy is encrypted. The<br>
user doesn't have any way of knowing if the connection between the proxy<br>
and the web server is encrypted. Thus any information in the subject<br>
should be related to the proxy and not to the webserver.</blockquote><div><br></div><div>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. </div></div><br></div></div>