> 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? _______________________________________________ Messaging mailing list Messaging@moderncrypto.org https://moderncrypto.org/mailman/listinfo/messaging
