Subject: psreq issue #11: Usage of the term "trust"

From: Pekka Nikander <[email-masked]>
Date: Tue, 11 Mar 2003 13:08:47 +0200

In the current draft we write:

  It should be noted that the term "trust" is used here in a rather
  non-technical and loose manner.  The most appropriate interpretation
  is to consider it as an expression of an organizational or
  collective belief, i.e., an expression of commonly shared beliefs
  about the future behavior of the other involved parties.
  Conversely, the term "trust relationship" denotes a mutual a priori
  relationship between the involved organizations or parties where the
  parties believe that the other parties will behave correctly even in
  the future.  A trust relationship makes it possible to configure
  authentication and authorization information between the parties,
  while the lack of such a relationship makes it impossible to
  pre-configure such information.

Craig Metz comments on this (issue #11):

  Please DO NOT use the term trust in this loose manner. One of the
  single greatest problems I see in the security field is one of
  communication. More specifically, it's often the case that two
  people miscommunicate because they use precise terms for which each of
  them have slightly different understandings of their meanings.
  In crypto security, those slight differences are often critical.
  So it's very important to use the standard definitions strictly AND to
  provide precise background definitions of those terms also as an
  added protection against such miscommunication.

  The whole point of this document is to define trust models, so very
  rigid uses of to trust, trusted, and trusting are important.

  Put more simply, terminology is a huge rat hole, don't fall
  down it.

<wg chair hat off>

Now, while I personally agree with Craig in the large, I disagree
in this specific case.  The draft is a problem statement draft,
and while it defines trust models, it defines them in business
terms, not in technical terms.

Thus, I think it *is* appropriate to use the term in a non-technical
manner.  What comes to the "loose" manner, actually scanning the
document for the word trust gives me the impression that it is *not*
used in a loose manner any more.

Thus, as a document editor, I propose that we resolve this
issue simply by removing the words "and loose" from the paragraph
above.  While this does not change the substance of the document
in any way, it seems to better reflect the true nature of the
usage of the term in the document.

<wg chair hat on>

Do you think this proposed resolution is OK?  Or are there
specific occurances of the words "trust", "trustworthy", or
"trusted", which should be qualified better?

--Pekka Nikander

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 Mar 2003 09:11:43 -0800

I agree with the change you are proposing, and think keeping the word trust is
fine. It is being used at a human level, not cyber level, in this draft.

            jak

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 11 Mar 2003 14:21:13 -0500

For what it's worth, I've also suggested being more precise here.

"Trust" is itself a rather vague word.  

I think it's better to use words like "authorization" and
"delegation", and specify precisely what is authorized and how
authorizations are delegated and..

						- Bill

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Mar 2003 14:03:27 -0800

>>>>> "Pekka" == Pekka Nikander <[email-masked]> writes:
    Pekka> Now, while I personally agree with Craig in the large, I disagree
    Pekka> in this specific case.  The draft is a problem statement draft,
    Pekka> and while it defines trust models, it defines them in business
    Pekka> terms, not in technical terms.

  A compromise is to use a new, nonsense (at least to english speakers)
word.

    Pekka> Do you think this proposed resolution is OK?  Or are there
    Pekka> specific occurances of the words "trust", "trustworthy", or
    Pekka> "trusted", which should be qualified better?

  I'm happy with your solution.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 12 Mar 2003 09:46:23 +0200

> authorizations are delegated and..

Bill,

Your suggestion would be great.  However, I'm afraid I don't
have cycles for that right now.  Would you like to edit the
draft to change the terminology?  Anyone else?   If not, I'll
stick with the t-word in the next version of the draft, and
we'll see what the IESG says.

Now, what comes to the more technical documents, I really think
that we should take care of not using the t-word there.

--Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 12 Mar 2003 09:54:58 +0200

> "trusted", which should be qualified better?

Based on the comments received, I resolved the issue by
removing the words "and loose", as I suggested.

However, I am not very happy with this resolution.  My only
defence is that this document is only a problem statement
document, and we really want to move forward.  Based on my
earlier experience, people rarely really come back to the
problem statement documents once they have been finished.
They work more like a baseline of understanding on what to
do.  The exact problems to solve tend to fluctuate somewhat
during the design process, as people start to understand
better what the issue is all about.

Thus, in order to save cycles for more important tasks,
I won't change the terminology.  However, if someone else
is willing to do that, I am happy to send the source rfc2xml
files for editing.

--Pekka Nikander