Subject: Re: Delta CRL processing

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 20 Apr 1999 19:02:27 -0600

Russ,

Let me poke at this for a moment.

Does this make it crystal clear that relying party software is not required to 
to obtain each and every CRL that is issued, nor every delta that might have 
been issued since the last time the base was updated?

When I first suggested the concept of a delta CRL to Warwick, back during
the waning days of PEM, I had in mind a "CRL CD of the month club"
type of mechanism, whereby I could efficiently retrieve the large bulk of 
CRLs and then download only the changes since that baseline.  Since the 
deltas would be cumulative since the baseline, the latest delta would 
always be correct.  I had in mind particularly the case where I am about 
to jump on an airplane, and I want to do some kind of a "hit the road"
option with a minimum of fuss and bother.

By comparison, if the relying party is required to download each and every 
delta that might have been issued, then either there will be a lot of 
bandwidth wasted loading the same information about some revoked 
certificate over and over again, or else (if such information is sent only
once), the RP would be at risk of having missed one, and/or there would
be a significant synchronization problem.

If some applications want to receive deltas at one second intervals, and 
for my purposes I only care about once a week, I don't want to be compelled
to check or download any more data or any more often than is
necessary for my application, regardless of what some other application 
might require.

I also question the need to issue a new, complete CRL every time a delta
is issued.  Although it may not matter if I am operating a local CA with its own
repository, or if I am a public CA (same thing), it might matter a very great 
deal if I am publishing all of my certs through some kind of a third party 
repository  - the cost could end up being prohibitive.

Is there something I don't understand?  If we have delta CRLs, why must
we also support full CRLs at the same frequency -- this seems to defeat the 
basic purpose of having delta CRLs in the first place??

Bob

>>> Russ Housley <[email-masked]> 04/20/99 12:23PM >>>
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 <[email-masked]>
>> 
>> 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]
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 21 Apr 1999 11:35:19 -0400

Bob:

delta-CRLs do not operate as you describe.  They are the updates since the
specified base.  Further, X.509 requires the CA to issue a full CRL every
time that a delta-CRL is generated.  RFC 2459 did not create this
requirement, itis inherited from X.509.

Russ

---

From: Juergen Walter <[email-masked]>
Date: Wed, 21 Apr 1999 18:42:50 +0200

I think that a delta crl along with its base crl is just a (temporal?)
replacement of *a* CRL that is issued after the time when the base CRL
is isssued. If it is a regularly scheduled CRL which is replaced then
the CRLNumber ensures that no regularly scheduled CRL is missed by the
relying application. There might be more sophisticated mechanisms (a
detailed thisUpdate - nextUpdate analysis over a set of CRLs when
appropriately implemented) nevertheless CRLNumber might be the best. 

Two examples. # short for CRLNumber in the following. 

(1) Cert A is pending at CRL #1. Delta-CRL #2 is issued according to the
base CRL #1. Delta-CRL #2 indicates that Cert A is removedFromCRL i. e.
Cert A is valid. Delta-CRL #3 does not contain any CRL entry
corresponding to Cert A. A relying application that does only process
Delta-CRL #3 (but not Delta-CRL #2) returns the result that Cert A is
always pending. But Cert A is valid after Delta-CRL #2 is issued.

(2) Cert B is valid at CRL #1. Delta-CRL #2 contains a CRL entry for
Cert B. Cert B expires before Delta-CRL #3 is issued. Delta-CRL #3 may
not contain any CRL entry for Cert B. A relying application that does
process only Delta-CRL #3 (but not Delta-CRL #2) returns the result that
Cert B is valid before it expires. But Cert B was revoked prior to
expiration.

Therefore the corresponding RFC 2459 paragraph 

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

should remain unchanged.

Clients that are not suitable for CRL downloading may use OCSP including
cashing. Another solution might be the use of CMP´s revocation
announcement (RFC 2510). Note, initially the intended usage of CMP´s
revocation announcement was different. Therefore you can not expect any
security measure that ensures that the client does not miss a particular
revocation announcement at protocol level.

Last but not least, Bob mentioned a new style delta-crl. I would like to
add new notation to Bob´s posting. An interesting question is the
following. Do we need an epsilon-crl i. e. a crl containing only changes
between the previously issued epsilon-crl and the current certificate
status information? Should be epsilon-crls regularly scheduled? Could a
crl issuer leave the crl generation at each time when an epsilon-crl is
issued? Is there a need for such an epsilon-crl? I tend to say yes.

I have chosen the term epsilon-crl to make it clear that a current
delta-crl MUST NOT generated in the above specified way.

Juergen