[cabfpub] Pre-Ballot - Short-Life Certificates
Jeremy.Rowley
jeremy.rowley at digicert.com
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>
More information about the Public
mailing list