Subject: RE: draft delta crl text

From: "Carlin Covey" <[email-masked]>
Date: Fri, 1 Jun 2001 06:56:00 -0700

Tim,

A commendable job, but I do have a comment concerning the following
portion of the text:

"For each certificate whose status has changed since the generation
of the referenced base CRL:

      (a)  If the certificate is revoked for a reason included in the
      scope of the CRL, list the certificate as revoked.

      (b)  If not (a), list the certificate with the reason code
      removeFromCRL."

Rule (a) is fine, but unfortunately rule (b) catches more certificates
in its net than was intended.  A literal reading implies that
certificates should be listed with reason code removeFromCRL if their
status has changed in any way at all, e.g. newly created certificates,
newly expired certificates, and even revoked or "removed from hold"
certificates that are not within the scope of the CRL.  (These are all
certificates whose status has changed that are "not (a)" )

Here's a suggestion for rule (b):

       If the certificate was previously listed on the referenced base
       CRL or a subsequent delta CRL with reason code certificateHold,
       and that certificate is no longer on hold, list the certificate
       with the reason code removeFromCRL.

By the way, although this is fairly obvious, for the sake of completeness
perhaps we should add a caveat that certificates can be de-listed after
they expire.  We might also want to some text similar to this text from the
Federal Bridge CA Profile:
"Certificates remain on the CRL and ICRL one inclusion interval beyond
their expiration date."

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Tim Polk
Sent: Thursday, May 31, 2001 3:30 PM
To: [email-masked]
Subject: draft delta crl text

Folks,

Russ Housley, David Cooper, and I have tried to draft what we hope *will
become* consensus text for the delta CRL and CRL number text.  We believe
that the attached text clarifies (1) the requirements for "conforming
applications that support CRLs", (2) the CRL issuer's responsibilities when
including the delta CRL indicator and CRL number extensions, (3) the
algorithm followed by a CRL issuer when determining what certificates
should be listed on a delta CRL, and (4) the algorithm followed by an
application when determining whether a complete CRL and a delta CRL may be
combined.

To do this we have introduced a number of changes, beginning in section
3.  In section 3, we introduce the "CRL issuer" in an enhanced version of
the ASCII art model of a pKI (figure 1.)  In section 5, we define several
more terms including CRL scope, base CRL, delta CRL and complete CRL.  All
this was necessary to set the stage for the CRL number extension and delta
CRL indicator extension text.

Please read these excerpts carefully.  We believe that the text is flexible
enough to support reasonable implementations of delta CRLs, does not unduly
burden clients that wish to support deltas, and is consistent with
X.509.  When you read this please ask yourself if you can *live* with it.

The attachment contains the following excerpts:  Figure 1 from section 3,
section 5 (the intro to CRLs), section 5.2.3 (CRL number extension) and
5.2.4 (delta CRL indicator extension).  Please ignore the blank spaces; I
was trying to remove anything irrelevant to this discussion.

Thanks,

Tim Polk

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 01 Jun 2001 11:10:38 -0400

Carlin:

Thanks.  This is a nice improvement.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 01 Jun 2001 18:32:59 +0200

Tim,

 
 
> X.509.  When you read this please ask yourself if you can *live* with it.

I browse through it and I still have a MAJOR problem with the CRL numbering.

The two following sentences are contradictory:

   The CRL number is a non-critical CRL extension which conveys a
   monotonically increasing sequence number for a given CRL scope and
   CRL issuer.  

I agree with the above sentence.
   
   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.  

This contradicts the first sentence.

======================================================================

I do have problems with MANY other sentences, like:

   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.  

What does "the same numbering sequence" mean ? This sentence is useless and
should be deleted.

   This extension allows users to easily determine when a
   particular CRL supersedes another CRL.  

This is not true. Since complete CRLs and delta CRLs share the same
numbering space, they cannot be compared. This sentence should be deleted.  

======================================================================

   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.

The right wording should be:

   The combination of a delat 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, that is valid between this Update and nextUpdate 
   from the delta CRL.

======================================================================

   An application that supports delta CRLs can construct a CRL that is
   complete for a given scope, at the current time, in either of the
   following ways:

      (a)  by retrieving the current delta CRL for that scope, and
      combining it with an issued CRL that is complete for that scope
      and that has a cRLNumber greater than or equal to the base CRL
      number referenced in the current delta CRL; or

      (b)  by retrieving the current delta CRL for that scope and
      combining it with a locally constructed CRL whose cRLNumber is
      greater than or equal to the base CRL number referenced in the
      current delta CRL.

