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

> 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?

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.

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 ~
>>
>>