<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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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:11.0pt;
font-family:"Calibri","sans-serif";}
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";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.TextodegloboCar
{mso-style-name:"Texto de globo Car";
mso-style-priority:99;
mso-style-link:"Texto de globo";
font-family:"Tahoma","sans-serif";}
p.BalloonText, li.BalloonText, div.BalloonText
{mso-style-name:"Balloon Text";
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EstiloCorreo21
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EstiloCorreo22
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EstiloCorreo23
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EstiloCorreo24
{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 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:678889919;
mso-list-type:hybrid;
mso-list-template-ids:-1926179508 -976294658 201981955 201981957 201981953 201981955 201981957 201981953 201981955 201981957;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-font-family:Calibri;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></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 lang=ES link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='color:#1F497D'>Iīm agree with Rich about the issuance of any certificate without revocation information, I think this is a must and albeit the short-lived certificates could be interesting, but I see disavantages technically and financially or in the “administration” area.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Technical <o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='color:#1F497D'><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:#1F497D'>In our infrastructure (I donīt know the others) we have set up the duration of the certificates to 4 years, 2 years, 23,45 months </span><span style='font-family:Wingdings;color:#1F497D'>J</span><span style='color:#1F497D'>, etc. So, at the time we issue a certificate we know when is going to finish and at the same time the CRL/OCSP “start working” to provide an answer for those who want to check it out. Unless we define a period/duration for the shor lived certificates (24 hours, 7 days, 10 days, …) that can be implemented by default I canīt issue certifcates one by one depending of what type is and which duration (this is not a butchery, I want one of 2 days, 3 certs of 24 hours, and a couple of 7 days)<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='color:#1F497D'><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:#1F497D'>Regarding the stapling, cached responses, etc. yes, youīre right, but the users can always check the status of the certificate by themselves, well, not “all” the users but the option is there, but the issuance whithout that “option” wouldnīt add more security because you canīt check it.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Administration<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='color:#1F497D'><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:#1F497D'>For every cert I issue I create an invoice (itīs the way we work, sorry) to the customer, so theyīll have one invoice every 2 years if weīre lucky (and you know we issue just a few of them) but with this short lived maybe we have to issue one invoice every day, so after 2 years, we have issued like 730 invoices (even in christmas, easter, etc, </span><span style='font-family:Wingdings;color:#1F497D'>L</span><span style='color:#1F497D'> ) and send them to the customer and manage them here and see if they pay all of them, or they forget, etc. itīs a mess. <o:p></o:p></span></p><p class=MsoListParagraph style='margin-left:72.0pt;text-indent:-18.0pt;mso-list:l0 level2 lfo1'><![if !supportLists]><span style='font-family:"Courier New";color:#1F497D'><span style='mso-list:Ignore'>o<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:#1F497D'>Yes, you can argue that do not need to do it that way, and send just one invoice with all the certs issued in 1 year, or month, or whatever, but itīs done automatically and that would make an economic impact. Iīd need to change my SAP<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='color:#1F497D'><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:#1F497D'>For the BR, and similar to EV, itīs needed to check all the info previously to the issuance so that would generate a big impact in the “validation team” (yes, you can argue that if the info does not change I can use the same but for how long?, is this a solution?)<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='color:#1F497D'><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:#1F497D'>Besides, I need to keep all the info of the certificates issued, so the folder of these kind of certificates can be quite big and again not easy to manage. The “archiving team” will have to check that all the info has been provided in terms of forms, like the request form (I understand that I need a request form every time, so a request form every day? Or every 2 days or 7 days?) and the same for the validation checks, etc.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>These are only some arguments that came to my mind but I see a lot of problems in the administrative tasks than in the Technical ones, which by the way, not including the “revocation information” donīt make them more secure albeit they “live” less and this is about security and I think it wonīt improve it.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Regards<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>PS: Like Tom uses to say, this is my opnion, if you donīt like I have others (and if I can explain them in spanish/basque with some “polite” words, much better </span><span style='font-family:Wingdings;color:#1F497D'>J</span><span style='color:#1F497D'> )<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><div><p class=MsoNormal style='line-height:9.75pt'><b><span lang=ES-TRAD style='font-size:8.5pt;font-family:"Tahoma","sans-serif";color:black'><o:p> </o:p></span></b></p><p class=MsoNormal style='line-height:9.75pt'><b><span lang=ES-TRAD style='font-size:8.5pt;font-family:"Tahoma","sans-serif";color:black'>Iņigo Barreira</span></b><span lang=ES-TRAD style='font-size:8.5pt;font-family:"Tahoma","sans-serif";color:black'><br>Responsable del Área técnica<br><a href="mailto:i-barreira@izenpe.net">i-barreira@izenpe.net</a><o:p></o:p></span></p><p class=MsoNormal><span lang=ES-TRAD style='font-size:8.5pt;font-family:"Tahoma","sans-serif";color:black'>945067705</span><span lang=ES-TRAD style='color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span lang=ES-TRAD style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><img border=0 width=585 height=111 id="Imagen_x0020_1" src="cid:image001.png@01CD9646.595AC350"></span><span lang=ES-TRAD style='color:#1F497D'><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='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-size:12.0pt;color:navy;mso-fareast-language:ES-TRAD'><o:p></o:p></span></p></div><p class=MsoNormal><span style='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"'>De:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> public-bounces@cabforum.org [mailto:public-bounces@cabforum.org] <b>En nombre de </b>Rich Smith<br><b>Enviado el:</b> martes, 18 de septiembre de 2012 18:05<br><b>Para:</b> 'Mads Egil Henriksveen'; 'CABFPub'<br><b>Asunto:</b> Re: [cabfpub] FW: Short lived OCSP signing certificate<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span lang=EN-US style='color:#1F497D'>I am still opposed to issuance of any certificate without revocation information. Yes, the BRs allow a signed OCSP response to be good for 10 days. My understanding for the reasoning behind that is that it is extremely time consuming to resign hundreds of thousands of "Good" OCSP responses for all of the valid certificates which a CA may have issued and some large CAs require nearly that whole time to cycle their responses. It does not mean that the CA is going to wait 10 days to publish a "Revoked" response if they revoke the certificate even minutes after signing an OCSP "Good" response. I can't speak for other CAs, but at Comodo, that "Revoked" OCSP response replaces the previous "Good" response almost immediately no matter how much time is theoretically left on the "Good" response. I suspect that other CAs behave in a similar fashion. The disconnect here seems to be that the relying parties take that 10 day lifespan to mean that they can leave off checking to 10 day intervals and that is faulty reasoning. IMO, that 10 day timeframe SHOULD NOT be used in caching OCSP responses in browsers, nor should it be used in stapling. Browsers and servers using stapling do not have to resign hundreds of thousands of responses, they just have to retrieve responses periodically. As such, IMO, they should be doing that at least every 24 hours, not every 10 days. If that is the case then revocation information is still useful and SHOULD remain mandatory. Moreover, I don't see why this is even an area of contention. There is absolutely no reason that a short-lived certificate REQUIRES the absence of revocation information. The only reason I can see is that some parties don't want to be held to account for not properly checking the revocation status, so if the information is not there they're off the hook. I fail to see how that makes anyone more secure.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='color:#1F497D'>Regards,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='color:#1F497D'>Rich<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> public-bounces@cabforum.org [mailto:public-bounces@cabforum.org] <b>On Behalf Of </b>Mads Egil Henriksveen<br><b>Sent:</b> Monday, September 17, 2012 9:40 AM<br><b>To:</b> CABFPub<br><b>Subject:</b> [cabfpub] FW: Short lived OCSP signing certificate<o:p></o:p></span></p></div></div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>Hi<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>This summer there was a discussion regarding short lived certificates. I didn’t find any conclusion on the topic, but apparently there was some disagreement between the participants regarding the usability of short lived Subscriber certificates. However, I do think we already have implicitly introduced the concept of short lived certificates related to OCSP signing certificates, but this has been included in the discussions so far. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>For the purpose of analyzing and understanding the usability of short lived Subscriber certificates as an introduction, I use three simplified models describing how an application validates a SSL-certificate received from a web server:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><b><span lang=EN-US>A: Standard OCSP <o:p></o:p></span></b></p><p class=MsoNormal><span lang=EN-US>In this model the application receives the SSL-certificate from the web server and must check the revocation status by using the issuing CA’s OCSP service.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>The revocation status received in the OCSP-response is time limited (up to 10 days according to BR) and the application should ensure that it always have a un-expired (valid) revocation status. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>I assume that the different browsers handle this in some way, although I guess this vary from browser to browser.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><b><span lang=EN-US>B: OCSP-stapling<o:p></o:p></span></b></p><p class=MsoNormal><span lang=EN-US>In this model the web server is responsible for returning the revocation status as an OCSP-response bundled with the SSL-certificate.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>The application receives a time limited revocation status from the web server and thus the responsibility for ensuring that a valid revocation status is available, is transferred from the application to the web server. The web server gets a “fresh” time limited revocation status by using the issuing CA’s OCSP service similar to A above. This is a more efficient model than A since the traffic towards the CA’s OCSP service is dramatically reduced.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>However, the application is expected to deal with the time limited revocation status in a proper and secure way (whatever that may be) also in this model. Again, I assume that this is (or will be) handled by the browsers when OCSP stapling is used. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><b><span lang=EN-US>C: Short lived certificates<o:p></o:p></span></b></p><p class=MsoNormal><span lang=EN-US>In this model the web server returns a short lived SSL-certificate (let’s assume max 10 days) without the revocation status.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>The web server must renew the SSL certificate frequently using another service from the issuing CA. However, this step is similar to getting a “fresh” time limited revocation status as used in B above. Therefore, the protocol between the parties (application, web server and CA) is basically similar to model B. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>The application could deal with short lived SSL-certificates in a standard way, i.e. discard expired certificates. However, I assume that browsers to not support short lived Subscriber certificates properly at the moment (?).<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><br>To summarize; I find model B and C conceptually equal and don’t really understand why model C is less proper and/or secure than model B. Of course, this simplified models do not take all aspects into consideration. But seen from this model at a conceptual level, I do not find any important differences between model B and C. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>And this leads me to the main topic: Short lived OCSP signing certificates. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>If a CA is using a delegated OCSP responder, BR mandates the usage of id-pkix-ocsp-nocheck in the OCSP signing certificates and RFC 2560 recommends (?) a CA to use a very short lifetime in this case. With this in mind, the concept of short lived certificates is already present, although not as Subscriber certificates but as OCSP Signing certificates, in the current infrastructure. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>Therefore, it could be interesting to understand how the models above are affected by introducing short lived OCSP signing certificates. And are short lived OCSP signing certificates comparable to short lived Subscriber certificates with respect to their lifetime? How should we think when defining a lifetime of a short lived OCSP signing certificate compared to the lifetime of a revocation status? Should they be similar, e.g. 10 days? And should OCSP signing certificates issued from a Root CA have a similar lifetime as certificates issued from a Subordinate CA?<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>For model A and B, the process is much more complex if the CA uses a delegated OCSP responder to sign OCSP responses. How do the applications deals with such short lived certificates? Will the OCSP response be discarded if the OCSP signing certificate has expired? <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>The bottom line is that the introduction of short lived OCSP signing certificates complicates the current infrastructure and I think the issues raised for short lived Subscriber certificates must be raised also for short lived OCSP Signing certificates. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>Regards<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>Mads <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div></div></body></html>