W3C home > Mailing lists > Public > public-xg-webid@w3.org > April 2011

Re: losing private key, means losing access to resources, surely.

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Wed, 13 Apr 2011 15:54:23 -0400
Message-ID: <4DA5FF6F.9080808@openlinksw.com>
To: peter williams <home_pw@msn.com>
CC: 'WebID XG' <public-xg-webid@w3.org>
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.


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.

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



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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:44 UTC