Agility Loop

In order to verify a certificate, a relying party must perform three operations:

• Ensure the certificate is issued from a trusted PKI
• Verify the certificate is not expired
• Check that the certificate has not been revoked by the issuing certificate authority (CA)

Trust is typically a simple matter of installing the Root CA for the PKI that a relying party would like to trust.  I say typically because although this is trivial when one PKI is involved, it is very quickly getting more complicated in a bridge enabled world. Expiration is a time check against the relying party's system clock.  There is always some variation in clock times, but most relying party applications have some wiggle in time checking.  Even if they don't, a matter of a few minutes is really only important for highly valuable or sensitive transactions (and I don't have time to get into signed and authoritative time sources). Of the three, revocation seems to be the one that causes folks the most trouble, especially in larger PKIs like DoD.  There are two main revocation methods, with one additional emerging.

• Certificate Revocation Lists (CRLs) - CRLs are signed binary files that contain a listing of serial numbers and other information of certificates that have been revoked by an issuing CA.  Relying parties wishing to check revocation need to download the CRL and parse the file.  Each issuing CA issues a CRL (including the Root), so relying parties will likely need to retrieve multiple files.  These files can be cached according to how long they are valid (this value is in the CRL itself).  As your PKI grows, your CRLs grow along with you.
• Online Certificate Status Protocol (OCSP) - This is a HTTP request for the status of certificates.  The response from an OCSP server can contain more than one response.  Relying parties will need to make a OCSP call for every certificate that it checks.   Like CRLs, theses files can be cached.  However, the cache is somewhat less useful since it contains a small set of certificates.
• Server-based Certificate Validation Protocol (SCVP) - Although SCVP is a standard, support for the protocol is still emerging.  SCVP allows for out-sourced trust processing.  It is especially valuable in PKI interoperability scenarios.

So as an IT admistrator or application owner, what do you choose? First and foremost this depends on the size of your PKI and the lifetime of your certificates.  If you are dealing with a smaller PKI and shorter lived certificates (say 10,000 users and one year certs) than most of your applications should be able to handle CRL downloads.  However, larger PKIs (50,000+ users and 3 years certs) need to consider different revocation checking methods for different scenarios.  Some PKIs have a series of CRLs over 100+ MBs! For client applications, especially email, I typically recommend that OCSP be considered.  However, using OCSP means that your PKI has to have an OCSP server up and running 24x7x365.  If OCSP services are down, your uses will NOT be able to verify transactions (and they will get error message and then in turn call you).  Even if your PKI is outsourced, you may have to purchase OCSP client licenses.  Microsoft added support to Windows with Vista, and even then the client has limited functionality and configurability (although we have tested that newer OCSP server software now supports OCSP requests from Vista and 7).  Using CRLs for clients can get VERY messy.  Think of it this way, do you really want every email client in your domain pulling down upwards of 100+ MBs of files? For server applications, it really depends on transaction volume.  Keep in mind that for every certificate your application needs to process, a revocation check needs to be performed.  For OCSP, this means a HTTP request to an OCSP server that may not be on the same network as your application.  So if you have a lot of users or transaction in your applicaiton, this could mean a lot of OCSP requests.  If CRLs are used, then you need only retrieve a CRL once every time it is produced (or less often if you desire) and cache it locally.  Keep in mind however that many web and applicaiton servers have fairly brittle CRL implementations.  Many administrators will create scripts that will allow them greater control over CRL downloads. Next time I get the chance to post, I'm going to cover how PKIs make CRLs available, and what NOT to put into a CRL Distribution Point (CDP).  Yes...I know it is very exciting!

I actually used Wordpress's "Tag Surfer" feature for the first time today, and stumbled upon a post on Identity Blogger.   In his post, Jeff Bohren discusses the challenge of getting users to adopt passwords.  He also references a post by Mark Dixon on the same topic. I think both articles make good points...intellectually it makes a TON of sense to get rid of passwords.  Mark actually makes an interesting point that passwords are like seatbelts.

It was ease of use, not a technology-driven obsession with safety,  that led to wide adoption of the seat belt.

What I do not agree with is why seat belts were adopted.  I don't think it is just because seat belts are easy to use and they make us safer.  A lot of the reason that I think a lot of people started to use seat belts is it because it became law.  States started mandating seat belt use in 1984, and very quickly the states all fell in line and start adopting it.  So instead of choosing to use seat belts, people were required to use seat belts or they broke the law.  A fortunate side effect to making this a law is that now for generations that drive after this law was enacted (like my own), wearing seat belts is second nature. I believe that a similar kind of action is going to be needed for web applications and enterprises to get off passwords.  However, it may not be the Government that actually steps in to mandate this...at least not directly.  As it stands now, banks and credit card companies have the ability to write off fraud when accounts are stolen.  So the cost is really passed on...they aren't really paying the $40 billion plus in fraud every year.  But what would happen if banks and credit card companies were limited in how much fraud they could actually write off?  I think that all of a sudden you would see a HUGE uptake in the use of improved identity technologies and the discontinued use of passwords.  Users would be forced to stop using passwords b/c the banks and credit cards would be financially dis-incentivized to support them any longer.  Of course the financial institutions would still find a way to pass the costs onto the consumer or the government... A quick and dirty case study for you.  DoD has been issuing smart cards to their population of 4+ million for years.  The primary use for a long time was secure email.  It wasn't until it was mandated by DoD that the cards be used for log on to networks and applications that passwords finally started going away.  Sure it was painful, but the networks are now more secure b/c of it. In my experience, people don't necessarily change b/c it is good for them or b/c it is easy.  They do it b/c there is a dis-incentive to continue the status quo.