- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Wed, 13 Apr 2011 15:54:23 -0400
- To: peter williams <home_pw@msn.com>
- CC: 'WebID XG' <public-xg-webid@w3.org>
- Message-ID: <4DA5FF6F.9080808@openlinksw.com>
On 4/13/11 2:58 PM, peter williams wrote: > > Lets assume a user maintains control of the foaf card, but loses > control over their public/private key. It's a well managed and secured > card, and only the public modulus of his own private keys are bound to > his/her own cert:id. > > I goto test site with browser. Its TLS server checks that I can sign a > client authn signature -- since it matches the cert in the SSL > handshake. But, of course, I control that cert value, and its list of > SAN URIs. TLS is confirming I possess the private key, bound to the > modulus used in the handshake. It provides that modulus to the webid > validator, along with the SAN URI claims. > > Under the workflow, for all cards (well managed or not, attacked or > not) pull their RSApubkey triples. Form a local associative array, > mixing all sources together. Look for match of webid and mod, in the > array. > > This seems to be the problem. > > Any of the sources can place in its card a cert:id->mod value that > matches the above. When I present my cert, I can be including a URI to > Henry's card say, which may have a cert:id->mod value for me, in > addition to his own. If I remove the binding from my own card (or make > the card go offline), webid would still authenticate me to resource > servers (because of Henry's recommendation, about me). > > If a thief steals my private key, there is nothing I can do to stop > him using it at my resources. > Re. ODS, you would do the following once you know your private key has been compromised. For instance, you laptop is stolen. Even worse, your USB key store is stolen. Steps: 1. Login to ODS using Digest Authentication using standard username and pwd interaction pattern 2. Remove all Public Keys (via "Security" tab UI) 3. If in possession of a new USB key store or personal computer, generate new certificates 4. Done, until next compromise of this magnitude. Kingsley > > If I somehow contacted all my friends (who have posted my cert:id->mod > binding in their cards) to have them remove their bindings about me, > this doesn't stop the problem. The thief can mint another variant of > my cert (signed by anyone), and add an new SAN URI making his own site > (at google site say) - a new source of a binding that satisfies the > workflow. > > There doesn't seem to be anything unique to webid about this issue. > But, it is a system property. There is no way to address losing your > key. If you had two copies (and one is now with the thief), this > doesn't help either. Each is equal in the eyes of the resource server. > > In the cert world this is addressed by (i) using TTPs, and (ii) > ensuring the true subscriber has a compromise recovery password. If > *anyone* uses that value, the cert is revoked. Various bank-style > means (personal knowledge of social facts) are used to recover that > password, if you lost it. Obviously, there is no advantage to the > thief using it, if it is stolen. (A covert theft can be used for a > planned DOS at later date, though) > > Applied to webid, the TTP scheme doesn't work (since there are no > TTPs) - and as all sources of foaf cards are equal in standing. One > cannot have a situation that says: absent from X URI, assume the > public key identity is revoked, as again the attacker is now in > control of the list of SAN URIs - that need not list X, any longer. > > On a small pgp scale, of course, a network of folks can pairwise agree > (OUT OF BAND) that some third party URI with a foaf must be confirmed > to be one of the sources of webid bindings and need not be listed in > the SAN URI set. This is enforced as part of access control rules, > once claim is partly verified. But, this obviously doesn't scale to > e-commerce type operations, in a many to 1 information flow model. The > dynamics of maintaining those pairwise associations also has the usual > lifecycle managemen issues, as values go stale. > > If one create a new key, and bindings, how do we expect folks to now > re-associate it with the ACL that used the previous webid value? Lets > say, im hit with a trademark claim that makes my webid injuncted, say. > How to I introduce the all the public resources doing webid ACLs to > the equivalence of my second webid to the suspended first? > > Is it going to be an TTP model, where if dominant X has equivalence > lists, all relying party sites assume its true? > > As I think more and more, we seem to be replacing CAs with CAs acting > under a different name. The need for the TTP doesn't go away, once the > full lifeycle management of keys is considered. > -- Regards, Kingsley Idehen President& CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Received on Wednesday, 13 April 2011 19:54:50 UTC