Practice Cryptography!

There's a set of assumptions that the classic identity model makes, but fails to disclose... and these assumptions are perhaps fatal.

1) If you have interacted with a name, you are interacting with the same person when you meet that name again.

This is problematic for several reasons, not the least of which is the lack of a completely unique identifier per-person. (Let's try this example: C=US/ST=Arizona/CI=Tucson/CN=Rodriguez/CN=Jose ... or would that be CN=Jose Rodriguez? Or what syntax should be used here? I don't know... but I do know that given the ethnic population of Tucson, it's very likely that there is more than 1 who would match that name.) Say you have a service where you provide information about goings-on in a specific part of town. One Jose Rodriguez logs in, sets up his profile to point to the northwest (his wife likes shopping at the mall up there, so he wants to get offers from them -- she spends an arm and a leg anyway, might as well give her some coupons to cut down on the financial outlay). Then, another one logs in, wanting to know about the goings-on of the neighborhood revitalization committee of the southwest. He sees that he's already (somehow) set up in the system with completely bogus information.

How to solve this? Well, we could always use the E= qualifier -- email address. But, that goes to prove that there's a problem which can't be easily dealt with. Say the same Jose Rodriguez has five different email accounts, and he gets certificates with them all separately. He decides he's going to sign up for a freebies list five times -- get five different free dinners at a local restaurant. And there'd be no way to know that he's ripping the restaurant off.

It's actually impossible to come up with any specific means of verifying that one party hasn't interacted with another party when only digital signatures are involved. (The other way would be for mandatory unique identifiers -- like driver's license numbers, or serial numbers, or whathaveyou that are embedded into the certificates -- but there are privacy concerns there as well. Several states have laws on the books preventing the information on ID cards or driver's licenses from being collected and used -- including their ID numbers.)

So, the thing is, digital certificates are a strong form of authentication -- but they're a two-factor form that effectively equals only one factor (something you have). Another thing would be a username (something you know), or a hash of a thumbprint or retina scan (something you are). Of these, usernames (or user IDs) seem to be the best idea -- identify what credentials you're trying to use to access whatever resources you want to use.

But why can't these be embedded into the certificates, too?

The main thing here is to realize that there's no way to verify that you're dealing with someone new... and in the current "tightly-bound" system, there's no way to verify that you're dealing with someone old, either.

That is where "context" comes into play... but even still, that solves only one half of the problem: you know that the person you're dealing with is the same one you dealt with before... but you can't know that a new identity doesn't belong to a person that you've dealt with before. This is an example of something that cryptography CAN'T guarantee, and it's something that system designers have to be aware of.