I agree with pretty much all of this. As far as the verification process goes in openssl, the certificate is verified before the token is I think which means you will need the date/time at which the digest was signed prior to "validating" the token.
Brad -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kyle Hamilton Sent: Wednesday, 3 December 2008 7:04 AM To: openssl-dev@openssl.org Subject: Re: [PATCH] ts verify for expired certificate patch On Mon, Dec 1, 2008 at 9:13 PM, Brad Mitchell <[EMAIL PROTECTED]> wrote: > I don't think there is anything in the openssl (ts) functions to accept > revocation to make this decision anyway. External daemons do exist, such as (e.g.) http://www.carillon.ca/tools/pathfinder.php > 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. Verisign is considered The Standard (as far as Microsoft is concerned). In fact: http://support.microsoft.com/kb/293781 lists all the certificates that are essential for Windows 2000, XP, Server 2003, Vista, and Server 2008. I'm not sure we should be considering Microsoft a standards-making body, but it's definitely a large consumer of the standards.) > 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 The point of the signature protocol is to effectively mirror the common-law requirements for signature verification: *At the time of the signature*, was the person identified as the signer intending to affix his mark as a part of a ceremony to agree to bind him-or-herself to the performance of a task, the non-performance of a task, or to limit the exercise of his or her rights in any way? (This is essentially part of the 'final proof' of a contract -- contract law, at least in the US, requires a clear understanding of the terms of the agreement, competent parties who could be legally said to be able to agree, and the agreement must include an exchange of valuable consideration. But, if the signature isn't valid, there's no need to determine if the other parts of a contract exist, much less what they entail.) The 'at the time of the signature' is the important part. This is why the time-stamp validation protocol is much more complex than most other X.509 signature validation, it's intended to provide evidence for a court that cannot be obtained any other way. -Kyle H ______________________________________________________________________ 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]
