[cabfpub] Short-Lived Certificate Ballot

Brian Smith brian at briansmith.org
Sat Oct 31 12:44:27 MST 2015

On Mon, Oct 26, 2015 at 11:38 AM, Jeremy Rowley <jeremy.rowley at digicert.com>

> b. cRLDistributionPoints This extension *MUST be present for Short-Lived
> Certificates that lack an authorityInformationAccess extension and* 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.

This requirement for the CRLDistributionPoints extension should be removed
before voting starts. I read the summary of the discussion at
but I think that the decision was made based on flawed reasoning:

"There 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.

"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: "With the exception of stapling, which is
noted below, [the authorityInformationAccess extensino] MUST be present."

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.

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.

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.

So, again, please remove this requirement (b).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151031/dc473e59/attachment.html 

More information about the Public mailing list