[cabfpub] Pre-Ballot - Short-Life Certificates

Jeremy Rowley jeremy.rowley at digicert.com
Tue Oct 28 01:25:52 UTC 2014

If short-lived certs are an acceptable form of revocation checking, then what advantage is there to use a phased-in approach with customer browser code?  You get the same benefits with no changes by simply omitting the revocation pointers.  I don't see what risks are mitigated by phasing in short-lived certs only for new browsers.  


-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com
Sent: Monday, October 27, 2014 5:44 PM
To: Gervase Markham; Tim Hollebeek; public at cabforum.org
Subject: Re: [cabfpub] Pre-Ballot - Short-Life Certificates

Gerv, I've pasted in your original response to this question below.  

If I can summarize, you don't want revocation pointers in new "short lived certs" as defined because legacy browsers and apps (i.e., every browser and app in use today) will continue to check for revocation information, thereby lowering the benefit of this new type of cert.  (You estimated 90% will still check for revocation -- but is that number realistic under Google's and Mozilla's current revocation checking processes?  I thought revocation checking was already omitted today for many long-lived certs...)

My question back is: how long would it take Firefox and Google (and other interested browsers) to modify your browser software as Tim and Rich have suggested - ignore revocation pointers if the cert is a short lived cert?  And how quickly would those code changes get distributed to your users?

The burden of revocation checking falls mostly on CAs, and it can only get better (fewer revocation checks) if some browsers decide not to check revocation for (self-designated) short lived cert by modifying their software.  So why not just move forward as browsers to do this?  The revocation checking burden on CAs that decide to start issuing short-lived certs would not go up as compared to current long lived certs, and over time (maybe quickly) would go down.

Having said that, Trend Micro is not yet convinced this is a good idea for the reasons stated by others -- but the browsers don't have to wait if they think the risk from eliminating revocation checking for short lived certs is acceptable.

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Gervase Markham
Sent: Monday, October 27, 2014 12:33 PM
To: Tim Hollebeek; public at cabforum.org
Subject: Re: [cabfpub] Pre-Ballot - Short-Life Certificates

On 27/10/14 14:14, Tim Hollebeek wrote:
> What does not having the revocation information in the cert actually solve?

I've covered this earlier in the thread :-)


On 24/10/14 13:40, Rich Smith wrote:
> I keep coming back to this same question every time this comes up, and 
> I have not received a satisfactory answer yet:
> Why MUST a short lived certificate be issued without containing 
> revocation information?

And I keep asking it every time you ask: because putting in revocation information eliminates 90% of their advantage, because there is then no advantage in all the currently-existing clients. A short-lived cert with revocation pointers will still incur the delay of revocation checking, even though (this is the argument, and the argument with which I hope you will engage) it's not necessary to provide them because the security properties of a 3-day cert are broadly comparable to a 1-year cert with 10-day, 5-day or 3-day-expiry OCSP responses.

> The simple fact of the matter is that revocation info in the 
> certificate MAY help SOME users IF the certificate gets revoked, and I 
> have yet to see anyone offer up any decent argument for why the 
> revocation info absolutely MUST NOT be present for short-lived certs to work.

No one is arguing that it MUST NOT be present for short-lived certificates to "work". But if a site and a CA are together considering deploying such a technology, they will look at the costs and benefits.
There will be significant costs in setting up the system; if the benefits are only in 5% or 10% of clients, it may well be judged not to be worth it.

> I'm open
> to such an argument, but until I see it I remain opposed to a ballot 
> to allow any certificate to be issued without revocation information.

I don't understand this position. Surely the acceptability or not of short-lived certificates should depend on whether their security properties are broadly comparable to existing solutions, not on whether I can construct an argument that shows it's required to remove the revocation information for it to be technically feasible to deploy them?

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.

Public mailing list
Public at cabforum.org

More information about the Public mailing list