<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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. <br>
<br>
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? <br>
<br>
Jeremy<br>
<br>
<br>
<div class="moz-cite-prefix">On 10/28/2014 4:46 PM, Ryan Sleevi
wrote:<br>
</div>
<blockquote
cite="mid:CACvaWvbNzpnCqBLukK+mm+CE5Vc1eJrj_7X9sjda5P1XniOSHg@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<p dir="ltr"><br>
On Oct 28, 2014 3:42 PM, "<a moz-do-not-send="true"
href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>"
<<a moz-do-not-send="true"
href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>>
wrote:<br>
><br>
> 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?<br>
><br>
> <br>
><br>
> 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)?<br>
><br>
> <br>
><br>
> 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? <br>
><br>
> <br>
><br>
> 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.<br>
></p>
<p dir="ltr">No browser shows a warning for DV in the standard
configuration.</p>
<p dir="ltr">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.</p>
<p dir="ltr">> <br>
><br>
> From: Jeremy.Rowley [mailto:<a moz-do-not-send="true"
href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>]
<br>
> Sent: Tuesday, October 28, 2014 3:15 PM<br>
> To: <a moz-do-not-send="true"
href="mailto:i-barreira@izenpe.net">i-barreira@izenpe.net</a>;
<a moz-do-not-send="true" href="mailto:philliph@comodo.com">philliph@comodo.com</a>;
Kirk Hall (RD-US)<br>
> Cc: <a moz-do-not-send="true"
href="mailto:public@cabforum.org">public@cabforum.org</a><br>
><br>
> Subject: Re: [cabfpub] Pre-Ballot - Short-Life Certificates<br>
><br>
> <br>
><br>
> The benefit is to everyone:<br>
> 1) CAs benefit by having a reduced load on their OCSP
servers (at the exchange of more certificates issued)<br>
> 2) Subscribers benefit from a shortened lifecycle for
revocation (two days instead of 10)<br>
> 3) Server operators benefit from smaller certificate sizes
and no call back to the CA to check revocation information<br>
><br>
> Jeremy<br>
><br>
> On 10/28/2014 8:27 AM, <a moz-do-not-send="true"
href="mailto:i-barreira@izenpe.net">i-barreira@izenpe.net</a>
wrote:<br>
>><br>
>> How do you already know this is going to be a benefit?
For who? Subscribers?<br>
>><br>
>> <br>
>><br>
>> <br>
>><br>
>> Iñigo Barreira<br>
>> Responsable del Área técnica<br>
>> <a moz-do-not-send="true"
href="mailto:i-barreira@izenpe.net">i-barreira@izenpe.net</a><br>
>><br>
>> 945067705<br>
>><br>
>> <br>
>><br>
>> 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!<br>
>> 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.<br>
>><br>
>> <br>
>><br>
>> De: <a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>
[mailto:<a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>]
En nombre de Jeremy.Rowley<br>
>> Enviado el: martes, 28 de octubre de 2014 15:19<br>
>> Para: Phillip Hallam-Baker; <a moz-do-not-send="true"
href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a><br>
>> CC: <a moz-do-not-send="true"
href="mailto:public@cabforum.org">public@cabforum.org</a><br>
>> Asunto: Re: [cabfpub] Pre-Ballot - Short-Life
Certificates<br>
>><br>
>> <br>
>><br>
>> 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.<br>
>><br>
>> Jeremy<br>
>><br>
>> On 10/28/2014 7:49 AM, Phillip Hallam-Baker wrote:<br>
>>><br>
>>> 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.<br>
>>><br>
>>> <br>
>>><br>
>>> 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.<br>
>>><br>
>>> <br>
>>><br>
>>> 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.<br>
>>><br>
>>> <br>
>>><br>
>>> <br>
>>><br>
>>> 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.<br>
>>><br>
>>> <br>
>>><br>
>>> <br>
>>><br>
>>> On Oct 27, 2014, at 10:26 PM, <a
moz-do-not-send="true" href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>
wrote:<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> 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.<br>
>>><br>
>>> 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.<br>
>>><br>
>>> -----Original Message-----<br>
>>> From: Jeremy Rowley [mailto:<a
moz-do-not-send="true"
href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>] <br>
>>> Sent: Monday, October 27, 2014 6:26 PM<br>
>>> To: Kirk Hall (RD-US); Gervase Markham; Tim <a
moz-do-not-send="true"
href="mailto:Hollebeek%3Bpublic@cabforum.org">Hollebeek;public@cabforum.org</a><br>
>>> Subject: RE: [cabfpub] Pre-Ballot - Short-Life
Certificates<br>
>>><br>
>>> 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. <br>
>>><br>
>>> Jeremy<br>
>>><br>
>>> -----Original Message-----<br>
>>> From: <a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>
[mailto:<a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>]
On Behalf Of <a moz-do-not-send="true"
href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a><br>
>>> Sent: Monday, October 27, 2014 5:44 PM<br>
>>> To: Gervase Markham; Tim Hollebeek; <a
moz-do-not-send="true" href="mailto:public@cabforum.org">public@cabforum.org</a><br>
>>> Subject: Re: [cabfpub] Pre-Ballot - Short-Life
Certificates<br>
>>><br>
>>> Gerv, I've pasted in your original response to this
question below. <br>
>>><br>
>>> 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...)<br>
>>><br>
>>> 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?<br>
>>><br>
>>> 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.<br>
>>><br>
>>> 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.<br>
>>><br>
>>> -----Original Message-----<br>
>>> From: <a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>
[mailto:<a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>]
On Behalf Of Gervase Markham<br>
>>> Sent: Monday, October 27, 2014 12:33 PM<br>
>>> To: Tim Hollebeek; <a moz-do-not-send="true"
href="mailto:public@cabforum.org">public@cabforum.org</a><br>
>>> Subject: Re: [cabfpub] Pre-Ballot - Short-Life
Certificates<br>
>>><br>
>>> On 27/10/14 14:14, Tim Hollebeek wrote:<br>
>>><br>
>>><br>
>>> What does not having the revocation information in
the cert actually solve?<br>
>>><br>
>>><br>
>>> I've covered this earlier in the thread :-)<br>
>>><br>
>>> Gerv<br>
>>> _______________________________________________<br>
>>><br>
>>> On 24/10/14 13:40, Rich Smith wrote:<br>
>>><br>
>>><br>
>>> I keep coming back to this same question every time
this comes up, and <br>
>>> I have not received a satisfactory answer yet:<br>
>>> Why MUST a short lived certificate be issued
without containing <br>
>>> revocation information?<br>
>>><br>
>>><br>
>>> 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.<br>
>>><br>
>>><br>
>>><br>
>>> The simple fact of the matter is that revocation
info in the <br>
>>> certificate MAY help SOME users IF the certificate
gets revoked, and I <br>
>>> have yet to see anyone offer up any decent argument
for why the <br>
>>> revocation info absolutely MUST NOT be present for
short-lived certs to work.<br>
>>><br>
>>><br>
>>> 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.<br>
>>> 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.<br>
>>><br>
>>><br>
>>><br>
>>> I'm open<br>
>>> to such an argument, but until I see it I remain
opposed to a ballot <br>
>>> to allow any certificate to be issued without
revocation information.<br>
>>><br>
>>><br>
>>> 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?<br>
>>><br>
>>> Gerv<br>
>>> <table
class="TM_EMAIL_NOTICE"><tr><td><pre><br>
>>> TREND MICRO EMAIL NOTICE<br>
>>> The information contained in this email and any
attachments is confidential and may be subject to copyright or
other intellectual property protection. <br>
>>> 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.<br>
>>> </pre></td></tr></table><br>
>>><br>
>>> _______________________________________________<br>
>>> Public mailing list<br>
>>> <a moz-do-not-send="true"
href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
>>> <a moz-do-not-send="true"
href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a><br>
>>> <table
class="TM_EMAIL_NOTICE"><tr><td><pre><br>
>>> TREND MICRO EMAIL NOTICE<br>
>>> The information contained in this email and any
attachments is confidential <br>
>>> and may be subject to copyright or other
intellectual property protection. <br>
>>> If you are not the intended recipient, you are not
authorized to use or <br>
>>> disclose this information, and we request that you
notify us by reply mail or<br>
>>> telephone and delete the original message from your
mail system.<br>
>>> </pre></td></tr></table><br>
>>><br>
>>> _______________________________________________<br>
>>> Public mailing list<br>
>>> <a moz-do-not-send="true"
href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
>>> <a moz-do-not-send="true"
href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a><br>
>>><br>
>>> <br>
>><br>
>> <br>
><br>
> <br>
><br>
> TREND MICRO EMAIL NOTICE<br>
> The information contained in this email and any attachments
is confidential <br>
> and may be subject to copyright or other intellectual
property protection. <br>
> If you are not the intended recipient, you are not
authorized to use or <br>
> disclose this information, and we request that you notify
us by reply mail or<br>
> telephone and delete the original message from your mail
system.<br>
><br>
><br>
> _______________________________________________<br>
> Public mailing list<br>
> <a moz-do-not-send="true"
href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
> <a moz-do-not-send="true"
href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a><br>
><br>
</p>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
<br>
</body>
</html>