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

From: [email-masked]
Date: Fri, 15 Jun 2001 06:46:07 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
	Author(s)	: R. Housley, W. Ford, W. Polk, D. Solo
	Filename	: draft-ietf-pkix-new-part1-07.txt
	Pages		: 124
	Date		: 14-Jun-01
	
This is the fourth draft of a specification based upon RFC 2459.
When complete, this specification will obsolete RFC 2459.  This
specification includes minor edits and clarifications.  The most
notable departures from RFC 2459 are found in Section 6, Path
Validation.  In RFC 2459, the reader was expected to augment the path
validation algorithm, which concentrated upon policy processing, with
information embedded in earlier sections.  For example, parameter
inheritance is discussed in Section 7, Algorithm Support, and can
certainly affect the validity of a certification path.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-07.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-new-part1-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-new-part1-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 18 Jun 2001 18:45:51 +0200

Russ, Tim and David,

I have not reviewed all the document but I have taken a look at sections
5.2.3 and 5.2.4.

The fix for section 5.2.3. would have been rather simple: remove
"monotonically", so that CRL numbers become "strictly increasing".
Unfortunately, this is not the direction that you have taken.

The new text is as follows:

5.2.3  CRL Number

   The CRL number is a non-critical CRL extension which conveys a
   monotonically increasing sequence number for a given CRL scope and
   CRL issuer.  This extension allows users to easily determine when a
   particular CRL supersedes another CRL.  CRL numbers also support the
   identification of complementary complete CRLs and delta CRLs.  CRL
   issuers conforming to this profile MUST include this extension in all
   CRLs.

   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.  If a delta CRL and a complete CRL that cover the
   same scope are issued at the same time, they MUST have the same CRL
   number and provide the same revocation information.  That is, the
   combination of the delta CRL and an acceptable complete CRL MUST
   provide the same revocation information as the simultaneously issued
   complete CRL.

   If a CRL issuer generates two CRLs (two complete CRLs, two delta
   CRLs, or a complete CRL and a delta CRL) for the same scope at
   different times, the two CRLs MUST NOT have the same CRL number.
   That is, if the this update field (section 5.1.2.4) in the two CRLs
   are not identical, the CRL numbers MUST be different.

   id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }

   CRLNumber ::= INTEGER (0..MAX)

My comments:

1) The text should say : "The CRL number is a non-critical CRL extension
which conveys a strictly increasing sequence number for a given CRL scope
and CRL issuer."
 
2) I have sent a detailed description on how to use delta-CRLs where that
description makes use of CRLnumber but where it is not required to use the
same CRL number for a delta-CRL and a full CRL. You have not said (nor Tim,
nor David) why this would not work. I am still awaiting your comments on my
proposal copied again below:

It appears that thisUpdate and nextUpdate are the
basis of the processing rule for verifying that the delta CRL is "valid".
However, for making use of already locally constructed CRLs (which is an
optimization that all clients do *not* need to support), the CRLNumber is
necessary (see case 3 below). 

Here is the new text proposal:

   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.

   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

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

3)  If a delta CRL and a complete CRL that cover the same scope are issued
at the same time, they do NOT provide the same revocation information since
they do not necessarilly have the same nextUpdate field: their validity
periods are different in general. Relying on one or the other is not the
same.

4) A full CRL and a delta  CRL with the same number would not provide the
same information since in one case, one CRL is needed (a full) and in the
other case a delta CRL plus another full CRL or additional local information
is needed.

The old text where all started from was the following in RFC 2459:

5.2.4  Delta CRL Indicator

   The delta CRL indicator is a critical CRL extension that identifies a
   delta-CRL.  The use of delta-CRLs can significantly improve
   processing time for applications which store revocation information
   in a format other than the CRL structure.  This allows changes to be
   added to the local database while ignoring unchanged information that
   is already in the local database.

   When a delta-CRL is issued, the CAs MUST also issue a complete CRL.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is the original sentence which triggered all the discussion. It has now
been removed.

   The value of BaseCRLNumber identifies the CRL number of the base CRL
   that was used as the starting point in the generation of this delta-
   CRL.  The delta-CRL contains the changes between the base CRL and the
   current CRL issued along with the delta-CRL.  It is the decision of a
   CA as to whether to provide delta-CRLs.  
   
   Again, a delta-CRL MUST NOT be issued without a corresponding complete
   CRL.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is the other sentence which triggered all the discussion. It has now
been removed.

   The value of CRLNumber for both the delta-CRL and the corresponding 
   complete CRL MUST be identical.
   A CRL user constructing a locally held CRL from delta-CRLs MUST
   consider the constructed CRL incomplete and unusable if the CRLNumber
   of the received delta-CRL is more than one greater than the CRLnumber
   of the delta-CRL last processed.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Telling what should be done would be more useful that telling what should
not be done. :-)

   id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }

   deltaCRLIndicator ::= BaseCRLNumber

   BaseCRLNumber ::= CRLNumber

This was all the text. Now, you can see that section 5.2.4 has expanded
quite a lot (much too long to be copied here). 

5) When delta-CRLs are supported, it is hard to know  which schemes MUST be
supported by the relying parties and which schemes MAY be supported. If a
relying party MUST support all the schemes that are described, we are not
going to see delta-CRLs very widely used, and, if ever, in commercial
products.

6) Besides the other points mentionned earlier, the next text is still
incomplete because it does not say how to use the fields thisUpdate and
nextUpdate. 

7) In addition, I would be interrested to get some explanations about the
item d) from 5.2.4 which is new text:

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

Regards,

Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 19 Jun 2001 11:50:13 -0400

>which conveys a strictly increasing sequence number for a given CRL scope

I think that the change you propose adds confusion, not clarity.

When a complete CRL and a delta CRL are issued at the same time and 
represent exactly the same revocation information, they MUST have the same 
CRL number.  So, two blobs of bits (representing the same revocation 
information) have the same CRL number.  I think that "strictly increasing" 
might confuse an implementors into assigning different CRL numbers.

>proposal copied again below:

I considered David's message that showed a way to issue delta CRLs shortly 
after complete CRLs (instead of at the same time) as a response to your 
message.  I'm sorry that you felt ignored and neglected.

>necessary (see case 3 below).

The section clearly states that any algorithm that yields the same result 
is acceptable.

>       number greater than the base CRL number referenced in the

You posted similar (or perhaps identical) text previously.  I believe that 
the list of conditions that MUST be satisfied to combine a complete CRL or 
a locally constructed CRL with a delta CRL incorporate your points, with 
one exception.  I would be willing to add the following paragraph:

    An application that supports delta CRLs MUST be able to construct
    a current complete CRL by combining a previously issued 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.

Is there a subtle point that I missed?

>periods are different in general. Relying on one or the other is not the

I agree that the delta CRL and complete CRL that are issued at time will 
contain different next update fields.  However, I do not think that the 
text is wrong.  I believe that applications that support delta CRLs will 
understand that delta CRLs are probably issued more frequently than 
complete CRLs (although, a compete CRL could be issued every time a delta 
is issued, as RFC 2459 requires).

>other case a delta CRL plus another full CRL or additional local information

A delta CRL is never useful without an associated base CRL.

>going to see delta-CRLs very widely used, and, if ever, in commercial

Does the paragraph proposed above solve your problem?

>incomplete because it does not say how to use the fields thisUpdate and

The discussion on the list makes it clear that either CRL number or 
date/time can be used.  Again, we are clear that any algorithm that 
provides the same result is acceptable.

>       complete CRL in the numbering sequence.

One cannot combine a complete CRL with a delta CRL that was issued before 
the complete CRL.  The complete CRL already includes all of the information 
in such a delta CRL.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 20 Jun 2001 18:32:38 +0200

(text deleted)

> message.  I'm sorry that you felt ignored and neglected.

Before I reply to your message, would you please repost "David's message"
that is supposed to be a response to the message I posted on June 11, with
the subject "Re: draft delta crl text" and starting with:

" I have had some talks with Tim Polk and David Cooper. We have all
progressed in the understanding. I have sent a new text proposal, but 
since I got no response, I have observed that placing the proposal on 
the PKIX mailing list usually triggers more rapid responses. :-)"

Apparently I have not received a response to that messsage.

Thanks,

Denis

(text deleted)

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 20 Jun 2001 18:28:26 -0400

Russ,

I agree with all of section 5.2.3.

I have four comments on Section 5.2.4, otherwise it looks fine.
In paragraph 2:

     The delta CRL indicator extension contains the single value of type
     BaseCRLNumber.  This value identifies the CRL number of the complete
     CRL that was used as the foundation in the generation of this delta
     CRL.
 ***      The referenced base CRL is a CRL that was explicitly issued as
 *** a CRL that is complete for a given scope. 
                                                The CRL containing the
     delta CRL indicator extension contains all updates to the revocation
     status for that same scope. The combination of a CRL containing the
     delta CRL indicator extension plus the CRL referenced in the
     BaseCRLNumber component of this extension is equivalent to a complete
     CRL, for the applicable scope, at the time of publication of the
     delta CRL.

1) The sentence highlighted above is confusing.  Elsewhere
   it is clear that the referenced base CRL may be either explicitly
   issued or locally constructed.  The sentence is too oblique to be
   a generation requirement; see comment 4) below for a replacement.

2) The phrase "The CRL containing the delta CRL indicator extension" (used
   twice above) seems excessive.  Can it be replaced with "The delta CRL"?

   Suggest replacing paragraph 2 with:

      The delta CRL indicator extension contains the single value of type
      BaseCRLNumber.  This value identifies the CRL number of the CRL,
      complete for a given scope, that was used as the starting point in
      the generation of this delta CRL.  The delta CRL contains all updates 
      to the revocation status for that scope.  The combination of a
      delta CRL plus the referenced complete CRL is equivalent to a
      complete CRL, for the same scope, at the time of publication
      of the delta CRL.

3) Paragraph 4 and paragraph 7 contain the same information.
   Delete paragraph 4 entirely (the one that begins: "When a delta CRL is
   issued, it MUST cover the same set of reasons ..."), and add the private
   key to the first condition of paragraph 7:

     (a)  The complete CRL and the delta CRL have the same issuer and are
     signed by the same private key.

4) I agree that the last paragraph of section 5.2.4 should be replaced
   with the text you proposed in reply to Denis, supplemented with an
   explicit generation requirement:

     a current complete CRL by combining a previously issued **complete** CRL
and

     A CA that issues a delta CRL MUST have previously issued a complete
     CRL that can be combined with that delta CRL.

Dave

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 21 Jun 2001 08:49:29 -0400

Dave:

Thanks for your careful review.

>I agree with all of section 5.2.3.

Great!

>    a generation requirement; see comment 4) below for a replacement.

See reply to your second comment.  I hope the proposed text resolve this 
concern.

>       complete CRL, for the same scope, at the time of publication

I agree with all of your changes; however, the notion that the base CRL has 
to be available seems to be even more vague in your proposed text.  How 
about the following:

    The delta CRL indicator extension contains the single value of type
    BaseCRLNumber.  This value identifies the CRL number, complete for a
    given scope, that was used as the starting point in the generation of
    this delta CRL.  The CRL issuer MUST publish the referenced base CRL.
    The delta CRL contains all updates to the revocation status for that
    same scope.  The combination of a CRL containing the delta CRL plus
    the CRL referenced base CRL is equivalent to a complete CRL, for the
    applicable scope, at the time of publication of the delta CRL.

>      signed by the same private key.

I do not agree.  Paragraph 4 is supposed to impose MUST statements on CRL 
issuers.  Paragraph 7 says when a relying party MAY combine a delta 
CRL  with a base CRL.  We are trying to be strict in paragraph 4, but more 
flexible in paragraph 7.  For example, a client may be willing to implement 
all of the complexity necessary to process non-PKIX compliant delta CRLs 
that are signed with a different private key than the referenced base.

>      a current complete CRL by combining a previously issued **complete** 
> CRL and

Good addition.

>      CRL that can be combined with that delta CRL.

Two points.  First, we should be talking about CRL issuers here, not 
CAs.  Second, I think that this point is now covered by the MUST statement 
that I proposed in response to you second concern.  Agree?

Russ

---

From: "David P. Kemp" <[email-masked]>
Date: Thu, 21 Jun 2001 09:53:15 -0400

"Housley, Russ" wrote:

> How about the following:

I agree with adding the CRL issuer sentence, and I agree with the rest of
the text after the two typos are corrected (shame we can't do strikeouts
in ASCII):

     The delta CRL indicator extension contains the single value of type
     BaseCRLNumber.  This value identifies the CRL number, complete for a
     given scope, that was used as the starting point in the generation of
     this delta CRL.  The CRL issuer MUST publish the referenced base CRL.
     The delta CRL contains all updates to the revocation status for that
     same scope.  The combination of a delta CRL plus
     the referenced base CRL is equivalent to a complete CRL, for the
     applicable scope, at the time of publication of the delta CRL.

> that are signed with a different private key than the referenced base.

My mistake.  I withdraw the suggestion.

> that I proposed in response to you second concern.  Agree?

Agree.

Dave

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 21 Jun 2001 16:16:54 +0200

