<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 6, 2015 at 3:37 PM, Anoosh Saboori <span dir="ltr"><<a href="mailto:ansaboor@microsoft.com" target="_blank">ansaboor@microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Reviving this older thread. It seems that both:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><span>1.<span style="font:7.0pt "Times New Roman"">      
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Forum has concerns around relying only on whois database or email address since the whois database might not be accurate
<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><span>2.<span style="font:7.0pt "Times New Roman"">      
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">MS still has concerns for #6 not being at par with the rest of validation mechanism proposed
<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:.25in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">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. “<u></u><u></u></span></p>
<p class="MsoNormal"><br></p></div></div></blockquote><div><br></div><div>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. </div><div><br></div><div>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?</div><div><br></div><div>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, <a href="http://foo.com">foo.com</a> and <a href="http://bar.com">bar.com</a> 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 <a href="http://bar.com">bar.com</a> MAY be able to apply for a certificate for <a href="http://foo.com">foo.com</a>.</div><div><br></div><div>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?)</div></div></div></div>