I'm afraid that this is "just the way it works".
Starting from first principles, there's only a few ways a system COULD be coded to work:
1. decrypt all messages as they are received, so the encryption is only for when the message is actually being transmitted
2. decrypt all messages as they are received, and then re-encrypt them with your choice of symmetric or asymmetric algorithm
3. leave the messages encrypted and require the certificate store to contain the certificates needed to do the decryption, whether those certificates have expired or not
4. leave the messages encrypted and store with each encrypted message the certificate necessary to decrypt it
Seems like from what you are telling us (3) is what Outlook does.
Note that the real problem here is that you are removing the expired certificates and expecting the old email to still be readable. If you just let the old certificates remain in the machine (which I suspect is the M$ model) it would still work.
Yes, there is a question of how to recover from a crashed or lost certificate store on the client machine. But note:
1. Losing a server certificate is no problem, you just generate a new one with a new key pair
2. Losing a personal identity (signature) certificate is no problem, you just generate a new one with a new key pair -- all the already existing signed objects will have a copy of the old certificate stored with them, so the signature can still be validated -- it's just that any new signing has to be done with the new signing certificate
3. Losing a code signing certificate is no problem, same argument
4. SO the **ONLY** case in which certificate escrow has any real meaning is **EXACTLY** the case of a personal privacy (encryption) certificate -- this is where all the argument in fact IS
Note: if you can regenerate the old certificate with the old private keys and the old serial number this is tantamount to maintaining an escrowed copy of the old certificate...
I thought it was, interestingly All the certificates are generated centrally and not in responce to a certificate request from outlook, So I am able to regenerate the certificate from the origanal keys and request. ... I have proven this by forcing the CA command to produce a new certificate from the original request and original keys with the same serial number. This works - but I was not sure if this is the only way.
So I now have to decide,
Do I do the above and force renewals to have the same keys, serial number and details from the original req.
This is against the rules: certificates have to be unique to the issuer and serial number. You cannot just reissue certificates with different expiration dates and the same serial number.
(this is true, isn't it?)
or do I tell the end users to open old mail they have to have the expired certificates on the system to.
With Outlook, yes. The other alternatives would seem to be difficult to achieve in the context of IMAP, for example, since it would require uploading stuff back into the server: (1) unencrypted message, (2) reencrypted message, or (4) copy of decryption certificate
There is a certain trade-off between security and convenience, and you may very well have just run into it.
I hope the cobversations in this message help others to realize what is going on. All the best.
DEREK
-- "An Internet-connected Windows machine is tatamount to a toddler carrying a baggie of $100 bills down a city street..."
Charles B (Ben) Cranston mailto: [EMAIL PROTECTED] http://www.wam.umd.edu/~zben
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