Russ,

Since you privately replied to this message and omitted to copy to the list,
you have acknowledged that there exists no reply to my message from June 11,
but a much earlier message from David Cooper.

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.

David Kemp has highlighted different problems with your latest proposal. In
addition the proposal contains statements which are ambiguous such as "the
most current delta CRL". What is the criteria to determine "the most current
delta CRL" ? Don't you use thisUpdate and nextUpdate ?

One again, I ask you to consider the wording I have proposed. It is copied
below:

If there is nothing wrong about it, let us go with it. 

If there is something wrong that can be easily corrected, let us correct it.

Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 21 Jun 2001 13:53:10 -0400

>      applicable scope, at the time of publication of the delta CRL.

Here is, I hope, a very minor readability improvement:

    The delta CRL indicator extension contains the single value of type
    BaseCRLNumber.  The CRL number identifies the CRL, complete for a
    given scope, that was used as the starting point in the generation of
    this delta CRL.  The CRL issuer MUST publish the referenced base CRL.
    The delta CRL contains all updates to the revocation status for that
    same scope.  The combination of a delta CRL plus the referenced base
    CRL is equivalent to a complete CRL, for the applicable scope, at the
    time of publication of the delta CRL.

Russ

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 21 Jun 2001 15:45:37 -0400

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.

I am grateful for proposed replacement text.  I makes the editor's job much 
easier when specific changes are proposed.

>since, in this way, it is possible to use a CRL number to uniquely identify

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.

>delta CRL" ? Don't you use thisUpdate and nextUpdate ?

Yes, Dave did point out some problems, and I believe that we a very close 
to a resolution.

As I stated in my opening paragraphs, this note is about the definition of 
current.  See below.

>One again, I ask you to consider the wording I have proposed. It is copied

I have done so.

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

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.

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

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

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.

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.

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

>       number greater than the base CRL number referenced in the

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:

    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.

I think that this resolved the difference in the cases that you offer.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 22 Jun 2001 18:57:10 +0200

Russ,
 
> the meaning of current.  If there are other, less obvious points, please

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

> easier when specific changes are proposed.

You are welcome. :-)

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

>     and the most current delta CRL.

This is the issue about "most current".

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

>           the fields in the extensions are the same in both CRLs.

I have no problem with this either.
 
>        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.

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

>           All rights reserved. Developed for Microsoft by Bloomsbury

I wished you used a "true" Dictionary like the Oxford Dictionary, the Colins
Dictionary or the Harraps Dictionary.

>     the current time is between the times contained in the thisUpdate

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.
 
> these cases.  We clearly tell the implementor how to number locally

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.

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.

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

Denis

Note: I will be away from my office the first three days of next week, so do
not expect an immediate reply.

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 22 Jun 2001 17:03:35 -0400

> the "right" delta, then clause (c) is self-sufficient.

It is needed because this section gives the rules for determining if the
delta is "right".  One of those rules, though it should be obvious, is that
the delta must be after the complete it is being combined with.  You just
said under (a) that explicit is good.  I agree.

> wording I have used under the MAY statement.

Your proposed wording does not explain HOW to locally compute a complete

> >       number greater than the base CRL number referenced in the

This says nothing about how to use more than one delta CRL in the
construction, yet it includes a provision concerning the "last delta CRL".
If the CRLs needed to construct a local CRL are A (complete) and
{ B, C, D, E } (deltas), you are saying you can use A provided that
E is satisfactory, but you provide no algorithm for getting from A
through A+B, A+B+C, A+B+C+D to A+B+C+D+E.

That is why numbering the intermediate CRLs is not a local matter - at
each step the CRLnumber of the constructed CRL must be greater than or
equal to the baseCRLnumber of the delta being combined.  I don't believe
you can express the requirement for all deltas to be satisfactory using
words such as in (b).  If you do, (a) and (b), which are already longer
and more incomprehensible than what's in part1-07, will become even longer
and even more incomprehensible.

The simple, elegant, uniform way to express the combining algorithm is
to treat issued and locally-constructed CRLs identically when combining
with a delta.  If you want to use some longer, more obtuse algorithm
that gives identical results, that's fine.  But don't ask PKIX to include
a long obtuse algorithm description when the short simple description
is entirely correct.

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 25 Jun 2001 11:09:19 -0400

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

>This was so obvious that it is was said, but you are right, we have to be

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.

>I have no problem with this either.

Good.

>than", it makes the same result.

Fine.  I changed it to "... equal to or greater than ..."

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

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

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

