3 ms·
Currently only 20,830,034 revoked certificates per my daily CRL download, versus ~1 billion active certificates. But the number of revoked certs could balloon
by agwa 2y ago
Currently only 20,830,034 revoked certificates per my daily CRL download, versus ~1 billion active certificates. But the number of revoked certs could balloon if there's another Heartbleed-like event, or a mass misissuance.
- mintplant 2y agoSo are embedded devices just expected to not check for certificate revocation?
- BertoldVdb 2y agoIf you can tolerate some level of false positives you can turn the CRL into a bloom filter and save quite a bit of storage.
- kibwen 2y agoI don't think this comment deserves to be downvoted. For the specific constraints imposed by embedded environments, a bloom filter seems perfectly cromulent here. The odds of a false positive scale according to the amount of memory that you can afford, and even in the event of a false positive it would fail closed, which is a better security posture than not checking at all.
- less_less 2y agoDepends how embedded and how many servers it's talking to. I'm also not sure you can really tolerate false positives, since the main domain you talk to might get revoked, but there are alternatives to Bloom filters that eliminate those. In any case it's going to be hard to go below about 0.8-1 byte per revoked cert (common case where most certs aren't revoked) even with a fancy data structure. You will surely want to shard the CRL, so if the device only accesses a few servers (and thus only has a few shards) then it'll be fine, but if it accesses many servers then there will be trouble, and you'll want to reserve extra space in case of a mass revocation.