I've been reflecting lately on the OpenID use-case(s) I'd been hoping
to implement, and relevant vulnerabilities in the PKI which v.Next is
eager to write into the spec.
At 3:30 PM -0700 4/19/10, Allen Tom wrote:
Alternatively, if the public key is considered to be public
information, then it could be shared via Webfinger (again, the RP
needs to know who the user is already).
Is having the public key considered a sign that the OP can represent the user?
It shouldn't be; that's why we call it the *public* key. But unless
the user is involving their private key in an identity transaction^1
somehow, how does it present any additional assurance that the OP is
(still) approved by that user to represent them, or that the user in
question *owns* a corresponding key?
Then, even if the user *did* have their private key on hand to
provide such an assurance with, that means their key would be
*available* (every moment they might need to use it for OpenID) to
every person and software (from legitimate but vulnerable to
trojan-like) that managed to access it. (Difficulty applies, sure;
and opportunities - but to fend off determined attackers, something a
little more resilient would be nice.)
Does it matter? I'm assuming that the involvement of a personal key
is for higher levels of assurance in authentication, but perhaps it's
just an FYI feature. Even if it *was* required by a RP, would account
recovery/switching work in favor of the OP vouching for that user,
and allow *keys* to be reset?
Here's an interesting question - will the user's personal key be used
to *authorize* the OP to represent them?
A week at a time, for instance; once per week, the user goes through
whatever complicated steps they must to have a secure, offline
moment, and signs for their OP (and possibly *its* (server's) cert)
to represent them for another week. They can even have multiple
signed authorization forms this way, in advance, and keep them
offline until needed. If they decide to change OP's, damage control
is already in place. If they can't get to their private key again for
a week, they diminish their reserve but don't self-DoS.
This would be a "user-centric" approach. Most users can't support it
right now,and many would have their bank (or similar trusted
entity^2) hold it in escrow for them, localizing trust - but still
being no different from OpenID's outsourcing of trust. Leading me
back to the thoughts I had slightly over a year ago, when first
joining this list - that no single entity ought to be trusted, and
their mutual noncooperation can be exploited to keep power from being
centralized in *anyone's* hands - not the user, but not anyone else,
either. Not user-centric, decentralized.
I don't trust any of the major OP's to not act "on behalf of" their
users *by logging in AS their users* (early caching, active updates
of new content, etcetera; there are many "features" that could be
seen as valid reasons to do this, and Google/Facebook *especially*
have been in the news a lot for allowing the shiny promise of new
features to blind them when it comes to negative consequences), so I
can't provide users with the assurance that "for-their-eyes-only"
information will *only* be exposed to them. That, to me and for them,
could be an appalling cost.
But that leaves me with no trust of OpenID, so I need to find some
way of establishing a minimum level of trust, even if it isn't worth
much. (Either that, or I need to stop using the internet altogether.
Such temptations are, I suspect (and must remember to keep telling
myself) nothing more than an occupational hazard of studying internet
"security".) Having reflected on these matters until I came to a
clearer understanding of the difference between "user-centric" and
"decentralized" (as I understand them), I can now imagine a solution
that mixes elements from both approaches:
Place the public key (rather, the signed authorization for an OP (by
cert, recommended) to speak for the user with that public key) with
multiple OP's - I suggest *not* using Webfinger for this, so as to
prevent correlation (unless the signed authorization doesn't mention
any non-key data; then, correlators could identify alternate services
used, at most, but not find out account names).
-Shade
^1) The process of logging in and exchanging data (or otherwise doing
something) which they are privileged to do on account of their
identity. I clarify this because I'm not confident of my terminology
here and I don't want the words rousing confusion later on as the
vocabulary becomes more precise.
^2) Actually, considering the current economic climate, maybe banks
weren't the best choice of example here :)
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