The right wording should be:

   An application that supports delta CRLs can construct a CRL that is
   complete for a given scope, at a given time T, in either of the
   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 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; 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 a content equivalent to a 
      full CRL that would have a cRLNumber equal or greater than 
      to the base CRL number referenced in the current delta CRL.

======================================================================

   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.

The right wording should be: 

   When a delta CRL is combined with a complete CRL or a locally
   constructed CRL, "The resulting locally constructed CRL is equivalent 
   to a complete CRL that would have thisUpdate and nextupdate respectively 
   equal to thisUpdate and nextUpdate from the delta CRL."

======================================================================

In this way, all the issues about CRL numbering vanish.

Since a conference call is now scheduled on Tuesday, with Tim, David and 
myself, I hope that we will be able to agree on the text changes
proposed above.

Note 1: I am lacking time to check the text about the onHold issue, but this
is far less critical.

Note 2: Next Monday is holiday in my country. :-)

Regards,

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 01 Jun 2001 18:47:08 +0200

Tim,

(snip)

> the ASCII art model of a pKI (figure 1.)  

I like the term "CRL Issuer". 

However, how should we call an entity that issues ACRLs ? 

Is it a "CRL Issuer" ?

If we take the definition under figure 1 which is:

   CRL issuer:  an optional system to which a CA delegates the
                publication of certificate revocation lists;

then we have a problem because ACRLs are not issued by CAs, but by AAs.

Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 01 Jun 2001 14:43:50 -0400

Denis:

AAs do not appear in Figure 1.  So, I think the text is okay, since it is 
explaining the figure.  AAs may also delegate the issuance of CRLs to a CRL 
issuer.

Russ

---

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

Tim,

I agree with either your original draft text, or amended according to
Carlin Covey's suggestions for removeFromCRL and "one interval beyond
their expiration date."

I wonder about the next-to-last sentence in section 5: "Conforming
applications are required to process both version 1 and 2 CRLs that
are complete for a given scope."  Since your example for scope includes
local information ("NIST employees located in Boulder"), does the
application requirement only apply to scopes that are expressable
in the Issuing Distribution Point extension, or does it require support
for the X.509 CRL Scope extension which is not profiled in new-part1-06,
or does it require mind-reading :-)?  Perhaps an explicit statement
about support for IDP would clarify.

I disagree with each of the points raised by Denis; comments appear
interspersed below.

Regards,
Dave

> This contradicts the first sentence.

No, for two reasons.

As previously discussed, monotonically increasing means "non-decreasing";
it does not mean "strictly increasing".  I would support replacing
"monotonically increasing" with "non-decreasing" if necessary for clarity.

More fundamentally, if a delta CRL and a complete CRL are issued at the
same time, they MUST reflect the identical revocation status for each
in-scope certificate.  If they reflect the same status, they should have
the same CRL number.  To do otherwise would make running delta CRLs
impossible - a delta contains a baseCRLNumber, and for at least some
subset of CRL numbers, applications must be able to download either a
full CRL or a delta CRL to use as a base.

It seems obvious to me that this sentence prohibits complete CRLs numbered
1,2,3, ... and delta CRLs for the same scope at the same respective times
numbered 1001, 1002, 1003, ...  If completes and deltas for a given scope
could be in different numbering sequences, then this example would not violate
the monotonically-increasing requirement.

The sentence must stay.

No.  A CRL is valid precisely at the time of publication.  It is
not "valid" one second later because it might have been superseded.

I don't disagree with the second wording, but it is irrelevant.  The first
wording is both correct and relevant to the issue of how the constructed
CRL may be used as a base for a future constructed CRL.

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 01 Jun 2001 16:46:42 -0400

>Carlin Covey's suggestions for removeFromCRL and "one interval beyond

We all know that...  Good catch.

Russ

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 01 Jun 2001 18:05:03 -0400

Carlin,

This is text that Tim Polk and I spent a long time trying to develop. Our goal was to get as close as possible to being "technically correct" while still having text that people could understand. Perhaps we're not quite there yet.

