RE: draft delta crl text

["David A. Cooper" <david.cooper@xxxxxxxx>]

Carlin,

This is text that Tim Polk and I spent a long time trying to develop. Our goal was to get as close as possible to being "technically correct" while still having text that people could understand. Perhaps we're not quite there yet.

First, we did not intend to include events such as the creation or expiration of a certificate as a "status change". Instead a status change could be a change from:

         a) valid to on hold
         b) on hold to valid
         c) valid (or on hold) to revoked
         d) a change in revocation reason (e.g., from affiliationChanged to keyCompromise)

Perhaps we need to define status change. We should also explicitly status that the requirement only applies to certificates that are within the scope of the delta-CRL.

The biggest complication that we needed to deal with was a result of two factors:

         1) It is possible for the revocation reason on a certificate to change
             after the certificate has been revoked.

         2) The scope of a CRL may not include all revocation reasons.

Imagine, for example, that a CA issues two streams of CRLs for the certificates that it issues: one that covers all certificates that have been revoked for keyCompromise or cACompromise and the other that covers all certificates that have been revoked for some other reason. Suppose that the delta-CRLs are issued for the second scope and that the revocation reason for a certificate that was originally revoked with reason code affiliationChanged is changed to keyCompromise. If the base CRL (or a subsequently issued CRL) includes the certificate with reason code affiliationChanged, what should the delta-CRL say? If the delta-CRL specifies reason code affiliationChanged, that is no longer accurate. The delta-CRL could list the certificate with reason code keyCompromise, but this would be "out of scope" for the delta-CRL. In fact, a concurrently issued complete CRL for the "non-compromise" scope would simply not list the certificate. So, it seems that the appropriate thing would be for the delta-CRL to list the certificate with reason code removeFromCRL with the understanding that the certificate would now be included in CRLs issued for the "compromise" scope. Tim and I were trying to account for examples such as this in the text that we wrote.

I noticed, however, that X.509 states:

         The removeFromCRL reason code is for use with delta-CRLs (see 8.6) only
         and indicates that an existing CRL entry should now be removed owing to
         certificate expiration or hold release. An entry with this reason code shall be
         used in delta-CRLs for which the corresponding base CRL or any subsequent
         (delta or complete for scope) CRL contains an entry for the same certificate
         with reason code certificateHold.

So, perhaps it would be improper in the example above to list the certificate with reason code removeFromCRL. I don't know if the effect of the text above on examples such as the one I provided was intentional or simply a failure to account for such odd cases.

In practice, I hope that this isn't a problem. I, personally, can not think of a reason to issue delta-CRLs for CRL scopes that do not include all revocation reasons. However, since such delta-CRLs are "legal", the text should correctly state how to generate them.

Any suggestions on how to address these issues would be welcome.


At 06:56 AM 6/1/01 -0700, Carlin Covey wrote:
>Tim,
>
>A commendable job, but I do have a comment concerning the following
>portion of the text:
>
>"For each certificate whose status has changed since the generation
>of the referenced base CRL:
>
>       (a)  If the certificate is revoked for a reason included in the
>       scope of the CRL, list the certificate as revoked.
>
>       (b)  If not (a), list the certificate with the reason code
>       removeFromCRL."
>
>
>Rule (a) is fine, but unfortunately rule (b) catches more certificates
>in its net than was intended.  A literal reading implies that
>certificates should be listed with reason code removeFromCRL if their
>status has changed in any way at all, e.g. newly created certificates,
>newly expired certificates, and even revoked or "removed from hold"
>certificates that are not within the scope of the CRL.  (These are all
>certificates whose status has changed that are "not (a)" )
>
>Here's a suggestion for rule (b):
>
>        If the certificate was previously listed on the referenced base
>        CRL or a subsequent delta CRL with reason code certificateHold,
>        and that certificate is no longer on hold, list the certificate
>        with the reason code removeFromCRL.

Just a minor nit. There is no requirement for a delta CRL to use the most recently issued complete CRL as its base. So,  "subsequent delta CRL" should instead be "subsequent CRL (delta CRL or complete CRL)".

>By the way, although this is fairly obvious, for the sake of completeness
>perhaps we should add a caveat that certificates can be de-listed after
>they expire.  We might also want to some text similar to this text from the
>Federal Bridge CA Profile:
>"Certificates remain on the CRL and ICRL one inclusion interval beyond
>their expiration date."
>
>Regards,
>
>Carlin