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

Re: KeyNote draft available


I can't agree with your objections:

The word "trust" as you have tried to explain below implies "relying" on some 
external system to do something.  That does not mean that there are not 
unreliable trusts, but that you are "relying" on an outside source to perform 
something for you.  Whether it gets done properly or not is outside of the 
context.  Basically, you're passing the buck and you better be sure that where 
ever you pass it to will do the job properly.  Thus reliability of trusts 
becomes an issue that needs to be contended with.

But, back to the word "trust" doesn't imply anything else.  Your quoted example 

TRUST-PREDICATE: (($app_domain="NUKE") &&

only implies that you are trusting on the application domain "NUKE" to launch 
the missile to the desired target.  Whether it actually launches it or not means
 nothing.  You are trusting the "NUKE" application domain to perform the task 
that you sent it and nothing more.  It must also "trust" you to send it valid 
operations as well.  Thus trust relationships are born.

FWIW
Walter Benton
___________________________________ 返信 _______________________________________
件名: KeyNote draft available
送信者:  "E. Gerck" <egerck@laser.cps.softex.br> at &NWS-Internet
日付:    98/03/14 11:29


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                     egerck@novaware.cps.softex.br http://
novaware.cps.softex.br
    --- Visit the Meta-Certificate Group at http://mcg.org.br ---