On 2009.10.12 at 19:00:30 +0200, Dr. Stephen Henson wrote: > > Well we are in the middle of a beta relase cycle so making incompatible > changes and/or major new functionality isn't an option.
Is this (#2) a major new functionality, given that cache field in X509_CTX is already here and applications rely on it? > Handling multi-megabyte CRLs is problematical in any cases. OpenSSL typically > trebles the size of them at least when storing in memory for example. Servers > which use fork() and are not multithreaded will suffer big perormance hits > reloading such CRLs. This is why I suggest this feature be controllable using cache field of X509_STORE. Application writer can than decide what is worse for him - performance hit from reloading of CRLs or interrupt of service, required when reload of server needed each time CRL is issued. > Documentation I think should really concentrate on the verification mechanism > and X509_STORE_CTX. X509_STORE is badly broken and was supposed to have been > replaced long ago but that hasn't happened for various reasongs. Documentation should concentrate on how to do the right thing. For most purposes the right thing is to point OpenSSL to the trusted store directory/file, set neccessary X509_V_FLAGs and let it care about the rest. With current API typical application writer never sees X509_STORE_CTX. 1. SSL_CTX allows him to get pointer to X509_STORE, not X509_STORE_CTX in order to set flags or may be cache field. Locations, callbacks and such is set using SSL_CTX API. 2. PKCS7_verify and CMS_verify receive X509_STORE, not X509_STORE_CTX. These two cases cover about 99% of use of the trusted certificate store in the applications. Rest would be probably attempts to implement application-specific lookup method, say store trusted certificates and CRLs in the SQL database. Only application where I myself had to create X509_STORE_CTX in my code was PKI Client application which handles certificates and CRLs received from CA and put it into the right place (doing some checks). There I have to use X509_STORE_CTX to manually check certificates and manually lookup CRLs (because there is no CRL validation function analougue to X509_verify_cert). I think that describing life cycle of CA certificates and CRLs is much more imporaint than details of X509_STORE_CTX API. Although details of verification process are, of course, important. But this process is already documented in the verify(1) man page. Only reference to this page can be made in the X509_verify_cert(3) man page. Some flags can be described just as reference to corresponding verify(1) option. But some flags, such as X509_V_FLAG_USE_CHECK_TIME do not have corresponding command line option in the verify command,. And some (such as X509_V_FLAG_CB_ISSUER_CHECK and X509_V_FLAG_NOTIFY_POLICY) have quite different semantic on API level than on command-line level. > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager majord...@openssl.org > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
