[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
SPKI Working Group                                            Matt Blaze
Internet Draft                                           Joan Feigenbaum
expires in six months                               Angelos D. Keromytis
                                                              April 1998

                 The KeyNote Trust-Management System
                draft-angelos-spki-keynote-01.txt (A)

Status of this Memo

   This document is an Internet-Draft.  Internet Drafts are working doc-
   uments of the Internet Engineering Task Force (IETF), its Areas, and
   its Working Groups.  Note that other groups may also distribute work-
   ing documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months, and may be updated, replaced, or obsoleted by other documents
   at any time.  It is not appropriate to use Internet Drafts as refer-
   ence material, or to cite them other than as a ``working draft'' or
   ``work in progress.''

   To view the entire list of current Internet-Drafts, please check
   the "1id-abstracts.txt" listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
   (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
   (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
   (US West Coast).

   Distribution of this memo is unlimited.


   This memo describes KeyNote, a simple trust-management system to
   support public-key infrastructure. It outlines the syntax and
   semantics of keynote credentials, describes action environment
   processing, and describes the application architecture into which a
   KeyNote implementation would fit.


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [Bra97].

Blaze/Feigenbaum/Keromytis   expires in six months              [Page i]

DRAFT                         KeyNote                         April 1998

1.  Introduction

   This memo describes KeyNote, a simple trust-management system for
   public-key infrastructures.  Trust management, introduced in the
   PolicyMaker system [BFL96], is a unified approach to specifying and
   interpreting security policies, credentials, and relationships that
   allows direct authorization of security-critical actions.  In
   particular, a trust-management system combines the notion of
   specifying security policy with the mechanism for specifying security
   credentials (subsuming the role of "certificates").  Credentials
   describe a specific delegation of trust among public keys; unlike
   traditional certificates, which bind keys to names, trust-management
   credentials bind keys to the authorization to perform specific tasks.

   KeyNote provides a simple notation for specifying both local
   security policies and security credentials that can be sent over an
   untrusted network.  Policies and credentials, called "assertions" as
   in PolicyMaker, contain predicates that describe the trusted
   actions permitted by the holders of specific public keys.  A signed
   assertion that can be sent over an untrusted network is called a
   Credential Assertion.  Credential assertions, which serve the role
   of "certificates," have the same syntax as policy assertions with
   the additional feature that they are signed by the entity
   delegating the trust.  A KeyNote evaluator accepts as input a set of
   local policy assertions, a collection of credential assertions, and
   a collection of attributes, called an "action environment," that
   describes a proposed trusted action associated with a set of public
   keys.  KeyNote determines whether proposed actions are consistent
   with local policy by applying the assertion predicates to the
   action environment.

   Although the basic design of KeyNote is similar in spirit to that of
   PolicyMaker, KeyNote's features have been simplified to more directly
   support public-key infrastructure-like applications.  The central
   differences between PolicyMaker and KeyNote are:
        - KeyNote predicates are written in a simple notation based on
          C-like expressions and regular expressions.
        - The KeyNote system always returns a boolean (trusted or not)
        - Credential signature verification is built in to the KeyNote
        - Assertion syntax is based on a human-readable
          "RFC-822"-style syntax.
        - Trusted actions are described by simple attribute/value pairs.

2.  KeyNote Assertion Format

   All KeyNote assertions are encoded in ASCII strings.  Four mandatory
   fields MUST appear in all assertions (KEYNOTE-VERSION, SIGNER,
   KEY-PREDICATE, and ACTION-PREDICATE); three optional fields MAY

Blaze/Feigenbaum/Keromytis   expires in six months              [Page 1]

DRAFT                         KeyNote                         April 1998

   The version of KeyNote assertions described in this document is 1.
   All fields MUST start at the beginning of a line; fields may be
   continued by indenting with at least one SPACE or TAB character at
   the beginning of the line.  Whitespace separates tokens but is
   otherwise ignored outside of quoted strings (our grammars below
   omit whitespace processing in the interest of readability).  All
   name tokens are case-insensitive.  It is encouraged that keys be
   encoded in lower-case hex digits.  String comparison of keys for
   internal purposes (e.g., matching a key in the KEY-PREDICATE of one
   assertion with a key in the SIGNER field of another assertion) MUST
   be case insensitive.  In the following sections, the notation [X]*
   means zero or more repetitions of the string X.  The notation [X]+
   means one or more repetitions of the string X.

2.1  Key Encoding

   Keys are encoded as ALG[:LEN:HEXENC]+, where LEN is an ASCII-encoded
   decimal number, indicating the number of characters in the HEXENC
   field.  HEXENC is key encoded in hexadecimal digits.  If more than
   one component is needed by the signature algorithm, the extra
   components are appended.  The required number of components is
   determined by the key type.  ALG is an ASCII string that describes
   the key type (such as RSA or DSA).


   The KEYNOTE-VERSION field is of the form KEYNOTE-VERSION:VerNumber,
   where VerNumber is an ASCII-encoded decimal number.  The current
   version is 1.  This field MUST be the first field appearing in a
   KeyNote assertion.

2.3  The LOCAL-INIT field

   The initialization field is of the form:
   Local-Init: Name = ConstantString [, Name = ConstantString]*

   Name is an identifier that can be used in the ACTION-PREDICATE and
   KEY-PREDICATE fields instead of the string ConstantString.  If the
   LOCAL-INIT field defines more than one identifier, it can occupy
   more than one line and be indented.  ConstantString can be composed
   by concatenating smaller strings using the "+" operator (see the
   examples).  If an initialization identifier is accessed but has
   not been defined, it should evaluate to the empty string.  The
   initialized identifier ANGELOS_DSA_KEY could, for example, be used

   When an initialization identifier is accessed in an
   ACTION-PREDICATE expression, it shadows the value of any action
   environment identifier, for this assertion only.  If an identifier
   is declared more than once in the LOCAL-INIT field, the assertion
   MUST be considered invalid.

Blaze/Feigenbaum/Keromytis   expires in six months              [Page 2]

DRAFT                         KeyNote                         April 1998

2.4  The SIGNER field

   The SIGNER field is of the form SIGNER:KEY, where KEY is a key
   encoded as described in 2.1 or an initialization constant as
   described in 2.3.  The SIGNER field may instead be of the form
   SIGNER:Policy.  A Policy assertion is one that is trusted
   directly by the local environment.  It can serve as the "root" of a
   trust structure that authorizes a requested action.  A valid input
   to the KeyNote evaluator must contain at least one Policy
   assertion.  Because they are trusted locally, Policy assertions do
   not require cryptographic signature verification.

2.5  The KEY-PREDICATE field

   The KEY-PREDICATE field is of the form Key-Predicate:KEY-EXPR.
   KEY-EXPR is given by the following grammar:

             KEY-EXPR "&&" KEY-EXPR |
             KEY-EXPR "||" KEY-EXPR |
             K-of(KEYLIST) |
             KEY |

             "$"STRING |
             KEY, KEYLIST |
             "$"STRING, KEYLIST

   STRING: [a-zA-Z0-9][a-zA-Z0-9_\.]*

   The "&&" operator has higher precedence than the "||" operator.

   "K" is an ASCII-encoded decimal number. A KEYLIST SHOULD contain at
   least K keys.  Whitespace characters (space, tab, newline) in
   KEY-EXPR MUST be ignored.  The semantics of k-OF are that at least
   K distinct keys from the KEYLIST must authorize a request.  If the
   KEY-EXPR field is empty, it always evaluates to TRUE and is used
   for direct authorization of a ACTION-PREDICATE by a policy or a

2.6  The SIGNATURE field

   The SIGNATURE field is of the form Signature:NAME[:LEN:SIG]+, where
   NAME is an ASCII string that indicates the signature type (e.g.,
   RSA-MD5-PKCS1).  LEN is an ASCII encoded decimal number that
   indicates the length of the SIG field. SIG is the signature encoded
   in  hexadecimal digits.  If more than one component is needed by
   the signature algorithm, the extra components are appended.  The
   required number of components is determined by the NAME field
   value.  The signature is computed over the KEYNOTE-VERSION, SIGNER,

Blaze/Feigenbaum/Keromytis   expires in six months              [Page 3]

DRAFT                         KeyNote                         April 1998

   concatenated with the NAME field, as they appear in the credential.
   This field MUST be last in a KeyNote assertion.

2.7  The COMMENT field

   The COMMENT field is of the form Comment: .*
   The interpretation of this field is application-dependent.


   where  EXPR is described by the following grammar:

   EXPR: "(" EXPR ")" |
         EXPR "&&" EXPR |       /* Logical AND */
         EXPR "||" EXPR |       /* Logical OR */
         "!"EXPR |              /* Logical NOT */
         NUMEXPR |
         FLOATEXPR |
         STRINGEXPR |
         true | false

   NUMEXPR: NUMEX < NUMEX |     /* Integer expression comparisons */
            NUMEX > NUMEX |
            NUMEX <= NUMEX |
            NUMEX >= NUMEX |
            NUMEX == NUMEX |
            NUMEX != NUMEX

   FLOATEXPR: FLOATEX < FLOATEX | /* Floating point */
              FLOATEX > FLOATEX |
              FLOATEX <= FLOATEX |
              FLOATEX >= FLOATEX

   STRINGEXPR: STR == STR |      /* String comparisons */
               STR != STR |
               STR < STR |      /* Alphanumeric comparison */
               STR > STR |
               STR <= STR |
               STR >= STR |
               STR ~= REGEXP    /* Regular expression matching */

   STR: STR + STR |             /* String concatenation */
        STR . STR |             /* Also string concatenation */
        "$(" STR ")"

   NUMEX: NUMEX + NUMEX |       /* Arithmetic operations */
          NUMEX - NUMEX |
          NUMEX * NUMEX |
          NUMEX / NUMEX |

Blaze/Feigenbaum/Keromytis   expires in six months              [Page 4]

DRAFT                         KeyNote                         April 1998

          NUMEX % NUMEX |
          NUMEX ^ NUMEX |       /* Exponentiation */
          (NUMEX) |
          NUMBER |

   FLOATEX: FLOATEX + FLOATEX |       /* Floating point operations */
            FLOATEX - FLOATEX |
            FLOATEX * FLOATEX |
            FLOATEX / FLOATEX |
            FLOATEX ^ FLOATEX |       /* Exponentiation */
            (FLOATEX) |
            FLOAT |

   NUMBER: [0-9]+
   STRING: [a-zA-Z][a-zA-Z0-9_]*
   VSTRING: [a-zA-Z0-9][a-zA-Z0-9_]*
   DQUOTE: \"
   LITERALSTRING: DQUOTE (([^\"\n])|(\\[.\n]))* DQUOTE

   The numeric operation precedence is (higher to lower) ^, (*, /, %),
   (+, -).  Operators of equal precedence are evaluated left-to-right.
   REGEXP refers to the POSIX 1003.2 regular expression syntax and
   semantics.  Single-backslash ("\") elimination must be performed on
   LITERALSTRINGs (e.g., "\ac" becomes "ac").  If an ACTION-PREDICATE
   field is empty, it always evaluates to TRUE.  A division (or modulo)
   by zero cause the enclosing boolean expression to evaluate to false.
   String operations (including regexps) can be case-sensitive or
   case-insensitive, specified as a run-time option.


   Trusted actions to be evaluated by KeyNote are described by a
   collection of attribute/value pairs called the Action Environment.
   An action environment is passed to the KeyNote system as part of
   each query and provides the values of the variables used by
   assertion predicates.

   The action environment specifies a collection of values of named
   attributes.  The attributes may be examined as variables by KeyNote
   trust predicates.

   The exact format for specifying an action environment is determined
   by the particular KeyNote implementation.  In general, an

Blaze/Feigenbaum/Keromytis   expires in six months              [Page 5]

DRAFT                         KeyNote                         April 1998

   environment may be thought of as a list of assignments to


   If an action environment attribute is not defined, it MUST
   evaluate to the empty string (if accessed as a string) or the
   value zero (if accessed as an integer or a float).

   An attribute that is accessed as an integer (by prepending the "@"
   sign) MUST contain only digits.  Similarly, an attribute that is
   accessed as a float (through the "&" sign) MUST consist entirely of
   digits and at most one period.  In both cases if the attribute
   contains any illegal character, the returned value MUST be zero.

   Only one attribute, called "$ACTION_SIGNERS", is mandatory.  This
   attribute lists the key or keys associated with the action
   environment (e.g., signer of the message whose trust is being
   evaluated by KeyNote). The $ACTION_SIGNERS attribute is used to
   provide the initial keys to match against the KEY-PREDICATEs.

   In most cases, the $ACTION_SIGNERS attribute will consist of a
   single public key (of the ALG:LEN:VAL form specified in the previous


   If an action is associated with more than one key, the
   ACTION_SIGNERS attribute may contain a comma-separated list of keys.


   The names of all other attributes in the action environment are not
   specified by KeyNote but must be agreed upon by the writers of any
   policies and credentials that are to cooperate in a KeyNote query
   evaluation.  By convention, the name of the application domain in
   which environment attributes should be interpreted is specified in
   the attribute APP_DOMAIN.  The IANA will provide a registry of
   reserved APP_DOMAIN names with the names and meanings of the
   attributes they use.  Note that an attribute with a particular name
   may have different meanings in different application domains.  Note
   that the use of the registry is optional; a policy or credential
   may depend on any attribute names used by the credentials to which
   trust is deferred.

   For example, an email application might reserve the APP_DOMAIN
   "RFC822-EMAIL" and might use the following attributes:

        $ADDRESS (the email address of a message's sender)

Blaze/Feigenbaum/Keromytis   expires in six months              [Page 6]

DRAFT                         KeyNote                         April 1998

        $NAME (the human name of the message sender)
        $ORGANIZATION (the organization name).

   The values of these attributes may be derived in the obvious way
   from the email message headers.

   Note that RFC822-EMAIL is simply 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

4.  KeyNote Action Evaluation

   This section describes the semantics of KeyNote action evaluation.
   An implementation is free to use any algorithm that provides
   equivalent semantics.


     The variable $App_Domain is assigned the name of the
     application (e.g., "RFC822-EMAIL").

     The keys that authenticate the request for a trusted action are
     assigned to the variable $Action_Signers.

     The rest of the action environment attributes are placed in their
     respective variables.

     The time of day MAY be placed in the variables $GMTTimeOfDay and
     $LocalTimeOfDay, using the format YYYYMMDDHHMMSS (e.g.,

     Any other implementation-dependent variables and their bindings are
     also created at this step.

   For each KeyNote assertion passed to the evaluation engine, the
   following steps are taken:

     The ACTION-PREDICATE expression is evaluated.  If the result is
     boolean TRUE, and the key expression in the KEY-PREDICATE
     field is also true, the request is approved.  Otherwise, it is

   The KEY-PREDICATE field public-key expression is evaluated as

     Let the key expression contain public key PK_i.  A boolean
     variable `PK_i' corresponds to this key.

     If there is no assertion in which PK_i is the SIGNER, then the

Blaze/Feigenbaum/Keromytis   expires in six months              [Page 7]

DRAFT                         KeyNote                         April 1998

     boolean variable `PK_i' is false.

     If there is at least one assertion in which PK_i is
     the source, then the boolean variable `PK_i' is true
     if and only if at least one of those assertions is true.

   For a request to be approved, there must exist a directed graph
   of KeyNote assertions rooted at a POLICY assertion of the
   evaluator that evaluates to TRUE.  If such a directed graph cannot
   be constructed, the request is denied for lack of authorization.
   Delegation of some authorization from key A to a set of keys B is
   expressed as an assertion with key A in the SIGNER field, key set B
   in the KEY-PREDICATE field, and the authorization delegated encoded
   in the ACTION-PREDICATE field.  How the expression digraph is
   constructed is implementation-dependent, in particular because
   different implementations may use different algorithms for
   optimizing the graph construction.

5.   Examples

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


      A. A policy unconditionally delegating trust to the holder of RSA
         key abc123:

           KEYNOTE-VERSION: 1
           SIGNER: policy
           KEY-PREDICATE: rsa-sha1-pkcsX:6:abc123
           ACTION-PREDICATE: true

      B. A credential assertion in which RSA Key abc123 trusts either
         RSA key 4401ff92 or DSA key d1234f 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 4401ff92 and d1234f as certification
         authorities for the keynote.research.att.com domain.

           KEYNOTE-VERSION: 1
           LOCAL-INIT: TRUSTED_PARTY1="dsa-sha1-pkcsX:8:4401" + "ff92",
           SIGNER: rsa-sha1-pkcsX:6:abc123
           ACTION-PREDICATE: ($app_domain == "RFC822-EMAIL") &&
                             ($address ~=
           SIGNATURE: rsa-md5-pkcsX:8:213354f9

Blaze/Feigenbaum/Keromytis   expires in six months              [Page 8]

DRAFT                         KeyNote                         April 1998

      C. A certificate credential for a specific user, issued by one of
         the certification authorities above:

           KEYNOTE-VERSION: 1
           SIGNER: dsa-sha1-pkcsX:8:4401ff92
           KEY-PREDICATE: dsa-sha1-pkcsX:8:12340987
           ACTION-PREDICATE: (($app_domain == "RFC822-EMAIL") &&
                              ($name == "M. Blaze" || $name == "") &&
                              ($address ==
           SIGNATURE: dsa-sha1-pkcsX:8:ab23487

      D. Another certificate credential for a specific user, issued by
         one of the certification authorities above.  This one allows
         three different keys to sign as jf@keynote.research.att.com
         (each with a different crypto algorithm).  Three credentials
         in one:

           KEYNOTE-VERSION: 1
           SIGNER: dsa-sha1-pkcsX:8:4401ff92=
           KEY-PREDICATE: dsa-sha1-pkcsX:6:abc991 ||
                          rsa-sha1-pkcsX:6:cde773 ||
           ACTION-PREDICATE: (($app_domain == "RFC822-EMAIL") &&
                          ($name == "J. Feigenbaum" || $name == "") &&
                          ($address == "jf@keynote.research.att.com"))
           SIGNATURE: dsa-sha1-pkcsX:8:8912aa

         Observe that under policy A and credentials B, C and D, the
         following action environments are accepted:

           $action_signer = "dsa-sha1-pkcsX:8:12340987"
           $app_domain = "RFC822-EMAIL"
           $address = "mab@keynote.research.att.com"


           $action_signer = "dsa-sha1-pkcsX:8:12340987"
           $app_domain = "RFC822-EMAIL"
           $address = "mab@keynote.research.att.com"
           $name = "M. Blaze"

         while the following are not accepted:

           $action_signer = "dsa-sha1-pkcsX:8:12340987"
           $app_domain = "RFC822-EMAIL"
           $address = "angelos@dsl.cis.upenn.edu"


           $action_signer = "dsa-sha1-pkcsX:6:abc991"
           $app_domain = "RFC822-EMAIL"

Blaze/Feigenbaum/Keromytis   expires in six months              [Page 9]

DRAFT                         KeyNote                         April 1998

           $address = "mab@keynote.research.att.com"
           $name = "M. Blaze"


           $action_signer = "dsa-sha1-pkcsX:8:12340987"
           $app_domain = "RFC822-EMAIL"
           $address = "mab@keynote.research.att.com"
           $name = "J. Feigenbaum"

       E.  Here's a credential that does not allow delegation to another

           KEYNOTE-VERSION: 1
           LOCAL-INIT: KEY1="dsa-sha1-pkcsX:6:fde995"
           SIGNER: dsa-sha1-pkcsX:8:4401ff92
           KEY-PREDICATE: $KEY1
           ACTION-PREDICATE:($app_domain="RFC822-EMAIL") &&
                            ($action_signers=$KEY1) &&
                            ($name == "A. Keromytis" ||
                             $name == "") &&
                            ($address ==
           SIGNATURE: dsa-sha1-pkcsX:8:fed121ab

         Now, even if we add a credential:

           KEYNOTE-VERSION: 1
           SIGNER: dsa-sha1-pkcsX:6:fde995
           KEY-PREDICATE: dsa-sha1-pkcsX:8:bad22bad
           ACTION-PREDICATE: true
           SIGNATURE: dsa-sha1-pkcsX:6:973cc1

         we still won't accept this action environment:

           $action_signer = "dsa-sha1-pkcsX:8:bad22bad"
           $app_domain = "RFC822-EMAIL"
           $address = "angelos@keynote.research.att.com"
           $name = "A. Keromytis"

         Although, of course, we would accept:

           $action_signer = "dsa-sha1-pkcsX:6:fde995"
           $app_domain = "RFC822-EMAIL"
           $address = "angelos@keynote.research.att.com"
           $name = "A. Keromytis"

         but not:

           $action_signer = "dsa-sha1-pkcsX:6:fde995"
           $app_domain = "RFC822-EMAIL"
           $address = "angelos@keynote.research.at.com"
           $name = "Matt Blaze"

Blaze/Feigenbaum/Keromytis   expires in six months             [Page 10]

DRAFT                         KeyNote                         April 1998


      F. A policy that delegates authority for the "SPEND" application
         domain to RSA key babe12 when @dollars is less than

           KEYNOTE-VERSION: 1
           SIGNER: policy
           KEY-PREDICATE: rsa-sha1-pkcsX:6:babe12
           ACTION-PREDICATE: ($app_domain="SPEND") && (@dollars < 10000)

   G. RSA key babe12 requires the signature of at least 2
      signers, one of which must be DSA key feed1234 in the
      "SPEND" application when @dollars is less than 5000

           KEYNOTE-VERSION: 1
           SIGNER: rsa-sha1-pkcsX:6:babe12
           KEY-PREDICATE: dsa-sha1-pkcsX:8:feed1234 &&
                          (rsa-sha1-pkcsX:6:abc113 ||
                           dsa-sha1-pkcsX:6:bcd987 ||
                           dsa-sha1-pkcsX:6:cde333 ||
                           dsa-sha1-pkcsX:6:def975 ||
           ACTION-PREDICATE: ($app_domain="SPEND") &&
                             (@dollars < 5000)
           SIGNATURE: rsa-sha1-pkcsX:6:9867a1

   H. Any two signers if @dollars < 1000:

           KEYNOTE-VERSION: 1
           SIGNER: policy
           KEY-PREDICATE: 2-of(dsa-sha1-pkcsX:8:feed1234:,
           ACTION-PREDICATE: ($app_domain="SPEND") &&
                             (@dollars < 1000)

   I. As above, but only one signer required if @dollars < 100.

           KEYNOTE-VERSION: 1
           SIGNER: rsa-sha1-pkcsX:6:babe12
           KEY-PREDICATE: (dsa-sha1-pkcsX:8:feed1234 ||
                           rsa-sha1-pkcsX:6:abc123 ||
                           dsa-sha1-pkcsX:6:bcd987 ||
                           dsa-sha1-pkcsX:6:cde333 ||
                           dsa-sha1-pkcsX:6:def975 ||
           ACTION-PREDICATE: ($app_domain="SPEND") &&
                             (@dollars < 100)

Blaze/Feigenbaum/Keromytis   expires in six months             [Page 11]

DRAFT                         KeyNote                         April 1998

           SIGNATURE: rsa-sha1-pkcsX:6:786123

      Under policies F and H, and credentials G and I, we accept:

           $action_signer = "dsa-sha1-pkcsX:6:978add"
           $app_domain = "SPEND"
           @dollars = 45


           $action_signer = "rsa-sha1-pkcsX:6:abc123,
           $app_domain = "SPEND"
           @dollars = 550


           $action_signer = "dsa-sha1-pkcsX:8:feed1234,
           $app_domain = "SPEND"
           @dollars = 2500


           $action_signer = "rsa-sha1-pkcsX:8:babe12"
           $app_domain = "SPEND"
           @dollars = 2000

      However, the following are not accepted:

           $action_signer = "dsa-sha1-pkcsX:6:def975"
           $app_domain = "SPEND"
           @dollars = 550


           $action_signer = "dsa-sha1-pkcsX:8:cde333,
           $app_domain = "SPEND"
           @dollars = 2500


      J. A policy that at least two signers are required to authorize
         the launch of missiles against London or Moscow.

           KEYNOTE-VERSION: 1
           SIGNER: policy
           KEY-PREDICATE: 2-of(dsa-sha1-pkcsX:8:badfeed1,

Blaze/Feigenbaum/Keromytis   expires in six months             [Page 12]

DRAFT                         KeyNote                         April 1998

           ACTION-PREDICATE: ($app_domain="NUKE") &&
                             ($action="launch") &&
                             ($delivery_system="missile") &&
                             (($target="moscow") || ($target="london"))

6.   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 architecture to support a KeyNote system is
   therefore rather different than that for a name-based certification
   scheme.  The KeyNote trust-management architecture is based on that
   of PolicyMaker [BFL96].

   It is important to understand the separation between the
   responsibilities of the KeyNote system and those of the application
   and other support infrastructure.  A KeyNote evaluator will
   determine, based on policy and credential assertions, whether a
   proposed action is permitted according to policy.  The usefulness
   of this determination depends on a number of factors.  First, the
   action environment attributes and the assignment of their values
   must reflect accurately the security requirements of the
   application.  Identifying the attributes to include in the action
   environment is perhaps the most important task in integrating
   KeyNote into new applications.  Second, the policy of the
   application must be correct and well-formed.  In particular, trust
   must be deferred only to keys and for predicates that should, in
   fact, be trusted by the application.  Finally, KeyNote does not
   directly enforce policy; it only provides advice to the
   applications that call it.  KeyNote assumes that the application
   itself is trusted and that the policy assertions are correct.
   Nothing prevents an application from submitting misleading
   assertions to KeyNote, or from ignoring KeyNote altogether.

   It is also up to the application (or some service outside KeyNote)
   to select the appropriate credentials and policy assertions with
   which to run a particular query.  Note that even if inappropriate
   credentials are provided to KeyNote, this cannot result in the
   approval of an illegal action environment (as long as the policy
   assertions are correct and the the action environment itself is
   correctly passed to KeyNote).  KeyNote is monotonic; adding an
   assertion to a query can never result in a query being rejected if
   it would have been accepted without the assertion.  Omitting
   credentials may, of course, result in legal action environments
   being disallowed.  Selecting appropriate credentials (e.g., from a

Blaze/Feigenbaum/Keromytis   expires in six months             [Page 13]

DRAFT                         KeyNote                         April 1998

   distributed database or "key server") is outside the scope of
   KeyNote itself, and may properly be handled by the remote client
   making a request, by the local machine verifying the request, or by
   a network-based service, depending on the application.

   In addition, KeyNote does not itself provide credential revocation
   services, although credentials can be written to expire after some
   date by including a date test in the predicate.  Applications that
   require credential revocation can use KeyNote to help specify and
   implement revocation policies.  A future draft will address
   expiration and revocation services in KeyNote.

   Observe that KeyNote adopts an almost opposite approach from that
   of a general-purpose name-based certification scheme.  In
   name-based schemes (such as X.509), the infrastructure aims to
   provide a common application-independent certificate, with each
   application left to develop its own mechanism to interpret the
   security semantics of the name.  KeyNote, on the other hand, aims
   to provide a common, application-independent mechanism for use with
   application-specific credentials and policies.  Each application
   (or class of applications) will develop its own set of attributes,
   with application-specific credentials and policies created to
   operate on them.

   Nevertheless, it is possible to take advantage of an existing
   general-purpose name-based infrastructure but still use KeyNote to
   specify policy and trust in some applications.  If an X.509 [X509],
   PGP [Zim95], or SDSI [LR97] -based certificate distribution
   infrastructure provides reliable bindings between names and keys,
   these certificates can be converted to KeyNote assertions that
   verify that an appropriate action environment attribute has the
   correct name.  Policy assertions can be used to specify the X.509,
   PGP, or SDSI certification authorities that are trusted for various
   kinds of names, etc.

   Because KeyNote is designed to support a variety of applications,
   several different application interfaces to a KeyNote
   implementation are possible.  In the simplest, a KeyNote evaluator
   would exist as a stand-alone application, with other applications
   calling it as needed.  KeyNote might also be implemented as a
   library to which applications are linked.  Finally, a KeyNote
   implementation might run as a local trusted service, with local
   applications communicating their queries via some interprocess
   communication mechanism.

7.   Security Considerations

   This draft discusses a trust-management system for public-key
   infrastructures.  The draft is itself concerned with a security

Blaze/Feigenbaum/Keromytis   expires in six months             [Page 14]

DRAFT                         KeyNote                         April 1998


   [BFL96] M. Blaze, J. Feigenbaum, J. Lacy, Decentralized Trust
           Management, 1996 IEEE Conference on Privacy and Security,
           Oakland, 1996.

   [LR97]  B. Lampson, R. Rivest, SDSI - Simple Distributed System
           Infrastructure, Draft, 1997.

   [Zim95] P. Zimmermann, PGP User's Manual, 1995.

   [Bra97] S. Bradner, Key words for use in RFCs to Indicate
           Requirement Level, RFC 2119, March 1997.

   [X509]  CCITT, Recommendation X.509: The Directory Authentication
           Framework, December 1988.

   [SPKI]  C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, and
           T. Ylonen, SPKI Certificate Theory, Work in Progress,


   Comments about this document should be discussed on the spki@c2.net
   mailing list.

   Questions about this document can also be directed to:

      Matt Blaze
      AT&T Labs - Research
      180 Park Avenue
      Florham Park, New Jersey 07932


      Joan Feigenbaum
      AT&T Labs - Research
      180 Park Avenue
      Florham Park, New Jersey 07932


      Angelos D. Keromytis
      Distributed Systems Lab
      CIS Department, University of Pennsylvania
      200 S. 33rd Street
      Philadelphia, Pennsylvania  19104-6389


Blaze/Feigenbaum/Keromytis   expires in six months             [Page 15]