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

From: Ryan Hurst <[email-masked]>
Date: Wed, 05 Sep 2001 22:15:47 -0700

David -
 
            Although my confusion on this issue has been cleared up (note to
self; always verify your sources) now; this brings up a very interesting
point. I and others I have spoken with believe that the addition of such an
extension (one that states that the CRL contains ALL revocation entries both
current and expired) would be very valuable. 
 
Consider this problem, today I receive a digitally signed and time stamped
document (a contract possibly), this document was signed by a certificate
issued off of any number of commercial CA's that exist today. 10 years later
the document is in question and I need to establish that the certificate
associated with the signature on the document was valid at the time it was
signed; there are several significant possibilities here:
 
1.	CA in question has CRLNumber extension in all of their CRLs and they
are all available
2.	CA in question does not have the CRLNumber in all CRLS or just a
subset
 
Now in #1 the problem is relatively easy, I find all CRLs that were valid
during my window and of those I pick the one that has the highest CRLnumber.
An extension like this would be "use-full" in this case but not necessary.
 
In #2 the problem gets, well unsolvable; Since there are no ways to
determine if I have all of the CRLs that are within my window (remember
validity windows on CRLs can overlap so the ones within the overlapped
window that state the certificate is revoked could be "lost") I will never
now if the certificate was valid at the time in question. Now if the CRLs
that were generated contained all entries and were marked as such with an
extension I would have a mechanism to solve this problem; simply get the
most recent CRL.
 
Ryan

-----Original Message-----
From: David A. Cooper [mailto:[email-masked]] 
Sent: Wednesday, September 05, 2001 7:39 AM
To: IETF-PKIX
Subject: Re: Removing expired certificates from CRLs.....
 
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.

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

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

---

From: jim <[email-masked]>
Date: Thu, 06 Sep 2001 18:28:19 -0400

Ryan,
    The quick and dirty answer is to use the Conclusive Logic middleware
solution, TrustLogic, for its Persistent Proof capability and do not worry about
notarization after the fact because you will already have captured all of the
legal requirements for notarization during the time when the session in which
the data transfer occurred.  The user will have been authenticated at the
beginning of the session and the data will be stored as encrypted XML in the
audit log, which is hashed and signed by the TrustLogic server.
    Call Nancy and talk with her and Jean about it.
Jim Heimberg, ABC, Ph.D.
Manager, Customer Relations
Conclusive Logic, Inc.
additional e-mail address:  [email-masked]

Ryan Hurst wrote:

> David -
>
> Although my confusion on this issue has been cleared up (note to self; always
> verify your sources) now; this brings up a very interesting point. I and
> others I have spoken with believe that the addition of such an extension (one
> that states that the CRL contains ALL revocation entries both current and
> expired) would be very valuable.
>
>   1. CA in question has CRLNumber extension in all of their CRLs and they are
>      all available
>   2. CA in question does not have the CRLNumber in all CRLS or just a subset
>
> In #2 the problem gets, well unsolvable; Since there are no ways to determine
> if I have all of the CRLs that are within my window (remember validity windows
> on CRLs can overlap so the ones within the overlapped window that state the
> certificate is revoked could be "lost") I will never now if the certificate
> was valid at the time in question. Now if the CRLs that were generated
> contained all entries and were marked as such with an extension I would have a
> mechanism to solve this problem; simply get the most recent CRL.
>
> Ryan
>
> Sent:Wednesday, September 05, 20017:39 AM
> To: IETF-PKIX
> At 03:53 PM9/5/01 +0200, Nada Kapidzic Cicovic wrote:
>
> Denis,
>
> 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.
>
> 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).
>
>
> 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.
>
> 010101000000Z)."). There didn't seem to be much support for this idea, so the
> extension was never created.
>
>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 6 Sep 2001 19:51:08 -0400

Jim,

PKIX, like most other IETF WGs, frowns on product advertisements 
inserted into our standards discussions. The product you mention also 
sounds like it is not connected to the PKI standards work we do here, 
hence even less appropriate for this discussion.

Thanks,

Steve