Subject: Invalidity Dates

From: [email-masked]
Date: Thu, 10 Dec 1998 15:47:00 -0500

The description of a CRL entry Invalidity Date in the PKIX
profile states:
" ...but the revocation date
   SHOULD NOT precede the date of issue of earlier CRLs."
The description of SHOULD NOT says:
"4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.
"

It seems to me that one could discover that one's key was
compromised since before the issue of the current CRL.
In which case, it seems that you'd like to be able to reflect
that information in the CRL entry (when the next one comes
out). This means that not only could applications have been
accepting the cert while it was invalid (the case always with
CRLs) but that it could have been doing so for longer than
the configured "acceptable risk" interval between CRLs.

Are there any other implications that need to be weighed
by either the developer planning on allowing this feature,
or the user/administrator who might set such a revocation
date?

I haven't seen any discussion on this on PKIX; I apoligize
if I'm rehashing old ground (to mix a metaphor).
     Mez

---

From: Dan Geer <[email-masked]>
Date: Thu, 10 Dec 1998 18:24:39 -0500

MEZ,

I cannot follow this mailing list in real time, but it seems to
me that all revocations are retroactive to a known good date.
If the attack were insidious or the key infrequently inspected,
the effective date of revocation could be arbitrarily many
CRL generations ago.  If CRLs are issued by other than the
CA, the date of revocation could precede the existence of
the revocation server.

And, of course, this is true for all time -- records do not
outdate.  I may, at any arbitrary time in the future, want to
inquire of a certificate/key status as of a date of my choosing.
The CRLs must be indexed by time, a signature must ensure there
are no omitted CRLs, and it is the diffs between CRLs that
constitutes their information content.  Further, if I seek
to prove my due diligence, I will want a signature binding
the moment in time I asked for this data with the global
signature on the state of the CRL database at that moment.
Even so, there will remain the semantic fine point of whether
the inter-CRL time scale constitutes a clock tick such that 
a revocation notice may be enqueued at the CRL issuer yet
the titularly correct answer in CRL-time-granularity is 
"not yet known to be invalid."

I hope this reply merely telescopes the implications of your
question and is not the pedantic rehash I fear it is.

Respectfully,

--dan

---

From: Stephen Kent <[email-masked]>
Date: Fri, 11 Dec 1998 10:25:16 -0500

Dan,

>CA, the date of revocation could precede the existence of

CRLs are almost always issued by the CA who issued the certificate,
although v2 CRLs do allow for indirect CRLs which allow for another CA to
perform the issuance.  A primary justification for this is if the issuing
CA looses its ability to issue a CRL, a "superior" CA can issue a CRL on
its behalf.  For exmaple, a corporate CA might issue a CRL on behalf of a
CA serving a division of the corporation, in the aftermath of a crypto
module failure that prevented the division CA from issuing a CRL.
Syntactically one can have any CA issue a CRL for any cert, but the
resulting trust issues become very complex very quickly.

>"not yet known to be invalid."

CRLs always represent revocation status relative to a previous time
interval.  So, one always needs the NEXT CRL issued after a transaction as
part of the evidence supporting non-repudiation.  Since we still generate
complete CRLs, as well as incremental CRLs, it's not clear that a "diff" is
needed. One needs to acquire a CRL that covers the time at which the
transcation took place, to show due diligence. And, as you note, one needs
to use a time stamp server to establish the time at which this evidence was
collected.

Steve