Re: draft delta crl text

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

Denis,

We have different, incompatible, ways of looking at CRLs.  I accept
that the difference exists, but prefer to continue with my way.



Denis Pinkas wrote:
> 
> 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.



> 
> > [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)

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?

Is it your position that unscheduled CRLs should be prohibited?  I disagree
with that prohibition, and I therefore think it is misleading to call
the time between thisUpdate and nextUpdate a "validity" period.

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