Subject: Strawman on Delta CRLs

From: Tim Polk <[email-masked]>
Date: Fri, 11 May 2001 15:07:08 -0400

Folks,

David Cooper, Russ Housley and I have collaborated on a "strawman" 
describing the use of delta CRLs in PKIX implementations.  We believe the 
functionality we describe is consistent with ISO X.509 as well.

The text describes algorithms for using deltas and base CRLs to (a) check 
the status of a certificate or (b) create a constructed CRL.  This is 
followed by three scenarios for the use of deltas - "traditional deltas", 
"sliding window deltas", and a variant on sliding window deltas that 
factors in the real world delays in populating repositories with base and 
delta CRLs.

I have appended the strawman below in ASCII text.  The text includes tables 
for the examples.  Please note, these tables *require* a fixed font to be 
legible.  If you would prefer a copy in either Word or PDF, I have posted 
them at the following URLs:
http://csrc.nist.gov/pki/documents/PKIX/PKIXdeltas.doc and 
http://csrc.nist.gov/pki/documents/PKIX/PKIXdeltas.pdf

Hopefully, this strawman will serve to frame further discussions and 
accelerate consensus.   Once we agree on the requirements, Russ and I will 
draft the necessary changes and we can finish Last Call.  (I am nothing if 
not an optimist.)

We would also like to add the examples as an *informative* appendix in 
son-of-2459.

Thanks,

Tim Polk

--------------------------------strawman---------------------------

Implementing Delta CRLs Using PKIX

This paper addresses the use of delta CRLs in PKIX-compliant systems.
This paper assumes that delta CRLs include the delta CRL indicator
extension (rather than a CRL scope extension) and ignores
complications involving combined delta CRLs from indirect CRL issuers.

This paper also assumes that CRLs with different scopes are distributed
using different distribution points.

Terms

Revoked: A statement that a particular certificate's status has changed
and it should no longer be trusted.  Once a certificate is revoked, it
is always revoked.

Suspension: A statement that a particular certificate may not be
trustworthy. Once placed on hold, a certificate may be revoked or the
suspension may be lifted.

Revocation notice: A statement that a particular certificate has been
suspended or revoked.  The revocation statement identifies the certificate
by the issuer name and serial number.  The issuer may be specified
explicitly or implicitly. The issuer may be explicitly identified using
the certificate issuer extension. If not specified explicitly, the issuer
of the certificate is implicitly identified as the issuer of the CRL. A
revocation notice includes the date and time the certificate was revoked.
A revocation notice may optionally include a revocation reason in the
reason code CRL entry extension. [Note: A revocation notice may optionally
specify in the invalidity date extension the date from which the
certificate should be considered invalid.  This date may precede the actual
revocation date.  The invalidity date extension does not feature in this
discussion, so it is not considered further in this paper.]

Certificate revocation list (CRL):  a list of revocation notices for
certificates.

CRL scope: the set of certificates that could appear on a given CRL.
For example, the scope may be "all certificates issued by CA X", "all
CA and end entity certificates issued by CA X", "all certificates issued
by CA X that have been revoked for key compromise and CA compromise", or
may be a set of certificates based on local information, such as "all
certificates issued to the NIST employees located in Boulder".

Full CRL: a CRL that lists all unexpired certificates, in its scope, that
have been revoked for one of the revocation reasons covered by the scope
of the CRL. The scope of a full CRL does not necessarily include all of
the certificates issued by a CA or all possible revocation reasons.

Base CRL:  the particular CRL used as the foundation for a delta CRL.  The
base must be a full CRL.

Delta CRL:  a CRL that only lists those unexpired certificates, in its scope,
whose revocation status has changed since the issuance of a particular,
referenced base CRL. The scope of a delta CRL is must be the same as the base
CRL that it references

CRL Numbering

A CRL issuer may generate full CRLs for more than one scope.  The CRL issuer
may also generate delta CRLs.  Each delta CRLs must have the same scope as the
full CRL referenced as its base.