First, we did not intend to include events such as the creation or expiration of a certificate as a "status change". Instead a status change could be a change from:

         a) valid to on hold
         b) on hold to valid
         c) valid (or on hold) to revoked
         d) a change in revocation reason (e.g., from affiliationChanged to keyCompromise)

Perhaps we need to define status change. We should also explicitly status that the requirement only applies to certificates that are within the scope of the delta-CRL.

The biggest complication that we needed to deal with was a result of two factors:

         1) It is possible for the revocation reason on a certificate to change
             after the certificate has been revoked.

         2) The scope of a CRL may not include all revocation reasons.

Imagine, for example, that a CA issues two streams of CRLs for the certificates that it issues: one that covers all certificates that have been revoked for keyCompromise or cACompromise and the other that covers all certificates that have been revoked for some other reason. Suppose that the delta-CRLs are issued for the second scope and that the revocation reason for a certificate that was originally revoked with reason code affiliationChanged is changed to keyCompromise. If the base CRL (or a subsequently issued CRL) includes the certificate with reason code affiliationChanged, what should the delta-CRL say? If the delta-CRL specifies reason code affiliationChanged, that is no longer accurate. The delta-CRL could list the certificate with reason code keyCompromise, but this would be "out of scope" for the delta-CRL. In fact, a concurrently issued complete CRL for the "non-compromise" scope would simply not list the certificate. So, it seems that the appropriate thing would be!
 for the delta-CRL to list the certificate with reason code removeFromCRL with the understanding that the certificate would now be included in CRLs issued for the "compromise" scope. Tim and I were trying to account for examples such as this in the text that we wrote.

I noticed, however, that X.509 states:

         The removeFromCRL reason code is for use with delta-CRLs (see 8.6) only
         and indicates that an existing CRL entry should now be removed owing to
         certificate expiration or hold release. An entry with this reason code shall be
         used in delta-CRLs for which the corresponding base CRL or any subsequent
         (delta or complete for scope) CRL contains an entry for the same certificate
         with reason code certificateHold.

So, perhaps it would be improper in the example above to list the certificate with reason code removeFromCRL. I don't know if the effect of the text above on examples such as the one I provided was intentional or simply a failure to account for such odd cases.

In practice, I hope that this isn't a problem. I, personally, can not think of a reason to issue delta-CRLs for CRL scopes that do not include all revocation reasons. However, since such delta-CRLs are "legal", the text should correctly state how to generate them.

Any suggestions on how to address these issues would be welcome.

>        with the reason code removeFromCRL.

Just a minor nit. There is no requirement for a delta CRL to use the most recently issued complete CRL as its base. So,  "subsequent delta CRL" should instead be "subsequent CRL (delta CRL or complete CRL)".

---

From: "Carlin Covey" <[email-masked]>
Date: Fri, 1 Jun 2001 16:30:34 -0700

David,

In lieu of my suggested text, I would be perfectly happy with a
definition of "status change," a caveat concerning requirements
applying only to in-scope certificates, and a note addressing the
de-listing of certificates after expiration.

You make some excellent points about concerning coordination between
CRL's of different scopes.  When I wrote my suggested wording
I was not thinking of the case of a certificate hopping from one CRL
or delta CRL to another due to a change in reasonCode.  This situation
brings to mind another knotty problem.  Suppose the CRL or DCRL that a
revoked certificate is hopping from is due for an update, but the CRL
or DCRL that the certificate is hopping to is not yet due for an update.
It seems inadvisable for the certificate to be listed on neither CRL
(i.e. temporarily valid) until the second CRL is updated.  The situation
is exacerbated if the two CRL's are issued by different authorities.

Perhaps the revoked certificate should continue to be listed on the
first CRL despite the fact that it is (or will be) on the second CRL.

Regards,

Carlin

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of David A. Cooper
Sent: Friday, June 01, 2001 3:05 PM
To: [email-masked]
Subject: RE: draft delta crl text

Carlin,

This is text that Tim Polk and I spent a long time trying to develop. Our
goal was to get as close as possible to being "technically correct" while
still having text that people could understand. Perhaps we're not quite
there yet.

First, we did not intend to include events such as the creation or
expiration of a certificate as a "status change". Instead a status change
could be a change from:

         a) valid to on hold
         b) on hold to valid
         c) valid (or on hold) to revoked
         d) a change in revocation reason (e.g., from affiliationChanged to
keyCompromise)

