WOT and Authentication Research

Melvin Carvalho melvincarvalho at gmail.com
Thu Dec 6 14:40:18 CET 2012


On 5 December 2012 23:15, Patrick Baxter <patch at cs.ucsb.edu> wrote:

> On Tue, Dec 4, 2012 at 5:29 AM, Melvin Carvalho
> <melvincarvalho at gmail.com> wrote:
> >
> > Not sure I've grokked everything in this thread, but some thoughts.
> >
> I'm working on the TL;DR version :).
>
> > Tying a key to a 'domain' (aka URI) is something that can be done already
> > using linked data.
> >
> > I do so on my home page already:
> >
> > http://melvincarvalho.com/
> >
> > This contains my GPG key, fingerprint, hex_id, modulus and exponent.
> >
> > Here is the data view of the same page:
> >
> >
> http://graphite.ecs.soton.ac.uk/browser/?uri=http%3A%2F%2Fmelvincarvalho.com%2F
>
> I'm not sure I understand what it is that ties your key to the domain.
>
> So, for example, you know your public key and it that it is the proper
> public key for your website. However, from an outsider's perspective,
> anyone could publish a signature and claim ownership of your domain.
> If they control the network path to a user first looking at your
> webpage, then there is no consensus on which public key will get you
> MITM'd and which is your actual key if they choose to present a
> different one. You add strength by making it available on your
> website, but it only goes so far.
>

The domain is tied to the information via DNS, which is the main web
paradigm.  Semantic tags let you make assertions in machine readable form.

Yes, in theory I could add an SSL cert to my homepage, though I havent paid
for one yes.

There's a theoretical attack from MITM, but this is the case for much of
the web.

I'm working on something that can provide extra strength by recording your
public keys over time:

http://publickey.info/

But I havent really had time to maintain it yet.


>
> My general idea is somewhat encompassing of the Sovereign Keys idea,
> but thats just part of the solution. Generally, I'd argue, you want a
> keysever infrastructure similar to the EFF's soverign keys that
> establish's a known single mapping. It widely distributes the public
> keys to that keyserver with software so that you have a secure
> connection into that data from the start. Now, you have to balance the
> needs of updating this mapping with the security of the
> infrastructure. There is lots of ways to capture meaningful data on
> validity and I'm for using as many ways as possible such that it still
> makes sense. Also, keeping a database of personally validated keys is
> still massively useful for things like email, phone, and chat. It can
> be used in conjunction with a better key server infrastructure to
> minimize the trust you place on it.
>

I need to read up on sovereign keys a bit more.  Has there been any serious
critiques of it yet?


>
> You could probably also argue that the less authority a key-server
> infrastructure has, the more resistant it is to corruption. This lends
> strength to trying to not entirely relying on it even if it is
> distributed and replicated.
>
> Now, the idea is that with this infrastructure you are restricted to
> how you learn about new keys. So an active attacker on your network
> connection will not find it so trivial present an fake key to users
> that are connecting for the first time.
>
> > Scroll down to see the PKI fields.
> >
> > I can use this key to sign and encrypt mail, for s/MIME as an x.509
> > certificate, to login via ssh and also encrypted chat on retroshare
> >
> > I also have links to other people storing keys in a kind of web of trust.
> >
> > What you call the WOT is really a Graph of Trust (GOT) or Network of
> Trust
> > (NOT) in so far as the Web is normally loosely associated with HTTP.
>
> Maybe, I'm confusing the issue by trying to tie too many things
> together, but the I think the problems all have a lot of fundamental
> things in common.
>
> Also, If a user can link to you through a WOT, then they have that
> initial validity that creates a much strong authentication and don't
> have to trust the first key servered over the network. I think there
> is a ton more potential for more effectively using WOT paths to
> establish validity as well.
>

Yes, trust should be additive, rather than one WOT to rule them all.
There's no perfect trust system, but you can do things to increase the
confidence interval.  You can generate a lot of functionality with limited
trust too.  The thing I dont like is when trust creates a barrier to entry
that does NOT allow you to do things.  Users should have freedom to choose,
imho.


>
> >
> > I think in terms of accessibility and usability we need a GPG equivalent
> of
> > what "hotmail" did to email.  This is what we call "webizing".  Then
> people
> > can make relations, sign and encrypt, over the web just as easily as
> they do
> > with desktop clients.  Obviously a huge task and the crypto in the
> browser
> > group will help.
>
> Definitely a massive undertaking and I think the most relevant problem
> to the world of crypto. It is getting better and more transparent (OTR
> ect.) and I think one of the last difficult tasks is making it easy
> for users with little knowledge to not only use crypto, but also be
> strongly authenticated. Its not terribly difficult to make an app that
> opportunistically establishes encryption, how do we make the user
> capture strong validity by default? I think, its in the form of better
> keyservers (users might need a little initial work to establish their
> key and prove they own their email for example) and signing keys
> automatically when you determine you have captured some sort of
> validity on that key (See ZRTP's authentication or the social
> millionaire protocol for OTR).
>
> And of course the last issue is finding a sane way for user's to store
> and use private keys. Hence the PSST project and the eventual idea of
> PGP smart card type computing devices.
>

I was at TPAC a couple of months ago and Mozilla did an impressive demo of
crypto in the browser to generate keys and encrypt/decrypt.  The W3C Crypto
working group will hopefully provide some great API for those that wish to
work with the web and with PKI.  I think in this way it may be possible to
scale the great features of GPG to a wider audience.  But as I say, most
groups are lite on resources, so it takes 1-2 people to make theory a
reality...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20121206/6c94ee9c/attachment.htm>


More information about the Gnupg-users mailing list