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