rfc2704.txt

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

   Principal Identifiers that are used by KeyNote only as labels are
   said to be `opaque'.  Opaque identifiers are encoded in assertions as
   strings (see Section 4.3):

       <OpaqueID>:: <StrEx> ;

   Opaque identifier strings should not contain the ":" character.






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


4.5.2  Cryptographic Principal Identifiers

   Principal Identifiers that are used by KeyNote as keys, e.g., to
   verify credential signatures, are said to be `cryptographic'.
   Cryptographic identifiers are also lexically encoded as strings:

       <KeyID>:: <StrEx> ;

   Unlike Opaque Identifiers, however, Cryptographic Identifier strings
   have a special form.  To be interpreted by KeyNote (for signature
   verification), an identifier string should be of the form:

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

   "ALGORITHM" is an ASCII substring that describes the algorithms to be
   used in interpreting the key's bits.  The ALGORITHM identifies the
   major cryptographic algorithm (e.g., RSA [RSA78], DSA [DSA94], etc.),
   structured format (e.g., PKCS1 [PKCS1]), and key bit encoding (e.g.,
   HEX or BASE64).  By convention, the ALGORITHM substring starts with
   an alphabetic character and can contain letters, digits, underscores,
   or dashes (i.e., it should match the regular expression "[a-zA-Z][a-
   zA-Z0-9_-]*").  The IANA (or some other appropriate authority) will
   provide a registry of reserved algorithm identifiers.

   "ENCODEDBITS" is a substring of characters representing the key's
   bits, the encoding and format of which depends on the ALGORITHM.  By
   convention, hexadecimal encoded keys use lower-case ASCII characters.

   Cryptographic Principal Identifiers are converted to a normalized
   canonical form for the purposes of any internal comparisons between
   them; see Section 5.2.

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

4.6  KeyNote Fields

4.6.1  The KeyNote-Version Field

   The KeyNote-Version field identifies the version of the KeyNote
   assertion language under which the assertion was written.  The
   KeyNote-Version field is of the form

       <VersionField>:: "KeyNote-Version:" <VersionString> ;
       <VersionString>:: <StringLiteral>
                       | <IntegerLiteral> ;




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


   where <VersionString> is an ASCII-encoded string.  Assertions in
   production versions of KeyNote use decimal digits in the version
   representing the version number of the KeyNote language under which
   they are to be interpreted.  Assertions written to conform with this
   document should be identified with the version string "2" (or the
   integer 2).  The KeyNote-Version field, if included, should appear
   first.

4.6.2  The Local-Constants Field

   This field adds or overrides action attributes in the current
   assertion only.  This mechanism allows the use of short names for
   (frequently lengthy) cryptographic principal identifiers, especially
   to make the Licensees field more readable.  The Local-Constants field
   is of the form:

       <LocalConstantsField>:: "Local-Constants:" <Assignments> ;
       <Assignments>:: /* can be empty */
                     | <AttributeID> "=" <StringLiteral> <Assignments> ;

   <AttributeID> is an attribute name from the action attribute
   namespace as defined in Section 3.  The name is available for use as
   an attribute in any subsequent field.  If the Local-Constants field
   defines more than one identifier, it can occupy more than one line
   and be indented.  <StringLiteral> is a string literal as described in
   Section 4.3.  Attributes defined in the Local-Constants field
   override any attributes with the same name passed in with the action
   attribute set.

   An attribute may be initialized at most once in the Local-Constants
   field.  If an attribute is initialized more than once in an
   assertion, the entire assertion is considered invalid and is not
   considered by the KeyNote compliance checker in evaluating queries.

4.6.3  The Authorizer Field

   The Authorizer identifies the Principal issuing the assertion.  This
   field is of the form

       <AuthField>:: "Authorizer:" <AuthID> ;
       <AuthID>:: <PrincipalIdentifier>
                | <DerefAttribute> ;

   The Principal Identifier may be given directly or by reference to the
   attribute namespace (as defined in Section 4.4).






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


