| Oh, I wasn't thinking about having this be a perfect oracle; just a better and smaller first pass (edit:) for CRL, not for OCSP. I got the idea from Squid and the network of caches.[1] That body of experience may be helpful. For shrinking the size, RLE might work (most entries would be 0), and rsync may reduce bandwidth. It looks like the Squid network just used http requests for refreshes. There's probably a sweet spot for bandwidth, and I'd guess that 90-99% would work fine; you're balancing the size of the continually updated bloom filter vs. the requests for certificates that match it. I didn't worry about false positives, because it could just send an OCSP query in that case. Your numbers for revocations sounded very low, but I just used crlset-tools[2] and checked, and it's about right. Which is weird, because someone else[3] mentioned a size of "4.107Kb" at version 1567, but that's somehow different - compression, perhaps. I thought I'd heard about CRLs megabytes long, but Google Chrome seems heavily curated re: CRLs. I'd hash over signatures instead of the oft-predictable serial numbers, as you noted. [1] http://wiki.squid-cache.org/SquidFaq/CacheDigests [2] https://github.com/agl/crlset-tools [3] https://scotthelme.co.uk/certificate-revocation-google-chrom... |