Re: Keysigning via Video Conferencing

On Thu, Jun 23, 2016 at 9:28 AM, Lars Wirzenius <liw@liw.fi> wrote:

On Thu, Jun 23, 2016 at 09:23:07AM -0700, Nikolaus Rath wrote:
> As I said in my other email, I am wondering if the extra burden is worth
> the gain in security.

Is there an extra burden? Seems to me that it'd happen naturally if
you contribute to Debian and as part of that interact with other
Debian people.

I would consider this an extra burden, yes. I've been playing with Linux for over a decade, have many DD's that know me by IRC handle, email address, and nothing else; a face to face meeting has never happened organically. The one time in my life I found a DD to sign my key, I had to schedule a time where work conveniently had me within an hour drive (one way) of that person. I would, personally, consider having an established relationship with someone you can recognize the face of because of face-to-face meetings as a bonus. It would allow you to feel comfortable verifying identity over a video conference. Just a bonus, though, I wouldn't ever make that my requirement.

What is it we're really trying to protect against? Signing a key doesn't mean you trust that person's work, it means you trust that person is who they say they are. We want to prevent an evil doer from getting a key into the keyring by pretending to be someone else. We have a completely different process for establishing trust of a persons work and that's all outlined in the DM/DD application process. Our face-to-face meeting and chat is a way to see if their government says they are who they claim to be.

Obviously, documents can be forged. You can ask what forms of ID they'll be bringing and use the search-o-matic to figure out signs of a counterfeit, but almost nobody is going to have the equipment to fully check every type of ID. Verifying a legal identity by means that are good enough for other organizations is only the first step in our identification process. Next up, we take the piece of paper home and start our own extended verification process (typos, existing work, etc.) followed by sending that encrypted signature back to the user via email (an address you should have verified has no typos) where the user needs to decrypt with their private key.

I believe there's a document out there called Trusting Trust which discusses drawing a line between what is and is not practical. We trust C developers to not create bugs that introduce authentication back-doors during future builds. Why? Because, even if we /could/ read through the C source and review everything that's changing, we're still not going to catch everything for the same reason that bugs exist in the first place. Heck, we can't keep bugs out of our applications written in C even assuming C itself is entirely bug free.

The point I'm attempting to make is that it's not practical to check every anti-forgery feature of every document. It's not (always) practical to verify an identity based on a long history of in-person interactions. Meeting someone, checking the features that don't require special equipment, having a chat with them, verifying no typos exist, and looking at existing work signed by that key, and sending an encrypted signature to that address is what we have decided is practical.

Is this not why we require DD signatures in the first place? We're trusting that all DD's have put in enough effort to ensure the identity of every key they've signed. Kinda like being an op in a #debian* IRC channel; you're automatically held to a higher standard when accepting the role. I feel like the established policies do a good job of meeting in the middle of the two extremes that have been discussed. We're trusting all DD's to follow the policies that have been decided on as the practical line. If a few DD's choose to adhere to a higher standard, so-be-it, but a lower standard should be avoided. I know DD's that trust something signed with my key is me. None of them will sign my key because they've never met me. It would be concerning if they were willing to because it reduces the overall integrity of the Debian project.

Somewhere, I saw it mentioned that you should be able to verify based on history only and their legal name doesn't matter. I don't entirely disagree. The chances of the NSA building a super computer to contribute to Debian, become a DD, and add backdoors into unwatched packages are pretty low. However, this does create hurdles for someone that has left the project under poor circumstances to build a new identity that they use to harm the project. It's also comforting to imagine every DD/DM is real person, just like the rest of us, and is the person they claim to be.

tl;dr -- +1 existing policies :)