<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 11, 2013 at 2:30 AM, Steve Roylance <span dir="ltr"><<a href="mailto:steve.roylance@globalsign.com" target="_blank" class="cremed">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>Hi Ryan, </div><div><br></div><div>
There's nothing to prevent any sub CA owner from issuing multiple level domains regardless of whether the CA has Constraints or not. The advantage with Constraints is you can't issue a working certfiiacte for domains you don't own (obvious but as this is a public posting I wanted to make sure it was clear). The BR's themselves were specifically reworded to align with Mozilla's policy to remove the need for mandatory external auditing. CA's can still opt to do this but the wording of Ballot 105 was clear in that audits are still required at the same level (3% or more) across the board (Constrained or not) and BR compliance rules are to be flowed down to the Sub CA by the CA. So there's no big change other than the independence of the party that looks at the results. If the CA doesn't care about it's brand/image and knowingly passes bad domain examples then why on earth are they a CA in the first place? As Ryan Hurst highlighted in a reply post to this thread we'll be moving by the end of 2013 to 100% checking of all 'technical' aspects of our Sub CAs and letting the Name Constraints themselves verify the Subject/Vetting aspects.</div>
<div><div><br></div><div>Several times during the discussions on Name Constraints people eluded to weaknesses due to the addition of the Constraints, however, this isn't accurate as those weaknesses (like belong able to issue as a multi level wildcard) are there in all cases. Name Constraints bolsters security in other areas. It doesn't weaken the system. As such I just wanted to make sure Name Constraints doesn't get a bad rap in threads like this. </div>
</div></div></div></blockquote><div><br></div><div>I'm not sure how you saw it being NC getting a bad rap - NC are indeed a much more flexible form of a wildcard cert, and that's a wonderfully good thing compared to the alternatives that exist today - such as relying on contractual controls or technical controls implemented at the CA side, rather than technical controls that can be implemented in the UA side.</div>
<div><br></div><div>I'm not particularly convinced of the value of audits for such constrained certificates. Because their ability to issue is restricted to their constrained names, the most 'damage' they can do is limited to their named scope - which is exactly what the audits are trying to do (limit the damage). </div>
<div><br></div><div>Mozilla's policy only requires that technically-constrained CAs be "operated" consistent with their policy - but there are no audit requirements. As such, I would suggest that there is still skew between what the BRs state and what programs like Mozilla require, but I would leave that for someone from Mozilla to comment. Put differently, I'm not sure what value (security or otherwise) is afforded by having the BRs require auditing technically constrained sub-CAs - that seems to me a brand-identity issue that CAs MAY choose to do, rather than a critical security issue that the CA/B Forum MUST address or that root programs MUST require.</div>
<div> </div><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><br></div><div>
In the <a href="http://paypal.com.domain.net" target="_blank" class="cremed">paypal.com.domain.net</a> example the URL is usually hosted by someone somewhere on some hosting platform and resolved by DNS and rendered by the browser so as with everything there are multiple parties that have some ability to help protect the innocent. One way in the example below where you do refeer o name constraints would be to show the user the Organization details the CA fixed into the name Constrained SubCA and therefore pulled up in the the Subscriber certificate in the Chrome to highlight it wasn't Paypal..but that's a Subject (pun intended) for another day ;-)</div>
<div><br></div></div></div></div></blockquote><div><br></div><div>Which again goes back to the point that it's user agents, not CAs, that are effective in the fight against phishing.</div><div> </div><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></div><div>Steve</div><p></p></div></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" class="cremed">sleevi@google.com</a>><br><span style="font-weight:bold">Date: </span> Tuesday, 10 September 2013 20:57<br>
<span style="font-weight:bold">To: </span> Eddy Nigg <<a href="mailto:eddy_nigg@startcom.org" target="_blank" class="cremed">eddy_nigg@startcom.org</a>><br><span style="font-weight:bold">Cc: </span> "<a href="mailto:public@cabforum.org" target="_blank" class="cremed">public@cabforum.org</a>" <<a href="mailto:public@cabforum.org" target="_blank" class="cremed">public@cabforum.org</a>><div class="im">
<br><span style="font-weight:bold">Subject: </span> Re: [cabfpub] [cabfman] Deceptive SSL cert issued for fake Chase domain<br></div></div><div><div class="h5"><div><br></div><div dir="ltr">Eddy,<div><br></div><div>I'm not sure whether CAs either can really be effective here in mitigating this, at least in the scope of subdomains. I think this is especially true when considering Mozilla's policy to allow technically constrained sub-CAs to issue certificates that are not audited to the BRs.</div>
<div><br></div><div>If I were to obtain a technically constrained sub-CA for <a href="http://mydomain.com" target="_blank" class="cremed">mydomain.com</a>, in which the CA fully vetted that ownership for <a href="http://mydomain.com" target="_blank" class="cremed">mydomain.com</a>, then I would be able to issue certificates for <a href="http://anydomain.com.mydomain.com" target="_blank" class="cremed">anydomain.com.mydomain.com</a>. That is, a technically constrained sub-CA behaves like a multi-level wildcard certificate.</div>
<div><br></div><div>Likewise, given a wildcard certificate for *.<a href="http://mydomain.com" target="_blank" class="cremed">mydomain.com</a>, I could create any degree of spoofables for <a href="http://anydomaincom.mydomain.com" target="_blank" class="cremed">anydomaincom.mydomain.com</a>. I suspect (but I'm not intimately familiar with) the possibility of Punycoding some degree there. I know this has been a point that Brad Hill has raised in the past.</div>
<div><br></div><div>I think when it comes to anti-phishing, this is something that may be better handled by the UAs, at least with respect to subdomains. You can already see this in UAs that highlight things like the "effective TLD+1" in their address bar, scrolling in particular to that location (eg: see Chrome on mobile platforms). That's not to say it's a perfect solution, by far, but it's a much more scalable solution that recognizes where the strengths and weaknesses are - and I think having CAs try to validate subdomains on the eTLD+1 is realistically a weakness that won't be solved effectively.</div>
<div><br></div><div>I think we still need to have the BRs concerned about spoofables at the eTLD+1 level, and still need to be concerned about high-risk requests, but when it comes to subdomains, I don't lose much sleep on this matter, at least when it comes to certificate issuance.</div>
<div><br></div><div>Put differently, I do not think the lock icon can be reasonably be considered an anti-phishing mitigation. It merely is an indication of the connection/encryption to the domain in question.</div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Sep 10, 2013 at 12:39 PM, Eddy Nigg (StartCom Ltd.) <span dir="ltr"><<a href="mailto:eddy_nigg@startcom.org" target="_blank" class="cremed">eddy_nigg@startcom.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div>
<br>
On 09/10/2013 08:13 PM, From Jeremy Rowley:
</div><blockquote type="cite">
<div>
<p class="MsoNormal"><span style="color:#1f497d">I know we’ve
performed similar (non-malicious) experiments with DV certs
to see how easy it would be to phish a banking domain. It’s
pretty easy. I think this is a good launching point to
discuss how we can improve the BRs in a manner that prevents
these types of phishing attacks.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
</div>
</blockquote>
<br><div>
In this respect I have a hot topic I'm supposed to check with the
CAB Forum, this comes convenient....<br>
<br>
From time to time we get requests for certificates that contain
possible domains within the host name, for example:<br>
<br>
<i><a href="http://domain.com.dom.net" target="_blank" class="cremed">domain.com.dom.net</a></i><br>
<br>
Now we have made an effort to disallow this practice as much as
possible recently because it could be easily abused:<br>
<br>
<i><a href="http://paypal.com.dom.net" target="_blank" class="cremed">paypal.com.dom.net</a></i><br>
<br>
Or to make it more obvious:<br>
<br>
<i><a href="https://www.paypal.com.some.net/us/cgi-bin/webscr?cmd=_flow&SESSION=KKIncv649JDbg" target="_blank" class="cremed">https://www.paypal.com.some.net/us/cgi-bin/webscr?cmd=_flow&SESSION=KKIncv649JDbg</a></i><br>
<br>
As it happens, some CAs issue such potentially confusing
certificates and we ourselves get every while requests for them. In
particular also from companies that provide or want proxy services
and in order to mask the names as much as possible it looks
something like this (this is from a real request):<br>
<br>
*.<a href="http://sharepoint.com.some.com" target="_blank" class="cremed">sharepoint.com.some.com</a> *.<a href="http://microsoftonline.com.some.com" target="_blank" class="cremed">microsoftonline.com.some.com</a><br>
*.<a href="http://outlook.com.shamir.adallom.com" target="_blank" class="cremed">outlook.com.shamir.adallom.com</a> *.<a href="http://office365.com.some.com" target="_blank" class="cremed">office365.com.some.com</a><br>
<br>
Which again could easily confuse a relying party which might or
might not know about the MITM going on. <br>
<br>
I would like to know what the stance of the membership here is on
this topic, in particular software vendors. And if there is room to
clarify this via regulation by the BR. Otherwise there is probably
no point in punishing our clients when others or they can get it
easily elsewhere.<br>
<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" class="cremed">StartCom Ltd.</a></td>
</tr>
<tr>
<td>XMPP: </td>
<td><a class="cremed">startcom@startcom.org</a></td>
</tr>
<tr>
<td>Blog: </td>
<td><a href="http://blog.startcom.org" target="_blank" class="cremed">Join the Revolution!</a></td>
</tr>
<tr>
<td>Twitter: </td>
<td><a href="http://twitter.com/eddy_nigg" target="_blank" class="cremed">Follow Me</a></td>
</tr>
<tr>
<td colspan="2"> </td>
</tr>
</tbody>
</table>
</div>
<br>
<br>
</div></div><br>_______________________________________________<br>
Public mailing list<br><a href="mailto:Public@cabforum.org" target="_blank" class="cremed">Public@cabforum.org</a><br><a href="https://cabforum.org/mailman/listinfo/public" target="_blank" class="cremed">https://cabforum.org/mailman/listinfo/public</a><br>
<br></blockquote></div><br></div>
_______________________________________________
Public mailing list
<a href="mailto:Public@cabforum.org" target="_blank" class="cremed">Public@cabforum.org</a>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank" class="cremed">https://cabforum.org/mailman/listinfo/public</a>
</div></div></span></div>
</blockquote></div><br></div></div>