[messaging] Thoughts on keyservers

[Alaric Snell-Pym]

On 19/08/14 13:45, Ximin Luo wrote:

> For example, for web servers, "key validity" means roughly, the owner
> of the key is the same entity that controls the DNS name on the cert.
> For PGP email UIDs, it means the entity can send to/from the email
> address. For PGP name UIDs, it's a rabbithole. Actually the first two
> are also rabbitholes, but I'll keep it short here. Overall however,
> this is not a cryptographic problem, but a logistical one. 

Let's take a stab at it, avoiding the rabbit hole of "What does a name
mean?" :-)

Perhaps it's pragmatic to define an identity in terms of control. I
should be able to create an identity that, in some sense, I control;
others can't sign things as that identity, only I can read things meant
only for reading by that identity, only I can perform actions on the
property of others that have been granted to that identity, etc (which
boils down to the power of signing on an untrusted network, but more
tightly-controlled local systems may have other means of principal
identification), etc.

Now, much is spoken about "I want to email Bob. How can I be sure this
is really Bob's public key?", but I think that's a slightly confused
question, as it avoids the issue of "What do I mean by 'Bob' anyway?",
and tends to lead one astray into worrying about how to have a namespace
where 'Bob' can be claimed and all that.

Why do I want to email Bob?

A) If I know Bob in real life, and want to be able to email him while
he's away, then I can ask the real-life Bob to give me his pubkey in a
situation where I trust the channel. Much key-management nomenclature
seems to come from this case - our model of 'Bob' is a real person I
know face-to-face. But little key exchange happens this way.

B) If I know Bob as somebody who writes really cool blog posts about
something interesting, so whose opinion I value and want to solicit,
then "Bob" is really just my petname for this identity. What I really
care about is that my message is only readable by the author of those
posts. Seeing what key has signed those posts and then using that to
encrypt a message and then checking the signature on the reply is what I
need (modulo some chains of signature authentication for different
signing/encrypting keys and all that, which I'll elide for brevity). For
instance, I pgp-sign posts here, and the fact that my posts are all
signed by the same key is probably a better assertion of my identity to
readers of this list than the name or email address I put on my key.

C) If I know Bob as somebody who emailled in a bomb threat, and then a
bomb goes off as described, and then I get another bomb threat signed by
the same key, then I can associate this new threat with somebody who
seems to have demonstrated the ability to pull off a bombing.

D) If I am introduced to Bob through a friend, then they send me some
statement (hopefully over a trusted channel, or signed, etc) that there
is this person who has certain attributes of interest to me (potential
employee, potential dating material, etc), and that they have a certain
pubkey. The fact that their name is Bob will probably be mentioned, but
not be largely relevant; what matters here is my friend's assertion that
the holder of a given pubkey has certain attributes.

E) If I see ads on the sides of busses and on TV saying that Foo is an
awesome bit of software that will make my computer do cool stuff, and I
then download some software claiming to be Foo, I'd like to be able to
check that the pubkey which signed it is really one issued by the one
and only FooCorp. This is the case we probably most want to solve, but
is quite remote from case (A) - we have no existing personal
relationship with FooCorp - despite the language of case (A) often being
employed in discussing it. We need some kind of consensus as to what
pubkey FooCorp holds, either enforced by some rules (central registry,
who-got-there-first-in-a-blockchain) or by some means that allow people
(including FooCorp themselves, as a motivated actor) to spot and repair
naughtiness (a bunch of keyservers that maintain a history of claims to
a name so usurpation is audited, and FooCorp has some means of fighting
to defend its name from motivated attackers, etc). This is interesting
stuff. Personally, I've yet to see a better mechanism than blockchains
for this. Can anyone improve on that?

So, to conclude, I think that in many cases, we want to assign pubkeys
to pseudonymous identities defined largely by reputation - other actions
that identity has done in the past. Even case (A) is like this; I have
this idea of "Bob" based on knowing a real-world person, and I
authenticate that identity by recognising their face and voice and
mannerisms and knowledge of shared history, and when they hand me their
pubkey in person that's just as good as seeing it signed by a key I
already trust to make that claim; I'm just chaining trust from one
identity checking mechanism to another, and the root identity is one I
have established via their past actions. Whether or not their nickname
and/or legal name is Bob is largely irrelevant to that.

But when it all gets hairy is when we don't have this establishment of
an identity by their past deeds and a means of asserting that all those
deeds came from the same identity; case (E).

ABS

-- 
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140819/4f2510bb/attachment.sig>