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  

> 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-----
>> [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-----
>> [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

Reply via email to