Paranoid Penguin - Mental Laziness and Bad Dogma to Avoid

On a related note, consider the digital certificate, which consists of a couple key pairs (one for signing/verifying, another for encrypting/decrypting), identity information (such as your name and organization) and various Certificate Authority signatures. Conventional wisdom says that every digital certificate must have an expiration date, the shorter the better, in case the certificate's owner unexpectedly leaves your organization or the private key is somehow compromised. The consequences of either event could include bogus signatures, illicit logins or worse.

This worst-case scenario assumes two things. First, if the certificate's owner leaves your organization, it may take a while for the certificate to be revoked (and for news of that revocation to propagate to the systems that use certificates). Second, it assumes that the certificate's passphrase can be guessed or brute-force cracked easily.

But, both of these are solvable problems. If you're deploying a Public Key Infrastructure in the first place, you need to configure all systems that use certificates either to download automatically and use Certificate Revocation Lists (CRLs) from your Certificate Authority, or better still, configure them to use the Online Certificate Status Protocol (OCSP). Many events can lead to a certificate's need to be revoked besides reaching some arbitrary expiration date, and managing your certificates diligently and using CRLs or OCSP are the only reliable means of reacting to those events.

Regarding certificate passphrases, setting passphrase complexity requirements is generally no harder for digital certificates than for system passwords. The situation in which it can be most challenging to protect certificate passphrases is when machines use certificates (for example, Web server SSL/TLS certificates), which usually requires either a passphrase-less certificate or a certificate whose passphrase is stored in clear text in some file to which the certificate-using process has read-access privileges.

The bad news is, in that scenario, renewing the server's certificate every year doesn't solve this problem. If it's possible for people to copy a server's certificate once, it's probably possible for people to do so every year, every six months or as often as they need or like. The solution to this problem, rather, is to protect the certificate at the filesystem/OS level, especially its passphrase file, if applicable.

Does that mean certificates shouldn't have expiration dates? Of course not! I'm simply saying that, as with password aging, if this is your only protection against user attrition or certificate compromise, you're in big trouble anyhow, so why not employ a variety of protections that allow you to relax a little on expiration dates, as you ought to be doing those other things anyhow?

For as long as I've worked on information security in large corporations, I've been told that e-mail encryption is only for geeks, and that business users lack the technical skills necessary to cope with it. I've always found this sort of amusing, given that it's usually us geeks who accuse business people of having too-short attention spans.

But, is using PGP or S/MIME really that much more complicated than using, say, LinkedIn? I know which I would rather spend time on! (I am, however, an admitted geek.)

How much of the inconvenience in e-mail encryption really falls on end users? Nowadays, I would argue, very little, especially if your organization can support a PGP key server or can incorporate S/MIME certificates into an MS-Exchange Global Address List.

In practice, key management tends to be the biggest headache with e-mail encryption—specifically, getting a valid/current digital certificate or PGP key for each person with which you need to communicate. But, this need not be a big deal if you set things up carefully enough on the back end and give your end users local settings that allow their mail client software to search for, download and update their local copies of other people's keys transparently.

One can go too far, of course, in coddling end users. I've seen organizations issue keys without passphrases, which makes those keys trivially easy to copy and abuse. I've seen other organizations issue passphrase-protected keys, but then send people their new key's initial passphrase via unencrypted e-mail! Obviously, doing things like that can defeat the whole purpose of e-mail encryption.

My point, really, is that modern e-mail encryption tools, which typically support GUI plugins for popular e-mail readers, such as MS Outlook and Squirrelmail, are exponentially simpler to use than the command-line-driven tools of old. Given a modicum of written documentation—a two-page instruction sheet is frequently enough—or even a brief computer-based-training module, nontechnical users can be expected to use e-mail encryption.

This is too valuable a security tool for so much of the world to have given up on!

There, I'm starting to feel better already! But, I'm not done yet. On to some mental laziness that never fails to annoy and frustrate.