[cabfpub] Defining BR scope

[Jeremy Rowley]

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] 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/06b899f8/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160202/06b899f8/attachment-0001.p7s>