What does 'openssl ts -verify' verify exactly?

Tue Feb 16 16:35:35 UTC 2021

On Tue, Feb 16, 2021 at 4:34 PM Hubert Kario <hkario at redhat.com> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210216/e8956221/attachment-0001.html>