Subject: Re: Removing expired certificates from CRLs.....

From: Nada Kapidzic Cicovic <[email-masked]>
Date: Wed, 05 Sep 2001 11:48:26 +0200

Ryan,

Some years ago we at Entegrity also had similar discussion. We were
positive CRLs were not to contain the information about the expired
certificates, until we came across some industry CA CRLs containing
information about all revoked certificates. We then looked into 2459
(draft in those days) and X.509 text and came to the conclusion that
deleting info about expired certificates from a CRL is only an
option.

I am not sure what was the intention of the original authors of X.509
(perhaps Sharon and Hoyt know more about it), but the current industry
practice seems to be a mixture of both approaches.

My personal opinion is that keeping all revoked certificates info in CRLs
brings more problems than benefits. However, it is questionable whether
PKIX needs to take a vote for one approach or the other.

In any case I would suggest that the text of 2459 be modified so that it
has a MAY (or a MUST) consistently
in all places where deleting expired certificates revocation info from
CRLs is mentioned. The current text only brings confusion, as you have
already pointed out.

Nada

At 08:49 PM 9/4/01 -0700, Ryan Hurst wrote:

I was
speaking with Peter Williams today about the removal of expired
certificates from CRLs; I have always been under the belief that this
behavior was optional, I vaguely remembered reading text in 2459 along
those lines; additionally I know of several commercial CAs that do not
remove the expired certificates from their CRLs. Peter on the other hand
was under the impression that it was a mandate to remove CRLs; he too
remembered reading text in 2459 to support is position.

So we each pulled out the RFC and found that we
were both right! Specifically both sections 3.3 and 8.6.2.2 have text on
this subject:

3.3  Revocation

When a certificate is issued, it is expected to
be in use for its entire validity period.  However, various
circumstances may cause a certificate to become invalid prior to the
expiration of the validity period.

....

An entry is added to the CRL as part of the
next update following notification of revocation. An entry may be
removed from the CRL after appearing on one regularly scheduled CRL
issued beyond the revoked certificate's validity period.

8.6.2.2 Issuing distribution point
extension

This CRL extension field identifies the CRL
distribution point for this particular CRL, and indicates if the CRL is
limited to revocations for end-entity certificates only, for authority
certificates only, or for a limited set of reasons only. The CRL is
signed by the CRL issuer's key- CRL distribution points do not have their
own key pairs. However, for a CRL distributed via the Directory, the CRL
is stored in the entry of the CRL distribution point, which may not be
the directory entry of the CRL issuer. If this field is absent, the
CRL shall contain entries for all revoked unexpired certificates issued
by the CRL issuer.

....

The
distributionPoint
component contains the name of the
distribution point in one or more name forms. If this field is absent,
the CRL shall contain entries for all revoked certificates issued by the
CRL issuer. After a certificate appears on a CRL, it is deleted
from a subsequent CRL after the certificate's expiry.

Although section 8.6.2.2 is specifically in
regards to CRLdps, any difference between full CRLs and CRLdps in this
case I feel would be an arbitrary one.

Now logically it makes sense to remove
certificates that are expired from CRLs to control size, yes this has a
negative point specifically it prevents CRLs from being used as a
non-repudiation source; but this is mute due to many other issues.

That being the case I think; and I believe
Peter would agree the correct thing to do is to remove these
expired/revoked entries from the CRL.

The question now is what is the PKIX stance on
this matter?

Ryan M. Hurst

ValiCert, Inc.

"It may roundly be asserted that human ingenuity cannot concoct
a cipher which human ingenuity cannot
resolve."

-Edgar Allan Poe

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 05 Sep 2001 14:12:11 +0200

Nada and Ryan,

> deleting info about expired certificates from a CRL is only an option.
> 

At the very beginning, when ISO started the work, non-repudiation was not
considered, but only authentication and data origin authentication.

> has a MAY (or a MUST) consistently in all places where deleting expired
> certificates revocation info from CRLs is mentioned. The current text only
> brings confusion, as you have already pointed out.

In all the sentences that have been extracted below, I could not find a
place where a change would be necessary. So I believe that the current text
is OK : it tells how long revoked certificates MUST be kept in a CRL but
does not forbid to maintain them longer. I agree that maintaining them too
long would be a problem because of the increasing size of the CRL, hence why
CRL information should be captured when still available, in case a
non-repudiation service is supported.

