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

[Jean-Marc Desperrier <jean-marc.desperrier@xxxxxxxxxxxx>]

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.

Bernd Matthes <mainbug@xxxxxxxxxx> wrote:
> 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.

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 ?