• BlogNav:
• Archive of all posts

Key Signing and The Identity Problem

Posted: Thu, 24 November 2005 | permalink | No comments

Yet another thread on keyring updates in Debian has gotten me thinking about key signatures, what they really represent, and other associated topics.

For those of you who might not know what I'm talking about, a brief primer.

Before someone can be admitted as a Debian Developer, they have to have an OpenPGP key (practically, a GPG key) signed by a current Debian Developer. That is, someone who is currently a DD has looked at a photo ID, compared the photo to the face offering a key fingerprint, and compared the name on the ID to the name on the key. If they all match, we have a signature. The other qualification for becoming a Developer is going through a process designed to determine whether you have the required competencies. Since this testing process is conducted electronically, not face-to-face, the primary means of identifying the person behind the answers is via the OpenPGP key they used throughout the process.

So, what do we have out of this process? Two things, that I can determine:

• The signature says that someone who Debian already trusts (the current Developer) affirms that the name on the key belongs to someone who has the same name.
• The holder of the relevant key has passed the necessary competence checks. Effectively, the New Maintainer process certifies that a particular key is competent, to all intents and purposes. This is important, because it's that key that gives you all of the "privileges" associated with being a DD -- voting, package upload, etc. Your identity is effectively that key.

So, the problem at issue is this -- what do you do when you lose control of that key? You lose it, or it gets compromised, or it expires (whoops!), or whatever. For all intents and purposes, when you lose control of your key, you no longer have an identity, in Debian terms.

Generating a new key (and hence identity) is straightforward -- a quick invocation of gpg and you're away. Unfortunately, all that gets you is a pile of bits. There's nothing that intrinsically links you to that key. That's what other people's signatures on your key is for.

Then, it comes time to get Debian to accept your new key as belonging to you. This is a lot harder than trying to convince the RTA (DMV.en_AU('New South Wales')) to give you a replacement drivers' licence. Why should it be? You're doing effectively the same thing -- "I am $FIRSTNAME $LASTNAME, give me my (licence | upload privileges)".

The difference is that, in the Debian case, all of our identity is effectively tied up in the key we use to go through NM. The person behind the key is somehow secondary to that whole process. So when the key completes NM, we record it in the "people who can upload" keyring.

When a new key (which is prima facie completely untrusted) should be put into the keyring, we need to ensure that it is qualified. How can that key prove qualification? Well, we can send the new key through NM (dear ghods, no!) or refer to the source document (as it were) -- the human being. We're looking for consistency between the person between the two keys. That's trickier than it looks at first glance.

Why? The big one is the non-uniqueness of $FIRSTNAME $LASTNAME (or even $FIRSTNAME $INITIAL $LASTNAME, for those so blessed). Google for yourself one day, and you'll see what I'm talking about. Anyone who has the same name as you could, at first instance, pretend to be "you" (for some values of, anyway). It might seem fairly unlikely, but there are two DDs with easily-mistakable names, out of a pool of 1,000 or so. The probabilities are not in our favour on this one. Then, of course, there's fake IDs, which are a whole other ballgame.

How does the government get around the problem of name clashes and identity-theft-by-ID? By using other metadata about you to more uniquely identify you. Your date of birth, street address, perhaps even a general physical description -- all of these can help to disambiguate all of the identically named people out there. Debian can't use that, though, since that metadata isn't initially collected, and so it can't be rechecked later.

This does suggest a bit of a solution, though. I said that Debian doesn't collect that info, but that's not entirely true. There is an optional repository of Developer contact details stored for other DDs to access, so we've got something to work from. The Developer updates their own details (whatever they feel comfortable entering). But, of course, people signing your key need to know about all that before they sign the key, so they can check (for example) your residential address and date of birth on your photo ID. You might ask "but how is the info the developer themselves entered accurate?", and that's a good question. The answer is that the legitimate developer entered that info, so if someone with the same name matches that data, then it's reasonable that it's still the same physical person.

It's not a real good solution, though. Not all developers enter full metadata (and I can understand why they don't want to). People also often forget to update their details, too, which could quickly cause all sorts of problems.

What is a good solution, then? We could always go with a bit of biometrics -- if there was any solution that was sufficiently cheap, reliable, and distributed enough to be used to identify 1,000 developers distributed across the globe to a reasonable standard of reliability.

I'll wait for a minute while you finish laughing and wipe your eyes dry.

I have to say, I'm stumped. I'd hoped, while writing this, that by the time I was finished I would have worked something out. But nope, it's a problem that's way beyond me. But I think I've got a much clearer handle on the problem space, so with a bit of luck, my subconscious (or someone else's) will eventually produce a sensible answer.

---