Discussion in 'Off-Topic Discussion' started by Edd1e, Oct 20, 2011.
Can someone please explain what S/MIME is ??
I'm more than positive you dont want to know, but here it goes.
S/MIME is a security extension standing for Secure Multipurpose Internet Mail Extensions. It has been around almost as long as SSL, came around about 1990's or so if I remember my books. S/MIME is natively supported by almost every popular email client. Google, yahoo, live; Yet it has not enjoyed anywhere near the same level of ubiquitous adoption as SSL, but that's beside the point.
You are asking what S/MIME is, and it's best explained in what it does it's self. This can be explained, I guess, in 5 parts.
1. The recipient always needs a certificate:
Due to the way public key cryptography works, a message is encrypted with the recipient’s public key from their certificate.
Only the recipient’s corresponding private key can decrypt the message. This means that if you’ve just deployed PKI, or purchased an email certificate from a third party, you are not necessarily any closer to being able to send S/MIME-encrypted email.
If your intended recipient is outside of your organization and does not have an email certificate, you’re out of luck.
2. You need to have the recipient’s certificate:
at the time that you’re ready to send the message, your email client needs to have the recipient’s certificate readily available, so that it can use their public key to encrypt the message properly.
If they’re internal to your organization, their cert can probably be looked up in an enterprise directory (kinda like BES for blackberry). But if this is not the case, you may be out of luck again.
Most email clients do have an ad-hoc way of sharing certificates, by exchanging digitally signed emails with your intended recipient first.
But this is not always practical or scalable.
In essence, many S/MIME deployments are focused on internal-only encryption scenarios.
3. Old Private Keys Need to be Kept Around:
When a user’s certificate expires and they enroll for a new one, the old one cannot be deleted, or the user won’t be able to read any email that was encrypted by the old certificate.
4. Private Keys Need to be Archived:
Any time you plan on keeping data on disk encrypted form -- an encrypted email is a prime example -- you will need to have a solid key archival and recovery plan, or you are risking data loss.
If a user loses their private key, or is terminated, retires, etc., their email still needs to be accessed.
In many cases this is a Data Retention requirement, with legal or compliance ramifications.
5. Separation of Certificates:
Encryption certificates need archived private keys.
But authentication or signature certificates have the opposite requirement when it comes to key protection: for digital signatures to have “non-repudiation” value, you want to be able to say that the user, and only that user, had access to the private keys… which is of course impossible if the keys are archived and recoverable by others.
This is why most email clients support the use of separate email certificates: one for email encryption and a different one for signing.
unlike encryption certificates, there is no risk of data loss from a lost signature certificate; you can just issue a new one.
Would you like me to go on?
I am here: http://maps.google.com/maps?ll=33.462327,-111.990684
Sent from my  iPhone 4 via Tapatalk
Separate names with a comma.