Jean-Marc Desperrier wrote, On 2009-01-30 03:25: > Paul Hoffman wrote: >> [...] >> That feels insufficient to me. I also disagree that there are >> "practical problems of revoking a very large number of certificates". >> The worst problem is that the CRL will grow; that's no big deal, it >> is supposed to grow. > > You *obviously* never had to handle this CRL : > http://onsitecrl.certplus.com/DIRECTIONGENERALEDESIMPOTSDIRECTIONGENERALEDESIMPOTSUSAGER/LatestCRL
Ah, yes, the proverbial 35 Megabyte CRL, which even at T1 speeds takes 3.5 minutes (211 seconds) to download. > Java programs just can't take it up. And J2EE is by far the most popular > application server architecture nowadays. 64 bits J2EE with an > enterprise level stability is not a reality today. Years ago, NSS used a general purpose BER/DER decoder everywhere. It was used to decode a single 35 MB CRL (from the DoD, as I recall), and IIRC it took 24 hours to decode it and used some large portion of a gigabyte of RAM to do so. The problem was that it allocated space for and copied the value of every component, and every subcomponent of every constructed (structured) member of the document. So, Julien wrote a new DER-only decoder that uses the same templates as the old decoder, specifically motivated to handle that whopping CRL. It does not make unnecessary copies. Today, NSS uses that "Quick DER Decoder" for anything that is DER encoded. I just ran it against that 35 MB CRL cited above. It took less than 2 seconds to parse the whole thing. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
