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

From: Ambarish Malpani <[email-masked]>
Date: Fri, 22 Jun 2001 13:17:02 -0700

Hi Denis,
    If a CRL and delta CRL are meant to represent the same CRL/
same revocation data, it makes more sense to me if the have
the same CRLNumber.

If I ever want to distinguish between them, I can always refer to
the "full CRL with CRLNumber x" or the "delta CRL with CRLNumber x"
(or for that matter, "delta CRL with CRLNumber x, off the base
CRL with CRLNumber y")

Requiring people to have 2 different names for something that
represents the same thing is wrong IMHO.

My 2 c.

Regards,
Ambarish

P.S. I still need to go through all the other points....

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Friday, June 22, 2001 9:57 AM
> To: Housley, Russ
> Cc: [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-pkix-new-part1-07.txt
> 
> 
> 
> Russ,
>  
> > Denis:
> > 
> > I believe that you are addressing a single issue in this 
> posting, that is
> > the meaning of current.  If there are other, less obvious 
> points, please
> > identify them.
> 
> Two issues:
> 
> 1) CRL numbering,
> 2) meaning of "current" or more exactly how to validate for a time t
>   (current time) or a time T (validation time for NR).
> 
> > I am grateful for proposed replacement text.  I makes the 
> editor's job much
> > easier when specific changes are proposed.
> 
> You are welcome. :-)
> 
> > >Since David Copper said that it is possible to issue a 
> delta CRL at a time
> > >that is different from the time a full CRL is issued (even 
> one second
> > >difference), then duplication of CRL numbers can be 
> avoided. This is fine
> > >since, in this way, it is possible to use a CRL number to 
> uniquely identify
> > >a CRL.
>  
> > Yes.  A CRL issuer can be compliant by issuing complete 
> CRLs and delta CRLs
> > that have unique CRL numbers (strictly increasing).  
> However, A CRL issuer
> > can also be compliant by issuing a complete CRL and a delta 
> CRL with the
> > same CRL number and the same thisUpdate time (monotonically 
> increasing).  I
> > do not think further discussion on this point is necessary 
> or productive.
> 
> 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.

... [Lots of stuff deleted]

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 28 Jun 2001 16:40:45 -0400

Denis:

I do not understand your point at all.  Delta CRL (according to LDAP and
X.500) schema is stored in a different attribute.  So, you will retrieve
what attribute you query.

In terms of some one able to replay other attributes, deltaCRLIndicator is a
critical extension within the signed envelop of the CRL and hence the
relying party client should be able to detect the replay.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Thursday, June 28, 2001 10:14 AM
To: Housley, Russ
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-new-part1-07.txt

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

---

From: "Tom Gindin" <[email-masked]>
Date: Fri, 29 Jun 2001 16:10:22 -0400

I'm not sure what protocol would typically be used to retrieve CRL's
for retrospective validation, if the reference time is more than a day or
two old.  If the reference time is far back, the old CRL's would probably
not be available from the HTTP or FTP locations in the distribution point
extensions - those would have been overwritten.  A local database in the CA
would be likelier to have this stuff - but that would return multiple
values for a query just as LDAP would.  In the TechNR draft, I suggested
that the responsible party (either the RP or the escrow holder) would
archive them himself and present them to the retrospective validator.
     In general, assuming single-valued attributes for delta CRL's would be
dangerous in retrospective validation, as can be seen in the following
example (ignoring time units other than days for simplicity):
a)   Suppose the base CRL has thisUpdate D and nextUpdate D+7.
b)   Suppose delta CRL's were produced on D+3, and D+5.
c)   Attempt to validate a transaction occurring on D+6.  The second delta
is needed.
d)   Attempt to validate a different transaction occurring on D+4.  The
first delta is needed.

     On your question about LDAP retrieval of CRL's by time range, there
