[messaging] Thoughts on keyservers

[Bruce Leidl]

On Tue, Aug 19, 2014 at 8:45 AM, Ximin Luo <infinity0 at pwned.gg> wrote:


> These are not specified in great detail, partly because there are so many ways of doing it, but it is an important part of the system. Often we don't even have an agreed precise *definition* of what it means for the key to be valid. We only have rough definitions, and we try to design auditing and monitoring around this; this is brittle and so we should decide on more precise definitions.

I think there are two philosophies on what constitutes a valid key
certification: (1) You can verify real life identities, or (2) you can
verify email addresses.

The first strategy has been the dominant one culturally for OpenPGP
since the 90s, and often involves going to something called a key
signing party (not actually a party and not to be confused with a key
party!) with your passport and key fingerprint and wandering around
the room looking at other people's documents and collecting their
fingerprints.  I've heard that people have come up with new schemes to
optimize this process so you only have to sit in a chair and listen to
somebody recite hex digits half an hour.   As a reward for
participation in this ritual you are now connected into something
called the 'web of trust' which makes information available allowing
other users to derive metrics on the trustworthiness of your key with
vaguely documented graph path calculations deep inside GnuPG.  I'm not
sure anybody understands precisely how this even works with the
possible exception of Werner Koch, dkg, and a few people writing
academic papers.

I understand the appeal of putting the emphasis on real life identity,
since if you're confident that you have the right public key for a
certain other human then it doesn't really matter where you send
encrypted messages to since the worst that can happen is you send it
to the wrong place but the recipient is unable to read it.

Problems emerge however when you have only an email address from which
you want to bootstrap secure communication because your email client
doesn't care much about legal names printed on passports and even
though everybody includes email addresses in their public key UIDs, no
due diligence was performed on email addresses at the key signing
party so it might not be such a good idea to just let your email
client automagically ask the web of trust for advice about email <-->
public key mappings.  (Yes, I know that after the key party you could
hypothetically encrypt some thing or receive some other signed thing,
but whatever ad hoc verification isn't what actually happened after
the key party)

Now users expect that in order to send email to somebody they haven't
previously corresponded with they are only going to need an email
address.  I think this is a reasonable expectation, especially since
our counter-offer is "Ok, how about an email address AND... 32 random
hexadecimal digits".

So I'm arguing from a usability perspective that in order to build
better tools so that Johnny can finally encrypt and get on with his
life, the important definition of key validity needs to be (only)
about authenticating the relationship between a public key and an
email address.  If you accept this assumption, then that quickly
narrows down the options available in order to accomplish this task
and makes it easier to reason about how strong the security guarantees
are of a system that proposes to deliver 'valid' keys to users.


--brl