<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 21, 2016 at 6:30 AM, Jody Cloutier <span dir="ltr"><<a href="mailto:jodycl@microsoft.com" target="_blank">jodycl@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>

<div style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif">
<p>As a Forum member, Google is certainly within its purview to vote no, then. Let's put it to a vote and see where it comes down.
<br></p></div></div></blockquote><div><br></div><div>It is truly unfortunate to see you encouraging a vote on a practice with known and quantifiable interoperability and security risks.</div><div><br></div><div>Interoperability risks: This violates RFC5280. This penalizes implementations that properly implement RFC5280 - such as Mozilla Firefox, which enforces that a dNSName properly conforms to the RFCs (with a limited exception for certain characters for legacy reasons, despite being forbidden by the BRs). </div><div><br></div><div>Security risks: Such addressing defeats the "Technically Constrained Sub-CA" provision of the BRs, allowing an issuing CA to bypass iPAddress nameConstraints for clients which do not enforce that the reference identifier (RFC 6125 terminology) is a domain. This is the majority of TLS clients out there, whose only protections are the explicit prohibitions of this behaviour in the Baseline Requirements.</div><div><br></div><div>While I can appreciate the need and desire to support downlevel Windows clients, I offered a clear and concrete solution that avoids these risks entirely, while meeting that need. To suggest there is no interest in addressing these, or that such risks are unimportant - which is what a ballot would effectively be, based on the information presently provided - would be a step back for the Forum, and an unfortunate statement for the endorsers.</div></div><br></div></div>