Hello Alex;-)... et al ...
The shoe is on the other foot;-)... So to speak.
The problem is not that we should prove the negative, but that those
who claim that trust is transitive should prove that this is true.
Those of us who see how it is false are satisfied to accept and work
within the parameters that are implied.
Those who will not bother to prove their assertions will have to live
with their consequences. It is a simple matter of will.
There is no SHALL implied here.
The problem is that those who will not see, cannot see.
It is their problem to solve, and their consequences to suffer.
We are not interested in pushing on a string.
One can lead a horse to water, but cannot make it drink.
We have presented information to counter the belief that trust is
transitive, but mind control is out of our scope, and we accept this
fact. We trust that others will allow us to also be free of mind
controls imposed by others.
Cheers...\Stef
PS: It has always been intuitively true for me that trust is not
transitive, as long long ago I found that when I trusted some friends
friends, that my trusting was in error, so it is obvious to me.
I am surprised that this is not also true for so many others.
So when I discovered that Ed Gerck had found a formal logical
proof of this fact, we came to form an alliance to spread the word
and also to capitalize on the fact that this opened the doors to new
ways to solve trust problems. That others have not yet figured it
out is, to some extent, a blessing for us.
But then, I have always been somewhat of a maverick, often looking at
the obverse side of things, just out of curiosity. The view from the
other side is often quite interesting, iff you can see it.
The roots of MIME came from this kind of perspective.../S
At 11:03 AM -0500 6/18/02, Alex Audu wrote:
>Ed,
>
>You made some interesting points which leads me to wonder if
>we can define Trust in such a way that its parameters are verifiable,
>then we can verify that it is transitive. In other words, if Jon gets
>a dollar from Mike, and Jon can verify the parameters of the dollar,
>then Jon doesn't care about the "trustworthyness" of Mike's source.
>Or should he?
>
>Regards,
>Alex.
>
>Ed Gerck wrote:
>
> > Stephen Kent wrote:
> >
> > > I feel that the term "trust" is appropriately applied to certs when
> > > the CA is not authoritative for the attributes in the cert, but is
> > > not appropriate when the CA is authoritative.
> >
> > Trust is oftentimes used as a synonym for authorization. This is fine if
> > you have a network, where a trusted user is a user authorized by the
> > sysadmin to do or be something. However, the concept of trust as we
> > have developed and learned to use it for thousands of years in commerce
> > and human communication (like an internet, a network of networks)
> > is much more complex than authorization. Thus, when we replace trust
> > with authorization we lose representation capacity -- we flaten out, so
> > to say, the descriptive capacity of our language.
> >
> > As authorization, trust can be transitive. Money is an authorization
> > for payment and it is surely transitive. However, if trust is taken as
> > representing the usual concept of trust, then it cannot be considered
> > transitive. For example, if I trust my brother this does not mean that I
> > must trust my brother's friends. We cannot grant it to be associative,
> > either. Let me exemplify.
> >
> > Definition 1: (associative)
> > An operation * is associative in the space of {A,B,C} if and only if
> > (A*B)*C = A*(B*C). Example: (3*5)*7 = 3*(5*7)
> >
> > (NOTE: "distributive" in the social sense)
> >
> > Proposition 1: Trust is not associative
> > Proof: Let trust be the operation *. We want to prove that Definition 1 is
> > not obeyed and one counter example will suffice.
> >
> > Suppose Jon trusts a CA and has his PKI cert issued by that CA.
> > After the cert was issued, the CA decides to trust Khadaffi and grants
> > Khadaffi access and control to all of its issued certificate and CRL
> > files, including Jon's of course -- which was already issued. This is
> > represented by the result of (Jon*CA)*Khadaffi, which is Ok because Jon
> > trusts the CA before the CA trusts Khadaffi, and thus gets his PKI
> > cert from that CA.
> >
> > Suppose now that Jon learns beforehand that the CA trusts Khadaffi and all
> > his data will be also know to Khadaffi if he decides to trust that CA and
> > that Khadaffi could revoke his cert at will (eg, simulating an error).
> > Then, if Jon does not trust Khadaffi, he will not have his PKI cert
> > issued by that CA. This is represented by the result of Jon*(CA*Khadaffi),
> > which is not Ok and Jon does not get his PKI cert from that CA.
> >
> > Of course, the result of the first operation is not equal to the second.
> > The same could be exemplified for competing businesses or competing
> > countries.
> >
> > Or, you may trust your lawyer before you know he trusts your competitor
> > but not after you know it, and so on.
> >
> > In summary, trust depends on the event sequence.
> >
> > Of course, you may never know that an untrustworthy C of (A*B)*C exists
> > (ie, the confidence-leak problem) and you may forever trust Aldrich Ames!
> > This is also part of the unsolvable problems of PKI certification,
> > when trust is used as a reference even though it is always relative to
> > unknown assumptions.
> >
> > This means that the only reliable trust is self-trust (which cannot have
> > an unknown C, by hypothesis) and the verifier must be able to decide on
> > the basis of his intrinsic and independent measurements. Further, trust on
> > a third-party is not only always unreliable but it cannot even be reliably
> > estimated (eg, Aldrich Ames).
> >
> > These problems eventually invalidate any PKI scheme which grows beyond
> > a certain "critical radius". And, it also casts serious doubts on
>the validity of
> > delegation and authorization chains if such aspects of trust are
>not taken into
> > account. As they are not, in PKI and in the DNS.
> >
> > Cheers,
> > Ed Gerck