[cabfpub] Short-Lived Certificate Ballot

Mon Nov 2 17:48:04 UTC 2015

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.

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.

It is certainly not perfect, but neither is it worthless.

> A short-lived certificate is effectively just a way of 

> compressing the certificate and the OCSP response together 

> under one signature instead of two.

I disagree.

A new OCSP response can be generated at any time during the life of a certificate indicating its revocation.

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.

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

No, it isn’t.

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).

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.

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

True, and although the BRs do permit what you describe that language in the BRs needs revising or removing.

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.

> A short-lived certificate is a way of enforcing that the 

> customer keep that promise. 

No, it isn’t.  Using must-staple (rfc7633) is a way of enforcing that the customer keep that promise.

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

Quite the contrary.  

Supporting CRLs for short-lived end-entity certificates should be very straightforward.  

The CRL will have zero entries in it during normal operation.  

It will therefore be very cheap to serve and quick to download.  

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.

Saving some effort to get a different result is not a definition of efficiency.

Omitting revocation checks is quicker, but not safer.

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

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.

But I smell the old point about initcwnd.  What % of deployed servers can't (and/or don't?) set the initcwnd?

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

Really?  I thought the main purposes of OCSP stapling were:

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

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.

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

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.

Revocation status checking is expensive, which is why so many clients don’t bother.

Not checking it does not increase security, in my opinion.

> 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 support those out-

> of-band revocation methods.

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.

Regards
Robin Alden

Comodo

[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.

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Brian Smith
Sent: 31 October 2015 19:44
To: Jeremy Rowley
Cc: public at cabforum.org
Subject: [PROMO]Re: [cabfpub] Short-Lived Certificate Ballot

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

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 https://cabforum.org/2015/10/07/2015-10-07-face-to-face-meeting-minutes-meeting-36-istanbul/#Short-Lived-Certificates 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).

Thanks,

Brian
-- 

https://briansmith.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151102/0e702238/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5156 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151102/0e702238/attachment.p7s>