Re: Invalidity Dates

[Stephen Kent <kent@xxxxxxx>]

Dan,

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

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.

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

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