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

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

John, 

Your text addition is fine and I have no problem to add it to the
Security considerations section.

"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."

Denis
 
> 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
> 
>