Subject: RE: delta-CRLs

From: Santosh Chokhani <[email-masked]>
Date: Fri, 4 May 2001 16:29:46 -0400

Russ and Denis:

With all due respect, that is a limited view of delta CRL (forcing to use
the base CRL that is referenced).

I am very disappointed with the PKIX process of writing these profiles and
rewording and mutating the concepts from X.509 to the point that introduce
limitations and errors.  Recall the buggy path validation procedure in 2459.

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Friday, May 04, 2001 2:16 PM
To: Denis Pinkas
Cc: [email-masked]
Subject: Re: delta-CRLs

Denis:

I can live with these.

>Taking into account the last proposal from Russ, this would
>lead to the two following paragraphs:
>
>    An application can construct an updated CRL, for a specific time T,
>    by retrieving the appropriate base CRL for that scope, and combining
>    it with a delta CRL which contains a delta CRL indicator extension
>    with the same CRL number as the base CRL. Applications that support
>    delta CRLs MUST ensure that time T falls between thisUpdate and
>    nextUpdate for both the base CRL and the delta CRL.
>
>    Note: An application could also reconstruct an updated CRL, for
>    a specific time T, by using a previously locally reconstructed CRL
>    based on a given base CRL, and combining it with a delta CRL which
>    contains a delta CRL indicator extension with the same CRL number as
>    the base CRL.

Russ