Hi. My comments in-line below:
On Saturday, June 02, 2007 5:40 AM, Johannes Ernst wrote: > > On May 31, 2007, at 18:41, Nat Sakimura wrote: > > > Public key idea is somewhat attractive to me, but there are some > > issues that comes up in my mind as well. > > Bring them on ;-) > > > 1) Storing many users' private key on the server in > decryptable format > > is not very safe. > > > > In your proposal, it looks like that OP is going to hold > the private > > key for each user in decryptable format. Considering that > most large > > scale privacy leakage happens at the server side, I have > got a feeling > > that such thing like private key in a shared location. > > How would this be less safe than storing many shared secrets > (per OpenID Auth) in decryptable format, or clear-text (more > likely) on the server? Well, we should not store any :-) We would not need them, do we? Just hashes would do. > Note that these private keys would not be general-purpose > private keys, but only for the specific purpose we are > discussing here. Actually, by Dick's comment, I am now realizing what was making me uneasy. I feel (sort of) ok on storing one's special purpose secret key on the server just like server-side wallet, but I want it to be replaceable without impacting my identity. i.e., it is ok to use the key to sign a message, but not make the pub-key my identifier. (Having said that, I am still not clear why we should need this for just AuthN. OP sigining the response on authenticating the user does not seem much different. Also, keeping one key in HSM and securely operating is easier than having millions of keys...) > > Also, I suspect that the use of these keys would be fairly > infrequent compared to other operations, so conceivably one > could add additional safeguards of various kinds if that was needed. > > > 2) It may mean a high cost operation for OPs. > > > > If we do this, it makes OP operation very high cost because to make > > the service safe, it would require a lot of measures. (NRI is > > providing similar kind of service but it indeed is very high cost > > operation.) > > > > Nice thing about i-number is that it has no value like public key > > except for its resolvability. Even if it leaks, that's kind > of ok so > > operational risk is low. > > This comparison does not work very well for me. However: I > don't know the details of how to avoid "impersonation" via > i-numbers (in case of key pairs, it would be "private key > leaks and is reused by attacker" > -- what would be the equivalent for i-numbers?), but I > suspect there are some measures that prevent attackers from > impersonation by using somebody else's i-number? If so, > aren't they similarly susceptible to attack? In the scenario that OP signs a unique string (whether it is i-number or something else), impersonization happens when OP's key is stolen. However, as Dick points out, we have a way to re-setup the keys between OP and RP. In case of "user private key as a part of identity" leaks, we do not have a very good way of replacing it. (Well, we cannot, as if we could, this will contradict its purpose as counter id recycling measure. Note, if it is not part of identity string and just used to sign something with public key discovery protocol, that is ok.) ( I also would like to point out that OP's key leaking is much easier to monitor and detect than user's. ) > > > Actually, these private key pain may be eased by IBE (Identity Based > > Encryption) but I need some more time to contemplate on it. > > I had somebody else mention this to me -- I wonder whether > anybody could put together an actual proposal. After some thinking, I started to think that this might not be a good idea after all. > > > 3) Since OPs has an access to the users' private key, they > > may recycle them as well. > > > > IMHO, recycling is operational problem as well as a technical one. > > i-number from a certified i-broker is somewhat trustable on the > > account of no recycling because of this operational > > restriction. Could > > there be operational restriction similart to that for > > general OPs as well? > > There could, and -- I suspect -- in the longer term there > probably will, but the whole point about a decentralized > system like OpenID is to keep the playing field level without > a central entity in the middle for the maximum length of time > and scope possible. Well, I am not talking about a central authority kind of thing. Having a uniquely identifying filed (whether canonicalID or fragment) in the spec would suffice because this will imply that an OP that does not meet this operation practice is not OpenID spec compliant. Some OP may opt to elect a third party auditor to prove their parctice, while some other would not. Also, reputation service kind of thing would be nice. This is all de-centralized. No central authority would be required. > > In any case, I think we should use the approach to use > (decentralized) technology to the maximum extent possible, > and only add operational requirements when unavoidable. (And > I know that many people on this list would scream bloody > murder if anybody seriously proposed such a centralized > requirement for OpenID usage ...) Personally I would feel we > didn't think hard enough on this particular problem if the > solution to this problem required us to use centralization of > some kind. > > > > > =nat _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
