Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Encryption Security

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

Posted by Cliff from the letting-others-know-that-e-mail-is-really-from-you dept.
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."
This discussion has been archived. No new comments can be posted.

Email Clients That Support Verisign Digital IDs? More

Email Clients That Support Verisign Digital IDs?

Comments Filter:

  • Danger Will Robinson (Score:1)

    by Anonymous Coward
    If they're "security conscious" then for goodness sake they shouldn't be using S/MIME. Very likely you will accidentally use weak crypto and not even know it because even to this day Netscape/Outlook and everything that supports S/MIME still has the weak crypto in there and usually uses it by default. Have your Russian friends switch to PGP and put their keys on servers. Generate larger than 1024 bit keys (an option unavailable in any major S/MIME app). There is no such thing as weak crypto in PGP.

  • Re:Your security isn't secure (Score:1)

    by Anonymous Coward
    So you grab the biometrics data if you have BO on the machine. At least you can *change* a password once compromised. A finger transplat is much more of a problem.
  • Sorry, I would guess you're right. I use Outlook Express; Outlook may be different.
  • That's what I get for going off without the facts. I meant to refer to Pronto, not PMail. I thought PMail's page didn't look right. Anyway, you get get Pronto at http://www.muhri.net/pronto/
  • Well, you can always use MS Outlook :-( I've been looking for the same, with the addition of supporting HTML mail, and it seems like PMail [scottbender.net] for GNOME has all these features. If you are a KDE user, I think newer versions of KMail [kde.org] might do the trick. StarOffice's email client also supports these features, but I found it to be awful. Mahogany [sourceforge.net] may also be a consideration. If you enjoy a text-based program, I highly recommend mutt [mutt.org] - awesome and highly configurable - I pass HTML mail through lynx or w3m to read it. I'll probably try out PMail for my wife soon.
  • China was not in the Soviet Block. Duh
  • The only part of X.509 PKI to come out of ISO is the layout of the certificate data structure. All the protocols (S/MIME, TLS, etc.) are developed by the IETF. All these documents are freely available. Check out the PKIX working group [ietf.org]. This is where all the development work on "X.509" PKI gets done.

    All of the people involved in developing these standards are "techno-geeks" who really know and care about security. The cryptography and protocols used in X.509 PKI are as strong as anything else out there. If you're really untrusting and paranoid, then you don't have to trust any other CAs, you can run your own.

  • Such a toolkit does exist. It's called NSS [mozilla.org]. This is the mozillafied version of Netscape's security libraries. It can do everything the Netscape communicator can do: SSL/TLS, S/MIME, PKCS #11, certs, you name it.

    It runs on every platform that Mozilla does: Windows, Linux, Solaris, HP, AIX...even Mac!

  • Should there really be a linux client for Lotus Notes? Is it not surprising that IBM/Lotus sees the linux platform as a server platform and not so much as a desktop? Personally I'm thrilled to be able to run the Lotus Notes/Domino server on Linux. I don't think they should take the resources to port the 5.x client over to *nix. Especially when wine, vmware, etc. allow the linux users to run the client just fine...
  • Oh, meant to include, Lotus is working on making the HTML interface to Notes much better. For many people a Notes client isn't needed... The only place where the HTML interface would be exceedingly annoying is for their email. But you can use POP3/IMAP to access your notes mail anyway, so why not just use that? Calendering might be annoying too but it some ways it would be better. The whole personal/group calendaring feature works well but isn't really setup optimally for the newbie. Maybe their HTML java widgets will fix that.
  • argh (just woke up)...

    Calendering might be annoying too but it some ways it would be better.

    Calendering might be annoying via the HTML interface but in some ways they could improve it over the current Notes client interface.

  • The idea with hardware tokens is that your private key is stored on it and that it can not be extracted from there. Instead the token (smart card for instance) supplies cryptographic functions that allows you to use the private key.

    If your smartcard reader has a so called protected authenticated path ( a pin pad or a fingerprint reader), the pin or the biometric info will _never _ enter your computer. And voila, you are protected against evil programs like back orifice!

    Take a look at precisebiometrics [precisebiometrics.se]

    The PKCS#11 standard: www.rsalabs.com

    A pin pad solution that provides protected authnticated path: www.accessgear.com

  • Two colleagues and I have just started a project on SourceForge [sourceforge.net] to do just this - make it easy to integrate S/MIME and other mail encryption capabilities to MUAs.

    Feel free to lend a hand.

    --

  • I tend to like high tech solutions like verisign, but if I have to pay for a key, I'll look more closely at the free solutions first.

    Try SwissSign [swisssign.com] for free X.509 certs and server certs.

  • Tradeclient does this very well... I've been using it for quite some time with multiple accounts (recieve and send).

  • PGP is available for many platforms, including Linux. And many E-Mail UA:s support them (mutt, pine, XFMail, etc). It's also free if you use GnuPG, or at least free for non-commercial use if you use the commercial PGP.

  • Right. And since PGP is avilable for so many platforms, point the person you are communicating with to it aswell. Problem solved.
  • Sounds a lot like S/MIME digital x509 certs to me. If this is the case then Netscape Communicator will do the job without problems, just make sure you request the key from Netscape in the first place so that it is supplied in the correct format to import (although this may be fixable after the event).

    The SSL plugin for Mozilla may add S/MIME support for this task too. Otherwise there's aways openssl on the command like and mutt ;)

    Phill
  • Pardon my typo, please...

    In the bit about importing the X.509 certificate after you export it from Netscape in pkcs12 format, the command for importing it should read: "openssl pkcs12 -in netscape.p12 -out temp.certs".

    That little typo of "-i" rather than "-in" is a touch embarassing.
  • 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?

    If there are people who have your private key, you're in a world of trouble, my friend. They could then decrypt anything that was encrypted with your public key (intended for you). Private keys are exactly that, private. I suggest you do some reading.
  • The same Certificate (to do away with the VeriSign product names) may be used for S/MIME -> mail and client authenticated SSL -> web-site access.
  • No need to add PGP to the mix.

    As the original author is stating, the ex-soviets are security conscious too, so he should get their certs from some directory service (or, if using Messanger, included in every signed mail) and encrypt with S/MIME directly.

  • So what's wrong with calling your coworker with a message (EG "I like green tea") and encrypting that message with your private key (using gpg or pgp), and putting your public key up on the web (giving the URL to the public key over the phone) or putting your public key on the keyservers?

    Because clicking on sign&encrypt in Netscape is so much simpler.

  • PKCS#11 [rsasecurity.com] is an API spec for accessing crypto token like SmartCards and SSL-Accelerators.

    VeriSign will give you a X.509 Cert (possibly in a PKCS#7 [rsasecurity.com] Message Format).

    VeriSign might deliver Certs on SmartCard-like token, which are accessed from Netscape via a PKCS#11 compliant driver.

  • yup. been using it for multiple mail accounts for years.
  • or maybe:

    Punctuation is your friend. Embrace it.

    or

    Punctuation is your friend; embrace it.
  • But just in case he's on his way to a scheduling get-together for the pre-meeting meeting, (IOW, if he's too Damned to see the fiery bars that cage him) it stands for Pointy Haired Boss.

    Boss of nothin. Big deal.
    Son, go get daddy's hard plastic eyes.

  • I only pay for things which have value.

  • Right, only people with his private key can read it. As the only person is him, only he can read it. What's the problem?

  • Pronto [muhri.net] can do this for you. When you compose a message there is a pulldown menu that let's you choose which account to send from, and, you guessed it, each account can have its own SMTP server.

    Its written in perl, and uses the GTK bindings, so you may have to download a few things to get it to work, but the install script takes care of this for you.

  • Bzzt! Thats psuedo-random, not random.
  • It's odd - I just looked at Verisign's site using Netscape on Linux and followed the link about using their certs with mail clients other than Messenger and Outlook. However, when I tried the same page w/ Konqueror, I found this link instead:

    http://www.verisign.com/client/enrollment/diff_e ma il.html
  • I'd like to thank everyone for their comments...even those of you who critiqued my grammer and punctuation. Sheesh. (g)
    Anyway, my original intent with my question was to find an email client, in Linux, that worked with a standard verisign digital id, much like it's handled by outlook in windows.
    In the 'new world' of Linux, we need a quick and easy way to prove our identities...I don't want to have to lose functionality to gain one advantage (ie, using a console mail app and losing rules/filters/multiple accounts, etc...).
    Thanks for your input, and I will keep you up-to-date (thats for the hyphen people below) on my search.
    thanks again. cya!


  • So what's wrong with calling your coworker with a message (EG "I like green tea") and encrypting that message with your private key (using gpg or pgp), and putting your public key up on the web (giving the URL to the public key over the phone) or putting your public key on the keyservers?

    Then if your overseas coworker can decrypt the message and get the correct text they learned of on the phone... it would seem this would go a good ways toward establishing trust.

    Sure, someone could snoop the overseas call and send the same message encrypted with their own private key, but they'd have a hard time taking down your website (which has the public key) and replacing it with their own (which would then hold the attacker's public key) without you noticing and calling back your coworker.

    I tend to like high tech solutions like verisign, but if I have to pay for a key, I'll look more closely at the free solutions first.
  • Try Pronto - it allows multiple smtp's, but it does ask which 'account' you want to be default. You have to manually change from the default account if you want to use a diff smtp.

    I'm at work so don't have the url, but you can find it at freshmeat.

  • Let me start by saying that I've implemented S/MIME for several different products on windows platforms, and have a reasonable amount of experience with what I am talking about (at least where it relates to the windows world).

    Why don't people develop an email client that supports S/MIME or PGP/MIME for Linux? The crypto toolkits. It's that simple. The tools are really complex, involve math that most people aren't familiar with, and invlove security, so if you don't do it just right, it might be insecure.

    Don't even think about using a third party toolkit for a linux app (unless you want to make the app non-open source). You would go bankrupt 100x over if you tried that. They are absurdly expensive for the most part (both the PGP kits from Network Associates, and the RSA kits and so on). I'm not over familiar with what might be available already open source, but I would be extremely surprised to find an open source toolkit that handled all of the neccessary algorithms and encodings.

    Not long ago, you couldn't use the RSA alg without paying royalties to RSA (of course you can now). That severely limited what you could do with open source RSA based algs. You also had the problem of export controls and ITAR etc. Just ask Phil Z. why this is a pain in the ass. So until just recently it would have been almost absurd to support S/MIME on open source. (Being as you would have had to pay RSA royalties on each copy of your free toolkit, and then get commerce department approval to export your toolkit (i.e. put it on the internet for general consumption) if you are in the US).

    Even today, if you want to develop an S/MIME client for linux, you will still need to write a good toolkit that handles all of the cryptography algorithms as well as the encoding/decoding of ASN.1 data (and other data formats if you are using PGP/MIME). Your toolkit must be open source (well at least it seems like it SHOULD be anyway), it must be secure (i.e. good PRN generators, zero out used memory, take advantage of cryptographic hardware if it is there, etc.), and it is going to take a heck of a long time to write.

    Now, when you are all done with the toolkit, then you can integrate it into an email client, with all of the UI that that may or may not require. All for a feature that almost nobody will use, and for functionality that you could have gotten (for the most part) using PGP and a little extra work.

    I think security is "a good thing", but today very, very few people use it, and most people simply don't care about security. Partially becuase it is so complex to do and to use properly, partially because most people just don't see the need for it in their day to day lives. Even in the simplest implementations, security makes exchanging email more complex because both parties must first create keypairs (and certs if using many protocols), and then somehow exchange them.

    Don't get me wrong, I think that email clients with built in security (such as S/MIME or PGP/MIME) can be a very nice thing, but I'd say that at this point they probably aren't worth the effort on Linux.

    NOTE: Why was it (relatively) easy in windows? The cryptography API that is part of windows. It has (more than) its share of flaws, but you can work around all of them that get in the way, it's free, and it's guaranteed to be on every windows box out there (excepting Win 3.x). Say what you want about M$ (I am not a big fan), but the gazillion APIs in the OS do make it easy for developers to add new features to existing apps in a relatively small amount of time (assuming that the API works and/or is documented). (I know, I know. The same can be said of open source, assuming that what you want is out there already). If my work had been targeting UNIX platforms instead, we would have had to have licensed a toolkit from RSA probably, and that would have cost us at least a quarter million, whereas the M$ stuff was free.

    Eric Klein
  • Well, for one thing, the great and mighty Knuth uses very poor examples to try and make his point. The words "non-zero" and "soft-ware" are much less like "e-mail" than are lots of words that are still hyphenated. For example: T-bill, u-turn, t-shirt, I-beam, o-ring, a-frame, s-curve, t-square, v-neck, A-team, U-boat, H-bomb, D-Day (which can also still stand alone as "D Day"), X-Men, f-stop, g-string, j-bar, Q-Tip, R-value, T-ball,T-bone, X-Files, X-rated and x-ray.

    About the only counter example I can think of is x-ray which I have seen spelled xray.
  • What you are trying to describe is a way to send a message via two differnet channels to make sure that an intercepter on one channel would be revealed. But you don't have to send an message that has to match over the different channels; just send the public key itself.

    Instead of doing this phrase thing, if you can call the guy, why don't you just have him read you your public key aloud, and you can look at it while he talks and make sure it is the same (or vice versa) ?

    Printing out the key and mailing it to him works great also. (A floppy disk or anything else to attract attention to the envelope may be a had idea for Russian mail.)
  • It seems that those id's are pretty standard X.509 certs. Netscape Communicator supports them. There are other efforts to make them work in another MUAs but none functional yet. Just export your cert from the Windows MUA - in pkcs12 format (export option should exist) and import it to linux netscape.

    --
  • As other said mozilla, doesn't support it yet. Someone out there have an ETA when it will?
  • Actually, Mozilla doesn't yet support encrypted or signed e-mail.
  • hey! you stole my secret phrase!
  • This is an important point but you should be aware that the Security Service of the country concerned would automatically be suspicious of 1k+ keys. 56bit and 128bit keys are not difficult to solve: What are you protecting? and from whom? If your co-workers are concerned about the State organs then I would suggest that it is easier and less time consuming for the State to raid the office/home of your co-workers and recover their PCs/documents - drawing attention to themselves by lengthy encrypted transmissions will be a self defeating object. Sometimes NO security is a better cover than any security at all. If they just need to know emails are from you then the excellent suggestions above will suffice; if on the other hand security of the content of messages is imperative I would recommend that you consider obfuscation or some of the other measures used to send encrypted messages covertly. As a foot note you should be aware that in the former soviet union 'paranoia is in the Levi's', it's how people survived from Stalin's purges onward and it is how the state exerted control; using the principle that if the population are so paranoid that they will not speak to anyone then they cannot plot against the state!

  • GemSafe Workstation deals with another dimension of this problem - it wraps Netscape's PKCS11 and IE's CSP functionality and enables the browsers and e-mail applications to store their x.509 certificates on a SmartCard.

    Not having the certs ever stored on a hard drive is something of an appealing idea, seeing as it gives you both mobility and an added level of authenticity, since there's only one copy of your private key in existence - and it happens to be protected by hardware encryption on a self-locknig pin-protected card.

    Here's the deal, though - GemSafe workstations only runs on Winblows systems at the moment.

    A few guys on our team, or elsewhere in the Gemplus Linux group have adapted some of the GemSafe functionality to linux - the pam-with-smartcard smart-login to machines, ssh-from-a-smartcard type stuff, but we've never adapted our own PKCS-11...

    What a great idea! I'm bringing it up at this afternoon's meeting, I just wanted to thank you for the idea, and see if anyone else has any additionals input to offer. :)

    Monstre.

    LinuxChicks of http://www.gemplus.com
    gila.sheftel@gemplus.com

  • yeah, but Berkeley is kinda communist, and they STILL hate the french. I would definitely take umbrage at someone calling me a frenchman, after the way those sneaky cheese-eating bastards stole the last World Cup. But I would be pretty peeved if someone called me a "floppy beef curtain," too.
  • Jeebus christ this guy must have searched high and low when the answer is two words that were probably on the tip of 95% of /.ers.

    One thing I'm sick and tired of hearing is the neverending chorus of PGP (GPG) users exclaiming why don't you just use PGP? Face it people, if this guy can't figure out that netscape messanger will solve his problem under linux then he's going to have a hell of a time with PGP. And since 99% of users are generally cluefree concerning matters of encryption the chance that his correspsondents also no nothing about PGP is fairly high.

    Shite.

  • They've answered your question. Netscape Messenger is an e-mail client which supports Verisign X509 certs, so does M$ Outlook but that doesn't run on Linux.

    Now Netscape likes its certs in PKCS12 format, so you may need to use openssl to do the conversion

    openssl pkcs12 -in cert_from_verisign -inkey your_private_key -out something.p12 -export

    should do it.

    It's probably not a good idea to use PGP because 90% of e-mail users on this planet use M$ Outlook which only supports S/MIME and the point of e-mail is to be able to send it to and receive it from other people.
  • Does anyone know why we don't have a VeriSign compliant secure e-mail program in Linux?
    No. But I think that I know that we do have a VeriSign compliant secure e-mail program in Linux...
    And if we do, where the heck is it?
    http://www.netscape.com [netscape.com]
  • The cryptographic key material used by PGP and X.509 certificates are essentially the same. Newer versions of PGP can support X.509 certificates where the PGP key is stored as an X.509 extension. YMMV.
    Also, check out Mutt at http://www.mutt.org [mutt.org] for a secure application.
  • plenty of clients support multiple SMTP servers. Of course, being one of its authors I can't stop myself from advising you to have a look at Mahogany [sourceforge.net]
  • Since about 1.4.2 of XFMail we have supported sending email's to different SMTP gateways based on the address you are sending from.
  • You seem to misunderstand my comment.

    I was quoting him and fixing his terminology.

    Attaching a certificate to a message doesnt prove the person wrote that message. A signature does.

    The certificate is supposed to help you ensure that the public key used to check the signature belongd to the person you think it does.

    read better

  • I think the idea is that you're always going to be sending from one machine and so, one domain. And, since at least some, perhaps many, smtp servers refuse to transport mail that isn't from or to their domain it's never really come up.
  • With so many options out there for authentication and encryption, it seems that its just getting harder to send someone a message they'll be able to verify easily. I think we need to accept some standard that is (at least) interoperable with others.

    --
  • http://prometheus.zerodivide.net/apps/pimp/ I'd be willing to add support for those signatures and such. Already working on gpg support.
  • You are forgetting your favorite Linux web browser! IIRC, Netscape has time-tested support for PKCS-11 public key infrastructure. When you obtain your X.509 certificate from VeriSign, you should be able to request a PKCS-11 key and install it into Netscape just by clicking on it.

    Also, take a look at some of the cool devices you can use to carry your certificates in. They are very inexpensive these days and you can use them on almost any platform and take them with you! Check out http://www.ibutton.com/pki.html [ibutton.com]. These things rock! I just bought one!

    -Pat

  • it's pretty standard in English writing for a new word to start out hyphenated and over time lose the hyphen as people get used to it.
  • MUAs need to talk SMTP to send mail AT ALL. You don't send outgoing mail via POP3 or IMAP - those are reading protocols. What is desired is the ability to send outgoing mail via a different SMTP server depending on which incoming server is selected. I'd also want it to used the appropriate e-mail address depending on which inbox I'm in...
  • Netscape Communicator 4.X (well, at least 4.7X) has supported individual certificates (even more than one at a time) quite well on all platforms.
  • Outlook's a bitch with multiple accounts, especially if some are MS Exchange and some are POP3/SMTP... Outlook Express works fine, however.
  • Nimrod, China is it's own sphere of influence and never needed Soviet protection. And the former Soviet bloc countries are still a reason to make people paranoid.
  • Oh, boy! Lets pity Castro's supporters because they've blindly embraced the hull of the Titanic on its way down. That mean old iceberg. Open your freaking eyes! The Russians abandoned that Communist crap almost a decade ago, and the Chinese are slowly building more capitalist zones to power the PLA. Cuba will turn noce Castro's mouldering corpse is thrown into the waters between Florida and Cuba. What the fuck are you doing in *your* basement, freako?
  • This is a good point. Almost done reading Cryptonomicon and it's putting me of a mind to make sure our overseas offices (one in a Soviet bloc country) begins using crypto for their communications to the US. Can overseas people get 4096-bit stuff? It also brings to mind what can happen to someone in another country when the state wants to get your keys. How many days would it take to crack your key by putting you in a cell? And, you may not know what you want to hide until it's time to hide it, by which time it's already encrypted and you look incriminating.
  • What's even less secure is that little button that says "don't sign this message" or "don't encrypt this message". At least that's how my PGP works. I sit down at your computer, I turn off the use of the certificate, I send a letter to your boss saying how much you want to tie him up and eat his dog in front of his whole family, and then I leave.

    You say that it couldn't be you, because you always use encryption for everything you do? Convenient excuse. Hard to use that certificate on that computer in the office from the unemployment line.

    Point is that unless you live in a tank you're not even going to be 99% safe. Heck, even then, give enough Vodka to some guy name Lenin and his wife and years later you end up with a kid with whole lot of tanks that'll take your keys and give you to guys with enough bamboo sticks to make you shout your keyphrase 5 times a minute.
  • I wouldn't want to tar all of the respondents in this interesting thread with one brush, but I've got a feeling that for many it would be useful to step back and have a look at what "security" is trying to achieve for an electronic transaction such as the email messages of the author.

    Although in general usage the word "security" has a range of meanings, when we talk about it in this context, we are mostly referring to the following:

    - encryption, to protect a communication against disclosure to other than intended recipients
    - signing, to "guarantee" the identity of the sender and to provide for non-repudiation of the message (I can prove that you sent the message, and that it hasn't be tampered with)

    So PGP is a good solution for encryption, but would require a deal more before it could be used for non-repudiation. For example, there is a PGP key pair for Patrick Keogh. I assert that I am Patrick Keogh, and indeed the same Patrick Keogh, but the reader would be foolish indeed to assume that any message that comes PGP-signed by Patrick Keogh is written by this /. contributor.

    All of that "bureaucratic" stuff that you get with X.509 and an appropriate X.500 infrastructure (RAs, CAs, paying for stuff etc. etc. etc.) end up being necessary if you want a general and flexible "security" solution for electronic transactions. And that's not all ... you also need traditional network and server security, a model for authorisation (all the above helps decide who the user is, but you also need to decide what they are authorised to do), well thought out security policy, appropriate auditing etc. etc. etc.

    I guess in summary, it is like anything else, the devil is in the detail. Doing e-business security without a really good idea of what you're trying to achieve, and what the pitfalls are, is like do it yourself brain surgery.
  • yes, you sure don't want to pay money for anything.
  • The T in T-shirt isn't an abbreviation, it's not short for anything, it stands for itself. And hyphens don't normally signify abbreviations. T-shirt has kept the hyphen because it would be confusing otherwise.

    The X in TeX is some greek letter, chi I think, hence the unusual pronunciation.

  • Awesome list, dude.. Did you pull those out of your hat as you keyed in the post?

    Personally, I use e-mail and email interchangeably, depending on the "tone" of the sentence. If I was a man-eating space alien, I'd spell human "hu-man."

  • Gnus (Score:2)

    by cdh ( 6170 )
    Gnus [gnus.org] has this ability. I haven't actually tried it, but there is a smime module that explicitly lists X.509. Not sure what version it started coming with but the latest version has it.
  • Netscape Messenger.

  • Two colleagues and I have just started a [sourceforge.net]
    project on SourceForge to do just this - make it easy to integrate S/MIME and other mail encryption capabilities to MUAs.

    Feel free to lend a hand.

    --

  • Just a quick bit I put together; don't blame me if it doesn't work right for you. :)

    This only works for UNIX/Linux, it assumes that you have OpenSSL installed in /usr/local/ssl, and assumes that you've got Pine setup already.

    Do these things (and do 'em the way I did 'em) and you'll end up with a Pine that can send S/MIME signed messages, and S/MIME signed+encrypted messages. As for decoding messages, for the moment, export them to a file, strip off the mail headers, and manually decrypt them with openssl. More directions on that later in the post.

    - Fire up Netscape or Internet Explorer. My Mozilla nightly from 01/09/2001 couldn't handle this.

    - Go to www.thawte.com and sign up for their FreeMail service. You'll end up with a valid, signed by a known CA X.509 certificate.

    - When the process of creating your certificate with Thawte asks what kind of certificate you want, choose "Netscape".

    - You'll go through a song and dance with Thawte, eventually, you'll have the option to import your X.509 certificate into Netscape. Do it.

    - Once the X.509 cert is imported into Netscape, bring up the Security Info window, click into the box to look at "Your Certs", and export your FreeMail cert to a file.

    - Use OpenSSL to get the cert out of the pkcs12 format that Netscape saved it in. If you saved the X.509 cert as "netscape.p12" something like.. "/usr/local/ssl/bin/openssl pkcs12 -i netscape.p12 -out temp.certs" would be a good command to try.

    - Break the temp.certs file into four parts
    * Private Key [save as private.cert]
    * Thawte FreeMail Key [save as thawte.cert]
    * Thawte Root CA Key [don't save, just toss it]
    * Public Key (the one with your email addy) [save as public.cert]
    In temp.certs you should see the Private Key first, then the Thawte FreeMail Key, then Thawte Root CA, and finally your Public Key.

    - chmod *.cert to something safe. -r-------- might be good.

    - Make a .ssl directory in your home directory, and chmod it to something safe. "mkdir ~/.ssl; chmod go-rwx ~/.ssl" might be useful.

    - Su up to root.

    - Create a shell script named smime-sign.sh in /usr/local/bin, and chmod ugo+x it. The source for smime-sign.sh is later in this post.

    - Create a shell script named smime-sign+enc.sh in /usr/local/bin and chmod ugo+x it. The source for smime-sign+enc.sh is later in this post.

    - Log out of root.

    - Fire up Pine, go into Setup, then Configure.

    - Find the "sending-filters" option.

    - Create a sending filter that reads "/usr/local/bin/smime-sign+enc.sh _TMPFILE_ _RECIPIENTS_"

    - Create another sending filter that reads "/usr/local/bin/smime-sign.sh _TMPFILE_"

    - And done!

    - Note, you *must* put the public keys of anyone you want to send email to into files in the .ssl directory in your home directory before you can send encrypted email to them.

    - Note, these scripts have only been tested on SuSE Linux 6.4, and I have nasty idea that /bin/sh may really be bash rather than bourne shell in SuSE. Syntax in the scripts may have to be updated for use with a real bourne shell.

    - Note, you can only send encrypted email to one person at a time using the smime-sign+enc.sh script. If anyone wants to fix that, feel free.

    - Decrypting mail that was sent to you encrypted would use a command something like this (if you exported the email to temp.crypt): "openssl smime -decrypt -in temp.crypt -inkey .ssl/private.cert -recip .ssl/public.cert > temp.plaintext"

    - For notes on verifying mail that was sent to you, try www.kfu.com/~nsayer/encryption/openssl.html and look near the bottom of the page.

    Scripts:

    smime-sign.sh

    #!/bin/sh
    user=`whoami`
    tmpfile="$1"
    certdir="/home/$user/.ssl"
    sslbin="/usr/local/ssl/bin"

    $sslbin/openssl smime -sign -inkey $certdir/private.cert -signer $certdir/public.cert -certfile $certdir/thawte.cert -in $tmpfile > $tempfile.signed

    mv $tmpfile.signed $tmpfile
    exit 0

    --

    smime-sign+enc.sh

    #!/bin/sh
    tmpfile="$1"

    if [ ! $# = 2 ]; then
    rm $tmpfile
    exit 1
    fi

    user=`whoami`
    certdir="/home/$user/.ssl"
    sslbin="/usr/local/ssl/bin"
    error=0

    recipients=`echo $* | sed "s,$tmpfile,,g"`

    recipentcerts=`for r in $recipients; do
    cd $certdir
    grep -l $r *
    if [ $? = 1 ]; then
    return 1
    fi
    done`

    if [ $? = 1 ]; then
    rm $tmpfile
    exit 1
    fi

    $sslbin/openssl smime -sign -inkey $certdir/private.cert -signer $certdir/public.cert -certfile $certdir/thawte.cert -in $tmpfile | $sslbin/openssl smime -encrypt $certdir/$recipientcerts > $tmpfile.signed

    mv $tmpfile.signed $tempfile
    exit 0

    Please consider all code to be firmly under the GPL v2 license. (www.gnu.org/copyleft/gpl.html)

    Notes: I only gave this brief testing - there may be a few bugs, particularly in the error handling.

    That's all folks!

    You can email glorian@eudoramail.com with questions, compliments, praise, etc, but I don't promise replies. ;)
  • 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.

    Not correct AFAIK--any link in the chain may be compromised, calling into question the validity of any key below it. This is one of the many problems with PKI (in the specific sense that term is often used, not in the general sense), and is why I prefer PGP, which has the same problem (as any public-key structure must), but handles it better.

  • Saying that a MUA should send mail to a remote SMTP server is assigning a job to a program not designed to handle the job.

    Well, If you're a singular entity in a singular domain. I'm not. I have accounts in multiple domains. Each domain resides in an entirely separate sphere of influence. For profession reasons my email should originate from the appropriate domain. For privacy reasons no-one needs my personal email address.
    It would be nice to not have to log in to each domain for email, but use a central client. Besides, if a client can log into one SMTP server, why not two or three or ...?

    Surely I'm not the only one with this problem.
  • Already available in KMail

    Ummm... have you actually tried this? Its possible with much fiddling with filters to get KMail to reply through the appropriate domain, but you cannot arbitrarily send through a specific domain. Neither does it support "POP before relay"

    and no, multiple accounts are not the feature he's looking for, so he's in pace and your'e shooting high.

    It seems that any client that can already connect to one server could surely connect to more than one. That doesn't sound like a very high aim to me.
  • E-Mail Clients That Support X.509 Digital IDs

    How about a client that simply supports multiple accounts and SMTP servers first?
    Of all the clients I've been able to test, some allow you to receive mail from multiple accounts, but none support sending through these accounts. Its always pick one, and only one, SMTP server. What's up with that?
  • Huh?, ever tried "View->Mail transport" in the composer?

    OK, I didn't see that - I'll try it. KMail's in bad need of more documentation :(

    Neither does it support "POP before relay"
    What exactly is that and why is it useful?

    It is a user verification method that requires one to POP the mail server (check for mail) for authentication prior to using the SMTP server.
    This must happen in sequence.
  • pine's "Role"s do this.
    setup seperate .sig's and reply-to's and everything. not quite as seamless as it should be, but best thing i've found in linux for handling 10+ email accounts.

    --
  • Just have one organization-signing key.

    All members have their trust flagged to trust all keys signed by the organization-signing key for their organization. They also get their own key signed by the organization key.

    By some configuration of how PGP calculates trust, you can put in transitiveness to make organizations trust other organizations. (For example, all are automatically marked to trust any keys signed by keys signed by the 'master organization'-signing key.

    True, PGP is not intended for this. One problem is that the key trust is transitive. I trust you who trusts someone elses key who trusts ..... to $N$ levels deep. You need this transitivity, but not necessarily to all 8 levels. We can use the UID field on a key to put an advisory informing PGP to cut the levels of transitivity.

    (So, an organization's master key can be flagged to not spread trust too far. You can also have cross-organizational trusting, and finally, one key may be a member of more than one trust heirarchy. (For cross-organizational groups.)

  • see http://www.winecentric.com/

    Works great.
  • I faced similar problem myslef and
    find out that seems to be 2 words - PGP
    users and X.509 users. Both have some
    mechanism within but no way to communicate
    securely with another world.

    So, here is idea: somebody could establish
    service, which will forward email messages,
    signed with PGP re-signing it with X.509 and
    vice versa.

    Suppose PGP user A@a.com wants to send encrypted message to X.509 user B@b.com. In his address book
    B is listed as B@forwarding.com and forwarding.com
    public key as B public key. So he just send message, which is received at forwarding.com,
    decrypted and re-encrypted with X.509 key of B.com
    and forwarded to him.

    The disadvantage of such scheme is that both parties should trust this forwarding service.

  • If you can convert the format to PKCS#12, you could use S/MIME mail in NS Communicator
  • some allow you to receive mail from multiple accounts, but none support sending through these accounts.

    It sounds like your goal is really to be able to send mail "from" any of your various accounts. That is, your recipients should see the mail as "coming from" user1@domain1.com or user2@domain2.com. Am I right?

    Really, which SMTP server you use doesn't matter much here, unless you're dealing with savvy people who dig into the SMTP headers. There are several e-mail clients (I use pine) that support multiple profiles. I've got a profile (pine calls it a "role" setup for each of my e-mail addresses. When I compose a new message, I get to choose what role I will use. Pine is fairly intelligent: It recognizes when someone sends mail to a particular address and replys by default come from that address/role (I can always change it, of course)

    So what SMTP server do I use? After all, most smtp servers are picky about who they will allow to use their services. Easy: I have to run an MTA for fetchmail to hand my POP'ed email to, so I use the same MTA (sendmail in my case) for sending. Yes, sendmail for one person could be considered overkill and there are simpler, lighter-weight MTA's out there. Find one you like.

    In short, worry less about which SMTP server you're using and look for something that lets you define multiple sending addresses.Good luck!



    --
  • >what's wrong with calling your coworker

    12-hour timezone difference, for starters ;-)
  • Amongst GUI clients:

    Mulberry (from Cyrusoft: http://www.cyrusoft.com) has Win, Mac, Solaris, Linux clients. It's commercial but worth it.

    Has preset identities, which can group an outbound mail "account" and a variety of headers, sigs, and signing/encryption keys. Can configure outbound mail in response to mail in a specific mail "folder" to default to a specific one of these identities.

    Automated filter rules are in alpha and need some work, but are almost there.
    S/MIME support is planned but not there.
    PGP support is in there.

    Supports IMAP (full online, offline, or disconnected: offline filing, mailbox creation, etc. work properly), POP and local mailboxes.
  • I just downloaded Mozilla 0.7 a few hours ago and setup my email with it. I haven't used the feature yet, but it claims to allow multiple outgoing SMTP servers.
    --
    MailOne [openone.com]
  • Hello, I had the same problem, because my company (a security consulting one) is almost based on Windows specialists and every single person on the company has a personal ID (Check http://www.thawte.com if you want one personal for FREE). I looked everywhere to see if I could find any console tools to do this (i really love console on linux). But at the moment I looked for, I just found that Netscape Navigator (4.7x in my case) worked with these IDs. And worked pretty well, on my personal experience. But now, looks like that the new PINE (console program) support it too. Take a look and choose the best one that fits for you (But for God's sake, just don't use the MS Outlook! :)).

  • Re:x.509, S/MIME, and OpenSSL (Score:3)

    by Anonymous Coward on Thursday January 11, 2001 @09:06AM (#514092)
    I played around with mutt and openssl a little. I've got verification working, but have a problem with signing.

    $HOME/bin/smime_verify:

    • #!/bin/sh

    • clear
      openssl smime -verify -CAfile my-bundle.crt 2>&1 >/dev/null

    $HOME/.muttrc:

    • macro pager V |smime_verify

    • macro compose S |smime_sign

    $HOME/bin/smime_sign would be something like:

    • openssl smime -pk7out -sign -signer my-client.crt -certfile my-bundle.crt -from me@here -to you@there -subject "test msg" </tmp/testmsg.txt | /usr/lib/sendmail you@there

    ... but the .muttrc "compose" macro feeds the signing script only the current attachment, not the whole message. One could probably take over one of the PGP-hooks, but it would be nice to support both flavors.

  • Tovaris Solution (Score:3)

    by RJ11 ( 17321 ) <serge@guanotronic.com> on Thursday January 11, 2001 @12:37PM (#514093) Homepage
    Tovris has a product which would let you send X.509 messages from any mail client that supports SSL. Platform independant.

    The product is called the Mithril Secure Server and it acts as a proxy which sits in front of a mail server performing X.509 encryption/decryption on incomming and outgoing mail. A lot of ISPs are installing this in order to upsell managed security.

    SSL authentication for IMAP/POP/SMTP is required to maintain security from the proxy box to the desktop. This is a very elegant solution which is packaged as a network appliance. Pretty much plug and play for any standards based email servers.

    Check it out: http://www.tovaris.com.
    Email sales@tovaris.com for more information on pricing, etc.

  • Re:Your security isn't secure (Score:3)

    by disappear ( 21915 ) on Thursday January 11, 2001 @09:19AM (#514094) Homepage
    Yeah, but if they've got system-level control (ie BackOrifice or root), then even biometrics won't help, as you can override the reporting functions....

  • Beonex and Netscape (Score:3)

    by 12dec0de ( 26853 ) on Thursday January 11, 2001 @08:21AM (#514095) Homepage
    Basically all Communicator or Mozilla derived Browsers will work. Try Beonex [beonex.com], Friends said it worked fine for them. I myself had troubles with the archive, but thats just me.

    With X.509 it is allways crucial to have the root keys installed. And the Verisign ones are in the programs mentioned above. This minimizes the effort for the uninitiated.

    It should not be so difficult to includet the PSE from Mozilla in s/w like Balsa, if they offer a generic way to manipulate the network connection before it is made.

    But I allways had the impression that most coders in the free software arena prefer PGP, thus never took the time to write the code to support S/MIME and SSL.

    The neccesary backend libraries are there (here for instance [openssl.org]), but the integration and the GUI needed to make it happen in end-user software where never done. The good thing about the mozilla PSE is the fact that it has some concept of doing the GUI itself, only the integration has still to be done. If I only had more hours to the day B-)

  • Re:Netscape, openssl (Score:3)

    by gabuzo ( 34544 ) on Thursday January 11, 2001 @08:53AM (#514096) Homepage

    Beside being more supported for email (ie: usable with more user agents on more platforms) I think that PGP should not have been a bad move for this particular case. Since there seems to be a limited number of identified recipients you can always generate your key, send the public key to the recipient by email and check the finger print by telephone.

    S/MIME is more suitable to do secure email with the world since it does not require you to check the public keys (certificates) you receive with their owners. That's right but it does not really solve the problem, it only moves it somewhere else: instead of asking yourself I'm I sure that the key belong to whom it claims you'll have to ask can I trust the certification authority.

    Look at the certification authorities in Netscape or Mozilla, there are dozens of them. Well I think I can trust Verisign, Thawte (ok it's the same) but can I trust the other ones? Can I be sure that they properly check the identity before issuing certificates? Sincerly I cannot tell.

    In my opinion the biggest advantage of x509 over PGP is the possibility to use your personnal certificate not only to sign or crypt email but also to authenticate yourself on access controled web sites with the same key.

  • Biometrics aren't secure, either. (Score:3)

    by rjh ( 40933 ) <rjh@sixdemonbag.org> on Thursday January 11, 2001 @09:40AM (#514097)
    Check out Bruce Schneier's Crypto-Gram of a few months back for examples of how faith in biometrics is misplaced faith, at best.

  • X.509 and PGP (Score:3)

    by cnewman ( 160567 ) on Thursday January 11, 2001 @08:38AM (#514098)
    X.509 is a digital certificate standard from ISO. ISO is a government oriented bureaucratic standards organization. As a result, X.509 certificates are vastly more complex than and anyone interested in doing a security review of the source code has to purchase the standard. In addition, the trust model forces users to trust a hierarchy which they have no reason to trust in most cases. Netscape has awkward, but functional support for X.509 certificates, including the S/MIME standard which uses them to sign/encrypt email.

    PGP has a much simpler format and a default trust model which is much more secure. Unfortunately, the default PGP trust model generally requires a user to manually set up a trust relationship with every other individual. As a result the average person finds S/MIME much easier to use and that's what companies deploy. PGP seems to be relegated to techno-geeks, the paranoid, and people who really need strong security and got good advice.

  • Re:Why not simply use PGP? (Score:3)

    by SquadBoy ( 167263 ) on Thursday January 11, 2001 @08:30AM (#514099) Homepage Journal
    Because PGP is not what the people he is communicating with have. It would appear that they want some of the features that Verisign provides as a part of this service (in particular the level 2 serivce looks interesting) I could easily see how using this to sign and PGP to encrypt would be a very usefull combo. In particular if it made your PHB fell better if someone was offering him money if it did not work.

  • Your security isn't secure (Score:4)

    by Wee ( 17189 ) on Thursday January 11, 2001 @08:40AM (#514100)
    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 [biometrics.org] in order to be really sure your communications are secure and identifiable. Heck, even a SecuurID [rsasecurity.com] is better than a plain password dialog.

    -B

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

    by YU Nicks NE Way ( 129084 ) on Thursday January 11, 2001 @11:57AM (#514101)
    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 (Score:5)

    by slim ( 1652 ) <john.hartnup@net> on Thursday January 11, 2001 @08:18AM (#514102) Homepage
    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 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.

Slashdot Top Deals

As long as we're going to reinvent the wheel again, we might as well try making it round this time. - Mike Dennison

Close