Re: CRL checking failing in 1.0.1
Bin Lu writes:
[...]
> if (dcrl)
> {
> ok = ctx->check_crl(ctx, dcrl);
> if (!ok)
> goto err;
> ok = ctx->cert_crl(ctx, dcrl, x); ç this does not
> run since dcrl is NULL
> if (!ok)
> goto err;
> }
> else
> ok = 1; ç so always return success
and the next bit of code is:
/* Don't look in full CRL if delta reason is removefromCRL */
if (ok != 2)
{
ok = ctx->cert_crl(ctx, crl, x);
if (!ok)
goto err;
}
so ctx->cert_crl is being called.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: CRL checking failing in 1.0.1
On Thu, Jan 09, 2014, Jakob Bohm wrote:
> On 1/9/2014 8:14 PM, Dr. Stephen Henson wrote:
> >On Thu, Jan 09, 2014, Bin Lu wrote:
> >
> >> Here is the problem, in cert_crl():
> >>
> >>/* The rules changed for this... previously if a CRL contained
> >> * unhandled critical extensions it could still be used to indicate
> >> * a certificate was revoked. This has since been changed since
> >> * critical extension can change the meaning of CRL entries.
> >> */
> >> if (crl->flags & EXFLAG_CRITICAL)
> >> {
> >> if (ctx->param->flags & X509_V_FLAG_IGNORE_CRITICAL)
> >> return 1;
> >> ctx->error = X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION;
> >> ok = ctx->verify_cb(0, ctx);
> >> if(!ok)
> >> return 0;
> >> }
> >>
> >>Why are we making this change, skipping the critical CRL extensions? This
> >>is causing all the regressions. In this case, should we expect
> >>X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION instead of the validation
> >>result based on the CRL content? Basically we fail the validation once we
> >>encounter a critical CRL extension, if flag IGNORE_CRITICAL is not set, or
> >>succeed if the flag is set, regardless whatsoever in the CRL ???
> >>
> >
> >This is now a requirement of RFC5280 5.2:
> >
> >If a CRL contains a critical extension
> >that the application cannot process, then the application MUST NOT
> >use that CRL to determine the status of certificates.
> >
>
> That seems a strange reading of the RFC. If a flag to IGNORE this rule
> is passed to OpenSSL, that should certainly ignore the rule, not the CRL.
>
>
Ugh, yes you're right that is a bug. It should carry on and use the CRL if
X509_V_FLAG_IGNORE_CRITICAL is set.
Workaround for now is to override
X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION in the callback.
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
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: CRL checking failing in 1.0.1
On 1/9/2014 8:14 PM, Dr. Stephen Henson wrote:
On Thu, Jan 09, 2014, Bin Lu wrote:
Here is the problem, in cert_crl():
/* The rules changed for this... previously if a CRL contained
* unhandled critical extensions it could still be used to indicate
* a certificate was revoked. This has since been changed since
* critical extension can change the meaning of CRL entries.
*/
if (crl->flags & EXFLAG_CRITICAL)
{
if (ctx->param->flags & X509_V_FLAG_IGNORE_CRITICAL)
return 1;
ctx->error = X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION;
ok = ctx->verify_cb(0, ctx);
if(!ok)
return 0;
}
Why are we making this change, skipping the critical CRL extensions? This is
causing all the regressions. In this case, should we expect
X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION instead of the validation result
based on the CRL content? Basically we fail the validation once we encounter a
critical CRL extension, if flag IGNORE_CRITICAL is not set, or succeed if the
flag is set, regardless whatsoever in the CRL ???
This is now a requirement of RFC5280 5.2:
If a CRL contains a critical extension
that the application cannot process, then the application MUST NOT
use that CRL to determine the status of certificates.
That seems a strange reading of the RFC. If a flag to IGNORE this rule
is passed to OpenSSL, that should certainly ignore the rule, not the CRL.
A flag to ignore a MUST rule in an RFC, while obviously violating said
rule, also brings an implementation outside the scope of that rule, if
not the entire RFC (but only when that flag is specified).
What extension in your CRLs is critical?
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
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: CRL checking failing in 1.0.1
On Thu, Jan 09, 2014, Bin Lu wrote:
> Here is the problem, in cert_crl():
>
>/* The rules changed for this... previously if a CRL contained
> * unhandled critical extensions it could still be used to indicate
> * a certificate was revoked. This has since been changed since
> * critical extension can change the meaning of CRL entries.
> */
> if (crl->flags & EXFLAG_CRITICAL)
> {
> if (ctx->param->flags & X509_V_FLAG_IGNORE_CRITICAL)
> return 1;
> ctx->error = X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION;
> ok = ctx->verify_cb(0, ctx);
> if(!ok)
> return 0;
> }
>
> Why are we making this change, skipping the critical CRL extensions? This is
> causing all the regressions. In this case, should we expect
> X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION instead of the validation result
> based on the CRL content? Basically we fail the validation once we encounter
> a critical CRL extension, if flag IGNORE_CRITICAL is not set, or succeed if
> the flag is set, regardless whatsoever in the CRL ???
>
This is now a requirement of RFC5280 5.2:
If a CRL contains a critical extension
that the application cannot process, then the application MUST NOT
use that CRL to determine the status of certificates.
What extension in your CRLs is critical?
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
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: CRL checking failing in 1.0.1
Here is the problem, in cert_crl():
/* The rules changed for this... previously if a CRL contained
* unhandled critical extensions it could still be used to indicate
* a certificate was revoked. This has since been changed since
* critical extension can change the meaning of CRL entries.
*/
if (crl->flags & EXFLAG_CRITICAL)
{
if (ctx->param->flags & X509_V_FLAG_IGNORE_CRITICAL)
return 1;
ctx->error = X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION;
ok = ctx->verify_cb(0, ctx);
if(!ok)
return 0;
}
Why are we making this change, skipping the critical CRL extensions? This is
causing all the regressions. In this case, should we expect
X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION instead of the validation result
based on the CRL content? Basically we fail the validation once we encounter a
critical CRL extension, if flag IGNORE_CRITICAL is not set, or succeed if the
flag is set, regardless whatsoever in the CRL ???
Thanks,
-binlu
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Dr. Stephen Henson
Sent: Thursday, January 09, 2014 5:08 AM
To: openssl-users@openssl.org
Subject: Re: CRL checking failing in 1.0.1
On Thu, Jan 09, 2014, Bin Lu wrote:
> Hi,
>
> I have a piece of code doing CRL revocation check which worked fine with
> 0.9.8 but now failing in 1.0.1.
> The code does something like:
> X509_STORE_add_crl(store,crl);
> X509_STORE_CTX_init(ctx, store, cert, NULL);
> Ctx->check_revocation(ctx);
>
> In openssl lib (x509_vfy.c), check_cert() does the following:
> while (ctx->current_reasons != CRLDP_ALL_REASONS)
> {
> /* Try to retrieve relevant CRL */
> if (ctx->get_crl) <== this is NULL
> ok = ctx->get_crl(ctx, &crl, x);
> else
> ok = get_crl_delta(ctx, &crl, &dcrl, x); <== this
> line gets called and returns the CRL in 'crl', 'dcrl' returns null.
> /* If error looking up CRL, nothing we can do except
> * notify callback
> */
> if(!ok)
> {
> ctx->error = X509_V_ERR_UNABLE_TO_GET_CRL;
> ok = ctx->verify_cb(0, ctx);
> goto err;
> }
> ctx->current_crl = crl;
> ok = ctx->check_crl(ctx, crl);<== here it only checks the
> validity of the crl, but does not do CRL checking against the cert
> if (!ok)
> goto err;
>
> if (dcrl)
> {
> ok = ctx->check_crl(ctx, dcrl);
> if (!ok)
> goto err;
> ok = ctx->cert_crl(ctx, dcrl, x); <== this does not
> run since dcrl is NULL
> if (!ok)
> goto err;
> }
> else
> ok = 1; <== so always return success
>
> Is this something wrong, or am I missing something?
>
The next bit is:
/* Don't look in full CRL if delta reason is removefromCRL */
if (ok != 2)
{
ok = ctx->cert_crl(ctx, crl, x);
if (!ok)
goto err;
}
That looks for the certificate serial number in the CRL.
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
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: CRL checking failing in 1.0.1
On Thu, Jan 09, 2014, Bin Lu wrote:
> Hi,
>
> I have a piece of code doing CRL revocation check which worked fine with
> 0.9.8 but now failing in 1.0.1.
> The code does something like:
> X509_STORE_add_crl(store,crl);
> X509_STORE_CTX_init(ctx, store, cert, NULL);
> Ctx->check_revocation(ctx);
>
> In openssl lib (x509_vfy.c), check_cert() does the following:
> while (ctx->current_reasons != CRLDP_ALL_REASONS)
> {
> /* Try to retrieve relevant CRL */
> if (ctx->get_crl) <== this is NULL
> ok = ctx->get_crl(ctx, &crl, x);
> else
> ok = get_crl_delta(ctx, &crl, &dcrl, x); <== this
> line gets called and returns the CRL in 'crl', 'dcrl' returns null.
> /* If error looking up CRL, nothing we can do except
> * notify callback
> */
> if(!ok)
> {
> ctx->error = X509_V_ERR_UNABLE_TO_GET_CRL;
> ok = ctx->verify_cb(0, ctx);
> goto err;
> }
> ctx->current_crl = crl;
> ok = ctx->check_crl(ctx, crl);<== here it only checks the
> validity of the crl, but does not do CRL checking against the cert
> if (!ok)
> goto err;
>
> if (dcrl)
> {
> ok = ctx->check_crl(ctx, dcrl);
> if (!ok)
> goto err;
> ok = ctx->cert_crl(ctx, dcrl, x); <== this does not
> run since dcrl is NULL
> if (!ok)
> goto err;
> }
> else
> ok = 1; <== so always return success
>
> Is this something wrong, or am I missing something?
>
The next bit is:
/* Don't look in full CRL if delta reason is removefromCRL */
if (ok != 2)
{
ok = ctx->cert_crl(ctx, crl, x);
if (!ok)
goto err;
}
That looks for the certificate serial number in the CRL.
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
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
CRL checking failing in 1.0.1
Hi,
I have a piece of code doing CRL revocation check which worked fine with 0.9.8
but now failing in 1.0.1.
The code does something like:
X509_STORE_add_crl(store,crl);
X509_STORE_CTX_init(ctx, store, cert, NULL);
Ctx->check_revocation(ctx);
In openssl lib (x509_vfy.c), check_cert() does the following:
while (ctx->current_reasons != CRLDP_ALL_REASONS)
{
/* Try to retrieve relevant CRL */
if (ctx->get_crl) <== this is NULL
ok = ctx->get_crl(ctx, &crl, x);
else
ok = get_crl_delta(ctx, &crl, &dcrl, x); <== this line
gets called and returns the CRL in 'crl', 'dcrl' returns null.
/* If error looking up CRL, nothing we can do except
* notify callback
*/
if(!ok)
{
ctx->error = X509_V_ERR_UNABLE_TO_GET_CRL;
ok = ctx->verify_cb(0, ctx);
goto err;
}
ctx->current_crl = crl;
ok = ctx->check_crl(ctx, crl);<== here it only checks the
validity of the crl, but does not do CRL checking against the cert
if (!ok)
goto err;
if (dcrl)
{
ok = ctx->check_crl(ctx, dcrl);
if (!ok)
goto err;
ok = ctx->cert_crl(ctx, dcrl, x); <== this does not
run since dcrl is NULL
if (!ok)
goto err;
}
else
ok = 1; <== so always return success
Is this something wrong, or am I missing something?
Thanks,
-binlu
