Re: Delta CRL processing

[Juergen Walter <walter@xxxxxx>]

Comments in line.

"David P. Kemp" wrote:
> 
> > From: Juergen Walter <walter@deh.de>
> >
> > 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.

I see. It was a wrong example. Thanks.

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

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.

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

Agreed.

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

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

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