Certificate Revocation Checks

Another usability issue that I have to deal with on a daily basis is the clash between enforced security policies and unavailable security services. Where I work, we use smart-cards that contain identity and email certificates. We are required to use them to access email using Microsoft Outlook. They serve as our two-factor authentication for accessing the account (you must have the card and know the PIN). This is a full-blown Outlook installation, so we have a central server that stores everyone's public keys so we can encrypt messages to one another and/or digitally sign them. The public keys are used by others to verify our digitally signatures and/or decrypt messages.

The cards are issued by another centralized authority so if you look at your certificates, you can see the chain of signatures going up to the root certificate authority (CA). The root CA certificates and all the intermediate certificates are installed and updated on everyone's system as part of a common enterprise-managed infrastructure (Windows 7 Enterprise).

Certificates can be revoked for a number of reasons (expiration, terminated employees, etc).  This includes both individual certificates and any certificate up the chain including the root CA potentially. So any time you receive a signed email, the signature must be verified by making sure it traces back to a root CA and has not been revoked. So where do we keep track of the certificate revocation list (CRL)? That's on yet another centralized repository somewhere and we use a program called Axway Desktop Validator that queries this repository to see if any certificates in the chain being verified have been revoked, which would invalidate everything from the point of revocation on down.

Our managed system policy enforces a number of behaviors that cannot be changed by normal, non-administrative users. The use and configuration of Axway being one of these. It integrates with Outlook so you rarely, if ever, see any visible signs of its existence. However, we certainly feel its effects because it rarely works well. The Axway program has a plethora of configuration options, many of them pertaining to timeouts for how long to keep revocation data and what to do in various circumstances and error cases. We seem to hit these cases frequently.

Whether the program and the service are simply latent in response or completely down, the local effect is that Outlook hangs until the operation is complete or times out, which can be on the order of 30 seconds. This falls into what I call the "piss-off" zone. It's long enough to disrupt your mental workflow and initiate frustration, but too short for you to go do something else and come back later. And often, the emails that use digital signatures are "official" messages from various authorities (facilities, security, IT, administration) that you really should read, so there's no avoiding it.

This whole certificate business is all about protecting integrity and providing non-repudiation, but these policy vs implementation clashes result in reduced availability. In my experience, availability always gets the short end of the stick over every other security aspect. I suspect it is because most people think of availability as simply a system being online or not regardless of performance and the cumulative impact that can have. The downstream consequences of poor performance can get multiplied exponentially.

Our technical support just shrugs their shoulders and says they can't do anything about the performance. They've deployed it as required. The security folks just shrug their shoulders and say "it's policy, you have to use it", whether it actually works well or not. So it becomes a classic case of the two entities that could do something about it just pointing the finger at each other and doing nothing. Neither one cares because they have each met their specific requirement.
A true improvement in the overall security of an organization would have someone appointed with both the responsibility and authority to look at these combined effects and do something about it. Perhaps the "Chief Usability Officer (CUO)". I'd like that job... :)

This post maps to CompTIA SY0-301 exam objectives 6.3 and 6.4.