[cabfpub] Pre-Ballot - Short-Life Certificates

Gervase Markham gerv at mozilla.org
Fri Oct 31 21:59:52 UTC 2014

On 31/10/14 21:55, Eddy Nigg wrote:
> On 10/31/2014 07:09 PM, Jeremy Rowley wrote:
>> 7) Short-lived certs provide a limited hard-fail since the expiration message for expired certs is more visible than the message received where revocation information is unavailable
> I don't agree with this entirely - a working revocation BLOCKS a visitor
> to the site usually,

Except that if you have enough control of the target's internet
connection to MITM them, you can also block the revocation check. So
revocation of this sort only really works when you're not being attacked.

> In my opinion browser would have to implement a similar logic as with
> revocations when a short-lived certificate is expired in order to be
> effective. And I highly doubt that neither CAs nor browser wish to do that.

There is certainly the option of treating expired short-lived certs
differently in new browsers, and I suggested that we might do that in
the discussion in Beijing. But that would be icing on the cake.

>> 8) Browsers don't need to add the certs to their CRLSets or do a call to the CA to retrieve revocation information.
> With the above logic, this isn't necessarily true if a key of such
> certificates gets compromised. Such a key could be potentially used for
> hundreds of certificates, depending on what the guidelines will be for
> reuse of such keys.

Would you prefer it if the guidelines said that each successive
short-lived cert had to use a different key? I think that might be a
reasonable change.


More information about the Public mailing list