[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Summary Trust x Delegation
On Wed, 28 May 1997, Michael Robinson wrote:
-> Stef Hoeben <Stefan.Hoeben@esat.kuleuven.ac.be> writes:
-> >At 03:58 PM 5/24/97 GMT, William Allen Simpson wrote:
-> >>
-> >>The protocol issues are "authentication", "authorization", and
-> >>"delegation".
->
-> >Doesn't SPKI have to solve this trust problem before people will
-> >be able to use this, or is there allready a solution?
->
-> As someone who is impatiently waiting for the SPKI draft to reach the
-> implementation phase, I have to say I find all this nonsense about
-> "this trust problem" deeply discouraging.
->
-> The statement above makes as much sense to me as, "doesn't contract law have
-> to solve the trust problem before people can use it?"
->
-> There is no "trust problem". Anybody can betray anybody else's trust at
-> any time. That's life. As far as a protocol is concerned, there is no such
-> thing as trust.
When the protocol enforces transfer of authorizations as a matter-of-fact
procedure, to people I never met, the protocol IS implementing trust
because that's what it amounts to.
You cannot ignore the fact that you need checks & balances in real life.
How then do you want to provide the software equivalent of a "blank check"
when you sign a certificate?
->
-> The problem which needs to be solved is the "accountability problem", which is,
-> how do you handle violations of trust.
Now, you have just contradicted yourself. Because one breath earlier you
wrote "There is no "trust problem", and then, ""As far as a protocol is
concerned, there is no such thing as trust." And yet, YOU want to "handle
violations of trust" as you just wrote.
Also, to be coherent, you cannot expect to solve the "accountability
problem" if you have procedures which not only are unaccountable for but
also totally neglects accountability.
-> For this, you need authentication,
-> authorization, delegation, auditability, and a sanctions mechanism. SPKI
-> provides the first three.
That is the point. If "authorization" and "delegation" use *your*
signature in order to satisfy someone's heart content then this is not
"authorization" or "delegation".
You may call it "disaster" or, if you wish, follow Humpty-Dumpty and
continue to call them "authorization" and "delegation" ;-)
Again, further tools are needed to handle this problem and this linear
approach will just not work. Why can't other tools be introduced, if the
current linear procedure leads to immediate contradictions?
Yours,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@laser.cps.softex.br
http://novaware.cps.softex.br
P.O.Box 1201, CEP13001-970, Campinas-SP, Brazil - Fax: +55-19-2429533
References: