<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=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:Cambria;
        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:0in;
        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.MsoPlainText, li.MsoPlainText, div.MsoPlainText
        {mso-style-priority:99;
        mso-style-link:"Plain Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
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";}
span.PlainTextChar
        {mso-style-name:"Plain Text Char";
        mso-style-priority:99;
        mso-style-link:"Plain Text";
        font-family:"Calibri","sans-serif";}
span.EmailStyle20
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
span.EmailStyle21
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.EmailStyle22
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.BalloonTextChar
        {mso-style-name:"Balloon Text Char";
        mso-style-priority:99;
        mso-style-link:"Balloon Text";
        font-family:"Tahoma","sans-serif";}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
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="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">Jeremy,<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">I agree and am in favor of this change – however, we need to be careful of browser behavior on failure cases for such certificates.  Because expiration is perhaps the most common legitimate cause of certificate
 invalidity today, most browsers allow a click-through, and most users would expect that a certificate only a few days out-of-date would be safe to click through.  That’s not the right behavior if we’re now relying on the short lifetime to now provide revocation-level
 security guarantees.<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">I would suggest that if browsers encounter a short-lived certificate, with no revocation information, and it is past its validity period, they SHOULD fail the connection with no user recourse.  (same behavior
 as HSTS)<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">-Brad<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<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"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> public-bounces@cabforum.org [mailto:public-bounces@cabforum.org]
<b>On Behalf Of </b>Jeremy Rowley<br>
<b>Sent:</b> Friday, July 27, 2012 11:29 AM<br>
<b>To:</b> public@cabforum.org<br>
<b>Subject:</b> Re: [cabfpub] Short Lived Certificates<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoPlainText">To follow up on the initial post, some members have disagreed about the value of the short-lived certificates.  This is a response to that disagreement and an attempt to move the discussion to the public mailing list:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">I think this discussion is straying from the point that several of us are trying to make-- that revocation time-tables are effectively the same as short-lived certificates, regardless of the mechanism selected.  In a secure-site environment,
 a short-lived certificate has the same practical effect as current revocation mechanisms because with the caching of CRLs and certificate status responses there will always create a window where revocation can't happen.  Even if a CA revokes a certificate
 using OCSP, the CA can't prevent an attacker from supplying a previously good response for a given TTL.  There isn't a benefit to OCPS or CRL over short-lived certs.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">All we should be asking at this point is whether a short-lived certificate should be acceptable under the baseline requirements (a minimum standard).  Remember, we are only establishing a floor for certificate practices, not building
 walls to restrict practices we don't implement, stifle new ideas, or prevent every conceivable attack.  Therefore, the burden is on those opposed to short-lived certificates to provide clear and convincing reasons why they should not be allowed.  From a practical
 standpoint, a short-lived certificate has a benefit for those companies who don't want to rely on OCSP or CRL certificate revocation and would like a performance gain by eliminating revocation look-ups.  The whole point of a short-lived certificate is that
 its short life IS the revocation information.  <o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">As far as intermediate certificates are concerned, we can get a significant performance gain if we limit the revocation information in intermediates used to issue short lived certificates to CRLs instead of mandating OCSP.  This way
 intermediates still have revocation information included but short-lived certificates continue to provide a significant benefit.  Unless someone has a good security reason against it, the baseline requirements should permit short-lived certificates issued
 from an Intermediate that contain CRLs but not require OCSP.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Jeremy<o:p></o:p></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>
<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"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> <a href="mailto:[mailto:public-bounces@cabforum.org]">
[mailto:public-bounces@cabforum.org]</a> <b>On Behalf Of </b>Jeremy Rowley<br>
<b>Sent:</b> Friday, July 27, 2012 12:26 PM<br>
<b>To:</b> <a href="mailto:public@cabforum.org">public@cabforum.org</a><br>
<b>Subject:</b> [cabfpub] Short Lived Certificates<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif"">Hi everyone, <o:p>
</o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif"">One of the current discussions in the CAB Forum is the issuance of short-lived certificates.  I thought I’d move the discussion over this public list for additional input. This is the proposal
 (which has been updated from its original post based on the comments received so far):<o:p></o:p></span></p>
<p><span style="font-size:11.0pt;font-family:"Cambria","serif"">While reviewing the baseline requirements, we noticed an odd situation where the baseline requirements permit a CA to omit any revocation information in a certificate.  We also noticed that the
 baseline requirements don't permit the use of short-lived certificates.  As discussed previously, short-lived certificates have a lifecycle of about seven days.  Because the lifecycle is short, the risks associated with a compromised certificate are minimized,
 making revocation information in the certificate unnecessary.  Because short-lived certificates are highly sensitive to the accuracy of a relying party's system time, for fault-tolerance purposes, it is best if short-lived certificates have a “valid from”
 date/time that pre-dates the actual date/time of issuance.  Having the certificate be valid for a period of 14 days (seven on either side of the issuance date) helps eliminate the accuracy concerns. <o:p></o:p></span></p>
