using the identity url to contain a key fingerprint
jld at club-internet.fr
Wed May 25 04:36:09 PDT 2005
That kind of argument is *exactly* what I was complaining about in my
Martin Atkins does not seem to grok.
You guys have put the cart before the horse!
You rushed to some implementation and to usage scenarios whithout
designing any specs from *requirements*
The so called "specs" page at Openid is *not* an architectural
specification it is a loosely worded mix of usage scenarios, API hints
and implementation details built on gratuitous assumptions.
May I suggest that you get back to the drawing board before making a
full mess of it?
Otherwise this will be Yet Another Giant Hack like Martin Atkins
rightfully calls it:
Your approach seems to be: take a "classic" authentication scheme and
scale it down while making it distributed.
If you keep the requirements of a vanilla authentication scheme you will
run into exactly the *same problems* that other implementors
encountered, do you think they were that dumb and *you* will make it
simple where they couldn't?
Adding the requirement to be distributed just make things much much worse.
Speaking from my very limited needs I would rather rework the base
requirements like below.
- What is the minimal need for a login to authenticate?
The client side should "do something" that proves that it holds some
secret key for user xyz.
- What should be the key and what should be the ID of user xyz?
All depends on *what* you want to "bind" to user xyz.
- In a classical setting the ID of user xyz is some "real" ID and the
whole point is :
to bind the secret key to this ID wich is itself bound to other
ressources and datas
to distribute this binding without disclosing the key
to refresh the key and redistribute the key to authentication servers
to revocate stolen keys
You know that stuff better than I do, Eh?
- Hold on the typing of code lines for a moment and think a bit about
user IDs in an anonymous setting.
- If users can be anonymous they may anyway tell whatever they like
They may have multiple identities.
A whole group may unknowingly share a single identity.
There is (there should be!) *no* way for anybody to match this
anonymous identity to any other "real" one.
- *These* requirements can be very easily fullfilled by using a public
key system and stating that
the user ID *is* the public key!!!
- In order to authenticate a login the website just need to ask the
client side to sign some piece of text
with his secret key, thus also providing along his public key which
*is* the sought for user ID.
- Everything secret is now on the client side and under his
There is *no* need for any authentication server!
There is *nothing* secret to distribute.
The whole scheme rely *only* on the agreement about the login protocol.
The "thing" that must be distributed is some kind of portable "PGP
lite" client side software
used only to answer login queries which should be able to generate and
pairs of secret/public keys with an interface tailored "for the masses".
This should not be too difficult if no fancy functionalities creeps
in beyond handling a set of alternate identities.
- Of course this is *not* a full fledged secret keys management system
and forgotten or stolen keys
will be lost for good!
- Some damage control could still exist for compromised keys by
broadcasting a revocation notice
(just like for stolen credit cards) but the logic of revocation could
only be handled by recipients
maintaining a list of revoked ID keys tagged by their arrival time
because there will be no certainty
about transmitted date stamps.
- The binding of such anonymous IDs to some "real" ressource could
still be done by providing
the same kind of authentication server logic which is currently
If some server can answer a login request from another website then
obviously the keyholder
*has* some control over the server (unless the key was stolen)
But authentication servers *will not be* a requirement for ordinary
and most common plain logins.
Are there strong "security weenies" on the list who could check the
logic of this proposal?
From the ongoing posts I see that you are still charging full speed ahead.
I *entirely trust you* to make "something" work, even (and more so...)
if it is a "giant hack" :-)
But THIS IS NOT THE POINT!!!
If the deployment is awkward it will not take off, YOU WILL BE SCREWED...
All the best,
Brad Fitzpatrick wrote:
>[ Security people, sanity-check me..... ]
>Because the key could change, and it'd be a pain for the people running
>the ID server to have to notify all their users to go change their link
>But perhaps we could add:
><link rel='openid.pubkey_signedby' value="93:AC:3A:B8:....." />
>And fingerprint of the CA that's supposed to have signed your public key?
>That way if we do use X.509 certs, and people had them signed (using a
>signing key they keep locked up on a separate machine/USB
>thumbdrive/CD-ROM) or Thawte or somebody, then they could rotate their
>public key as often as they want (or whenever they got hacked), and they'd
>never have to have their users update their links tags, assuming the
>signing authority's signing key didn't change?
>Security people, did I get that anywhere near right?
>I'm reluctant to go down the road of full PGP/PKI/SSL, but I'll listen for
>awhile and learn and make sure we do something that's at least extensible
>later, if needed. In the end I want OpenID to be the pragmatic identity
>solution, though, not some academic/tinfoil-hat-wearing answer that nobody
>actually every deploys. So keeping that in mind, what should I consider
>On Tue, 24 May 2005, Imran Ghory wrote:
>>One of the assumptions this protocol makes is that the page at the
>>identity url is secure (otherwise someone could change the id server,
>>etc.), so if that's the case why not store a fingerprint of the id
>>server key alongside the id server identity that would essentially
>>remove the problem of key distribution from our protocol ?
>>MSN: tickletux at hotmail.com
>>yadis mailing list
>>yadis at lists.danga.com
>yadis mailing list
>yadis at lists.danga.com
More information about the yadis