[cabfpub] Ballot 153 – Short-Lived Certificates

[kirk_hall at trendmicro.com]

Trend Micro opposes Ballot 153 – Short-Lived Certificates for the following reasons.  The ballot is a major step backward for user security.

1. Revocation checking via OCSP is important for all certificates, including Short-Lived Certificates.  While users who visit a site before a certificate is revoked will cache the “good” OCSP response and will not receive an OCSP update for up to 10 days under BR 4.9.10, all other users who visit the site after revocation will be notified “revoked” by OCSP until the certificate expires – so potentially many users will be protected.  This is essential for internet security, even for a 4-day certificate (many phishers and fraudsters get their greatest use from a certificate during the first 48 hours after issuance).  This same user protection will not occur with only CRLs for Short-Lived Certificates, as explained below.
2. The Forum has continuously been improving revocation checking over the past four years, moving from revocation checking via CRL to OCSP, and it would be a security mistake to go backwards now.  Version 1 of the Baseline Requirements in 2011 covered OCSP requirements for end-entity certificates.  In later ballots the Forum required support of OCSP checking using the GET method for all end-entity certificates, required that CAs not provide a “good” response to unknown certificates, and also required CAs to provide OCSP responses for the issuing sub-CA.  CAs have spent a lot of money setting up robust OCSP responders to comply.  All this was intended to improve user security, but Ballot 153 would move us back in time to less-secure CRLs, which is a bad idea.

3.  The Diginotar case emphasized the necessity of using OCSP revocation checking and not CRLs.  A CRL only lists certificates that have been revoked, but cannot tell a user if a certificate is “good” or “unknown”.  Because Diginotar’s issuance logs were erased, Diginotar could never know what bad certificates had been issued, and so could never list them on a CRL as revoked.  In contrast, with OCSP a CA must respond “good”, “revoked”, or “unknown” – this extra information is crucial for protecting users when CA logs have been lost or compromised.  We are requiring all EV certs to be CT logged for user protection – we should also require all CAs to provide a “good” response via OCSP when a user is checking for revocation.

4.  Here is the most compelling argument against Ballot 153.  CRLs are issued to cover all end-entity certificates that are issued and then later revoked by a single issuing sub-CA, and many CAs only use a single sub-CA to issue all certificates to all FQDNs owned by all customers around the world.

Under BR 4.9.7 the value of a nextUpdate field in a CRL is up to 10 days – so if a user visits *any* website secured by a certificate issued by a particular CA and downloads the related CRL, that user will not receive any updated revocation information for *any other* website secured by a certificate from that same CA for a full 10 days.

In other words, by visiting one secured FQDN and downloading that CA’s CRL for the issuing sub-CA, the user is effectively *blocked* from receiving *ANY* further revocation information from that CA for any other FQDN owned by any customer for 10 days – even though the user is visiting other secured websites and FQDNs around the world.  They will get no new revocation information.

As an example, if Let’s Encrypt, or DigiCert, or Trend Micro, begins issuing thousands of Short-Lived Certificates each day to thousands of different customers, and if any particular user visits any of those websites once and pulls down the issuing CA’s CRL, that user will *never* receive any further revocation information from that CA as to any site owned by any other party secured by a Short-Lived Certificate for another 10 days.  The user might think revocation checking is occurring by CRL, but it is not.

Also, as we understand it, some browsers no longer do revocation checking by CRL, so even if the user downloads the current CRL for a Short-Lived Certificate and the CRL shows the certificate has been revoked, the browser will not report that to the user.

In contrast, with OCSP revocation checking each Short-Lived Certificate has a unique Serial Number, and each visit by a user to each site secured by a Short-Lived Certificate will generate a new OCSP revocation checking response from the issuing CA for that particular site (certificate) based on the Short-Lived Certificate’s unique Serial Number.  This is very effective revocation checking, and represents good security for users.  A visit to 100 FQDNs secured by Short-Lived Certificates from the same CA will result in 100 individual OCSP responses – much better user security than CRL.

5.  So far as we can tell, the only reason for Ballot 153 is so CAs can stop providing OCSP revocation information for Short-Lived Certificates and thereby save money – there are no security advantages and no benefits to users.  This is not a good reason to degrade user security.  Because of the problems with CRLs listed above, switching to CRLs effectively kills revocation checking for Short-Lived Certificates.

6.  The Forum has come so far in improving internet security over the past few years, it would be a great mistake to go backward now from OCSP revocation checking (with a fresh query for each new certificate encountered) to CRLs (which will only download a fresh CRL once every 10 days for all certificates issued to all customers by an issuing CA).

We will vote “no” on Ballot 153 for all these reasons.


<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151030/44fd796d/attachment.html