Hacker News new | past | comments | ask | show | jobs | submit login

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

Does anyone know what the rate of revocations is?

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 "proprietary, browser-specific CRLs". Moreover there are non-browser clients which we must consider if we are to take this proposal seriously.

------

My quick back of the envelope estimation:

CRL size: 4GiB (they say in the article that it could be easily the size of a movie)

Average Cert Size: 75 bytes (first hit in Google, no idea if reliable number)

Time Span: 825 days (CRLs have only unexpired certs and ones older than 825 should all be expired)

4GiB/(75B/cert)/825days = 69141 certs/day

Sounds way too high to me. Where am I wrong?




In the CRLite paper [1] the bandwidth cost was estimated to be ~600 KB per day. Most crucially they do not directly store certificates but only boolean flags for hashes of virtually all once-valid certificates in existence. This is made possible because of Certificate Transparency; once the signature has been verified there can be only so many hashes to check.

[1] https://obj.umiacs.umd.edu/papers_for_stories/crlite_oakland...




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: