<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt"><div style="color:rgb(34,34,34);font-family:arial,helvetica,sans-serif;font-size:13px;background-color:rgb(255,255,255)">Steve, members,</div><div style="color:rgb(34,34,34);font-family:arial,helvetica,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
<br></div><div style="color:rgb(34,34,34);font-family:arial,helvetica,sans-serif;font-size:13px;background-color:rgb(255,255,255)">Let me first say categorically that Google does not support this motion and will vote No. As discussed previously, we believe there are several flaws in the reasoning for this motion, and do not believe this meaningfully improves security on the Internet.</div>
<div class="im" style="color:rgb(80,0,80);font-family:arial,helvetica,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><div style="color:rgb(34,34,34)"><br></div><span style="color:rgb(34,34,34)">* On the matter of forbidding internal names or IPs in the CN, but permitting them in SANs.</span><div style="color:rgb(34,34,34)">
<br></div></div><div style="color:rgb(34,34,34);font-family:arial,helvetica,sans-serif;font-size:13px;background-color:rgb(255,255,255)">The entire purpose of permitting the CN to contain duplicated information from the SAN is to support legacy clients that only support or examine the CN for information about the assured server identity. Forbidding it in the CN, but not in the SAN, in our view does absolutely nothing to improve the quality of validated information within the certificate. As all member browsers in this Forum are examining the SAN for the assured server identity, and thus ignoring the CN, this only serves to actively break these legacy clients, for reasons that remain unclear. While we support measures to outright forbid internal names and internal IPs (for the many reasons shared previously), we don't think this proposal is consistent with the security concerns involved, nor do we think it's reasonable to arbitrarily break such legacy clients.</div>
<div class="im" style="color:rgb(80,0,80);font-family:arial,helvetica,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><div style="color:rgb(34,34,34)"><br></div><div style="color:rgb(34,34,34)">* On the matter of requiring OV validation for distinct domain names within a cert</div>
<div style="color:rgb(34,34,34)"><br></div></div><div style="color:rgb(34,34,34);font-family:arial,helvetica,sans-serif;font-size:13px;background-color:rgb(255,255,255)">We believe DV certs have played and will continue to play a vital part in improving web security, and thus oppose measures that seek to deprecate or prevent their usage. DV certs allow a domain holder, with minimal cost and effort, to establish a secure presence on the Internet, protecting their visitors from passive eavesdropping, fingerprinting, and, to some degree, from a variety of active attacks. As we have promoted in numerous forums, the wider deployment of TLS is something we strongly support, and we think DV offers a reasonable and compelling solution to permit opportunistic encryption with a domain.</div>
<div style="color:rgb(34,34,34);font-family:arial,helvetica,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></div><div style="color:rgb(34,34,34);font-family:arial,helvetica,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
As has been repeatedly explained to members advocating for this, the security properties of one certificate with ten names vs ten certificates with one name, are in the real world indistinguishable. This is because we view DV certificates as a means of asserting domain authorization - and not, as some member CAs may view - as a way of establishing identity or trustworthiness. Because the technical value of one certificate with ten names is still significantly greater than ten certificates with one name, preventing them seems both misguided and hostile towards DV, and thus also hostile to actually improving and encouraging the deployment of TLS on the web.</div>
<div style="color:rgb(34,34,34);font-family:arial,helvetica,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></div><div style="color:rgb(34,34,34);font-family:arial,helvetica,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
It is regrettable that a number of TLS clients still do not support SNI, but that ship has sailed and that deployment is our reality. Making SNI a requirement, or making it more difficult and complicated to obtain certificates that are functionally equivalent to SNI, is something that is only going to hinder TLS deployment, which is why we do not support this measure.</div>
<div class="im" style="color:rgb(80,0,80);font-family:arial,helvetica,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><div style="color:rgb(34,34,34)"><br></div><div style="color:rgb(34,34,34)">* On the matter of requiring OV for internal names</div>
<div style="color:rgb(34,34,34)"><br></div></div><div style="color:rgb(34,34,34);font-family:arial,helvetica,sans-serif;font-size:13px;background-color:rgb(255,255,255)">It should come as no surprise that, as a browser and as a member deeply concerned about security on the web, we strongly dislike the issuance of internal names in publicly trusted certificates, in all forms. We do not believe that a publicly trusted CA can or should be asserting ownership of a particular internal name - which is why we support their deprecation in October 2016, and would welcome it much sooner if member CAs felt it was possible.</div>
<div class="im" style="color:rgb(80,0,80);font-family:arial,helvetica,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><div style="color:rgb(34,34,34)"><br></div><div style="color:rgb(34,34,34)">The proposal to require OV for these names is alluring at first, if only because it makes it more difficult to obtain these names, ergo it will further discourage CAs from issuing them and subscribers from obtaining them. However, coupled with the proposal has been the suggestion that somehow OV addresses the security concerns of internal names, which is a position which we actively disagree with and we think may be harmful to the future deprecation of such names.</div>
<div style="color:rgb(34,34,34)"><br></div></div><div style="color:rgb(34,34,34);font-family:arial,helvetica,sans-serif;font-size:13px;background-color:rgb(255,255,255)">Thus, while we support this effort, it should be clear our motivations, and that we'd not support measures to further encourage, permit, or undeprecate internal names, regardless of any additional validation checks that may be proposed in the future.</div>
<br><div class="gmail_quote">On Fri, Nov 16, 2012 at 12:35 AM, Steve Roylance <span dir="ltr"><<a href="mailto:steve.roylance@globalsign.com" target="_blank">steve.roylance@globalsign.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:12px;font-family:Arial,sans-serif;word-wrap:break-word"><div><div><div>Morning Ryan,</div><div><div><div><p></p><font style><font><p style="font-size:14px;font-family:Arial,sans-serif"></p></font></font></div>
</div></div></div></div><div>So what you are saying below, is that because there are a few clients out there that can only support CN (CN = mail or CN =192.168.2.1 for example) then it's acceptable (until Nov 2015) for CAs to offer single dimensional 'intranet' certificates with no other verified content? (This is what Rich was first eluding to in his initial post)</div>
<div><br></div><div>Does this not mean an attacker could very easily build up a portfolio of attack certs with various internal names and IPs and pretty much zero traceability?</div><div><br></div><div>Or are you saying (unlike Rich) that other details should be added? That's what we are saying with ballot 92. We are simply saying that to deter hackers we need to know the details of the entity to add to the Subject O field and not that they simply have control/access to an FQDN which also may be untraceable when it comes to investigation/crunch time.</div>
<div><br></div><div>See lines 14/15/16 and 34/35/36 on my spreadsheet with the examples I created to illustrate the situations we wish to prevent.</div><div><br></div><div>I hope it's clear that this is both from a security perspective and as Jeremy already answered last night, relying party understanding perspective.</div>
<div><br></div><div>Have a great weekend and no doubt speak to you on Monday's call ;-)</div><div><br></div><div>Steve</div><div> </div><div><br></div><div><br></div><span><div style="border-right:medium none;padding-right:0in;padding-left:0in;padding-top:3pt;text-align:left;font-size:11pt;border-bottom:medium none;font-family:Calibri;border-top:#b5c4df 1pt solid;padding-bottom:0in;border-left:medium none">
<span style="font-weight:bold">From: </span> Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>><br><span style="font-weight:bold">Date: </span> Thursday, 15 November 2012 22:26<br>
<span style="font-weight:bold">To: </span> Eddy Nigg <<a href="mailto:eddy_nigg@startcom.org" target="_blank">eddy_nigg@startcom.org</a>><br><span style="font-weight:bold">Cc: </span> <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><br>
<span style="font-weight:bold">Subject: </span> Re: [cabfpub] Ballot 92 - Subject Alternative Names<br></div><div><div class="h5"><div><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt">On Thu, Nov 15, 2012 at 2:10 PM, Eddy Nigg (StartCom Ltd.) <span dir="ltr"><<a href="mailto:eddy_nigg@startcom.org" target="_blank">eddy_nigg@startcom.org</a>></span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<br>
On 11/15/2012 11:52 PM, From Rich Smith:
<div><blockquote type="cite">
<div>
<p class="MsoNormal"><span style="font-size:11pt;color:rgb(31,73,125);font-family:Calibri,sans-serif">Since
many clients and servers will still choke on a cert with no
Common Name.</span></p>
</div>
</blockquote>
<br></div>
Rich, can you please give me real examples of commonly used browsers
and servers that wouldn't work? Much appreciated.<br>
<br>
<div>
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
<td colspan="2">Regards </td>
</tr>
<tr>
<td colspan="2"> </td>
</tr>
<tr>
<td>Signer: </td>
<td>Eddy Nigg, COO/CTO</td>
</tr>
<tr>
<td> </td>
<td><a href="http://www.startcom.org" target="_blank">StartCom Ltd.</a></td>
</tr>
<tr>
<td>XMPP: </td>
<td><a>startcom@startcom.org</a></td>
</tr>
<tr>
<td>Blog: </td>
<td><a href="http://blog.startcom.org" target="_blank">Join the Revolution!</a></td>
</tr>
<tr>
<td>Twitter: </td>
<td><a href="http://twitter.com/eddy_nigg" target="_blank">Follow Me</a></td>
</tr>
<tr>
<td colspan="2"> </td>
</tr>
</tbody>
</table>
</div>
<br>
</div><br>_______________________________________________<br>
Public mailing list<br><a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br><a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
<br></blockquote></div><br><div>I don't know if the volume is many, but I have seen a variety of vendor-proprietary implementations that behave as Rich describes.</div><div><br></div><div>However, I don't think think the volume of affected clients matter - the whole point of permitting entries in the CN (in addition to the SAN) is to support such clients.</div>
<div><br></div><div>For any <b>new</b> client, which supports SAN, what benefits does this provide / security threats does this address?</div><div> - I would suggest none, since any SAN-supporting client will ignore the CN</div>
<div><br></div><div>For any <b>old</b> client, which does not support SAN, what benefits does this provide / security threats does this address?</div><div> - Given that internal IPs / hostnames are still permissible in the SAN, I would suggest none.</div>
<div><br></div><div><br></div><div>I'm certainly sympathetic to the argument "The UI [might be] ambiguous", but I think that's a different problem, and arguably address[ed/able] today by requiring the value of the CN match one of the values of the SANs, so it remains unclear to me.</div>
</div></div></div>
_______________________________________________
Public mailing list
<a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a></span></div>
</blockquote></div><br></div>