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

["Housley, Russ" <[e-mail]>]

Denis:

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

This point has already been discussed.  If there are two CRLs with the same
number, then they contain the same list of revoked certificates
(potentially with different nextUpdate information).  This point has been
beat to death, and I do not hear anyone besides you that thinks this is an
issue.

If others agree with Denis and have kept quiet because they feel that he is
a good spokesman, now is the time to speak up.  To me, and the PKIX WG
chairmen, it seems that Denis is a lone voice on this issue.  If it is not
so, yell now!

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

I do not believe that an application that supports delta CRLs MUST be able
to combine historical complete CRLs with historical delta CRLs.  In my
mind, this is clearly optional.

> > >This is the issue about "most current".
>
>[snip]
>
> > Fine.  I changed it to "... equal to or greater than ..."
>
>Thank you.

You are welcome.

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

Unless you can show that it is incorrect, I suggest that we move on.

> > > > 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 is my belief that implementations MUST be able to validate certificates
based on the current time, but that support for historic time values is
optional.  Tim and I need to collaborate on some text to make this point clear.

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

Denis, I think you missed my point.  And, maybe I am missing yours too.

A delta CRL identifies the associated base with a CRL number.  This is the
only mechanism, there are no others.  Therefore, for a locally constructed
complete CRL to be subsequently updated by a later delta CRL, we must know
what CRL number to assign it.

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

Again, it is my belief that implementations MUST be able to validate
certificates based on the current time, but that support for historic time
values is optional.  Thus, support for the validation of historical delta
CRLs with historical certificates is also optional.  There are many
applications of certificates and CRLs where such features will never come
into play, so they should not be mandated by this profile.

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

I disagree.

Russ