<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 26, 2015 at 11:38 AM, Jeremy Rowley <span dir="ltr"><<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:Arial,sans-serif;color:black">b. cRLDistributionPoints This extension<span> </span><span><u>MUST be present for <span class="">Short</span>-<span class="">Lived</span> <span class="">Certificates</span> that lack an authorityInformationAccess extension and</u></span><span> </span>MAY
be present for all other <span class="">certificates</span>. 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></blockquote></div><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:</div><div class="gmail_extra"><br></div><div class="gmail_extra">"T<span style="color:rgb(51,51,51);font-family:'Droid Sans',Arial,Verdana,sans-serif;font-size:13px;line-height:11.1429px">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. </span><span style="font-size:13px;color:rgb(51,51,51);font-family:'Droid Sans',Arial,Verdana,sans-serif;line-height:11.1429px">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. </span><span style="font-size:13px;color:rgb(51,51,51);font-family:'Droid Sans',Arial,Verdana,sans-serif;line-height:11.1429px">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></div><div class="gmail_extra"><span style="font-size:13px;color:rgb(51,51,51);font-family:'Droid Sans',Arial,Verdana,sans-serif;line-height:11.1429px"><br></span></div><div class="gmail_extra"><span style="font-size:13px;color:rgb(51,51,51);font-family:'Droid Sans',Arial,Verdana,sans-serif;line-height:11.1429px">"</span><span style="color:rgb(51,51,51);font-family:'Droid Sans',Arial,Verdana,sans-serif;font-size:13px;line-height:11.1429px">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."</div><div class="gmail_extra"><font color="#333333" face="Droid Sans, Arial, Verdana, sans-serif"><span style="line-height:11.1429px"><br></span></font></div><div class="gmail_extra"><font color="#333333" face="Droid Sans, Arial, Verdana, sans-serif"><span style="line-height:11.1429px">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></font></div><div class="gmail_extra"><font color="#333333" face="Droid Sans, Arial, Verdana, sans-serif"><span style="line-height:11.1429px"><br></span></font></div><div class="gmail_extra"><font color="#333333" face="Droid Sans, Arial, Verdana, sans-serif"><span style="line-height:11.1429px">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></font></div><div class="gmail_extra"><font color="#333333" face="Droid Sans, Arial, Verdana, sans-serif"><span style="line-height:11.1429px"><br></span></font></div><div class="gmail_extra"><font color="#333333" face="Droid Sans, Arial, Verdana, sans-serif"><span style="line-height:11.1429px">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></font></div><div class="gmail_extra"><font color="#333333" face="Droid Sans, Arial, Verdana, sans-serif"><span style="line-height:11.1429px"><br></span></font></div><div class="gmail_extra">So, again, please remove this requirement (b).</div><div class="gmail_extra"><br></div><div class="gmail_extra"><font color="#333333" face="Droid Sans, Arial, Verdana, sans-serif"><span style="line-height:11.1429px">Thanks,</span></font></div><div class="gmail_extra"><font color="#333333" face="Droid Sans, Arial, Verdana, sans-serif"><span style="line-height:11.1429px">Brian<br></span></font>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><a href="https://briansmith.org/" target="_blank">https://briansmith.org/</a></div><div><br></div></div></div></div></div></div></div>
</div></div>