OpenPGP keys can be "resolved" using key servers - for example -
here's mine:


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,

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

Reply via email to