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.
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@xxxxxxxxxx> 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
