|
Hello
Steve,
Thanks for your reply but a few doubts still exist, > 1. Suppose we request for the revocation status of many certificates in a > single request > > eg (openssl verify -crl_check -CAfile demoCA/crl/chain cert1 cert2 > cert3 .....) > > threads are created for each request.So during the first certificate > verification the revoked list is sorted. During this time all the remaining > threads must not interfere the sorting process so we are locking the CRL structure > inside the sorting function. Am I right ? > >>Only if the application is multithreaded. The openssl verify utility isn't 1. Can we improve the CRL lookup performance by implementing threading in OpenSSL verify utility.? 2. Is there any applications available with thread support for verifying CRL ? 3. In a multithreaded application we perform the lock so that when one thread sorts the CRL , the other thread do not interfere this sorting process. Am I right ? > 2. Suppose we request for the revocation status of many certificates in a > single request > > eg. (openssl verify -crl_check -CAfile demoCA/crl/chain cert1 cert2 > cert3 .....) > > Do we have to verify the CRL signature for each certificate (or) is it > enough to verify the CRL signature only once? > >>The current verify function will verify the signature each time, the cached >>encoding will make this quicker than before though. Is the CRL signature verification necessary for every certificate or can we limit it to just a single CRL signature verification.? > 4. Does ASN1_ENCODING_enc element added to X509_crl_info_st structure used > for caching the original CRL encoded list for verification ? > > >>Well it stores the original encoding of the signed portion of the CRL which is >>effectively the same thing. So the encoding we cache is a replica of the original encoded CRL list or just the signed portion ? Thanks, Prakash __________________________________________________ |
