Re: CRL parsing, in C
Thanks. You've been most helpful. One thing about the import of CRLs in the cert DB: how big can the cert DB get? I looks like the cert DB will keep growing without bounds, as long as new CRLs are added to it. Moreover, deleting a CRL from the cert DB does not reduce the DB's size! Finally, at one time, importing large CRLs caused a corruption of the cert DB: Have all the problems related to this issue been fixed as of NSS 3.4 (I'm currently using NSS 3.4.2)? Are there any outstanding problems concerning the import of CRLs in the cert DB? -- POC
RE: CRL parsing, in C
Thanks. I assume I don't need to first import the CRL in the NSS cert DB before using the CERT_DecodeDERCRLWithFlags function; all I need to provide are the CRL raw bytes (e.g., read from a file), correct? Also, it looks like I need to use the CERT_CompleteCRLDecodeEntries function to actually get to the list of revoked certs. If I did first import the CRL in the NSS cert DB (e.g., using crlutil), how much of a performance hit would I take when reading the CRL back out for parsing, versus decoding CRL straight from a file? I assume the crlutil tool uses your improved CRL decoding function when importing. Where does NSS do the actual checking of a CRL for the revocation status of a particular certificate? -- POC -Original Message- From: Julien Pierre [mailto:jpierre;com.netscape.netscape.com] Sent: Tuesday, October 29, 2002 5:51 PM To: [EMAIL PROTECTED] Subject: Re: CRL parsing, in C Patrick, POC wrote: Does mozilla have a API I could use to parse through a CRL? I'm currently using Sun's CertificateFactory and calling the generateCRL() method but I find it very slow when dealing with large CRLs 1 MB...Moreover if I build a list of such CRL objects, my JVM runs out of memory! I'm ready to try a C API.. I looked at the NSS command crlutil, but that tool is geared around the CRL being first imported in the NSS cert DB. -- POC The recently-released NSS 3.6 contains improved CRL decoding. The function you want to look at is called CERT_DecodeDERCRLWithFlags . One of its current limitations is that it can only deal with full CRLs. Delta CRLs, or CRLs containing issuing distribution point extensions, or freshest CRL extensions, currently cannot be decoded with this API. It is likely that this extra functionality will only become available in NSS 4.0. The additional work is not scheduled for the next version of NSS, which is NSS 3.7 . If it is acceptable to you to decode only full CRLs, then the C API should meet your performance need. To give you an idea of how fast the decoding the NSS CRL decoding API has become in NSS 3.6, it is now capable of decoding a 26 MB CRL containing 1.2 million revoked certificate entries in under 8 seconds on a low-end 440 MHz Ultrasparc II machine. This is about 6 times as fast as in previous versions of NSS. It also needs about 1/4 as much RAM as before to do the decoding - which is still an additional 35 MB of memory, on top of the 26 MB DER source CRL. Both improvements are the result of a new ASN.1 DER decoder I wrote for NSS 3.6, called the QuickDER decoder (see SEC_QuickDERDecodeItem if you are interested). Documentation on that new decoder - as well as on the old, less efficient SEC_ASN1DecodeItem - will be written in upcoming months. But you don't need to use the ASN.1/DER decoder directly to decode a CRL. The cert.h header file should contain sufficient documentation on how to call CERT_DecodeDERCRLWithFlags .
Re: CRL parsing, in C
microseconds on the 2.2 GHz Xeon CPU system I'm using to type this. To be able to take advantage of the performance improvements from the CRL cache, you need to use the NSS certificate verification functions mentioned above, and the CRL must be present in a PKCS#11 token. It should be noted that the official PKCS#11 specification doesn't currently include CRLs. We (Netscape) defined extensions to support this. Only the NSS certificate database (softoken) and some other internal Netscape proprietary PKCS#11 modules currently support these PKCS#11 CRL extensions. So at this time, your only option is to import your CRL to the database. The crlutil tool will allow you to do that. You can then start your NSS application against that database containing the CRL, and simply call the certificate verification functions. The CRL check will be automatically performed. The first time you verify a certificate from your CA, NSS will transparently read the CRL from the database, decode it, and put it in the cache along with the hash table. So your first verification will take a long time. Subsequent certificate verifications however will be very short. The 50 microseconds revocation check time is actually negligible compared to the rest of the certificate verification. With a cerificate containing a 1024 bit RSA key, the signature verification will take over 500 microseconds. With a 2048 bit key it will be much longer. So basically the CRL check will be invisible overhead after your first verification. Note that in versions of NSS before 3.6 that didn't have the CRL cache, the CRL was pulled from the tokens, decoded, and freed, for every certificate verification. Needless to say, the performance with that method was not impressive and this is why the CRL cache was added. -- POC -Original Message- From: Julien Pierre [mailto:jpierre;com.netscape.netscape.com] Sent: Tuesday, October 29, 2002 5:51 PM To: [EMAIL PROTECTED] Subject: Re: CRL parsing, in C Patrick, POC wrote: Does mozilla have a API I could use to parse through a CRL? I'm currently using Sun's CertificateFactory and calling the generateCRL() method but I find it very slow when dealing with large CRLs 1 MB...Moreover if I build a list of such CRL objects, my JVM runs out of memory! I'm ready to try a C API.. I looked at the NSS command crlutil, but that tool is geared around the CRL being first imported in the NSS cert DB. -- POC The recently-released NSS 3.6 contains improved CRL decoding. The function you want to look at is called CERT_DecodeDERCRLWithFlags . One of its current limitations is that it can only deal with full CRLs. Delta CRLs, or CRLs containing issuing distribution point extensions, or freshest CRL extensions, currently cannot be decoded with this API. It is likely that this extra functionality will only become available in NSS 4.0. The additional work is not scheduled for the next version of NSS, which is NSS 3.7 . If it is acceptable to you to decode only full CRLs, then the C API should meet your performance need. To give you an idea of how fast the decoding the NSS CRL decoding API has become in NSS 3.6, it is now capable of decoding a 26 MB CRL containing 1.2 million revoked certificate entries in under 8 seconds on a low-end 440 MHz Ultrasparc II machine. This is about 6 times as fast as in previous versions of NSS. It also needs about 1/4 as much RAM as before to do the decoding - which is still an additional 35 MB of memory, on top of the 26 MB DER source CRL. Both improvements are the result of a new ASN.1 DER decoder I wrote for NSS 3.6, called the QuickDER decoder (see SEC_QuickDERDecodeItem if you are interested). Documentation on that new decoder - as well as on the old, less efficient SEC_ASN1DecodeItem - will be written in upcoming months. But you don't need to use the ASN.1/DER decoder directly to decode a CRL. The cert.h header file should contain sufficient documentation on how to call CERT_DecodeDERCRLWithFlags .
Re: CRL parsing, in C
Patrick, POC wrote: Does mozilla have a API I could use to parse through a CRL? I'm currently using Sun's CertificateFactory and calling the generateCRL() method but I find it very slow when dealing with large CRLs 1 MB...Moreover if I build a list of such CRL objects, my JVM runs out of memory! I'm ready to try a C API.. I looked at the NSS command crlutil, but that tool is geared around the CRL being first imported in the NSS cert DB. -- POC The recently-released NSS 3.6 contains improved CRL decoding. The function you want to look at is called CERT_DecodeDERCRLWithFlags . One of its current limitations is that it can only deal with full CRLs. Delta CRLs, or CRLs containing issuing distribution point extensions, or freshest CRL extensions, currently cannot be decoded with this API. It is likely that this extra functionality will only become available in NSS 4.0. The additional work is not scheduled for the next version of NSS, which is NSS 3.7 . If it is acceptable to you to decode only full CRLs, then the C API should meet your performance need. To give you an idea of how fast the decoding the NSS CRL decoding API has become in NSS 3.6, it is now capable of decoding a 26 MB CRL containing 1.2 million revoked certificate entries in under 8 seconds on a low-end 440 MHz Ultrasparc II machine. This is about 6 times as fast as in previous versions of NSS. It also needs about 1/4 as much RAM as before to do the decoding - which is still an additional 35 MB of memory, on top of the 26 MB DER source CRL. Both improvements are the result of a new ASN.1 DER decoder I wrote for NSS 3.6, called the QuickDER decoder (see SEC_QuickDERDecodeItem if you are interested). Documentation on that new decoder - as well as on the old, less efficient SEC_ASN1DecodeItem - will be written in upcoming months. But you don't need to use the ASN.1/DER decoder directly to decode a CRL. The cert.h header file should contain sufficient documentation on how to call CERT_DecodeDERCRLWithFlags .
