I know this seems impossible - because proofs need to be "public." But it is possible, just not in the current sense of "proving" your identity on Keybase.
Why this makes sense: This is theoretically similar to the issue of signing keys: When Alice signs Bob's key she indicates that at the time when she signed the key, it belonged to Bob. At some time in the future, it may no longer belong to him - Bob may give it to someone else, or his key may change. By signing someone's key you do not simply say that the key really belongs to the person - you say that it belonged to the person at the time when you signed it.
How it's possible to do in a practical manner: The problem with Keybase "proofs" is that the proof is meant to be public. I.e. it's not enough that Bob says that a Twitter account belongs to him; his public Twitter post makes it possible for anyone to check that he had the ability to sign a message.
It is possible to do with what I will call a "list of private proofs."
Here's how it will work: Alice can tell Keybase that on 7/21/2014, Bob (with the key abcdefg) owned bob@example.com. The proof information will not actually "prove" it whenever anyone asks for the proof (as it is private), but Keybase's system of asking for such proofs will require that all proving take place within its system by asking Bob to send a signed message from his email bob@example.com, encrypted to Alice using her public key. In return, Alice will send a signed message, encrypted with Bob's public key, to Bob. Based on this information Keybase will record that Alice trusts that on 7/21/2014, Bob owned bob@example.com, and Bob trusts that Alice owns alice@example.com.
This is similar to the web of trust model, but for email ownership. In the web of trust model, people sign each others' keys based on private proofs of trust and ownership of keys. I.e. instead of a public proof (the equivalent of posting a signed JPEG of your ID card on Keybase to show that you are a particular person and own the key) you have a series of private proofs (showing that in a private meeting you proved to someone that you are a particular person, and that you own a particular key). Here we have a private proof that you own your email address; people can't check this any time they want but can base their approval of this proof based on whether they trust others - e.g. if they trust the people who trust you. So if Alice posts a "private proof" that Bob owns his email address, and Bob posts a "private proof" that Cathy owns hers, then Alice can trust that Cathy owns her email address.
The definition of "ownership" of an email is that you can send and receive messages from it. If you can send a signed message to another user, that means that the public key is associated with the email. And if you can receive an encrypted message it means that you can receive email at that address.
The way this can work is if Keybase enables a messaging system (see #888, Encrypted email client). When you want to prove your email address, you select another Keybase user who you want to prove that they have their email address. This will begin a process with the end result being that Keybase will keep a list of such "private proofs" that Bob owns bob@example.com and when showing tracking information, it will say the last time email ownership was confirmed.
here's the detailed process:
Alice wants to prove that she owns alice@example.com, and reaches out to Bob at bob@example.com (who she tracks) with the CLI command keybase prove-my-email -to bob (or something like it). Keybase then sends an automatic email to Bob from her email address (using the encrypted email client #888) with a proof: a message signed by Alice and encrypted with Bob's public key so that only Bob can read it. The message will include a copy of the signed & encrypted message as an attachment.
Bob downloads the signed & encrypted message and runs the command keybase prove-email alice proof.txt. This will automatically prove that she owns the email address, and will ask him if he wants to prove his email to Alice. If he says yes, then he will automatically send a signed & encrypted message back to Alice. This task will prove that (a) Bob can receive email at bob@example.com and (b) that Alice can send email from alice@example.com.
Alice receives the email with Bob's signed message encrypted to her, and does the same thing (keybase prove-email bob proof.txt). This proves that (a) Alice can receive email at alice@example.com and (b) Bob can send email from bob@example.com.
Once this is done, Keybase has proof that according to Alice & Bob, both Alice & Bob can send and receive email at their respective addresses - at least at the time that the proof exchange took place.
It might be nice to be able to have web of trust proofs for arbitrary statements (e.g. name on this identity document at this point in time, I wrote this thing, etc) with the normal trust levels.
I know this seems impossible - because proofs need to be "public." But it is possible, just not in the current sense of "proving" your identity on Keybase.
Why this makes sense: This is theoretically similar to the issue of signing keys: When Alice signs Bob's key she indicates that at the time when she signed the key, it belonged to Bob. At some time in the future, it may no longer belong to him - Bob may give it to someone else, or his key may change. By signing someone's key you do not simply say that the key really belongs to the person - you say that it belonged to the person at the time when you signed it.
How it's possible to do in a practical manner: The problem with Keybase "proofs" is that the proof is meant to be public. I.e. it's not enough that Bob says that a Twitter account belongs to him; his public Twitter post makes it possible for anyone to check that he had the ability to sign a message.
It is possible to do with what I will call a "list of private proofs."
Here's how it will work: Alice can tell Keybase that on 7/21/2014, Bob (with the key
abcdefg
) owned bob@example.com. The proof information will not actually "prove" it whenever anyone asks for the proof (as it is private), but Keybase's system of asking for such proofs will require that all proving take place within its system by asking Bob to send a signed message from his email bob@example.com, encrypted to Alice using her public key. In return, Alice will send a signed message, encrypted with Bob's public key, to Bob. Based on this information Keybase will record that Alice trusts that on 7/21/2014, Bob owned bob@example.com, and Bob trusts that Alice owns alice@example.com.This is similar to the web of trust model, but for email ownership. In the web of trust model, people sign each others' keys based on private proofs of trust and ownership of keys. I.e. instead of a public proof (the equivalent of posting a signed JPEG of your ID card on Keybase to show that you are a particular person and own the key) you have a series of private proofs (showing that in a private meeting you proved to someone that you are a particular person, and that you own a particular key). Here we have a private proof that you own your email address; people can't check this any time they want but can base their approval of this proof based on whether they trust others - e.g. if they trust the people who trust you. So if Alice posts a "private proof" that Bob owns his email address, and Bob posts a "private proof" that Cathy owns hers, then Alice can trust that Cathy owns her email address.
The definition of "ownership" of an email is that you can send and receive messages from it. If you can send a signed message to another user, that means that the public key is associated with the email. And if you can receive an encrypted message it means that you can receive email at that address.
The way this can work is if Keybase enables a messaging system (see #888, Encrypted email client). When you want to prove your email address, you select another Keybase user who you want to prove that they have their email address. This will begin a process with the end result being that Keybase will keep a list of such "private proofs" that Bob owns bob@example.com and when showing tracking information, it will say the last time email ownership was confirmed.
here's the detailed process:
keybase prove-my-email -to bob
(or something like it). Keybase then sends an automatic email to Bob from her email address (using the encrypted email client #888) with a proof: a message signed by Alice and encrypted with Bob's public key so that only Bob can read it. The message will include a copy of the signed & encrypted message as an attachment.keybase prove-email alice proof.txt
. This will automatically prove that she owns the email address, and will ask him if he wants to prove his email to Alice. If he says yes, then he will automatically send a signed & encrypted message back to Alice. This task will prove that (a) Bob can receive email at bob@example.com and (b) that Alice can send email from alice@example.com.keybase prove-email bob proof.txt
). This proves that (a) Alice can receive email at alice@example.com and (b) Bob can send email from bob@example.com.Once this is done, Keybase has proof that according to Alice & Bob, both Alice & Bob can send and receive email at their respective addresses - at least at the time that the proof exchange took place.