<p dir="ltr"><br>
On Oct 29, 2014 11:10 AM, "Doug Beattie" <<a href="mailto:doug.beattie@globalsign.com">doug.beattie@globalsign.com</a>> wrote:<br>
><br>
> Gerv,<br>
><br>
> 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.<br>
><br>
> 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.<br>
></p>
<p dir="ltr">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).</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">> Are we SURE that removing AIA won't adversely impact site operators' customers, whoever they are?<br>
><br>
> Doug<br>
><br>
> > -----Original Message-----<br>
> > From: Gervase Markham [mailto:<a href="mailto:gerv@mozilla.org">gerv@mozilla.org</a>]<br>
> > Sent: Wednesday, October 29, 2014 11:52 AM<br>
> > To: Doug Beattie; 'Tim Hollebeek'; <a href="mailto:public@cabforum.org">public@cabforum.org</a><br>
> > Subject: Re: [cabfpub] Pre-Ballot - Short-Life Certificates<br>
> ><br>
> > On 27/10/14 20:08, Doug Beattie wrote:<br>
> > > If we're going to create a new type of certificate which is exempt<br>
> > > from revocation checking we need to tag them as special - a new<br>
> > > extension or something so that they can be processed differently.<br>
> ><br>
> > Why? Legacy browsers will continue to treat them exactly the same whether<br>
> > or not you mandate a new marker, and newer browsers which decide to<br>
> > adopt special treatment will do so based on their maximum lifetime, not on<br>
> > any other criteria.<br>
> ><br>
> > Gerv<br>
><br>
> _______________________________________________<br>
> Public mailing list<br>
> <a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
> <a href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a><br>
><br>
</p>