<br><br><div class="gmail_quote">On Wed, Nov 9, 2011 at 5:36 PM, Daniel Kahn Gillmor <span dir="ltr"><<a href="mailto:dkg@fifthhorseman.net">dkg@fifthhorseman.net</a>></span> wrote:</div><div class="gmail_quote"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> I don't actually see any problem with .local domains using SSL. The real<br>
> problem comes from browsers telling end users that this means a site is<br>
> 'safe'. So one approach would be to tell browser providers that when SSL is<br>
> used at .local sites that the user should never see a padlock icon or any<br>
> other security indicator in primary chrome.<br>
<br>
</div>Sorry, but I don't think you can have this both ways.  I think you get<br>
two choices:<br>
<br>
 0) You can think cryptographic authentication is important on the LAN;<br>
in this case you have to acknowledge that signing a .local certificate<br>
by a global certificate authority really doesn't make any sense without<br>
somehow forcing it to be scoped to a specific LAN.  i'm not convinced<br>
that such a link-layer-scoping mechanism has ever been proposed for<br>
X.509, much less implemented.  It's certainly not present in the<br>
certificates gathered by the observatory project.<br>
<br>
or<br>
<br>
 1) you think that cryptographic authentication is *not* important for<br>
the LAN.  In this case, there's no reason for *anyone* to create .local<br>
certificates, let alone for a global certificate authority to do so.<br>
<br>
It would be nice if someone from a responsible Certificate Authority<br>
(even one that has made mistakes in the past) would stand up and say<br>
"this doesn't make sense; good CAs won't do things this way".  It's a<br>
little disheartening to hear consistent pushback that claims that things<br>
are not as bad as we fear, that we just need to "trust" more in a system<br>
that already appears to be failing in many ways, or that practices which<br>
are pretty clearly a bad idea are actually somehow reasonable.<br></blockquote><div><br></div><div>I think you misunderstand my point here. I am arguing that if we want </div><div>to make changes that stick here we have to do more than just tell</div>
<div>people 'no soup for you'.</div></div><div><br></div><div><br></div><div>I think that it is pretty clear that there is a need for SSL in .local. </div><div>It is also clear that having public CAs issuing unrestricted public certs </div>
<div>is not an ideal solution.</div><div><br></div><div>.local names have always been prohibited for EV because of the </div><div>issues raised.</div><div><br></div><div><br></div><div>What should be done with DV depends on what your view is of </div>
<div>the security DV can provide. I don't think it provides much security at</div><div>all because there is no demonstration of accountability. Anyone</div><div>can get a domain name. My preference would be no more padlock </div>
<div>icons at all.</div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br><br>