<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<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:0in;
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:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
color:black;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";
color:black;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
p.Textodeglobo, li.Textodeglobo, div.Textodeglobo
{mso-style-name:"Texto de globo";
mso-style-link:"Texto de globo Car";
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
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.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle23
{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:8.5in 11.0in;
margin:70.85pt 85.05pt 70.85pt 85.05pt;}
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]-->
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext">Jeremy – as a CA who is potentially interested in issuing short-life certs – are you saying you would
<u>not</u> 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?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext">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)?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext">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? <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext">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.<o:p></o:p></span></p>
<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 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"> Jeremy.Rowley [mailto:jeremy.rowley@digicert.com]
<br>
<b>Sent:</b> Tuesday, October 28, 2014 3:15 PM<br>
<b>To:</b> i-barreira@izenpe.net; philliph@comodo.com; Kirk Hall (RD-US)<br>
<b>Cc:</b> public@cabforum.org<br>
<b>Subject:</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">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<o:p></o:p></p>
<div>
<p class="MsoNormal">On 10/28/2014 8:27 AM, <a href="mailto:i-barreira@izenpe.net">
i-barreira@izenpe.net</a> wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">How do you already know this is going to be a benefit? For who? Subscribers?</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="line-height:9.75pt"><b><span lang="ES-TRAD" style="font-size:8.5pt;font-family:"Tahoma","sans-serif"">Iñigo Barreira</span></b><span lang="ES-TRAD" style="font-size:8.5pt;font-family:"Tahoma","sans-serif""><br>
Responsable del Área técnica<br>
<a href="mailto:i-barreira@izenpe.net">i-barreira@izenpe.net</a></span><o:p></o:p></p>
<p class="MsoNormal"><span lang="ES-TRAD" style="font-size:8.5pt;font-family:"Tahoma","sans-serif"">945067705</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="ES-TRAD" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><img border="0" width="585" height="111" id="Imagen_x0020_1" src="cid:image001.png@01CFF2C5.28DC9EA0" alt="Descripción: cid:image001.png@01CE3152.B4804EB0"></span><o:p></o:p></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><o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<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 href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [<a 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 href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a><br>
<b>CC:</b> <a href="mailto:public@cabforum.org">public@cabforum.org</a><br>
<b>Asunto:</b> Re: [cabfpub] Pre-Ballot - Short-Life Certificates</span><o:p></o:p></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 href="mailto:kirk_hall@trendmicro.com">
kirk_hall@trendmicro.com</a> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<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 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 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 href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [<a href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>] On Behalf Of
<a 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 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 href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [<a 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 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>
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:13.5pt">What does not having the revocation information in the cert actually solve?</span><o:p></o:p></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>
<br>
</span><o:p></o:p></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?</span><o:p></o:p></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>
<br>
</span><o:p></o:p></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.</span><o:p></o:p></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>
<br>
</span><o:p></o:p></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.</span><o:p></o:p></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 href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a 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 href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a></span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
</blockquote>
<p class="MsoNormal"> <o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>
<table><tr><td bgcolor=#ffffff><font color=#000000><pre><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></pre></font></td></tr></table>