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

["Linn, John" <jlinn@xxxxxxxxxxxxxxx>]

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