[messaging] Thoughts on keyservers

[Tom Ritter]

Oooooh Keyservers!  Fun topic.  I have a lot of seperate thoughts on
this, none of which relate to the massive leak of social graph
information ;)


First off, I think Trevor started off by pointing out the most common
situation one uses a keyserver for: I have an email address, and I
want to get the key associated to that address.  I start with
bob at example.com, not 'Bob Jones' which is a much harder problem.
Email addresses are unique and that greatly simplifies things.



(Like Trevor said) example.com is authoritative for that email, so
anything that shows that [whatever] is a key for bob, coming from
example.com, is trustworthy for _most_ definitions of 'trustworthy'.

[Implement Me] And since there happens to be a global PKI heirarchy,
why can't I stick a DNSSEC chain into my OpenPGP signature, and let
people validate my key that way?

Likewise, email-based verification systems (like some sort of
auto-responder) put a slightly different spin on this by asserting
that someone who can receive and send email at this email address
serts this key.  That's also trustworthy for _most_ definitions of
trustworthy.  But auto-responders require infrastructure, let's
outsource this - the PGP Global Directory, Bruce's Nyms, and
Keybase.io.  They all verify that a key corresponds to an email, and
if you trust the certifier OR you trust the user-to-provider and
provider-to-provider link encryption that's good enough.

If you don't trust certifier A, you need a certifier you do trust both
technically (e.g. Google) and ideologically (e.g. the EFF, ACLU, or
just Trevor Perrin) or you need a collective of certifiers you do
trust thus-wise, as well as not to collaborate or hack each other.
That's more or less Nyms, I think. How those certifiers communicate
their certification is infrastructure.  And it could work with our
existing infrastructure. If they agreed with me :-p
https://github.com/keybase/keybase-issues/issues/900

[Implement Me] Someone should go take Keybase.io's code, and modify it
to sign keys and publish to the Web of Trust if that's they keyowner's
desire.




On 18 August 2014 02:09, Trevor Perrin <trevp at trevp.net> wrote:
>  * Query a "central authority" where everyone registers their public
> key.  To mitigate availability and monopoly risk there could be
> several such authorities, and users just have to register with one.
> But multiple authorities increases the risk of "misissuance", and
> mitigating that risk is difficult.

A central authority can't act maliciously if it doesn't act with any
intelligence or verification at all.  And thus we have the SKS
keyservers.

> But there's still a coordination problem - what if Bob registers his
> key someplace, and Alice checks somewhere else?  It's unclear how this
> would play out at scale - fragment into islands? centralize around one
> authority?

What we have is a network of linked keyservers who replicate each
other.  They're all interconnected for the benefit and disadvantage.





> Or maybe keyservers could be made more trustworthy via auditing.  If
> keyservers support lookup over Tor then it's hard for them to deliver
> targeted wrong answers.  Keyservers could also support "transparency"
> similar to CT, e.g. periodically snapshot their directory so that
> 3rd-party monitors can fetch the delta of new/deleted entries.  These
> monitors could notify Bob if his key changes, and send Alice a root
> hash that she uses to check that keyserver responses have been
> published [1].

[Implement Me] One can very easily make CT for keyservers today, by
running a keyserver, adding to the SKS pool, and then adding a
function on _top_ of it to publish things in a CT-style way.




Or blockchain.  (AIUI) The idea of using the blockchain is
more-or-less the same as EFF's Sovereign Keys: first come first serve
to an identifier (like 'greg') and that maps to a key.  Its strength
is its weakness: it's irrevocable. With Nyms/Keybase, I can't revoke a
PGP key I lose my key & revocation certificate for, but I can make a
new key that can be certified by some authority(ies), and my old key
loses its certification.   In namecoin, would I not need a new
identifier?  And since we're starting with an email address, a new
identifier is waaaaaaay more painful.  And, since we start with an
email address, you'd want your identifier in namecoin to be your email
address, which you either leave open to landgrab (terrible idea) or
you need _some sort of email certifier that operates outside the
blockchain_.

Sovereign Keys made an attempt to be namecoin for companies (not just
crypto-anarchists debating mesh communication fabrics). It piled on
the hacks to do so, and still wasn't feasible. And that's not even
counting the fact that to 'run this securely' I need a copy of the
blockchain.  I've been really impressed by the effort you've put into
DNSChain, Greg, and I may have gotten some details wrong - but I'm
still not sold on its feasibly.

-tom