[messaging] Thoughts on keyservers

[Michael Rogers]

Sorry for the broken formatting, writing this on my phone...

> 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 

This is secure only to the extent that you trust the channel by which you obtained the blog posts. Anyone could take those posts, strip off the author's signatures and sign them with another key in order to receive replies intended for the author.

> 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.

Same problem here.

Cheers,
Michael

Alaric Snell-Pym <alaric at snell-pym.org.uk> wrote:

>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/
>
>
>_______________________________________________
>Messaging mailing list
>Messaging at moderncrypto.org
>https://moderncrypto.org/mailman/listinfo/messaging