<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 21, 2016 at 7:30 AM, Ryan Sleevi <span dir="ltr"><<a href="mailto:sleevi@google.com">sleevi@google.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I'm afraid you've misunderstood my concern. An implementation on the client that enforces RFC5280 here will rightfully reject such certificates, as the labels to not conform to the LDH rule - that is, a domain name constructed entirely of numbers is an invalid hostname, the dNSName field should only contain valid hostnames, and such are rejected.</div></div></div></div></blockquote><div><br></div><div>As a clear and concrete example:</div><div><a href="http://mxr.mozilla.org/mozilla-central/source/security/pkix/lib/pkixnames.cpp#1880">http://mxr.mozilla.org/mozilla-central/source/security/pkix/lib/pkixnames.cpp#1880</a></div><div><a href="http://mxr.mozilla.org/mozilla-central/source/security/pkix/lib/pkixnames.cpp#2017">http://mxr.mozilla.org/mozilla-central/source/security/pkix/lib/pkixnames.cpp#2017</a></div><div><br></div><div>While Chrome is planning to do the same, it highlights how 'blessing' such certificates enables further fragmentation of the WebPKI, by encouraging more "exceptions" to RFC5280. With nameConstraints being non-critical, there were no identified compatibility risks, and thus was not seen as an issue. Here, I've given a clear example of a compatibility risk. And while we can argue that Mozilla could update their code, why should Mozilla bear the burden rather than Microsoft, for the problem of Microsoft's creation?</div></div><br></div></div>