[cabfpub] Pre-Ballot - Short-Life Certificates

Ryan Sleevi sleevi at google.com
Wed Oct 29 18:39:54 UTC 2014

On Oct 29, 2014 11:10 AM, "Doug Beattie" <doug.beattie at globalsign.com>
> Gerv,
> I was under the (apparently false) impression that if certificates did
not have AIA information then browsers would display a warning or error
message to the user.  You answered Kirk with a statement "no browser I know
of today, in its default configuration, will refuse to accept a cert for
the reason that it contains no revocation pointers ".  If this is generally
believed to be true, then I withdraw my recommendation around tagging these
certificates with unique identifiers.
> I just find it hard to swallow that all browsers accept SSL certificates
without an AIA/CDP as valid.  I acknowledge that they are non-compliant
with the BRs and the CA will get a beating.  It just seems irresponsible to
accept certs like this as completely valid.  But, apparently (some)
browsers don’t use the AIA to check the status of certificates when present
either.  Somebody is using AIA because we provide terabytes of data every
month to support revocation checking.

We (Chrome) have several bugs open to explore UI indicators for non-BR
compliance. However, we are careful and reticent to foist UI on end users
unless it is something actionable for the user or the site operator (SHA-1
is an example of a real concern for site operators that requires attention
and planning).

The further compounding factor is the high number of false positives caused
by practices like CA backdating, or the fact that very few CAs proactively
made efforts for security by taking actions regarding the BRs by the
effective dates, instead opting to wait until required by the root
programs. Indeed, there are still a significant number of CAs (the
majority, at last check) who are not BR compliant. Several CAs have gone on
record indicating to root programs that, barring the root program taking
action, they do not intend to be BR compliant until 2016 or later.

In this kind of world, we are judicious in our application of UI. And given
that, to date, Chrome has been the most aggressive in surfacing security
issues via UI, that should say something.

On this specific point of AIA and CDPs, however, it's far simpler. If the
client application itself does not directly rely on these fields, it makes
no sense to warn on their absence. This is the same as UAs that don't warn
about inconguencies in the subject field for certs that have validated the
organization - if it doesn't affect the security posture, then its a matter
between the browser and the CA, not between the browser and the user.

To be clear though, yes, we monitor for these, and yes, BR noncompliance is
something we take VERY seriously. We just don't use our users as the canary
to detect that noncompliance.

> Are we SURE that removing AIA won't adversely impact site operators'
customers, whoever they are?
> Doug
> > -----Original Message-----
> > From: Gervase Markham [mailto:gerv at mozilla.org]
> > Sent: Wednesday, October 29, 2014 11:52 AM
> > To: Doug Beattie; 'Tim Hollebeek'; public at cabforum.org
> > Subject: Re: [cabfpub] Pre-Ballot - Short-Life Certificates
> >
> > On 27/10/14 20:08, Doug Beattie wrote:
> > > If we're going to create a new type of certificate which is exempt
> > > from revocation checking we need to tag them as special - a new
> > > extension or something so that they can be processed differently.
> >
> > Why? Legacy browsers will continue to treat them exactly the same
> > or not you mandate a new marker, and newer browsers which decide to
> > adopt special treatment will do so based on their maximum lifetime, not
> > any other criteria.
> >
> > Gerv
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20141029/247491cf/attachment-0003.html>

More information about the Public mailing list