Re: What does 'openssl ts -verify' verify exactly?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux