[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: definition of cert - trust in SPKI certs
On Fri, 23 May 1997, Brian M. Thomas wrote:
-> >
-> > However, trust is not transitive.
-> >
->
-> My involvement in SPKI arose because of issues of this nature. Trust is
-> transitive to the extent that I (as verifier) say that it is transitive.
But you can't logically say that and -- worse -- you cannot allow everyone
to say that about everyone, which is what you do when you write a
standard. If you want to delegate, fine -- but you need higher rules,
stricter logic, checks & balances, "sand-boxes", etc.
Otherwise, wishful thinking would amount actually to a complete
derrogation of trust, by going full circle back.
I certainly would never wish to enforce a standard that says you MUST
trust Khadaffi on matters of X because you trust your boss on matters of X
and he trusts Khadaffi on matters of X!
Neither would I say you MAY, because if YOU are not careful MY security
would be compromised.
Again, higher tools and methods must be used so the appropriate boundary
conditions are enforced.
Delegation is necessary but, IMHO, cannot be viewed as "transitive trust".
It is much more complicated.
I think that SPKI did a pioneering work by discussing that -- however, the
provided tools and models are not sufficient to actually deploy it as they
are today. There are logical problems and that's what I will try to show
in the next (long) lines.
Please forgive the emphasis. Just see lots of ;-)
-> Tony and Bill's responses are useful in illustrating this, but my bit is
-> that the primary purpose of a certificate is to convey my wishes as user
-> to my software agents in cyberspace. The point is that trust is not
-> *implicitly* transitive, but *explicitly*.
->
I agree with that if you say: "if trust is transitive then it must be
explicitly transitive". Herein lurks the danger. You explicitly say you
trust the unknown -- yes, because the recipient of your delegation
can do whatever he wishes with that and only God (or the Shadow) would
know what lurks in his heart.
To allow that to go unchecked is to invite disaster, someday, sooner or
later.
-> If I issue a certificate to Jon as Bank President, then I accept full
-> responsibility for my program's trust in his key. The nature of the
-> role of "Bank President" which I entrust to him by the certificate is
-> such that I am explicitly trusting those whom he certifies in roles
-> relating to his role. I would not be wise to do this in the absence of
-> assurance by him that he stands behind the actions of every key that he
-> certifies in this context. In turn, he would not issue such assurances
-> without assurances to him of the employee's trustworthiness and, as a
-> final safeguard, a bonding agreement, which the bonding company would
-> not offer without assurances of its own which it gains by background
-> checks; etc.
And all that will be assured, legally bonding, understood perfectly and
known to all parties over 10 seconds of Internet certification to a site
in Moldavia!
Besides, if one of his employees is Aldrich Ames -- who was very
"trustworthy" and had all the proper "credentials" -- then the insurance
company pays and we all pitch in for a higher policy cost.
"Law is no substitute for engineering" now has been reversed, because we
just forget about the rules of logic, about the principle of avoiding a
leap-of-faith, about good design, cross our fingers and say: Hope for the
best! If the worse comes, sue!
On the contray, I think that wishful thinking is no substitute for
engineering and that if we want to delegate, higher rules must come into
play.
->
-> Note that none of that participates in the structure of the certificate,
-> but each party, aware of that to which he commits thereby, gathers
-> assurances satisfactory to himself and appropriate to the risks
-> involved, and certifies others appropriately. Nothing in certificate
-> structures or protocols can replace this process, but they merely
-> allow me to execute what I have already chosen to believe, including
-> trusting others to convey trust. As Bill points out, this is easy to
-> lose control over, but it is what is intended.
->
->
-> > This means that you could trust 100% the issuer's key as authoritative to
-> > do the binding of another key (the subject) to an auth field under the
-> > validation hypothesis and, yet, you do not trust that other key (ie, the
-> > subject) in relationship to those attributes in the auth field.
-> >
->
-> > In other words, the fact that you trust Jon as the Bank President does not
-> > mean that you must trust Mary as your account manager -- as she was just
-> > appointed by him! So, you cannot accept Jon's certificate -- even though
-> > it is a valid certificate by SPKI's rules.
->
-> The role of Bank President means *exactly* that in the real world; certificates
-> merely extend that to cyberspace. Jon's appointment of Mary to her position
-> is consummated by papers signed by him authorising her in this role. These
-> papers are satisfactory enough evidence of his conveyance of authority that
-> if she misbehaves in her role he can be held legally liable, for negligence
-> if not for complicity.
Yes, but she may be in vacation when he did that, she may have just asked
for a dismissal a minute ago because she didn't trust the Bank anymore,
she may have been arrested last night for Bank theft, and God knows what
.. but you don't!
The fact that he has a legal right to appoint her (and you accept that
right by signing his key in that capacity) does not mean that she didn't
quit the minute before or after. Further, it does not mean you will
blindly trust your life's savings to a newly appointed Bank employee.
Or even an old one, as history has shown over and over.
->
-> > Another point is that Mary may not have agreed with Jon's appointment and
-> > the verifier has no way of knowing this because the certificate is signed
-> > by Jon only.
-> >
->
-> If she acts in the appointed role, thus giving me the opportunity to choose
-> whether to trust her, her feelings about the job are moot; functionally
-> speaking, she agrees with the appointment, QED.
->
It is not a question of feelings -- she may be unware of it. She may even
be fired a minute after or earlier. She may not be legally qualified but
she lied to get a job. Whatever ...
->
-> > However, if Mary also co-signs the certificate that still proves nothing
-> > because the verifier has no way of knowing that Mary *is* Mary -- say, by
-> > independent channels of information and must only trust Jon, again.
->
-> The verifier believes that Mary's *key* is Mary, and more importantly,
-> is someone duly authorised to act on the bank's behalf, because Jon said
-> so, and because I said I would trust Jon when he did.
->
How would the verifier -- who does not know Mary -- believe that Mary's
*key* is Mary's? Further, how would the verifier -- who has trusted Jon --
know that Jon can still be trusted?
Finally, what would be the total probability of the conditional chain that
Mary *is* Mary, that Mary's key *is* Mary's, that Mary *is* also duly
authorized by Jon, that Mary has legally accepted that (constitutional
rights of denial?) and that Jon is doing that according to a higher
authorization from a State law that says that Mary must have a type of
degree for that?
It is impossible to compute, some say. Then, since it is impossible,
trust, enforce laws and wish for the best. But, that is not trust -- it is
wishful thinking.
Here, as an example of a direction one might go, Dempster-Shafer theory
says differently. It says that instead of trying to compute the
probability of the conditional chain above, you should compute the
probability that the evidence supports the chain. Because you have no
evidence either way, you have to say that your belief on this chain is
zero.
So, I feel that higher rules must be brought into the picture, with other
mechanisms for checks & balances if we want to abandon chance as an
"element of trust". Gauge-theory, Dempster-Shafer theory, trust theory,
etc. must be used to cope with the devil you have uncorked!
-> >
-> > -> How the trust in that issuer's
-> > -> key is established is outside the scope of this one certificate.
-> > ->
-> >
-> > This is an interesting question, because as the certificate does not say
-> > that -- how and to what effect trust was established -- it is difficult
-> > for the verifier to "remember" exactly how it was that such trust was
-> > established and what are its limits, both in time as well as in scope.
->
-> Such questions are outside the capacity of my dull and ignorant cyber-agents,
-> and thus outside the scope of certificate structures. If I say I trust
-> someone, I expect my program to carry out that trust, not to judge whether
-> I should have done so. I'm still in charge here, not some automaton.
->
That's not my point. What I said was that the verifier -- you -- had no
way of knowing or remembering how such trust was established, its limits,
and so on. This would be crucial in a site that gets hundreds of visits a
minute, or per hour.
->
-> I chose not to respond in detail to the rest of your note, not from
-> lack of interest but lack of time. The thrust of it seems to be, as
-> above, on mechanising means of assurance in order to establish trust.
-> This is, of course, an interesting topic, and should be pursued
-> further. The pages you mention offer a forum for this, which I believe
-> I will follow. However, we must separate high-level from low-level
-> questions, and SPKI, as a certificate structure, does not and should
-> not deal in those issues. PolicyMaker, being a robust and flexible,
-> if computationally more expensive, mechanism, comes a long way into
-> that realm, and we have often proposed strategies which incorporate
-> it in SPKI deployments. MCs may go beyond this, but it's new ground.
->
Well, thanks for the chat. To summarize:
I feel that higher rules must be brought into the picture, with other
mechanisms for checks & balances if we want to abandon chance as an
"element of trust" -- which is what we do if we think that trust can be
transitive.
Gauge-theory, Dempster-Shafer theory, trust theory, etc. must be used to
cope with the devil you have uncorked!
Lest it gets us on our backs!
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: