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

On 13 April 2011 20:58, peter williams <home_pw@msn.com> 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. 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.

A very important practical question.

I think all of these mechanisms can work in parallel with WebID to
make it that much better.  Trusted third party, password recovery,
well known information, revocation, and many more imaginable in next
generation web of trust.

We should really give the user the choice.  Users should be able to
place their trust in whoever they want.

Specialization inevitably leads to people delegating identity
management, to an extent.  Some will always want this, some will never
want this.  Are we replacing some services with other new ones?

Probably yes, but in hopefully a democratic and webby way, where the
best content and services bubble up to the top, rather than protecting
mediocre services with barriers to entry.

>
>

Received on Thursday, 14 April 2011 01:19:39 UTC