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
