What does 'openssl ts -verify' verify exactly?

[Matthias Buehlmann]

On Tue, Feb 16, 2021 at 8:56 PM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> > On Feb 16, 2021, at 1:34 PM, Hubert Kario <hkario at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210216/4045b391/attachment.html>