Subject: Query about nonce field in Time-stamp response.

From: "Prashant Dambe" <[email-masked]>
Date: Thu, 25 Jan 2001 10:37:33 +0530

Time-Stamp Protocol Response contains Nonce field as a part of signed TimeStamp 
token. It will be stored as a part of timestamp token. But the nonce will be checked 
at the time of receiption of Time-Stamp token against the client generated nonce.
What will be the use of Nonce field stored in the Time-stamp token when in the future
the that token will be used.
Should nonce be a part of TSTInfo in time-stamp token and stored as part of Time-stamp token ?

Prashant

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 25 Jan 2001 10:14:11 +0100

Prashant Dambe wrote:

> Time-Stamp Protocol Response contains Nonce field as a part of signed
> TimeStamptoken. It will be stored as a part of timestamp token. But
> the nonce will be checkedat the time of receiption of Time-Stamp token
> against the client generated nonce.What will be the use of Nonce field
> stored in the Time-stamp token when in the futurethe that token will
> be used.Should nonce be a part of TSTInfo in time-stamp token and
> stored as part of Time-stamp token ?

Replay detection is one thing, but there can be other uses of the nonce
field.

If you think of it, the nonce is an arbitrary choosen user identifier
for the token ...
So it's not so inconvenient if it's included in the payload of the
TimeStamptoken.

---

From: Bernd Matthes <[email-masked]>
Date: Thu, 25 Jan 2001 10:31:43 +0100

> So it's not so inconvenient if it's included in the payload of the

Hi,

I think it's a little auxiliary means against double timestamps.
A TSA should reject a time stamp query if the same
messageImprint *and* the same nonce found in it's database. 
It's possible to get multiple timestamps ("re-new") for the 
same document,message or whatever, 
but *never* with already issued nonce value.

with kind regards
-- 
Mors certa, hora incerta. In dubio pro mille.
--------------------------------------------------------------------
Bernd Matthes                   Celo Communications GmbH
Senior Software Engineer    	Weissenfelser Strasse 46a
Nachrichtentechniker            D 06217 Merseburg
Dipl.-Ing.(FH)                  http://www.celocom.com
  f. technische Informatik      mailto:[email-masked]
http://www.worldbug.de          Tel.: +49 3461/3318-0
mailto:[email-masked]      Fax:  +49 3461/415072
--------------------------------------------------------------------
Have You kicked Your cat today?

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 25 Jan 2001 12:14:14 +0100

Prashant Dambe wrote:

> Is it  required that Nonce should be included in  TSTInfo i.e the part of
> TimeStampToken ?

Draft version 13 says :
TSTInfo ::= SEQUENCE  {
  ....
     nonce                        INTEGER                  OPTIONAL,
       -- MUST be present if the similar field was present
       -- in TimeStampReq. In that case it MUST have the same value.

So it's required, yes.

> Nonce can be a part of Time-stamp response like PKIStatusInfo which will be
> not included in Timestamptoken.

No such possibility is provided in the current form of the TimeStampResp.
Anyway, the nonce would have to be signed by the responder, so what you suggest
requires a second signature, so that the nonce can be removed without breaking
the TSTInfo signature.

If you don't want the nonce payload, the draft suggests to use both a local
clock and a moving time window during which the requester remembers all the
hashes sent during that time window.

> but *never* with already issued nonce value.

My understanding until now is that's it's only up to the client to check the
nonce, and not to the server.

So howewer interesting your idea is, the standard does not forbid a client to
do what you describe, for whatever reason, and the systematic rejection could
cause interoperability problems.

If you did it, your clients would have to check their tools will never do that,
especially when resending the same request because the answer wasn't received.

Here's what Denis said recently which is quite related to this question :

>> And additional badSenderNonce(18)?
>This has not been added. I do not want to raise at this time questions like:
>what is a bad nonce ? or how does a server know it is a bad nonce ?