[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft delta crl text
David,
(snip)
> I disagree with each of the points raised by Denis; comments appear
^^^^
> interspersed below.
Not really, since you have deleted the most important part of the text
without providing *any* argument against it.
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.
> Regards,
> Dave
> > I browse through it and I still have a MAJOR problem with the CRL numbering.
> >
> > The two following sentences are contradictory:
> >
> > The CRL number is a non-critical CRL extension which conveys a
> > monotonically increasing sequence number for a given CRL scope and
> > CRL issuer.
> >
> > I agree with the above sentence.
> >
> > If a delta CRL and a complete CRL that cover the
> > same scope are issued at the same time, they MUST have the same CRL
> > number.
> >
> > This contradicts the first sentence.
>
> No, for two reasons.
>
> As previously discussed, monotonically increasing means "non-decreasing";
> it does not mean "strictly increasing". I would support replacing
> "monotonically increasing" with "non-decreasing" if necessary for clarity.
See my other message to Santosh on that point about unique CRL numbers for
CRLs.
> 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.
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.
> To do otherwise would make running delta CRLs
> impossible - a delta contains a baseCRLNumber, and for at least some
> subset of CRL numbers, applications must be able to download either a
> full CRL or a delta CRL to use as a base.
Doing otherwise is indeed possible using unique CRL numbers. thisUpdate and
nextUpdate MUST be used.
> > ======================================================================
> >
> > I do have problems with MANY other sentences, like:
> >
> > If a CRL issuer generates delta CRLs in addition to complete CRLs for
> > a given scope, the complete CRLs and delta CRLs MUST share one
> > numbering sequence.
> >
> > What does "the same numbering sequence" mean ? This sentence is useless and
> > should be deleted.
>
> It seems obvious to me that this sentence prohibits complete CRLs numbered
> 1,2,3, ... and delta CRLs for the same scope at the same respective times
> numbered 1001, 1002, 1003, ... If completes and deltas for a given scope
> could be in different numbering sequences, then this example would not violate
> the monotonically-increasing requirement.
>
> The sentence must stay.
Thanks for the example, I now understand what was intended. However this is
not necessary. The way I have formulated the processing rules does not need
to take advantage of this property. So this sentence can be deleted (see the
text at the top of this e-mail).
> > ======================================================================
> >
> > The combination of a CRL containing the delta CRL indicator
> > extension plus the CRL referenced in the BaseCRLNumber component
> > of this extension is equivalent to a complete CRL, for the
> > applicable scope, at the time of publication of the delta CRL.
> >
> > The right wording should be:
> >
> > The combination of a delat CRL (containing the delta CRL indicator
> > extension) plus the CRL referenced in the BaseCRLNumber component
> > of this extension is equivalent to a complete CRL, for the
> > applicable scope, that is valid between this Update and nextUpdate
> > from the delta CRL.
>
> No. A CRL is valid precisely at the time of publication. It is
> not "valid" one second later because it might have been superseded.
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.
> > ======================================================================
> >
> > When a delta CRL is combined with a complete CRL or a locally
> > constructed CRL, the resulting locally constructed CRL has the CRL
> > number specified in the CRL number extension found in the delta CRL
> > used in its construction.
> >
> > The right wording should be:
> >
> > When a delta CRL is combined with a complete CRL or a locally
> > constructed CRL, "The resulting locally constructed CRL is equivalent
> > to a complete CRL that would have thisUpdate and nextupdate respectively
> > equal to thisUpdate and nextUpdate from the delta CRL."
> I don't disagree with the second wording, but it is irrelevant.
Fine. So you can live with it. :-)
> The first
> wording is both correct and relevant to the issue of how the constructed
> CRL may be used as a base for a future constructed CRL.
The second wording does not make use the CRL numbering, hence why it is
there.
Regards,
Denis