Re: WebID in Browsers conf feedback

On 12 Jun 2011, at 19:25, Peter Williams wrote:

> 
>  david chadwicks repeat of comments from unknown parties is of the same essence as the Paypal comment. They are both stuck in the https conception of a decade ago, not seeing how https/ssl can evolve to do what is *already* being done with IPsec and client certs.
>  
> Both criticisms have the same structure: that server farms based on load-balancing, failover, HA, .... architectures CANNOT adopt webid - BECUASE of the need to follow a reference. Any reference.

There is the "they need to follow a reference" and "they need to follow any reference" part of the argument. If I remember there was also the issue that if they need to follow a reference then hardware would need to be changed. My answer was that all that those hardware pieces really need to do is verify the public/private keys match. The dereferencing logic can be done at other layers, and those can also cache the results, avoiding the need for multiple dereferencing s by caching valid webids and profiles.

>  
> In a UCI world (where anyone can make up any crap), obviously who in a Paypal-grade of corporate entity wants to be seen publicly to be following a ref to irc://childporn.com, just because its presented in a cert ref from an nonymous party seeking to identity (and disrupt)? David's comment about someone's argument was that by IMPOSING trusted intermediaries (known as CAs), paypal's of the world are protected - as the CA has vetted the refs, up front.

An irc URL would indeed be silly to follow :-)

The HTTP GET Request is defined as being a safe method. So dereferencing a URL with GET does not make the dereferencer liable to anything. Coming to conclusions about what people think or do by looking at their GETs is bad thinking. If it were otherwise then search engines would be impossible.

>  
> Of course, this is the anti-thesis of the webid movement. The whole claim basis of webid as an argument is that the sematic web has a "reputation" trust model built in. And, one uses that, rather than imposing CAs as qualifying-introducers.
>  
> SO, the defense has to address the objection, expressed in its own terms. And that real objection is (ignoring the suggestion to go back to CAs) that webid needs to be able to qualify WHICH refs a consumer follows, before it follows them.

I don't think it needs to do that: it will be completely up to the knowledge and rules followed by the authenticating server. If the server has a list of WebID's that are allowed access, then there is no need for him to follow anything other than claims to be those WebIDs. If on the other hand he wishes some form of global authentication, then any webid should be acceptable. If you only trust the US government, then only accept .gov urls. Though I think you may as well just dereference and verify any webid, and then authorise based on those webids, such as are those .gov minted ones, or is he a friend of a friend of mine....

>  
> Its like saying: given a webid claim from a client cert newly presented, one needs to consult the semantic web as a trust model to find out whether or not the reference itself is something one wants to follow, before following it and evaluating the *content* of the triple store similarly against the semantic web and its trust model (now applied to triples, vs mere refs). One has to consider the provenance (hint) of the ref that is.
>  
> Now, knowing Henry argument style, he would probably say: this is architecturally already dealt with, because we are are assuming that those URI refs have domain-names, registered in DNS (as managed by or rooted by US firms, in whom we globally trust). Thus the DNS is the Reputation-source about the refs, since its the reputation source about their domain-names - and the notion of "authority" built into the URI concept. Webid is thus formalizing that the DNS (signed zone) is the authority of that namespace of URIs. DNS decides it the authority component of the webid resolves, or NOT. Its a security authority for refs, that is.
>  
> Now, we have got rid of CAs (and replaced them with more scalable signed DN zones!).

We don't need to get rid of CAs, they are another trust anchor that can be useful. (though they too look into DNS to verify claims.)

>  Little or none of this is talked about in the spec. Similarly, the control model of centralized/de-centralized implications of DNS and signed azones is not explored. It doesnt say how de-centralized zone signing is to be achieved (allowing for walled-garded DNS servers, with their own signed zone key management, ....)

I think the URL spec must cover this quite in detail I suppose. Billions of people dereference URLs each day based on this. But it may be worth in the formal proof I started putting together in n3 to work these rules out in more details.

Henry

>  
>  
> > Date: Sun, 12 Jun 2011 12:31:46 -0400
> > From: hhalpin@w3.org
> > To: public-xg-webid@w3.org
> > Subject: Re: WebID in Browsers conf feedback
> > 
> > The W3C released a blog post as well:
> > 
> > http://www.w3.org/QA/2011/06/workshop_tackles_the_hard_prob.html
> > 
> > 
> > Also, we will produce a final report within a week or two.
> > 
> > As regards WebID, I think David Chadwick's summary is good, as is Brad 
> > Hill (Paypal)'s summary of the security issues that need to be addressed.
> > 
> > cheers,
> > harry
> > 
> > 
> > On 06/12/2011 09:12 AM, Henry Story wrote:
> > > Here is some feedback from the WebId in Browser conf.
> > >
> > > Henry
> > >
> > > On 26 May 2011, at 14:00, David Chadwick wrote:
> > >
> > >> Hi Henry
> > >>
> > >> I got some good feedback from people at the workshop, which you should consider in a revision of the protocol.
> > >>
> > >> 1. You should not interrupt an SSL/TLS session midway (to fetch anything, either a remote page and/or the remote server's cert).
> > >> The solution to this would be either
> > >> a) get the browser to issue self signed certs for the user (the best solution), or
> > >> b) get the browser to send the user's server signed cert plus the server's cert which has been signed by a known root CA during the TLS handshake. In this way the receiving server can validate the signature chain without having to make a call out. However this would still mean modifications to the SSL software similar to that used by proxy certificates in their chain validation (since the signing servers' cert is flagged as an end user cert and not a CA cert, so it isnt allowed to issue certificates to end users. Consequently standard X.509 cert chain processing software will fail.)
> > >>
> > >> 2. it is not a good idea to ask a server to go and fetch any remote page (in this case the user's web id page) since an attacking user can point the server to poisoned pages that can contain any arbitrary code to be executed by the fetching server.
> > >>
> > >> I am not sure what the solution to this is Internet scale, since the whole process hinges on user's being able to point to arbitrary web id pages. For small scale use you can have white lists of known trusted servers and only allow user's to store their web id pages on these trusted servers.
> > >>
> > >> 3. Some people questioned how usable the PGP type web of trust would be, and whether it would scale to Internet proportions. One comment was I would not want the semantic web crawling to be more than two links deep as I cannot trust anything further removed from me than that. I think that in order to establish links between people at Internet scale you need around 7 links in order to connect most people together.
> > >>
> > >> Hope these comments are useful
> > >>
> > >> regards
> > >>
> > >> David
> > >>
> > >>
> > >> *****************************************************************
> > >> David W. Chadwick, BSc PhD
> > >> Professor of Information Systems Security
> > >> School of Computing, University of Kent, Canterbury, CT2 7NF
> > >> Skype Name: davidwchadwick
> > >> Tel: +44 1227 82 3221
> > >> Fax +44 1227 762 811
> > >> Mobile: +44 77 96 44 7184
> > >> Email: D.W.Chadwick@kent.ac.uk
> > >> Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
> > >> Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
> > >> Entrust key validation string: MLJ9-DU5T-HV8J
> > >> PGP Key ID is 0xBC238DE5
> > >>
> > >> *****************************************************************
> > > Social Web Architect
> > > http://bblfish.net/
> > >
> > >
> > 
> > 

Social Web Architect
http://bblfish.net/

Received on Monday, 13 June 2011 12:57:12 UTC