Perhaps we need to define status change. We should also explicitly status
that the requirement only applies to certificates that are within the scope
of the delta-CRL.

The biggest complication that we needed to deal with was a result of two
factors:

         1) It is possible for the revocation reason on a certificate to
change
             after the certificate has been revoked.

Imagine, for example, that a CA issues two streams of CRLs for the
certificates that it issues: one that covers all certificates that have been
revoked for keyCompromise or cACompromise and the other that covers all
certificates that have been revoked for some other reason. Suppose that the
delta-CRLs are issued for the second scope and that the revocation reason
for a certificate that was originally revoked with reason code
affiliationChanged is changed to keyCompromise. If the base CRL (or a
subsequently issued CRL) includes the certificate with reason code
affiliationChanged, what should the delta-CRL say? If the delta-CRL
specifies reason code affiliationChanged, that is no longer accurate. The
delta-CRL could list the certificate with reason code keyCompromise, but
this would be "out of scope" for the delta-CRL. In fact, a concurrently
issued complete CRL for the "non-compromise" scope would simply not list the
certificate. So, it seems that the appropriate thing would be!
 for the delta-CRL to list the certificate with reason code removeFromCRL
with the understanding that the certificate would now be included in CRLs
issued for the "compromise" scope. Tim and I were trying to account for
examples such as this in the text that we wrote.

         The removeFromCRL reason code is for use with delta-CRLs (see 8.6)
only
         and indicates that an existing CRL entry should now be removed
owing to
         certificate expiration or hold release. An entry with this reason
code shall be
         used in delta-CRLs for which the corresponding base CRL or any
subsequent
         (delta or complete for scope) CRL contains an entry for the same
certificate
         with reason code certificateHold.

So, perhaps it would be improper in the example above to list the
certificate with reason code removeFromCRL. I don't know if the effect of
the text above on examples such as the one I provided was intentional or
simply a failure to account for such odd cases.

In practice, I hope that this isn't a problem. I, personally, can not think
of a reason to issue delta-CRLs for CRL scopes that do not include all
revocation reasons. However, since such delta-CRLs are "legal", the text
should correctly state how to generate them.

>        with the reason code removeFromCRL.

Just a minor nit. There is no requirement for a delta CRL to use the most
recently issued complete CRL as its base. So,  "subsequent delta CRL" should
instead be "subsequent CRL (delta CRL or complete CRL)".

---

From: "Carlin Covey" <[email-masked]>
Date: Fri, 1 Jun 2001 16:29:08 -0700

David,

Regards,

Carlin

-  Carlin Covey
   Cylink Corporation

-----Original Message-----

Carlin,

         a) valid to on hold
         b) on hold to valid

---

From: Dr S N Henson <[email-masked]>
Date: Sat, 02 Jun 2001 01:39:38 +0100

"David A. Cooper" wrote:
> 
> 
> First, we did not intend to include events such as the creation or expiration of a certificate as a "status change". 
> 
[snip]
>          with reason code certificateHold.

Just a quick comment here wrt removeFromCRL and expiry of previous CRL
entries. 

There is at least one reason for doing this. It allows a locally
constructed CRL to be cleared of expired entries. Otherwise if a client
uses delta CRLs for an extended period of time (several certificate
lifetimes) its size may become excessive.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [email-masked] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [email-masked] PGP key: via homepage.

---

From: "Al Arsenault" <[email-masked]>
Date: Fri, 1 Jun 2001 21:50:39 -0400

David C. wrote:

><snip>

My personal preference in such a scenario would be to have the entry remain
on the "non-compromise" CRL as well as being placed on the "compromise" CRL.
That guarantees that it doesn't fall off the CRL entirely because a timing
problem in issuance of CRLs by different issuers (as pointed out by Carlin
in a subsequent post).  And, while I recognize that this is a somewhat
hypothetical scenario, it's doubtful that the subject of a cert revoked for
"affiliationChanged" would suddenly have its "affiliation unchanged".

If we're being consistent with explicit X.509 actions in other areas :-) we
should do so here and only support removeFromCRL because of certificate
expiration or status change. In general, I think that the text David and Tim
have proposed here is acceptable, with a clarification of what "status
change" means.

If necessary, you can add text that describes the above scenario and
provides whatever the consensus PKIX recommendation is, but I'm not sure
that it is necessary at this point.

        Al Arsenault
        Chief Security Architect
        Diversinet Corp.

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 04 Jun 2001 08:32:29 -0400

