[cabfpub] Pre-Ballot - Short-Life Certificates

Gervase Markham gerv at mozilla.org
Fri Oct 24 06:52:04 MST 2014


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


More information about the Public mailing list