[cabfpub] Domain validation

[Anoosh Saboori]

Hi Ryan,


What you stated below partly is the main reason for us not supporting #6 . Another example is Azure tenant who is assigned "example.clouapp.net". While the tenant can pass the test in #6  by inserting nonce in "example.cloudapp.net/.well-known/certificate", they are not the real owner for that domain name, Azure is.

I also agree with your statement in regards to IP addresses.

Anoosh



________________________________
From: Ryan Sleevi <sleevi at google.com>
Sent: Wednesday, May 6, 2015 3:49 PM
To: Anoosh Saboori
Cc: Eddy Nigg; public at cabforum.org
Subject: Re: [cabfpub] Domain validation



On Wed, May 6, 2015 at 3:37 PM, Anoosh Saboori <ansaboor at microsoft.com<mailto:ansaboor at microsoft.com>> wrote:
Reviving this older thread. It seems that both:


1.       Forum has concerns around relying only on whois database or email address since the whois database might not be accurate

2.       MS still has concerns for #6 not being at par with the rest of validation mechanism proposed

So, can we get to a point where both concerns are addressed by modifying the requirement as: "#6 continues to be accepted, only if other validation methods failed to work. CAs then keep documentation on why they decided to accept #6. "


I'm still not sure why Microsoft doesn't feel that #6 is not on-par with the rest. It would be very helpful if you could elaborate what properties you feel that the other methods offer that #6 does not. In digging through your past replies, it only seems that you've highlighted it's "not as strong" - but you haven't clarified what property is absent.

If I understand by reading between the lines, your concern is that method #6 allows verification to happen by any attacker who can gain filesystem-level access, whereas the other methods require some level of password compromise (e.g. email, methods 1/2/4 from the original message), remote code execution (e.g. TLS bindings, method 11 from the original message), or has compromised the domain management (methods 7/8 from the original message). Is that correct?

I'm surprised that Microsoft hasn't highlighted Item 9 (IP address validation) as similarly weaker in guarantees. For example, in a shared hosting service, foo.com<http://foo.com> and bar.com<http://bar.com> may both be hosted on the same IP, and use SNI (for HTTPS) and the Host: header (for HTTP) to disambiguate which host the client wishes to talk to. As presently worded, it seems like bar.com<http://bar.com> MAY be able to apply for a certificate for foo.com<http://foo.com>.

Now, I know that's not the intent, but that strikes me as an area that needs further clarification about what "controls an IP address" means (e.g. does it mean looking in the appropriate RIR for that Netblock and confirming the applicant through a Reliable Means of Communication?)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20150506/e925e60c/attachment-0001.html