On Thu, Dec 09, 2004, Chris Jarshant wrote: > All, > > We have a code signing facility that has signed a lot of code using > a certificate that recently expired. Now, validation of the signed > code fails because one of the certs in the chain has expired (not > the root cert, and not the signing cert). > > So, should the verification routine be changed to recognize that > the code was signed *before* the cert expired, thereby considering > the signature "valid"? Or should we re-sign the thousands of objects > using a new cert? It will be a pain to re-sign each time a cert in the > chain expires. Are there any official standards that say what it means > when a cert in a validation chain is expired? What are the security > issues in trying to ascertain the date that an object was signed so that > we can compare the "signed-on" date against the validity dates of > the certs in the chain (vs. using the current time of the system)?? > What other solutions are there? >
The usual solution to this problem is to countersign using a trusted timestamp. Then the signature of the timestamp is checked and the original chain verified at the time it indicates. Without a trusted timestamp various security issues are raised if the time supplied is simply accepted. For example someone with an expired or worse revoked certificate could simply set the system time back and use it, giving the impression that the signature was made when the certificate was valid. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
