On Tue, Feb 7, 2012 at 12:07 PM, Ralph Holz <[email protected]> wrote:
> What is the point in disabling OCSP, then? Chrome could always use its > own revocation database as a primary reference, and use OCSP > additionally if there is no hit. I like that Chrome pulls revocations > via the update mechanism, but this does not sound very scalable - where > do you draw the line? Do you have data how many CRL entries come with a > reason (those are preferred by Chrome). I made some small statistics about the certificate revocation reasons in December: http://www.foo.be/cgi-bin/wiki.pl/2011-12-17_Certificate_Revocation_Reasons_2011 1153606 certificates were revoked with a reason (December 2011) 678039 Cessation Of Operation (code 5) 172888 Unspecified (code 0) 89823 Certificate Hold (code 6) 88788 Superseded (code 4) 76445 Key Compromise (code 1) 43482 Affiliation Changed (code 3) 3910 Privilege Withdrawn (code 9) 230 CA Compromise (code 2) 1 A A Compromise (code 10) Looking at the software provided by Google to fetch[1] their current "CRL" bundle (CRLSet version 94), I have the following results (assuming that the format is somehow a revoked serial number per line): $ ./crlset dump crl-set | wc -l 1656 Maybe they use a bloomfilter-like format or something like that. But it seems that their current bundle is not matching the numbers of the revoked certificate especially the ones with a reason. Information about the Google CRLSet format is welcome. adulau [1] https://github.com/agl/crlset-tools -- -- Alexandre Dulaunoy (adulau) -- http://www.foo.be/ -- http://www.foo.be/cgi-bin/wiki.pl/Diary -- "Knowledge can create problems, it is not through ignorance -- that we can solve them" Isaac Asimov _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
