Subject: LAST CALL:draft-ietf-pkix-time-stamp-05.txt

From: Warwick Ford <[email-masked]>
Date: Tue, 25 Jan 2000 09:59:37 -0800

This document is hereby issued for 14-day WG Last Call.  Please submit any
comments to this list.

Warwick

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, January 07, 2000 3:39 AM
To: IETF-Announce; @imc.org
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-time-stamp-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working
Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Time
Stamp 
                          Protocols (TSP)
	Author(s)	: C. Adams,  P. Cain, D. Pinkas,  R. Zuccherato
	Filename	: draft-ietf-pkix-time-stamp-05.txt
	Pages		: 20
	Date		: 06-Jan-00
	
A time stamping service allows to prove that a datum existed before
a particular time and can be used as a Trusted Third Party (TTP) as
one component in building reliable non-repudiation services (see
[ISONR]). This document describes the format of a request sent to a
Time Stamping Authority (TSA) and of the response that is returned.
An example on how to prove that a digital signature was generated
during the validity period of the corresponding public key
certificate is given in an annex.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-05.txt

---

From: "Linn, John" <[email-masked]>
Date: Mon, 31 Jan 2000 16:05:18 -0500

I've a few comments on this specification.

If different entities obtain timestamps on the same data object using the
same hash algorithm, or a single entity obtains multiple timestamps on the
same object, the generated timestamp tokens will include identical message
imprints; as a result, an observer could determine that the timestamps refer
to the same underlying data.  It might be worth a note in Security
Considerations stating that, in contexts where this potential exposure is a
concern, some unique value could be generated by the requester and combined
with a data object before hashing the combination in order to produce
MessageImprint's hashedMessage. 

The second paragraph of Sec. 2.2 bears a number of SHALLs for verification
steps which are to be performed by the requesting entity once the
TimeStampToken is received.  What's the recommended or required action if
any of these verifications fail? 

In the Accuracy structure, is no more than one of the seconds, millis, or
micros OPTIONALs to occur, or may more than one of these elements occur in
combination? 

In References, [ESS] is now RFC-2634.

Editorially, there's an odd character which seems to recur instead of the
apostrophe in the phrase "TSA's", and in other places where an apostrophe or
closing single quote is intended; on my display, it appears as a ligature
"AE".

Other, minor editorial points:

p. 8, 1st line, "may to be used" -> "may be used".

Later on p. 8, "subtracting the accuracy to" -> "subtracting the accuracy
from". 

Appendix A, 4th line, "allows to know" -> "allows a verifier to know".

--jl