rfc2704.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   That is, an <AttributeID> begins with an alphabetic or underscore
   character and can be followed by any number of alphanumerics and
   underscores.  Attribute names are case-sensitive.



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


   The exact mechanism for passing the action attribute set to the
   compliance checker is determined by the KeyNote implementation.
   Depending on specific requirements, an implementation may provide a
   mechanism for including the entire attribute set as an explicit
   parameter of the query, or it may provide some form of callback
   mechanism invoked as each attribute is dereferenced, e.g., for access
   to kernel variables.

   If an action attribute is not defined its value is considered to be
   the empty string.

   Attribute names beginning with the "_" character are reserved for use
   by the KeyNote runtime environment and cannot be passed from
   applications as part of queries.  The following special attribute
   names are used:

       Name                        Purpose
       ------------------------    ------------------------------------
       _MIN_TRUST                  Lowest-order (minimum) compliance
                                   value in query; see Section 5.1.

       _MAX_TRUST                  Highest-order (maximum) compliance
                                   value in query; see Section 5.1.

       _VALUES                     Linearly ordered set of compliance
                                   values in query; see Section 5.1.
                                   Comma separated.

       _ACTION_AUTHORIZERS         Names of principals directly
                                   authorizing action in query.
                                   Comma separated.

   In addition, attributes with names of the form "_<N>", where <N> is
   an ASCII-encoded integer, are used by the regular expression matching
   mechanism described in Section 5.

   The assignment and semantics of any other attribute names beginning
   with "_" is unspecified and implementation-dependent.

   The names of other attributes in the action attribute set are not
   specified by KeyNote but must be agreed upon by the writers of any
   policies and credentials that are to inter-operate in a specific
   KeyNote query evaluation.








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


   By convention, the name of the application domain over which action
   attributes should be interpreted is given in the attribute named
   "app_domain".  The IANA (or some other suitable authority) will
   provide a registry of reserved app_domain names.  The registry will
   list the names and meanings of each application's attributes.

   The app_domain convention helps to ensure that credentials are
   interpreted as they were intended.  An attribute with any given name
   may be used in many different application domains but might have
   different meanings in each of them.  However, the use of a global
   registry is not always required for small-scale, closed applications;
   the only requirement is that the policies and credentials made
   available to the KeyNote compliance checker interpret attributes
   according to the same semantics assumed by the application that
   created them.

   For example, an email application might reserve the app_domain
   "RFC822-EMAIL" and might use the attributes named "address" (the
   email address of a message's sender), "name" (the human name of the
   message sender), and any "organization" headers present (the
   organization name).  The values of these attributes would be derived
   in the obvious way from the email message headers.  The public key of
   the message's signer would be given in the "_ACTION_AUTHORIZERS"
   attribute.

   Note that "RFC822-EMAIL" is a hypothetical example; such a name may
   or may not appear in the actual registry with these or different
   attributes.  (Indeed, we recognize that the reality of email security
   is considerably more complex than this example might suggest.)

4.  KeyNote Assertion Syntax

   In the following sections, the notation [X]* means zero or more
   repetitions of character string X.  The notation [X]+ means one or
   more repetitions of X.  The notation <X>* means zero or more
   repetitions of non-terminal <X>.  The notation <X>+ means one or more
   repetitions of X, whereas <X>? means zero or one repetitions of X.
   Nonterminal grammar symbols are enclosed in angle brackets.  Quoted
   strings in grammar productions represent terminals.

4.1  Basic Structure

       <Assertion>:: <VersionField>? <AuthField> <LicenseesField>?
                     <LocalConstantsField>? <ConditionsField>?
                     <CommentField>? <SignatureField>? ;

   All KeyNote assertions are encoded in ASCII.




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


   KeyNote assertions are divided into sections, called `fields', that
   serve various semantic functions.  Each field starts with an
   identifying label at the beginning of a line, followed by the ":"
   character and the field's contents.  There can be at most one field
   per line.

   A field may be continued over more than one line by indenting
   subsequent lines with at least one ASCII SPACE or TAB character.
   Whitespace (a SPACE, TAB, or NEWLINE character) separates tokens but
   is otherwise ignored outside of quoted strings.  Comments with a
   leading octothorp character (see Section 4.2) may begin in any
   column.

   One mandatory field is required in all assertions:

      Authorizer

   Six optional fields may also appear:

      Comment
      Conditions
      KeyNote-Version
      Licensees
      Local-Constants
      Signature

   All field names are case-insensitive.  The "KeyNote-Version" field,
   if present, appears first.  The "Signature" field, if present,
   appears last.  Otherwise, fields may appear in any order.  Each field
   may appear at most once in any assertion.

   Blank lines are not permitted in assertions.  Multiple assertions
   stored in a file (e.g., in application policy configurations),
   therefore, can be separated from one another unambiguously by the use
   of blank lines between them.

4.2  Comments

      <Comment>:: "#" {ASCII characters} ;

   The octothorp character ("#", ASCII 35 decimal) can be used to
   introduce comments.  Outside of quoted strings (see Section 4.3), all
   characters from the "#" character through the end of the current line
   are ignored.  However, commented text is included in the computation
   of assertion signatures (see Section 4.6.7).






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


4.3  Strings

   A `string' is a lexical object containing a sequence of characters.
   Strings may contain any non-NUL characters, including newlines and
   nonprintable characters.  Strings may be given as literals, computed
   from complex expressions, or dereferenced from attribute names.

