Fixing the broken GPG and HTTPS (X509) trust models with Simple Public Key Infrastructure (SPKI)

nymble at gmail.com nymble at gmail.com
Tue Jun 30 02:15:22 PDT 2015


> 
> Telehash
> Enter Telehash, an encrypted network stack in which you route messages directly to a public key. The code is pretty simple
Interesting, not seen this before … currently working on something similar with hashing keys for identifiers.  This is largely for the ‘bootstraping’ of devices.

> 
> expect(mesh).to.be.an('object');
> mesh.receive(new Buffer("208cb2d0532f74acae82","hex"), pipe);
> 
> The cryptographic key is the routing address. So now we only have to accomplish one level of indirection: person to key.
> 
> Something old, something new, something borrowed, something blue. Enter SPKI and our old friend, the Granovetter diagram.
> 
> SPKI and trust in networks, not webs
> Simple Public Key Infrastructure is what we should have deployed instead of X509/HTTPS and the GPG web of trust. There are two critical differences between SPKI and X509/GPG. They are:
> 
> 1) SPKI gives users the ability to certify facts about other users, for example “bob is allowed to use my computer” can be expressed in a machine-readable fashion (s-expressions.) This lets users build their own trust architectures on an ad-hoc basis.
Glad to see SPKI brought up … but I’m partial to it’s partner SDSI intro text.  SDSI/SPKI are a very good solution that gets over the notion of ‘names’ as identity and defines a ‘key centric’ naming.  It inverts the model that a naming authority binds a unique name to a key, to a unique key being bound to possible non-unique names.

That said - SDSI/SPKI has not been adopted for some good reasons … it has some issues.  The delegation lacks adiquate constraint limitations. S-expressions really are not stylisitically a viable protocol in this decade.  These are fixable issues and worthy of more exploration …

> 
> 2) SPKI allows anybody to chain certificates of this type (“fred says that bob says that vinay says that bob is allowed to use his computer.”) This ability removes the centrality of the CA: anybody that I trust can give me a certificate stating “this is the key for amazon.com” and because of certificate chaining, I can see the line of authority down which that key passed.
> ...
> 
> For ease, let’s consider realtime chat in the first instance – just pushing messages down telehash sockets. The only question we have to answer is which telehash socket corresponds to which person.
> 
> 1) person = key
> there’s no way to break the binding between a person and a key, because a person is a key, or multiple keys.
Wrong abstraction … a key may or may not be controlled by a person.

> 
> 2) delivery = key
> this is what we get from telehash – I don’t need to worry about how I’m sending you the message, it’s right there.
Privacy issues here …  discovey and identity need to be separate.

> 
> So I obtain a key for a friend of mine by, say, email. Once I’ve connected to them, I can then ask them to send me keys for our mutual friends.
> 
> 3) keys carry the chain of referrers
> “alice says this is her key”
> “bob says that alice says that this is her key”
Names are not the optimal construct… what does this mean to someone who does not know alice or perhaps knows several alice’s.  The names are a cute handle in SPKI, but lack notions of binding to other attributes (like a person or device).

> “fred says that bob says that alice says that this is her key”
> 
> 
...
> 
> Basically you get a decentralized social network with secure chat pretty much out of the box, where “friending” somebody acquires their key, and the referral network through which keys propagate is a key social dynamic. This can work.

Yes … it could.

> 
> 

Paul





More information about the cypherpunks mailing list