RE: Processing of freshestCRL extension in CRLs

["Horvath, Tom \(US SSA\)" <tom.horvath@xxxxxxxxxxxxxx>]

Bruce,

It looks like you found a problem.  The code that starts at line 963 of
CRL_Mgr.cpp checks to see if the CRL has a freshestCRL extension, but
then never pulls CRLs from the distribution points in that extension.
You were correct about things working properly if the cert contains the
freshestCRL extension.  If the cert does not contain the freshestCRL
extension and the deltaCRL happens to reside in the certificate issuers
entry it works as well, but if the only way to find the delta is by
looking in the distribution points in the CRLs freshestCRL extension
then we will never retrieve it.  Good catch.  I never noticed that I
missed this functionality as the PKITS tests do not contain that exact
scenario where the only way to locate the deltaCRL is though a
distribution point in the freshestCRL extension of the CRL.  I need to
add this to the list of things to do when we have further funding.  This
is open source so we never turn down suggestions if you wish to tackle
it before we have a chance to get back to it.  

Regards,
Tom
-----Original Message-----
From: Bruce Stephens [mailto:bruce.stephens@xxxxxxxxx] 
Sent: Wednesday, January 17, 2007 12:26 PM
To: Horvath, Tom (US SSA)
Cc: imc-cml
Subject: Re: Processing of freshestCRL extension in CRLs

"Horvath, Tom  (US SSA)" <tom.horvath@xxxxxxxxxxxxxx> writes:

> The CML should handle the case where either the cert and/or the CRL
has
> the freshestCRL extension.  The code that should be called in either
of
> these cases is on line 963 of CRL_Mgr.cpp.  This code checks to see if
> the certificate contained the freshestCRL extension by checking if the
> isDelta flag passed into findValidCRL() is set to true and also checks
> if the complete base CRL contains the freshestCRL extension.  In
either
> circumstance, chooseValidCRL() is called with list of CRLs retrieved
> from RequestCRLs() which was above on line 947.  It is actually
> RequestCRLs() where the CRLs are retrieved either from the local SRL
> database or the remote LDAP server depending on how search bounds is
set
> in your CML session.

Indeed.  I'm suggesting that RequestCRLs isn't being called for the
distribution points in the freshest CRL extension of the base CRL.

It would be for the same extension in a certificate
(CRL_CheckRevStatus has an obvious loop doing that, at line 307), but
that really is only for a certificate (and not a CRL), isn't it?  I
don't see any similar code for the extension in CRLs.

> If the search bounds is set to one of the
> following, then the remote LDAP directory could be searched at some
> point.  
>
>     CM_SEARCH_REMOTE,       /* Search only the remote data store */
>     CM_SEARCH_BOTH,         /* Search both the local & remote data
> stores */
>     CM_SEARCH_UNTIL_FOUND   /* Search the local and stop if object
found
> */
>
> Only CM_SEARCH_REMOTE forces the remote LDAP server to always be
> searched.  Any other settings may use local CRLs that were retrieved
> earlier.  A quick way to find out if the deltaCRL is being retrieved
> is to stop your application, remove the SRL database files and then
> restart your application.  If your CML session has been created with
> one of the search bounds listed above it will retrieve deltaCRLs
> from the remote directory.  Try this and let me know what happens.

We're using CM_SEARCH_UNTIL_FOUND.  Could it be that finding the base
CRL locally prevents the library from searching remotely for deltaCRLs
(in such a way that CM_SEARCH_REMOTE might work in this case)?  That
feels wrong (and doesn't match my understanding of the code).

That also doesn't match what I saw looking at the LDAP (using
wireshark to snoop the protocol).  For the specific certificates and
CRLs I was looking at, the uris were nicely distinct.  The uri in the
freshest CRL extension (which was only in the CRL, not in the
certificates) has the form
ldap:///<DN>?deltaRevocationList?base?objectClass=cRLDistributionPoint

and none of the other distribution points ask for deltaRevocationList.

Looking at the snooped LDAP searches, none of them ask for
deltaRevocationList.  (This is from application startup.)

Our applications are set up to use fresh SRL databases each time
they're run (which defeats the object of them, yes, and needs review
at some point), so I think that's not the issue.

And, as it happens, we have no deltaCRLs (so the expected behaviour
was for verification to fail, which it does does, of course).  And the
specific CRL has now expired.

Anyway, I'll continue investigating (I'm currently working on
constructing CRLs with this extension, and deltaCRLs, since OpenSSL
doesn't directly support these yet).

[...]