[cabfpub] Certificate lifetimes: end state or trajectory?

[Gervase Markham]

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.

Revocation works for misissuance. It doesn't work for "this practice
everyone was doing wasn't optimal/algorithm everyone used was bad, and
we'd like to stop relying on certs which used it as quickly as we can".

>>> Right now we have a situation where certain people are loudly 
>>> asserting that we can't do effective revocation because it
>>> requires X and simultaneously asserting that we must make other
>>> measures that are less effective but also require X.
>> 
>> What is X in your example?
> 
> Change in site administration infrastructure.
> 
> 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.

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

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

Gerv