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

From: "Prashant Dambe" <[email-masked]>
Date: Thu, 1 Feb 2001 16:02:26 +0530

Is it required to have responder's signature over the Nonce as nonce will
never be used in the future time.
If it is so then nonce can be included like PKIStatusInfo which will be not
included in Timestamptoken.
If nonce has to be signed then why PKIStatusInfo is not included in
Signed-Data.

----- Original Message -----
From: Jean-Marc Desperrier <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 25, 2001 4:44 PM
Subject: Re: Query about nonce field in Time-stamp response.

> 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 <[email-masked]> 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 ?

---

From: "Prashant Dambe" <[email-masked]>
Date: Thu, 1 Feb 2001 16:02:26 +0530

----- Original Message -----
From: Jean-Marc Desperrier <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 25, 2001 4:44 PM
Subject: Re: Query about nonce field in Time-stamp response.

of
be
suggest
breaking
local
the
the
to
could
that,
received.

---

From: Bernd Matthes <[email-masked]>
Date: Thu, 01 Feb 2001 21:27:49 +0100

> If nonce has to be signed then why PKIStatusInfo is not included in
Hi,

How do you inform a client about a refused time stamp token if the 
PKIStatusInfo is inside the refused token?
There bites the cat itself in the tail.
If the PKIStatusInfo is outside of the time stamp token it can be always
sent
to the client.

If the nonce not belongs to the messageImprint in a signature
it's never provable surely that an time stamp token belongs to an 
time stamp query. The nonce is a part of evidence and must be therefore
signed.
The TSA had to prove that a nonce belongs to a messageImprint
has received. On which way should it be done? Just only with a *signed*
nonce.

An unsigned nonce can be exchanged from a "man in the middle" to provoke
that the client reject the received time stamp token.

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?