[cabfpub] Pre-Ballot - Short-Life Certificates

[Wayne Thayer]

I agree with many of these benefits. I agree that technically short-lived certs are equivalent to current forms of revocation. I agree that the Forum should act to enable them. But I don't like the approach that's been proposed.

Currently, CAs are responsible for publishing revocation information and browsers are responsible for deciding what to do with it (sometimes making decisions that many CAs don't like, but I digress). I feel that this is the correct approach and one that completely compatible with short-lived certs.

If the Forum defines what a short lived cert is (max validity), then browsers can implement the logic to consciously ignore revocation information. Modern browsers with auto-update mechanisms can deploy this change rapidly. Clients that prefer not to support short-lived certs can also choose to continue to check revocation info. The proposed approach is a hack based on the fact that browsers can't reliably fail when presented with certs that don't contain any revocation info.

Wayne

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley
Sent: Friday, October 31, 2014 10:09 AM
To: public at cabforum.org
Subject: Re: [cabfpub] Pre-Ballot - Short-Life Certificates

I think this discussion could benefit from some of the reasons that people want short-lived certificates.  These were previously discussed on the Mozilla mailing list, but not everyone follows what is going on there.

Here are some of the advantages:
1) Subscribers in areas prone to unrest and where their server might be taken over can let the certificate expire, essentially letting the certificate fail to renew.
2) Subscribers can eliminate size from the certificate
3) Subscribers can avoid call-backs to the CA
4) Subscribers can control how long revocation information takes to propagate (up to 3 days, but could be less)
5) This is a change that doesn't require action by the browsers, meaning it's a CA-drive improvement
6) The change isn't required for any CA. All it does is permit CAs interested in offering the services to customers to do so.
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
8) Browsers don't need to add the certs to their CRLSets or do a call to the CA to retrieve revocation information.
9) Short-lived certs provide shorter revocation windows than currently offered under the BRs.

There are 9 advantages that I could readily find. I'm sure many more exist.  Of course, short-lived certs aren't for every customer and will be deployed only by a small percent of the internet population.  However, for those interested in using them, there are key advantages in deployment. 

Jeremy




-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Gervase Markham
Sent: Thursday, October 30, 2014 7:29 AM
To: kirk_hall at trendmicro.com; Ryan Sleevi; Doug Beattie
Cc: public at cabforum.org
Subject: Re: [cabfpub] Pre-Ballot - Short-Life Certificates

On 29/10/14 18:50, kirk_hall at trendmicro.com wrote:
> Ryan, thanks for the information, and I respect your analysis.  But 
> many of us would say that revocation (and the ability to check for
> revocation) is a fundamental aspect of whether a cert is valid at all. 

I think we all agree that the ability to revoke certs is vital. However, in the real world, there is always going to be a time lag of some sort between the decision to revoke and all clients becoming aware of that revocation. Comparing any system to the perfect system of universal instant revocation is unfair.

An analysis of real-world revocation inevitably involves complex scenarios about the nature of the attack, the capabilities of the attackers, the type of revocation system being used, the update frequency of clients, the characteristics of the network, and so on. And it inevitably involves vulnerability windows for some clients.

My assertion is that, in reasonable attack scenarios, the vulnerability windows and overall risk of short-lived certs is about the same as long-lived certs using OCSP.

Gerv

_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public