Re: Processing of freshestCRL extension in CRLs

[Bruce Stephens <bruce.stephens@xxxxxxxxx>]

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

[...]