On Tue, Sep 14, 2004, Goetz Babin-Ebell wrote: > Hi Steve, > > Dr. Stephen Henson wrote: > >On Mon, Sep 13, 2004, Goetz Babin-Ebell wrote: > > > >>ther might be a problem in X509_verify_cert() (at least 0.9.7d): > >>if you set a verification time and > >>the CRL was not yet valid at this time, > >>the error X509_V_ERR_CRL_NOT_YET_VALID will be generated. > >>(see check_crl() in x509_verify.c) > >> > >>It seems to me that a logic like: > >>If check_time (and X509_V_FLAG_USE_CHECK_TIME) are set: > >> accept the CRL if it is (now or after the check_time) valid. > >> And if the certificate is set in the CRL, > >> return X509_V_ERR_CERT_REVOKED if no revocationDate > >> is set or if it is older than the check_time. > >> (in cert_crl() in x509_verify.c) > >> > >>But this opens another can of worms: > >> > >>If the certificate expired before the CRL was issued > >>the revocation entry might be dropped from the CRL... > >> > >>Any Ideas how to handle this ? > > > >There are other issues as well. I know of one CA can suspend a certificate > >in a > >CRL and later remove the suspension. > > For this we (and OpenSSL) would have to keep all CRLs issued > by this CA to check the validity of a certificate > at a given check_time.
Or the application has some method of obtaining CRLs at a given time. > Ignoring the gigabytes of disk space and RAM needed to do this > for a bigger list of CAs, I don't think that OpenSSL > is able to handle more than one CRL for one CA. > The standard methods of directory and file based (along with cache based) lookup can't handle more than one CRL. I'd however regard this as a limitation which will be fixed at some point. If an application overrides the get_crl callback no such limitation exists. > > A certificate listed in a CRL is either revoked or put on hold. > > So if the suspension is removed, the certificate can be > regarded as valid even during the period where it was set > on hold in the CRL. So I don't think we have a problem here. > I'm not sure what (if anything) the standards say about this. > I still would propose the following logic: > a) CRL is valid (regarding issuance time) > if thisUpdate >= checkTime and thisUpdate <= now. > b) CRL is considered to be able to deliver revocation > information if thisUpdate <= notAfter from the certificate > (because after that time the certificate > might be removed from the CRL). > That could certainly be added as a verify flag but I'm a bit wary of doing that by default. If you want that behaviour you can always catch the appropriate error code in the verify callback and (after performing the above checks) tell it to continue. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
