Specifying identifier recycling

Fri Jun 1 01:41:01 UTC 2007

Public key idea is somewhat attractive to me, but there are some issues that
comes up in my mind as well. 

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.

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. 

Actually, these private key pain may be eased by IBE (Identity Based
Encryption) but I need some more time to contemplate on it. 

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? 

=nat

> -----Original Message-----
> From: specs-bounces at openid.net 
> [mailto:specs-bounces at openid.net] 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: specs-bounces at openid.net 
> [mailto:specs-bounces at openid.net] 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 at openid.net
> > http://openid.net/mailman/listinfo/specs
> 
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
> 