Re: when can an entry not appear on a CRL?

[Juergen Walter <walter@xxxxxx>]

Paul Koning wrote:
> 
> It's not clear to me why it is useful to distinguish "short term" and
> "long term" signatures and then define different validation algorithms
> for them.  

The algorithms are the same. They differ in the choosen time variable T
in chapter 6 of [PKIX1]. [PKIX1] says that T is less or equal NOW. I
don`t know exactly the origin of the notation "short term" and "long
term". The origin might be the Digital Signature Law Interoperability
Guide (SIGI) published by German Bundesamt fuer Sicherheit in der
Informationstechnik. But, I am not sure. I apologize when I have made a
mistake. The motif for use of this notation was just the following. I
wanted a name for the limits of the interval, where T lives in. In
addition, I wanted to avoid certificate paths for simplification. As a
result, these two definitions appeared.   

>For example, what property distinbuishes the two flavors?

The validity of those signatures that corresponds to revoked and/or
expired certificates. 

> On a related issue, if you use "time of signature generation" how do
> you know what that is?  It can't just be the timestamp in the
> signature, since that would allow the thief of a key which was revoked
> at time T to generate a "valid" signature by constructing one with
> signing time T-epsilon.

This is right under the assumption that the thief can sign with signing
time T-epsilon. If the signer has included an appropriate
non-repudiation token (e. g. a token generated by a trusted time stamp
server), then this attack fails.

> 
> If I have independent evidence I trust that a signature is at least as
> old as T2 where T2 >= T, 

This refers to a time stamp outside the signed data. It makes sense
provided that T2 is close to T, say T2=T+ epsilon, where epsilon is
sufficiently small.

>my inclination would be to verify that the
> certificate wasn't revoked at T2, 
>and was valid during the interval
> T..T2.   Without independent evidence about the time of signing,
> I basically have T2==now, which gets me what you describe as the "short
> term" algorithm.
> 
Let T3 be the time, when the relying party validates the signature. We
have T3 > T2. As T3 tends to T2 the difference between these two dates
is getting smaller. Hence, the result of certification path validation
will be almost the same. Note, T3 may be indentically to the
_nextUpdate_ of the CA`s CRL. Is it now?

Of course, the relying party is free to get a time stamp over the signed
data. This procedure yields a upper limit of the date, when the
signature was generated. The signature validation itself may be later.
... 
-- 

Juergen