Hi, OpenPGP keys can be "resolved" using key servers - for example - here's mine:
http://pgp.mit.edu:11371/pks/lookup?search=0xc0ded00d&op=vindex&exact=on In the old days, they used "key ID" to find these things, but they stopped doing that and started using fingerprints when people like me worked out how pick our own key ID's :-) I don't think public keys for identifiers are a good idea. I know you're all sick of me whining about privacy, but once again - these things "leak" all kinds of information about the victim... err.. owner so if you start using them in places they were not meant to go, for things they were not meant to do - you're begging for trouble. Oh yeah - and don't forget that all signed keys expire every year, most keys (whether or not signed) expire every few years, and you can't ever get a key without it coming inside a certificate, and these things can change all the time. Not my ideal concept of anything that's supposed to be "persistent". Oh - and the obvious thing while I'm here - nobody's got public keys anyhow, with the exception of a few geeks here and there, and everyone involved in cybercrime. Kind Regards, Chris Drake, =1id.com Wednesday, June 6, 2007, 2:50:17 PM, you wrote: dr> For posterity, here's how I'd summarize this thread about using public keys dr> as persistent identifiers: dr> 1) Yes, a public key could be used as an identifier, and could serve as a dr> persistent identifier if it was not reassignable. dr> 2) The issue of it becoming invalid as a credential if the private key was dr> compromised is orthogonal to its use purely as an identifier, i.e., as dr> Johannes points out, if the private key was compromised, use of the public dr> key could revert to the role of serving purely as an identifier, and another dr> set of credentials (such as another public/private key pair) could be dr> assigned. dr> 3) In this light, the primary drawbacks I see to public keys as identifiers dr> are: dr> a) They are typically much larger than other persistent identifiers dr> designed for this purpose (e.g., XRI i-numbers as issued by XDI.org or dr> Handles as issued by CNRI). dr> b) I am not aware of a resolution protocol designed for them, with dr> the exception that I believe syntactially they could be used as XRI dr> i-numbers. dr> =Drummond dr> -----Original Message----- dr> From: [EMAIL PROTECTED] dr> [mailto:[EMAIL PROTECTED] On Behalf dr> Of Johannes Ernst dr> Sent: Tuesday, June 05, 2007 7:27 PM dr> To: =nat dr> Cc: 'OpenID specs list' dr> Subject: Re: Specifying identifier recycling dr> I think you are making an invalid analogy. What prevents you from dr> setting up a "private key reset" function the same way you set up a dr> "password reset" function, using an alternate credential? You allow dr> for this for non-public-key credentials but not for others ... dr> But I don't want to perpetuate this thread given the general dr> reluctance of the community to think about public key cryptography at dr> this time ... I just want to go on record that I find the arguments dr> made counter public keys on this thread non-persuasive and want to dr> pick it back up when the community is ready to go there ... (note dr> also that the security industry would not exist in the shape it does dr> if we didn't have public key crypto, so that technology does dr> contribute something somewhere ... perhaps also to OpenID?) dr> Just follow the following argument ... let's assume that the problem dr> that started this thread dr> ... can be solved by adding a number to the URL identifier (using a dr> fragment syntax or an i-number or whatever other approaches were dr> discussed) dr> ... then it also can be solved by adding a large number instead of dr> just any number dr> ... then it also can be solved by adding a large number that could be dr> a public key, which is nothing but a large number dr> ... which, therefore, makes a public-key-based approach at least as dr> powerful as a plain number dr> Just some stuff for thought ... ;-) dr> Cheers, dr> Johannes. dr> On Jun 5, 2007, at 17:58, =nat wrote: >> Hi. >> >> Ok. Now I see the heart of the topic :-) >> >> Fundamental difference is that you postulate that one cannot lose >> one's >> credential including all the information that bears onto establish >> one's >> identity while I do not postulate so. >> >> For example, one can loose one's password and reset it. >> You can loose your credit card and replace it. >> Doing so has not nullished your "identity". You still are yourself. >> Your identity itself and the attribute associated with it apart >> from this >> particular lost credential data (whether it was a password or >> credit card) >> stays intact. >> >> This picture changes dramatically when you use public key >> as your main identity address. If you lose your private key, >> that's the end of story. Your relationships with all the RPs are >> ruined. >> >> That is why I believe that we should not be using this kind of >> public key >> as the identification data for RPs. >> >> Also, mandating OPs to specify a unique opaque string as the >> identification data would be much simpler than requiring parties to >> do public key verification, I think :-) >> >> Having said that, I do agree that we should be completing 2.0 cycle >> quickly and making it SIMPLE! >> >> Nat >> >> >>> -----Original Message----- >>> From: Johannes Ernst [mailto:[EMAIL PROTECTED] >>> Sent: Tuesday, June 05, 2007 1:45 PM >>> To: =nat >>> Cc: 'OpenID specs list' >>> Subject: Re: Specifying identifier recycling >>> >>> I would postulate that if you want to be able to prove your >>> identity, you cannot allow your credential to be lost, >>> interpreting "credential" to be all the information that >>> bears onto establishing your identity. (saying it this way, >>> it is a tautology.) >>> >>> This is independent of whether anybody uses public keys, or >>> any other technology. So I very strongly suspect that while >>> it may be more apparent to you guys that the issue exists for >>> public key technology, it also exists for all other >>> approaches, whether we know them at this time or not! >>> >>> However, I can readily see that strong voices (that'd be you >>> guys ;-)) are not ready to adopt any kind of public key >>> technology into the OpenID family, never mind whether X or Y >>> wins this particular argument. So we don't need to continue >>> this thread. >>> >>> I continue to believe, however, as I have said before, that >>> we don't have enough of an agreement on the solution to be >>> able to standardize any of them at this time. (Personally, I >>> don't think we have agreement on the problems to be solved >>> either.) I'd much rather see our creative juices flowing on >>> the much larger problem of simplifying the OpenID Auth draft >>> in a manner that people say "this is much easier than 1.1" >>> instead of the opposite. >>> >>> >>> On Jun 3, 2007, at 23:11, =nat wrote: >>> >>>> Dick's concern is very valid, I think. >>>> >>>> I do not even want to think of the consequence of losing my >>> own main >>>> identity secret :-p >>>> >>>> =nat >>>> >>>>> -----Original Message----- >>>>> From: [EMAIL PROTECTED] >>>>> [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt >>>>> Sent: Sunday, June 03, 2007 8:24 PM >>>>> To: Johannes Ernst >>>>> Cc: OpenID specs list >>>>> Subject: Re: Specifying identifier recycling >>>>> >>>>> There is a huge difference between the OP/RP shared secret >>> and using >>>>> a shared secret as an identifier. >>>>> >>>>> The secret between the OP and RP has a mechanism for it to be >>>>> recycled. If it happens to be lost, then the pair can set up a new >>>>> secret. >>>>> >>>>> If the user's secret is lost, then that identifier and any >>> accounts >>>>> that it was used for are lost. >>>>> >>>>> -- Dick >>>>> >>>> >>>> _______________________________________________ >>>> specs mailing list >>>> specs@openid.net >>>> http://openid.net/mailman/listinfo/specs >>> dr> _______________________________________________ dr> specs mailing list dr> specs@openid.net dr> http://openid.net/mailman/listinfo/specs dr> _______________________________________________ dr> specs mailing list dr> specs@openid.net dr> http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
