This may be falling into the crack between S/MIME and PKIX.
I do not think this needs a change in any of the documents, although
something in the security section MIGHT be appropriate (as below).
I have seen it proposed that the signing time be used when validating
signatures, and at least one S/MIME implementation may do this.
I THINK this violates the intent of CERT section 4.1 and rfc3280
(KEYM) sections 3.3 and 6.3.3.
That is, "current time" in these rfc's should not be interpreted to
be equivalent to the "signing time" from the message.
Sean Turner's recent comment #6, 2 March 2004 on CERT is also relevant.
This was discussed back in 1998 and I think responsibility allocated
to KEYM (PKIX). The unique S/MIME WG issue is the improper (IMHO) use
of the signing time in the message to judge certificate expiry or CRL
validity (of course KEYM does not mention signing time).
Denis Pinkas wrote (28 Sept 1998, in part):
"...The signingTime attribute only reflects the time the signer wanted to be
The signer may well pre-date that value, ... but more important, if the key of
signer is compromised then an attacker may also pre-date that value. In such a
situation it cannot be made a difference between a past "honest" signature from
right signer and a pre-dated "fake" signature from an attacker...."
An attack is for a forger to set their local clock back to a time prior
to the revocation, forge the message and enclose a then-current (old)
CRL in the message. If the signing time is used to select the CRL the
forger could succeed (the forger might mount a DOS attack to prevent the
receiver getting a more recent CRL). Alternatively, the forger waits for
certificate expiry and then compromises the key, back-dates their forged
- and again the attack is successful even if the rightful owner knows about
it (since revocation support is not guaranteed past expiry).
I think the following are correct:
1. The certificate is checked for expiry, and if unexpired, the
current and not "too old" CRL is used (or OCSP server, etc. accessed).
Specifically the check for expiry AND "too old" must be based on
the receiver's sense of time, NOT the signing time.
(Ideally it would be based on a trusted time source but this is
normally not available, so this should not be mandatory.
If there is a trusted time stamp other options are available).
2. If the certificate is expired, no CRL (or OCSP) check is
done since the CA does not guarantee revocation processing.
CRL checking should not be done even if a cached "old" CRL
is available (e.g. as provided within the message).
This has consequences when attempting to (re-)verify old
messages stored in inBoxes for example.
They may verify when received, but fail when re-verified later.
This is bad for users, and implementers may be tempted to provide
a "better" solution by using the signing time (bad).
If a signature on an incoming message is important,
users must consider using (prior to cert expiry)
a trusted time stamp server or trusted archive so a
"trusted time" can be added. Enterprise users might consider
automating this; e.g. ensuring that old e-mails (and CRLs!!)
are archived in a trusted and timely manner.
Should a sentence be added cautioning users against using the untrusted
signing time from the message for certificate expiry and CRL validity
For example something like:
"The signing time in the message cannot be trusted if the signing key
has been compromised. Thus the signing time should not be used as
the "current time" when performing certificate expiry or revocation
checking as per KEYM."
PS: A quote from Peter Sylvester (30 July 2003) in the PKIX WG discussion:
"Isn't creating a digital signature which is not
almost immediately presented to some relying or attesting party
a profound misunderstanding of cryptographic techniques? "
Unfortunately we must live with e-mail application reality!
PPS: There is a long discussion, (starting in about 30 July 2003)
in the PKIX WG on related issues including potential archiving of CRL's.
I think for current purposes we just need to emphasize that "signing time"
is untrusted and must not be used for expiry or CRL validity testing. Going
beyond that might get too complicated and best left with PKIX.