- From: Henry Story <henry.story@bblfish.net>
- Date: Mon, 13 Jun 2011 15:07:45 +0200
- To: WebID XG <public-xg-webid@w3.org>
- Cc: Chadwick David <d.w.chadwick@kent.ac.uk>
On 12 Jun 2011, at 15:12, 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). I think Peter Williams argued well that TLS does currently require an interruption if only to "go fetch CRLs and OCSP responses and cert policies labelled by URIs". The only difference is that there is no limitiation in WebID to the hosts that can be connected too. If the issue is that those hardware verifiers are not built for this dereferencing then the answer is just to force them to just do public/private key verification, and move the second part of the authentication to another layer. > >> The solution to this would be either >> a) get the browser to issue self signed certs for the user (the best solution), or not sure how this would help. >> 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.) yes, one needs to use as little as possible from standard cert processing software. Luckily we have shown that this can be done in nearly every available programming language. >> 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. yes, that's an odd argument. There is of course no need to execute javascript that would come in a page. The semantic web is purely declarative. >> >> 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. yes, but there is no need to crawl the whole web. You get as much information as you can about someone as quickly as possible (1 or 2 GETs), and give them access rights based on what you know. As you know more you can also give them more access. >> >> 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 13:08:17 UTC