<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 26, 2016 at 3:32 PM, Peter Bowen <span dir="ltr"><<a href="mailto:pzb@amzn.com">pzb@amzn.com</a>></span> wrote:<br><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">Why would anyone ever need to emulate Microsoft’s behavior? </blockquote><div><br></div><div>Because people will inevitably see something as accepted and see it as recommended? The same way most of the WebPKI has historically, and unfortunately, happened?</div><div> </div><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"> My proposal assumes that there are two classes of clients:<br>
<br>
1) Clients that follow the RFC and look at iPAddress type GeneralNames in the SAN (for example Mozilla)<br>
<br>
2) Clients that don’t follow the RFC ignore ipAddress type GeneralNames (for example Windows 8)<br>
<br>
For clients in category #1, they process certificates according to the RFCs.  That is they check the URL, determine if the host is a domain or an IP address.  If it is an IP address they don’t do any matching on dNSName type GeneralNames but only look at iPAddress type GeneralNames.  Name constraints on IPs work as per the specification.  On the other hand, if it is a domain, match on dNSName.  This is all per spec. They only thing that these clients have to do is not completely reject a certificate containing an all-numeric hostname.  They can keep these names around or throw them away, but either way they will not be matches.<br></blockquote><div><br></div><div>Which is to say, clients can't enforce compliance with RFC5280, nor does an implementation that expects certificates from publicly trusted CAs to comply with RFC5280 work with such certificates.</div><div> </div><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">
For clients in category #2, if they are to implement name constraints, they do have to do what you suggest and parse things to apply constraints.  However I’m not suggesting that anyone new go down this path and apparently they already implement the constraint processing you describe.<br><div></div></blockquote><div><br></div><div><div>Are you suggesting that Windows earlier than 10 applies nameConstraints from iPAddresses against dNSNames and commonNames? That's not what I've seen. Certainly, the application against commonNames isn't specified in RFC5280 (for dNSNames or iPAddresses), even if it's something a number of implementations have begun to do.</div></div><div><br></div><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> Is there a third category of clients that does something different?</div></blockquote><div> </div><div><div>Yes, there's those in category #3 - which don't look at if the host portion of the URL is a domain or an IP address, and simply treat is as an opaque string, examining against either the dNSName or the iPAddress. Given the significant complexities of the URL spec with relation to determining if the host is one or the other (e.g. <a href="http://12345/">http://12345/</a> is a valid URL in many implementations - but is perhaps not what you'd expect), it's much easier to enforce compliance that dNSNames are DNS, iPAddresses are IPs, and then just do a string-match on either when evaluating against the host, assuming it will fit into the right slot.</div><div><br></div><div>So your description of how clients process iPAddress in GeneralNames is not correct. Whether you consider that a subset/correction for #1 (since they do respect iPAddress) is perhaps qubbling</div></div></div></div></div>