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

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