[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 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.
[Denis] Since you are "not a big fan of this requirement" and no other fan
has been found up to now, let us suppress that sentence.
> 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.
[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.
> 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.
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.
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.
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.
> >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.
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".
> >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.
Regards,
Denis