WOT and Authentication Research

[Patrick Baxter]

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.

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.

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.

>
> 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.