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? Note that these private keys would not be general-purpose private keys, but only for the specific purpose we are discussing here. 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? > 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. > 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. 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 > > > > > >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst >> Sent: Thursday, May 31, 2007 2:30 PM >> To: OpenID specs list >> Subject: Re: Specifying identifier recycling >> >> If we cannot assume that nobody manages to obtain a secret they >> should not have gotten in the first place, then OpenID as it stands >> is rather useless as we cannot trust its authentication scheme. >> >> Note that the surface through which the D-H shared secret can escape >> is about twice as large as the surface through which a private key >> can escape -- because an RP does not have access to the private key. >> In other words, if I was an attacker, I'd go after a lot of things >> first before I'd try to obtain a private key. >> >> Note also that public keys would make rather good i-numbers -- for >> those who would like to, they can ignore that they are public keys >> and do i-number-based verification only, because they are simply >> numbers. For those who don't care about i-numbers, they use their >> public key aspects. Win-win, perhaps? >> >> There is also the case -- which Stefan Brands would >> undoubtedly bring >> up if he was on this list -- that the IdP may be hostile, or may >> become hostile. (think of, say, a large OpenID provider going out of >> business, and being bought out by spammer.com -- or just the domain >> name whose registration lapsed) A scheme that is public key based is >> inherently more resilient towards this than one that is not. You >> certainly don't want to trust spammer.com to honor whatever >> conventions the previous owner of the domain put in place to >> disambiguate their users. >> >> -- >> >> Overall, I'm not sure we are ready in this community to pick one >> alternative over another as "the standards". I have my views, (many) >> others have (many) others -- and I don't think that any of this has >> to be in an Authentication 1.x (x>1) or 2.0 spec, whatever it will >> be. This seems like a clean add-on. >> >> >> >> On May 30, 2007, at 22:01, Drummond Reed wrote: >> >>> Johannes: >>> >>> What about the point Dick posted earlier in this thread, that the >>> problem >>> with using a public key is if the private key gets compromised? >>> Persistent >>> identifiers need to persist independent of any attribute changing >>> or being >>> revoked. >>> >>> =Drummond >>> >>> -----Original Message----- >>> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On >>> Behalf >>> Of Johannes Ernst >>> Sent: Wednesday, May 30, 2007 9:54 PM >>> To: OpenID specs list >>> Subject: Re: Specifying identifier recycling >>> >>> >>> On May 30, 2007, at 21:02, Johnny Bufu wrote: >>> >>>> ...The bottom line is >>>> that it can't be done easily - a mechanism similar to >> XRI's canonical >>>> ID verification would have to be employed, to confirm that the i- >>>> number actually 'belongs' to the URL on which discovery was >>>> initiated. (Otherwise anyone could put any i-number in their URL- >>>> based XRDS files.) >>> >>> Public keys ... public keys ... with the added benefit that no >>> centralized or trusted verification service needs to be employed >>> whatsoever ... >>> >>> >>> >>> >>> Johannes Ernst >>> NetMesh Inc. >>> >>> >>> >>> _______________________________________________ >>> specs mailing list >>> specs@openid.net >>> http://openid.net/mailman/listinfo/specs >> >> _______________________________________________ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs >> _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
