CRL validation must be skipped for certs with no CRLDPs

[Jeff Saremi]

This was mentioned briefly in another thread by myself. I thought it
deserved its own discussion. The copies of how it went on are pasted below.

Section 6.3.3. of RFC 5280 - CRL Processing
"This algorithm begins by assuming that the certificate is not revoked....
For each distribution point (DP) in the certificate's CRL distribution
points extension, for each corresponding CRL ...."

So my expectation is that after I instruct OpenSSL to perform CRL
checking -- whether I set or not set any CRLs -- no checking must be
done on any certificates which don't have CRLDP in them.

The spec ofcourse mentions that implementations are not required to
follow this algorithm, however, it also mentions that the end result
must be the same as when they did.

Now as an average user of OpenSSL API, I expect not to have to write any
piece of code (such as over-ruling the validation failure in validation
callback) for the normal process of certificate/CRL validation to take
its course. Is this a reasonable expectation?

thanks
Jeff

********* Original Problem Statement ************
Re: Need Help with Programmatic Downloading+Checking of CRLs
...

> So as per previous posts, I implemented lookup_crl().
> Now one of the major problems is what do I return from this method, if
> the certificate has no CRL distribution points!
> Returning an empty stack causes get_crl_delta() to fail.
> Is there a flag that I can setup to let this cert be excluded from CRL
> checking?
> Is that something I should be doing in lookup_crl? Or should the
> framework be smart enough not to even ask me for a CRL in this case?
>
> thanks
> jeff

> 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.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org

[Bruce Stephens]

Jeff Saremi <jsa...@morega.com> writes:

[...]

> Section 6.3.3. of RFC 5280 - CRL Processing
> "This algorithm begins by assuming that the certificate is not revoked....
> For each distribution point (DP) in the certificate's CRL distribution
> points extension, for each corresponding CRL ...."
>
> So my expectation is that after I instruct OpenSSL to perform CRL
> checking -- whether I set or not set any CRLs -- no checking must be
> done on any certificates which don't have CRLDP in them.

I think you should read on. Specifically, the last paragraph seems to
me to indicate different behaviour is intended:

If the revocation status has not been determined, repeat the process
above with any available CRLs not specified in a distribution point
but issued by the certificate issuer. For the processing of such a
CRL, assume a DP with both the reasons and the cRLIssuer fields
omitted and a distribution point name of the certificate issuer.
That is, the sequence of names in fullName is generated from the
certificate issuer field as well as the certificate issuerAltName
extension. After processing such CRLs, if the revocation status has
still not been determined, then return the cert_status UNDETERMINED.

That seems to me more natural: if there's no CRLDP then check any
relevant CRL. If (after all this) you fail to find any relevant CRLs,
then the revocation status is undetermined.

[...]

[Jeff Saremi]

I'm not sure how you read this. I read it like a programmer.
In programming primitives, the spec would be coded like this:

Here's the spec:

"This algorithm begins by assuming that the certificate is not revoked....
For each distribution point (DP) in the certificate's CRL distribution
points extension, for each corresponding CRL ...."

And here's the C code:

cert.status = UNREVOKED;
for (i = 0; i < cert.crldp.size; ++i)
{
/* more processing loops */
}

Right there, the main loop should not even execute because
cert.crldp.size is zero.
But let's play along and say that for some unknown reason we get to the
section of the spec you're referring to:

Here's the spec:

> I think you should read on. Specifically, the last paragraph seems to
> me to indicate different behaviour is intended:
>
> If the revocation status has not been determined, repeat the process
> above with any available CRLs not specified in a distribution point
> but issued by the certificate issuer.

Here's the code:

cert.status = NOT_REVOKED;
for (i = 0; i < cert.crldp.size; ++i)
{
/* some processing loops */
if(cert.status == UNDETERMINED)
{
/* do what Bruce Stephens suggested */
}
}

As you can see again there's another stop and that stop is that our
certificate's status is not "UNDETERMINED" but rather "UNREVOKED".

But lets view this whole thing from another perspective:
I have a limited certificate authority in my organization. have a root
cert which does not get revoked. I distribute that to the ones who want
to deal with me. I also generate a multitude of endpoint certificates. I
do not intend for any of these to become revoked, ever. Hence, I do not
bother with the process of certificate revocation and CRL issuance. Now
as a result of OpenSSL's imlementation, none of my clients who use
OpenSSL will be able to deal with me online. Because my certificates do
not have a CRL and CRLDP period. Should I stop doing business
altogether? Should I contact my business partners and tell them that
they should be applying a patch to their code, overriding verification
failure in their certVerifyCallbacks? Let's just think that through a
little.