>should not be part of the standard.

I disagree.  When a delta CRL is used to update a complete CRL (whether
that compete 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.

>implementation may be conformant without the need to implement the

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.

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

Russ

---

From: "David P. Kemp" <[email-masked]>
Date: Mon, 25 Jun 2001 15:53:51 -0400

>     in the thisUpdate and nextUpdate fields.

In the last sentence "the most current one" could be interpreted to mean
that there can be only one most-current CRL.  I would agree with it
if and only if it were followed by an indication that unscheduled
CRLs are permitted.  Something like:

      Note: there may be more than one delta CRL for a given scope
      for which the current time is between thisUpdate and nextUpdate.
      An application that has two or more such CRLs should consider
      the one with the latest thisUpdate to be the most current.

Dave

P.S. The comma in the last sentence should be removed.

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 26 Jun 2001 15:02:34 -0400

Dave:

Good point.  I propose to revise the text as follows:

    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 the current time is between the times contained in the
    thisUpdate and nextUpdate fields.  Under some circumstances, the CRL
    issuer may publish one or more delta CRLs before indicated by the
    nextUpdate field.  If an application encounters more than one delta
    CRL for a given scope for which the current time is between
    thisUpdate and nextUpdate, the application MUST consider the delta
    CRL with the latest thisUpdate to be the most current.

Russ

---

From: "David P. Kemp" <[email-masked]>
Date: Tue, 26 Jun 2001 15:45:57 -0400

Agree.

Dave

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 28 Jun 2001 16:14:15 +0200

Russ,

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

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

 
 
> Fine.  I changed it to "... equal to or greater than ..."

Thank you.

> done by people less involved in the PKI standards community than you.

I still think this text is unnecessary.

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

> that complete CRL was obtained directly from the CRL issuer or it was

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

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

> constructed complete CRL.

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

Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 28 Jun 2001 17:18:33 -0400

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

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

>[snip]

You are welcome.

>I still think this text is unnecessary.

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

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

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

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

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

I disagree.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 29 Jun 2001 17:05:27 +0200

Russ,

I have purposely changed the header of this e-mail so that people may pay
attention to it.

I have only copied a pasted the first part of your response so that people
can reply. I will address the other part in a separate e-mail.

 
> beat to death, and I do not hear anyone besides you that thinks this is an

This is not the main issue, but how many responses you can get while
specifying a CRLnumber + a CRL distribution point. If a CRL number is
unique, then the answer is one (or none). If not, it may be two (or even
more).

OPTION A: The original text in draft-ietf-pkix-new-part1-06.txt was:

   The CRL number is a non-critical CRL extension which conveys a
   monotonically increasing sequence number for each CRL issued by a CA.
   This extension allows users to easily determine when a particular CRL
   supersedes another CRL.  CAs conforming to this profile MUST include
   this extension in all CRLs.

Everybody agrees that the first sentence option A is misleading (e.g. it
would be permitted to issue all CRLs with the same number !). So we have
options B and C.

OPTION B: The (much longer) text in draft-ietf-pkix-new-part1-07.txt

Option C : I am proposing a simple and single fix to RFC 2459 by changing 
"monotonically" into "strictly", which leads to:

   The CRL number is a non-critical CRL extension which conveys a
   strictly increasing sequence number for each CRL issued by a CA.
   This extension allows users to easily determine when a particular CRL
   supersedes another CRL.  CAs conforming to this profile MUST include
   this extension in all CRLs.

[Note: monotonically means "superior or equal". strictly only means
"superior".]
 
> chairmen, it seems that Denis is a lone voice on this issue.  If it is not

So the vote, if any, is between Option B and Option C.

Denis

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 29 Jun 2001 11:49:58 -0400

Denis Pinkas wrote:
> > [Russ]:

Under part1-07 (option B), the answer is one (or none).  One would expect
different distribution points for deltas and completes with the same
scope.

Even if a CRL issuer decided to use the same distribution point and there
were two responses, the application can easily determine which is the
complete and which is the delta.  Of course such a setup would be
pointless, since the purpose of deltas is to save bandwidth.

> "monotonically" into "strictly", which leads to:  [snip]
> 

Option C is unacceptable for reasons which have, as Russ says, been
beaten to death.

Option B is entirely satisfactory.

---

From: Tim Polk <[email-masked]>
Date: Fri, 29 Jun 2001 16:25:35 -0400

Option B.

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 29 Jun 2001 16:25:24 -0400

I vote for B!