[cabfpub] Pre-Ballot - Short-Life Certificates

Tue Oct 28 17:04:39 MST 2014

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141028/8111328a/attachment-0001.html 