[OpenID] OpenId recycling and trust

[tom calthrop]

Hi Peter,

Thanks very much for saving me a few years here:)


Is the following a possible/plausible solution:

1. At discovery I look for public key - 
http://openid.net/specs/openid-service-key-discovery-1_0-01.html

(the huge assumption here is that this key-pair was generated at 
registration of account and therefore this public key is not the same as 
the last users public key.

2. For a new user I store the public key. If no public key is found I 
request some other identifier (a site password).
3. On future connections I check that the public key is the same. If 
not, the consumer informs user of how to proceed (verify your account).

Am I on the right track here?

Tom



Peter Williams wrote:
> If it helps, the X.509 community went through the very same issues, in about 1990.
>  
> In the 1998 version of the standard, the X.509 v1 cert had no notion of identity recycling. One firm argued it had no need , as one could index a cert uniquely as {Name,serial}. By 1990, ISO had passed an amendment for the v2 cert. The extension mechanism of ISO 8824 was applied to add tags to the abstract type for certs. They added issuerUnique and subjectUnique integers (at the behest of NorTel/CSE and DEC/NSA). Arguments that v1 format was sufficient were rejected - even though BBN/NSA disclosed how it used v1 serial numbers for authority controls, in tightly controlled cert issuing regimes relying on trust in certified hardware that in turn relied on certified manufacturing/keyescrow protocols only found in the late-1980s comsec world.
>  
> Whilst these v2 integers solved the problem, they never really took off - as they were tied to the base Directory protocols - which were necessary for resolving the unique name (including historical id recycling).
>  
> The v3 format of the X.509 cert was what took off - once it was decoupled from the Directory world for use in the internet world of Steve Dusse's S/MIME and Tajer El Gamal's SSL. In V3, the name field is irrelevant now, as is the serial number of the cert. All you care about is the unique (signed) hash of the subject's public key.
>  
> So, if you want to learn a lesson of history, tie identifier recyling to the handling of certified public keys. It works, it scales, and its adoptable en masse. Or, you can be doomed to repeat all the old discussions of the same old topics, decade after decade.
>
> ________________________________
>
> From: general-bounces at openid.net on behalf of tom calthrop
> Sent: Sun 9/30/2007 12:32 AM
> To: OpenID List
> Subject: [OpenID] OpenId recycling and trust
>
>
>
> Hi All,
>
> I'm sure this issue has been bounced around a lot, but I I've not found
> "the answer", hence the following....
>
> We have software to create a community in which people contribute. We
> identify them using OpenID. The problem is this: a person connects to us
> using http://tom.provider1.com <http://tom.provider1.com/> , then abandons provider1.com in favor of
> provider2.com. Provider1.com then frees the account and another person
> registers with them who is then given the same URL. They then connect to
> our community and automatically become the author of the original
> contributors work.
>
> I appreciate that is is probably something associated with the source of
> the "this is not a trust system" statement, however I would like to
> attempt to explore possible solution here because I think trust is
> important.
>
> [small rant]...
> It is rather painful having to explain to people that this is not a
> trust system when most OPs choose to put "trust once" or "trust always"
> on the bottom of a "trust" page;) ...
> [/small rant]
>
> This can be resolved in the consumer application by asking for a
> password, however I have been at pains to explain to people that you
> should never input a password associated with your OpenID anywhere
> except under the URL of their OpenID login page; hence from a usability
> perspective this something we are loathed to do.
>
>
> I'd like to gather thoughts on / proposed solutions for this/trust for 2
> reasons:
>
> 1. I'd like to have a solution at the consumer which is easy for us to
> implement and does not require explanation to the user.
> 2. I think the issue of "trust" is going to come up again and again with
> OpenID and I'd like to know on a wider scale if their are any
> initiatives out their to address it.
>
>
> Tom
>
>
>
>
>
>
>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>
>