Re: I-D ACTION:draft-ietf-pkix-new-part1-07.txt

[Denis Pinkas <[e-mail]>]

Russ,

>> I do think it is a major advantage to be able to use unique numbers so that
>> if I say "CRL 12345", only one CRL can be retrieved for a given CRL scope
>> and CRL Issuer. In this way references to CRLs can easily be used and only
>> the right CRLs may be stored or fetched in some repositories.
 
> We have achieved this goal.  CRL 12345 represents a specific set of revoked
> certificates.  The relying party might determine the membership of that
> list in more than one way (complete CRL, delta CRL combined with a previous
> complete, or delta CRL combined with a locally constructed complete), but
> in each case the membership of the list will be identical.

I do not think so. You are not looking at the problem in the same way. I
looked at it in terms of objects stored, whatever their content is. If I ask
to retrieve CRL 12345 from a repository, with your approach, I could
retrieve TWO CRLs and not a single one. Thus If I want to make sure that CRL
12345 is stored, with your approach, the answer could be yes, but without
additional information it would be impossible to know whether it is the full
CRL or the delta-CRL with the same number.

I do understand that you want this property, but I do insist to say that
this not necessary. See later for additional explanations.

> > > >    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.
> > >
> > > I believe that this paragraph says the same thing as:
> > >
> > >     An application that supports delta CRLs MUST be able to construct a
> > >     current complete CRL by combining a previously issued complete CRL
> > >     and the most current delta CRL.

Equivalent, ... except that one sentence is only applicable for the current
time t, while the other is applicable at time t and a time T in the past.
So, this is not equivalent.

> >This is the issue about "most current".
> >
> > > When taken in the context of other previous paragraphs, which impose
> > > important profile restrictions that are not handled in your paragraph:
> > >
> > >     A complete CRL and a delta CRL MAY be combined if the following four
> > >     conditions are satisfied:
> > >
> > >        (a)  The complete CRL and delta CRL have the same issuer.
> >
> >This was so obvious that it is was said, but you are right, we have to be
> >very explicit.
> 
> In the PKIX profile, we are not allowing the complete CRLs to be issued by
> one CRL issuer and the delta CRLs to be issued by another.  The complexity
> on the relying party would be significant.
> 
> > >        (b)  The complete CRL and delta CRL have the same scope.  The two
> > >        CRLs have the same scope if either of the following conditions are
> > >        met:
> > >
> > >           (1)  The issuingDistributionPoint extension is omitted from
> > >           both the complete CRL and the delta CRL.
> > >
> > >           (2)  The issuingDistributionPoint extension is present in both
> > >           the complete CRL and the delta CRL, and the values for each of
> > >           the fields in the extensions are the same in both CRLs.
> >
> >I have no problem with this either.
 
> Good.
 
> > >        (c)  The CRL number of the complete CRL is greater than or equal
> > >        to the BaseCRLNumber specified in the delta CRL.  That is, the
> > >        complete CRL contains (at a minimum) all the revocation
> > >        information held by the referenced base CRL.
> >
> >Besides the fact that I prefer to say "equal or greater than" rather than
> >"greater than or equal", because the normal case is "equal" and not "greater
> >than", it makes the same result.
 
> Fine.  I changed it to "... equal to or greater than ..."

Thank you.

 
> > >        (d)  The CRL number of the complete CRL is less than the CRL
> > >        number of the delta CRL.  That is, the delta CRL follows the
> > >        complete CRL in the numbering sequence.
> >
> >This is not wrong, but I am not sure this condition is needed. If you pick
> >the "right" delta, then clause (c) is self-sufficient.
> 
> Tim and I discussed this point.  We recognize that it might be a bit
> tutorial.  We felt that it might help to avoid errors in implementations
> done by people less involved in the PKI standards community than you.

I still think this text is unnecessary.

> > > So, we are back to the definition of current.  We actually use the word
> > > current in two contexts.  First, we require CRL issuers to include the
> > > "current revocation status."  I think that this is simply the dictionary
> > > definition.  Here is the definition from one that I can cut-and-paste from:
> > >
> > >          current
> > >
> > >          adjective
> > >
> > >          1.existing now: happening, existing, or in force at the present
> > >          2.valid: accepted as legally valid
> > >          3.presently accepted: widely known, accepted, or believed
> > >          4.FINANCE up-to-date with payments: having made all the
> > >                  payments required for the present time
> > >
> > >          Encarta (r) World English Dictionary (c) & (P) 1999 Microsoft
> > Corporation.
> > >           All rights reserved. Developed for Microsoft by Bloomsbury
> > Publishing Plc.
> >
> >I wished you used a "true" Dictionary like the Oxford Dictionary, the Colins
> >Dictionary or the Harraps Dictionary.
> 
> Like I said, I picked one from which I could easily cut-and-paste the text.
> 
> I could also have used www.m-w.com, but that is not on list of Denis
> approved dictionaries either...
> 
> > > The second context involves applications.  Here we say: "construct a
> > > current complete CRL."  Again, I think that the dictionary definition is
> > > fine.  However, we also say that applications use the "most current delta
> > > CRL."  Perhaps we could help the reader here.  To this end, I propose the
> > > addition of a sentence:
> >
> > >     A delta CRL is considered to be the most current one, if and only if
> > >     the current time is between the times contained in the thisUpdate
> > >     and nextUpdate fields.
> >
> >I believe this is fine for real-time transactions. However, for NR, reading
> >again the arguments raised by Tom Guidin and James Manger, we might come to
> >different conclusions. I prefer to think a little bit more about it.
 
