[cabfpub] Lifecycle of EV certs

Ryan Sleevi sleevi at google.com
Thu Mar 19 23:22:13 UTC 2015

On Thu, Mar 19, 2015 at 4:00 PM, Eddy Nigg <eddy_nigg at startcom.org> wrote:

> On 03/20/2015 12:50 AM, Ryan Sleevi wrote:
> Indeed, I'd argue that the current EV lifetime is one of the few things
> where EV *is* a security improvement over DV/OV and thus potentially
> deserving of it's special UI status.
> Can you explain what the security risks would be as you perceive it, if
> the lifetime would be increased to three years in particular for EV?
> (Btw. I find the 27 and 39 month rather stupid, nothing prevents from
> re-validating and issuing a certificate after 24/36 month. It's just adding
> another 3 month to something that can done exactly the same after two/three
> full years.)

Sure. It's no surprise that we're strong supporters of limited lifetime
certs on the sites we operate. For example, looking at
https://www.google.com shows a cert expiring in 3 months.

Keeping the validity period as tight as reasonably possible provides
several benefits:

* In the event of a key compromise or misissuance, reduces the opportunity
the attacker has to use this cert.

I realize 3 months is a long time, and some may argue is no different than
3 years, but I think it's a reasonable disagreement. Certainly, the
short-lived certs (e.g. 10 days or, on the more aggressive side, Mozilla's
3 day proposal) helps reduce this risk even further.

* The validity period is the lower-bound for the industry to make
progressive changes that are technically enforcable.

For example, if (in a hypothetical world), cert validity periods were
capped at 12 months, then the discussion of SHA-1 in 2012 could have been
that as of 2015-01-01, no new certs should be issued. This would have
allowed for a 2016-01-01 rollover.

As the world stands, because pre-BR saw some CAs issuing 10 year certs, and
the present BRs allow up to 5 years, there are still a number of
certificates held by customers that are SHA-1 signed and expire well beyond
the 'flag day' of 2017-01-01. When that day comes, and software vendors
move to disable SHA-1 signatures, a number of sites will find themselves no
longer working.

This is why we've been proactive in Chrome in messaging this to users and
site operators, to reduce the amount of friction and pain felt in
2017-01-01 (to which I realize some CAs may feel that we reduced the
2017-01-01 pain by spreading it out from now until then).

This same logic applies to every other change the CA/B Forum makes
regarding security; anything under the old scheme remains valid, and it's
not until (effective date - 1) + (maximum validity period) that a user
agent can implement strong technical controls.

* We can reasonably assume revocation "Doesn't Work", as presently
implemented (by all major UAs).

A short expiration time builds in technical controls for the steps CAs must
take (e.g. revalidating information), rather than requiring CAs to
implement more complex controls, such as those Jeremy mentioned.

* It encourages better security practices and can reduce training and
support overhead.

While I realize this may seem counter-intuitive to some CAs, it's well
known that actions that are practiced regularly become skills. Under the
current BRs, the number of times in which an administrator of a server must
touch or examine their server configuration can be up to five years.

In an organization, a lot can happen in five years. The person responsible
can change. The documentation can become lost. The keys and necessary
knowledge can disappear. It's also one of the only times a server operator
will re-evaluate their overall SSL/TLS security posture - disabling weak
algorithms, weak ciphersuites, upgrading products and libraries, etc.

We've long been supporters of site operators proactively choosing shorter
validity certificates, and working in processes and controls where they
regularly update their servers and re-evaluate for the current security
best practices, which can change on a regular basis. BEAST, Lucky13, RC4,
and FREAK all demonstrate the need to actively stay on top of things, and a
habit of annual rotation of certificates can help set an upper-bound on how
long insecure practices live on.

This is not guaranteed, certainly, but it is also a good practice, as with
any other security practice, and thus deserves encouraging.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150319/b406d087/attachment-0003.html>

More information about the Public mailing list