<p><span style="font-size:11.0pt;font-family:"Cambria","serif"">Appendix B of the baseline requirements state:<o:p></o:p></span></p>
<p><i><span style="font-size:11.0pt;font-family:"Cambria","serif"">B. cRLDistributionPoints</span></i><span style="font-size:11.0pt;font-family:"Cambria","serif""><o:p></o:p></span></p>
<p><i><span style="font-size:11.0pt;font-family:"Cambria","serif"">This extension MAY be present.  If present, it MUST NOT be marked critical, and it MUST contain the  HTTP URL of the CA’s CRL service.  See Section 13.2.1 for details.</span></i><span style="font-size:11.0pt;font-family:"Cambria","serif""><o:p></o:p></span></p>
<p><i><span style="font-size:11.0pt;font-family:"Cambria","serif"">C. authorityInformationAccess</span></i><span style="font-size:11.0pt;font-family:"Cambria","serif""><o:p></o:p></span></p>
<p><i><span style="font-size:11.0pt;font-family:"Cambria","serif"">With the exception of stapling, which is noted below, this extension MUST be present.  It MUST NOT be marked critical, and it MUST contain the HTTP URL of the Issuing CA’s OCSP responder (accessMethod
 = 1.3.6.1.5.5.7.48.1).  It SHOULD also contain the HTTP URL of the Issuing CA’s certificate (accessMethod = 1.3.6.1.5.5.7.48.2).  See Section 13.2.1 for details.</span></i><span style="font-size:11.0pt;font-family:"Cambria","serif""><o:p></o:p></span></p>
<p><i><span style="font-size:11.0pt;font-family:"Cambria","serif"">The HTTP URL of the Issuing CA’s OCSP responder  MAY be omitted provided that the Subscriber  “staples” OCSP responses for the Certificate in its TLS handshakes [RFC4366].</span></i><span style="font-size:11.0pt;font-family:"Cambria","serif""><o:p></o:p></span></p>
<p><span style="font-size:11.0pt;font-family:"Cambria","serif"">This results in an odd situation where a CA can issue a certificate without either a CRL or AIA if the customer promises to use OCSP stapling. A customer won’t serve a revoked certificate through
 its server, meaning the certificate can never be effectively revoked. Compare this to Appendix B of the EV Guidelines.<o:p></o:p></span></p>
<p><i><span style="font-size:11.0pt;font-family:"Cambria","serif"">(B) cRLDistributionPoint</span></i><span style="font-size:11.0pt;font-family:"Cambria","serif""><o:p></o:p></span></p>
<p><i><span style="font-size:11.0pt;font-family:"Cambria","serif"">This extension SHOULD be present and MUST NOT be marked critical.  If present, it MUST contain the HTTP URL of the CA‟s CRL service.  This extension MUST be present if the certificate does not
 specify OCSP responder locations in an authorityInformationAccess extension.  See Section  11 for details.</span></i><span style="font-size:11.0pt;font-family:"Cambria","serif""><o:p></o:p></span></p>
<p><i><span style="font-size:11.0pt;font-family:"Cambria","serif"">(C) authorityInformationAccess</span></i><span style="font-size:11.0pt;font-family:"Cambria","serif""><o:p></o:p></span></p>
<p><i><span style="font-size:11.0pt;font-family:"Cambria","serif"">This extension SHOULD be present and MUST NOT be marked critical.  If present, it MUST contain  the HTTP URL of the CA‟s OCSP responder (accessMethod = 1.3.6.1.5.5.7.48.1).</span></i><span style="font-size:11.0pt;font-family:"Cambria","serif""><o:p></o:p></span></p>
<p><i><span style="font-size:11.0pt;font-family:"Cambria","serif"">An HTTP URL MAY be included for the Subordinate CA‟s certificate (accessMethod = 1.3.6.1.5.5.7.48.2)</span></i><span style="font-size:11.0pt;font-family:"Cambria","serif""><o:p></o:p></span></p>
<p><i><span style="font-size:11.0pt;font-family:"Cambria","serif"">This extension MUST be present if the certificate does not contain a cRLDistributionPoint extension.  See Section 11 for details.</span></i><span style="font-size:11.0pt;font-family:"Cambria","serif""><o:p></o:p></span></p>
<p><span style="font-size:11.0pt;font-family:"Cambria","serif"">To accommodate short-lived certificates and remedy this loophole, I propose we modify the baseline requirements as follows:<o:p></o:p></span></p>
<p><u><span style="font-size:11.0pt;font-family:"Cambria","serif"">(new definition) Short Lived Certificates: A Certificate with an “Valid To” date that is seven or less days from the date of issuance and a “Valid From” date that is no more than seven days
 prior to the date of issuance.</span></u><span style="font-size:11.0pt;font-family:"Cambria","serif""><o:p></o:p></span></p>
<p><span style="font-size:11.0pt;font-family:"Cambria","serif"">13.1.5 Reasons for Revocation<o:p></o:p></span></p>
<p><u><span style="font-size:11.0pt;font-family:"Cambria","serif"">If one or more of the following reasons for revocation occurs, a CA SHALL, within 24 hours, (i) revoke all affected Certificates that contain a cRLDistributionPoint or an authorityInformationAccess
 extension and (ii) cease issuing Short Lived Certificates to the Subscriber until none of the reasons for revocation apply.<o:p></o:p></span></u></p>
<p><span style="font-size:11.0pt;font-family:"Cambria","serif"">13.2.2 Repository<o:p></o:p></span></p>
<p><span style="font-size:11.0pt;font-family:"Cambria","serif"">The CA SHALL maintain an online 24x7 Repository that application software can use to automatically check the current status of all unexpired Certificates<u> (except Short Lived Certificates)</u>
 issued by the CA. <u> The CA MAY include certificate status information for Short Lived Certificates in its Repository.</u><o:p></o:p></span></p>
<p><span style="font-size:11.0pt;font-family:"Cambria","serif"">Appendix B – Certificate Extensions (Normative)<o:p></o:p></span></p>
<p><b><span style="font-size:11.0pt;font-family:"Cambria","serif"">Subordinate CA Certificates<o:p></o:p></span></b></p>
<p><span style="font-size:11.0pt;font-family:"Cambria","serif"">B. cRLDistributionPoint<o:p></o:p></span></p>
<p><span style="font-size:11.0pt;font-family:"Cambria","serif"">This extension <u>
MUST</u> be present <u>and </u>MUST NOT be marked critical.  This extension MUST contain the  HTTP URL of the CA’s CRL service. <u>
</u><o:p></o:p></span></p>
<p><span style="font-size:11.0pt;font-family:"Cambria","serif"">C. authorityInformationAccess<o:p></o:p></span></p>
<p><span style="font-size:11.0pt;font-family:"Cambria","serif"">With the exception of stapling, which is noted below, this extension
<u>MAY</u> be present.  <u>If present, this extension </u>MUST NOT be  marked critical, and it MUST contain the HTTP URL of the Issuing CA’s OCSP responder (accessMethod  = 1.3.6.1.5.5.7.48.1).  It SHOULD also contain the HTTP URL of the Issuing CA’s certificate 
 (accessMethod = 1.3.6.1.5.5.7.48.2).  See Section 13.2.1 for details.  <o:p></o:p></span></p>
<p><b><span style="font-size:11.0pt;font-family:"Cambria","serif"">Subscriber Certificates<o:p></o:p></span></b></p>
<p><span style="font-size:11.0pt;font-family:"Cambria","serif"">B. cRLDistributionPoint<o:p></o:p></span></p>
<p><span style="font-size:11.0pt;font-family:"Cambria","serif"">This extension MAY be present.  If present, it MUST NOT be marked critical, and it MUST contain the  HTTP URL of the CA’s CRL service. <u> This extension MUST be present if the certificate does
 not specify OCSP responder locations in an authorityInformationAccess extension and the certificate is not a Short Lived Certificate. 
</u><o:p></o:p></span></p>
<p><span style="font-size:11.0pt;font-family:"Cambria","serif"">C. authorityInformationAccess<o:p></o:p></span></p>
<p><span style="font-size:11.0pt;font-family:"Cambria","serif"">With the exception of stapling, which is noted below,<u> Short Lived Certificates</u>, this extension MUST be present. <u> This extension MAY be present in Short Lived Certificates</u>. It MUST
 NOT be  marked critical, and it MUST contain the HTTP URL of the Issuing CA’s OCSP responder (accessMethod  = 1.3.6.1.5.5.7.48.1).  It SHOULD also contain the HTTP URL of the Issuing CA’s certificate  (accessMethod = 1.3.6.1.5.5.7.48.2).  See Section 13.2.1
 for details.  <o:p></o:p></span></p>
<p><span style="font-size:11.0pt;font-family:"Cambria","serif"">Jeremy<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif""><o:p> </o:p></span></p>
</div>
</div>
</body>
</html>