Subject: RE: Rationale for Nonce in Time Stamp Protocol

From: [email-masked]
Date: Wed, 31 May 2000 10:38:29 -0400

Salut Denis,

I agree with both the word change and the proposed pointer.

However, I still think that leaving the term "timeliness" in Section 2.2
could be misinterpreted to mean that a requesting entity MUST reject a
totally valid response because of possible delays in the intervening network
elements and/or a drifting of this requesting entity own local time
reference.

According to Section 2.2, what would a requesting entity be required to do
if he/she receives a time stamp token with the right hash value and nonce,
however the time included in the response is before or very much later than
his/her own local trusted time reference?

Regards,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[email-masked]      Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com     Fax. (613) 723-5078

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Wednesday, May 31, 2000 4:19 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Rationale for Nonce in Time Stamp Protocol

François,

I have inserted your text, with one change, in the security
considerations section of the "moving draft" I am locally
maintening.

Instead of: If the same hash value is *generated* more than once
within a time window, 

I have inserted: If the same hash value is *present* more than once
within a time window, 

About your proposal of changing the text in section 2.2., I believe
that the current text is fine. Deleting "timeliness" and replacing
is by "replay" is more restrictive. We could however add a pointer
to the security consideration section, like: "For more details,
about replay attack detection see the security considerations
section (item 6)". 

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 31 May 2000 16:51:36 +0200

François,

> his/her own local trusted time reference?

The current sentence is:

 ... by verifying *either* the time included in the response against
a local trusted time reference, if one is available, *and/or* the
value of the nonce (large random number with a high probability that
it is generated by the client only once) included in the response
against the value included in the request.

Instead of "and/or", we could say "or". Would this solve your
concern ?

Denis