Re: Delta CRL processing

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

Russ,

Thanks for the background info.  But do you agree that the sentence
quoted below does not accurately describe the usage of delta CRLs
(by either a server or an end user application), and should be
removed from the next version of the PKIX profile?

The input to a delta CRL processor is one base CRL and one delta CRL.
There is no state involved in the process, and the CRLNumbers of
delta CRLs processed before or after the current one are irrelevant.

The sentence as written is no more security-helpful than, for example:

  "A CRL user constructing a locally held CRL from delta-CRLs MUST
   consider the constructed CRL incomplete and unusable if the
   delta-CRL is received on the third Thursday of the month."


Dave K.



> From: Russ Housley <housley@spyrus.com>
> 
> Dave:
> 
> I thought some background might help.  When I was drafting the CRL section
> for RFC 2459, I wanted to say "do not used delta-CRLs."  I was convinced
> that they have some value when a high-end server caches CRL information in
> a local format for rapid access.  In this environment, the delta-CRL is
> used to update the server-friendly data structure without having to process
> the entire CRL.  Note that X.509 requires that a full CRL be generated
> every time that a delta-CRL is generated.  So, it seemed to be reasonable
> that the server obtain the most recent full CRL when it has a few spare
> cycles.  This means that the delta-CRL information is only used for a brief
> period until the server have resources to convert the most recent full CRL
> into the server-friendly format.
> 
> Russ
> 
> 
> At 11:53 AM 4/19/99 -0400, David P. Kemp wrote:
> >
> >RFC 2459 section 5.2.4 contains the following requirement:
> >
> >  "A CRL user constructing a locally held CRL from delta-CRLs MUST
> >  consider the constructed CRL incomplete and unusable if the CRLNumber
> >  of the received delta-CRL is more than one greater than the CRLnumber
> >  of the delta-CRL last processed."

       [remainder snipped]