[messaging] Thoughts on keyservers

[Ximin Luo]

On 19/08/14 19:07, Bruce Leidl wrote:
> 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.
> 
> [..]
> 
> 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)
> 

This can be automated though, just like you're doing with Nyms. It might be harder to make these tools "the standard" that everyone uses, but I think in the long run that would carry a big benefit, and it would work.

As mentioned elsewhere, when you don't bind to a real identity, there is likely someone that can mess with this binding. For example, how do you deal with the case where my email provider turns rogue and starts to MITM my email? (This is made even easier, if they are treated as "the place to go" for my key, as under some of these proposals.)

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

I recognise the value in providing easier-to-use binding systems that don't achieve full key validity (binding against a real-world identity). However, I don't think it's good to fudge the issue. Why not be precise? That is, acknowledge that this system only "goes so far" in the push towards full key validity, and *provide the option* to do physical verification if the user wants to?

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

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