[cabfpub] Pre-Ballot - Short-Life Certificates

Tue Oct 28 14:19:17 UTC 2014

By not making a change in the BRs, the CAB Forum is essentially saying 
CAs can't use expiration as a means of revocation.  Without the benefit 
provided by short lived certs, you won't have subscribers using them.

Jeremy

On 10/28/2014 7:49 AM, Phillip Hallam-Baker wrote:
> Which is why I disagreed with Gerv’s claim that there is no point to 
> issuing short lived certs with the revocation indicators present. The 
> point is that it establishes a base of deployment that can then be 
> used to justify the necessary changes in the BRs.
>
> The reason that I am interested in short lived certs even with the 
> compressed CRL technology is because even a compressed delta CRL is 
> still a list. The scaling issue is postponed, not eliminated.
>
> If however we combine short lived certs with compressed CRLs we can 
> reduce the vulnerability window from days to hours. Which is a big 
> gain because it would mean that we likely remove the incentive to 
> attempt an attack.
>
>
> The secret to keeping Disneyland clean is that the park is already 
> clean. People feel bad about littering if the place is clean. If there 
> is litter they don’t feel bad about making more.
>
>
> On Oct 27, 2014, at 10:26 PM, kirk_hall at trendmicro.com 
> <mailto:kirk_hall at trendmicro.com> wrote:
>
>> Not everyone agrees at this point that the risk profile of 
>> short-lived certs that can't be recalled (no revocation checking 
>> possible) is equivalent to the risk profile of long-lived certs with 
>> revocation checking but with all the limitations discussed.
>>
>> Leaving the decision on whether to accept short-lived certs with no 
>> revocation checking to the interested browsers and interested CAs 
>> means that other CAs and browsers don't have to approve or 
>> participate -- and no changes to the BRs would be required.
>>
>> -----Original Message-----
>> From: Jeremy Rowley [mailto:jeremy.rowley at digicert.com]
>> Sent: Monday, October 27, 2014 6:26 PM
>> To: Kirk Hall (RD-US); Gervase Markham; Tim 
>> Hollebeek;public at cabforum.org <mailto:public at cabforum.org>
>> Subject: RE: [cabfpub] Pre-Ballot - Short-Life Certificates
>>
>> 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.
>>
>> Jeremy
>>
>> -----Original Message-----
>> From: public-bounces at cabforum.org 
>> <mailto:public-bounces at cabforum.org> 
>> [mailto:public-bounces at cabforum.org] On Behalf Of 
>> kirk_hall at trendmicro.com <mailto:kirk_hall at trendmicro.com>
>> Sent: Monday, October 27, 2014 5:44 PM
>> To: Gervase Markham; Tim Hollebeek; public at cabforum.org 
>> <mailto: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> 
>> [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 <mailto: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 :-)
>>
>> Gerv
>> _______________________________________________
>>
>> 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?
>>
>> Gerv
>> <table class="TM_EMAIL_NOTICE"><tr><td><pre>
>> TREND MICRO EMAIL NOTICE
>> 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.
>> </pre></td></tr></table>
>>
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org <mailto:Public at cabforum.org>
>> https://cabforum.org/mailman/listinfo/public
>> <table class="TM_EMAIL_NOTICE"><tr><td><pre>
>> TREND MICRO EMAIL NOTICE
>> 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.
>> </pre></td></tr></table>
>>
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org <mailto:Public at cabforum.org>
>> https://cabforum.org/mailman/listinfo/public
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20141028/e9e1b743/attachment-0003.html>