<div dir="ltr">Responding with permission of the author on the public list. Response below<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 16, 2015 at 12:27 AM, Ben Wilson <span dir="ltr">&lt;<a href="mailto:ben.wilson@digicert.com" target="_blank">ben.wilson@digicert.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal">AJ ONeal writes:<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">This section excludes the ability to grant a certificate to localhost.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">It makes sense that you don&#39;t want `whatever.local` and `foo.home` to have<u></u><u></u></p><p class="MsoNormal">certificates, because any computer can claim those names on any network and<u></u><u></u></p><p class="MsoNormal">the winner wins.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">However, localhost is consistently globally unique to the requesting<u></u><u></u></p><p class="MsoNormal">computer, so it is not vulnerable to any kind of attack.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">We want more developers to develop with https and as such, there should be<u></u><u></u></p><p class="MsoNormal">some sort of public, shareable, localhost certificate that any developer<u></u><u></u></p><p class="MsoNormal">can use to start experimenting with HTTPS and experience the differences in<u></u><u></u></p><p class="MsoNormal">browser security policy, etc, that are enforced when using it.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">We want them to be able to do so without big red scary browser warnings<u></u><u></u></p><p class="MsoNormal">that make them feel that https is something complicated that they want to<u></u><u></u></p><p class="MsoNormal">avoid.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Also, I don&#39;t know if a <a href="http://localhost.example.com" target="_blank">localhost.example.com</a> would fall into this category<u></u><u></u></p><p class="MsoNormal">or not, but we definitely need a way for localhost apps and home server<u></u><u></u></p><p class="MsoNormal">apps to communicate with each other and with web apps in the new wave of<u></u><u></u></p><p class="MsoNormal">peer-web development.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">See also:<u></u><u></u></p><p class="MsoNormal"><a href="http://stackoverflow.com/questions/6793174/third-party-signed-ssl-certificate-for-localhost-127-0-0-1" target="_blank">http://stackoverflow.com/questions/6793174/third-party-signed-ssl-certificate-for-localhost-127-0-0-1</a><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">AJ ONeal<u></u><u></u></p></div></div><br></blockquote></div><br></div><div class="gmail_extra">So, the assumption that &quot;localhost&quot; is globally unique is wrong, and demonstrably wrong on modern platforms.</div><div class="gmail_extra"><br></div><div class="gmail_extra">RFC 6761, Section 6.3 ( <a href="https://tools.ietf.org/html/rfc6761#section-6.3">https://tools.ietf.org/html/rfc6761#section-6.3</a> ) spells out the expectations for &quot;localhost.&quot; (as a special-use domain name and as a special-use TLD)</div><div class="gmail_extra"><br></div><div class="gmail_extra">Within this section, there is only one MUST-level requirement (i.e. has to be implemented and is not optional), which is that DNS registries and registrars not allow attempts to register &quot;localhost&quot;</div><div class="gmail_extra"><br></div><div class="gmail_extra">In particular, pay attention to bullet 3 - &quot;Name resolution APIs&quot; (what modern browsers would use) are not required (MUST, SHALL) to address locally. Instead, they merely SHOULD return the loopback and SHOULD NOT send to the network.</div><div class="gmail_extra"><br></div><div class="gmail_extra">In empirical testing, we&#39;ve seen multiple resolvers (notably, OS X&#39;s) send localhost queries to the network, either as part of DNS suffix searches (localhost.my.suffix.search.example), as a single-label entry (&quot;\09localhost\0&quot; in DNS terms), or as part of multicast DNS.</div><div class="gmail_extra"><br></div><div class="gmail_extra">As a result, accessing &quot;<a href="https://localhost">https://localhost</a>&quot;, say, on a hostile WiFi access point (such as your coffee shops) can be intercepted by a network attacker and redirected to a site (or a certificate) of their choosing.</div><div class="gmail_extra"><br></div><div class="gmail_extra">On the browser side, we&#39;ve (Chrome) been extremely supportive of the CA/B Forum&#39;s efforts to deprecate internal names, and excluding &quot;localhost&quot; from being exceptional is, from our POV, &quot;working as intended&quot;. Such a certificate will, in time, be outright rejected (as part of the sunset of these certificates).</div><div class="gmail_extra"><br></div><div class="gmail_extra">As to your follow-up, which is the rationale for why a localhost certificate is needed in the first place, I&#39;d suggest following up with the browsers. This has been discussed in the W3C&#39;s WebAppSec WG both as part of the &quot;Secure Contexts&quot; work ( <a href="https://w3c.github.io/webappsec/specs/powerfulfeatures/#is-origin-trustworthy">https://w3c.github.io/webappsec/specs/powerfulfeatures/#is-origin-trustworthy</a> ) and in the context of &quot;Mixed Content&quot; work ( <a href="https://w3c.github.io/webappsec/specs/mixedcontent/#should-block-fetch">https://w3c.github.io/webappsec/specs/mixedcontent/#should-block-fetch</a> ).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Alternatively, if there are specific issues with browsers, then you&#39;d likely find this being discussed on Mozilla&#39;s mozilla.dev.platform newsgroup/mailing list ( <a href="https://groups.google.com/forum/#!forum/mozilla.dev.platform">https://groups.google.com/forum/#!forum/mozilla.dev.platform</a> ) or on Chromium&#39;s security-dev mailing list ( <a href="https://groups.google.com/a/chromium.org/forum/#!forum/security-dev">https://groups.google.com/a/chromium.org/forum/#!forum/security-dev</a> ). Both of these places are appropriate for discussions about whether or not HTTPS is required to use powerful new web platform features (e.g. for Chromium, for localhost, it nearly universally isn&#39;t required, and if there are features that still require it for localhost / loopback addrs, they&#39;re bugs to be filed) and whether or not, say, <a href="https://foo.example">https://foo.example</a> should be prevented from opening ws://localhost (e.g. for Chromium, for a publicly routable domain such as foo.example talking to a local daemon such as localhost, HTTPS is presently required, and that&#39;s working as intended; in the future, such communication may be blocked and require a separate opt-in from localhost to allow foo.example to talk to it)</div><div class="gmail_extra"><br></div><div class="gmail_extra">Hopefully in the reply above I&#39;ve properly addressed what seems to be the root of your issue, and, if not, given suggestions on where follow-ups might be useful and why, from a publicly trusted CA side, issuing a cert to &quot;localhost&quot; is dangerous and with real risk.</div></div>