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

Reply via email to