[cabfpub] Domain validation

[Tim Hollebeek]

In the #10 use case Gerv was discussing, the certificates are self-signed, so the TLS-ness doesn’t provide much value, so it doesn’t matter where the TLS terminates.  If we’re going to allow that, I think we should make it explicit what we’re allowing (self-signed or untrusted certificates), and also enforce the .well_known requirement for the same reasons why we did it for #6.

However, on the validation working group call, another use case was discussed, where validation *does* matter, however the validation is against a non-publicly trusted root (basically, the web site installs a test cert to prove they control the certs for the domain).  It’s an interesting use case that I think should be allowed, though I think it should be a separate enumerated method because the security model is different.

I think #10 needs to be tightened up and clarified significantly.  I’m sure this will be discussed extensively on the validation WG call in two weeks.

-Tim

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Thursday, May 07, 2015 12:07 PM
To: Tim Hollebeek
Cc: CABFPub; Anoosh Saboori
Subject: RE: [cabfpub] Domain validation


On May 7, 2015 6:47 AM, "Tim Hollebeek" <THollebeek at trustwave.com<mailto:THollebeek at trustwave.com>> wrote:
>
> I’ll note that if you object to #6 on those grounds, you also object to #10, which is basically “do #6 via TLS, with fewer requirements around where the value must be placed.”
>
>
>
> In fact I’m starting to think that #10 should be eliminated and rolled into #6, simply by noting in #6 that for the purposes of #6, TLS with an untrusted server certificate can be used in place of HTTP.
>
>
>
> -Tim
>

No Tim, they aren't equivalent under the threat model / equivalency that Anoosh agreed as (part of) the concern.

In both the Azure and the AppEngine case, the hosting provider terminates TLS, and thus the tenant cannot influence it.

This isn't universal for all hosting scenarios (e.g. Google Compute Engine, AWS), but it does represent a material difference to the threat model that we should not consider them equivalent.

________________________________

This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150507/01cf49e4/attachment-0003.html>