Re: draft delta crl text

["Al Arsenault" <awa1@xxxxxxxx>]

David C. wrote:

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

My personal preference in such a scenario would be to have the entry remain
on the "non-compromise" CRL as well as being placed on the "compromise" CRL.
That guarantees that it doesn't fall off the CRL entirely because a timing
problem in issuance of CRLs by different issuers (as pointed out by Carlin
in a subsequent post).  And, while I recognize that this is a somewhat
hypothetical scenario, it's doubtful that the subject of a cert revoked for
"affiliationChanged" would suddenly have its "affiliation unchanged".

If we're being consistent with explicit X.509 actions in other areas :-) we
should do so here and only support removeFromCRL because of certificate
expiration or status change. In general, I think that the text David and Tim
have proposed here is acceptable, with a clarification of what "status
change" means.

If necessary, you can add text that describes the above scenario and
provides whatever the consensus PKIX recommendation is, but I'm not sure
that it is necessary at this point.

        Al Arsenault
        Chief Security Architect
        Diversinet Corp.