RE: delta-CRLs (was Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments)

["Trevor Freeman" <trevorf@xxxxxxxxxxxxxxxxxxxxx>]

David,
You are absolutely right that this is a mater of policy on the part of
the CA operator, so why mandate this in the RFC. There is no equivalent
policy that states republish a CRL if you publish new information via
OCSP. OCSP client may well get more up-to-date information but I don't
see a mass of protests from the CRL aware clients.
We have also found that publishing a base and delta simultaneously with
the same CRL number causes problems where you have replicated
distribution points. With replicated distribution mechanisms, there is
no guarantee that both objects replicate together, which means you end
up in a race condition as to which CRL replicates to a given location.
If the base makes it to a given location first, all is well, but it the
delta wins, you get an error since the delta now points to a base which
the client cannot obtain from the same location. Unfortunately, with
bandwidth restricted networks, administers frequently allow small
updates through more frequently, preferring large update to be batched
to an off-peak hour typically resulting in a no-contest as to which CRL
replicates first.
Trevor

-----Original Message-----
From: David A. Cooper [mailto:david.cooper@xxxxxxxx] 
Sent: Thursday, April 19, 2001 9:48 AM
To: ietf-pkix@xxxxxxx
Subject: delta-CRLs (was Re: Last Call: draft-ietf-pkix-new-part1-06.txt
comments)

Denis,

There seems to be some confusion about the way that delta-CRLs work. I
will try to clarify things with my responses in-line below.

At 05:32 PM 4/19/01 +0200, Denis Pinkas wrote:
>In the third paragraph the first sentence (still) says:
>
>    When a conforming CA issues a delta CRL, the CA MUST also issue a
CRL

I must admit that I am not a big fan of this requirement. From my point
of view, there are both advantages and disadvantages to issuing a full
CRL whenever a delta-CRL is issued. The advantage is that clients that
can not process delta-CRLs can always obtain the same status information
as those than can process delta-CRLs. The disadvantage is that it
imposes a burden of uploading full CRLs to repositories more often than
may be necessary. On the other hand, just because the CA issues the full
CRLs, this does not mean that clients must retrieve them.

In the end, though, it is mostly a policy decision. If you want to
provide the same support to clients that can not process delta-CRLs as
to those that can, you must issue a full CRL whenever you issue a
delta-CRL. I think the decision should be left to CRL issuers, but will
not complain if PKIX remains as it is.

>3) The text says:
>
>    An application can construct a CRL that is complete for a given
>    scope, at the current time, in either of the following ways:
>
>       (a) by retrieving the current delta CRL for that scope, and
>       combining it with an issued CRL that is complete for that scope
>       and that has a cRLNumber greater than or equal to the cRLNumber
of
>       the base CRL referenced in the delta CRL; or
>
>       (b) by retrieving the current delta CRL for that scope and
>       combining it with a locally constructed CRL whose cRLNumber is
>       greater than or equal to the cRLNumber of the base CRL
referenced
>       in the current delta CRL.
>
>  a) It is hard to understand in which case the base CRL may have a 
>     cRLNumber *greater than* the cRLNumber of the base CRL referenced 
>     in the delta CRL. I certainly miss something here. The equality
case
>     is easy to understand. The "greater than" case is much harder. 
>     Is it really needed ?
>
>  b) the case of a locally constructed CRL is quite stange and it is 
>     questionnable why this case is being mentioned. In the following
fix, 
>     that case has been deleted.

If you want a detailed description on this, you could read my paper on
delta-CRLs, http://csrc.nist.gov/pki/documents/sliding_window.pdf, but
I'll try to briefly explain here.

Suppose that delta-CRLs are issued once an hour. For example, suppose
that a base CRL, CRL number 5, was issued at midnight and that every
hour for the next 24 hours, delta-CRLs were issued with a BaseCRLNumber
of 5. If a relying party performs its first validation at 3:10am, it
would the full CRL issued at midnight and the delta-CRL issued at 3:00am
(CRL number 8). It would combine these to construct full CRL number 8.
In this case, the CRL number of the full CRL used in combination with
the delta-CRL would be the same as the BaseCRLNumber in that delta-CRL.

A few hours later, at 6:30am, the relying party performs another
validation. The relying party has, in its local cache, the contents of
CRL number 8 (which it constructed at 3:10am). It wants to update the
information in its local case to based on the newly available revocation
information. So, it obtains the latest delta-CRL. This delta-CRL has a
CRL number of 11 and a BaseCRLnumber of 5. Since it has a BaseCRLNumber
of 5, the delta-CRL provides status information for all certificates
whose status has changed since CRL number 5 was issued. (midnight). So,
clearly the delta-CRL provides status information for all certificates
whose status has changed since 3:00am when CRL number 8 was issued.
Thus, the relying party can combine the delta-CRL with its locally
cached version of full CRL number 8 to obtain the contents of CRL number
11. This is a case where the CRL number of the complete CRL used is
greater than the BaseCRLNumber specified in the delta-CRL.

There are other reasons why the two numbers may not match, but I will
not go into them. If you are interested, you can read my paper.

>Finally we should explain what happens at the boundaries, i.e. when a
CA
>decides to generate a (new) base CRL. Here is a text proposal:
>
>   When issuing a base CRL that supports a delta-CRL mechanism then the

>   CRL Issuer MUST at the same time issue a delta CRL that points to
that 
>   base CRL. This first delta CRL will usually be empty (or will
include 
>   last-minute additions to the base CRL).

This is not acceptable. The rule is that when a base CRL is issued a
delta-CRL must be issued that has the same cRLNumber. The base CRL
referenced by the delta must either be the previously issued base CRL or
a base CRL issued before that one. Since the new base and the delta must
have the same cRLNumber, there can be no differences as a result of
"last-minute additions to the base CRL".

>Suppose we issue a base CRL every midnight. The question is whether we
>should issue a delta and, if yes, does this delta refer to the previous
>base or to the new one ?

The delta must refer either to the previous base or a base issued before
the previous base.

>Suppose it refers to the previous one. According to the current
sentence:
>"The constructed CRL has the CRL number specified in the CRL number
>extension found in the delta CRL used in its construction.", it is
>impossible. If that was the case the delta CRL would have a CRL number
equal
>to the base CRL and it is not allowed for two CRLs to have the same CRL
>number.

I think you are confusing two different extensions. The
deltaCRLIndicator extension contains a BaseCRLNumber which is used to
determine against which base CRLs the delta-CRL can be applied. The
cRLNumber extension specifies the CRL number of the full CRL that will
be generated by applying the delta-CRL to a base CRL. The sentence above
states that the CRL number of the constructed CRL is taken from the
cRLNumber extension, not the BaseCRLNumber of the deltaCRLIndicator
extension.