was some discussion on this group last summer by Steven Legg (the thread is
"Matching Rules for Constructed Syntaxes"), with David Chadwick and I also
contributing, about how to search LDAP for ASN.1 subfields, which is
reflected in an Internet-Draft
draft-legg-ldapext-component-matching-02.txt.  Until this is actually part
of LDAP, you probably can't do it.  If it is adopted as part of LDAP,
someone needs to give samples for the filters people actually would want to
run - notably times in certificates and CRL's, and values of KeyUsage.

          Tom Gindin

"David P. Kemp" <[email-masked]>@mail.imc.org on 06/29/2001 02:44:53
PM

Sent by:  [email-masked]

To:   [email-masked]
cc:

Tom Gindin wrote:
>
> [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.

Tom,

Wouldn't a retrospective verifier use a protocol other than LDAP to
retrieve
non-current CRLs?  I believe that searching the CDP attributes on an LDAP
server would always return a single CRL for the current wallclock time.
Could there conceivably be an LDAP mechanism to return all CRLs issued
between 10:00 June 3 2001 and 9:30 June 4 2001, or would such a retrieval
requirement be better satisfied using some other protocol (database search,
http query, ftp get by directory/filename, etc.)?

In other words, is there a downside to profiling as single-valued any
directory attributes that hold CRLs?

I agree with Denis that identifying the fact that an unscheduled CRL
is missing is a security consideration.  If the consideration rose to
the level of a security concern (which I doubt), it could be addressed
by sequential numbering or by a new CRL extension holding a backpointer
to the previously-issued CRL.

Dave

---

From: Santosh Chokhani <[email-masked]>
Date: Fri, 29 Jun 2001 17:11:51 -0400

Shouldn't the locally constructed CRL number be the same as the latest delta
CRL that was applied to construct the local CRL? 

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Friday, June 29, 2001 5:08 PM
To: Denis Pinkas
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-new-part1-07.txt

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.

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.

Tim working on an update to Appendix C.  Once he completes this update, he
will post an updated Internet-Draft.  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.)

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:
>
>    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:
>
>               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:
>
>          (2)  The issuingDistributionPoint extension is present in both
>               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
>       [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
> >
> > To:   Denis Pinkas <[email-masked]>
> > cc:   [email-masked]
> > > > complete, or delta CRL combined with a locally constructed
complete),
> > but
> > >looked at it in terms of objects stored, whatever their content is. If
I
> > ask
> > >retrieve TWO CRLs and not a single one. Thus If I want to make sure
that
> > 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!
> > > > > > >    a CRL that is complete for a given scope, at a given time
T,
> > by
> > > > > >     current complete CRL by combining a previously issued
complete
> > 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.
> >
> > >[snip]
> > You are welcome.
> > 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
> > > > > > 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
> > > > >again the arguments raised by Tom Guidin and James Manger, we might
> > > come to
> > 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.
> >
> > > > > > >       is between thisUpdate and nextUpdate and combining it
with
> > > > > > This is covered by the following, with the above definition of
> > > "most current":
> > > > > >
> > > > > > >       is between thisUpdate and nextUpdate and combining it
with
> > > > > > >       the last delta CRL used to construct that local CRL has
a
> > > > >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
> > > > >algorithm using local numbers provides the same result, that's
fine,
> > but
> > >local numbering. Instead of saying the locally constructed CRL has
number
> > X,
> > 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.
> >
> > > > >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
most
> > >not a time in the past, ... while the text I am still proposing is
valid
> > for
> > 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.
> >
> > > > > >     constructed CRL, the resulting locally constructed CRL has
the
> > > > >We do not need to locally number the CRLs. The "equivalent"
algorithm
> > > I have
> > > > that provides the same results is sufficient.  However, this is
needed
> > I disagree.

---

From: "Tom Gindin" <[email-masked]>
Date: Fri, 29 Jun 2001 16:10:22 -0400

Tom Gindin

To:   [email-masked]
cc:

what
current
which

Tom,

Dave