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

What problem are we trying to solve?

Matt Blaze writes:

> [snip]
 > Our solution isn't perfect and would benefet greatly from diverse
 > feedback and broader experience, but I think we at least picked the
 > right problem.

Undoubtly and KeyNote may offer an alternative standard "library"
procedure to introduce a type of high-level script language that
may allow people to do what nowadays is done in bits an pieces
using lower-level tools such as C, Java, Perl, etc.

That is why (based on its potential usefuleness) that I suggested
it was unfortunate that it used the word trust when it meant
authorization -- which is a type of an unnecessary glass roof,
besides being at odds with the SPKI terminology in the current
drafts and clashing with the use of the word trust in other
security applications.

For example:

1. when the submitted draft talks about "delegating trust" as in
"A policy that deligates trust for the 'SPEND' application domain",
whereas it is clear that trust cannot be delegated (neither social nor
technical -- for example, can a CA delegate trust to another CA?).
You may clearly "delegate authorization", however, and CA1 may
delegate an authorization to CA2 for some purposes.

So, changing trust --> authorization in that (and similar) phrase
makes it clear that the "SPEND" application is authorized by
"policy" to perform some action without any need to consult
"policy". Which is quantitative and objective.

2. when the draft uses boolean logic to calculate "trust-predicates",
whereas we know that trust is NOT boolean (hence, e.g., the
PKI quagmire).

and other points, which motivate a simple change to "authorization".

That's why also I suggested a quick correction. Everything else stays
the same and the draft can be evaluated by its content, not by its

Thank you,


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