RE: Processing of freshestCRL extension in CRLs

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

Bruce,

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.  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.

Thanks,
Tom


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

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

> Did you install SMP patch 2.5.2 located at
> http://www.digitalnet.com/knowledge/download.htm?

Yes.  I've rechecked (since we import things into CVS, and it's
certainly not impossible to slip up).

> This patch contains a few bug fixes for the deltaCRL processing.

Indeed.  As it happens, our code first exposed to the CRL in question
was based on SMP 2.5.0, and that has different behaviour (it verifies
the CRL initially, but then treats the cached CRL as invalid).

> Please make sure you have this patch installed and that you have
> rebuilt the SMP libraries and re-linked your application prior to
> re-testing.  If you still experience problems let us know.

The code I was using was definitely rebuilt and relinked with the
right library.

I think my analysis was correct: I can see processing of the
certificate's freshest CRL extension in CRL_CheckRevStatus.

In findValidCRL there's checking of a CRL's freshest CRL extension,
but that just calls chooseValidCRL, and that doesn't seem to attempt
to retrieve anything.

And a grep for m_pFreshestCRL doesn't show any places where the
distribution points might be used.  Rather, the code's looking at the
presence of the extension.

It's possible the specific PKI configuration is unusual.  The
end-entity certificate doesn't appear to have a freshest CRL
extension.  If it had one (matching the CRLs), then I think CML would
work fine, processing that and retrieving the deltaCRLs.

[...]