[cabfpub] Certificate lifetimes: end state or trajectory?

[Phillip Hallam-Baker]

> From: Gervase Markham [mailto:gerv at mozilla.org]
 
> Hi Philip,
> 
> On 03/03/17 16:14, Phillip Hallam-Baker wrote:
> > Going from 2 years to 1 or even 90 days makes no significant
> > difference to security in my view. The only way to make a significant
> > difference is to take the vulnerability window down to 3 days or less
> > by requiring effective revocation.
> 
> You keep making this point, but it assumes incorrectly that the reason for
> reducing certificate lifetimes is to reduce the "vulnerability window". That's
> simply not the case. No-one is arguing "we should reduce certificate lifetimes
> because then we don't have to bother with revocation at all".

I accept that the reasons motivating the proposal are different.

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.

If people will promise to say that the only benefit to the proposal is to give the industry more time to procrastinate over changes, I will be happy to stop bringing up revocation.

Since the proponents keep coming back with arguments that are a consequence of the lack of hard fail OCSP or demanding stapling, I will keep addressing the technical benefits.


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

Requiring sites to adopt any other technology that is not already widely supported in the next 24 or even 48 months is a very much bigger ask.


> I would be more open to listening to your thoughts on revocation if found
> you could clearly articulate all the reasons for Mozilla's position regarding
> why we think OCSP hard-fail for every cert is not possible (even if you didn't
> agree with it). Then you could tell me how whatever plans you have address
> all those issues. But regardless, let's do that in another thread, because this
> one is not about revocation.

We are aware of those objections and as you say this is not the place to discuss them right now.

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.


> > CAs and Browser providers naturally have different views on the last
> > as site administrators are our customers. So a proposal that requires
> > hundreds of thousands of site admins to spend hours or days
> > implementing a change is a major issue for CAs.
> 
> This is another of those "if this is true, something is very wrong"
> moments. If it takes hours or days to replace a cert, something is very wrong.
> Moving from 2 years to 1 year makes it happen twice as often. If it's taking
> that long, this customer needs automation whether certs are
> 2 years or 1 year in duration.

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.

The problem that I don't think you appreciate is that turning on automation is not automatic. Certainly not in an environment where high levels of reliability are demanded. Running random Perl scripts off the net is not the way a lot of places operate and those that do are likely to create problems.