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

From: Denis Pinkas <[email-masked]>
Date: Mon, 02 Jul 2001 11:09:21 +0200

Russ,

> Denis:
> 
> I have discussed my response with Tim Polk.  While he has not reviewed the
> text of this message, he did agree with my verbal outline of this message.
> 
> I believe that your note is about two issues.  The first issue is the a
> requirement that a locally constructed CRL be assigned a specific CRL
> number.  The second issue is the rules for combining a delta CRL and a
> complete CRL.  These two are interwoven, and they cannot be addresses
> separately.
> 
> We want there to me a single mechanism for determining whether or not a
> delta CRL can be combined with a given complete CRL.  In order for these
> rules to be the same for complete CRLs issued by CRL issuers and for
> locally constructed complete CRLs, then applications must know what CRL
> number to associate with locally constructed complete CRLs.  This is the
> reason that we have a MUST statement regarding these numbers.

On page 56 of draft-ietf-pkix-new-part1-07.txt, the text uses MAY: 

   A complete CRL and a delta CRL MAY be combined if the following four
   conditions are satisfied:

I have also used MAY to be as close as possible with that text.
If you refer to a different statement, please clarify.
 
> Your proposal includes two separate rule sets, one to determine if it is
> appropriate to combine a delta CRL with a complete CRLs issued by the CRL
> issuer, and one to determine if it is appropriate to combine a delta CRL
> with a locally constructed complete CRL.  This complexity is avoided by
> telling applications how to number a locally constructed complete CRL.  In
> this way, one rule does the job for both situations.

I do not believe that two lines of text add complexity. These two lines are:

  (d)  The local CRL number of the locally constructed CRL is equal
       to or greater than the BaseCRLNumber specified in the delta CRL.

Local CRL numbers are purely artificial and even Trevor Freeman is quite
validly questioning the real interest to have a CRL number for a delta-CRL.
As he said, thisUpdate is quite sufficient. A different algorithm could be
constructed by locally remembering the "thisUpdate" from the CRLs and the
delta.

In this way we could even have a CRL number that is purely unique (as the
certificate number is), without having any monotonocally increasing or
strictly increasing property.

This would lead to option D:

   The CRL number is a non-critical CRL extension which conveys a
   unique number for a given CRL scope and CRL issuer. CRL issuers 
   conforming to this profile MUST include this extension in all CRLs.

Only for reasons of backward compatibility, I will not push this proposal,
but we have to understand that CRL numbers have an unneeded and overloaded
semantics. So why we should make clear that local CRL numbers are no more
than ONE way to implement an algorithm that could also be implemented using
thisUpdate. Saying that using an algorithm that exhibits the same properties
would be equally valid is not enough, because the reader will understand
that the algorithm has to use CRL numbers. It would help to say that an
algorithm using thisUpdate could also be constructed.

> Tim working on an update to Appendix C.  Once he completes this update, he
> will post an updated Internet-Draft.  

Before he does this, I would really appreciate that he sends to the list a
revised text for sections 5.2.3 and 5.2.4 taking into account what has been
posted on this thread.

> We hope that we have captured
> consensus of the working group with our words.  We hope that everyone can
> live with the content of the updated document, even if they are not
> completely happy with every sentence.  (Standards occur when everyone is
> equally unhappy, not when everyone is equally happy.)

Now, let me say once again a point: the issue of identical CRL numbers
could also be nicely solved by not allowing to issue a base CRL and a delta
CRL exactly at the *very same* second. 

This is option C, and not option B, as I wrongly mentioned in my last
e-mail.

Denis

