What does 'openssl ts -verify' verify exactly?

[Matthias Buehlmann]

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.

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.

Cheers and thank you for your help,
Matthias

On Tue, Feb 16, 2021 at 2:49 PM Hubert Kario <hkario at redhat.com> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210216/6708b26d/attachment.html>