<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 2, 2016 at 4:20 AM, Peter Bowen <span dir="ltr"><<a href="mailto:pzbowen@gmail.com" target="_blank">pzbowen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
</span>Do they do this in the presence of a SAN extension or just the absence?<br></blockquote><div><br></div><div>Modern browsers: Only when the SAN is bereft of DNS/IP addresses</div><div>Most every other software library: In addition to, and generally as the first match. I have seen code (and filed bugs) against implementations in PHP, Python, Ruby, and C that all opted to check CN, and if CN didn't match, check SAN. I've pointed them to RFC 6125 and explained the risks.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
>> If so, are we anywhere near the point where<br>
>> they could stop doing this?<br>
><br>
> Well, we mandated that SANs should mirror CN quite a while back, so<br>
> there may be scope for this soon for publicly-trusted certs. I believe<br>
> Ryan had some views here...<br></span></blockquote><div><br></div><div>Modern browsers: If they're willing to break the certs issued by some CAs that had 5-10 year validities right before the BRs came into effect, it should be reasonably accomplishable. However, this can *only* be accomplished if browsers recognize the distinction between "Chains to a BR compliant CA" and "Chains to a non-BR compliant CA" (e.g. enterprise CA). The former category should be mostly safe for CNs, save for the long-lived zombie certs. The latter category is dominated by CNs w/o SANs.</div><div><br></div><div>Other software: It will be a decade+ before such applications stop checking CNs.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
><br>
>> I'm wondering if we could define the scope of the BRs to consider not<br>
>> just the EKU extension, but also the SAN extension.  (I forget if this<br>
>> has been proposed previously - apologies if it has).<br>
><br>
> This does run into the "protecting people with down-level revisions of<br>
> software" problem.<br>
<br>
</span>What about keyUsage?  Are browsers checking that?<br></blockquote><div><br></div><div>keyUsage versus extendedKeyUsage? No, many CAs and software stacks have so thoroughly botched this that the field is salted for keyUsage being meaningful in the near-term. </div></div></div></div>