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

["David A. Cooper" <david.cooper@xxxxxxxx>]

Denis,

My comments are in line.

At 06:50 PM 4/20/01 +0200, Denis Pinkas wrote:
>[Denis] This is the case I had in mind. However I would disagree to say that
>the locally contructed CRL is equal to the full CRL number 8, because there
>is no need to issue such CRL (see the first comment). It is simply the
>"freshest CRL constructed from the base CRL number 5 for 3:10 am". This
>locally contructed CRL bears no number, or if you assign one, this is a
>local matter and is not part of the standard. This also avoids the later
>confusing between CRL numbers.

This is simply not true. A delta-CRL can (will) contain the cRLNumber extension just as a full CRL will. If a full CRL and a delta-CRL are issued at the same time, the combination of the delta-CRL and an appropriate base CRL must be equivalent to the full CRL, and both the delta-CRL and the full CRL must have the same cRLNumber. If a delta-CRL is issued, and no corresponding full CRL issued, then the combination of the delta-CRL and an appropriate base CRL should be equivalent to the full CRL that would have been issued at that time, if a full CRL had been issued. The delta-CRL should have the same cRLNumber as would have been assigned to a full CRL issued at the same time.

A delta-CRL is nearly the same as a full CRL. It has a thisUpdate, nextUpdate, cRLNumber, etc. just as a full CRL. It just has an incomplete list of revoked certificates.

> > 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.
>
>[Denis] This is a local matter and I would not mandate this in the document
>since there is another and simpler way to do it: you keep in the cache the
>base CRL (instead of the previously recontructed full CRL). This has the
>same end result, except that the method your recommend is not optimum: it
>will include many duplicates and deleting the duplicates is more painfull
>than making a simple addition.

I'm not sure what you are saying is a local matter. The contents of the delta-CRL is not a local matter and must be mandated in the certificate and CRL profile. If you prefer to always apply the delta-CRLs to the referenced base CRL instead of to a locally generated, more recent CRL, that is your choice. The document states that the delta-CRL may be combined with the referenced base CRL or a more recently issued full CRL.

>The basic algorithm is to take the base CRL and to add the delta. This is
>the standard. As soon as you get the same end result this is fine. This is
>the approach we have taken for path validation. Other ways do not need to be
>mentionned.
>
> > 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.
>
>[Denis] I read it (and skipped the mathematical formulas)
>
>This paper is proposing a method for over-issuing the CRLs. It omits to take
>into consideration that in PKIX-1 we mandate the CRL number extension
>(section 5.2.3) so we need to advertise the nextUpdate. If you issue a CRL
>before the next update you have no more way to know which base CRL is the
>freshest CRL. I believe this is a major security weakness and for that
>reason this mechanism should be deprecated.

The paper does discuss over-issuing of CRLs, but there is plenty of information about using delta-CRLs efficiently without over-issuing. Bear in mind, however, that the nextUpdate field only specifies the time by which a new CRL will be issued. Many people intend to issue a new CRL whenever a revocation occurs (or a revocation for key compromise) without waiting until the regularly scheduled time.

>BTW, the same security problem would occur as soon as a base would be used
>for every delta. Hence another good reason to delete the sentence which
>originally triggered all this discussion.

I don't understand this at all.

>BTW, I noticed that you have precisely deleted from my previous e-mail all
>the text dealing with this nextUpdate. :-( 
>
>So I am still insisting on the major text change to make to that section:
>
>    An application can construct a CRL that is the most current for 
>    a given scope, at the current time, by retrieving the current 
>    base CRL for that scope, and combining it with a delta-CRL which 
>    contains a Delta CRL Indicator equal to the cRLNumber of the base 
>    CRL and where the current date from that delta-CRL is between 
>    thisUpdate and nextUpdate;
>
>It is important to notice that the algorithm does NOT use the individual CRL
>numbers assigned to the delta-CRLs, but uses instead thisUpdate and
>nextUpdate. This is *very* important.

I thought I did respond to this. First, one should expect that delta-CRLs will always be at least as recent as base CRLs. So the first step should be to obtain the current delta-CRL. Next, one obtains a base CRL that can be used in combination with that delta-CRL. You may choose to only use the full CRL whose cRLNumber is equal to the BaseCRLNumber specified in the delta-CRL, however, any full CRL with a cRLNumber greater than or equal to the BaseCRLNumber is acceptable. Since the cRLNumber of the base can be greater than the specified BaseCRLNumber, the document should say so. There is no need to state that the current time must be after the thisUpdate time in the delta-CRL as this will always be true by construction. Finally, since a CRL issuer may issue "emergency" delta-CRLs, there is no guarantee that any delta-CRL whose nextUpdate time is later than the current time is the most current delta-CRL.

> > >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".
>
>[Denis] This does not work. Let me explain it differently. Suppose that
>during the week you do not generate delta-CRLs but for the week-end you
>decide to do it (e.g. more risk, more transactions done by citizens). So you
>issue a CRL with the freshest CRLindicator. You say that the delta points to
>the previous base CRL. The one from yesterday or the one from last week ? 
>In either case this simply does not work.

Why? A delta-CRL must include a BaseCRLNumber that corresponds to a CRL that was issued at some time in the past.

>The rule you mention, i.e. "The rule is that when a base CRL is issued a
>delta-CRL must be issued that has the same cRLNumber" is also wrong. The
>notion of a base CRL that would have the same number as a delta does not
>exist.
>
> > >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.
>
>[Denis] Certainly not. Your paper however provides the right answer
>(on page 1): " A delta-CRL is a CRL that only provides information about
>certificates who statuses have changed since the issuance of a specific,
>previously issued CRL".

Where is the difference? A CRL that is referenced in the BaseCRLNumber of a delta-CRL is by definition a base CRL.

> > >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.
>
>[Denis] I do not think I make a confusion. The confusion comes from the
>numbering you introduce (see my earlier comment).
>
>Let me conclude:
>
>1) I do not have the time to spend hours of discussions on that topic.
>However the current text needs to be corrected and I have provided text
>for this. Please take again a look at it in the light of the following.
>
>2) In your paper you advertise the "traditional delta-CRLs". Let us stay in
>the tradition and let us mandate the implementation of the "tradition" if
>someone wans to support the delta-CRL mechanism.
>
>Any other method would first need to be proven to be secure (over-issuing
>CRLs and sliding window delta-CRLs have security problems) and should
>*anyway* fall in the MAY category, so that noone needs to implement to claim
>conformance with the delta CRL mechanism. Standard track documents need to
>make choices among multiple methods, otherwise two different implementations
>will never interoperate.

you say that you want to stick with "traditional" delta-CRLs, however you are proposing changes to the text that would not result in "tradtional" delta-CRLs but would result in broken implementations. We do not prevent people from implementing "traditional" delta-CRLs, but we should not force them to either. There are no security problems with sliding window delta-CRLs and they do not add any complexity for those who choose not to implement them.

I want to be sure that the delta-CRL text is correct just as you do, but I still feel that many of your comments are based on a misunderstanding and are not based on actual problems in the text.

Dave