rfc2704.txt

RFC 的详细文档！

   The Comment field allows assertions to be annotated with information
   describing their purpose.  It is of the form

       <CommentField>:: "Comment:" <text> ;

   No interpretation of the contents of this field is performed by
   KeyNote.  Note that this is one of two mechanisms for including
   comments in KeyNote assertions; comments can also be inserted
   anywhere in an assertion's body by preceding them with the "#"
   character (except inside string literals).

4.6.7  The Signature Field

   The Signature field identifies a signed assertion and gives the
   encoded digital signature of the principal identified in the
   Authorizer field.  The Signature field is of the form:

       <SignatureField>:: "Signature:" <Signature> ;

       <Signature>:: <StrEx> ;

   The <Signature> string should be of the form:

       <IDString>:: <ALGORITHM>":"<ENCODEDBITS> ;

   The formats of the "ALGORITHM" and "ENCODEDBITS" substrings are as
   described for Cryptographic Principal Identifiers in Section 4.4.2
   The algorithm name should be the same as that of the principal
   appearing in the Authorizer field.  The IANA (or some other suitable
   authority) will provide a registry of reserved names.  It is not
   necessary that the encodings of the signature and the authorizer key
   be the same.

   If the signature field is included, the principal named in the
   Authorizer field must be a Cryptographic Principal Identifier, the
   algorithm must be known to the KeyNote implementation, and the
   signature must be correct for the assertion body and authorizer key.

   The signature is computed over the assertion text, beginning with the
   first field (including the field identifier string), up to (but not
   including) the Signature field identifier.  The newline preceding the
   signature field identifier is the last character included in
   signature calculation.  The signature is always the last field in a
   KeyNote assertion.  Text following this field is not considered part
   of the assertion.




Blaze, et al.                Informational                     [Page 18]

RFC 2704          The KeyNote Trust-Management System     September 1999


   The algorithms for computing and verifying signatures must be
   configured into each KeyNote implementation and are defined and
   documented separately.

   Note that all signatures used in examples in this document are
   fictitious and generally much shorter than would be required for
   security in practice.

5.   Query Evaluation Semantics

   The KeyNote compliance checker finds and returns the Policy
   Compliance Value of queries, as defined in Section 5.3, below.

5.1  Query Parameters

   A KeyNote query has four parameters:

   *  The identifier of the principal(s) requesting the action.

   *  The action attribute set describing the action.

   *  The set of compliance values of interest to the application,
      ordered from _MIN_TRUST to _MAX_TRUST

   *  The policy and credential assertions that should be included in
      the evaluation.

   The mechanism for passing these parameters to the KeyNote evaluator
   is application dependent.  In particular, an evaluator might provide
   for some parameters to be passed explicitly, while others are looked
   up externally (e.g., credentials might be looked up in a network-
   based distribution system), while still others might be requested
   from the application as needed by the evaluator, through a `callback'
   mechanism (e.g., for attribute values that represent values from
   among a very large namespace).

5.1.1  Action Requester

   At least one Principal must be identified in each query as the
   `requester' of the action.  Actions may be requested by several
   principals, each considered to have individually requested it.  This
   allows policies that require multiple authorizations, e.g., `two
   person control'.  The set of authorizing principals is made available
   in the special attribute "_ACTION_AUTHORIZERS"; if several principals
   are authorizers, their identifiers are separated with commas.






Blaze, et al.                Informational                     [Page 19]

RFC 2704          The KeyNote Trust-Management System     September 1999


5.1.2  Ordered Compliance Value Set

   The set of compliance values of interest to an application (and their
   relative ranking to one another) is determined by the invoking
   application and passed to the KeyNote evaluator as a parameter of the
   query.  In many applications, this will be Boolean, e.g., the ordered
   sets {FALSE, TRUE} or {REJECT, APPROVE}.  Other applications may
   require a range of possible values, e.g., {No_Access, Limited_Access,
   Full_Access}.  Note that applications should include in this set only
   compliance value names that are actually returned by the assertions.

   The lowest-order and highest-order compliance value strings given in
   the query are available in the special attributes named "_MIN_TRUST"
   and "_MAX_TRUST", respectively.  The complete set of query compliance
   values is made available in ascending order (from _MIN_TRUST to
   _MAX_TRUST) in the special attribute named "_VALUES".  Values are
   separated with commas; applications that use assertions that make use
   of the _VALUES attribute should therefore avoid the use of compliance
   value strings that themselves contain commas.

5.2  Principal Identifier Normalization

   Principal identifier comparisons among Cryptographic Principal
   Identifiers (that represent keys) in the Authorizer and Licensees
   fields or in an action's direct authorizers are performed after
   normalizing them by conversion to a canonical form.

   Every cryptographic algorithm used in KeyNote defines a method for
   converting keys to their canonical form and that specifies how the
   comparison for equality of two keys is performed.  If the algorithm
   named in the identifier is unknown to KeyNote, the identifier is
   treated as opaque.

   Opaque identifiers are compared as case-sensitive strings.

   Notice that use of opaque identifiers in the Authorizer field
   requires that the assertion's integrity be locally trusted (since it
   cannot be cryptographically verified by the compliance checker).

5.3  Policy Compliance Value Calculation

   The Policy Compliance Value of a query is the Principal Compliance
   Value of the principal named "POLICY".  This value is defined as
   follows:







Blaze, et al.                Informational                     [Page 20]

RFC 2704          The KeyNote Trust-Management System     September 1999


5.3.1  Principal Compliance Value

   The Compliance Value of a principal <X> is the highest order
   (maximum) of:

      -  the Direct Authorization Value of principal <X>; and

      -  the Assertion Compliance Values of all assertions identifying
         <X> in the Authorizer field.

5.3.2  Direct Authorization Value

   The Direct Authorization Value of a principal <X> is _MAX_TRUST if
   <X> is listed in the query as an authorizer of the action.
   Otherwise, the Direct Authorization Value of <X> is _MIN_TRUST.

5.3.3  Assertion Compliance Value

   The Assertion Compliance Value of an assertion is the lowest order
   (minimum) of the assertion's Conditions Compliance Value and its
   Licensee Compliance Value.

5.3.4 Conditions Compliance Value

   The Conditions Compliance Value of an assertion is the highest-order
   (maximum) value among all successful clauses listed in the conditions
   section.

   If no clause's test succeeds or the Conditions field is empty, an
   assertion's Conditions Compliance Value is considered to be the
   _MIN_TRUST value, as defined Section 5.1.

   If an assertion's Conditions field is missing entirely, its
   Conditions Compliance Value is considered to be the _MAX_TRUST value,
   as defined in Section 5.1.

   The set of successful test clause values is calculated as follows:

   Recall from the grammar of section 4.6.5 that each clause in the
   conditions section has two logical parts: a `test' and an optional
   `value', which, if present, is separated from the test with the "->"
   token.  The test subclause is a predicate that either succeeds
   (evaluates to logical `true') or fails (evaluates to logical
   `false').  The value subclause is a string expression that evaluates
   to one value from the ordered set of compliance values given with the
   query.  If the value subclause is missing, it is considered to be
   _MAX_TRUST.  That is, the clause




Blaze, et al.                Informational                     [Page 21]

RFC 2704          The KeyNote Trust-Management System     September 1999


       foo=="bar";

   is equivalent to

       foo=="bar" -> _MAX_TRUST;

   If the value component of a clause is present, in the simplest case
   it contains a string expression representing a possible compliance
   value.  For example, consider an assertion with the following
   Conditions field:

       Conditions:
          @user_id == 0 -> "full_access";             # clause (1)
          @user_id < 1000 -> "user_access";           # clause (2)
          @user_id < 10000 -> "guest_access";         # clause (3)
          user_name == "root" -> "full_access";       # clause (4)

   Here, if the value of the "user_id" attribute is "1073" and the
   "user_name" attribute is "root", the possible compliance value set
   would contain the values "guest_access" (by clause (3)) and
   "full_access" (by clause (4)).  If the ordered set of compliance
   values given in the query (in ascending order) is {"no_access",
   "guest_access", "user_access", "full_access"}, the Conditions
   Compliance Value of the assertion would be "full_access" (because
   "full_access" has a higher-order value than "guest_access").  If the
   "user_id" attribute had the value "19283" and the "user_name"
   attribute had the value "nobody", no clause would succeed and the
   Conditions Compliance Value would be "no_access", which is the
   lowest-order possible value (_MIN_TRUST).

   If a clause lists an explicit value, its value string must be named
   in the query ordered compliance value set.  Values not named in the
   query compliance value set are considered equivalent to _MIN_TRUST.

   The value component of a clause can also contain recursively-nested
   clauses.  Recursively-nested clauses are evaluated only if their
   parent test is true.  That is,

       a=="b" ->  { b=="c" -> "value1";
                    d=="e"  -> "value2";
                    true -> "value3"; } ;

   is equivalent to

       (a=="b") && (b=="c") -> "value1";
       (a=="b") && (d=="e") -> "value2";
       (a=="b") -> "value3";




Blaze, et al.                Informational                     [Page 22]

RFC 2704          The KeyNote Trust-Management System     September 1999


   String comparisons are case-sensitive.

   A regular expression comparison ("~=") is considered true if the
   left-hand-side string expression matches the right-hand-side regular
   expression.  If the POSIX regular expression group matching scheme is
   used, the number of groups matched is placed in the temporary meta-
   attribute "_0" (dereferenced as _0), and each match is placed in
   sequence in the temporary attributes (_1, _2, ..., _N).  These
   match-attributes' values are valid only within subsequent references
   made within the same clause.  Regular expression evaluation is case-
   sensitive.

   A runtime error occurring in the evaluation of a test, such as
   division by zero or an invalid regular expression, causes the test to
   be considered false.  For example:

      foo == "bar" -> {
                        @a == 1/0 -> "oneval";    # subclause 1
                        @a == 2 -> "anotherval";  # subclause 2
                      };

   Here, subclause 1 triggers a runtime error.  Subclause 1 is therefore
   false (and has the value _MIN_TRUST).  Subclause 2, however, would be
   evaluated normally.

   An invalid <RegExpr> is considered a runtime error and causes the
   test in which it occurs to be considered false.

5.3.5  Licensee Compliance Value

   The Licensee Compliance Value of an assertion is calculated by
   evaluating the expression in the Licensees field, based on the
   Principal Compliance Value of the principals named there.

   If an assertion's Licensees field is empty, its Licensee Compliance
   Value is considered to be _MIN_TRUST.  If an assertion's Licensees
   field is missing altogether, its Licensee Compliance Value is
   considered to be _MAX_TRUST.

   For each principal named in the Licensees field, its Principal
   Compliance Value is substituted for its name.  If no Principal
   Compliance Value can be found for some named principal, its name is