<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A different approach is to have Bob's service provider, as specified<br>

in his username, be his keyserver</blockquote><div><br></div><div>One approach I've been wanting to prototype is exploiting DKIM.</div><div><br></div><div>That is, to get someone's public key you just ask them for a short hash via email and then check the DKIM signature on the email you received using e.g. a special client that speaks IMAP, or a browser extension. DNSSEC would give you a chain of trust if implemented, but the email market is concentrated enough that the DKIM keys of most major providers could simply be hard-coded for now and then diverse DNS lookups executed via Tor to convince yourself of the correct DKIM key for smaller providers.</div>
<div><br></div><div>Whilst this can be entirely decentralised if you're willing to send a message like "Hey, can you send me your key?", with a bit more centralisation you can have users register by just sending an email to a key server registration address with your key attached, the key server would verify the DKIM signature on the email and then connect the users public key with their address.</div>
<div><br></div><div>You'd probably want to do what miniLock does and talk about IDs instead of keys though. Like having an instruction that says, "to register with your email address, just put your easyTalk ID in the subject line of an email to <a href="mailto:register@foo.net">register@foo.net</a>".</div>
</div></div></div>