Subject: Delta CRL processing

From: "David P. Kemp" <[email-masked]>
Date: Mon, 19 Apr 1999 11:53:07 -0400 (EDT)

RFC 2459 section 5.2.4 contains the following requirement:

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

Aside from being poorly specified (what happens the first time a
delta-CRL is used and there isn't one that was last processed?), the
requirement adds no security value.  But more importantly, it effectively
precludes the use of delta-CRLs to support near-realtime certificate
status checking.

Consider the following scenario:

1. A CA generates and posts to the distribution channel a full CRL every
  7 days.  The thisUpdate field is set to time T, and the nextUpdate
  field is set to time T + 7 days.

2. The CA generates and posts to a (probably different) distribution
  channel a delta CRL every 60 seconds.  The BaseCRLNumber refers to
  the most recent full CRL issued in step 1 at time T.  (To conform
  with another unnecessary RFC2459 requirement, the CA also "issues",
  but does not necessarily post, a full CRL every 60 seconds,
  incrementing CRLNumber each time.  These would be considered
  unscheduled updates, despite their being "issued" on a regular
  schedule. :-)  When I discussed the X.509 text with Hoyt a while
  back, he pointed out the useful distinction between issuing and
  distributing.  If a tree falls in an empty forest, is there a sound?
  If a CRL is issued but not distributed, does it exist? :-)

* A relying application validates a certificate, fetches the applicable
  base CRL for time T, and fetches the current delta CRL, say for time
  T + 13 hours 37 min.  A couple of hours later, it validates another
  cert, fetching the delta CRL for time T + 15 hours 45 min.  Since
  the base CRL is still valid, it doesn't need to be fetched again,
  saving the bandwidth of a year's worth of revocations.
  
In this scenario, the relying application gets revocation information
as fresh as its policy requires (24 hours, 4 hours, 15 min, or 1 min),
yet it only incurs the transmission cost of fetching full CRLs every 7
days.  The delta CRLs only contain up to a week's worth of revocations,
so they don't add much overhead to the validation process.  They could
either be fetched by the verifier(s) when needed, or fetched by the signer
and passed to the verifier(s) along with the signed info.

This scenario is, as far as I can tell, secure.  Yet it violates the
1-up rule cited above.

If the 1-up rule serves no security-enhancing purpose, can it be
scrapped when the PKIX profile goes to Draft?  If the rule does enhance
security, can someone describe the hole in this scenario?

---

From: Russ Housley <[email-masked]>
Date: Mon, 19 Apr 1999 15:44:49 -0400

Dave:

I thought some background might help.  When I was drafting the CRL section
for RFC 2459, I wanted to say "do not used delta-CRLs."  I was convinced
that they have some value when a high-end server caches CRL information in
a local format for rapid access.  In this environment, the delta-CRL is
used to update the server-friendly data structure without having to process
the entire CRL.  Note that X.509 requires that a full CRL be generated
every time that a delta-CRL is generated.  So, it seemed to be reasonable
that the server obtain the most recent full CRL when it has a few spare
cycles.  This means that the delta-CRL information is only used for a brief
period until the server have resources to convert the most recent full CRL
into the server-friendly format.

Russ

---

From: Francois Rousseau <[email-masked]>
Date: Wed, 21 Apr 1999 15:34:37 -0400

Note that Clause 12.6.3.3 on the Delta CRL indicator field in the Proposed
Draft Amendment (PDAM) on X.509(97) was already clarifying part of this
issue, however this item was discussed further at the last Directory
Working Group meeting in Orlando.

The revised Clause 12.6.3.3 in the Final PDAM (FPDAM) on X.509 (97) should
soon be available. It will include a more precise explanation of the
proposed rules for constructing delta-CRLs along with a more extensive
example of their use.

Francois Rousseau
AEPOS Technologies

---

From: Russ Housley <[email-masked]>
Date: Thu, 22 Apr 1999 15:40:09 -0400

Francois:

Irt will still be a Proposed Draft Addendum, not a standard (yet).

Russ