<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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>
<div class="moz-cite-prefix">On 10/28/2014 8:27 AM,
<a class="moz-txt-link-abbreviated" href="mailto:i-barreira@izenpe.net">i-barreira@izenpe.net</a> wrote:<br>
</div>
<blockquote
cite="mid:763539E260C37C46A0D6B340B5434C3B0A40BC44@AEX06.ejsarea.net"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]-->
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Texto de globo Car";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
color:black;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.TextodegloboCar
{mso-style-name:"Texto de globo Car";
mso-style-priority:99;
mso-style-link:"Texto de globo";
font-family:"Tahoma","sans-serif";
color:black;}
span.EstiloCorreo20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 3.0cm 70.85pt 3.0cm;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US">How do you already know this is going to be a
benefit? For who? Subscribers?<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="line-height:9.75pt"><b><span
style="font-size:8.5pt;font-family:"Tahoma","sans-serif""
lang="ES-TRAD">Iñigo Barreira</span></b><span
style="font-size:8.5pt;font-family:"Tahoma","sans-serif""
lang="ES-TRAD"><br>
Responsable del Área técnica<br>
<a moz-do-not-send="true"
href="mailto:i-barreira@izenpe.net">i-barreira@izenpe.net</a><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:8.5pt;font-family:"Tahoma","sans-serif""
lang="ES-TRAD">945067705</span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="ES-TRAD"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="ES-TRAD"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><img
id="Imagen_x0020_1"
src="cid:part2.02000406.05080709@digicert.com"
alt="Descripción: cid:image001.png@01CE3152.B4804EB0"
border="0" height="111" width="585"></span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="ES-TRAD"><o:p></o:p></span></p>
<p class="MsoNormal" style="line-height:9.75pt"><span
style="font-size:7.5pt;font-family:"Tahoma","sans-serif";color:#888888;mso-fareast-language:ES-TRAD">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!</span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#888888;mso-fareast-language:ES-TRAD"><br>
</span><span
style="font-size:7.5pt;font-family:"Tahoma","sans-serif";color:#888888;mso-fareast-language:ES-TRAD">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.</span><span
style="font-family:"Calibri","sans-serif";color:navy;mso-fareast-language:ES-TRAD"><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">De:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">
<a class="moz-txt-link-abbreviated" href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>
[<a class="moz-txt-link-freetext" href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>] <b>En nombre de </b>Jeremy.Rowley<br>
<b>Enviado el:</b> martes, 28 de octubre de 2014 15:19<br>
<b>Para:</b> Phillip Hallam-Baker;
<a class="moz-txt-link-abbreviated" href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a><br>
<b>CC:</b> <a class="moz-txt-link-abbreviated" href="mailto:public@cabforum.org">public@cabforum.org</a><br>
<b>Asunto:</b> Re: [cabfpub] Pre-Ballot - Short-Life
Certificates<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">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<o:p></o:p></p>
<div>
<p class="MsoNormal">On 10/28/2014 7:49 AM, Phillip
Hallam-Baker wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">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:<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt">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 [<a moz-do-not-send="true"
href="mailto:jeremy.rowley@digicert.com">mailto:jeremy.rowley@digicert.com</a>]<span
class="apple-converted-space"> </span><br>
Sent: Monday, October 27, 2014 6:26 PM<br>
To: Kirk Hall (RD-US); 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>
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>
[<a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org">mailto: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>
[<a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org">mailto: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>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:13.5pt">What
does not having the revocation information in the cert
actually solve?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:13.5pt"><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>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:13.5pt">I keep
coming back to this same question every time this
comes up, and<span class="apple-converted-space"> </span><br>
I have not received a satisfactory answer yet:<br>
Why MUST a short lived certificate be issued without
containing<span class="apple-converted-space"> </span><br>
revocation information?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:13.5pt"><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>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:13.5pt">The
simple fact of the matter is that revocation info in
the<span class="apple-converted-space"> </span><br>
certificate MAY help SOME users IF the certificate
gets revoked, and I<span class="apple-converted-space"> </span><br>
have yet to see anyone offer up any decent argument
for why the<span class="apple-converted-space"> </span><br>
revocation info absolutely MUST NOT be present for
short-lived certs to work.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:13.5pt"><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>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:13.5pt">I'm
open<br>
to such an argument, but until I see it I remain
opposed to a ballot<span class="apple-converted-space"> </span><br>
to allow any certificate to be issued without
revocation information.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:13.5pt"><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.<span
class="apple-converted-space"> </span><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<span
class="apple-converted-space"> </span><br>
and may be subject to copyright or other intellectual
property protection.<span
class="apple-converted-space"> </span><br>
If you are not the intended recipient, you are not
authorized to use or<span
class="apple-converted-space"> </span><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><o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
<br>
</body>
</html>