<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 18, 2015 at 8:13 AM, Gervase Markham <span dir="ltr"><<a href="mailto:gerv@mozilla.org" target="_blank">gerv@mozilla.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi everyone,<br>
<br>
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1148766" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1148766</a> is Mozilla's<br>
investigation of certs using IP addresses in SANs.<br>
<br>
Our engineer says that as long as you do the proper SANs first and the<br>
ones with IP addresses encoded as DNS names last, then it should work<br>
everywhere, presumably as Firefox will find the good ones (which match)<br>
and accept them, and software which doesn't understand them will skip<br>
over them and use the broken ones.<br>
<br>
Please let us know if your testing says something different.<br>
<br>
Gerv<br></blockquote><div><br></div><div>Gerv,</div><div><br></div><div>Are you suggesting/endorsing that CAs violate the Baseline Requirements, which requires RFC 5280 conformance, by improperly encoding IP addresses into the dNSName field?</div><div><br></div><div>Section 4.2.1.6 of RFC 5280 has this to say:</div><div><br></div><font face="monospace, monospace">   When the subjectAltName extension contains a domain name system<br>   label, the domain name MUST be stored in the dNSName (an IA5String).<br>   The name MUST be in the "preferred name syntax", as specified by<br>   Section 3.5 of [RFC1034] and as modified by Section 2.1 of<br>   [RFC1123].</font></div><div class="gmail_quote"><font face="monospace, monospace"><br></font></div>That statement doesn't leave any room for encoding an IPv4 address - and especially not an IPv6 address - within that field. Any CA that does do that, while understandably targeted at compatibility reasons, is failing to adhere to the Baseline Requirements. For those who haven't read RFC1034, it establishes the LDH syntax and notion of labels. A label must begin with a letter according to 1034 rules. 1123 relaxed this to allow labels to begin with a letter or digit, but this introduction of ambiguity (is it a label or an IP octet) was only permitted because of the presumption of IANA TLD policies (since reflected by ICANN's TLD policies) that no TLD will begin with a digit. This comes from Section 2.1. of RFC 1123,</div><div class="gmail_extra"><br></div><div class="gmail_extra"><pre class="newpage" style="font-size:13.3333330154419px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)">   However, a valid host name can never
   have the dotted-decimal form #.#.#.#, since at least the
   highest-level component label will be alphabetic.</pre><pre class="newpage" style="font-size:13.3333330154419px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)"><br></pre>The argument seemingly provided on the bug is for compatibility with Microsoft products prior to Windows 10 - which lack support for iPAddress subjectAltNames, but which accept IP addresses in both the common name and in the dNSName subjectAltNames because they treat the name to match as a (mostly) opaque string. However, the compatibility issue does not necessitate violating the Baseline Requirements or RFC 5280, as a CA could fully adhere to the BRs by expressing an iPAddress SAN with the IP in the common name. The absence of a dNSName SAN (and the lack of support for iPAddress SAN) will result in the CN being treated as a "domain", and then matching with the opaque string.</div><div class="gmail_extra"><br></div><div class="gmail_extra">It does mean that you _cannot_ mix and match hostnames and IP addresses in publicly trusted certificates, due to the compatibility issues, but I thought it was well understood by CAs as a necessary tradeoff in order to conform to the relevant technical standards and audit criteria.</div><div class="gmail_extra"><br></div><div class="gmail_extra">While Mozilla's handling of such improperly formed certificates for non-publicly trusted certificates is arguably entirely reasonable (given how awful many such internal systems are at producing RFC-conforming certificates), for publicly trusted CAs, non-conformance is a serious issue.</div></div>