We could add is a recommendation like: "Certificates identifiers
for certificates that contain the NR bit in the KeyUsage extension field
SHOULD be maintained in a CRL a few days or weeks after they have expired." 

However, it seems rather late to add such a sentence, since we passed IETF
last call. I leave the issue to the editors ...

Denis

> > I was speaking with Peter Williams today about the removal of expired
> > So we each pulled out the RFC and found that we were both right!
> > Specifically both sections 3.3 and 8.6.2.2 have text on this subject:
> >
> >
> >
> > 3.3  Revocation
> >
> > When a certificate is issued, it is expected to be in use for its entire
> > validity period.  However, various circumstances may cause a certificate
> > to become invalid prior to the expiration of the validity period.
> >
> >
> >
> > ....
> >
> >
> >
> > An entry is added to the CRL as part of the next update following
> > notification of revocation. An entry may be removed from the CRL after
> > appearing on one regularly scheduled CRL issued beyond the revoked
> > certificate's validity period.
> >
> >
> >
> >
> >
> >
> >
> > 8.6.2.2 Issuing distribution point extension
> >
> > This CRL extension field identifies the CRL distribution point for this
> > particular CRL, and indicates if the CRL is limited to revocations for
> > end-entity certificates only, for authority certificates only, or for a
> > limited set of reasons only. The CRL is signed by the CRL issuer's key-
> > CRL distribution points do not have their own key pairs. However, for a
> > CRL distributed via the Directory, the CRL is stored in the entry of the
> > CRL distribution point, which may not be the directory entry of the CRL
> > issuer. If this field is absent, the CRL shall contain entries for all
> > revoked unexpired certificates issued by the CRL issuer.
> >
> >
> >
> > ....
> >
> >
> >
> > The distributionPoint component contains the name of the distribution
> > point in one or more name forms. If this field is absent, the CRL shall
> > contain entries for all revoked certificates issued by the CRL issuer.
> > After a certificate appears on a CRL, it is deleted from a subsequent
> > CRL after the certificate's expiry.
> >
> >
> >
> >
> >
> > Although section 8.6.2.2 is specifically in regards to CRLdps, any
> > difference between full CRLs and CRLdps in this case I feel would be an
> > arbitrary one.
> >
> >
> >
> > Now logically it makes sense to remove certificates that are expired
> > from CRLs to control size, yes this has a negative point specifically it
> > prevents CRLs from being used as a non-repudiation source; but this is
> > mute due to many other issues.
> >
> >
> >
> > That being the case I think; and I believe Peter would agree the correct
> > thing to do is to remove these expired/revoked entries from the CRL.
> >
> >
> >
> > The question now is what is the PKIX stance on this matter?
> >
> >
> >
> > Ryan M. Hurst
> >
> > ValiCert, Inc.
> >
> >
> >
> >      "It may roundly be asserted that human ingenuity cannot concoct a
> >      cipher which human ingenuity cannot resolve."
> >      -Edgar Allan Poe
> >
> >

---

From: Nada Kapidzic Cicovic <[email-masked]>
Date: Wed, 05 Sep 2001 14:52:40 +0200

>does not forbid to maintain them longer. I agree that maintaining them too

The text in 8.6.2.2 does not mention the possibility of leaving the expired 
certificates identifiers in CRL. The last extracted sentence is very 
explicit in requiring removal of revocation info for expired certificates.

>non-repudiation service is supported.

I could not agree more. Perhaps DPV/DPD work could include such guidelines.

>last call. I leave the issue to the editors ...

You are right. Since the document has already progressed this far, it may 
not be worth making additional modifications.

Nada

---

From: li yunfeng <[email-masked]>
Date: Wed, 5 Sep 2001 21:12:19 +0800 (CST)

Ryan:
I now  are developing PKIX software, and encouted the
same question as yours, Because befor one can check
the CRL, one may first check  the certificate's
validate period. So I think remove the expired
certificate from the CRL will be benefit to keep the
CRL small. 

forward li

--- Nada Kapidzic Cicovic <[email-masked]>
的正文：
<HR>

