[cabfpub] Pre-Ballot - Short-Life Certificates

Tue Oct 28 17:30:23 MST 2014

Kirk,

I didn't say that at all. I would encourage you to re-read what I wrote,
but also what you said, as that is specifically what I responded to. Your
most recent message is a change in topic from what you asked, and does a
bit of a disservice to the discussion.

You asked whether browser changes would be required to support the
proposal. If no browser changes are required due to what is being proposed
- and again, this is the crux of your stated concern that I responded to -
does this change your opinion?
On Oct 28, 2014 5:27 PM, "kirk_hall at trendmicro.com" <
kirk_hall at trendmicro.com> wrote:

>  Well, it’s news to me that (all?) browsers currently don’t care and
> don’t check for CDPs or AIAs in certificates, and don’t do any revocation
> checking.
>
>
>
> If that’s true, why are CA OCSP responders getting so many queries, and
> why are our CRLs getting downloaded?  Who is doing that?
>
>
>
> And if that’s true, then what revocation checking burdens are the
> advocates of short-life certificates trying to avoid?
>
>
>
> Hard to evaluate this.
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi at google.com]
> *Sent:* Tuesday, October 28, 2014 5:05 PM
> *To:* Kirk Hall (RD-US)
> *Cc:* CABFPub; jeremy rowley
> *Subject:* Re: [cabfpub] Pre-Ballot - Short-Life Certificates
>
>
>
> If browsers don't need to change (and I'm not aware of one that does),
> does that resolve your concern? Put differently, you addressed the logical
> result if you're correct, but if you're incorrect, as I believe you are -
> and no changes are necessary - how does that change your reaction to the
> proposal?
>
> On Oct 28, 2014 4:59 PM, "kirk_hall at trendmicro.com" <
> kirk_hall at trendmicro.com> wrote:
> >
> > My point (maybe not very important) is that I think browsers MUST make
> changes in their code in order to support short-life certs that don’t
> contain any revocation pointers.
> >
> >
> >
> > If that’s correct – then browsers can go ahead and make those changes
> anyway, and can choose not to follow the revocation pointers in a
> short-life cert (as they define them).  CAs would continue to include
> revocation pointers in the short-life certs (no change to the BRs requiring
> revocation pointers would be needed), but the unilateral action / decision
> of browsers who support dropping revocation checking will cause them to
> disregard the pointers and do no checking – the revocation checking burden
> is lifted from CAs, there is potentially faster page delivery, etc., and no
> changes are needed in the BRs.
> >
> >
> >
> > Put another way, if browsers would already have to change their code to
> say “it’s ok for a cert not to have revocation pointers if it’s a 48 hour
> cert” – why not skip that step, and go straight to browser code changes
> that say “I will ignore the revocation pointers that are present and not do
> any revocation checking if this is a 48 hour cert” – it same result in the
> end, and the latter option leaves in the revocation checking pointers for
> those browsers and apps who chose not to drop revocation checking.
> >
> >
> >
> > From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Jeremy.Rowley
> > Sent: Tuesday, October 28, 2014 4:08 PM
> > To: public at cabforum.org
> >
> > Subject: Re: [cabfpub] Pre-Ballot - Short-Life Certificates
> >
> >
> >
> > The BR change wouldn't prohibit revocation pointers.  Instead, the BRs
> should give CAs the option of using certificate expiration as an
> alternative to revocation.  CAs who are worried about immediate revocation
> (<2 days) can still chose to include the pointers.
> >
> > Whether DigiCert will issue short-lived certs with or without the BR
> change is irrelevant.  If short-lived certs are something CAs can implement
> without requiring browser updates, why not roll it out that way?  What
> advantage is there in requiring browsers to change all their code  instead
> of letting CAs do the work?
> >
> > Jeremy
> >
> > On 10/28/2014 4:46 PM, Ryan Sleevi wrote:
> >>
> >>
> >> On Oct 28, 2014 3:42 PM, "kirk_hall at trendmicro.com" <
> kirk_hall at trendmicro.com> wrote:
> >> >
> >> > Jeremy – as a CA who is potentially interested in issuing short-life
> certs – are you saying you would not want to issue any short-life certs if
> (say) 30% of browsers in use will do revocation checking and 70% will not
> (because some but not all browsers modify their code to ignore revocation
> pointers in the short lived certs as a policy matter)?  It seem in that
> example that the load on your OCSP servers will be only 30% of today’s load
> for longer life certs with revocation checking – isn’t that an improvement?
> >> >
> >> >
> >> >
> >> > Put another way, are you only willing to issue short-life certs if
> you know that 100% of browsers and applications will not check for
> revocation (because the BRs would prohibit revocation pointers in the
> short-life certs)?
> >> >
> >> >
> >> >
> >> > Related to that – what happens today in the browsers if they
> encounter a cert that has NO revocation pointers (no CDP or AIA inside the
> cert)?  Do they treat the cert as valid?  Or do they put up a warning?
> >> >
> >> >
> >> >
> >> > If browsers today put up a warning, it seems that 100% of browsers
> would have to modify and distribute their code to stop showing warnings in
> order for short lived certs to be viable – true?  Just prohibiting
> revocation pointers in these certs via the BRs will not automatically make
> them viable in 100% of browsers.
> >> >
> >>
> >> No browser shows a warning for DV in the standard configuration.
> >>
> >> Several browsers offer (generally undocumented) functionality to always
> require revocation checking, but this is so awful that users are already
> conditioned to see errors regularly.
> >>
> >> >
> >> >
> >> > From: Jeremy.Rowley [mailto:jeremy.rowley at digicert.com]
> >> > Sent: Tuesday, October 28, 2014 3:15 PM
> >> > To: i-barreira at izenpe.net; philliph at comodo.com; Kirk Hall (RD-US)
> >> > Cc: public at cabforum.org
> >> >
> >> > Subject: Re: [cabfpub] Pre-Ballot - Short-Life Certificates
> >> >
> >> >
> >> >
> >> > The benefit is to everyone:
> >> > 1) CAs benefit by having a reduced load on their OCSP servers (at the
> exchange of more certificates issued)
> >> > 2) Subscribers benefit from a shortened lifecycle for revocation (two
> days instead of 10)
> >> > 3) Server operators benefit from smaller certificate sizes and no
> call back to the CA to check revocation information
> >> >
> >> > Jeremy
> >> >
> >> > On 10/28/2014 8:27 AM, i-barreira at izenpe.net wrote:
> >> >>
> >> >> How do you already know this is going to be a benefit? For who?
> Subscribers?
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> Iñigo Barreira
> >> >> Responsable del Área técnica
> >> >> i-barreira at izenpe.net
> >> >>
> >> >> 945067705
> >> >>
> >> >>
> >> >>
> >> >> ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta
> egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea
> gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi
> erantzuna. KONTUZ!
> >> >> ATENCION! Este mensaje contiene informacion privilegiada o
> confidencial a la que solo tiene derecho a acceder el destinatario. Si
> usted lo recibe por error le agradeceriamos que no hiciera uso de la
> informacion y que se pusiese en contacto con el remitente.
> >> >>
> >> >>
> >> >>
> >> >> De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> En nombre de Jeremy.Rowley
> >> >> Enviado el: martes, 28 de octubre de 2014 15:19
> >> >> Para: Phillip Hallam-Baker; kirk_hall at trendmicro.com
> >> >> CC: public at cabforum.org
> >> >> Asunto: Re: [cabfpub] Pre-Ballot - Short-Life Certificates
> >> >>
> >> >>
> >> >>
> >> >> 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 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
> >> >>> 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] 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 :-)
> >> >>>
> >> >>> 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
> >> >>> 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
> >> >>> https://cabforum.org/mailman/listinfo/public
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> > 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.
> >> >
> >> >
> >> > _______________________________________________
> >> > 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
> >
> >
> >
> > 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.
> >
> >
> > _______________________________________________
> > Public mailing list
> > Public at cabforum.org
> > https://cabforum.org/mailman/listinfo/public
> >
>
>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141028/228db432/attachment-0001.html 