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