[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: KeyNote draft available
Matt Blaze writes:
> 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.
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.
>
> 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.
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:
TRUST-PREDICATE: (($app_domain="NUKE") &&
($action="launch") &&
($delivery_system="missile") &&
(($target="moscow") || ($target="london")))
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
> 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.
>
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.
> 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.
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
> "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).
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....
>
> 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.
>
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
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
--- Visit the Meta-Certificate Group at http://mcg.org.br ---
References: