What does 'openssl ts -verify' verify exactly?

[Hubert Kario]

On Tuesday, 16 February 2021 03:35:32 CET, Matthias Buehlmann wrote:
> If openssl ts -verify is used, what exactly is verified?
>
> For example, while the [-crl_check] [-crl_check_all] and
> [-extended_crl] verify options are supported, there is no way to pass
> CRLs to the call. So, is anything checked for revocation?
>
> How are timestamps verified for which the signing certificate has
> expired or has been revoked?
>
> If I understand correctly, to verify the validity of a timestamp token
> at the current time, one must
> - Check that the singing certificate was valid at the time of
> timestamp (for this either current or historical CRLs for the entire
> trust chain must be checked)

that's not correct, the timestamp is only valid as long as the singing
certificate is valid

if you want to retain validity of a timestamp, you need to timestamp the
timestamp with a new TSA, and then keep on applying additional timestamps 
as
TSA certs lose validity

see XAdES-A, PAdES-A, or CAdES-A standards for practical implementaiton of 
this

> - If the certificate is not valid anymore at the current time, one
> must show that none of the certificates in the trust chain have been
> revoked, or that those that have been revoked have the reasonCode
> extension and that this reasonCode extension shows one of the
> following revocation reasons: unspecified (0), affiliationChanged (3),
> superseded (4) or cessationOfOperation (5), in which case the
> timestamp token is still valid (section 4 off
> https://www.ietf.org/rfc/rfc3161.txt)

if the certificate is not valid any more and you have no newer timestamp
proving that the original timestamp was created before the certificate lost
validity, then the original timestamp is useless

now, to verify a certificate in the past you need to have a CRL or an OCSP
_from the time it was still valid._ CAs have no obligation to retain a
certificate in the CRL after it lost validity. But at the same time you
can't have a CRL or OCSP response from similar time as the timestamp, as
the CAs have a grace period to issue revocation information, so you need to
have a saved CRL or OCSP response likely from a day later to few weeks 
later.

I can only recommend reading one of the standards I mentioned above, it
goes into much more detail about all of it

> Can openssl ts -verify do that? If not, how is a timestamp token
> properly verified using OpenSSL?

no, ts -verify just does simple check at *now,* it has no support for 
CAdES-A,
if you need it, you need to implement it yourself
-- 
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