<html>
Ryan,<br><br>
Some years ago we at Entegrity also had similar
discussion. We were
positive CRLs were not to contain the information
about the expired
certificates, until we came across some industry CA
CRLs containing
information about all revoked certificates. We then
looked into 2459
(draft in those days) and X.509 text and came to the
conclusion that
deleting info about expired certificates from a CRL is
only an
option.<br><br>
I am not sure what was the intention of the original
authors of X.509
(perhaps Sharon and Hoyt know more about it), but the
current industry
practice seems to be a mixture of both
approaches.<br><br>
My personal opinion is that keeping all revoked
certificates info in CRLs
brings more problems than benefits. However, it is
questionable whether
PKIX needs to take a vote for one approach or the
other. <br><br>
In any case I would suggest that the text of 2459 be
modified so that it
has a MAY (or a MUST) c<font face="Arial,
Helvetica">onsistently</font>
in all places where deleting expired certificates
revocation info from
CRLs is mentioned. The current text only brings
confusion, as you have
already pointed out.<br><br>
Nada<br><br>
At 08:49 PM 9/4/01 -0700, Ryan Hurst wrote:<br><br>
<blockquote type=cite class=cite cite><font
face="arial" size=2>I was
speaking with Peter Williams today about the removal
of expired
certificates from CRLs; I have always been under the
belief that this
behavior was optional, I vaguely remembered reading
text in 2459 along
those lines; additionally I know of several commercial
CAs that do not
remove the expired certificates from their CRLs. Peter
on the other hand
was under the impression that it was a mandate to
remove CRLs; he too
remembered reading text in 2459 to support is
position.<br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>So we each pulled out the
RFC and found that we
were both right! Specifically both sections 3.3 and
8.6.2.2 have text on
this subject:<br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2><b>3.3&nbsp; Revocation<br>
</b></font><br>
<font face="arial" size=2>When a certificate is
issued, it is expected to
be in use for its entire validity period.&nbsp;
However, various
circumstances may cause a certificate to become
invalid prior to the
expiration of the validity period.<br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>....<br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>An entry is added to the CRL
as part of the
next update following notification of revocation.
<b><i>An entry may be
removed from the CRL after appearing on one regularly
scheduled CRL
issued beyond the revoked certificate's validity
period.<br>
</i></b></font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2><b>8.6.2.2 Issuing
distribution point
extension<br>
</b></font><br>
<font face="arial" size=2>This CRL extension field
identifies the CRL
distribution point for this particular CRL, and
indicates if the CRL is
limited to revocations for end-entity certificates
only, for authority
certificates only, or for a limited set of reasons
only. The CRL is
signed by the CRL issuer's key- CRL distribution
points do not have their
own key pairs. However, for a CRL distributed via the
Directory, the CRL
is stored in the entry of the CRL distribution point,
which may not be
the directory entry of the CRL issuer.<i> <b>If this
field is absent, the
CRL shall contain entries for all revoked unexpired
certificates issued
by the CRL issuer.<br>
</i></b></font><br>
<font face="arial" size=2><i>&nbsp;<br>
</i></font><br>
<font face="arial" size=2>....<br>
</font><br>
<font face="arial" size=2 color="#0000FF">&nbsp;<br>
</font><br>
<font face="arial" size=2>The
</font><font face="arial" size=1><b>distributionPoint
</b></font><font face="arial" size=2>component
contains the name of the
distribution point in one or more name forms. If this
field is absent,
the CRL shall contain entries for all revoked
certificates issued by the
CRL issuer. <b><i>After a certificate appears on a
CRL, it is deleted
from a subsequent CRL after the certificate's
expiry.<br>
</i></b></font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>Although section 8.6.2.2 is
specifically in
regards to CRLdps, any difference between full CRLs
and CRLdps in this
case I feel would be an arbitrary one. <br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>Now logically it makes sense
to remove
certificates that are expired from CRLs to control
size, yes this has a
negative point specifically it prevents CRLs from
being used as a
non-repudiation source; but this is mute due to many
other issues.<br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>That being the case I think;
and I believe
Peter would agree the correct thing to do is to remove
these
expired/revoked entries from the CRL. <br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>The question now is what is
the PKIX stance on
this matter?<br>
</font><br>
<font face="arial" size=2>&nbsp;<br>
</font><br>
<font face="arial" size=2>Ryan M. Hurst<br>
</font><br>
<font face="arial" size=2>ValiCert, Inc.<br>
</font><br>
<font face="arial" size=2>&nbsp;</font>
<dl><font face="Times New Roman, Times">
<dd>&quot;It may roundly be asserted that human
ingenuity cannot concoct
a cipher which human ingenuity cannot
resolve.&quot;</i></font><font face="Times New Roman,
Times">
<dd>-Edgar Allan Poe</font>
</dl><font face="Times New Roman,
Times">&nbsp;</font></blockquote></html>

_________________________________________________________
Do You Yahoo!? 登录免费雅虎电邮! http://mail.yahoo.com.cn

<font color=#6666FF>无聊？郁闷？高兴？没理由？都来聊天吧！</font>―― 
雅虎全新聊天室! http://cn.chat.yahoo.com/c/roomlist.html

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 05 Sep 2001 15:22:10 +0200

Nada,

Which text are using using ? In son-of-RC2459 there is no section 8.6.2.2.
as you indicate.

Please be more specific on the exact sentence that you think is not
appropriate in son-of-RC2459 and which exact change you would like to be
done.

Denis

---

From: Nada Kapidzic Cicovic <[email-masked]>
Date: Wed, 05 Sep 2001 15:53:30 +0200

At 03:22 PM 9/5/01 +0200, Denis Pinkas wrote:

Nada,

Which text are using using ? In son-of-RC2459 there is no section
8.6.2.2.

as you indicate.

Denis,

I was making comments on the text which Ryan extracted in his mail,
assuming that they were from the son-of-RFC2459.

In particular the last sentence in this paragraph:

The distributionPoint component contains the
name of the distribution point in one or more name forms. If this field
is absent, the CRL shall contain entries for all revoked certificates
issued by the CRL issuer. After a certificate appears on a CRL, it
is deleted from a subsequent CRL after the certificate's
expiry.

However, after getting your comment I realized that this sentence
and the referred section 8.6.2.2 comes from the X.509 (the latest version
that I have on my disk is X_509_4thEditionDraftV6, and it contains the
above text).

The current text of the son-of-RFC2459 does not seem to contain it or any
other misleading sentences regarding this issue.

Sorry for the confusion.

Nada

Please be more specific on the
exact sentence that you think is not

appropriate in son-of-RC2459 and which exact change you would like to
be

done.

Denis

discussion. We were

conclusion that

> > > deleting info about expired certificates from a CRL is
only an option.

authors of X.509

current industry

questionable whether

> > > PKIX needs to take a vote for one approach or the
other.

modified so that it

belief that this

text in 2459 along

remove CRLs; he too

> > > > remembered reading text in 2459 to support is
position.

> > > > This CRL extension field identifies the CRL
distribution point for this

> > > >      "It may roundly be
asserted that human ingenuity cannot concoct a

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 05 Sep 2001 10:38:41 -0400

At 03:53 PM 9/5/01 +0200, Nada Kapidzic Cicovic wrote:
>Denis,
>
>I was making comments on the text which Ryan extracted in his mail, assuming that they were from the son-of-RFC2459.
>
>The distributionPoint component contains the name of the distribution point in one or more name forms. If this field is absent, the CRL shall contain entries for all revoked certificates issued by the CRL issuer. After a certificate appears on a CRL, it is deleted from a subsequent CRL after the certificate's expiry.
>
>However, after getting your comment I realized that this sentence and the referred section 8.6.2.2 comes from the X.509 (the latest version that I have on my disk is X_509_4thEditionDraftV6, and it contains the above text). 

I have X_509_4thEditionDraftV8 on my computer and it appears that this has been fixed. I now says "After a certificate appears on a CRL, it may be deleted from a subsequent CRL after the certificate’s expiry."  I didn't bother to look at son-of-2459.

In any case, both X.509 and son-of-2459 should say that a certificate may be deleted from a CRL after it has expired.  In general, though, I don't think there is much benefit to leaving expired certificates on CRLs.  The problem is that, at the moment, if an expired certificate is not listed on a CRL, there is no way to determine whether it is not listed because it was never revoked or if it was revoked but is not listed because it was removed after expiration.

Some time ago, there was a suggestion to create a new, non-critical CRL extension that would specify whether an expired certificate was covered by a CRL (e.g., the extension could state: "This CRL includes all revoked certificates that expire(d) after Jan. 1, 2001 (i.e., notAfter >= 010101000000Z)."). There didn't seem to be much support for this idea, so the extension was never created.

>The current text of the son-of-RFC2459 does not seem to contain it or any other misleading sentences regarding this issue. 
>
>Sorry for the confusion.
>
>Nada