[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft delta crl text
David,
In lieu of my suggested text, I would be perfectly happy with a
definition of "status change," a caveat concerning requirements
applying only to in-scope certificates, and a note addressing the
de-listing of certificates after expiration.
You make some excellent points about concerning coordination between
CRL's of different scopes. When I wrote my suggested wording
I was not thinking of the case of a certificate hopping from one CRL
or delta CRL to another due to a change in reasonCode. This situation
brings to mind another knotty problem. Suppose the CRL or DCRL that a
revoked certificate is hopping from is due for an update, but the CRL
or DCRL that the certificate is hopping to is not yet due for an update.
It seems inadvisable for the certificate to be listed on neither CRL
(i.e. temporarily valid) until the second CRL is updated. The situation
is exacerbated if the two CRL's are issued by different authorities.
Perhaps the revoked certificate should continue to be listed on the
first CRL despite the fact that it is (or will be) on the second CRL.
Regards,
Carlin
____________________________
- Carlin Covey
Cylink Corporation
-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of David A. Cooper
Sent: Friday, June 01, 2001 3:05 PM
To: ietf-pkix@xxxxxxx
Subject: RE: draft delta crl text
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