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

["Tom Gindin" <[e-mail]>]

     I don't know if this will be considered helpful or not.  While
retrospective verification is certainly not a mandatory feature of RP
software, there is a method for retrospective validation which is
compatible with the proposed wording in part1.  (Please note that there's a
typo in that paragraph: 'compete' should be 'complete').  In the proposed
paragraph below, the terms 'current' and 'most current' are given meanings
fully compatible with those in the proposed paragraph in part1 - a
'current' delta CRL in the sense of that proposal is a 'current' one as of
the present time in the sense of this.  I have not included the internal
CRL possibility for retrospective validation, as it seems pointless in such
a case.

An application that supports delta CRLs MAY be able to construct a complete
CRL for a reference time T prior to the current time by combining a
complete CRL issued no later than T and the most current delta CRL as of T.
A delta CRL is considered to be a current one as of a given time T if T is
between the times contained in the thisUpdate and nextUpdate fields. If
more than one current delta CRL for a given scope as of T 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 as of T is encountered, the application MUST consider it to be the
most current one.

     Please note that I am NOT suggesting any particular handling for
certificateHold or removeFromCRL.

          Tom Gindin


"Housley, Russ" <[e-mail]>@mail.imc.org on 06/28/2001
05:18:33 PM

Sent by:  [e-mail]


To:   Denis Pinkas <[e-mail]>
cc:   [e-mail]
Subject:  Re: I-D ACTION:draft-ietf-pkix-new-part1-07.txt



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