4.3.1  String Literals

      <StringLiteral>:: "\"" {see description below} "\"" ;

   A string literal directly represents the value of a string.  String
   literals must be quoted by preceding and following them with the
   double-quote character (ASCII 34 decimal).

   A printable character may be `escaped' inside a quoted string literal
   by preceding it with the backslash character (ASCII 92 decimal)
   (e.g., "like \"this\".").  This permits the inclusion of the double-
   quote and backslash characters inside string literals.

   A similar escape mechanism is also used to represent non-printable
   characters.  "\n" represents the newline character (ASCII character
   10 decimal), "\r" represents the carriage-return character (ASCII
   character 13 decimal), "\t" represents the tab character (ASCII
   character 9 decimal), and "\f" represents the form-feed character
   (ASCII character 12 decimal).  A backslash character followed by a
   newline suppresses all subsequent whitespace (including the newline)
   up to the next non-whitespace character (this allows the continuation
   of long string constants across lines).  Un-escaped newline and
   return characters are illegal inside string literals.

   The constructs "\0o", "\0oo", and "\ooo" (where o represents any
   octal digit) may be used to represent any non-NUL ASCII characters
   with their corresponding octal values (thus, "\012" is the same as
   "\n", "\101" is "A", and "\377" is the ASCII character 255 decimal).
   However, the NUL character cannot be encoded in this manner; "\0",
   "\00", and "\000" are converted to the strings "0", "00", and "000"
   respectively.  Similarly, all other escaped characters have the
   leading backslash removed (e.g., "\a" becomes "a", and "\\" becomes
   "\").  The following four strings are equivalent:

        "this string contains a newline\n followed by one space."
        "this string contains a newline\n \
        followed by one space."







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


        "this str\
           ing contains a \
             newline\n followed by one space."

        "this string contains a newline\012\040followed by one space."

4.3.2  String Expressions

   In general, anywhere a quoted string literal is allowed, a `string
   expression' can be used.  A string expression constructs a string
   from string constants, dereferenced attributes (described in Section
   4.4), and a string concatenation operator.  String expressions may be
   parenthesized.

       <StrEx>:: <StrEx> "." <StrEx>    /* String concatenation */
               | <StringLiteral>        /* Quoted string */
               | "(" <StrEx> ")"
               | <DerefAttribute>       /* See Section 4.4 */
               | "$" <StrEx> ;          /* See Section 4.4 */

   The "$" operator has higher precedence than the "." operator.

4.4  Dereferenced Attributes

   Action attributes provide the primary mechanism for applications to
   pass information to assertions.  Attribute names are strings from a
   limited character set (<AttributeID> as defined in Section 3), and
   attribute values are represented internally as strings.  An attribute
   is dereferenced simply by using its name.  In general, KeyNote allows
   the use of an attribute anywhere a string literal is permitted.

   Attributes are dereferenced as strings by default.  When required,
   dereferenced attributes can be converted to integers or floating
   point numbers with the type conversion operators "@" and "&".  Thus,
   an attribute named "foo" having the value "1.2" may be interpreted as
   the string "1.2" (foo), the integer value 1 (@foo), or the floating
   point value 1.2 (&foo).

   Attributes converted to integer and floating point numbers are
   represented according to the ANSI C `long' and `float' types,
   respectively.  In particular, integers range from -2147483648 to
   2147483647, whilst floats range from 1.17549435E-38F to
   3.40282347E+38F.

   Any uninitialized attribute has the empty-string value when
   dereferenced as a string and the value zero when dereferenced as an
   integer or float.




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


   Attribute names may be given literally or calculated from string
   expressions and may be recursively dereferenced.  In the simplest
   case, an attribute is dereferenced simply by using its name outside
   of quotes; e.g., the string value of the attribute named "foo" is by
   reference to `foo' (outside of quotes).  The "$<StrEx>" construct
   dereferences the attribute named in the string expression <StrEx>.
   For example, if the attribute named "foo" contains the string "bar",
   the attribute named "bar" contains the string "xyz", and the
   attribute "xyz" contains the string "qua", the following string
   comparisons are all true:

    foo == "bar"
    $("foo") == "bar"
    $foo == "xyz"
    $(foo) == "xyz"
    $$foo == "qua"

   If <StrEx> evaluates to an invalid or uninitialized attribute name,
   its value is considered to be the empty string (or zero if used as a
   numeric).

   The <DerefAttribute> token is defined as:

      <DerefAttribute>:: <AttributeID> ;

4.5  Principal Identifiers

   Principals are represented as ASCII strings called `Principal
   Identifiers'.  Principal Identifiers may be arbitrary labels whose
   structure is not interpreted by the KeyNote system or they may encode
   cryptographic keys that are used by KeyNote for credential signature
   verification.

       <PrincipalIdentifier>:: <OpaqueID>
                             | <KeyID> ;

   4.5.1  Opaque Principal Identifiers