Subject: KeyNote draft available

From: "E. Gerck" <[email-masked]>
Date: Fri, 13 Mar 1998 23:29:27 -0300

Matt Blaze writes:
 > We have just released a new internet draft describing KeyNote, a trust
 > management system designed to support PKI applications.  KeyNote is
 > based on PolicyMaker, with simplfied features optimized specifically
 > for the PKI problem.  We believe KeyNote provides a simple mechanism
 > that addresses many of the issues of concern to the SPKI group.  We'll
 > be presenting KeyNote in L.A.
 >

I think this document has serious flaws and should be recalled.

When KeyNote considers delegation of trust and its management it
follows the earlier model of "Decentralized Trust Management" -- which
ignores the properties of trust (cf
http://www.mcg.org.br/trustprop.txt) and instead follows an ad hoc
concept of "trust" and its properties. Such concept, which has little
to do with the meaning that the word trust would have in a linguistic
or social context, is not self-consistent either.

In particular, the notion of delegation of trust is flawed, as
evidenced by the following paragraph:

     The TRUST-PREDICATE expression is evaluated.  If the result is
     boolean TRUE, and the key expression in the KEY-PREDICATE 
     field is also true, the request is approved.  Otherwise, it is 
     rejected.

which highlights the use of boolean expressions to evaluate
TRUST-PREDICATE... however, trust does NOT follow a boolean algebra,
as is well known in certificate and security applications (see also
the reference given above).

Further, when the document says:

 TRUST-PREDICATE: (($app_domain="NUKE") &&
                          ($action="launch") &&
                          ($delivery_system="missile") &&
                          (($target="moscow") || ($target="london")))

then we see that what the document calls "trust-predicate" has little
to do with what one would call a predicate of trust in any meaningful
way.

Thus, the document is misleading in its use of the word trust and
should either be changed throughout so that "trust" reads
authorization (for example) and correcting other logical problems or
should not be submitted to the IETF. In any case, it should be
recalled as it is.

Cheers,

Ed 
______________________________________________________________________
Dr.rer.nat. E. Gerck                     [email-masked]
http://novaware.cps.softex.br
    --- Visit the Meta-Certificate Group at http://mcg.org.br ---

---

From: Matt Blaze <[email-masked]>
Date: Fri, 13 Mar 1998 22:24:36 -0500

I must confess that I don't quite understand your point.  You seem to
be objecting to the use of the term "trust" in conjunction with
predicates that delegate from one key to another the permission to
perform specific security actions.

While I would be the first to agree that the word "trust" can be used
to describe concepts other than this, we use the word "trust" as a
technical term.  It is not at all unusual for words to have a meaning
as a technical term-of-art that are rather different from their
connotations in informal or non-technical language.  Indeed, computer
science is full of such terms; consider "reliable," "trivial," "large,
and "fair," for starters.

Here, we use "trust" in a technical sense, not in a social or
political sense.  In particular, we use the word in the sense of
"trusted system", and, especially, "trust management," a term we
introduced in our original PolicyMaker paper to refer to the problem
of describing (and containing) the extent to which other parties are
permitted to perform security-critical actions.  You suggest the term
"authorization," which is also a good word, but we used "trust
management" because that phrase is beginning to be fairly widely
understood by the technical community (there has been at least one
conference on the subject, and it has appeared in several
calls-for-papers, for example).

In any event, we think KeyNote provides a very simple mechanism that
is flexible enough to addresses many of the issues of concern to the
SPKI charter, and we hope to stimulate discussion on our direction.

-matt

---

From: "E. Gerck" <[email-masked]>
Date: Sat, 14 Mar 1998 02:11:06 -0300

> perform specific security actions.

My point is simple. I object to let a word be used in technical
situations where the word's intended usage diverges from its usual
technical understanding -- which frontally speaks agains any hope for
standardization. Such was the case for the word "trust" in this work,
hence my objection.

It is technically understood that "trust is not transitive" since PGP
questioned the PEM model several years ago and stated a well-known
comparison which I will rephrase as  "The fact that I trust my
brother to drive my car does not mean that I must trust the friends
he trusts to do the same".

It is also technically understood and so *implemented* in softeware in
wide use today -- such as Apache/SSL -- that trust is not transitive
and so trust chains should stop at depth one, lest it becomes leap of
faith chains...

It has also been published -- and NOT contested, rather reaffirmed -- 
since July 8th, 1997 that trust (in the technical sense in
communication protocols and certification) is actually neither
transitive, nor distributive, nor symmetric
[http://www.mcg.org.br/trustprop.txt]. 

Further, it was discussed in this forum last year the consequences of
such technical security constraints, as well as currently, which will
be exemplified below.

 > technical term.

As above, it is exactly as a technical term in the context of security
protocols that trust has been shown NOT to follow boolean
algebra. However, the use of trust or trust predicates in the proposed
work RELIES UPON boolean expressions such as:

and several other boolean constructs, which are simply not warranted
if you want to call that trust... but, which may be correct and indeed
useful if you call it something else that would obey a boolean algebra
-- such as authorization or delegation  -- and so properly explained.

 >It is not at all unusual for words to have a meaning

You are right to the limited extent that it is academically valid to
define anything as anything, however as cited above the word trust in
the context of security protocols is not too much overly-variable,
even though there are indeed differences in the fine aspects of
different technical definitions -- but none that diverge so much as
your intended use. 

To exemplify the technical feeling for such subject, just a few days
ago the following text from Phill was cited by myself here -- as
written in 1994 but very on the mark regarding your comment above:

"We have two options either we can attempt to define wonderfull academic
forms of trust model de novo. Or we can observe the real world and attempt
to model the trust mechanisms that allow it to function. Since we do not
see a hierarchical trust model it is not the solution. We do not see
anarchy either, or at least in places where it has taken hold it is
disaster.What we see is binary interpersonal relationships heavily
qualified in manyways. The approach that has always seemed most promising
to me is to replicate those relationships allowing them full colour with
respect to the areas for which trust is granted (finacial, notarial,
reliability etc), the extent of such trust and the confidence with which
that trust is allowed."

In the almost four years (an eternity in Internet time) that passed
since that comment  which was contextually based on PGP, such view has
in fact consolidated itself as I commented above to the extent that it
is rather common nowadays to consider that trust is not transitive --
hence not boolean.

Regarding the other properties of trust already mentioned (not
distributive and not symmetric), I would also add that technical
trust cannot be regarded as objective either (as implied in your
work I am commenting on) but has to be treated as inter-subjective
[http://www.mcg.org.br/augustine.txt] if one wants to represent
real-world perceptions of it. These three further properties of trust
add several other non-boolean properties to technical trust --
which further invalidates the proposed methodology.

 > permitted to perform security-critical actions.

As above, your use of the technical word trust in the text and in the
boolean expressions of the proposed methodology is not concordant with
its use in widely disseminated security protocols such as PGP and
in security software such as Apache/SSL or in other works. The fact
that is not concordant either with semantics derived from standard
linguistics is a further indication that it cannot be taken as a de
novo definition either (to the fair sense that everything else would be
wrong).

 > You suggest the term

Herein lies the danger of impregnating the word trust with overloaded
meanings. The technical concept of trust -- and trust management --
will become an (eventually transparent) foundation for most of our
communications, and with this transparency will come a degree of
complacency with the technical/linguist/social/political implications
of the policies and assumptions that underly its operations.
(cf today's msg from Tony).

The fact that a past use was not precise and is being further
developed --  with conflicting basic mathematical properties such as
which algebra it obeys to -- is certainly one more reason to correct
the course now, since no one would care to correct something that
had no value.

So, if you pls re-read my former msg you will see that I did not
dismiss it (even though I mentioned without exemplifying that some
logical problems would have to be corrected). Rather, I clearly and
objectively targeted and exemplified its overloaded use of the word
trust -- which contradicted not only earlier accepted technical
understandings and properties of trust in security systems, but
also its linguistic/social use.

I think it must be axiomatic that if a technical concept obeys algebra
A and has properties B, being designated by word XYZ -- then if
another concept does NOT obey algebra A and does NOT have properties
B, it should NOT be called XYZ either....

 > SPKI charter, and we hope to stimulate discussion on our direction.

It could well be but by calling trust what is NOT trust, your proposal
calls upon it three different nemesis:

1. It is inconsistent with previous technical use of the term trust in
security systems in general (though consistent with some of your own
previous work),

2. It is inconsistent with and not needed by SPKI, when it states:

   The first purpose of SPKI certificates is to address the issue of
   "trust" by avoiding the term and instead concentrating on asking what
   a given keyholder is permitted or authorized to do.

3. It is irrevocably mathematically at odds with anything else that
will treat trust as trust, such as not being boolean for example.

That's why -- not to be just a technical criticism but also as a
fruitful discussion between colleagues -- that I suggested the word
"authorization" or "authorization management" if you prefer or
"delegation", which avoid the three problems above and may allow your
paper to be viewed under a coherent technical light now and in the
future, also within current SPKI texts.

Cheers,

Ed

    --- Visit the Meta-Certificate Group at http://mcg.org.br ---