<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 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:12.0pt;
        font-family:"Times New Roman","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.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:12.0pt;
        font-family:"Times New Roman","serif";}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        mso-fareast-language:EN-US;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
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-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I disagree with Brian’s statements in favour of the removal of the requirement for a CRLDP in the short lived certificates proposed by ballot 153.<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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I think that the logic of his argument, like Adam Langley’s before him (https://www.imperialviolet.org/2011/03/18/revocation.html), is predicated on the belief that because boring old revocation[1] is not perfect it is therefore worthless and should be discarded.<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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>It is certainly not perfect, but neither is it worthless.<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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> A short-lived certificate is effectively just a way of <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> compressing the certificate and the OCSP response together <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> under one signature instead of two.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I disagree.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>A new OCSP response can be generated at any time during the life of a certificate indicating its revocation.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Whilst the short lifetime of the certificate may mean that a user who has already encountered the certificate and its associated OCSP response before the revocation event will have a cached ‘Valid’ (i.e. unrevoked) OCSP response for that certificate, a user who has not previously encountered the certificate will pick up a fresh OCSP response and will discover the certificate’s revocation.<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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> There In fact, because the maximum validity period of a <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> short-lived certificate is shorter than the maximum lifetime <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> of an OCSP response, short-lived certificates are actually <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> a *safer* form of revocation than a stapled OCSP response.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>No, it isn’t.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Firstly, they are not alternatives.  We are not considering the alternatives of a short lived certificate (exclusive) OR an OCSP response.  We are considering, given the premise of the ballot which is to have short lived certificates, whether there should also be an associated revocation status (OCSP or CRL).<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The short lifetime of the certificate, of course, limits the damage than can be done with it, but that damage can be limited further by its association with the existing revocation mechanisms.<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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> Note that a CA isn't required to include the AIA OCSP <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> responder URL in a certificate if the customer promises <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> to always staple an OCSP response. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>True, and although the BRs do permit what you describe that language in the BRs needs revising or removing.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>It should only be permitted with must-staple (rfc7633). The high-traffic case it considers should have additional security considerations if the revocation pointer is to be absent.<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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> A short-lived certificate is a way of enforcing that the <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> customer keep that promise. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>No, it isn’t.  Using must-staple (rfc7633) is a way of enforcing that the customer keep that promise.<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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> Note, in particular, that CAs were until this point not <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> required to support CRLs for end-entity certificates at all. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> This seems like a tremendous burden on CAs that are trying <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> to offer a *safer* and *more efficient* revocation mechanism.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Quite the contrary.  <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Supporting CRLs for short-lived end-entity certificates should be very straightforward.  <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The CRL will have zero entries in it during normal operation.  <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>It will therefore be very cheap to serve and quick to download.  <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The CA is likely to put an entry into this CRL only when a certificate has an ‘interesting’ (in the sense used for CRLsets) revocation reason of KeyCompromise, CACompromise or AACompromise.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Saving some effort to get a different result is not a definition of efficiency.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Omitting revocation checks is quicker, but not safer.<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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> Also note that it is critically important that certificate <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> chains get smaller due to the nature of the TCP and TLS <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> protocols, especially when combined with CT, which makes <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> them significantly larger. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>CT in certificate bodies is not the only fruit.  CT does not require certificate bloat – although presumably getting the SCT in a TLS extension doesn’t reduce the bytes over the wire any.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>But I smell the old point about initcwnd.  What % of deployed servers can't (and/or don't?) set the initcwnd?<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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> One of the main purposes of OCSP <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> stapling is to help make the certificate-related parts of <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> the TLS handshake more efficient in this respect, and the <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> requirement for adding the CRL DP extension, which is <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> relatively large, is counterproductive to this primary <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> purpose. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Really?  I thought the main purposes of OCSP stapling were:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>a) the privacy enhancement of not requiring the end user to hit the CA with a certificate-specific query from a client-specific IP address and<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>b) reduce the latency and (almost) guarantee the availability of the OCSP response to the end user because it is being provided on the same channel on which the encrypted site content is being downloaded.<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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> Note that changes in the size of certificates by just a <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> few bytes can often have a dramatic effect on the efficiency <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> of TLS, due to how TCP counts things in terms of packets.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Noted.  But surely the cost of the extra bytes in the certificate for the revocation service URI is dwarfed by the time cost of calling out to the URI.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Revocation status checking is expensive, which is why so many clients don’t bother.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Not checking it does not increase security, in my opinion.<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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> If people want this in order to support CRLSets/OneCRL/etc. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> then it would be better to find an efficient out-of-band <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> method for advertising the CRL URLs to support those out-<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> of-band revocation methods.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Finally we’re starting to reach something we might agree on.  When there’s a better way to get revocation status information out there then let’s use it, but let’s not throw the existing mechanisms away until there is a superior replacement for them.<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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Regards<br>Robin Alden<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Comodo<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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>[1] By ‘boring old revocation’ I mean revocation via a CRL fetched from a CRLDP or via an OCSP response fetched from an online responder, including sane caching of those responses.<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 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>Brian Smith<br><b>Sent:</b> 31 October 2015 19:44<br><b>To:</b> Jeremy Rowley<br><b>Cc:</b> public@cabforum.org<br><b>Subject:</b> [PROMO]Re: [cabfpub] Short-Lived Certificate Ballot<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><div><p class=MsoNormal>On Mon, Oct 26, 2015 at 11:38 AM, Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>> wrote:<o:p></o:p></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif";color:black'>b. cRLDistributionPoints This extension <u>MUST be present for Short-Lived Certificates that lack an authorityInformationAccess extension and</u> MAY be present for all other certificates. 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><o:p></o:p></p></div><p class=MsoNormal><br>This requirement for the CRLDistributionPoints extension should be removed before voting starts. I read the summary of the discussion at <a href="https://cabforum.org/2015/10/07/2015-10-07-face-to-face-meeting-minutes-meeting-36-istanbul/#Short-Lived-Certificates">https://cabforum.org/2015/10/07/2015-10-07-face-to-face-meeting-minutes-meeting-36-istanbul/#Short-Lived-Certificates</a> but I think that the decision was made based on flawed reasoning:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>"T<span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#333333'>here has been opposition to having certificates with no revocation." Sorry if I've overlooked something, but based on my reading of all the discussion on the matter, that opposition seems to be without technical merit. A short-lived certificate is effectively just a way of compressing the certificate and the OCSP response together under one signature instead of two. There In fact, because the maximum validity period of a short-lived certificate is shorter than the maximum lifetime of an OCSP response, short-lived certificates are actually a *safer* form of revocation than a stapled OCSP response. Note that a CA isn't required to include the AIA OCSP responder URL in a certificate if the customer promises to always staple an OCSP response. A short-lived certificate is a way of enforcing that the customer keep that promise. Thus, again, short-lived certificates are technically safer than OCSP.</span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#333333'>"This supports Microsoft’s policy which requires every certificates to have either/or CRL or OCSP information." This is a chicken-and-egg problem. We should be optimistic that Microsoft will improve its policy to account for short-lived certificates. Also, the Baseline Requirements are already more liberal than Microsoft's policy: "</span>With the exception of stapling, which is noted below, [the authorityInformationAccess extensino] MUST be present."<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-family:"Arial","sans-serif";color:#333333'>Note, in particular, that CAs were until this point not required to support CRLs for end-entity certificates at all. This seems like a tremendous burden on CAs that are trying to offer a *safer* and *more efficient* revocation mechanism.</span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-family:"Arial","sans-serif";color:#333333'>Also note that it is critically important that certificate chains get smaller due to the nature of the TCP and TLS protocols, especially when combined with CT, which makes them significantly larger. One of the main purposes of OCSP stapling is to help make the certificate-related parts of the TLS handshake more efficient in this respect, and the requirement for adding the CRL DP extension, which is relatively large, is counterproductive to this primary purpose. Note that changes in the size of certificates by just a few bytes can often have a dramatic effect on the efficiency of TLS, due to how TCP counts things in terms of packets.</span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-family:"Arial","sans-serif";color:#333333'>If people want this in order to support CRLSets/OneCRL/etc. then it would be better to find an efficient out-of-band method for advertising the CRL URLs to suppor those out-of-band revocation methods.</span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>So, again, please remove this requirement (b).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-family:"Arial","sans-serif";color:#333333'>Thanks,</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-family:"Arial","sans-serif";color:#333333'>Brian<br></span>-- <o:p></o:p></p><div><div><div><div><div><div><div><p class=MsoNormal><a href="https://briansmith.org/" target="_blank">https://briansmith.org/</a><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div></div></div></div></div></div></div></div></div></div></body></html>