Re: as trustworthy as the hierarchical CA system currently in place...

On 3/7/12 12:17 PM, Mo McRoberts wrote:
> Breaking cover for this one, because it's really basic stuff which should be well-understood by anybody.
>
> On 7 Mar 2012, at 15:10, Kingsley Idehen wrote:
>
>> There is a composite key in two places, they have to match via semantically rich relations verification. This system isn't vulnerable to the scenario you describe.
>>
>> If you believe it is vulnerable then I would encourage you to demonstrate said vulnerability. I can easily protect a published resource using a WebID based ACL, then ask you to access this resource by exploiting the vulnerability you assume. That's what I would do etc..
> I raised all of this a year ago, but no matter :\
>
> According to the spec as written today, if I want to assume your identity:
>
> I generate a key containing your URI.
>
> I either:—
>
> a) convince the relying party to look at my server instead of yours when verifying that the key appears in your profile document; or
>
> b) compromise your server and replace your files with modified versions.
>
> Option (b) is a given in any situation, so doesn't need any special discussion.
>
> Option (a) is made more difficult by serving via HTTPS, because not only would I have to engage in DNS cache poisoning or similar, but I'd also have to obtain a certificate issued by a CA trusted by the relying party naming your server; this is countered by CAs generally not being very good at issuing certificates to the right people (because the more arduous they make it, the harder it is to obtain a legitimate certificate). DNSSEC also helps to defeat this attack. Maybe I do none of those things and just compromise your domain registrar instead. Malicious people have all of the experiences the criminal fraternity in attempting phishing attacks to draw upon.
>
> All of these things can be mitigated; a relying party can have 'degrees of trust' — DNSSEC + HTTPS = not likely to be spoofed, plain HTTP and no DNSSEC = risky in any high-profile service. But, crucially, the spec only hints at them being issues. It doesn't have to solve them at this point, I don't think, it just needs to outline what the things are that a relying party must take into consideration and what steps it can take to mitigate them (e.g., paying attention to key continuity), and noting that with a different certificate trust regime things might be different (the CA model is demonstrably unreliable, but maybe WebID can rely on a replacement being adopted before it's considered a mainstream identity solution).
>
> M.
>

Based on the above, I have a data access policy scoped to:
A given WebID + Public Key combo, not a WebID ideally soley. Basically, 
a composite key comprised of a WebID and Public Key.

You've spoofed my WebID, somehow spoofed a graph with a relation that 
has my WebID and some Public Key, what you don't have is the actual 
Public Key that drives my data access policy. Thus, how are you go going 
to get at the protected resource?

Bearing in mind, authorization is a different matter from 
authentication. My point above is about authorization via ACLs that 
incorporate the WebID protocol.

To conclude, you could *theoretically* (if you successfully divert 
relying agent) compromise a WebID on its own if the end game is 
authorization based on a key with a single element, but not so if the 
key used in the access policy is a composite.

I am happy to publish a resource at an address then invite folks to 
subvert my resource ACLs :-)

-- 

Regards,

Kingsley Idehen	
Founder&  CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen