Re: Processing of freshestCRL extension in CRLs

[Bruce Stephens <bruce.stephens@xxxxxxxxx>]

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

[...]