[cabfpub] Defining BR scope

[Ryan Sleevi]

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
CNs.


> >
> >> 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>