I was kind of surprised that OCSP stapling didn't get any mention at all. I thought that was a major improvement in both resource cost and privacy? Since the time stamped response is proxied by the site operator rather then going directly to the CA, the load is almost entirely switched to the site itself, and the site itself is the only one who knows a given IP is asking for it, which is fine because obviously the site knows a given browser is connecting to it anyway. It's decentralized again. I vaguely remember at one point there was a major limitation of only supporting a single OCSP response at a time but I thought that was dealt with via a later RFC and then entirely obviated as an issue by TLS 1.3.<p>Did something happen there or some other significant issue get discovered? I'm curious why the move back to CRLs (albeit improved) vs must-staple. It seemed like a reasonable elegant and straight forward solution that fit the web pretty well.
> If we had an incident where we needed to revoke every single one of those certificates at the same time, the resulting CRL would be over 8 gigabytes.<p>I don't know much about this stuff, so apologies if this is a silly question:<p>If you needed to revoke all the certificates, couldn't you just revoke the handful of intermediary certificates and call it a day? I assume you'd want to revoke them anyways if there's a situation severe enough that merits revoking 200 million certificates.
> This means that they’re often very large – easily the size of a whole movie.<p>Couldn't they just use actual units? This says absolutely nothing.
Browsers and CAs still deciding for the user what's best with yet another centralized database that we have to "trust" is complete and implemented correctly. I don't see how this is so hard: just let us download the CRLs. Maybe add them on a torrent-like system so they can be shared (and validated) peer-to-peer, or at least have hundreds or thousands of mirrors that can provide that data. All this "it's too big and the user would have to download it" bullshit is just pushing us more and more into "computing as a service"; aka: we OWN your digital life.<p>Edit: I was partly wrong, this is a good thing because you CAN download the CRLs now (see comments below here for info), whereas previously you couldn't. Your browser still probably won't support a full CRL download, but I could be pleasantly surprised.
> <i>"They process the CRLs into a smaller format such as a Bloom filter, then push the new compressed object to all of the installed browser instances using pre-existing rapid update mechanisms. Firefox, for example, is pushing updates as quickly as every 6 hours."</i><p>Does anyone know what the rate of revocations is?<p>I can easily imagine a situation where it is high enough to cause a browser update every few hours. That is for every installed browser, because - as they say in the article - Browser-Summarized CRLs are <i>"proprietary, browser-specific CRLs"</i>. Moreover there are non-browser clients which we must consider if we are to take this proposal seriously.<p>------<p>My quick back of the envelope estimation:<p>CRL size: 4GiB (they say in the article that it could be easily the size of a movie)<p>Average Cert Size: 75 bytes (first hit in Google, no idea if reliable number)<p>Time Span: 825 days (CRLs have only unexpired certs and ones older than 825 should all be expired)<p>4GiB/(75B/cert)/825days = 69141 certs/day<p>Sounds way too high to me. Where am I wrong?
> There’s still a long way to go before revocation in the Web PKI is truly fixed.<p>It won't be fixed until we have name constraints on CA certificates, and a way to decorate trust anchors with local policy name constraints.
Lots of this information is completely bogus.<p>> But because OCSP infrastructure has to be running constantly and can suffer downtime just like any other web service, most browsers treat getting no response at all as equivalent to getting a “not revoked” response. This means that attackers can prevent you from discovering that a certificate has been revoked simply by blocking all of your requests for OCSP information.<p>This is false. Non-nonce OCSP is inherently cachable, and replayable. That means you can have your own HA setups with HA OCSP clients talking to HA OCSP servers (repeaters & responders) backed up by caching in commercial CDNs, and local caching servers like bluecoats.<p>Likewise, OCSP stapling helps remove much of the performance and privacy issues, pushing it to the serving webserver.<p>Beyond this, you can just use squid or localized HA OCSP services, and do some DNS rewriting to support it even more HA.<p>Nonced OCSP is the rare beast that needs to be online, but there are HA OCSP with smart OCSP clients.<p>> To help reduce load on a CA’s OCSP services, OCSP responses are valid and can be cached for about a week. But this means that clients don’t retrieve updates very frequently, and often continue to trust certificates for a week after they’re revoked.<p>Trust Stores are inherently manageable. The lag around revocation completely depends on CRL/OCSP publishing, and client update requests.<p>> And perhaps worst of all: because your browser makes an OCSP request for every website you visit, a malicious (or legally compelled) CA could track your browsing behavior by keeping track of what sites you request OCSP for.<p>This is why we advocate OCSP Stapling and use of CDNs for OCSP & CRL cache hits. Furthermore, localized OCSP mentioned above decentralizes this even further.<p>> So both of the existing solutions don’t really work: CRLs are so inefficient that most browsers don’t check them, and OCSP is so unreliable that most browsers don’t check it. We need something better.<p>CRLs & OCSP work pretty well when actually supported.<p>When Diginotar happened I polled every single publicly available commercial CA - strangely, a ton of them were not producing any CRL/OCSP at all, putting clients into a fail-open mode.<p>Lesson of the story: don't blame a protocol for lazy CAs, bad implementations, or the lack of operational excellence from many vendors.