<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:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@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:"Balloon Text Char";
        margin:0cm;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","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.EmailStyle19
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
span.EmailStyle20
        {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;}
--></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=NO-BOK link=blue vlink=purple><div class=WordSection1><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></body></html>