[OpenID] OpenId recycling and trust

[Peter Williams]

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