<html><head></head><body style="color: rgb(0, 0, 0); font-size: 12px; font-family: Arial, sans-serif; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><div>Morning Ryan,</div><div><div><div><p></p><font class="Apple-style-span" style="color: rgb(0, 0, 0); "><font class="Apple-style-span"><p style="font-family: Arial, sans-serif; color: rgb(0, 0, 0); font-size: 14px; "></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 id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> Ryan Sleevi <<a href="mailto:sleevi@google.com">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">eddy_nigg@startcom.org</a>><br><span style="font-weight:bold">Cc: </span> <<a href="mailto:public@cabforum.org">public@cabforum.org</a>><br><span style="font-weight:bold">Subject: </span> Re: [cabfpub] Ballot 92 - Subject Alternative Names<br></div><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 class="im"><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">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>
_______________________________________________
Public mailing list
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><a href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a></span></body></html>