> There are other "out of band" mechanisms where a CRL might be available but
> not mentioned in a CRLDP. OpenSSL has no way of telling what those might be
> and if the absence is really an error or not.
>
> The best you can do is trap the issuer error in the verify callback and ignore
> it if appropriate.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
Is introducing a mechanism to lookup_crl to allow this bypass unreasonable?
Or introducing an override method (like the pointers in X509_STORE) to
check if the code should ask for a CRL or not? Such as the following:
static int check_revocation(X509_STORE_CTX *ctx)
{
int i, last, ok;
if (!(ctx->param->flags & X509_V_FLAG_CRL_CHECK))
return 1;
if (ctx->param->flags & X509_V_FLAG_CRL_CHECK_ALL)
last = sk_X509_num(ctx->chain) - 1;
...
for(i = 0; i <= last; i++)
{
ctx->error_depth = i;
if(ctx->crl_check_required(i))
{
ok = check_cert(ctx);
if (!ok) return ok;
}
}
return 1;
}
crl_check_required(int i) in the default (most simplistic case) could
just do a check on CRLDP in the certificate. And if as you said there
are other CRLs that could have been provided, then one could overwrite it.
Here's another suggestion:
There's a lot of logic and functionality in the following methods:
check_cert()
and
get_crl_delta()
If these could be overwrite-able in X509_STORE would be great.
Especially get_crl_delta.
If get_crl defaulted to get_crl_delta that solution would still be
workable as well..
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
