Subject: Re: Delta CRL processing

From: "Bob Jueneman" <[email-masked]>
Date: Thu, 22 Apr 1999 16:41:55 -0600

I must be dense, Russ. The text you attached seems to agree precisely
with what Sharon said, and was exactly what I was requesting as well.

Sharon used the term "publish", not "issue", and the last paragraph 
certainly seems to be quite explicit in allowing that option, by differentiating 
between issuing and publishing.

Why do you disagree?  What am I missing? 

Bob

>>> Russ Housley <[email-masked]> 04/22/99 01:38PM >>>
>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 disagree with Sharon.  X.509-1997 says: " ... It is the decision of a CA
as to whether to provide delta-CRLs. However, a delta-CRL shall not be
issued without a corresponding complete CRL being issued at the same time."
 I have attached the entire section on delta-CRLs from X.509-1997 at the
end of this message.

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

Agree.

>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!
>

Russ

--- Begin Section 12.6.3.3 from X.509-1997 ---

12.6.3.3	Delta CRL indicator field

This CRL extension field identifies a CRL as being a delta-CRL only. This
field is defined as follows:

   deltaCRLIndicator EXTENSION ::= {
	SYNTAX		BaseCRLNumber
	IDENTIFIED BY 	id-ce-deltaCRLIndicator }
   BaseCRLNumber ::= CRLNumber

The value of type BaseCRLNumber identifies the CRL number of the base CRL
that was used as the starting point in the generation of this delta-CRL,
i.e. this delta-CRL contains the changes between the base CRL and the
complete CRL issued along with this delta-CRL. It is the decision of a CA
as to whether to provide delta-CRLs. However, a delta-CRL shall not be
issued without a corresponding complete CRL being issued at the same time.
The value of the CRL number, as conveyed in the CRL number extension field
(if present), shall be identical for both the delta-CRL and the
corresponding complete CRL. 

The CRL user constructing a locally held CRL from delta-CRLs shall consider
the constructed CRL incomplete and unusable if both the following
conditions are true:

-  the value of the CRLNumber of the received delta-CRL is more than one
greater than that of the CRLNumber of the delta-CRL last processed; and

-  the value of BaseCRLNumber of the received delta-crl has changed from
the BaseCRLNumber of the delta-CRL last processed.

This extension is always critical. A certificate user that does not
understand the use of delta-CRLs should not use a CRL containing this
extension, as the CRL may not be as complete as the user expects. CRLs not
containing critical extensions must contain all current CRL entries for the
issuing CA, including entries for all revoked user certificates and CA
certificates.

NOTE-It is the decision of the CA as to whether or not to distribute the
CRLs issued between two base CRLs. For example, it may be the policy of the
CA to distribute base CRLs via CD-ROM and delta-CRLs via an on-line service
such as the Directory. Although the CA had issued its CRL with the
associated  delta-CRL, it may be the CA's policy that the user shall
construct the current CRL by applying the delta-CRL to the base CRL held on
the CD-ROM.

--- End Section 12.6.3.3 from X.509-1997 ---

---

From: Paul Koning <[email-masked]>
Date: Fri, 23 Apr 1999 10:56:08 -0400

>>>>> "Bob" == Bob Jueneman <[email-masked]> writes:

 Bob> I must be dense, Russ. The text you attached seems to agree
 Bob> precisely with what Sharon said, and was exactly what I was
 Bob> requesting as well.

 Bob> Sharon used the term "publish", not "issue", and the last
 Bob> paragraph certainly seems to be quite explicit in allowing that
 Bob> option, by differentiating between issuing and publishing.

 Bob> Why do you disagree?  What am I missing?

 Bob> Bob

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

 > I disagree with Sharon.  X.509-1997 says: " ... It is the
 > decision of a CA as to whether to provide delta-CRLs. However, a
 > delta-CRL shall not be issued without a corresponding complete
 > CRL being issued at the same time."  I have attached the entire
 > section on delta-CRLs from X.509-1997 at the end of this
 > message.

I think it would be a good idea to apply the normal "black box rule of 
protocol specification" to this issue.  In protocol specs, the only
parts that can be normative are those that describe externally visible 
behavior.  If anything is said about internal algorithms, that is only 
for illustrative purposes.

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