> In Section 6, we do not offer any details about retrospective
> algorithms.  Rather, we say that the algorithm can be adjusted by the
> implementor to handle more than just the current time.  I do not see any
> reason to do otherwise in this section.

The current text is as follows:

6.1.1  Inputs

   This algorithm assumes the following seven inputs are provided to the
   path processing logic:

      (a) a prospective certification path of length n;

      (b) the time, T, for which the validity of the path should be
      determined.  This may be the current date/time, or some point in
      the past.

>From that text, it is clear that some point in the past is equally adressed.
If this is not the case, then this text is misleading and thus we should
have something like:

      (b) the time, T, for which the validity of the path should be
      determined.  This must be the current date/time. The case of 
      some point in the past is not addressed in this section.

 
> > > >    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
> > >
> > > I must point out that you use the word current, and the dictionary meaning
> > > is quite sufficient.
> > >
> > > This is covered by the following, with the above definition of "most
> > current":
> > >
> > >     An application that supports delta
> > >     CRLs MAY also be able to construct a current complete CRL by
> > >     combining a previously locally constructed compete CRL and the most
> > >     current delta CRL.
> > >
> > > >       (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.
> > >
> > > This is covered by the same sentence.  I do not see any reason to separate
> > > these cases.  We clearly tell the implementor how to number locally
> > > constructed CRLs:
> >
> >Numbering locally CRLs is a local feature that should not be mentioned. It
> >is important to say how to use external information. If, it ends up that the
> >local numbering does the same job, that's fine, but it is certainly not the
> >single way to do it. So I would use the equivalence in the reverse
> >direction: we should define an algorithm that says how to use external
> >elements independant of any local convention. If it happens that the
> >algorithm using local numbers provides the same result, that's fine, but
> >should not be part of the standard.
 
> I disagree.  When a delta CRL is used to update a complete CRL (whether
> that complete CRL was obtained directly from the CRL issuer or it was
> locally constructed) the resulting CRL number MUST be known for that
> locally constructed CRL to be further updated by subsequent delta CRLs.

No. Take a look again at the wording I have used, where you can avoid this
local numbering. Instead of saying the locally constructed CRL has number X,
it tells you exactly what king of information shall be maintained whith each
locally constructed CRL so that it is possible to make sure whether it fits
or not.

"... 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

... 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." 

 
> >Now the reason to separate the two cases is that before using a locally
> >constructed CRL you have to build it, this is covered by the MUST statement.
> >Using locally constructed CRLs is an optimization that does not need to be
> >supported. Hence why it is covered under a MAY statement. In other words, an
> >implementation may be conformant without the need to implement the
> >optimization case.
 
> We agree.  That is handled in a different paragraph.  With the sentence
> that I agreed to add, the paragraph that I am referring to reads:
> 
>     An application that supports delta CRLs MUST be able to construct a
>     current complete CRL by combining a previously issued complete CRL
>     and the most current delta CRL.  An application that supports delta
>     CRLs MAY also be able to construct a current complete CRL by
>     combining a previously locally constructed compete CRL and the most
>     current delta CRL.  A delta CRL is considered to be the most current
>     one, if and only if the current time is between the times contained
>     in the thisUpdate and nextUpdate fields.

If I include the modifications proposed by Dave and Tom, this should now
lead to the following:

   An application that supports delta CRLs MUST be able to construct a
   current complete CRL by combining a previously issued complete CRL
   and the most current delta CRL. An application that supports delta
   CRLs MAY also be able to construct a current complete CRL by
   combining a previously locally constructed compete CRL and the most
   current delta CRL. A delta CRL is considered to be a current one if 
   the current time is between the time contained in the thisUpdate and
   nextUpdate fields. If more than one current delta CRL for a given scope 
   is encountered, the application MUST consider the one with the latest 
   value in thisUpdate to be the most current one; while if only one 
   current delta CRL for a given scope is encountered, the application 
   MUST consider it to be the most current one.

However, this text is not sufficient and only valid for a current time and
not a time in the past, ... while the text I am still proposing is valid for
the current time and a time T in the past. See above.

> > >     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.
> >
> >We do not need to locally number the CRLs. The "equivalent" algorithm I have
> >provided does not need that local numbering. It is a local matter issue,
> >that is *not* needed by the algorithm. This explains you the reason of the
> >wording I have used under the MAY statement.
 
> I have already addressed this above.  We already say that any algorithm
> that provides the same results is sufficient.  However, this is needed if
> subsequent delta CRLs are going to be applied to the resulting locally
> constructed complete CRL.

I believe that I have demonstrated that this is not needed.

Denis
 
> Russ