[guardian-dev] WOT and Authentication Research

Hans-Christoph Steiner hans at guardianproject.info
Thu Jan 17 13:46:46 EST 2013



On 01/16/2013 09:04 PM, Patrick Baxter wrote:
> Hi Hans,
> 
> Thanks for jumping in on this. Keeping this short:
> 
>> I think its possible to use the WOT without publishing your social graph
>> publicly.  The keyservers can be used only for keys and revokation, then
>> people can exchange local signatures in a p2p fashion without ever publishing
>> them to keyservers.  This is very hard to do right now, but it is something
>> that can definitely be automated and with little user interaction needed.  I
>> hope to work on this as part of PSST this year.
> 
> I still think the benefits of publishing signatures outweighs the
> anonymity problems. Its a very debatable point though so I think a
> solution to this would be to allow the owner of the key to set a flag
> that would allow or disallow other people to publish signatures of
> their own key. People could only upload signatures for user's that
> have allowed it.

> If publishing signatures was distributed, what would be the method to
> determine who you share you signatures with? Once you share, whats to
> stop it from being re-shared? With a keyserver keeping record, I would
> think its easier to respect privacy in the matter of publishing
> signatures.

Whether its a worthwhile exchange to publish signatures publically depends a
lot on what the repercussions are.  For me personally, it is clear that the
benefits outweigh the loss of privacy because it is quite unlikely that my
government or anyone else will torture or kill people in my web of trust.  In
places like Syria right now, its a very different equation, so there needs to
be some flexibiliy.

I could see three "modes" related to this:

* paranoid: always use lsign, only exchange signatures face to face, no
exchange of signatures other than my own
* peer-to-peer: never export signatures to the keyservers, exchange all
signatures I know about when I meet face-to-face
* keyserver: export everything to the keyservers

Ideally, this mode would be tagged in the signature itself so when a
'paranoid' exchanges signatures with a 'keyserver' all signatures involving
the 'paranoid' do not get uploaded to the keyserver, and so on and so forth.
I suppose that if the peer-to-peer mode works well, then nobody should really
use the keyserver.

>> There is a lot there, I'm wondering if you've condensed what
>> you're particular questions are since then?
> 
> I'm focusing more on the advantages of having a single (but
> decentralized) key-server that is a framework for providing a useful
> mapping for any domain. So a server that allows only a single mapping
> to exist for each UID of a domain. Allows signatures (with privacy),
> requires proofs of control to initially establish a name, and has a
> flexible way for dealing with failures (so it is accessible). I think
> some remaining questions would be how to look as this from the user's
> perspective (independently authenticated > independent WOT path >
> exists on server that I sort of trust and have a pinned https
> connection too) and how to establish account control among failures
> (losing keys, losing account access, dos signups).

Why do you want to push verification to the keyserver?  I suppose it could
provide another channel of authenticity data for bootstrapping.  But it seems
once you've verified the fingerprint and its connection to a UID, then you
don't need the keyserver to verify anything.  That keeps the keyserver simple.

>> As a kind of aside, I think that the Zooko's triangle analogy is not very
>> good.  It does not map the problem very well because it portrays the three
>> elements as equally affected by each other, when I think that's clearly not
>> the case
> 
> Good point. Also, I think by decentralized he might mean having
> namespaces with unique identifiers. I think that's achievable in a
> decentralized system. So, I wouldn't look into that analogy of the
> triangle much more myself :)
> 

UUIDs seem to work pretty well for being "universally unique" and totally
decentralized. :)

.hc


More information about the Guardian-dev mailing list