Submind YouTube summaries
Thumbnail for Continuous Key-Signing Party introduction

Continuous Key-Signing Party introduction

Watch on YouTube

Video summary

The presentation by Jonathan McDowell and Gunnar Wolf introduces the concept of a continuous key-signing party within the Debian community, emphasizing that trust in open-source projects like OpenPGP is fundamentally built on a distributed web of identity rather than centralized authority. The speakers draw parallels between trusting software developers who can upload packages as root and trusting strangers with physical keys or browsing history, noting that while we cannot verify everyone personally, we rely on a network of verified individuals to ensure system integrity. This approach shifts the burden of trust from a top-down hierarchy to a peer-to-peer model where identities are cryptographically linked through mutual verification, creating a resilient structure that can withstand the limitations of physical distance and the inability to meet every contributor in person. To facilitate this distributed trust, the talk details practical methods for validating identities during the conference, moving away from reading long strings of hexadecimal fingerprints aloud to instead verifying SHA-256 sums of key lists collectively. The presenters explain that while a signature does not guarantee a person's inherent moral character, it confirms that their actions and identity are consistently linked within the project over time. Participants are encouraged to create personal maps or simple cards listing their names and verified fingerprints, which serve as tangible proof of identity for others. This process allows individuals who cannot travel to still be integrated into the global web of trust through local connections made by those who have been physically vetted at events like DebConf. The session also addresses specific technical workflows and community norms regarding key signing, such as the use of the CAFF program which automates mailing certificates to key owners, though its limitations with modern email configurations are acknowledged. A significant portion of the discussion focuses on the importance of signing other people's keys to establish trust paths not only for oneself but also to reach into other free software ecosystems, like those managed by Linus Torvalds. The speakers clarify that while individuals may have different personal policies regarding how strictly they verify identity—ranging from checking government IDs to relying on long-term familiarity—the goal is to ensure that every signed key belongs to the person standing in front of the signer, thereby preventing malicious actors from contributing anonymously or under false pretenses. Ultimately, the continuous key-signing party aims to transform a potentially chaotic event with long lines into an organic social process where participants mingle throughout the conference to exchange signatures naturally. By setting early expectations that attendees should have their keys printed on badges and be ready to interact with others, the community fosters a culture of active participation rather than passive observation. The talk concludes by reinforcing that this ongoing effort is essential for maintaining the security and reliability of the operating system, ensuring that the web of trust remains strong, interconnected, and capable of adapting to the needs of a global, decentralized development community.
Read the full video transcript
My name is Lee Garrett. I'm the talk master for this talk. Um, next up is Jonathan McDowell and Gunnar Wolf on continuous key signing party introduction. Give them a warm welcome. >> Okay, thanks. Uh, well, so so let's start with this. I guess most of you already have some knowledge about OpenPGP. We will start with some introduction as to what and why and what's the meaning of all this and then we will get into the the the the details of our key signing party. So, it's all a matter of trust. Uh, we are we are a group of people trusted by many people. So, do you trust us, both of us? Would you trust me your house's keys? Would you Would you let me read your browsing history? Okay. But you do. Because if you are Debian user and I guess a slight majority of people in this room qualify as as Debian users, well, you trust us more than what you know. You trust over 1,000 weird people with with your information. Most of us are volunteer and have a very loose affiliation. Each of the people blessed with the with the status of developer can upload arbitrary packages to to Debian and they will be run as root in your computer. So, well, of course, there are many checks in place, but you do trust us a lot. Uh so, every individual that gets this this status as Debian developer or Debian maintainer has a great deal of power. And of course, I I I'm not trying to scare people away from using Debian. I am a nice guy. This guy is a nice guy. Trust me. I I know him for many years. >> [laughter] >> Uh ask ask your neighbors while while watching this talk, "Can I be trusted?" I I can assure you we can be trusted. Yeah. But, well, this is because we are up here and you are we are under your public scrutiny. So, you you have only to repeat the yes this exercise with 1,000 people, slightly over 1,000 people. So, can you trust everybody? Of course, you can't. And well, uh it's 1,200 active developers. Uh we also have maintainers. We also have contributors that have no official status. And we also have all of the authors of of the free software we use day to day. So, it's orders of magnitude more. How can we ensure a trustable operating system that the world depends on? Well, it trust by it starts by trusting somebody. Uh it starts by making an organization be linked together. So, uh when we participate in the project, we do so based on our personal identity or in some [snorts] rendering of our personal identity. Uh but we live in different places in the world. We often don't see each other for very long time. How can you we ensure that we are the people that we're supposed to be? So, how can you be sure that my name is a wolf? Well, maybe the traditional answer would be well, I I am Mexican and and this is the general format. If you come across sign with me, I I I will show you mine. This is the format of of our national ID, our voter card. So, I can show to any security guard in my country uh my my ID and they will trust my identity. But uh I mean, this amounts to centralized trust. People trust our voting registration agency in Mexico. But you don't have a a reason to trust them. So, we we end up doing a game more more like this. We we try to do distributed identity trust where we introduce to each other, where we try to convince each other that our identities are what they what we promise they are. And instead of a top-down uh thing like what we have in HTTPS, we have something more like more like a web of trust where uh uh we don't measure trust from the root to the leaves, but but we measure it between [snorts] any two points that we're interested in. >> You mean to say that these are your operations like >> I I I don't know. >> So, so there's an interesting piece here about um that gives us strong trust and identities and in particular consistent use of identities. Just because keys are signed doesn't mean that the person is inherently a trustworthy person, but it does mean that your actions throughout your activity with the project can be linked back to one individual and a consistently trustworthy set of actions therefore can be trusted. So, if you look at the new member process, that looks at your actions over time and says, you know, have they contributed to the project? Have they been signed in their uploading of packages? Um and the thing that underpins all of that is this web of trust that we have built whereby we can cryptographically link the identities together. And we can start to trust people because they consistently present the same identity. We can verify it's them, but to do that we need to bootstrap the cross-identifying identity thing. So, that's why this key signing party sort of exists to get that signature signature done and strongly connected. You might be as Gunner says, a little bit connected, might be somewhat connected, and you can be strongly connected. And the hope is that we have a strong we build a strong set of connection from this process during the conference. Everyone goes back to where they live and they help spread that connection out to other people as well, right? So, we build strong connections here, which then helps us build strong connections across the world. So, people who aren't lucky enough to be able to travel, people who for some reason or another don't want to travel, still have the opportunity to find someone local to them who is strongly connected who'll be able to link them in to our web of trust to give them that cryptographic identity that we can then build project trust in. Okay. So, we don't have we we ask for a short talk. We're not doing a tutorial. Here we we we can assume we we assume you all created a PGP key pair and took note of the fingerprint it has. Uh may maybe some of you have not. We will talk a little bit a bit about this later. Uh but we are willing to help you create the necessary bits if you approach us during the the conference. And if you're not in a in the listing we will be mentioning, don't worry, you can still play join join the game and and get signatures. Uh the Sorry, this is like forward of me. The canonical the recommended way to to do key signing in in Debian is using the caff program. Uh recently talked with some of you. Caff is a very old program that assumes some things that are not anymore common. Like say it wants to be run on a MTA enabled system. It wants to have a local mail transport agent. But anyway, we can check the details later. Caff is a program that will look at a set of keys that you're willing to sign and will automate the process. Does drives GNU PG to do the key signing, mails the certificates to their key owners. As the name says, it's a certificate authority fire and forget. Uncheck. So, this is the important part of this session. Uh I I published some weeks ago a list of keys and some days ago I like published the final version. It's in the the URL that you can see there. And uh we produced this this printouts that omit the most important parts, but include the names and some checkboxes. So, if you have one of these and if you have uh checked your the the the URL, please let's read this together. But please remember, it's not important that you check the URL printed here. It's important that you check it matches to what you have on your computer. So >> So the the key thing is here that fun not intended. As long as your SHA-256 sum matches what we've got on the screen, then you can be concerned that we're all using the same list of fingerprints, right? So, when you talk to someone, what you do with them is you say, "Did you check the sum?" I mean, are we all talking about the same key file? And did you check your fingerprint was correct in that file? And that saves us all having to read out our fingerprints here, right? What we're doing here is validating that the list we're working from we're all working from the same list. When you talk to someone, you go, "Did you check your fingerprint?" You know there already that they're working from the same list. They tell you they checked the fingerprint. You know you can trust their fingerprint on that page. And it's a short-circuiting instead of us having to read out several hundred hex digits, several thousand hex digits. >> Mhm. But we have to verify. >> We have to verify this. Um please, I hope some people in the room have verified the signature on this file already, and therefore we can do some validation. Do you want to do reading out? >> Well one of the traditional things is that is that we chant this together. >> [laughter] >> Because you can all you can all read it on the screen. You can all look at your files. So, please, recite with me. E 3 2 1 C E 1 D A 7 8 1 D F 7 1 1 6 9 8 2 4 >> B 4 D >> 8 >> D 5 >> 5 2 6 >> 4 >> 3 >> A >> C >> A >> 1 >> D >> 1 >> 6 >> F >> 8 >> 9 >> 0 7 5 >> 1 >> A >> 2 >> C >> E >> B >> 3 >> 4 >> 3 >> C >> 9 2 >> C >> 5 >> B 1 >> 8 >> E >> F >> 9 >> Yay. Okay. And And how are you supposed to use these little pages? Well, oh, and uh if you haven't find your personal map. If you are part of this page, you can find your personal page, your personal map in in the files I prepared. You will see whom are you connected with and who whom you're far farther away from. Uh if you didn't make this, you can make cards like what I'm showing here. Cards or slip of paper. It doesn't have to be formal in any way. Just something that includes your name, as verifiable as you want it, and the the the fingerprint for your for your key. >> The the signing party package will actually print you out a a sheet of sort of little fingerprint slips that have your full key IDs and fingerprints on it if you haven't done already. Sort of print you like, I I several dozen to a pH. >> Well, finally what what why do you do with this? >> So, what we're trying to do is prove identity. How you do that is kind of up to up to you. Um some people will look at government IDs. They will want to see your government ID. They'll want to confirm that your name matches the name on the key. They will use that to sign. Some people will be asked on long-term familiarity. I do not sign keys of people I do not recognize. Um so generally means I have to have met you a couple of times and talked to you. Um we can't really determine that, but what we are requiring you to do is is is be sure that the key you're signing belongs to the person you're talking to. Um you get to have your own policy. We request that you do this in a strong fashion, right? Have some verification rather than just randomly signing with no indication, but if someone doesn't want to sign your key, you shouldn't take it personally, right? It's not a judgment on your ability or you in any way. It's purely a judgment about whether or not they feel they can verify your identity. That's what we're trying to do here, right? Key Key web of trust is verification of identity. Um That run this wouldn't protect against a malicious person with some intent, but it would have meant they had to turn up to a DebConf and they had to interact with people and they had to get signatures and we had some proof of identity that we could track over time. So, it is another piece in the trying to track who's trying to contribute to the project and make sure that we don't have malicious people contributing. >> Yeah, that that's what you already said. There's no one way to do this. I'm not going to ask for his identity. I know him. We We checked and our keys are not cross-signed. So, I will sign his key. I guess that you verify your your fingerprint. >> The other thing I would say about key signatures is it is just as important for you to sign other people's keys as for them to sign you, right? First of all, it'll give you trust paths to other people, right? Once you're in the Debian strong set, you have a trust path to Linus's key for current signatures, for example. There are a whole bunch of other free software projects that do signatures on their packages that you can get a trust path to from the Debian key ring. So, it is in your interest to sign other people's keys so you have that trust path life. Also, it's a good thing to do in terms of building the strength, but don't just try and get signatures. Make sure you sign enough other people to spread that out so that you have trust paths to people. Um >> Yeah, I think that's it. Yay, that's it. So, please we we we try to leave some time for for questions. There's always some some interesting questions around. Please bring them. >> All right. If you have a question, wait for the microphone to come to you so you people on the stream can also hear a question. Um are there any questions? Yes. No. >> [laughter] >> I think I think we were first here. One second. >> Yeah, thanks for the talk. If I just got myself a new email address on my existing key, how important is it that I get my key re-signed? >> Uh generally it's good to have signatures on all of your UIDs. So, I would advise you to go and write talk to people you know at the wireless and get some signatures on it. Especially if you're going to at some point revoke the other ones or might want to get rid of them, then it's better to do it in advance. >> Uh also, if you speak, please stand up so people can see you and uh >> Okay. Hello. First, thanks for organizing this party. I have one question. So, I submitted my key and I'm on the list, but I have one of these Uh, keys which now seems to be the recommended way to have the name in one identity and the email address only without the name in a second identity or UID. And I think the the key you got from me only has my email address and not the name. Uh, so question it's available on the key server. But the question is how to best handle this. I guess I have to tell the people to get the key from the right key server and then sign both UIDs. >> Maybe you mean from from the page that that I prepared. Please blame blame my scripts. The weakest link in all of these are my scripts. I they made several mistakes. I know that some people's keys didn't end up in the in the page and well there are many mistakes. But your key is fine. People will sign One of the issues that you may find with CAFF is that CAFF will send a mail encrypted to each of your identities. And if one identity doesn't have a mail, CAFF will not send a mail to it. >> It No, it actually sends it to the other addresses. >> Oh, okay. >> My name is on the list. That's fine. Just the the key on your webpage if you downloaded it misses >> The key is complete. But the listing I I built it with using scripts that are not that well made. I made them a bit hastily. So there are many cases where my scripts get something's wrong. >> All right. We have time for one more short question. >> All right. So thanks for the talk. Is there some time or place where we can go if we want to sign other people's keys like in a you know >> What What we've moved to is a continuous key signing approach for people then mingle and talk to each other over the course of the conference so that it's rather than sort of a big long line of people. If you notice, people should have keys on the bottom of their badges, so it should be clear to see who else is participating. Um, so the idea is over the course of the week you're free to go up and talk to people with that to sign keys, rather than us having one big event that ends up being quite unwieldy with as many people. That's That's why we do this talk very early on, so that we set that out as an expectation that if you're on the key signing party, people might come up to you and ask for key crossing signatures. >> All right. Uh, that concludes the talk. Uh, give a warm round of applause to Gunnar and Jonathan.