What does 'openssl ts -verify' verify exactly?

[Hubert Kario]

On Tuesday, 16 February 2021 15:54:24 CET, Matthias Buehlmann wrote:
> Hello Hubert (sorry, replied to your e-mail address directly before instead
> of the mailing list),
>
> thank you for your reply, but I don't think you're correct that timestamp
> tokens expire together with the signing certificate! Timestamp tokens CAN
> stay valid beyond the validity of the signing certificate, otherwise PAdES
> LTV (Long Term Validity) wouldn't make much sense. Check RFC3161
> specification chapter 4.1:
>
>       When a TSA shall not be used anymore, but the TSA private key has
>       not been compromised, the authority's certificate SHALL be
>       revoked.  When the reasonCode extension relative to the revoked
>       certificate from the TSA is present in the CRL entry extensions,
>       it SHALL be set either to unspecified (0), affiliationChanged (3),
>       superseded (4) or cessationOfOperation (5).  In that case, at any
>       future time, the tokens signed with the corresponding key will be
>       considered as invalid, but tokens generated before the revocation
>       time will remain valid.  When the reasonCode extension relative to
>       the revoked certificate from the TSA is not present in the CRL
>       entry extensions, then all the tokens that have been signed with
>       the corresponding key SHALL be considered as invalid.  For that
>       reason, it is recommended to use the reasonCode extension.

not necessarily, it does not talk about the notAfter date at all, only 
about
"not used anymore", that may (and actually should) happen at least a year 
before
notAfter date

but the details I remember may be from Qualified Signature requirements, 
not
the IETF standards

I do know that the BSI has a different policy still, so you need to know 
under
which policy you need to perform the verification

> Chapter 4.3 DOES talk about key lifetime and renewing trust in issued
> tokens by restamping, however the term "lifetime" used here is in relation
> to key-length (longer key-length = longer lifetime, finite key-length =
> finite lifetime), NOT validity period of TSA certificate:
>
>       The TSA signing key MUST be of a sufficient length to allow for a
>       sufficiently long lifetime.  Even if this is done, the key will
>       have a finite lifetime.  Thus, any token signed by the TSA SHOULD
>       be time-stamped again (if authentic copies of old CRLs are
>       available) or notarized (if they aren't) at a later date to renew
>       the trust that exists in the TSA's signature. time-stamp tokens
>       could also be kept with an Evidence Recording Authority to
>       maintain this trust.
>
> It doesn't make sense that a token could retain its validity beyond the
> validity of the TSA certificate in a revocation scenario (when key or CA
> hasn't been compromised) but not in an expiration scenario.
> All TSA certificates I encountered so far have very short lifetimes (1-3
> years). If it was true that tokens would only remain valid within that
> period without being restamped, the whole point of PAdES LTV would be moot.

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
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic