WOT and Authentication Research
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:
> 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
I'm working on something that can provide extra strength by recording your
public keys over time:
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
> > (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,
> > I think in terms of accessibility and usability we need a GPG equivalent
> > what "hotmail" did to email. This is what we call "webizing". Then
> > 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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gnupg-users