Re: [foaf-protocols] non issue comments on webid IX draft

On Mon, Feb 21, 2011 at 6:59 PM, Henry Story <henry.story@bblfish.net>wrote:

>
> On 21 Feb 2011, at 23:22, Peter Williams wrote:
>
>
> I may be 12 months too early in this topic (though it may influence how the
> webid spec's requirements are formulated). If you think so, Ill forward to
> the w3c list.
>
> To drive the point home, comprehend all of section 3.1 (ignoring step #6)
> and answer the following questions, says the school exam:-
>
> if the verifier receives a cert with 100 SAN URI entries, and the first
> entry tried has failed to obtain a document whose contents matches the cert,
> what should the verifier do?
>
> a. exit and refuse access
> b. try the next SAN URI, but no more than reasonable
> c. having tried 49 URIs, exit at 50 if it fails since 50 is half of 100
> d. iterate through all 100, till one works
> e. none of the above.
>
>
> I think any of the above. If you go into a shop and someone asks you for a
> credit card and you give them one that is wrong,
> they don't have to test all 50 of them. They don't even have to let you in
> the shop to start off with. After all they can do server maintenance.
>
>
> Should the spec imply the answer to the above?
>
>
> Not sure why the spec should say anything on that subject.
>

I don't think the spec should specify a max. limit here, though I agree
implementations should have measures in place to avoid any kind of DoS here..
Maybe this could go into a non-norminative section of the spec?


>
>
> if the verifier scans an XHTML document with well formed RDFa that matches
> the client cert but notices that that document has javascript with malicious
> content, what would be best to do:
>
> a. cache the document, and proceed to access control
> b. proceed to access control, but refuse to cache the document
> c. reject the document and try the next URI in sequence
> d. abandon the protocol run
> e. none of the above.
>
> Should the spec imply the answer to the above?
>
>
> I don't see why the verifier should bother with running the javascript in
> the page. The html is the declarative part of the document. The javascript
> transformation is something that the recipient can choose or not to execute
> on that information.
>

agreed with Henry. That's irrelevant for the WebID specification, and really
up to each implementation. js is only dangerous when run in certain contexts
(mostly in browsers), but since js is not used as part of the protocol, it
should not be executed server side. What you do with the WebId Profile
document and where you display it is up to you (implementers). If it is
displayed as part of the web app, you should of course escape any
non-trusted content etc..

Steph.


>
>
>
> if the verifier consults a URI reputation source before attempting to
> contact the resource and notes that the URI is in an IP  block known to
> affiliate with criminal syndicates, what should the verifier do?
>
> a. reject the certificate and then ask for a new client certificate
> b. reject the cert and the blacklist the IP address of the sender locally
> c. ignore the URI, but try the next one in the list
> d. try a different DNS server for the authority in the URI, to see if there
> is a better reputation opinion there
> e. let google worry about it by only relying on Google websso (since Google
> processes the webid issues).
>
> Should the spec imply the answer to the above?
>
>
> I don't think the spec should provide answers to those authorization
> questions. The spec should deal with authentication not authorization. We
> can start work on authorization as a side project. That is what the acl work
> was on. I am waiting to get webid working on Clerezza before entering that
> debate.
>
> Henry
>
>
>
> ------------------------------
> From: henry.story@bblfish.net
> Date: Mon, 21 Feb 2011 22:03:12 +0100
> CC: foaf-protocols@lists.foaf-project.org
> To: home_pw@msn.com; public-xg-webid@w3.org
> Subject: Re: [foaf-protocols] non issue comments on webid IX draft
>
> This really belongs to the WebID mailing list, as we are discussing the
> spec there.
>
> On 21 Feb 2011, at 19:17, peter williams wrote:
>
> http://www.w3.org/2005/Incubator/webid/spec/#processing-the-webid-profile
>
> Let me criticize the spec, as will real security experts (not that I can
> claim to being one, being a mere “enthusiast”).
>
> Sayeth the spec, the resource server MUST ping all servers which are listed
> in the SAN array of URIs. If I make a cert with 10,000 URIs and none of the
> foaf:agents’ RDF documents match the client authn client cert’s pubkey, the
> resource server MUST ping upto 10,000 other servers - chosen by the
> attacker.
>
>
> I don't know where you find that.
>
> In section 3.1 it says "with at least one" quite clearly
>
> [[
> The Verification Agent<http://www.w3.org/2005/Incubator/webid/spec/#dfn-verification_agent>
>  *must* attempt to verify the public key<http://www.w3.org/2005/Incubator/webid/spec/#dfn-public_key> information
> associated with at least one of the claimed WebID URI<http://www.w3.org/2005/Incubator/webid/spec/#dfn-webid_uri>s.
> The Verification Agent<http://www.w3.org/2005/Incubator/webid/spec/#dfn-verification_agent>
>  *may* attempt to verify more than one claimed WebID URI<http://www.w3.org/2005/Incubator/webid/spec/#dfn-webid_uri>.
> This verification process *should* occur either by dereferencing the WebID
> URI <http://www.w3.org/2005/Incubator/webid/spec/#dfn-webid_uri>and
> extracting RDF data from the resulting document, or by utilizing a cached
> version of the RDF data contained in the document or other data source that
> is up-to-date and trusted by the Verification Agent<http://www.w3.org/2005/Incubator/webid/spec/#dfn-verification_agent>
> .
> ]]
>
> http://www.w3.org/2005/Incubator/webid/spec/#authentication-sequence
> <http://www.w3.org/2005/Incubator/webid/spec/#authentication-sequence>
>
>  Can a server impose a local limit – one process more than 5? Don’t process
> ANY, if more than 5 present, etc?
>
>
>
> Implieth the spec,  the resource MUST trawl the web each time a client
> authn event is received (60 a second… on average?). This seems to imply that
> resource servers MUST be able to choose to (i) ignore events selectively
> (addressing DOS,DDOS using velocity counters) (ii) ignore based on local
> criteria.  Since one doesn’t want those 59 attacking events on the internal
> network, probably the firewall SSL interceptor needs to be doing the
> filtering and selecting (on behalf of the array of web servers)
>
>
> Where do you find that said in the spec precisely? If it is saying that
> then it is wrong.
>
>
> Assuming that the document is pulled, one has to allow resource server (or
> more likely the firewall) to scan the inbound content (for malicious
> javascript, say); since the URI is user-sponsored.
>
>
> The Relying Party (to use http://identitycommons.org/ vocabulary ) does
> not need to exectute anything in the certificate. Clearly there is not
> reason to do so. And if there were, I don't think that that would be up to
> this spec to talk of, since we don't require javascript in the certificate.
>
>
> It was unclear in the way the spec lays out the verification steps in
> sequence (i) having performed SSL mutual auth merely to learn the webid
> (from parsing a SAN field on the inbound cert) and (ii) having pulled the
> document referenced by the SAN URI, whether an ADDITIONAL handshake of SSL
> is required. (This is what I read the spec to say, note. Clear this up, if
> only 1 handshake is required).
>
>
> yes, that's odd. I am not sure how that ended up in the spec
>
>
> The spec is very unclear on what happens when an SSL resume handshake is
> used (and the server supplies the client cert to the servlet/CGI consumer
> based on its SSL session state, rather than from the wire).
>
>
> Can you develop this a bit? (don't go into too much length, a few pointers
> to the right spec, or descriptions of the problem, and how it affects us
> will do)
>
>
>
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols@lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>
>
> Social Web Architect
> http://bblfish.net/
>
>
>
> Social Web Architect
> http://bblfish.net/
>
>
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols@lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>