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 must attempt to verify the public key information associated with at least one of the claimed WebID URIs. The Verification Agent may attempt to verify more than one claimed WebID URI. This verification process should occur either by dereferencing the WebID URIand 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/#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/