trust is not associative

Ed Gerck egerck at nma.com
Wed Jul 16 11:55:35 EDT 2003


>

The thread "Announcing httpsy://, a YURL scheme"  has not dealt with the
issues of *order of introduction* that, however, play a major role in terms
of introduction and the development of trust.

Let trust be the operation *.

Suppose Jon trusts a CA and has his 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,         (1)

which is Ok because Jon trusts the CA before the CA trusts Khadaffi, and thus
Jon gets his cert from that CA. This means that Jon accepts to be introduced
by the 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 (e.g., simulating an error).
Then, if Jon does not trust Khadaffi, he will not have his cert
issued by that CA.

This is now represented by the result of

    Jon*(CA*Khadaffi),     (2)

which is not Ok and Jon does not get his extrinsic cert from that CA.
This means that Jon DOES NOT accept to be introduced by the CA.

Of course, the result of (1) is not equal to (2). Trust depends on the event
sequence. Trust is not associative.

The same could be exemplified for competing businesses or competing
countries, as I comment in the paper at http://www.mcg.org.br/cie.htm

Or, you may trust your lawyer before you know he trusts your competitor
but not after you know it. Of course, you may never know that an untrustworthy
C of (A*B)*C exists (i.e., the confidence-leak problem) and you may forever trust
Aldrich Ames!

In short, a system that ignores that trust is not associative can make you rely on an
otherwise unacceptable introduction. OTOH, a system that makes you rely on
a single introduction is essentially setting you up for a single point of failure.

Cheers,
Ed Gerck


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list