For each scope supported by the CRL issuer, a numbering sequence must be
maintained.  For each scope, the CRLs are numbered in a monotonically 
increasing
sequence.  (Wrapping is not permitted in the PKIX profile.)  If a CRL issuer
generates CRLs for one scope (e.g., full CRLs and deltas CRLs), the issuer must
maintain one numbering sequence.  If a delta CRL and a full CRL that cover the
same scope are issued at the same time, they will have the same CRL number.

If a CRL issuer generates CRLs for two scopes (e.g., one covering CA
certificates and one covering end entity certificates), then the CRL issuer 
must
maintain two number sequences.  The CRLs and deltas for the same scope 
(e.g., CA
certificates) will share one numbering sequence.  The CRLs and deltas for the
second scope (e.g., end entity certificates) will share one numbering 
sequence.
There is no requirement that these sequences be disjoint.

Algorithms for Determining Status from a Full CRL and a Delta CRL

Consider a full CRL, F, with CRL number X.  A client may obtain BF in either of
the following ways:
(a) the full CRL F may have been pushed to the client or pulled from a 
repository; or
(b) F may have been constructed from a full CRL and a delta CRL using this 
algorithm.

Consider a delta CRL, D, which specifies base CRL Y and has CRL number Z.  This
means that all certificates whose statuses have changed since the issuance 
of CRL Y
will be listed on the delta CRL.  Note that the PKIX profile requires the 
CA to issue
CRL Y as a full CRL.

Determining Whether a Full CRL and Delta CRL May Be Combined

F and D may be combined if each of the following conditions are met:

(1)	X is greater than or equal to Y.  That is, the full CRL must (at a minimum)
contain all the revocation information held by the referenced base CRL.
(2)	X is less than Z.  That is, the delta CRL must cover some time that was not
covered by the full CRL.

Determining Status of a Certificate from a Full CRL and a Delta CRL

If the PKI client maintains the delta and full CRL, the status of an unexpired
certificate C may be determined as follows:

(1)	If C is listed on the delta CRL, then:
a.	If C is listed on the delta CRL with reason code "removeFromCRL", then C
is not revoked.
b.	Otherwise, certificate C is revoked.
(2)	If C was not listed on the delta CRL, then the full CRL is checked, and the
status is as follows:
a.	If C is listed on the full CRL, then C is revoked.
b.	If C is not listed on the full CRL, then C is not revoked.

Combining a Full CRL and Delta CRL into a Constructed CRL

If the PKI client maintains the current CRL in a local cache:

The revocation information on F is assumed as the initial condition.  F is 
a list
of revoked certificates; each certificate is listed with a revocation reason
(which may be "unspecified").

The list of revoked certificates L with n entries denoted as L[i] where 1 
<= i <= n.
(The value n may shrink or grow as the combination process proceeds.)

Initialize L to the revocation notices on F.  For each certificate C on the 
delta CRL,
update the contents of L as follows.

If a certificate C appears on the delta CRL, and C is not currently in the 
list L,
then:
(a)	if C has a revocation reason other than "removeFromCRL", add C as a new 
entry
in  the list of revoked certificates L.
(b)	If C has revocation reason "removeFromCRL", skip this certificate.  No 
update
to the cache is needed.

If a certificate C appears on the delta CRL, and C is presently listed in L 
as entry
L[i], then:
(a)	If C is listed on the delta CRL with a revocation reason of 
"removeFromCRL",
delete entry L[i]
(b)	If C is listed on the delta CRL without a revocation reason or with a 
revocation
reason other than "removeFromCRL", change the reason code associated with 
L[i] to the
reason code specified in the delta CRL.

The combination of F and D forms a new full CRL with CRL number Z.  This 
full CRL has
complete information until the time specified in the next update field in 
the delta CRL
is reached.  If a relying party is validating a certificate with respect to 
time T, and
T is before the next update field in the delta CRL, they may assume 
complete information.

If an unexpired certificate C within the scope of the constructed CRL is 
not listed, then
certificate C is not revoked for one of the revocation reasons covered by 
this CRL.  If
the constructed CRL covers all reasons, then the certificate C is not revoked.

Using Deltas to Distribute Revocation Information

