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.