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

On 7 Mar 2012, at 18:17, 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).

Btw, we do need a new security section that goes into some of these basic issues that always come up.
If you have some text you wish to add to the spec, please propose it. It can save us repeating these
discussions again and again here.

Currently I am mainly working on writing code for demos for www2012, and it seems a lot of others on this
list are too as we discussed yesterday in the teleconf...


> 
> M.
> 
> -- 
> Mo McRoberts - Technical Lead - The Space,
> 0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
> Project Office: Room 7083, BBC Television Centre, London W12 7RJ
> 
> 
> 
> http://www.bbc.co.uk/
> This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
> 					
> 

Social Web Architect
http://bblfish.net/

Received on Wednesday, 7 March 2012 17:24:10 UTC