RE: MyProfile

There were many things in that response to argue with. Let me focus on what
I think is the most important.

One thing I want Berlin paper writing process to clear up is: what happens
when a proxy sitting between resource server and foaf card endpoint does a
302  redirect (to some URI maybe *little* related to the original target)?

Im an attacker, knowing the ACL has a positive entry webid W. Webid X is
sought by resource server. I have EVERY incentive to find and subvert a
proxy so access to X 302-redirects to W, and thus passes the ACL guard.

Are we trusting proxy servers - to only 30x to "equivalent" resource ids?

Should our resource servers (in foaf card recovery mode) refuse to follow
referals (perhaps because the HTTP proxy is not a  part of the
document-centric equivalence statement world)?

In the openid world version of the same issue, they are ONLY looking for
redirects to endpoints of agents  (vs identifiers of the subjects). It
doesn't really matter (much) that endpoint for agents move around, or are
multi-plicitous. That's just binding land. IN our world, we don't have the
distinction between endpoint and identifier.

We have to get rather more formal about the multiple SAN issue, I feel, in
addition. And, yet more formal even that that about the multiple keys in an
anchored graph. We have to decide are we a "framework" (out of which one can
build multuiple, perhaps incompabitle products .... like X.509), or is the
one single vision complete in its own right, read as a uiniversal problem
solver (for 80% of the common cases).

Take RFC 1422 characteristics, by way of example. In RFC 1422, unlike the
later vision of "PKI", you can have a pubkey certified by multiple EE certs,
supported by different cert chains. The assumption is that ACLs do NOT cue
off the subject name ( the identifier claim), but the issuer+serial id of
the PARTICULAR cert. This allowed a real person to gain independence from
CAs (who would otherwise typically get all fascist, eventually strutting
like facebook as an overlording IDP full of this or that dogma for society).
But, 1422 also PRESUMED that the acls at resource servers were "cert based"
(where the cert's own id (issuer+serial) was, in Kingsley-speak, a proxyname
for the subkect name - a more refined name with certain "distinguished
properties" that allowed different certs of the same subject to be
delineated, for various real world reasons).


-----Original Message-----
From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
On Behalf Of Henry Story
Sent: Wednesday, May 04, 2011 12:40 PM
To: peter williams
Cc: 'Andrei Sambra'; public-xg-webid@w3.org
Subject: Re: MyProfile


On 4 May 2011, at 21:05, peter williams wrote:

> Ok. So the paper really *is& a discussion of myprofile, not webid.
Myprofile is an implementation, contrasting with foaf.me (say).

I also think that it is worth developing the FreedomBox/MyProfile picture.
It puts some things a lot more clerly into focus. 

> And, its specifically interesting BECAUSE the profile and its agent is on
the user's personal computer (and is not controlled by provider of websites,
like the contrasting foaf.me more "webby" example). I like that you are
focusing on this constraint (it's what I wanted to do with Opera Unite,
similarly; not that I succeeded to make it work). Since the foaf card is not
signed, assuming a third party WILL maintain the profile's integrity (think
Facebook) makes webid little better than openid. Of course foaf.me is going
to suspend me, the moment it gets a covert order to do so. He goes to jail
if he doesn't. Of course he is going to suspend me too, if his insurer rings
up (and demands it, under threat of removal of coverage).
>  
> Ok. Im getting to understand, from this update. Myprofile may ENSURE there
is a unique identity concept (not that the underlying webid standard does
this). May want to make this clear - that there is an explicit constraint
being imposed (that other webids may not have).  I'll guess that by
profiling and constraining webid standard, Myprofile enabled the webid
mechanism to support the "unique id" claim, specific to myprofile.

I don't think one should misunderstand the idea of a "unique ID" . No open
system can constrain any object to have only one name. What is important is
that the ID be uniquely referring, which is of course what URIs do. What may
be important is to find a way to help other players know that they are
dealing with a box that is owned by the identified agent - since that has
certain properties relating to confidentiality.

One way to do that would be for the client certificate to use the same publc
key as the TLS endpoints. It would be good to know if there are weaker ways
to do this too.  


> To implement that, myprofile may for example be less open than webid 
> as specified, in that it (a) might require the user browser to use 
> certs that are minted by myprofile software (certs minted by third 
> party software from PKI for example, cannot integrate in _MYPROFILE_), 
> (b) may not support the multiple SANs notion (which introduces lots of 
> identity ambiguity),

Why you could have a certificate that has multiple SANs but one of them has
a special relation to a server that is found to be administered by the
identified person.

> (c) may somehow ensure the user cannot export the  keying material and
reuse it (at foaf.me, say) undermining the uniqueness claim.

Why? You may export it, but in doing so just loose the "Administrator" of
that machine property, and so loose certain confidentiality properties.

