using the identity url to contain a key fingerprint

[Jean-Luc Delatre]

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