On Tue, Oct 13, 2009, Victor B. Wagner wrote: > 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? >
If it breaks existing applications yes, if it is a bugfix no. I think in this case it is arguably "fixing" something which is broken so it could come under that. > > 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. > I'd suggest using a bitfield in this case but you need rather more flags than just each type of object. For example some application which need to verify certificates at times in the past might want to keep expired objects around. Since cache is unused it could (for example) use (1 << X509_LU_WHATEVER) for flags which avoids clashes with X509_LU_PKEY, though as you note that is currently unused. > > > 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. > Although applications don't use X509_STORE_CTX directly they do use it and related APIs indirectly and some understading of how these structures interact would help. In that vein we'd need to document X509_STORE_CTX, X509_verify_cert() and X509_VERIFY_PARAM (and related functions). Some of this could just copy and paste or point to some existing documentation for the verify utility. 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
