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.
