using the identity url to contain a key fingerprint

Wed May 25 09:21:47 PDT 2005

Jean,

There are at least two dozen groups working on this problem of distributed
identity/authentication.  The reason we made a new one and didn't go join
project X is because our focus is different:

We're building something!  And we're building it for the 99% of the
population that doesn't know a public key is.  Most our users don't even
know what a web browser is, but they use one.  The just thought it was
called The Internet.

All the stuff you typed below... it's not worth replying to individually.
In whole:  you're on the wrong list.  We're not solving those problems.
Go to another list and laugh at us, but it solves our problems.

Or think of this as an interim solution to the perfect solution.  We can
educate a few million people in the next couple weeks about the basic
concept of distributed auth and when your ideal fat client comes along in
N years that does full PKI/revocation/etc, a few more might understand
/WHY/ they should care, even if they don't understand the details.

- Brad

On Wed, 25 May 2005, Jean-Luc Delatre wrote:

> That kind of argument is *exactly* what I was complaining about in my
> previous message
> (http://lists.danga.com/pipermail/yadis/2005-May/000272.html) that
> 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:
>  http://lists.danga.com/pipermail/yadis/2005-May/000123.html
>
> No wonder!
> 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
>   etc, etc...
>   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
> about them.
>   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.
>   Et voila!!!
>
> - Everything secret is now on  the client side and under his
> *responsibility*.
>   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
> locally manage
>   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
> envisionned.
>     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,
>
> JLD [Kevembuangga]
>
>
> Brad Fitzpatrick wrote:
>
> >[ Security people, sanity-check me..... ]
> >
> >Imran,
> >
> >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
> >tags.
> >
> >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
> >changing?
> >
> >- Brad
> >
> >
> >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 ?
> >>
> >>Imran
> >>--
> >>MSN: tickletux at hotmail.com
> >>AIM: tickletux1
> >>_______________________________________________
> >>yadis mailing list
> >>yadis at lists.danga.com
> >>http://lists.danga.com/mailman/listinfo/yadis
> >>
> >>
> >>
> >>
> >_______________________________________________
> >yadis mailing list
> >yadis at lists.danga.com
> >http://lists.danga.com/mailman/listinfo/yadis
> >
> >
> >
> >
>
>