Patrick Patterson wrote:
Actually, what you care about are the keys associated with the certificate. For encryption, you've got content that is encrypted with the public key, and decryptable only with the private key. Since the certificate is your public key signed by some Certificate Authority or other (or, itself), then after the certificate expires, most software will not let you or others encrypt things with that public key. However, since you are still in possession of the private key, you should still be able to decrypt everything just fine.
A cert is more than a public key signed by a CA -- it's a binding of that key to an identity (in this case an email addr?). Never mind the red herring of calling it an SSL cert, it's apparently used here for the purposes of SMIME encryption, which requires the use of two public-private key pairs in the case in which an email is encrypted and signed (and sent to another party). For enveloped data, the content-encryption key is encrypted for each recipient (using the recipient's public key); for signed messages, the private key of the sender is used appropriately to generate the signature. This requires that both the sender's public key and the recipient's private key be known and usable into the foreseeable future, independent of cert expiration. Keys don't expire -- certificates do. Expiration of a cert should only render invalid any messages signed (in the case of expiration of the sender's cert) or encrypted (in the case of expiration of the recipient's cert) after the expiration date. AFAIK many (most) MUAs which support SMIME will keep certs in their database forever, until purged. And why would you need to protect a private key when its associated public key is longer used for encryption, and when the key itself is no longer used for signing? - Michael ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
