[cabfpub] Defining BR scope

Ryan Sleevi sleevi at google.com
Tue Feb 2 18:06:56 UTC 2016

On Tue, Feb 2, 2016 at 4:20 AM, Peter Bowen <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

> >
> >> I'm wondering if we could define the scope of the BRs to consider not
> >> just the EKU extension, but also the SAN extension.  (I forget if this
> >> has been proposed previously - apologies if it has).
> >
> > This does run into the "protecting people with down-level revisions of
> > software" problem.
> What about keyUsage?  Are browsers checking that?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160202/79cd997b/attachment-0003.html>

More information about the Public mailing list