E-Mail Clients That Support X.509 Digital IDs?

pipeb0mb asks: "I recently had to get a Verisign Digital ID [Verisign uses X.509 compliant ids] in order to securely communicate with some overseas co-workers, and unfortunately, I am limited to only a few programs in which I can utilize my encrypted e-mail. And all of those, so far as I can tell, are for Windows only. Does anyone know why we don't have a VeriSign compliant secure e-mail program in Linux? And if we do, where the heck is it? Also, how does the Verisign Public Key correspond to a PGP key?"

"I have already checked a previous Ask Slashdot on this, as the title would suggest being close, but it seems to be more about sending anonymous e-mail through a secure POP/SMTP connection for an ISP which is a tad different and a tad more complicated than my needs.

In my particular case, I have this Digital ID that confirms that any mail a recipient gets is actually sent from me. The way it works, every time I send mail, it pops up a dialog and asks for my password. After confirmation, it encrypts the contents and attaches a security certificate that the recipient can view to confirm authenticity. In this way, even someone on my machine can't send mail as me. The certificate allows me to encrypt mail also, so only people that have my specific key can read it. It has several other useful features as well. (Here's a quick FAQ link)

I have to do this because, at work, I deal with about 100 developers that live in an unnamed former Soviet bloc country, and are QUITE security concious. The Verisign DigitalID allows them to be sure that the mail they are getting comes from me. It's quite cool, and I would LOVE to have this capability in Linux. Unfortunately, there seem to be no solutions to this problem, at least none that are obvious."

Comments

Your security isn't secure

[Wee]

In this way, even someone on my machine can't send mail as me.

Hate to say it, but that's not true. If you've got something like Back Orifice (or a keystroke sniffer, or even a shoulder surfer) on your machine, then the jig is up. You need to use something which incorporates biometrics in order to be really sure your communications are secure and identifiable. Heck, even a SecuurID is better than a plain password dialog.

-B

Re:You sound like a corn-fed windows cow (sorry)

[YU Nicks NE Way]

And get your terminology right: It attaches a digital signature( not a "security certificate") then it encrypts your message. only people that have my private ( not "specific" ) key can read it. Where did you get those term from anyway?

Bzzt! Sorry, no prize, but thanks for playing.

PKCS 7 does, indeed, attach a copy of the certificate to the message. It also attaches a copy of the MD5 hash of the body of the message, encrypted with the sender's private key. The receiver can then recompute the hash of the message he or she received and compare it to the value he or she obtains by decrypting the encrypted hash paylod with the sender's public key. They must match, or the message has been tampered with.

Finally - and here's why people use X.509 certs, - the MUA can resolve the certificate chain corresponding to the cert in the message. If each certificate in the chain was issued by its putative issuer, and if the root of the chain is trusted, then either the sender's key has been compromised, or the message is both authentic and valid.

PKCS 7 can, but is not required to, encrypt the message body itself. That is a somewhat more complicated process. In order to encrypt a message, it needs the public key of the known recipient. It then generates a cryptographically secure random number, and encrypts it with the receipient's public key. It then use that random number to conceal the contents of the message (using a standard symmetric algorithm). That body is then signed as per the unencrypted form, and the resulting envelope is sent.

It is left as an exercise to the reader to figure out why (a) the message is securely encrypted, (b) the resulting message is repudiable, (c) this all works without either party needing to know the other party's private key and (d) why the keys in each leaf (non-issuer) certificate can be, and are, thrown away after the cert is generated, so that the only copy left in existence is in the cert itself.

Netscape, openssl

[slim]

S/MIME is the way to do email with X509 certificates, and Netscape Communicator is one mail app which uses S/MIME.

You can manipulate S/MIME messages (encrypt, decrypt, sign, verify) using OpenSSL at the command line. I'd love to see mutt hacked to front-end OpenSSL smime the way it can with PGP.

There are those who would argue that X509 is evil, thanks to its strict hierarchical structure (where Verisign's root CA is the big daddy of everything), and that only PGP gives the power to the people -- but from a pragmatic point of view, X509 is everywhere thanks to SSL etc. and if you want to be able to do secure email with the world, S/MIME is the way to go. PGP is attempting to converge with the S/MIME standard in any case.
--

x.509, S/MIME, and OpenSSL

[Brian Ristuccia]

x.509 is typically used with a message format called S/MIME. Recent versions of Netscape Communicator have a facility for sending, receiving, encrypting, and decrypting S/MIME messages using x.509 certificates.

If you use a flexible mail program such as mutt, you can pipe your message through the openssl smime command. By canning openssl smime with the options -encrypt, -decrypt, -sign, and -verify, you can perform all the same operations you could with a client that supported S/MIME natively.