On Tue, Feb 16, 2021 at 8:56 PM Viktor Dukhovni <openssl-us...@dukhovni.org> wrote:
> > On Feb 16, 2021, at 1:34 PM, Hubert Kario <hka...@redhat.com> wrote: > > > > the whole problem is that if you trust the date in the timestamp as the > date the timestamp was created, attacker can compromise the TSA key years > after > > it was last used and then create timestamps that look like they have been > > created while the TSA key was still valid > > Timestamps can only be deemed authentic if they are part of a Merkle > chain that validates all past timestamps signed with a *currently* > still trusted key. The trusted key can change from time to time, > but the Merkle chain needs to be append-only. > > Once a given Merkle chain is abandoned, and no longer has an active > signer attesting to the validity of long-ago events, at some point > it becomes impossible to say anything meaningful about the integrity > of past signatures. While I do in fact use a Merkle Tree in my case as well as chained timestamps, I don't think the claim "Timestamps can only be deemed authentic if they are part of a Merkle chain that validates all past timestamps signed with a *currently* still trusted key" is correct, since the specification in no way talks about Merkle Trees and only indirectly of Merkle Chains (suggesting that existing timestamp tokens should be time-stamped again in the future, however, this is in respect to a finite-length encryption key having finite lifetime - but this can well mean 1000 years in the future). It's true though that if one has such a chain AND one can show that at the time a newer timestamp was added the existing keys were still trusted, the timestamps can be trusted.