> Russ
> 
> At 06:27 PM 6/29/2001 +0200, Denis Pinkas wrote:
> 
> >Tom and Russ,
> >
> > >      I don't know if this will be considered helpful or not.
> >
> >Yes, it is helpful and thank you for your explanations. This allows me to
> >respond to the second part of the e-mail from Russ as well.
> >
> >We all agree that the construction of a CRL using a delta CRL in the past is
> >only an option and thus the text has to use MAY and not MUST.
> >
> >Having said that, when the application wants to do such a construction in
> >the past, we should give some guidance, and this is what you have done
> >below, using a MAY.
> >
> > > 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.
> >
> >I have some problems with this text, first with "most current" and then with
> >the two last MUST. I propose the following fix:
> >
> >  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 a delta CRL valid as of T.
> >  A delta CRL is considered to be valid at 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 SHOULD 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 SHOULD
> >  consider it to be the most current one. Note that if two delta CRLs, valid
> >  at time T, are placed in a repository, unless additional security measures
> >  are taken, there is no guarantee that both will necessarilly be seen.
> >
> >Note that in order to close this issue, we still need to agree on the
> >set of conditions to use the full CRL or the locally constructed
> >CRL to be used with the delta CRL.
> >
> >Russ said: "Denis, I think you missed my point.  And, maybe I am missing
> >yours too." I think we can both agree on this statement. :-)
> >
> >So using the text from draft-ietf-pkix-new-part1-07.txt I have tried to show
> >which wording could be used:
> >
> >Making a small fix to section 5.2.4, we could say:
> >
> >    When a delta CRL is combined with a complete CRL or a locally
> >    constructed CRL, the resulting locally constructed CRL is equivalent
> >    to a full CRL which would have a local CRL number equal to the CRL
> >    number specified in the CRL number extension found in the delta CRL
> >    used in its construction. In addition, the resulting locally constructed
> >    CRL has the thisUpdate and nextUpdate times specified in the
> >    corresponding fields of the delta CRL used in its construction.
> >    In addition, the locally constructed CRL inherits the issuing
> >    distribution point from the delta CRL.
> >
> >This means that we could solve the issue by saying:
> >
> >A complete CRL or a locally constructed CRL and a delta CRL MAY be combined
> >if:
> >
> >       (a)  The complete or locally constructed CRL and delta CRL have the
> >            same issuer.
> >
> >       (b)  The complete or locally constructed 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 CRLs.
> >
> >          (2)  The issuingDistributionPoint extension is present in both
> >               CRLs, and the values for each of the fields in the
> >               extensions are the same in both CRLs.
> >
> >       (c)  The CRL number of the complete CRL is equal to or greater
> >            than the BaseCRLNumber specified in the delta CRL; or
> >
> >       (d)  The local CRL number of the locally constructed CRL is equal
> >            to or greater than the BaseCRLNumber specified in the delta CRL.
> >
> >
> >One sentence should be moved from 5.2.3 to 5.2.4, since this is specific
> >with deltas, i.e:
> >
> >    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.
> >
> >... while the issue of identical CRL numbers could also be nicely solved but
> >not allowing to issue a base CRL and a delta CRL exactly at the very same
> >second. This is, if I remember correctly, one option with which Tim Polk
> >could live with. This is implied by option B.
> >
> >Denis
> >
> >
> >Annex for Russ only: Hereunder some text that I have been using before
> >making the above proposal. This shows that we do not need to use a local CRL
> >numbering. I also believe that clause (f) is clearer than the current text,
> >but in order to try to close the discussion, I have as close as possible to
> >the text from draft 07.
> >
> >A complete CRL or a locally constructed CRL and a delta CRL MAY be combined
> >if, first, the following two conditions are satisfied:
> >
> >       (a)  The complete or locally constructed CRL and delta CRL have the
> >            same issuer.
> >
> >       (b)  The complete or locally constructed 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.
> >
> >In addition, a complete CRL and a delta CRL MAY be combined if, the
> >following two other conditions are satisfied:
> >
> >       (c)  The CRL number of the complete CRL is equal to or greater
> >       than 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.
> >
> >       (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.
> >
> >       [If we now place the new text to say how to pick the right
> >       delta-CRL, and unless the CA is not conformant with section 5.2.3 !,
> >       the text under (d) is unnecessary, but I left it for the time being]
> >
> >In addition, a locally constructed CRL and a delta CRL MAY be combined if,
> >the locally constructed CRL has been build using a full CRL that has a
> >cRLNumber either:
> >
> >       (e)  equal to or greater than the base CRL number referenced
> >       in the delta CRL; or
> >
> >       (f) lower than the base CRL number referenced in the delta CRL,
> >       provided that the delta CRL that has been used to make the
> >       construction has a CRL number greater than the base CRL number
> >       referenced in the delta CRL.
> >
> >===================================================================
> >
> > >      Please note that I am NOT suggesting any particular handling for
> > > certificateHold or removeFromCRL.
> > >
> > >           Tom Gindin
> > >
> > > "Housley, Russ" <[email-masked]>@mail.imc.org on 06/28/2001
> > > 05:18:33 PM
> > >
> > > Sent by:  [email-masked]
> > >
> > > To:   Denis Pinkas <[email-masked]>
> > > cc:   [email-masked]
> > > 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

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 02 Jul 2001 11:07:18 +0200

Tom,

(snip)

> I have some problems with this text, first with "most current" and then
> with the two last MUST. I propose the following fix:
 
>  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 a delta CRL valid as of T.
 
 [Tom] I'll leave SHOULD vs. MUST for Russ, although I don't understand what
 would lead a retrospective verifier to use the second or third most current
 delta CRL rather than the most current, if he recognizes them as such.
 Your last sentence is helpful, although I don't think that the measures
 which guarantee both deltas being seen are security measures.  The most
 common reason to only see one would be an LDAP client implementation which
 only picked up one value of a multi-valued attribute.

The most common reason to only see one CRL has nothing to do with LDAP.
The reasons are among the following:

  a) the administrator of one of the repositories where the CRLs are
    replicated has purposely suppressed some CRLs. This is a suppression 
    while in storage.

  b) during the replication process some CRLs have been removed. This is
     a suppression while in transit.

X509 does NOT rely on the security of the repositories (called Directories)
or of their administrators. 

Denis

(snip)