[messaging] Looking up public keys on public sites (was Re: Keybase Chat)

[Jack O'Connor]

> On the other hand, the discovery work for finding a
> pinned Tweet with special text (or a specially-named gist, or a
> well-known URL on a website) seems manageable.

Yes a pinned tweet could work, or maybe adding something to your
Twitter bio. On HackerNews that's actually what we require you to do,
since there's no equivalent of the the KeybaseProofs subreddit there.
The main reason to prefer regular tweets and Facebook posts when we
can do them, is that those sites have good support for 3rd parties
asking you to post things, and we can give people a relatively easy
proof flow even on mobile. For less-well-supported places to put text,
even if we link people to just the right section of their Facebook
profile, step-by-step instructions like "copy this, hover here, click
the edit button, ..." are a drag by comparison.

> If the "identity proof" was just a public key fingerprint, Alice could
> still use that key to sign other public keys, right, and publish those
> signatures to Keybase?

Yes that could work. I guess on the Keybase side things might be
exactly the same, a chain of signed statements that include all the
same associated data. The main difference would be that the 3rd party
proof wouldn't be explicitly bound to those statements, but instead
could be usable with any such chain (maybe across entirely different
apps) that included signatures by the right private key.

The main downside I can think of is the attack I mentioned above,
where Bob steals Alice's key and uses it to make it look like his
Keybase account owns her Facebook account, without actually needing to
compromise anything on the Facebook side. With the proof bound to a
specific account, that attack doesn't work, though maybe it's
unrealistic to think Bob would get Alice's keys without getting her
browser cookies too. There might be a scarier version of this attack
where a large set of PGP private keys all get cracked at the same
time, and any fingerprint-only assertions referring to those keys
become widely exploitable.

Right now we also think about the various sequence numbers embedded in
proofs as an extra constraint on the server to prevent rollback
attacks. We'd lose that if proofs were just fingerprints. But maybe
that's redundant anyway once our clients start checking the
blockchain, or something else public/trustworthy?

It would also change our story around account reset and delete. Right
now proofs are tied not just to your account name, but also to your
"eldest key", which changes during an account reset and invalidates
old proofs. Without that assertion, a proof could still be valid
across account resets, if the key gets reused. (Unlikely with NaCl
keys, which users don't usually handle themselves, but likely with PGP
keys.) That might mean we need to tell users something like "yes
you've really deleted your Keybase account forever _but_ you might
still need to go take down the following posts just in case." Though
it could potentially make some "I forgot my password" reset scenarios
more convenient too.

I'm curious whether you're thinking about some kind of open standard
for key assertions across apps? What do you have in mind?