Re: Delta CRL processing

[Russ Housley <housley@xxxxxxxxxx>]

Dave:

I think that your proposed rewording is more clear.  Two things are important:

	(1) The CA must issue a full CRL every time a delta is issued.

	(2) The relying party may use a delta and the assocuated base.

Russ


At 06:03 PM 4/19/99 -0400, David P. Kemp wrote:
>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]
>