What does 'openssl ts -verify' verify exactly?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

What does 'openssl ts -verify' verify exactly?

Matthias Bühlmann
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)
- 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)

Can openssl ts -verify do that? If not, how is a timestamp token
properly verified using OpenSSL?
Reply | Threaded
Open this post in threaded view
|

Re: 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

Reply | Threaded
Open this post in threaded view
|

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

Matthias Bühlmann
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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Hubert Kario
On Tuesday, 16 February 2021 15:54:24 CET, Matthias Buehlmann wrote:

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

not necessarily, it does not talk about the notAfter date at all, only
about
"not used anymore", that may (and actually should) happen at least a year
before
notAfter date

but the details I remember may be from Qualified Signature requirements,
not
the IETF standards

I do know that the BSI has a different policy still, so you need to know
under
which policy you need to perform the verification

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

the whole problem is that if you trust the date in the timestamp as the
date the timestamp was created, attacker can compromise the TSA key years
after
it was last used and then create timestamps that look like they have been
created while the TSA key was still valid
--
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

Reply | Threaded
Open this post in threaded view
|

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

Matthias Bühlmann
On Tue, Feb 16, 2021 at 4:34 PM Hubert Kario <[hidden email]> wrote:
On Tuesday, 16 February 2021 15:54:24 CET, Matthias Buehlmann wrote:
> 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.

not necessarily, it does not talk about the notAfter date at all, only
about
"not used anymore", that may (and actually should) happen at least a year
before
notAfter date

That's correct, the entire specification (unfortunately) doesn't explicitly mention notAfter/notBefore/expiration, but since this paragraph shows that while revocation invalidates a certificate this doesn't necessarily invalidate already issued token, this therefore means that one also can't assume that expiry of the certificate (which is another form of invalidation) would dictate invalidation of the already issued token.

Cryptographically it makes sense that timestamps in issued token can be trusted so long as one can trust:
1. the self-signed RootCA
2. that the hashing algorithm used for the digest in the token is still cryptographically secure
3. that the key-length and algorithm of the signatures in the trust chain are still cryptographically secure
4. that none of the private keys in the trust chain have been compromised
5. that the issuing certificate was valid at the time of timestamping

If these things can be trusted, then it's not possible that the token was forged.
Point 1 is an a-priori choice
Points 2 & 3 boil down to the mentioned cryptographic "lifetime" and depend on current policy at the time of evaluation.
Point 4 is a crucial one. If I have a copy of currently valid CRLs for all certificates in the chain and none of them shows that a key was compromised, then I can trust in this point. My question is whether there is any way of also trusting that no keys have been leaked if one doesn't have CRLs that are valid at the time of validation (for example, if one would have an older CRL that is not valid anymore but which shows that the certificate has been revoked for one of the accepted reasons, can one then also safely assume that the key hasn't been leaked at a later date? Is there for example a way one can establish trust that a private key has been properly destroyed in such a revocation scenario?).
For Point 5 one needs CRLs or OSCPs of the time of timestamping (or, as you point out correctly, maybe better of a day later - however AFAIK a rfc5280 CRL is not timestamped beyond the notBefore-notAfter validity period, so one couldn't say when these CRLs were obtained anyway other than by relying on the timestamp of the token that one wants to verify). Is it even possible to validate a token without having historic CRLs or OSCPs that were valid at the time of timestamping? (because any of the certificates in the chain may have been in "Hold" status (or can this be ignored since any "Hold" status that does not turn into a "Revoked" status can be ignored for token validity?)
 

but the details I remember may be from Qualified Signature requirements,
not
the IETF standards

I do know that the BSI has a different policy still, so you need to know
under
which policy you need to perform the verification

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

the whole problem is that if you trust the date in the timestamp as the
date the timestamp was created, attacker can compromise the TSA key years
after
it was last used and then create timestamps that look like they have been
created while the TSA key was still valid

Correct, that's the problem and that's why I guess the CRLs (historic and current) are crucial. If I have CRLs that are currently valid for all the certificates in the trust chain that show that none of the keys has been compromised (either due to the certificates not being revoked or the revocationCode being one of the accepted ones of chapter 4.1), then I should be able to consider the token being valid since it's not possible that it was forged.

The question then is whether there's a way to show a token could not have been forged if no currently valid CRLs are available (maybe because they're not issued anymore). For example, if a historic CRL is available, which was valid after the timestamp has been issued but is however not valid anymore at the time of validation, but which shows that the certificate was revoked for one of the accepted revocation reasons, can the token then be considered valid.

Are there any standardized policy definitions specific to RFC3161 (or RFC5816) validation?
Reply | Threaded
Open this post in threaded view
|

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

Viktor Dukhovni
In reply to this post by Hubert Kario
> On Feb 16, 2021, at 1:34 PM, Hubert Kario <[hidden email]> wrote:
>
> the whole problem is that if you trust the date in the timestamp as the date the timestamp was created, attacker can compromise the TSA key years after
> it was last used and then create timestamps that look like they have been
> created while the TSA key was still valid

Timestamps can only be deemed authentic if they are part of a Merkle
chain that validates all past timestamps signed with a *currently*
still trusted key.  The trusted key can change from time to time,
but the Merkle chain needs to be append-only.

Once a given Merkle chain is abandoned, and no longer has an active
signer attesting to the validity of long-ago events, at some point
it becomes impossible to say anything meaningful about the integrity
of past signatures.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

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

Matthias Bühlmann


On Tue, Feb 16, 2021 at 8:56 PM Viktor Dukhovni <[hidden email]> wrote:
> On Feb 16, 2021, at 1:34 PM, Hubert Kario <[hidden email]> wrote:
>
> the whole problem is that if you trust the date in the timestamp as the date the timestamp was created, attacker can compromise the TSA key years after
> it was last used and then create timestamps that look like they have been
> created while the TSA key was still valid

Timestamps can only be deemed authentic if they are part of a Merkle
chain that validates all past timestamps signed with a *currently*
still trusted key.  The trusted key can change from time to time,
but the Merkle chain needs to be append-only.

Once a given Merkle chain is abandoned, and no longer has an active
signer attesting to the validity of long-ago events, at some point
it becomes impossible to say anything meaningful about the integrity
of past signatures.
 
While I do in fact use a Merkle Tree in my case as well as chained timestamps, I don't think the claim  "Timestamps can only be deemed authentic if they are part of a Merkle
chain that validates all past timestamps signed with a *currently* still trusted key" is correct, since the specification in no way talks about Merkle Trees and only indirectly of Merkle Chains (suggesting that existing timestamp tokens should be time-stamped again in the future, however, this is in respect to a finite-length encryption key having finite lifetime - but this can well mean 1000 years in the future). It's true though that if one has such a chain AND one can show that at the time a newer timestamp was added the existing keys were still trusted, the timestamps can be trusted.