[cabfpub] Certificate lifetimes: end state or trajectory?

[Phillip Hallam-Baker]

From: Gervase Markham [mailto:gerv at mozilla.org]
 
> On 03/03/17 17:25, Phillip Hallam-Baker wrote:
> > But when we get into discussions, the security reason for doing it is
> > so that 'bad certs' are valid for shorter times. Whether you like it
> > or not, that is a validity argument by definition.
> 
> But it's not a problem that can be solved by revocation. Well, technically you
> could solve the problem that e.g. "we've issued 2 million 39-month certs
> using an algorithm we now known to be broken" by revoking them all, but in
> practice the level of disruption is too great.
> However, making the max validity period 13 months means that people will
> be planning to rotate their certs on a yearly basis anyway.

And it isn't a problem that can be solved by shortening the certificate lifetime either.

We are dealing with a complex infrastructure in which it currently takes about ten years to deploy a new algorithm.

It is not just a matter of updating the browsers or the Web sites. HTTP is used in a vast number of IoT devices that are currently fire and forget. Many have no update capabilities at all. Others can be upgraded with no controls on the upgrade process. It is a mess and not one that is going to be solved by CABForum fiat.

Certificate lifetime is currently much shorter than its place on the critical path for algorithm deployment demands. 

> > We have been promoting stapling for quite a few years now and we are
> > quite likely at a point where we could say 'you must turn on
> > stapling'.
> 
> My understanding is that both Apache and nginx are not at a stage where
> stapling "just works". And that's not for want of trying; we've paid for work
> on Apache to try and make this better.

So based on that experience, how long before we could require automated certificate management?


> > But the fact remains that if you the Browser providers are not willing
> > to require sites turn on stapling or suffer a performance penalty
> > because you think it is infeasible then the same objection holds for
> > demands the same sites go to automated issue to support shorter
> > lifetimes.
> 
> You are right that we aren't willing to slow down 85%+ of the Internet for our
> users (and block 1-3% of it) in order to drive a behavioural change among
> sites, yes.

That is understood. We have to apply technical means to reduce the penalty. 


> > There are many, many sites where the very least change requires
> > considerable process. And the reason for that is that without that
> > process you end up in situations like the one that caused both my
> > doorbells to fail for 4 hours this week after a cloud service provider
> > had an outage.
> 
> I'm so tempted to say that this is yet another "if this is true, something is very
> wrong" moment ;-).

Just the one thing very wrong?