<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 19, 2015 at 4:00 PM, Eddy Nigg <span dir="ltr"><<a href="mailto:eddy_nigg@startcom.org" target="_blank">eddy_nigg@startcom.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<br>
<div>On 03/20/2015 12:50 AM, Ryan Sleevi
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Indeed, I'd argue that the current EV lifetime is
one of the few things where EV <b>is</b> a security improvement
over DV/OV and thus potentially deserving of it's special UI
status. <br>
</div>
</blockquote>
<br></span>
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?<br>
<br>
(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.)</div></blockquote><div><br></div><div>Sure. It's no surprise that we're strong supporters of limited lifetime certs on the sites we operate. For example, looking at <a href="https://www.google.com">https://www.google.com</a> shows a cert expiring in 3 months.</div><div><br></div><div>Keeping the validity period as tight as reasonably possible provides several benefits:</div><div><br></div><div>* In the event of a key compromise or misissuance, reduces the opportunity the attacker has to use this cert.</div><div><br></div><div>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.</div><div><br></div><div>* The validity period is the lower-bound for the industry to make progressive changes that are technically enforcable.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>* We can reasonably assume revocation "Doesn't Work", as presently implemented (by all major UAs).</div><div><br></div><div>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.</div><div><br></div><div>* It encourages better security practices and can reduce training and support overhead.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>This is not guaranteed, certainly, but it is also a good practice, as with any other security practice, and thus deserves encouraging.</div><div><br></div><div><br></div></div></div></div>