I agree that emulating Web PKI might not fit this situation, but that's because I'm not sure I fully understand the need for any PKI for human-to-human messaging. I don't need to be able to authenticate everyone out there, just the people I want to communicate with.
This whole situation seems pretty similar to dealing with phone numbers. Back before programmable phones, the phone book basically acted as a the central PKI for numbers, and you would go look up someone's number if you wanted to call them. However, once we had programmable phones and started maintaining our own contact lists, we found that we didn't really need the phone book anymore. Sure, it's now a bit more inconvenient to not be able to look up someone's number if you don't already have it, but I guess we compensate for that now by being sure to get the phone number at first contact or getting it through a friend of a friend. Either way, phone number authentication is now much more of a social interaction than it used to be, which I take to mean that as a society we deem social authentication as better than centralized authentication. Another example of no-PKI authentication is SSH. Every time you try to ssh into a new server, by default, you see the message: The authenticity of host 'example.com (192.168.1.2)' can't be established. ECDSA key fingerprint is 12:34:56:78:90:ab:cd:ef:12:34:56:78:90:ab:cd:ef. Are you sure you want to continue connecting (yes/no)? You usually accept it because you have context for the situation. Your boss probably gave you the address, or you got the address from the list of instances on AWS, or whatever other interaction lead you to try and connect with that server in the first place. You didn't need to verify the authenticity with some other party because you have context. PKI, for me, serves the purpose of providing authentication without prior context (hence why it's needed in Web PKI). However, in human-to-human messaging, there's almost always prior context, so I don't really see the need to force a standardized PKI. Daniel On Tue, Aug 19, 2014 at 3:27 AM, Trevor Perrin <[email protected]> wrote: > One theme in the keyserver discussion is seeking analogies with the > Web PKI, or trying to adapt ideas from it (like CT). But the Web PKI > evolved under performance constraints that are very different from > "user key lookup", so we should be careful. > > In particular, for latency and reliability reasons browsers don't want > to perform extra lookups during an SSL handshake. So the browser has > to verify the server's certificate without another source of > information, which means the certificate has to be endorsed by an > authority the browser already knows about. This dictates the > centralized nature of the CA system and CT. > > But user key lookup is a rarer operation than visiting a web page, so > can take more time. So it might be OK if Alice looks up Bob's key > however she wants: central directory, Bob's provider, various key > servers she trusts for different reasons, an aggregator, or some > combination. > > There may still be reasons to prefer a centralized system, or to use > it in conjunction with other options. But I think that needs to be > justified on better grounds than "it worked for the web", and also > taking consideration the risks of centralization Moxie's written > about: > > http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/ > > > Trevor > _______________________________________________ > Messaging mailing list > [email protected] > https://moderncrypto.org/mailman/listinfo/messaging _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
