Delta CRL processing

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

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?