You bring up a good issue about revocation and it isn't something I've
thought about, just some details from RFC3161:
A) Time-stamping information needs to be obtained soon after the
signature has been produced (e.g., within a few minutes or hours).
1) The signature is presented to the Time Stamping Authority
(TSA). The TSA then returns a TimeStampToken (TST) upon
that signature.
2) The invoker of the service MUST then verify that the
TimeStampToken is correct.
B) The validity of the digital signature may then be verified in the
following way:
1) The time-stamp token itself MUST be verified and it MUST be
verified that it applies to the signature of the signer.
2) The date/time indicated by the TSA in the TimeStampToken
MUST be retrieved.
3) The certificate used by the signer MUST be identified and
retrieved.
4) The date/time indicated by the TSA MUST be within the
validity period of the signer's certificate.
5) The revocation information about that certificate, at the
date/time of the Time-Stamping operation, MUST be retrieved.
6) Should the certificate be revoked, then the date/time of
revocation shall be later than the date/time indicated by
the TSA.
If all these conditions are successful, then the digital signature
shall be declared as valid.
^^^^
I don't think there is anything in the openssl (ts) functions to accept
revocation to make this decision anyway.
At the end of the day, time-stamping is only going to be as secure as the
Time Stamping Authority is. The security of the certificates or rather, the
private key is paramount and if this is a third party performing the time
stamping, then this shouldn't be an issue. The party performing the
verification should only have the X.509 cert for the TSA and the X.509 for
the CA.
>From a point of view of gathering evidence and time stamping it, if you were
to present data many years later and not be able to verify the data due to
certificates being expired (CA or TSA or otherwise) then the standard would
be pretty useless as well as the concept/idea. I would think that so long
as you can take the revocation into account, a timestamp should be able to
be verified if any and all certificates used in the process are currently
expired, i.e. can't be used to sign at this point in time, but were once
valid and were valid at the time of signing.
Look forward to other comments and suggestions about this.
Brad
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of David Schwartz
Sent: Tuesday, 2 December 2008 2:54 PM
To: openssl-dev@openssl.org
Subject: RE: [PATCH] ts verify for expired certificate patch
> Problem Description:
> When a digest has been signed and a response is produced,
> the current version of openssl will not verify the contents
> correctly if the certificate used to sign the digest has expired.
> Solution:
> When verifying the response/token, the time at which the digest was
> signed is used by setting the time in the X509 store by using
> X509_STORE_CTX_set_time.
> I have attached a patch file to fix this.
> Brad
I don't know enough about the specifics of this use in this case to comment
intelligently on whether this is good or bad. However, I do know enough to
urge caution before this patch is accepted. There are a list of possible
issues. Again, I don't know whether each of these issues actually applies to
this situation, but they must be all ruled out by someone competent before
this patch is accepted:
1) The certificate may have been revoked before this signature was made. Yet
the certificate may not be on the current revocation list because expired
certificates may be dropped from that list.
2) Are we trusting the expired certificate to tell us when the signature was
made? What if the certificate is not very secure and so was only made valid
for, say, 6 months because it was expected to take more than 6 months to
break it. Now that somoene has compromised it 2 years later, we don't want
them to create a signature that claims it was made during the validity
interval.
I believe current practice is only to accept a signature with an expired
certificate if the signature is timestamped by a trusted certificate that
has not itself expired. That way, we know by a certificate that is still
valid that the signature was in fact made during the validity interval for
that signing certificate.
Again, this is outside my field of expertise. I just want to make sure this
isn't adopted (by the distribution or by readers of this list) before it's
security is evaluated.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
