rfc2704.txt

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

5.4  Assertion Management

   Assertions may be either signed or unsigned.  Only signed assertions
   should be used as credentials or transmitted or stored on untrusted
   media.  Unsigned assertions should be used only to specify policy and
   for assertions whose integrity has already been verified as
   conforming to local policy by some mechanism external to the KeyNote
   system itself (e.g., X.509 certificates converted to KeyNote
   assertions by a trusted conversion program).

   Implementations that permit signed credentials to be verified by the
   KeyNote compliance checker generally provide two `channels' through
   which applications can make assertions available.  Unsigned,
   locally-trusted assertions are provided over a `trusted' interface,
   while signed credentials are provided over an `untrusted' interface.
   The KeyNote compliance checker verifies correct signatures for all
   assertions submitted over the untrusted interface.  The integrity of
   KeyNote evaluation requires that only assertions trusted as
   reflecting local policy are submitted to KeyNote via the trusted
   interface.




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


   Note that applications that use KeyNote exclusively as a local policy
   specification mechanism need use only trusted assertions.  Other
   applications might need only a small number of infrequently changed
   trusted assertions to `bootstrap' a policy whose details are
   specified in signed credentials issued by others and submitted over
   the untrusted interface.

5.5  Implementation Issues

   Informally, the semantics of KeyNote evaluation can be thought of as
   involving the construction a directed graph of KeyNote assertions
   rooted at a POLICY assertion that connects with at least one of the
   principals that requested the action.

   Delegation of some authorization from principal <A> to a set of
   principals <B> is expressed as an assertion with principal <A> given
   in the Authorizer field, principal set <B> given in the Licensees
   field, and the authorization to be delegated encoded in the
   Conditions field.  How the expression digraph is constructed is
   implementation-dependent and implementations may use different
   algorithms for optimizing the graph's construction.  Some
   implementations might use a `bottom up' traversal starting at the
   principals that requested the action, others might follow a `top
   down' approach starting at the POLICY assertions, and still others
   might employ other heuristics entirely.

   Implementations are encouraged to employ mechanisms for recording
   exceptions (such as division by zero or syntax error), and reporting
   them to the invoking application if requested.  Such mechanisms are
   outside the scope of this document.

6.  Examples

   In this section, we give examples of KeyNote assertions that might be
   used in hypothetical applications.  These examples are intended
   primarily to illustrate features of KeyNote assertion syntax and
   semantics, and do not necessarily represent the best way to integrate
   KeyNote into applications.

   In the interest of readability, we use much shorter keys than would
   ordinarily be used in practice.  Note that the Signature fields in
   these examples do not represent the result of any real signature
   calculation.








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


   1. TRADITIONAL CA / EMAIL

      A. A policy unconditionally authorizing RSA key abc123 for all
         actions.  This essentially defers the ability to specify
         policy to the holder of the secret key corresponding to
         abc123:

           Authorizer: "POLICY"
           Licensees: "RSA:abc123"

      B. A credential assertion in which RSA Key abc123 trusts either
         RSA key 4401ff92 (called `Alice') or DSA key d1234f (called
         `Bob') to perform actions in which the "app_domain" is
         "RFC822-EMAIL", where the "address" matches the regular
         expression "^.*@keynote\.research\.att\.com$".  In other
         words, abc123 trusts Alice and Bob as certification
         authorities for the keynote.research.att.com domain.

           KeyNote-Version: 2
           Local-Constants: Alice="DSA:4401ff92"  # Alice's key
                            Bob="RSA:d1234f"      # Bob's key
           Authorizer: "RSA:abc123"
           Licensees: Alice || Bob
           Conditions: (app_domain == "RFC822-EMAIL") &&
                       (address ~=   # only applies to one domain
                         "^.*@keynote\\.research\\.att\\.com$");
           Signature: "RSA-SHA1:213354f9"

      C. A certificate credential for a specific user whose email
         address is [e-mail] and whose name, if
         present, must be "M. Blaze". The credential was issued by the
         `Alice' authority (whose key is certified in Example B
         above):

           KeyNote-Version: 2
           Authorizer: "DSA:4401ff92"  # the Alice CA
           Licensees: "DSA:12340987"   # mab's key
           Conditions: ((app_domain == "RFC822-EMAIL") &&
                        (name == "M. Blaze" || name == "") &&
                        (address == "[e-mail]"));
           Signature: "DSA-SHA1:ab23487"










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


      D. Another certificate credential for a specific user, also
         issued by the `Alice' authority.  This example allows three
         different keys to sign as [e-mail] (each
         for a different cryptographic algorithm).  This is, in
         effect, three credentials in one:

           KeyNote-Version: "2"
           Authorizer: "DSA:4401ff92"   # the Alice CA
           Licensees: "DSA:abc991" ||   # jf's DSA key
                      "RSA:cde773" ||   # jf's RSA key
                      "BFIK:fd091a"     # jf's BFIK key
           Conditions: ((app_domain == "RFC822-EMAIL") &&
                        (name == "J. Feigenbaum" || name == "") &&
                        (address == "[e-mail]"));
           Signature: "DSA-SHA1:8912aa"

         Observe that under policy A and credentials B, C and D, the
         following action attribute sets are accepted (they return
         _MAX_TRUST):

             _ACTION_AUTHORIZERS = "dsa:12340987"
             app_domain = "RFC822-EMAIL"
             address = "[e-mail]"
          and
             _ACTION_AUTHORIZERS = "dsa:12340987"
             app_domain = "RFC822-EMAIL"
             address = "[e-mail]"
             name = "M. Blaze"

         while the following are not accepted (they return
         _MIN_TRUST):

             _ACTION_AUTHORIZERS = "dsa:12340987"
             app_domain = "RFC822-EMAIL"
             address = "[e-mail]"
          and
             _ACTION_AUTHORIZERS = "dsa:abc991"
             app_domain = "RFC822-EMAIL"
             address = "[e-mail]"
             name = "M. Blaze"
          and
             _ACTION_AUTHORIZERS = "dsa:12340987"
             app_domain = "RFC822-EMAIL"
             address = "[e-mail]"
             name = "J. Feigenbaum"






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


   2. WORKFLOW/ELECTRONIC COMMERCE

      E. A policy that delegates authority for the "SPEND" application
         domain to RSA key dab212 when the amount given in the
         "dollars" attribute is less than 10000.

           Authorizer: "POLICY"
           Licensees: "RSA:dab212"  # the CFO's key
           Conditions: (app_domain=="SPEND") && (@dollars < 10000);

      F. RSA key dab212 delegates authorization to any two signers,
         from a list, one of which must be DSA key feed1234 in the
         "SPEND" application when @dollars < 7500.  If the amount in
         @dollars is 2500 or greater, the request is approved but
         logged.

           KeyNote-Version: 2
           Comment: This credential specifies a spending policy
           Authorizer: "RSA:dab212"        # the CFO
           Licensees: "DSA:feed1234" &&    # The vice president
                          ("RSA:abc123" || # middle manager #1
                           "DSA:bcd987" || # middle manager #2
                           "DSA:cde333" || # middle manager #3
                           "DSA:def975" || # middle manager #4
                           "DSA:978add")   # middle manager #5
           Conditions: (app_domain=="SPEND")  # note nested clauses
                         -> { (@(dollars) < 2500)
                                -> _MAX_TRUST;
                              (@(dollars) < 7500)
                                -> "ApproveAndLog";
                            };
           Signature: "RSA-SHA1:9867a1"

      G. According to this policy, any two signers from the list of
         managers will do if @(dollars) < 1000:

           KeyNote-Version: 2
           Authorizer: "POLICY"
           Licensees: 2-of("DSA:feed1234", # The VP
                           "RSA:abc123",   # Middle management clones
                           "DSA:bcd987",
                           "DSA:cde333",
                           "DSA:def975",
                           "DSA:978add")
           Conditions: (app_domain=="SPEND") &&
                       (@(dollars) < 1000);





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


      H. A credential from dab212 with a similar policy, but only one
         signer is required if @(dollars) < 500.  A log entry is made if
         the amount is at least 100.

           KeyNote-Version: 2
           Comment: This one credential is equivalent to six separate
                    credentials, one for each VP and middle manager.
                    Individually, they can spend up to $500, but if
                    it's $100 or more, we log it.
           Authorizer: "RSA:dab212"      # From the CFO
           Licensees: "DSA:feed1234" ||  # The VP
                      "RSA:abc123" ||    # The middle management clones
                      "DSA:bcd987" ||
                      "DSA:cde333" ||
                      "DSA:def975" ||
                      "DSA:978add"
           Conditions: (app_domain="SPEND")  # nested clauses
                         -> { (@(dollars) < 100) -> _MAX_TRUST;
                              (@(dollars) < 500) -> "ApproveAndLog";
                            };
           Signature: "RSA-SHA1:186123"

      Assume a query in which the ordered set of Compliance Values is
      {"Reject", "ApproveAndLog", "Approve"}.  Under policies E and G,
      and credentials F and H, the Policy Compliance Value is
      "Approve" (_MAX_TRUST) when:

           _ACTION_AUTHORIZERS = "DSA:978add"
           app_domain = "SPEND"
           dollars = "45"
           unmentioned_attribute = "whatever"
       and
           _ACTION_AUTHORIZERS = "RSA:abc123,DSA:cde333"
           app_domain = "SPEND"
           dollars = "550"

      The following return "ApproveAndLog":

           _ACTION_AUTHORIZERS = "DSA:feed1234,DSA:cde333"
           app_domain = "SPEND"
           dollars = "5500"
       and
           _ACTION_AUTHORIZERS = "DSA:cde333"
           app_domain = "SPEND"
           dollars = "150"






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


      However, the following return "Reject" (_MIN_TRUST):

           _ACTION_AUTHORIZERS = "DSA:def975"
           app_domain = "SPEND"
           dollars = "550"
       and
           _ACTION_AUTHORIZERS = "DSA:cde333,DSA:978add"
           app_domain = "SPEND"
           dollars = "5500"

7.  Trust-Management Architecture

   KeyNote provides a simple mechanism for describing security policy
   and representing credentials.  It differs from traditional
   certification systems in that the security model is based on binding
   keys to predicates that describe what the key is authorized by policy
   to do, rather than on resolving names.  The infrastructure and
   arch