<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Bonjour,
<div class=""><br class="">
<div apple-content-edited="true" class="">
<div class=""><br class="">
</div>
</div>
<div>
<blockquote type="cite" class="">
<div class="">Le 2 févr. 2016 à 20:02, Peter Bowen <<a href="mailto:pzb@amzn.com" class="">pzb@amzn.com</a>> a écrit :</div>
<br class="Apple-interchange-newline">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
On Feb 2, 2016, at 10:06 AM, Ryan Sleevi <<a href="mailto:sleevi@google.com" class="">sleevi@google.com</a>> wrote:<br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="gmail_extra">
<div class="gmail_quote">On Tue, Feb 2, 2016 at 4:20 AM, Peter Bowen <span dir="ltr" class="">
<<a href="mailto:pzbowen@gmail.com" target="_blank" class="">pzbowen@gmail.com</a>></span> wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br class="">
</span>Do they do this in the presence of a SAN extension or just the absence?<br class="">
</blockquote>
<div class=""><br class="">
</div>
<div class="">Modern browsers: Only when the SAN is bereft of DNS/IP addresses</div>
<div class="">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 class=""> </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 class="">
>> they could stop doing this?<br class="">
><br class="">
> Well, we mandated that SANs should mirror CN quite a while back, so<br class="">
> there may be scope for this soon for publicly-trusted certs. I believe<br class="">
> Ryan had some views here...<br class="">
</span></blockquote>
<div class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">Other software: It will be a decade+ before such applications stop checking CNs.</div>
</div>
</div>
</div>
</div>
</blockquote>
<br class="">
</div>
<div class="">And it is certs like <a href="https://crt.sh/?id=11880495" class="">https://crt.sh/?id=11880495</a> that prove that this is true. That certificate was issued in the last month, has no SAN or EKU, has a FQDN in the CN, and chains back to one or
more roots trusted by every browser (<a href="https://gist.github.com/pzb/c55a802c283c7b44002d" class="">https://gist.github.com/pzb/c55a802c283c7b44002d</a>). <a href="https://www.ssllabs.com/ssltest/analyze.html?d=aflsa.jag.af.mil" class="">https://www.ssllabs.com/ssltest/analyze.html?d=aflsa.jag.af.mil</a> shows
that the certificate is in use at the FQDN in the CN.</div>
<div class=""><br class="">
</div>
<div class="">According to the ssllabs analysis, the chain should fail due to policy constraints, but I’m not sure if anything enforces such constraints.</div>
</div>
</div>
</blockquote>
</div>
<div><br class="">
</div>
<div>Correct.</div>
<div><br class="">
</div>
<div>From top to bottom, the chain is:</div>
<div>
<ul class="">
<li class="">DST ACES CA X6 (trust anchor)</li><li class="">IdenTrust ACES CA 1</li><li class="">Federal Bridge CA 2013</li><li class="">Federal Common Policy CA</li><li class="">SHA-1 Federal Root CA</li><li class="">DoD Interoperability Root CA 1</li><li class="">DoD Root CA 2</li><li class="">DOD CA-28</li><li class="">aflsa.jag.af.mil</li></ul>
</div>
<div><br class="">
</div>
<div>Using RFC5280 wording, valid_policy_tree is equal to NULL at « SHA-1 Federal Root CA », and the chain fails at the « DoD Root CA 2 » certificate, because now explicit_policy is equal to 0 (and valid_policy_tree is NULL).</div>
<div>Strangely, certificate for « DoD Interoperability Root CA 1 » has a PolicyMappings extension, but policy mapping is forbidden since « SHA-1 Federal Root CA ».</div>
<div>Strangely again, the PolicyConstraints extension contained in « DoD Root CA 2 » is not critical. It’s a MUST for RFC5280, and a MAY for X.509 (with a recommendation to set it critical). It’s the extension that requires an explicit policy and makes the
chain fail.</div>
<div><br class="">
</div>
<div>OpenSSL is able to reject such a chain (it doesn’t seem to handle the policy mappings), I’ve been told that MS can correctly reject it, I’m pretty sure that the recent Mozilla PKIX lib accepts it while the previous one rejects it. (And I wouldn’t bet a
cent on GnuTLS to do such things correctly)</div>
<div><br class="">
</div>
<div><br class="">
</div>
<div>Cordialement;</div>
<div>Erwann Abalea</div>
<br class="">
</div>
</body>
</html>