It actually gets even better: Mozilla's CRLite deltas with generation on a 6-hour interval are only about 60kB! Even with 10 billion internet devices fetching every 6 hours you're looking at a mere 222Gbps of bandwidth: a lot, but plenty of tech companies do more.

> At this point, why not just use DANE (RFC 6698), store the public keys in the DNS, rely on DNSSEC to provide the necessary authenticity, and use DNS TTL settings to control the cached lifetime of the public key? With a combination of DNSSEC Chain Extensions and DNSSEC stapling, it is possible to perform a security association handshake by having the server provide the client with (...)

Yeah, until an attacker gets access to DNS, stores a record with a TTL of 1 year, and staples that - of course after poisoning the caches of major DNS resolvers with the address of the attacker's server.

Interests of the existing PKI industry may be the source of some friction, but the bigger issue is that DANE depends on DNSSEC, which is not widely deployed, and sometimes actively avoided due to its complexity and ease of breaking you site.

Don't get me wrong, I'd love it if DANE, or something similar caught on, but I don't think it is practical until something changes to make DNSSEC (or equivalent) common.

To ensure that RLs would always be manageable in size, we used distribution points (cRL and issuing) and decided at certificate issuance which RL would contain this certificate's serial number if ever it were revoked.

This approach scaled really well and kept RLs manageable.

There were applications that didn’t understand distribution points and needed the One RL to Revoke Them All, so we supported that as well (as an option, IIRC).