[cabfpub] Pre-Ballot - Short-Life Certificates

[Gervase Markham]

On 23/10/14 18:26, kirk_hall at trendmicro.com wrote:
> (1) Even though the short lived cert (with no revocation checking
> pointers) expires in 73 hours, if a CA actually revoked a 73 hour
> cert within 1 hour of issuance and included revocation checking
> pointers (especially OCSP), a lot of clients (not 100%, but
> potentially a lot) would get the revocation information during the
> remaining 72 hours.  But no client will have any chance to get a
> revocation warning with a short lived cert that lacks checking
> pointers.  Is this an issue?

We talked this through at the face-to-face. Any revocation system has a
built-in delay of some sort. This one has the same delay for everyone;
others have variable delays for different clients, depending on when
they check revocation information. For this one, the revocation
information always "gets through" on the deadline because there is no
need for an additional request; for others, a pre-cached OCSP response
could be stapled even after revocation by an active attacker.

So the two risk profiles are not the same, but there seemed to be rough
consensus at the meeting that they are similar enough that allowing this
is not a weakening of security.

> (2) I worry that a customer that chooses to move to short lived certs
> and arranges for auto-downloads and auto-installation of new certs
> every three days could create a vulnerability in its systems.  I
> suppose that's for the customer to worry about, but should we have a
> concern?

Indeed, I think that's for the customer to worry about. I don't
anticipate Joe's Bait Shop adopting this system. In fact, we aren't
entirely sure whether or if there is anyone for which the different
trade-offs made with short-lived certs makes sense. That's one reason we
want to allow people to try them out. If no-one ends up using them,
that's not a problem.

Gerv