Jon Udell has a good column about using the security features of email.

You can assert the validity and integrity of your messages, but no-one expects you to. You can automatically acquire public keys from others who sign their message, but no-one does so. Having acquired those keys you can encrypt messages to those people, but again, they don't expect you to do so.

The problem with the S/MIME suite of email security features is that they tackle problems people pay lip service to, but don't really care much about. A problem that people do care about, though, is spam. Do we care enough to assert our identities, and thus enable software to separate us from abusers who will not?

If you'll excuse me banging on about the virtues of Groove [again]... it fixes this stuff. As many people have pointed out, Groove's solution is to create a new infrastructure, with some proprietary protocols and software -- of course in many ways the spam issue goes away if you make a walled garden. I'd like to address those things too.

Let's separate this into: transport, identity assertion, and openness.

Groove messages -- IMs and shared-space synchronisation -- are always strongly encrypted. They're also signed, meaning that you can always provably verify their authenticity. Crucially, you don't get a choice in this: it's all-crypto-all-the-time. User indifference, the biggest factor in the lousy take-up of strong crypto, is completely ignored.

Identity assertion -- the subject of Jon's piece -- is more tricky, and here I think we have a great set of solutions. In the beginning, anyone can create an identity (from scratch, with no certifier). That identity has a name, address (vcard) and some keys. Everything you do is signed and sealed with that identity's keys: your identity is always asserted, even if it's not certified. To other users you just appear as "John Doe", but anyone can authenticate your identity for their own purposes: once I know you're the real "John Doe", I can tell Groove that the real John Doe should always show me a "yes it's really him" icon by his name. Even if the name changes, the keys remain intact. You can give John Doe an alias for your own use (say, "John from Dorking") without breaking the strong authentication.
Organisations can also certify users' identities. So my vcard says "Hugh Pyle/Groove", and this identity is certified by Groove Networks (my employer). I don't need to make any effort to authenticate other people from the same organisation: they get a "yes, it's really him" icon because we share a certificate.
Organisations can also cross-certify. So Gavin's user-icon always shows a "yes, Gavin's employer says it's really him, and we trust Gavin's employer" icon .

This begins to look interesting. Organisational certifiers, cross-certifiers, and full-on strong identities all the time. So we can automatically separate correspondents into several groups: members of my organisation, members of other organisations known to me, people I've authenticated myself, and don't-know-you-from-Adam.