Subject: Re: Delta CRL processing

From: "David P. Kemp" <[email-masked]>
Date: Wed, 21 Apr 1999 14:14:11 -0400 (EDT)

> From: Juergen Walter <[email-masked]>
> 
> 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.

Agree.

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

What do you mean by pending?  I assume you mean that Cert A appears
on CRL #1 with a CRLReason of "certificateHold" in its entry extension.

If CRL #2 has no entry for Cert A, Delta-CRL #2 (referring to baseCRL #1)
would have Cert A with a CRLReason of removedFromCRL.
Similarly, Delta-CRL #3 (referring to baseCRL #1) would have Cert A
with a CRLReason of removedFromCRL, and so would Delta #4, Delta #5,
and all other Deltas with a baseCRL of #1.

Your assertion that Delta-CRL #3 would indicate that cert A is on
certificateHold is incorrect.

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

This situation is not specific to Delta CRLs, it applies to CRLs in
general.

If the relying application wants to know whether a cert was revoked
in a time interval, it must check the CRL issued at the end of that
interval.  In your example, Cert B is revoked sometime between CRL #1
and CRL #2, and it appears on CRL #2 and Delta-CRL #2.  If it appears
on CRL #3, it will also appear on Delta-CRL #3 (referring to baseCRL #1).
It would not appear on Delta-CRL #3 (referring to baseCRL #2)
because CRL #2 already shows that Cert B is revoked.  Either case
(Delta#3/Base#1 or Delta#3/Base#2) must return the same result
as CRL #3.

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

Your very first statement contradicts this.  A delta CRL along with its
base CRL must *IN EVERY CASE* yield identical results to a CRL issued
(hypothetically or actually) at the time of the delta CRL.  That is the
mathematical definition of a delta: the difference between two
absolutes.

Proof by construction:  if you create Delta-CRL #15 as the difference
between CRL #15 and CRL #1, then CRL #1 + Delta-CRL #15 must yield
CRL #15.

The contents of Delta-CRLs #2,3,....14 are irrelevant.

---

From: Juergen Walter <[email-masked]>
Date: Thu, 22 Apr 1999 11:24:05 +0200

Comments in line.

> would have Cert A with a CRLReason of removedFromCRL.

I see. It was a wrong example. Thanks.

> certificateHold is incorrect.

Agreed. Here is the replacement: (1)' Cert A is valid at the time when
CRL #1 is issued. Delta-CRL #2/baseCRL #1 has a CRL entry for Cert A
with reasonCode of "certificateHold". Delta-CRL #3/baseCRL #1 has not
any entry according to Cert A. Certificate path validation that does not
take notice of Delta-CRL #2 results in valid for the time interval
whereby the certificate was on hold.

> This situation is not specific to Delta CRLs, it applies to CRLs in

Agreed.

> Your very first statement contradicts this. 

You are right again. The RFC 2459 is more suitable for those crls that I
called epsilon-CRLs. My examples are not delta-crl specific. It is
simply the fact that you need the appropriate CRLs for certificate path
validation at a certain time in the past.

> A delta CRL along with its

I resume that nobody wants to implement epsilon-crls. Alternatively one
may split up large crls according to revocationTime intervals. Is it
prudent to go this way?

Juergen