On Tue, Feb 16, 2021 at 8:56 PM Viktor Dukhovni <openssl-users@xxxxxxxxxxxx> wrote:
> On Feb 16, 2021, at 1:34 PM, Hubert Kario <hkario@xxxxxxxxxx> 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.