[cabfpub] Pre-Ballot - Short-Life Certificates

[Gervase Markham]

On 24/10/14 14:42, Rich Smith wrote:
> You're argument hinges upon either the browser having already cached a
> Good OCSP response, OR an active attacker serving up a stapled Good OCSP
> response, and in those cases, yes, short lived w/out revocation info is
> equal to longer lived cert with revocation info. BUT in a case where
> neither of those (cached response or active attacker) is true, at least
> as far as Comodo systems are concerned, we will serve a Revoked OCSP
> response as soon as we revoke a certificate.  If there is no cached
> response already stored by the browser and there is not an active
> attacker who has already obtained and is serving a Good OCSP response,
> anyone encountering that cert WILL see that it is revoked, so it is NOT
> equal in such a case.  

Indeed not. And in the case where the theft is not discovered for a
week, the OCSP-using cert has a worse security story than the
short-lived cert.

It's certainly possible to construct scenarios where one is superior to
the other. My assertion is that the risk profile is broadly comparable.

> In a case of simple fraudulent activity by a site
> owner, 

I'm not quite sure what you mean by that; how is a site owner committing
fraud a cert-related issue? People are always telling me that certs are
about identity, not reputation.

But I still don't understand your position. You are saying "why don't
the browsers all just agree to treat short-life certs differently?" OK,
let's say we did. Now every browser doesn't check revocation for
short-life certs. If this is OK by you, why are you not OK with us
achieving the same end more quickly by removing the revocation pointers?

Gerv