[messaging] Identity; was: Thoughts on keyservers
alaric at snell-pym.org.uk
Wed Aug 20 06:00:59 PDT 2014
On 20/08/14 13:16, Ximin Luo wrote:
>> I think that a very important test for "validity" is just "is this the
>> same person as I've seen before", either with the same key or with a
>> signed statement asserting that the new key is also theirs...
> Bindings of the form (actions) -> (key) are harder to bootstrap - current systems would restrict you only to actions that can be signed, such as making comments, commits, files.
> If we bind to real-world identities, we can use our knowledge of real actions performed by them, to build up our view of their reputation more quickly. I'm not sure how to bind these things directly to a key.
Well, if I witness real-world actions, there will presumably be
something I can use to ascertain the identity of the actor. With
real-world actions, this is usually their face, voice, mannerisms, and
things they demonstrate knowledge of.
How to bind that to a key? Well, I see a person on several occasions,
and on those occasions they impress me in some way with a desire to
communicate electronically with them. So I need to ask them for a key
and addresses with which to do so. The fact that I go to the person I
recognise (and it's hard to forge that kind of biometric + shared
knowledge of our history together authenticator) and they give me a key
via a secure channel (such as handing me a business card, assuming the
NSA don't have nanotech robots that will rewrite business cards in my
pocket), in effect "signs" the details on the business card with their
The issues we are worrying about here are the usability issues of that
"key plus address".
I have a business card with an email address, a PGP key ID, and a
fingerprint. Checking that fingerprint is ugly and unpleasant, worth
doing only for cypherpunks who do it for fun, or for somebody who's
about to send me a million pounds or something. But it degrades
gracefully to just ignoring the key stuff and using the email address.
It would be nice if I could just give out the email address, and have a
mechanism for people to get the valid key for that address - by "valid"
I mean the key that I, as the publisher of the email address, wish to
also publish along with it. But I fear that any such reliable means of
key distribution could probably also just be used to send me messages or
authenticate messages as from me in the first place, there's nothing to
bootstrap from. Any way I can prove to a registry that I control an
email address, so it should accept my key<->address mapping to certify,
could just be used directly to authenticate myself to you in the first
place, no? Even if just to send you an ephemeral public key to send me
encrypted messages back.
Perhaps the best bet is to use a namecoin-style blockchain, with
something posted on it saying "The address X is claimed by identity I,
along with a suggestion to use the pubkey P1 to send it encrypted
messages, and that it will sign messages with the pubkeys P2, P3, P4, or
P5", where I is some pubkey used only to sign subsequent updates to the
state of address X. A system that publishes email address -> key
bindings in that way is somewhat vulnerable when somebody who doesn't
use the system hands out their email address, and a baddie then creates
an identity I and posts a claim to have keys for that address in the
chain, and then reads messages that people thought encrypted - which
rather implies that we then need to adopt a new namespace, and publish
my namecoin name on my business card (that software can then use to look
up my email address as a signed property of that name). And have my
plain email address also on the card for graceful degredation purposes.
How is this secure? Only the first identity I to claim a name in the
blockchain will be trusted to make statements about that name (apart
from if I signs an explicit transfer to another identity, or a release
to the next lucky claimint, or fails to sign renewals often enough, or
other such well-defined rules), and when choosing a name, I can attempt
to make a claim then wait and see if my claim gets in before others and
is accepted into the blockchain as per the above rules, and choose
another if not until I succeed. So I can be sure of my claim to a name
before publishing it, and keep it as long as I keep renewing it and
don't transfer or release it, as long as I can keep the private key for
Now, the namecoin folks have standards for this (https://nameid.org/),
but it's hardly widely implemented yet, and there's some hurdles to be
overcome around secure access to a blockchain. But does anybody have a
better basis to start from?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: OpenPGP digital signature
More information about the Messaging