>  
> If anyone cares, the traditional structure in the security world is
identification (get the name, as registered under registration criteria),
authentication (of the name claim) to third parties, authorization (using
role/group/label claims attached to the id, somehow).
>  
> In the case of foaf.me, I get a name, which is my identifier. It makes a
PPD. Then I establish authentication credentials (by stuffing in my public
key), allowing for acts of authentication of my presentation of the id claim
(using TLS mechanisms). Then, authorization claims are pulled/pushed to the
resource server, enabling IBAC (identity based access control).
Alternatively, the resource server performs RBAC (rule based access
control). In the IBAC world, users have discretion to change access rules on
resources. In the RBAC world, users do not; only privilege administrators
may change the users labels, or the labels on the resources, that guard
access.
>  
> Perhaps we stick to that world view - being SO established. It's the X.509
world, where the terms are long standardized by ITU/ISO in X.800. In the
practical authentication framework version of the scheme, get an directory
name and an user-class entry, stuff in cert attribute (optionally), use
signed operations at a UA to present the name/identifier claim to an agent
guard. As a result, the guarding agent validates the authN evidence from the
wire (a signature, supported by certified name/key binding), then normally
performs AuthZ, using either IBAC model (roles/groups tied to the id claim
compared against ACEs in the ACLs) or RBAC access control models (labels
lattices tied to the id claim and resources, and channels/ports often).
>  
> Now is something about webid or myprofile NEEDS a different organization
of core security framework perhaps argue that. Lets know if its myprofile
(specifically) or the underlying webid standard that mandates the shift in
perspective. OpenID has the classical formulation (if that's relevant). If
security for/from the semweb perhaps requires  a different language game
(perhaps because of the underlying RDF model, the nature of the webid
enforcement logic,  or .), this is WELL worth communicating.
>  
> I think we just have to ensure we are not dropped in the openid 1 
> bucket, and folks like UK JANET look at webid per se and essentially
dismiss it (because it has "no value"). Semweb with webid has to avoid being
labeled as another "openid 1".
>  
>  
> From: public-xg-webid-request@w3.org 
> [mailto:public-xg-webid-request@w3.org] On Behalf Of Andrei Sambra
> Sent: Wednesday, May 04, 2011 10:24 AM
> To: public-xg-webid@w3.org
> Subject: Re: MyProfile
>  
> On 04-May-11 18:39, peter williams wrote:
> Comments
>  
> https://docs.google.com/document/d/1hqxoA70Gz6daGop7ucKwEZtc_HbmQzed9w
> QBcLq8nyE/edit?hl=en&authkey=CPTf9qIP#
>  "WebID proposes a way to uniquely identify a person, company, 
> organization, or other agents, using a URI which is included in an 
> X.509 browser certificate. The authentication process relies on TLS to 
> validate that the private key in use matches the public key of the 
> declared certificate, as well as the public key found in the profile 
> at the location indicated by the URI. In other words, it provides a 
> cryptographic way of authenticating and identifying a user, based on 
> resources managed by the user -- the browser certificate and the 
> corresponding profile accessible at the URI location. "
>  
> The last clause is really not true. Surely, there is no *Cryptographic*
use of the assumptions of user control over browser or profile. Rather,
webid security protocol is asserting the truth of the claims, having itself
relied on TLS crypto to prove X. The crypto (in TLS) only does (mostly, see
below) what the first part of the paragraph says. TLS's security services
are relied upon, but the crypto (and TLS) methods underlying the delivery of
those services make no use of user-governance of the cert or user control of
the profile (at the URI).
>  
> Its obviously trivial for the administrator of foaf.me to modify my foaf
card, using privileged access.
>  
> What I said there was in the context of MyProfile project, in which users
host their profiles on their own computers/dedicated machines. What you
should understand from this, as opposed to having your card stored on
foaf.me, is that there is no other entity (i.e. administrator) who could
potentially modify anything.
> 
> 
> Webid is a "security protocol (SP)". As the para says, that SP relies on
TLS (to do X..). The SP then enforces various non TLS controls, intended to
prove the claims. This relations is much like how https builds upon TLS, to
enforce various security controls that TLS does not deliver.
>  
> Suggest: First, distinguish the claims due to webid "validation" from the
evidence/role of TLS in helping make/prove those claims, where TLS is merely
a supporting mechanism.  Second, show how the validation design proves the
claims, or state the limits. In my view, the claims are merely assertions.
Its their nature that limits them to being only assertions, in my view.
>  
> Are you still referring to the above quoted paragraph (I see no relation)?
If you are, then any ambiguity a reader might have can easily be dismissed
by examining the WebID specifications (let's not be lazy).
> 
> 
> -----
>  
> Concerning "proposes a way to uniquely identify", is this really true?
Nothing in TLS nor in webid SP prevents or detects two parties sharing one
private key. Indeed, we have said that there can be multiple URIs in the
SAN, pointing to different profile documents. A profile ownser can have
multiple keys in each profile, and the keys sets in n  profiles can be
disjoint. Thus, to the SP one has to assume the user has different keys (and
TLS evidences thus, when keys are applied for signing macs) and different
URIs, undermining the core "uniquely identifies" claim.
> 
> 
> Identification and authentication are two different things. Would you
agree that identifying yourself means matching a credential (i.e. the
certificate) to a description of a user / device / etc.? 
> 
> 
> If I look at our fundamental concept, we are specifically not proposing a
way to uniquely identify. We are giving a way for different identities to be
considered equivalent. Its really is a variation of having two cert paths
terminating a different trust anchors, both certifying the same user pubkey.
In the semweb version of this problem/case, its something
ontological/logical/enforcing that the semweb elements of the design do (not
the crypto). It's also the semweb that delivers the *assurance* that
*inferred* equivalency claims are even computable and/or then true.
> Again, you are confusing identity and authentication. Authentication stops
as soon as a match is found between the public key of the certificate and
the RDF description of the same public key in the foaf card. Next comes
identification, since now a service trusts that the contents of the foaf
card indeed belong to the user that is found behind the browser and which is
accessing said service. Even more, after identification we can now talk
about authorization. All three are different concepts, you shouldn't get
confused.
> 
> 
> It's the close reasoning on this I *most* want to hear in the Berlin
papers! Don't need more generalities per the paper for the American vendors.
Now we want the semantic web to shine, and not just because its webby. It
has to be showing how it enforcing some specific security claims, and also
who why anyone should believe it does this.
> Are you proposing anything for the Berlin workshop? 
> 
> Andrei

Social Web Architect
http://bblfish.net/

Received on Wednesday, 4 May 2011 23:48:50 UTC