What a receiver needs are the NEXT set of
CRLs issued, ones issued after the message was sent, to prove that the
relevent certificates were not revoked at the time the message was
sent.
There are still a couple of "holes" in the long-term non-repudiation
story. It is, indeed, most effective to archive the CRLs believed to be
current at the time of signing as well as the NEXT set of CRLs issued,
however, how do I know for sure whether the CRL I have was the NEXT
CRL issued ?
Consider the case where a private key gets compromised between
regularly scheduled CRLs. If the issuer chooses to issue an emergency
CRL which hotlists the certificate for the compromised key, there is
no easy way for me to know that this (and not the next regularly
scheduled CRL) is the NEXT CRL. All goes OK in the long term if the
next regularly scheduled CRL continues to hotlist the certificate in
question. What if, however, the certificate naturally expires before
the next regularly scheduled CRL ? The current CRL semantics suggest
that the issuer drop that certificate from the hotlist leaving only
the "emergency" CRL with any indication of the compromise.
Seeing a certificate listed on a CRL would certainly "raise the red
flag" for anyone verifying signatures that were purported to be signed
after the date of listing. Perhaps, to be prudent, one shouldn't
trust a signature made by the key corresponding to a hotlisted
certificate if the signature was created around or even before the
date of listing. Indeed, the RFC1422 suggests that the date of
listing be interpreted as the date/time that the issuing CA formally
acknowledges compromise, not the date/time of suspected compromise.
Consider the case, however, where a user changes affiliation causing
their certificate to get hotlisted. Should this event cast doubt upon
any signatures created by that user after, around, and before the date
of listing?
These are tough issues. I believe the ANSI X9F committee is working
towards closing some of these holes. Perhaps we should try to align
ourselves in the next specification of PEM.
This begs the question of how we know "when a message was sent," which
is an old issue. (I assume that by "sent" Steve really meant "signed".)
Instead, we need a digital WWV, which would broadcast
the current date and time once a second, and would include
a true random number along with each tick. Once a minute, once
an hour, or once a day, the entire collection random numbers
would be digitally signed, broadcast, and archived.
Your suggestions about trusted time-stamping are timely. I think that
this subject warrants much more discussion. I would like to get
feedback from the other participants in this list;
Is pem-dev the right place for this discussion ?
Are there current Internet time standards that are sufficient to form
the foundation for a trusted time-stamping service ?
Is there enough interest for a BOF ?
Cheers,
Steve Dusse
RSA