[cabfpub] Lifecycle of EV certs

[Eddy Nigg]

Hi Ryan,

On 03/20/2015 01:22 AM, Ryan Sleevi wrote:
>
> 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.

Sure, but you are not a typical example just because you can afford it 
and have your own issuing CA...in this respect we really have to look at 
the typical subscriber instead.

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

Yes, but does it matter if it's EV or not in this respect? I believe it 
doesn't matter that much...

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

True, but as such also take into account the software that uses it. I 
believe that this goes pretty much in tandem.

> 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.

In the real world this probably wouldn't have worked that well, again 
because of the software side. If we would have decided in 2012 to 
rollover to SHA2 (which nobody was seriously considering to propose), 
than the software wouldn't have been ready.

Most CAs were ready for SHA2 probably for a while, but the server and 
client software was holding it back. Realistically I believe that 3 
years is a pretty good compromise for such changes where CAs and 
software vendors would have to get their house in order.

If software could support a short rollover within one year without 
creating havoc, I would agree with you, but so far it can't and it's not 
feasible.

> 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).

I don't believe you did any real good with that, sincerely! Microsoft's 
approach of a planned, realistic and well-informed move to SHA2 was not 
only much more sensitive to the needs of the various parties (including 
their own customers I assume), it was much less hysteric and in an 
orderly fashion. Except that Google thought otherwise and made a mess 
with it - the results are felt here and not at our place.

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

That's because browser vendors don't want to, not because it's not 
possible. Also this decision is for the net gain of the browser (vendor).

> In an organization, a lot can happen in five years.

Yes, but we are talking about either two or three years (not five) - and 
even this is a long time really. But everything is a compromise 
eventually I guess.

Our policy has been, the weaker the validation, the shorter the validity 
of the certificate. This is the risk assessment we made, whereas EV 
(should) provide the longest period with the least risks as we see it.

-- 
Regards
Signer: 	Eddy Nigg, COO/CTO
	StartCom Ltd. <http://www.startcom.org>
XMPP: 	startcom at startcom.org <xmpp:startcom at startcom.org>
Blog: 	Join the Revolution! <http://blog.startcom.org>
Twitter: 	Follow Me <http://twitter.com/eddy_nigg>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20150320/5c05e62c/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4313 bytes
Desc: S/MIME Cryptographic Signature
Url : https://cabforum.org/pipermail/public/attachments/20150320/5c05e62c/attachment.bin