Subject: RE: Timestamp: nonce field

From: "Manger, James" <[email-masked]>
Date: Wed, 22 Sep 1999 15:22:31 +1000

The nonce field adds nothing.  It should be removed from the request &
timestamp token.  The messageImprint serves the desired purpose.

Replay attacks are not attacks for a timestamp.  A timestamp means "this
datum existed at this time", which implies it exists for all time beyond
this point as well (you could lose the datum but I don't think that is
relevant).  If you request a timestamp today but a timestamp for the same
message from last Monday is substituted... you know the datum existed before
last Monday, which is (always) better than knowing it existed before today.

Perhaps you want a new timestamp for the same message because you want it
signed with the TSA's new key, or you want a version 2 timestamp, or you
want a different policy, or you want an extension.  In all these cases, you
should not check for freshness but for your desired feature.

If all you want is a fresh timestamp as "signed time" it is still simple:
make up a random message (or a random hash) and get that timestamped.

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 22 Sep 1999 14:09:19 +0200

> timestamp token.  The messageImprint serves the desired purpose.

There has already be a thread on that topic and the conclusion was
to keep the nonce. 
 
> last Monday, which is (always) better than knowing it existed before today.

Not in all cases: in some cases it is important to get the time
stamp with the current time and not to get an older one. When the
client has no trusted local clock, the nonce is the only way to test
the freshness.

Denis
 
>   --------------------------------------------------------------------
> 
>    Part 1.2       Type: application/ms-tnef
>               Encoding: base64