Making email identity work

I've watched with bemusement as Bill Gates has been making the rounds lately -- the World Economic Forum, the RSA Conference -- to announce that Microsoft is "innovating on many different fronts" to eradicate spam. Really? The hashcash scheme, which requires the sender to spend CPU cycles, dates back to about 1992 or so. And "caller ID for e-mail" derives from RMX (Reverse MX), a more recent proposal to bind senders to authorized relays via DNS records.

The truth is we've had plenty of innovation over the years. What we've lacked is follow-through. Consider S/MIME digital signatures. It's very likely that your e-mail client supports them. But it's overwhelmingly unlikely that you've ever digitally signed an e-mail message. [Full story at InfoWorld.com]

There's no excuse for not having checked that myself. Typically I do. I've probably installed more digital certificates, in more browsers, on more operating systems, than anybody. But sadly I was willing to believe that the painful procedure outlined in that O'ReillyNet article was necessary because, well, that's the universal experience of S/MIME. Everything's ten times harder than it should be.

Whenever I write something about digital signatures, a handful of folks are inspired to send me signed messages, and since this happens so rarely, I always learn something new. One such message came from a DoD employee, who wishes to remain anonymous. His was the first cert I've ever received from a DoD certification authority. Outlook and OS X Mail, as it turns out, have inverse policies for dealing with this case. Outlook refused to trust the cert until I explicitly approved the issuing DoD CA. OS X Mail, questionably in my view, trusted it implicitly.

Anyway, the DoD guy had written to me to find out how to require per-message passwords, an advanced feature I describe in the column. In his office they use smartcards. When he hits Send in Outlook, he's challenged once for the smartcard PIN. Subsequent access to the signing key requires no further interaction. He's concerned about walking away from the machine and leaving signing enabled. For that, at least, there's a solution: yank the card when you walk away. But I'd add another concern: that a piece of rogue software could show up even while he's sitting there, and silently impersonate him. Clearly you're not going to yank the card during a session. So per-message confirmation of access to the private key -- which I've now also learned how to do in OS X Mail -- seems like a good idea to me.

But according to this fellow, what I have been considering a feature of Outlook is actually thought, by Microsoft, to be a bug!

If I am understanding the document at the following URL properly, Microsoft considers it a BUG if you get asked for your password before sending each digitally signed message (using Windows XP) and they have a BUG FIX so it will STOP asking you each time. This seems BACKWARDS to me from a security standpoint!

http://support.microsoft.com/?kbid=821574

Finally, I received this thoughtful response from David Wall, chief software architect of Yozons Inc., which I quote with permission:

You are to be commended for fighting through the free email certificate acquisition and installation process. And to think you just have to do it again next year. Or when you get another computer. Or you want to send email from your office, laptop and home computer using the same email address. Or when you change your email address, and you realize there's no way to invalidate the certificate for the old email address.

And if just you and the rest of the world would actually do this complicated process, S/MIME would finally become useful for email, provided all those desktops were secure enough to keep hackers and virus writers from stealing your keys. Also, if you encrypt on your desktop using a recipient's public key, you'll likely be violating corporate policies because the company will not be able to meaningfully audit or archive the encrypted message.

But do you suppose free email certificates wouldn't be free today if people actually wanted them? They are free because nobody will pay for them, and even at the cost of nada, few actually do. I think this points out that people as a whole just can't work with PKI's complexity, portability and constant renewal hassles. Have you ever tried to validate a digitally signed email from a few years ago? Do you really have the certificates that went with old message today? And even if you're one of the rare folks who actually keeps all of these thousands of certificates -- one per email address per year does add up quickly -- because they expire, you will get signature failures and have to note that the error was related to expiration and not because it was tampered with or the cert was revoked.

T-Mobile is our most recent large business customer. There are working alternatives today, like our Yozons business private network, and unlike S/MIME, they can also produce legally recognized electronic signatures as well as keep messages secure, provide full tracking and auditing, and there's no fuss about installing, revoking or otherwise keeping digital certificates current and secure.

The S/MIME problems that David Wall cites are quite real. And since we have so far failed to tame these problems on the public network, we are -- quite rationally -- retreating to various kinds of private networks. Yozons' solution is one example. Groove is another. Aggressively-whitelisted email services are yet another. It's far more practical to establish trust within private networks than on the public network, and there are very good reasons to do so.

But private networks are islands. We ultimately need a workable trust solution for the global public network. That's clearly a daunting challenge. PKI is only a first draft of the solution. It's possible that that we'll need to rip it up and start over. It's also possible, though, that we can refine and improve it. But not if current implementations don't evolve in response to use.

Former URL: http://weblog.infoworld.com/udell/2004/03/19.html#a948