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

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.