[cabfpub] DV issuance for next-generation onion services

[Ryan Sleevi]

On Sun, Nov 5, 2017 at 9:53 AM, Fotis Loukos via Public <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.


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


> However, in the tor
> case this is different. For example, putting "HiddenServicePort 80
> 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.

Could you explain why you believe NG names are materially different, in
this respect, then what is permitted under the BRs?


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