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

On 3/5/12 5:25 AM, Ben Carrillo wrote:
>
>     Certificates are self signed, so a CA is never involved.
>
>
> I'm not sure I understand / agree with this, Melvin.
>
> Don't you think the cited article refers to the publishing of the 
> WebID profile (I remember a thread some weeks ago about moving to 
> https instead of http), and not to the client certificates? I don't 
> remember spec saying anything about how the profiles have to be 
> published, although we all think TLS is better than plain. And we all 
> know that the ugly red screen scares your users away...
>
> I believe we should consider more carefully certain kind of critiques 
> in this direction. If someone's missing the point (I think that author 
> is missing the expressivity that comes with rdf, but that's something 
> not that easy to grasp), it might be our fault if it is not clear 
> enough in the spec (for the average joe-developer, or maybe we need an 
> implementors guide or something, if we _really_ want wider adoption). 
> Or, it might be that someone has a different security model in mind.
>
> Currently, how do we trust the webid profile publishing? How do you 
> trust that the assertions stated there have not been tampered on their 
> way, or maliciously changed since their original publication? Besides 
> the fact that most of us are serving demo profiles over http, I'd bet 
> that most of the implementations are just fetching what they find 
> behind the uri, without paying attention to the cert protecting it, if 
> any. So yes, I'm also afraid most of the profiles out there (actually, 
> most of the implementations) are subject to mitm. Please correct me if 
> I'm wrong.
>
> In addition to this point, I'll dare to state another, related one:
>
> "The whole system is [currently] only as trustworthy as the publishing 
> system currently in place".
>
> If the whole point of dereferencing uris is to demonstrate to the 
> world your write-handle over a resource, the overall trust in the 
> system is aproximately equal to the trust you put in the fact that 
> your publishing system is honoring the premises about permissions and 
> roles. If Alice is using a vanilla drupal to publish her webid 
> profile, when Bob's webid authentication system dereferences the URI 
> in Alice's cert, there are several facts implied in trusting the 
> claims claimed there:
>
> - The mod and exp claimed in the webid URI match those in the cert 
> being presented to the auth endpoint. Nice.
> - So, they belong to the same agent. Alice, or an agent operating on 
> Alice's behalf? not quite sure yet...
> - We *trust* that the publishing system in place does not allow 
> arbitrary people to publish material in a protected resource.
>
> I know what I'm stating sounds ridiculously obvious, but what I'm 
> implying is that, in our _current_ trust model, we're trusting the 
> publishing systems as much as the crypto boilerplate. They're the 
> weaker link, in my view. If your name is Homakov, you could have 
> impersonated any webid user who's serving his profile using rails. Or, 
> actually, pushed to any WebID implementation on github... XD [0]
>
> Can we agree that WebID profiles published by generic cms like 
> wordpress, drupal, joomla, spip, etc imply a somehow 
> "probabilistically" lesser trust on them than a file that only can be 
> modified by ssh? Greater attack surface, among other things. Am I 
> missing something?

The URIs in the subjectAlternateName (SAN) of an X.509 cert. have to 
resolve to a descriptor (RDF based profile graph). Post resolution 
(which includes SSL/TLS handshake) there is comparison of claims 
centered on the WebID (a URI) --> Public key relation. A man in the 
middle attack doesn't work around this issue. WebID is a tweak to the 
SSL/TLS handshake that involves the aforementioned lookup en route to 
verifying identity claims across two places.

>
> I don't say this is something that can be formally taken into account 
> in a spec, I just wanted to share a thought that has been haunting me 
> for a time.
>
> Of course, I'm stressing the _current_ state of affairs, since I'm 
> pretty sure that in the near future we'll be able to leverage digital 
> signatures,  belief networks evaluation, and such kind of smart stuff 
> built upon the current webid auth foundations. But let's be humble and 
> accept that, right now, the model is not perfect, and, like many 
> others, is open to attacks, be them theoretical or practical.

You don't speculate that its open to attack, you demonstrate that it is. 
Thus, if anyone feels the system is broken, then just go prove it with a 
live example. How about that? Why the speculation?

Kingsley
>
> Ben.
>
> [0] 
> http://www.zdnet.com/blog/security/how-github-handled-getting-hacked/10473
>
>
>         Any references to previous discussion on this issue?
>         Thanks!
>         ~ elf Pavlik ~
>


-- 

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