Subject: RE: Delta CRL processing

From: Santosh Chokhani <[email-masked]>
Date: Mon, 19 Apr 1999 12:32:53 -0400

Dave:

You are correct.  This wording seems to be wrong.  The proper way to use
a delta CRL is to apply it to an appropriate base CRL.  A delta CRL need
not be applied previous deltas since deltas are issued with respect to a
base.

> -----Original Message-----
> From:	David P. Kemp [SMTP:[email-masked]]
> Sent:	Monday, April 19, 1999 11:53 AM
> To:	[email-masked]
> Subject:	Delta CRL processing
> 
> 
> 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: "Bob Jueneman" <[email-masked]>
Date: Wed, 21 Apr 1999 14:54:56 -0600

David, I appreciate and agree with your analysis in this case.
It would indeed be perverse to implement a more efficient
algorithm such as delta-CRLs, and then force the CA to go 
through an onerous and unnecessary publication step.

If "issue" in this case is closer to "create the equivalent of and 
hold it in a private archive in case it's needed", I'm perfectly 
happy. But what, precisely, does  RFC 2459 currently require, 
and does the language need to be modified to fit this 
interpretation of x.509?

With respect to what Juergan called an epsilon-CRL, i.e.,
a delta CRL that is NOT cumulative since the last base, but 
instead is incremental, requiring the entire collection in order 
to be complete, I was not proposing such a construct -- I just
want to be clear that WASN'T what we were doing.

I'm not necessarily opposed to such a function -- I just
haven't heard a sufficient explanation of where it might
apply to be convinced yet.

Regards,

Bob

>>> "David P. Kemp" <[email-masked]> 04/21/99 01:27PM >>>

> From: Russ Housley <[email-masked]>
> 
> Bob:
> 
> delta-CRLs do not operate as you describe.  They are the updates since the
> specified base.  Further, X.509 requires the CA to issue a full CRL every
> time that a delta-CRL is generated.  RFC 2459 did not create this
> requirement, itis inherited from X.509.
> 
> Russ

We need a glossary which clarifies exactly what X.509 means by "issue".

In a private message, Sharon Boeyen points out:

  "As of the 1997 edition of X.509 a CA is NOT required to publish
  a full CRL."

I claim that not only does an X.509 CA not have to "publish" a full
CRL, it also does not need to create a DER representation of the CRL
or generate a signature of that DER.  The intent of the word "issue"
is to ensure that at any point in time, there is a single, unique,
unambiguous instance of a full CRL that would have been generated and
published had the CA chosen to do so.  Or in other words, if an
application reconstructs the revocation status for a certain point in
time, it will always reconstruct the same status as would have been
obtained had a full CRL been generated, published, and retrieved.  It
must be impossible to take two different inputs (combinations of full,
delta, and DP-partitioned CRLs) and arrive at conflicting conclusions
as to the status of a given certificate.

This is analogous to the procedure for Certification Path Validation,
which says:

  "Conforming implementations ... are not required to implement this
   algorithm, but shall be functionally equivalent to the external
   behavior resulting from this procedure."

Reference algorithms are often chosen to emphasize simplicity,
correctness and tutorial value instead of operational efficiency.
Optimizations may be applied as long as the optimized algorithm yields
correct results.  The external result of CRL processing is the
revocation status of a particular certificate at a particular time, and
the correct answer is the one which would have been obtained from a
full CRL.

It would be perverse indeed to interpret X.509 as saying that optimized
revocation methods are allowed, as long as you also perform the
unoptimized reference method in parallel!

---

From: "Bob Jueneman" <[email-masked]>
Date: Fri, 23 Apr 1999 12:25:53 -0600

Paul, I agree.

>Similarly, the only statements about a CA that can be normative are
>those that are externally observable.  If a CA publishes a CRL, that
>is observable.  If it generates one that it doesn't publish, that's an
>internal algorithm and illustrative only.
>
>With that in mind, if X.509 *requires* a CA to "issue" a CRL under
>some conditions, there are two possible conclusions:
>
>1. The term "issue" describes externally visible behavior, i.e., it is 
>synonymous with "publish", or
>
>2. The term "issue" describes internal behavior, is not meant as
>"publish" and the standard is in error in that it appears to require
>something that isn't observable.
>
>	paul

Since it is clear from the final paragraph of that section that the CA is 
not required to _publish_ the issued the CRL, the standard is over-reaching
by specifying something that isn't visible.  I would suggest submitting a
defect report to X.509 to remove the entire section having to do with 
"issuing" a certificate that isn't published and isn't needed.  Simultaneously,
we can clean up the language of RFC 2459 in a similar fashion..

Bob