[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft delta crl text
> Denis,
> We have different, incompatible, ways of looking at CRLs. I accept
> that the difference exists, but prefer to continue with my way.
I have had some talks with Tim Polk and David Cooper. We have all progressed
in the understanding. I have sent a new text proposal, but since I got no
response, I have observed that placing the proposal on the PKIX mailing list
usually triggers more rapid responses. :-)
> > Here is this text again (without the previous text):
> >
> > An application that supports delta CRLs can construct a CRL that is
> > complete for a given scope, at a given time T, in either of the
> > following ways:
> >
> > (a) by retrieving a delta CRL for that scope where the time T
> > is between thisUpdate and nextUpdate, and combining it with a CRL
> > that is complete for that scope and that has a cRLNumber equal or
> > greater than to the base CRL number referenced in the current
> > delta CRL; or
> >
> > (b) by retrieving a delta CRL for that scope where the time T
> > is between thisUpdate and nextUpdate and combining it with a
> > locally constructed CRL that has a content equivalent to a
> > full CRL that would have a cRLNumber equal or greater than
> > to the base CRL number referenced in the current delta CRL.
>
> I don't disagree with these words, although I slightly prefer Tim's less
> pedantic version of (b). Precision is good in a standard, and which of
>
> "a locally constructed CRL whose cRLNuber is ..."
> or
> "a locally constructed CRL that has a content equivalent to a full CRL
> that would have a cRLNumber ..."
>
> is more precise is a matter of personal preference.
>
> The key to my agreement with your (a) and (b) is that they both
> use cRLNumber, not thisUpdate and nextUpdate, to link the delta with
> its base. It appears from your other points that you intend for
> cRLNumber to disappear entirely, and that is where we part company.
We talked about this. It appears that thisUpdate and nextUpdate are the
basis of the processing rule for verifying that the delta CRL is "valid".
However, for making use of already locally constructed CRLs (which is an
optimization that all clients do *not* need to support), the CRLNumber is
necessary (see case 3 below).
Here is the new text proposal:
An application that supports delta CRLs MUST be able to construct
a CRL that is complete for a given scope, at a given time T, by
retrieving a delta CRL for that scope where the time T is between
thisUpdate and nextUpdate, and combining it with a CRL that is
complete for that scope and that has a cRLNumber equal or greater
than to the base CRL number referenced in the current delta CRL.
It MAY also construct a CRL that is complete for a given scope,
at a given time T, in either of the two following ways:
(a) by retrieving a delta CRL for that scope where the time T
is between thisUpdate and nextUpdate and combining it with a
locally constructed CRL that has been constructed using a
full CRL that has a cRLNumber equal or greater than the
base CRL number referenced in the current delta CRL; or
(b) by retrieving a delta CRL for that scope where the time T
is between thisUpdate and nextUpdate and combining it with a
locally constructed CRL that has been constructed using a
full CRL that has a cRLNumber lower than the base CRL
number referenced in the current delta CRL, provided that
the last delta CRL used to construct that local CRL has a CRL
number greater than the base CRL number referenced in the
current delta CRL.
> > > [dpk] More fundamentally, if a delta CRL and a complete CRL are issued at the
> > > same time, they MUST reflect the identical revocation status for each
> > > in-scope certificate. If they reflect the same status, they should have
> > > the same CRL number.
> >
> > [Denis] More fundamentally, if a delta CRL and a complete CRL are issued at the same
> > time, they do *not* necessarilly reflect the same revocation information
> > since their validity periods are not necessarilly identical: i.e. their
> > nextUpdate is not necessarilly the same. Hence they will not necessarilly be
> > applicable during the same time interval. Since they do not reflect the same
> > validity of the information, they certainly should *not* have the same CRL
> > number. See a related coment later on.
>
> My background is in digital signal processing, so I view CRLs as samples
> of a physical process (the revocation events that have been reported
> to a CA and reflected in the CA's internal state). A sample at time T and
> another sample at the identical time T contain the identical information.
> It makes no difference if the next scheduled samples in each series will
> be taken at T + 1 hour and T + 24 hours respectively. The complete CRL at
> time T and the delta CRL at time T should have the same CRL number.
>
> > > [dpk] A CRL is valid precisely at the time of publication. It is
> > > not "valid" one second later because it might have been superseded.
> >
> > [Denis] Certainly not. Take a look at PKIX part 1:
> >
> > This field indicates the date by which the next CRL will be issued.
> > The next CRL could be issued before the indicated date, but it will
> > not be issued any later than the indicated date. CAs SHOULD issue
> > CRLs with a nextUpdate time equal to or later than all previous CRLs.
> > nextUpdate may be encoded as UTCTime or GeneralizedTime.
> >
> > This profile requires inclusion of nextUpdate in all CRLs issued by
> > conforming CAs.
> >
> > This means that a CRL is valid between thisUpdate and nextUpdate.
>
> I respectfully submit that it means nothing of the sort. Consider the
> following CRLs, issued entirely in accordance with PKIX part 1:
>
> cRLNumber: 1 2 3
> thisUpdate: 0900 0910 1500
> nextUpdate: 1500 1500 2100
> cert list: (17, 52) (17, 52, 113) (17, 52, 113)
According to PKIX part 1, the following CRLs would be issued entirely in
accordance with PKIX part 1:
cRLNumber: 1 1 1
thisUpdate: 0900 0910 1500
nextUpdate: 1500 1500 2100
cert list: (17, 52) (17, 52, 113) (17, 52, 113)
:-(
> Notice that certificate 113 was revoked sometime between 9 o'clock and 9:10.
> Notice that according to your definition of "validity", CRLs 1 and 2 are
> both valid at 12:00 noon, but they contain different information with
> respect to certificate 113. Is one of them "more valid" than the other,
> or is it simply the case that CRL 2 is "more recent" than CRL 1?
Both are valid, but if a client one has the CRL from 9:00 a.m. in his cache,
there is no reason why he SHALL fetch a new one. Even, if he does, there is
no guarantee that the one from 9:10 a.m. will ever be obtained (when there
is a denial of service attack).
> Is it your position that unscheduled CRLs should be prohibited?
For real time use, unscheduled CRLs may be useful, but once again there are
not a bullet proof mechanism. If someone wants to use CRLs and make sure
that the freshest revocation information cannot be missed, then delta-CRLs
should be used.
For non repudiation use, unscheduled CRLs should/shall be prohibited because
two clients capturing the same revocation information at the same time,
could gather two different CRLs and since the goal of non repudiation is to
solve disputes, we would have an unsolvable dispute.
> I disagree with that prohibition, and I therefore think it is misleading
> to call the time between thisUpdate and nextUpdate a "validity" period.
See above.
Regards,
Denis
> Regards,
> Dave
>
> P.S. to Tim:
>
> I believe that the sentence:
> "CAs SHOULD issue CRLs with a nextUpdate time equal to or later than
> all previous CRLs"
> should be amended to apply separately to complete CRLs and delta CRLs.
> In other words, I believe the following should be perfectly legitimate
> set of CRLs (they should not violate a PKIX SHOULD):
>
> Complete:
> ----------------------------
> cRLNumber: 100 104
> thisUpdate: Wed 0300 Thu 0300
> nextUpdate: Thu 0300 Fri 0300
>
> Delta for the same scope:
> ----------------------------
> cRLNumber: 100 101 102 103 104
> thisUpdate: Wed 0300 Wed 0900 Wed 1500 Wed 2100 Thu 0300
> nextUpdate: Wed 0900 Wed 1500 Wed 2100 Thu 0300 Thu 0900