[cabfpub] Ballot 153 – Short-Lived Certificates
sleevi at google.com
Fri Oct 30 11:07:34 MST 2015
Thanks for your public reply to the ballot. While it appears that
TrendMicro will not be convinced otherwise, I think some of the points you
raise (and have raised for some time) deserve addressing on the public
list, just as they've been repeatedly addressed on past calls and F2F.
On Fri, Oct 30, 2015 at 10:35 AM, kirk_hall at trendmicro.com <
kirk_hall at trendmicro.com> wrote:
> 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.
This, of course, presumes that the attacker will neither use
a) OCSP stapling as a means to disable clients OCSP behaviour
b) Network-level attacks to disrupt or replay past 'Good' OCSP responses.
In a realistic threat model (e.g. common browsers, common servers), both a)
and b) are particularly relevant and applicable.
Since you raise Diginotar as an example for the necessity, it is worth
pointing out that option b) could easily have been leveraged by the
attackers, and almost certainly would be by any future attackers.
> 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.
All of the above-mentioned improvements are equally valid (and arguably
beneficial) for OCSP stapling, which is wholly independent.
These arguments are arguably against CRLs entirely - except that the Forum
already permits CRLs to be used for subscriber certificates. I can
understand if you don't want to see the 'furtherance' of CRL use, but it's
useful to examine that in a 'threat model', this cow has already left the
> 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
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.
This is not factually/technically correct. CRLs can be segmented, and
indeed, many CAs do.
If you're not familiar with this mechanism, RFC 5280, Section 5.2.5 can
provide more details.
The failure of CAs to use this method has, among other things, contributed
to why browsers prefer not to check CRLs.
> 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.
Rather than attempt to dispel the incorrect assumptions here, I think it
may be more useful to simply point to the empirical research side and hope
you can see how it applies and disputes these claims:
> 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.
This is, of course, not the only reason for Ballot 153, as has been
repeatedly and extensively discussed, and as reflected in multiple meetings
minutes. The numerous security advantages have been repeatedly explained to
you and the Forum, including lengthy discussion about key compromise events.
While I can appreciate that you may disagree with these benefits, or that
you may not appreciate the significance they represent to site operators,
it's not correct to suggest there are no security advantages.
Further, the lengthy discussions of benefits to users, and the practical
ways in which short lived certificates enable more sites to be protected by
TLS, offering direct privacy and security benefits to users, are also
seemingly being dismissed.
Rather than rehash this conversation in full, I think it's simply
worthwhile to highlight that there's quite a bit of evidence counter to
If you would like to further understand the motivations for, and benefits
from, Ballot 153, I would refer you to the minutes of our most recent F2F
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public