Dr. Henson,

I agree with you. The draft text specifies circumstances in which one is required to list a certificate on a delta-CRL. Tim Polk and I believe that one should be allowed to list a certificate with reason code removeFromCRL when it expires, but one should not be required to list it. On the other hand, while I haven't done the math, I would suspect that it would be more efficient to simply have relying parties download a new complete CRL whenever their local caches of revoked CRLs become too large rather than list each expired certificate on one or more delta-CRLs.

The reason that I quoted the text from X.509 below was because it states that one can only list a certificate with reason code removeFromCRL if it has expired or has been released from hold. If one follows this text literally, it is not clear what to do if a revoked certificate becomes "out-of-scope" for the delta-CRL as a result of a change in reason code. Should one list it as removeFromCRL, with the old but in scope reason, or with the new but out of scope reason?

Dave

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 05 Jun 2001 15:26:18 +0200

Russ,
 
> explaining the figure.  AAs may also delegate the issuance of CRLs to a CRL

I don't think so. The danger is that people might take the following as a
definition:

CRL issuer:  an optional system to which a CA delegates the publication of
certificate revocation lists.

This term is left undefined elsewhere, so this is the *only* definition so
far in the
document.

If an AA issues ACs that can be revoked, then I believe that CRL issuers can
be used.

So a more appropriate definition would be: 

CRL issuer: an optional system to which a CA (or an AA) delegates the
publication of certificate revocation lists.

or

CRL issuer: an optional system to which a CA (or a PKI Authority) delegates
the
publication of certificate revocation lists.

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 05 Jun 2001 15:54:02 +0200

David,

(snip)
 
> I disagree with each of the points raised by Denis; comments appear
                  ^^^^
> interspersed below.

Not really, since you have deleted the most important part of the text
without providing *any* argument against it.

Here is this text again (without the previous text):

> "monotonically increasing" with "non-decreasing" if necessary for clarity.

See my other message to Santosh on that point about unique CRL numbers for
CRLs.

> the same CRL number.  

More fundamentally, if a delta CRL and a complete CRL are issued at the same
time, they do *not* necessarilly reflect the same revocation information
since their validity periods are not necessarilly identical: i.e. their
nextUpdate is not necessarilly the same. Hence they will not necessarilly be
applicable during the same time interval. Since they do not reflect the same
validity of the information, they certainly should *not* have the same CRL
number. See a related coment later on.

> To do otherwise would make running delta CRLs

Doing otherwise is indeed possible using unique CRL numbers. thisUpdate and
nextUpdate MUST be used.
 
> the monotonically-increasing requirement.

Thanks for the example, I now understand what was intended. However this is
not necessary. The way I have formulated the processing rules does not need
to take advantage of this property. So this sentence can be deleted (see the
text at the top of this e-mail).

> not "valid" one second later because it might have been superseded.

Certainly not. Take a look at PKIX part 1:

   This field indicates the date by which the next CRL will be issued.
   The next CRL could be issued before the indicated date, but it will
   not be issued any later than the indicated date.  CAs SHOULD issue
   CRLs with a nextUpdate time equal to or later than all previous CRLs.
   nextUpdate may be encoded as UTCTime or GeneralizedTime.

   This profile requires inclusion of nextUpdate in all CRLs issued by
   conforming CAs. 

This means that a CRL is valid between thisUpdate and nextUpdate.

> I don't disagree with the second wording, but it is irrelevant.  

Fine. So you can live with it. :-)

> The first

The second wording does not make use the CRL numbering, hence why it is
there.

Regards,

Denis

---

From: "David P. Kemp" <[email-masked]>
Date: Tue, 05 Jun 2001 14:35:50 -0400

Denis,

We have different, incompatible, ways of looking at CRLs.  I accept
that the difference exists, but prefer to continue with my way.

>       to the base CRL number referenced in the current delta CRL.

I don't disagree with these words, although I slightly prefer Tim's less
pedantic version of (b).  Precision is good in a standard, and which of
 
  "a locally constructed CRL whose cRLNuber is ..."
      or
  "a locally constructed CRL that has a content equivalent to a full CRL
   that would have a cRLNumber ..."

is more precise is a matter of personal preference.

