On Thursday, September 1, 2016 at 5:30:28 AM UTC-7, Erwann Abalea wrote: > The whitelist for EV logged before 01/01/15 contained around 180k > certificates, each one identified by a 64bits digest, the list was compressed > in order to gain 25%, the result was an object slightly larger than 1MB. > Today, this list contains around 110k certificates, and it's less than 680KB.
Note: The EV whitelist uses a probablistic structure that Google was comfortable with when determining EV, since it would also have needed to have the EV policy OIDs, and thus unlikely to be "gamed," but when considering trust, is unacceptably high in the false-positive case when considering a CA that may not be trustworthy. For example, the CNNIC whitelist, as implemented by both Chrome and Firefox, uses the full 32-byte hashes. If we accept 110K (for your number), that's 3.5 megs (uncompressed). If we accept Peter's estimate, that's 6.3 megs (uncompressed). If we accept the full 230K Richard posted, that's 6.4 megs (uncompressed). We should probably fork off to the other thread if we're going to consider to discuss whitelist technical solutions, if there is community interest, and we can discuss the various concerns and tradeoffs between probablistic data structures (such as Golomb coded sets like the EV whitelist uses, Bloom filters as was proposed elsewhere in the past, and other forms of compression), as well as run concrete analysis of various implementations. As of yet, there doesn't seem to be a good inline solution that adequately reflects the facts surrounding it, if a whitelist is determined to be suitable. - Date based retroactive trust is impaired by known backdating - Full whitelists are insufficiently large - Probabablistic whitelists can be gamed with false positives (And I'm actively factoring in the CPU cost involved with signing as part of this threat model, assuming both "worst case" and "reasonable case") - Online lookups have privacy flaws (same as OCSP) I say "SafeBrowsing-like", but for sake of the PKIX familiar, it might otherwise be rephrased as "shared certificate *Trust* lists with issuerDistributionPoints", which is effectively the same thing :) _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
