Dick Hardt, founder and now CTO of ActiveState, was prowling around the digital ID conference asking a deceptively simple question: "Why do I need a key pair?"
Those of us who have long assumed that giving people key pairs and certificates is an inevitable and necessary basis for identity-aware computing were, of course, shocked by this naive-sounding question. Dick's not naive by any means, though, and he raises a very serious matter. Let's review the things I can do with my Thawte Freemail Cert:
Sign email.
Assure the bitwise integrity of email.
Encrypt email.
Authenticate to sites and services equipped to read attributes of certs (currently none that I frequent).
Now let's review the fine print:
I have to authenticate to my certificate database to use my private key.
The cert is portable, but not easily. I have retrieved versions of it for Mozilla and MSIE on my desktop PC and my ThinkPad. I tried to do the same on my loaner PowerBook, but the Mozilla cert didn't take, and neither Entourage nor Apple's Mail are cert-aware.
Acquisition of client digital IDs is an obscure procedure that hardly anybody knows about.
Smartcards that will simplify all this are (at least in the US) making little headway.
Passport, Liberty, Shibboleth, and PingID are all examples of cert-agnostic identity providers. You could use a cert to authenticate; equally you could use name/password, biometrics, or something else. So why do people need key pairs? Answer: to do crypto. We can't remember keys, and we can't do crypto in our heads, so we need to store keys somewhere.
Now Dick draws a distinction between my key, issued to me, managed in my certificate database by my software on my device, and a key that lives on a device (phone, PDA, computer) to which I can authenticate. "Crypto happens between machines, not people," notes Dick. If you're going to trust my signature then you already trust some authentication process, namely, my authentication to my cert database. So why not trust my authentication to the device, and accept its keys as a proxy for my keys?
In this scenario, the device's cert presumably tracks to an issuer that other devices could trust, just as we now accept VeriSign-backed websites. How does the device represent the user, and how do users decide whether or not to trust one another? I'm not sure how to solve this equation, but it seems worth thinking about. We have been pushing the boulder up the hill of PKI for a long time, and we're no closer to putting crypto keys into the hands of users than we were a decade ago. Meanwhile identity providers that are not crypto-based -- Passport/Liberty/Shibboleth/PingID -- are proliferating. Users of these kinds of services could, over time, build up reservoirs of trust based on credit history, peer reputation, or other factors.
Because it conflates cryptography with identity and trust, PKI winds up being a real brain-melter. If we can tease these issues apart, maybe we should.
Former URL: http://weblog.infoworld.com/udell/2002/10/13.html#a465