The key to my agreement with your (a) and (b) is that they both
use cRLNumber, not thisUpdate and nextUpdate, to link the delta with
its base.  It appears from your other points that you intend for
cRLNumber to disappear entirely, and that is where we part company.

> 
> > [dpk] More fundamentally, if a delta CRL and a complete CRL are issued at the
> [Denis] More fundamentally, if a delta CRL and a complete CRL are issued at the same

My background is in digital signal processing, so I view CRLs as samples
of a physical process (the revocation events that have been reported
to a CA and reflected in the CA's internal state).  A sample at time T and
another sample at the identical time T contain the identical information.
It makes no difference if the next scheduled samples in each series will
be taken at T + 1 hour and T + 24 hours respectively.  The complete CRL at
time T and the delta CRL at time T should have the same CRL number.

> > [dpk] A CRL is valid precisely at the time of publication.  It is
> [Denis]  Certainly not. Take a look at PKIX part 1:
> 

I respectfully submit that it means nothing of the sort.  Consider the
following CRLs, issued entirely in accordance with PKIX part 1:

 cRLNumber:        1               2               3
thisUpdate:     0900            0910            1500
nextUpdate:     1500            1500            2100
 cert list:  (17, 52)   (17, 52, 113)   (17, 52, 113)

Notice that certificate 113 was revoked sometime between 9 o'clock and 9:10.
Notice that according to your definition of "validity", CRLs 1 and 2 are
both valid at 12:00 noon, but they contain different information with
respect to certificate 113.  Is one of them "more valid" than the other,
or is it simply the case that CRL 2 is "more recent" than CRL 1?

Is it your position that unscheduled CRLs should be prohibited?  I disagree
with that prohibition, and I therefore think it is misleading to call
the time between thisUpdate and nextUpdate a "validity" period.

Regards,
Dave

P.S. to Tim:

I believe that the sentence:
  "CAs SHOULD issue CRLs with a nextUpdate time equal to or later than
   all previous CRLs"
should be amended to apply separately to complete CRLs and delta CRLs.
In other words, I believe the following should be perfectly legitimate
set of CRLs (they should not violate a PKIX SHOULD):

Complete:
----------------------------
  cRLNumber:       100                                         104
 thisUpdate:  Wed 0300                                    Thu 0300
 nextUpdate:  Thu 0300                                    Fri 0300

Delta for the same scope:
----------------------------
  cRLNumber:       100        101        102        103        104
 thisUpdate:  Wed 0300   Wed 0900   Wed 1500   Wed 2100   Thu 0300
 nextUpdate:  Wed 0900   Wed 1500   Wed 2100   Thu 0300   Thu 0900

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 05 Jun 2001 16:30:44 -0400

Denis:

How about:

         CRL issuer: an optional system to which a CA delegates the
         publication of certificate revocation lists (CRLs).  (Note:  An
         Attribute Authority (AA) might also choose to delegate
         publication of CRLs to a CRL issuer.)

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 11 Jun 2001 16:59:33 +0200

> that the difference exists, but prefer to continue with my way.

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

> cRLNumber to disappear entirely, and that is where we part company.

We talked about this. 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. 

>  cert list:  (17, 52)   (17, 52, 113)   (17, 52, 113)

According to PKIX part 1, the following CRLs would be issued entirely in
accordance with PKIX part 1:

 cRLNumber:         1               1               1

:-(

> or is it simply the case that CRL 2 is "more recent" than CRL 1?

Both are valid, but if a client one has the CRL from 9:00 a.m. in his cache,
there is no reason why he SHALL fetch a new one. Even, if he does, there is
no guarantee that the one from 9:10 a.m. will ever be obtained (when there 
is a denial of service attack).

> Is it your position that unscheduled CRLs should be prohibited?  

For real time use, unscheduled CRLs may be useful, but once again there are
not a bullet proof mechanism. If someone wants to use CRLs and make sure
that the freshest revocation information cannot be missed, then delta-CRLs
should be used. 

For non repudiation use, unscheduled CRLs should/shall be prohibited because
two clients capturing the same revocation information at the same time,
could gather two different CRLs and since the goal of non repudiation is to
solve disputes, we would have an unsolvable dispute.

> I disagree with that prohibition, and I therefore think it is misleading 
> to call the time between thisUpdate and nextUpdate a "validity" period.

See above.

Regards,

Denis