SMIME certificates used to encrypt email
Hi List, I'm working with a library to decrypt emails with openssl, all is working well if I know which certificate was used, but now I need to detect which certificate was used to encrypt it and I want to know if openssl can do this automatically and if not I want to know if there is some alternative. regards, -- Daniel Zamorano Research Development __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: smime certificates
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]
smime certificates
I have been trying to renew a certificate geterated for signing emails. The renew goes ok. first revoke old one then resign req with new end date etc. and I can use the new certificate ok. However if I try and open an old email sent from home using my old certificate to sign it - I can't Outlook can't find the private key for the message. But if I put the expired certificate back on my windows box it does find it and all is well. Does this mean to open old email I allways need to leave my expired certs on the PC, or Have I not managed to re-sign the certificate properly? Or is this just the way it works? I have investigated; and the new certificate has a different serial number to the old one, if I fidle the certifate number and for openssl to re-sign the certificate with the same serial number - it works! But I am sure you are not suposed to do this! Anyone any ideas, suggestions? DEREK __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: smime certificates
[EMAIL PROTECTED] wrote: I have been trying to renew a certificate geterated for signing emails. The renew goes ok. first revoke old one then resign req with new end date etc. and I can use the new certificate ok. However if I try and open an old email sent from home using my old certificate to sign it - I can't Outlook can't find the private key for the message. But if I put the expired certificate back on my windows box it does find it and all is well. Does this mean to open old email I allways need to leave my expired certs on the PC, or Have I not managed to re-sign the certificate properly? Or is this just the way it works? I have investigated; and the new certificate has a different serial number to the old one, if I fidle the certifate number and for openssl to re-sign the certificate with the same serial number - it works! But I am sure you are not suposed to do this! Anyone any ideas, suggestions? DEREK __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] I'm afraid that this is just the way it works. One think should be obvious: The private keys have to be available to read old mails, since otherwise the old mails had to be re-encrypted with the new private key. I'm not sure how you do a renew with Outlook. The implementations I've seen always generate a new private key and a new certification request if the old cert is expired. If you're working manually with openssl it is possible to generate a new certificate request for the same private key, but this new certificate is different from the old one. As you noticed the serial number, as well as the Not before- and Not after-Fields are modified, since the certificate in fact must be a new one (even if the private keys are the same). So I can imagine that Outlook cannot match the new certificate with the old mail even if it has the same public keys. Anyone who knows better please correct me. Hope it helps, Ted ;) -- PGP Version: 2.6.3i Public Key Information Download complete Key from ftp://ftp.convey.de/ted/tedkey.asc Key fingerprint = 26 A9 0C 25 60 15 2C B2 D0 F3 A2 31 3D 35 F3 95 smime.p7s Description: S/MIME Cryptographic Signature
Re: smime certificates
[EMAIL PROTECTED] wrote: I have been trying to renew a certificate geterated for signing emails. The renew goes ok. first revoke old one then resign req with new end date etc. and I can use the new certificate ok. However if I try and open an old email sent from home using my old certificate to sign it - I can't Outlook can't find the private key for the message. But if I put the expired certificate back on my windows box it does find it and all is well. Does this mean to open old email I allways need to leave my expired certs on the PC, or Have I not managed to re-sign the certificate properly? Or is this just the way it works? I have investigated; and the new certificate has a different serial number to the old one, if I fidle the certifate number and for openssl to re-sign the certificate with the same serial number - it works! But I am sure you are not suposed to do this! Anyone any ideas, suggestions? DEREK __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] I'm afraid that this is just the way it works. One think should be obvious: The private keys have to be available to read old mails, since otherwise the old mails had to be re-encrypted with the new private key. I'm not sure how you do a renew with Outlook. The implementations I've seen always generate a new private key and a new certification request if the old cert is expired. If you're working manually with openssl it is possible to generate a new certificate request for the same private key, but this new certificate is different from the old one. As you noticed the serial number, as well as the Not before- and Not after-Fields are modified, since the certificate in fact must be a new one (even if the private keys are the same). So I can imagine that Outlook cannot match the new certificate with the old mail even if it has the same public keys. Anyone who knows better please correct me. Hope it helps, Ted ;) -- PGP Version: 2.6.3i Public Key Information Download complete Key from ftp://ftp.convey.de/ted/tedkey.asc Key fingerprint = 26 A9 0C 25 60 15 2C B2 D0 F3 A2 31 3D 35 F3 95 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. So the new certificate has the same public and private keys as the original, but outlook still does not realise it has the correct private key. The link that outlook appears to use is the serial number, if it does not find a certificate with the same serial number as the one in the message it will not find the private key to decrypt the message. 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. or do I tell the end users to open old mail they have to have the expired certificates on the system to. I hope the cobversations in this message help others to realize what is going on. All the best. DEREK __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: smime certificates
On Mon, Nov 15, 2004, [EMAIL PROTECTED] wrote: The link that outlook appears to use is the serial number, if it does not find a certificate with the same serial number as the one in the message it will not find the private key to decrypt the message. This is part of the S/MIME v2 (PKCS#7) standards. The recipient is identified by the certificates issuer name and serial number. 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. The CA commands don't let you easily do this for a good reason. It is a violation of the standards. The issuer name and serial number should be unique. If distinct certificates exist with the same issuer name and serial number quite a lot of software will misbehave or produce hard to trace errors. 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. or do I tell the end users to open old mail they have to have the expired certificates on the system to. I hope the cobversations in this message help others to realize what is going on. All the best. Well unless the software provides a means to reencrypt with a new certificate the only way is to keep the old certificates and private keys on the system. 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]
Re: smime certificates
Dr. Stephen Henson wrote: Well unless the software provides a means to reencrypt with a new certificate the only way is to keep the old certificates and private keys on the system. soapbox This is something I noticed before too - and appears to be a real failing with PKI. Although by failing I mean not what end-users expect... Let's assume the whole world has embraced PKI and everyone is sending/receiving S/MIME encrypted e-mails. How are we (as a society) meant to handle old e-mails - when by definition there is a lifespan associated with any certificates used in them? A different spin on the same problem: my cert gets stolen/compromised. I get my certificate revoked. Now no-one trusts my old e-mails - sent and signed by me before the cert was compromised?!? You may argue that is a MUA S/MIME implementation issue - but it's true today for the MUAs I've tried. What is the purpose of the expiry date on a S/MIME cert anyway? If you had a cert with a 1-year expiry date, *and you know it was never compromised* - then that fixes these sorts of problems. Is there any downside to that? As far as S/MIME is concerned (IMHO time-limited certs do have a place in other roles), if the safety of the cert is assured, then maybe we should have huge expiry dates on them? The idea that you have to renew/get new certs for crypting e-mails (documents in general?) doesn't seem right to me... I mean, as far as a usercode goes, as long as you have a right to access (say) a company network, your usercode is static. Your password that protects that usercode should be changed on a regular basis - but even that is really to *limit the length* of a compromise more than stop it being compromised in the first place. Maybe we should ensure apps focus more on private key protection than try to get the certificates via expiry dates to do that job? (and yes, that can always be worked around as the end-user controls everything in the case of a cert) /soapbox -- Cheers Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +64 3 9635 377 Fax: +64 3 9635 417 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: smime certificates
Jason Haar wrote: soapbox This is something I noticed before too - and appears to be a real failing with PKI. Although by failing I mean not what end-users expect... Let's assume the whole world has embraced PKI and everyone is sending/receiving S/MIME encrypted e-mails. How are we (as a society) meant to handle old e-mails - when by definition there is a lifespan associated with any certificates used in them? And while we are on the soapbox, I never understood why there is a lifespan associated with me anyway! ;) The lifespan of a certificate only defines the timespan during which it is valid to sign or encrypt with it. It says nothing about when to verify or to decrypt. And what's the problem to keep a certificate (which uses a kilobyte of memory) with the messages after it is expired? A different spin on the same problem: my cert gets stolen/compromised. I get my certificate revoked. Now no-one trusts my old e-mails - sent and signed by me before the cert was compromised?!? You may argue that is a MUA S/MIME implementation issue - but it's true today for the MUAs I've tried. That's the reason why you use certificates with a limited lifespan. So if your current cert is compromised at least the mails signed with the old mails are still valid! And, btw, if there is a reliable way to assure when the signature has been generated (for example using a timestamping service, or less elaborate, the time when you received the message) there is no reason to doubt signatures which have been generated before the cert was revoked! But I agree, this IS a MUA implementation issue. And an issue of assuring signature timestamps. What is the purpose of the expiry date on a S/MIME cert anyway? If you had a cert with a 1-year expiry date, *and you know it was never compromised* - then that fixes these sorts of problems. Is there any downside to that? As far as S/MIME is concerned (IMHO time-limited certs do have a place in other roles), if the safety of the cert is assured, then maybe we should have huge expiry dates on them? If you can assure the safety (that is, trust your users), this may be the way of doing it. It's just a risk optimisation, where risk is the product of probability of damage and amount of damage done. Maybe you also noticed, that many CA-certs have rather huge expiry dates... ;) The idea that you have to renew/get new certs for crypting e-mails (documents in general?) doesn't seem right to me... AFAIK it comes from the idea that it is never possible to assure 100% security. What if tomorrow some genious finds a way of qickly factorising products of large primes (they hope to be able to do that with quantum computers)? Then your 1 year expiry on a RSA-key may only last 10 years. And given enough time every key can be broken brute force. OK, there are some who say even the universe has a limited lifespan... ;) I mean, as far as a usercode goes, as long as you have a right to access (say) a company network, your usercode is static. Your password that protects that usercode should be changed on a regular basis - but even that is really to *limit the length* of a compromise more than stop it being compromised in the first place. And how do you handle the situationwhen someone manages to copy your (encrypted and password protected) secret key? This one would not be very impressed by you changing passwords (on your copy anyway). Maybe we should ensure apps focus more on private key protection than try to get the certificates via expiry dates to do that job? (and yes, that can always be worked around as the end-user controls everything in the case of a cert) As I tried to show, it's just the amount of paranoia hounting your brain. Noone prevents you to issue user-certificates with a lifetime of 20 years. But don't believe that you can make me trust your CA-cert if the protected data is valuable enough. /soapbox Hope this helps, Ted ;) -- PGP Version: 2.6.3i Public Key Information Download complete Key from ftp://ftp.convey.de/ted/tedkey.asc Key fingerprint = 26 A9 0C 25 60 15 2C B2 D0 F3 A2 31 3D 35 F3 95 smime.p7s Description: S/MIME Cryptographic Signature
