[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On the nature of trust

On Fri, 23 Jan 1998, Tony Bartoletti wrote:

-> Ed,
-> I found your short argument good reading and I am generally in agreement.
-> I believe, however, that much argument may follow simply from the choice
-> of the term "trust".  In common english usage, the term most often signifies
-> "that which one does not know, but is 'banking on'" as in "I trust that the
-> U.S. government will not fall tomorrow morning, the sun will come up, etc."
-> One almost universally says "I trust ..." to things one cannot actually know
-> with certainty at the time (else one would say "I know ...").

The word "trust" was chosen exactly on semantic grounds for the English
language. Linguistically, "Trust" is akin to "true" and "faithful", with a
usual first dictionary meaning of "1 a : assured reliance on the 
character, ability, strength, or truth of someone or something b : one in
which confidence is placed."

So, in common English usage trust is what you place your confidence in or,
expect to be truthful.

In that sense it is also used in cryptography, when we say "trusted cert"
or "trusted key". 

The point that has everyone mired in the muck is that when we (as
cryptographers and information scientists) are speaking about "trust" in a
communication channel and meaning something very specific, everyone else
is thinking about things such as "legal warranty" (a lawyer), "employee
loyalty" (employers), "clearance"  (government officials), etc. 

So, akin to "information" in information theory, we can very well (and,
indeed we must) find a "real-world" model of trust that allow us to make a
clean cut and be precise. So, "trust" and "information" in IT have nothing
to do with concepts such as knowledge or meaning. 

"Trust" as defined in the posting is not what you know  -- that was just
(loosely speaking, as warned) a way to make a comparison with
"information" being what you don't  know (which is not strictly correct in
IT, either). Because, as I comment below, trust can decay or disappear --
which knowledge can never do (it can get outdated or impossible to access
as in sclerosis, but that is not the same as loosing trust on your
supplier because you find out he is Aldrich Ames).

-> In contrast, your use of the term refers, loosely speaking, to that which
-> one already knows (no possible surprise, risk, etc.)  If I were to take your
-> document and globally replace the term "trust" with "knowledge" then I am
-> certain that few if any could find a point of argument.

But it would not allow trust to decay with time, for example, or to
disappear (see ref.5 of the original posting) becaus eit is not

This is a very important point, and may be a common question. The
knowledge you acquire is static, you know that the Sun is hot and that
will not change. The trust you acquire can change abruptly at any moment,
it can increase, it can decrease. Hence, trust is not knowledge, not even

-> Beyond this, your point that, in essence, trust (knowledge) is the medium,
-> not the message, is an insightful and useful point of view.  However, when
-> virtual machines, pipes and their data are both software, it will be an
-> uphill battle to keep this border distinct.  Perhaps that is your point.

Entropy enters the picture here. If you could keep trust untainted by
information then everything would be fine. However, as argued, that would
be death, isolation. You must allow risk to raise its ugly head,
counterpoint it with cost and define a soft-trust model that warrants a
critical radius of trust which is adequate in space and **time** to your
needs, regarding the different entropy generators you admit in your threat

So, this is not anymore guess-work or black art but can be estimated and
designed. Truly, other layers such as the laws of Birmania must be taken
in ... but only *after* the IT trust layer is designed and insofar as you
want to sell to Birmania... 



Dr.rer.nat. E. Gerck                     egerck@novaware.cps.softex.br
    --- Visit the Meta-Certificate Group at http://mcg.org.br ---