This section provides three different scenarios for the use of delta 
CRLs.  For the
purpose of these examples, assume a goal of providing revocation 
information to relying
parties that is no more than one hour old.

The following notation is used to denote a revoked certificate on a CRL:
		Xr	certificate X is listed for reason r, where r in {a,k,h,r}
The reason codes {a,k,h,r} correspond to "affiliation changed", "key 
compromise",
"certificate hold", and "remove from CRL" respectively.

(Note:  The remaining reason codes are omitted for simplicity.  The handling of
certificates revoked for  the reasons "unspecified", "CA compromise", 
"superseded", and
"cessationOfOperation" are identical to "affiliation changed or "key 
compromise").

Example #1

The example below shows the "traditional" method of issuing delta CRLs.
In this example, full CRLs are issued once every 3 hours and deltas are
issued once an hour. For consistency, the issuer begins issuing deltas
at the same time as the very first full CRL. After that, however, a delta
can always use a previously issued full CRL as its base. Notice that
starting with cRLNumber 4, the delta CRL issued at the same time as a
full CRL uses the previously issued full CRL as its base. However, the
delta-CRLs never provide more than 3 hours of history.

In this example:
Certificate 14 was revoked for key compromise before 12:00 when the first
CRL was issued.
Certificate 124 was revoked for key compromise between 12:00 and 13:00.
Certificate 39 was placed on hold between 14:00 and 15:00, and its
suspension was lifted between 16:00 and 17:00.
Certificate 67 was revoked for an affiliation change between 16:00 and
17:00.  The reason was changed to key compromise between 18:00 and 19:00.

current  | Revoked      | Full CRL                 | Delta-CRL
time     | certificates |                          |
---------|--------------|--------------------------|----------------------
12:00    | {14k}        | cRLNumber = 1            | cRLNumber = 1
          |              | thisUpdate = 12:00       | thisUpdate = 
12:00
          |              | nextUpdate = 15:00       | nextUpdate = 13:00
          |              | CertificateList = {14k}  | BaseCRLNumber = 1
          |              |                          | CertificateList = 
{}
---------|--------------|--------------------------|----------------------
13:00    | {14k, 124k}  |                          | cRLNumber = 2
          |              |                          | thisUpdate = 13:00
          |              |                          | nextUpdate = 14:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
14:00    | {14k, 124k}  |                          | cRLNumber = 3
          |              |                          | thisUpdate = 14:00
          |              |                          | nextUpdate = 15:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
15:00    | {14k, 124k,  | cRLNumber = 4            | cRLNumber = 4
          |   39h}       | thisUpdate = 15:00       | thisUpdate = 
15:00
          |              | nextUpdate = 18:00       | nextUpdate = 16:00
          |              | CertificateList =        | BaseCRLNumber = 1
          |              |  {14k, 124k, 39h}        | CertificateList =
          |              |                          | {124k, 39h}
---------|--------------|--------------------------|----------------------
16:00    | {14k, 124k,  |                          | cRLNumber = 5
          |   39h, 67a}  |                          | thisUpdate = 16:00
          |              |                          | nextUpdate = 17:00
          |              |                          | BaseCRLNumber = 4
          |              |                          | CertificateList = {67a}
          |              |                          |
---------|--------------|--------------------------|----------------------
17:00    | {14k, 124k,  |                          | cRLNumber = 6
          |   67a}       |                          | thisUpdate = 17:00
          |              |                          | nextUpdate = 18:00
          |              |                          | BaseCRLNumber = 4
          |              |                          | CertificateList =
          |              |                          | {39r, 67a}
---------|--------------|--------------------------|----------------------
18:00    | {14k, 124k,  | cRLNumber = 7            | cRLNumber = 7
          |   67a}       | thisUpdate = 18:00       | thisUpdate = 
18:00
          |              | nextUpdate = 21:00       | nextUpdate = 19:00
          |              | CertificateList =        | BaseCRLNumber = 4
          |              | {14k, 124k, 67a}         | CertificateList =
          |              |                          | {39r, 
67a}
---------|--------------|--------------------------|----------------------
19:00    | {14k, 124k,  |                          | cRLNumber = 8
          |   67k}       |                          | thisUpdate = 19:00
          |              |                          | nextUpdate = 20:00
          |              |                          | BaseCRLNumber = 7
          |              |                          | CertificateList = {67k}
---------|--------------|--------------------------|----------------------

Scenario #2

The example below shows the "sliding window" method of issuing delta-CRLs.
In this example, full CRLs are issued once every 3 hours and deltas are
issued once an hour. For consistency, the issuer begins issuing deltas at
the same time as the very first full CRL. Notice that starting with
cRLNumber 7, the delta CRL issued at the same time as a full CRL does not
use the previously issued full CRL as its base but the preceding CRL instead.
However, these delta-CRLs never provide more than 6 hours of history.

As in example #1:
Certificate 14 was revoked for key compromise before 12:00 when the first
CRL was issued.
Certificate 124 was revoked for key compromise between 12:00 and 13:00.
Certificate 39 was placed on hold between 14:00 and 15:00, and its
suspension was lifted between
16:00 and 17:00.
Certificate 67 was revoked for an affiliation change between 16:00 and 17:00.
The reason was changed to key compromise between 18:00 and 19:00.

current  | Revoked      | Full CRL                 | Delta-CRL
time     | certificates |                          |
---------|--------------|--------------------------|----------------------
12:00    | {14k}        | cRLNumber = 1            | cRLNumber = 1
          |              | thisUpdate = 12:00       | thisUpdate = 
12:00
          |              | nextUpdate = 15:00       | nextUpdate = 13:00
          |              | CertificateList = {14k}  | BaseCRLNumber = 1
          |              |                          | CertificateList = 
{}
---------|--------------|--------------------------|----------------------
13:00    | {14k, 124k}  |                          | cRLNumber = 2
          |              |                          | thisUpdate = 13:00
          |              |                          | nextUpdate = 14:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
14:00    | {14k, 124k}  |                          | cRLNumber = 3
          |              |                          | thisUpdate = 14:00
          |              |                          | nextUpdate = 15:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
15:00    | {14k, 124k,  | cRLNumber = 4            | cRLNumber = 4
          |   39h}       | thisUpdate = 15:00       | thisUpdate = 
15:00
          |              | nextUpdate = 18:00       | nextUpdate = 16:00
          |              | CertificateList =        | BaseCRLNumber = 1
          |              |  {14k, 124k, 39h}        | CertificateList =
          |              |                          | {124k, 39h}
---------|--------------|--------------------------|----------------------
16:00    | {14k, 124k,  |                          | cRLNumber = 5
          |   39h, 67a}  |                          | thisUpdate = 16:00
          |              |                          | nextUpdate = 17:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList =
          |              |                          | {124k, 39h, 67a}
---------|--------------|--------------------------|----------------------
17:00    | {14k, 124k,  |                          | cRLNumber = 6
          |   67a}       |                          | thisUpdate = 17:00
          |              |                          | nextUpdate = 18:00
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList =
          |              |                          | {124k, 39h, 67a}
---------|--------------|--------------------------|----------------------
18:00    | {14k, 124k,  | cRLNumber = 7            | cRLNumber = 7
          |   67a}       | thisUpdate = 18:00       | thisUpdate = 
18:00
          |              | nextUpdate = 21:00       | nextUpdate = 19:00
          |              | CertificateList =        | BaseCRLNumber = 1
          |              | {14k, 124k, 67a}         | CertificateList =
          |              |                          | {124k, 39r, 67a}
---------|--------------|--------------------------|----------------------
19:00    | {14k, 124k,  |                          | cRLNumber = 8
          |   67k}       |                          | thisUpdate = 19:00
          |              |                          | nextUpdate = 20:00
          |              |                          | BaseCRLNumber = 7
          |              |                          | CertificateList =
          |              |                          | {39r, 67k
---------|--------------|--------------------------|----------------------

Note that the delta CRLs are marginally larger than in the first scenario
since they cover a longer time period.  On the other hand, a relying party
is less likely to download full CRLs in the second scenario.

For example, a relying party that validated one certificate at 12:15, then
a second certificate at 16:15 would not require a new full CRL in scenario #2.
In scenario #1, the relying party would be forced to obtain both full CRL 4
and delta CRL 5.

Scenario #3 Allowing for Replication/Propagation Delays

In this scenario, full CRLs and delta CRLs are replicated throughout a
repository system.  Data is replicated through the system at different
rates based on the size of the file.  The CA operators estimate that full
CRLs will be available throughout the system within three hours.  Delta CRLs
will be available within 15 minutes.  (Assume the initial CRL is small and
will propagate as if a delta CRL to resolve the bootstrap issues.)

The example below uses the "sliding window" method of issuing delta-CRLs,
but overlaps the thisUpdate and nextUpdate times to allow for propagation.
In this example, full CRLs are issued once every 3 hours and deltas are
issued every 45 minutes. For consistency, the issuer begins issuing deltas
at the same time as the very first full CRL. Notice that starting with
cRLNumber 7, the delta CRL issued at the same time as a full CRL does not
use the previously issued full CRL as its base but the preceding CRL instead.
As in example #2, these delta-CRLs never provide more than 6 hours of history.

Similary to examples #1 and #2:
Certificate 14 was revoked for key compromise before 12:00 when the first CRL
was issued.
Certificate 124 was revoked for key compromise between 12:00 and 12:45.
Certificate 39 was placed on hold between 14:15 and 15:00, and its suspension
was lifted between 16:00 and 17:00.
Certificate 67 was revoked for an affiliation change between 15:45 and 16:30.
The reason was changed to key compromise between 18:00 and 18:45.

current  | Revoked      | Full CRL                 | Delta-CRL
time     | certificates |                          |
---------|--------------|--------------------------|----------------------
12:00    | {14k}        | cRLNumber = 1            | cRLNumber = 1
          |              | thisUpdate = 12:00       | thisUpdate = 
12:00
          |              | nextUpdate = 18:00       | nextUpdate = 13:00
          |              | CertificateList = {14k}  | BaseCRLNumber = 1
          |              |                          | CertificateList = 
{}
---------|--------------|--------------------------|----------------------
12:45    | {14k, 124k}  |                          | cRLNumber = 2
          |              |                          | thisUpdate = 12:45
          |              |                          | nextUpdate = 13:45
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
13:30    | {14k, 124k}  |                          | cRLNumber = 3
          |              |                          | thisUpdate = 13:30
          |              |                          | nextUpdate = 14:30
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
14:15    | {14k, 124k}  |                          | cRLNumber = 4
          |              |                          | thisUpdate = 14:15
          |              |                          | nextUpdate = 15:15
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList = {124k}
---------|--------------|--------------------------|----------------------
15:00    | {14k, 124k,  | cRLNumber = 5            | cRLNumber = 5
          |   39h}       | thisUpdate = 15:00       | thisUpdate = 
15:00
          |              | nextUpdate = 21:00       | nextUpdate = 16:00
          |              | CertificateList =        | BaseCRLNumber = 1
          |              |  {14k, 124k, 39h}        | CertificateList =
          |              |                          | {124k, 39h}
---------|--------------|--------------------------|----------------------
15:45    | {14k, 124k,  |                          | cRLNumber = 6
          |   39h, 67a}  |                          | thisUpdate = 15:45
          |              |                          | nextUpdate = 16:45
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList =
          |              |                          | {124k, 39h, 67a}
---------|--------------|--------------------------|----------------------
16:30    | {14k, 124k,  |                          | cRLNumber = 7
          |   67a}       |                          | thisUpdate = 16:30
          |              |                          | nextUpdate = 17:30
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList =
          |              |                          | {124k, 39r, 67a}
---------|--------------|--------------------------|----------------------
17:15    | {14k, 124k,  |                          | cRLNumber = 8
          |  67a}        |                          | thisUpdate = 17:15
          |              |                          | nextUpdate = 18:15
          |              |                          | BaseCRLNumber = 1
          |              |                          | CertificateList =
          |              |                          | {124k, 39r, 67a}
---------|--------------|--------------------------|----------------------
18:00    | {14k, 124k,  | cRLNumber = 9            | cRLNumber = 9
          |   67a}       | thisUpdate = 18:00       | thisUpdate = 
18:00
          |              | nextUpdate = 24:00       | nextUpdate = 19:00
          |              | CertificateList =        | BaseCRLNumber = 5
          |              | {14k, 124k, 67a}         | CertificateList =
          |              |                          | {39r, 67a}
---------|--------------|--------------------------|----------------------
18:45    | {14k, 124k,  |                          | cRLNumber = 10
          |   67k}       |                          | thisUpdate = 18:45
          |              |                          | nextUpdate = 19:45
          |              |                          | BaseCRLNumber = 5
          |              |                          | CertificateList =
          |              |                          | {39r, 67k}
---------|--------------|--------------------------|----------------------

Delta CRL number 6 is issued at 15:45.  By 16:00, delta CRL number 6 should
be available throughout the system.  As a result, delta CRL number 5 specified
16:00 as its nextUpdate time.

However, full CRL number 5 was issued at 15:00 and may not be available
throughout the system  until 18:00.  As a result, full CRL number 1 specified
18:00 as its nextUpdate time.  In addition, delta CRL number 6 must be based
on full CRL number 1 which was issued at 12:00.

If the relying party finds full CRL number 5 in the repository, they may still
apply delta CRL number 6 and achieve the correct answer.

Finally, note that a CRL issuer must generate more CRLs to achieve the goal of
status information that is no more than one hour old when factoring in the
propagation delays.

---

From: "Sarbari Gupta" <[email-masked]>
Date: Wed, 16 May 2001 11:02:52 -0400

Tim, David, Russ,

The "strawman" on the use of delta CRLs was very precise and clear - thank you. I know this thread had been discussed to death already, but I did have a comment:

It seems counterproductive to have CRLs and delta-CRLs that are valid in parallel as in your examples. CRL #1 is valid between 12:00 and 15:00, and delta CRL #3 is valid between 14:00 and 15:00. If I am trying to validate certificate 124 at 14:30, I will get opposite results if I use CRL #1 versus delta CRL #3 - yet both are valid at the time. 

I can understand CRLs and OCSP giving different revocation status because of the different levels of latency. Why is it a good idea to have contradictory results with the same (CRL) mechanism? More importantly, why should the standard be formulated to allow such usage of CRLs, where you can have two CRLs that are both valid yet contradict each other? 

I would vote for CRLs and delta CRLs to have non-overlapping validity periods so that there is no possibility of a contradictory revocation status. If network delays are a problem, engineering solutions need to be found - the validity period of the CRL may need to be adjusted to be larger than the anticipated network delay, or the scope of the CRL may be adjusted to allow smaller-sized CRLs, or perhaps, a different revocation checking mechanism should be considered. 

- Sarbari Gupta
==============================
Sarbari Gupta
Electrosoft Services, Inc.
Tel: (703)861-2108
FAX: (703)757-0040
Email: [email-masked]
Web: <http://www.electrosoft-inc.com/>
==============================

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Tim Polk
Sent: Friday, May 11, 2001 3:07 PM
To: [email-masked]
Subject: Strawman on Delta CRLs

Folks,

Thanks,

Tim Polk

--------------------------------strawman---------------------------

Terms

CRL Numbering

Example #1

In this example:

Scenario #2

As in example #1:

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 16 May 2001 12:58:18 -0400

Sarbari,

The CRLs in the examples do not give contradictory results because CRLs
do *not* have a validity period, they have a validity instant.

CRL #1 is valid at 12:00.  The next CRL might be issued at
15:00, but it also might be issued at 12:05.

CRL #3 is valid at 14:00.

CRL #3's thisUpdate is two hours later than CRL #1's. CRL #3
contains fresher revocation information, and it is incorrect
to assert that that information "contradicts" the staler
information in CRL #1.

CRLs, like OCSP responses, are valid at the instant they
are issued, and no longer.  Relying Parties may use nextUpdate to
determine when to look for a new CRL.  But RPs must not delude
themselves into thinking that an old CRL is magically "valid"
until its nextUpdate, because another CRL, delta or full, could
have been issued seconds later.

Dave

---

From: Tim Polk <[email-masked]>
Date: Wed, 16 May 2001 15:06:30 -0400

Sarbari,

Having CRLs and delta-CRLs that are valid in parallel is a *feature*. 
<smile>  It may be reasonable in some applications to accept CRLs that are 
updated relatively infrequently.  Other applications may demand the 
freshest information available.  By including the freshestCRL extension in 
a CRL, the relying party can determine which category they fall in and 
decide if they should retrieve the delta.  This lets the relying party 
manage the risk according to the threat it faces.

However, a CA that wants to maintain control can do so.  If a CA wishes to 
ensure that all parties use the freshest information possible, they can 
always issue a full CRL simultaneously with each delta.  In this case, the 
full CRLs are valid for relatively short periods, and clients that cannot 
process delta CRLs may consume a lot of network bandwidth downloading full 
CRLs.

There are tradeoffs with both approaches (i.e., relying party control vs. 
CA control).  The algorithms described in the delta CRL strawman have the 
flexibility to support local requirements.  I think that is the right choice.

BTW, I do not accept the notion that OCSP requests and CRL processing 
inherently provides different latency to the relying party.  Since most 
OCSP servers obtain certificate status information in the form of CRLs, the 
information obtained by relying parties has the same latency regardless of 
the source.  Where an OCSP server and CA are the same system, the latency 
will be different.  However, this is a theoretical distinction since (most? 
all?) OCSP servers are separate systems.

Thanks,

Tim

At 11:02 AM 5/16/01 -0400, Sarbari Gupta wrote:
>Tim, David, Russ,
>
>The "strawman" on the use of delta CRLs was very precise and clear - thank 
>you. I know this thread had been discussed to death already, but I did 
>have a comment:
>
>It seems counterproductive to have CRLs and delta-CRLs that are valid in 
>parallel as in your examples. CRL #1 is valid between 12:00 and 15:00, and 
>delta CRL #3 is valid between 14:00 and 15:00. If I am trying to validate 
>certificate 124 at 14:30, I will get opposite results if I use CRL #1 
>versus delta CRL #3 - yet both are valid at the time.
>
>I can understand CRLs and OCSP giving different revocation status because 
>of the different levels of latency. Why is it a good idea to have 
>contradictory results with the same (CRL) mechanism? More importantly, why 
>should the standard be formulated to allow such usage of CRLs, where you 
>can have two CRLs that are both valid yet contradict each other?
>
>I would vote for CRLs and delta CRLs to have non-overlapping validity 
>periods so that there is no possibility of a contradictory revocation 
>status. If network delays are a problem, engineering solutions need to be 
>found - the validity period of the CRL may need to be adjusted to be 
>larger than the anticipated network delay, or the scope of the CRL may be 
>adjusted to allow smaller-sized CRLs, or perhaps, a different revocation 
>checking mechanism should be considered.
>
>- Sarbari Gupta
> {124k}
> {124k}
> {124k}
> {124k}
> {124k}
> {124k}
> {124k}

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 18 May 2001 18:58:17 +0200

David,

I agree with Sabari, so I feel sorry to disagree with you.

> do *not* have a validity period, they have a validity instant.

The text from X.509 (nor RFC 2459) does not say this.

Now let us look what people do in practice. They want to make sure that a
CRL is valid at the instant T. So any CRL where the following condition is
met is a good CRL.

thisUpdate < T < nextUpdate

So if an emergency CRL is issued, two CRLs will meet the condition.

For that reason it is dangerous to issue "emergency CRLs", that contain
references to non repudiation certificates, as soon as there is a key
compromise, because one party may get it, while the other may not. 

If, using a CRL mechanism, there is a need to advertise as early as possible
a key compromise then delta CRLs should be used. Delta-CRLs can be issued
much more frequently. If relying parties are informed that they MUST fetch
delta CRLs, and if there is a denial of service attack on the delta CRLs,
then relying parties must not accept the certificate: they may either reject
it if they cannot wait or if they can wait, wait until they can get access
to the delta CRLs again.
 
Denis