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

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

Denis wrote, excerpting:

> Let us address the three technical points raised by John first:
> 
> JL1: "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."
> 
> An observer could indeed determine that the timestamps refer to the
> same underlying data. However, this is not a big concern since the
> observer will neither know the actual content nor the intended
> usage. The way that is proposed to address this issue might lead to
> the definition of another standardized binding technique so that the
> receiver of the TSP can know how to verify the linkage. I am not in
> favor of defining such a new linkage structure under the reason that
> I do not find the problem sufficiently important to be corrected. I
> would rather prefer to address the concern in a different way: if
> the requester really cares about this problem, he should rather use
> a protected channel with data confidentiality to access the TSA. If
> you wish to provide some text along these lines, I would be willing
> to consider it for inclusion in the security consideration section.
> 

I don't think that a confidentiality-protected channel to the TSA solves the
issue I was envisioning.  I expect that some uses of timestamps will require
that their recipients present or post them (selectively or generally) for
examination after they're obtained, and that such timestamps could
potentially be correlated by third parties.  I might be interested, e.g., to
observe a timestamp obtained by someone else with a hash which matches that
of a confidential document of mine. I'm not committed to proposing a
particular mechanism; I suggest, however, slightly adapting text above into
an advisory note for Security Considerations: "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 with access to those timestamp tokens could infer that the
timestamps may refer to the same underlying data."

--jl