[cabfpub] Defining BR scope

[Peter Bowen]

It is under the US Federal PKI which is cross-signed/subordinated by IdenTrust ACES/Public Sector.  See https://bugzilla.mozilla.org/show_bug.cgi?id=1037590#c21 <https://bugzilla.mozilla.org/show_bug.cgi?id=1037590#c21>
> On Feb 2, 2016, at 11:07 AM, Jeremy Rowley <jeremy.rowley at digicert.com> wrote:
> 
> Who’s root is that one off of? That’s a terrible cert. Such a completely misissued cert should probably be discussed at the Mozilla forum since it impacts their root store program, right? 
>   <>
> From: public-bounces at cabforum.org <mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org <mailto:public-bounces at cabforum.org>] On Behalf Of Peter Bowen
> Sent: Tuesday, February 2, 2016 12:02 PM
> To: Ryan Sleevi
> Cc: CABFPub
> Subject: Re: [cabfpub] Defining BR scope
>  
> On Feb 2, 2016, at 10:06 AM, Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com>> wrote:
> On Tue, Feb 2, 2016 at 4:20 AM, Peter Bowen <pzbowen at gmail.com <mailto:pzbowen at gmail.com>> wrote:
> 
> Do they do this in the presence of a SAN extension or just the absence?
>  
> Modern browsers: Only when the SAN is bereft of DNS/IP addresses
> 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.
>  
> >> If so, are we anywhere near the point where
> >> they could stop doing this?
> >
> > Well, we mandated that SANs should mirror CN quite a while back, so
> > there may be scope for this soon for publicly-trusted certs. I believe
> > Ryan had some views here...
>  
> 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.
>  
> Other software: It will be a decade+ before such applications stop checking CNs.
>  
> And it is certs like https://crt.sh/?id=11880495 <https://crt.sh/?id=11880495> 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 (https://gist.github.com/pzb/c55a802c283c7b44002d <https://gist.github.com/pzb/c55a802c283c7b44002d>).  https://www.ssllabs.com/ssltest/analyze.html?d=aflsa.jag.af.mil <https://www.ssllabs.com/ssltest/analyze.html?d=aflsa.jag.af.mil> shows that the certificate is in use at the FQDN in the CN.
>  
> According to the ssllabs analysis, the chain should fail due to policy constraints, but I’m not sure if anything enforces such constraints.
>  
> Thanks,
> Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160202/aad683c3/attachment-0003.html>