4.6.4   The Licensees Field

   The Licensees field identifies the principals authorized by the
   assertion.  More than one principal can be authorized, and
   authorization can be distributed across several principals through
   the use of `and' and threshold constructs.  This field is of the form

       <LicenseesField>:: "Licensees:" <LicenseesExpr> ;

       <LicenseesExpr>::      /* can be empty */
                         | <PrincExpr> ;

       <PrincExpr>:: "(" <PrincExpr> ")"
                     | <PrincExpr> "&&" <PrincExpr>
                     | <PrincExpr> "||" <PrincExpr>
                     | <K>"-of(" <PrincList> ")"        /* Threshold */
                     | <PrincipalIdentifier>
                     | <DerefAttribute> ;

       <PrincList>:: <PrincipalIdentifier>
                   | <DerefAttribute>
                   | <PrincList> "," <PrincList> ;

       <K>:: {Decimal number starting with a digit from 1 to 9} ;

   The "&&" operator has higher precedence than the "||" operator.  <K>
   is an ASCII-encoded positive decimal integer.  If a <PrincList>
   contains fewer than <K> principals, the entire assertion is omitted
   from processing.

4.6.5  The Conditions Field

   This field gives the `conditions' under which the Authorizer trusts
   the Licensees to perform an action.  `Conditions' are predicates that
   operate on the action attribute set.  The Conditions field is of the
   form:

    <ConditionsField>:: "Conditions:" <ConditionsProgram> ;

    <ConditionsProgram>:: /* Can be empty */
                          | <Clause> ";" <ConditionsProgram> ;

    <Clause>:: <Test> "->" "{" <ConditionsProgram> "}"
             | <Test> "->" <Value>
             | <Test> ;

    <Value>:: <StrEx> ;




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


    <Test>:: <RelExpr> ;

    <RelExpr>:: "(" <RelExpr> ")"        /* Parentheses */
              | <RelExpr> "&&" <RelExpr> /* Logical AND */
              | <RelExpr> "||" <RelExpr> /* Logical OR */
              | "!" <RelExpr>         /* Logical NOT */
              | <IntRelExpr>
              | <FloatRelExpr>
              | <StringRelExpr>
              | "true"        /* case insensitive */
              | "false" ;     /* case insensitive */

    <IntRelExpr>:: <IntEx> "==" <IntEx>
                 | <IntEx> "!=" <IntEx>
                 | <IntEx> "<" <IntEx>
                 | <IntEx> ">" <IntEx>
                 | <IntEx> "<=" <IntEx>
                 | <IntEx> ">=" <IntEx> ;

    <FloatRelExpr>:: <FloatEx> "<" <FloatEx>
                   | <FloatEx> ">" <FloatEx>
                   | <FloatEx> "<=" <FloatEx>
                   | <FloatEx> ">=" <FloatEx> ;

    <StringRelExpr>:: <StrEx> "==" <StrEx>  /* String equality */
                    | <StrEx> "!=" <StrEx>  /* String inequality */
                    | <StrEx> "<" <StrEx>   /* Alphanum. comparisons */
                    | <StrEx> ">" <StrEx>
                    | <StrEx> "<=" <StrEx>
                    | <StrEx> ">=" <StrEx>
                    | <StrEx> "~=" <RegExpr> ; /* Reg. expr. matching */

    <IntEx>:: <IntEx> "+" <IntEx>        /* Integer */
            | <IntEx> "-" <IntEx>
            | <IntEx> "*" <IntEx>
            | <IntEx> "/" <IntEx>
            | <IntEx> "%" <IntEx>
            | <IntEx> "^" <IntEx>        /* Exponentiation */
            | "-" <IntEx>
            | "(" <IntEx> ")"
            | <IntegerLiteral>
            | "@" <StrEx> ;

    <FloatEx>:: <FloatEx> "+" <FloatEx>  /* Floating point */
              | <FloatEx> "-" <FloatEx>
              | <FloatEx> "*" <FloatEx>
              | <FloatEx> "/" <FloatEx>
              | <FloatEx> "^" <FloatEx> /* Exponentiation */



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


              | "-" <FloatEx>
              | "(" <FloatEx> ")"
              | <FloatLiteral>
              | "&" <StrEx> ;

    <IntegerLiteral>:: {Decimal number of at least one digit} ;
    <FloatLiteral>:: <IntegerLiteral>"."<IntegerLiteral> ;

    <StringLiteral> is a quoted string as defined in Section 4.3
    <AttributeID> is defined in Section 3.

   The operation precedence classes are (from highest to lowest):
        { (, ) }
        {unary -, @, &, $}
        {^}
        {*, /, %}
        {+, -, .}

   Operators in the same precedence class are evaluated left-to-right.

   Note the inability to test for floating point equality,  as most
   floating point implementations (hardware or otherwise) do not
   guarantee accurate equality testing.

   Also note that integer and floating point expressions can only be
   used within clauses of condition fields, but in no other KeyNote
   field.

   The keywords "true" and "false" are not reserved; they can be used as
   attribute or principal identifier names (although this practice makes
   assertions difficult to understand and is discouraged).

   <RegExpr> is a standard regular expression, conforming to the POSIX
   1003.2 regular expression syntax and semantics.

   Any string expression (or attribute) containing the ASCII
   representation of a numeric value can be converted to an integer or
   float with the use of the "@" and "&" operators, respectively.  Any
   fractional component of an attribute value dereferenced as an integer
   is rounded down.  If an attribute dereferenced as a number cannot be
   properly converted (e.g., it contains invalid characters or is empty)
   its value is considered to be zero.









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


4.6.6  The Comment Field

   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