[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

Ryan Sleevi sleevi at google.com
Thu Aug 22 09:13:29 MST 2019


On Thu, Aug 22, 2019 at 12:01 PM Christian Heutger <ch at psw.net> wrote:

> > Unfortunately, the current practices these Enterprises practice makes
> the ecosystem less secure and less robust. All organizations MUST be
> prepared to replace certificates in a timely fashion, to
>
> > ensure that users can be protected when, e.g. certificates need to be
> replaced because the issuing CA violated one or more Root Program
> requirements, when the method used to validate the
>
> > authorization for the certificate is determined to be insecure, the CA
> is distrusted, etc.
>
>
>
> That’s exactly, what I meant: If(!) there are such issues arising. An
> emergency change is something different and for sure could and should be
> handled, there should be methods and it should be optimized, that such
> issues won’t arise, but for “just in case” it’s no good idea to enforce a
> not well accepted solution as automation and it’s also not the idea of
> measurements on risks.
>

Unfortunately, this is a bit like arguing it's best not to apply security
patches until you're exploited. I understand that we'll not see eye-to-eye
here, and that's OK. I'm concerned about ensuring our users, and the
Internet at large, is sufficiently secure and robust when CAs mess up,
which they do on a regular basis, and to minimize the impact to any
organization: both those using that CA, and which may need to respond
accordingly, and those that may not be using it, but nevertheless placed at
risk by such CAs.

This is a much needed, preventative measure. It's unconscionable to suggest
that it's inappropriate to take measures that are known to secure users are
sites, and instead wait for the compromises, which happen on a regular
basis.


> > As a concrete example, consider what would happen if the CA used by
> these organizations were distrusted, such as due to routine failure to
> implement the required validation process, or failure
>
> > to oversee their Registration Authorities or their Subordinate CAs. Such
> a CA poses a risk to every secure site on the Internet, and every user, in
> that the CA's failure to exercise the required
>
> > controls can and will likely result in a misissued certificate.
> Attempting to accommodate such organizations, by delaying the distrust of
> such a CA, simply transfers the risk and harm onto all other
>
> > users. This is unacceptable, and we do not plan to support such use
> cases going forward.
>
>
>
> Again my question from before, what is the job of WebTrust and ETSI
> audits? Do all of them fail? What are they worth, if reading your
> statemtents look like that all CA always violate BR? If they do, continued,
> always and permanent, WebTrust and ETSI auditors need to be fired, as they
> seem not to do their job and you need to shut down KPMG, PWC, EY and all
> other auditing organisations, as they lie, misuse, get paid for reports and
> don’t do their job? It’s a bit confusing, if you claim mishandling on one
> hand and auditors certify such companies on the other? Looks a bit strange,
> isn’t it? I know, that RA should also perform WebTrust RA audits, therefor
> RA audit requirements exist, to ensure, that such issues as in the past
> with RA don’t arise anymore?
>

You are correct. Browsers do not trust audits to detect or prevent these
issues. Audits are not a preventative measure, they are defense in depth.
There have been multiple auditing firms that have been distrusted from
providing audit reports to browsers, and there have been years of efforts
to improve these issues. However, audits are merely a component of a
holistic security story. Relying on audits alone is not, nor has it ever
been, a sensible security practice.

I think your frustration may be a misunderstanding of audits and the goals
and value they provide, which is understandable.


> > This is not a hypothetical risk. It has happened to several CAs. Even
> on a less significant level than complete and total distrust, a number of
> the leading members of the Forum have had to require
>
> > some subset of customers replace their certificates, due to these CAs'
> misissuances and control failures within the past year. There are,
> admittedly, organizations, even very large and important
>
> > organizations, that are not and were not adequately prepared for this. I
> do not dispute this. However, as we've seen from the past decade of
> discussion here in the Forum, and especially in the
>
> > past five years, attempting to accommodate these organizations harms the
> overall security of the Internet. Reducing lifetimes helps balance that
> risk and harm caused by attempting to
>
> > accommodate these organizations.
>
>
>
> Again, then require such CA (or all CA) to use services which monitor such
> misissuances and require the CA to correct them in a timely manner.
>

As noted, "correction" involves both addressing existing certificates that
exist out there and having CAs ensure no new certificates with the issue
are issued. Addressing existing certificates is /only/ reliably addressable
on the Internet via expiration. No other technology has been shown to be
consistency reliable for a wide-variety of users, on a wide variety of
networks. I would be shocked if the organizations opposed to this would
find it acceptable if all of their user data may be accessible or exposed
for 27 months, and yet that is the current risk. Similarly, I would be
shocked if organizations opposed found it acceptable that an attacker who
compromised their system for a few minutes would be able to persist the
attack, and attack all traffic, for 4.5 years. Yet that is the world today.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190822/dd0870a5/attachment.html>


More information about the Servercert-wg mailing list