[cabfpub] Pre-Ballot - Short-Life Certificates

[kirk_hall at trendmicro.com]

Ryan, thanks for the information, and I respect your analysis.  But many of us would say that revocation (and the ability to check for revocation) is a fundamental aspect of whether a cert is valid at all.

Other elements of BR noncompliance are important, but none is as important as when a CA says “Don’t rely on this cert, it has been revoked.”  Without CDP and AIA data in a cert, there is no way that any application can check to see if the cert is still valid and should be relied on (the cert may or may not be listed in any CRL).  That’s a fundamental flaw in a trust system involving third party trust anchors, trusted root stores, etc. and in my opinion goes way beyond general BR compliance issues, which version of the BRs applies, etc.  It’s kind of launching a missile with no way to destroy it mid-flight for error or new information (like the war is over) – you had better be sure everything was correct at launch, as there is no way to recall it.

I agree that browsers and apps will make their own judgments about when a case of BR non-compliance is serious enough to warrant a UI warning, and when it can be ignored.  I would just offer my opinion that lack of CDP and AIA data in a cert (whether or not Chrome wants to check that information in the client) is a fundamental certificate flaw that renders the cert inherently untrustworthy, and it should automatically be rejected by applications (just as expired certs, etc. are now automatically rejected).  But that’s just my opinion.

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi
Sent: Wednesday, October 29, 2014 11:40 AM
To: Doug Beattie
Cc: public at cabforum.org
Subject: Re: [cabfpub] Pre-Ballot - Short-Life Certificates


On Oct 29, 2014 11:10 AM, "Doug Beattie" <doug.beattie at globalsign.com<mailto:doug.beattie at globalsign.com>> wrote:
>
> 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<mailto:gerv at mozilla.org>]
> > Sent: Wednesday, October 29, 2014 11:52 AM
> > To: Doug Beattie; 'Tim Hollebeek'; public at cabforum.org<mailto: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 whether
> > 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 on
> > any other criteria.
> >
> > Gerv
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org<mailto:Public at cabforum.org>
> https://cabforum.org/mailman/listinfo/public
>

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20141029/e4c90c4f/attachment-0003.html>