Trust Management Working Group Matt Blaze Internet Draft Joan Feigenbaum expires in six months John Ioannidis Angelos D. Keromytis November 1998 The KeyNote Trust-Management System draft-blaze-ietf-trustmgt-keynote-00.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. Abstract This memo describes the KeyNote trust-management system. It specifies the syntax and semantics of KeyNote `assertions,' describes `action environment' processing, and outlines the application architecture into which a KeyNote implementation would fit. Terminology The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this document are to be interpreted as described in [Bra97]. 1. Introduction 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 notation for specifying both local security policies and security credentials. The credentials can be sent even over an untrusted network. Policies and credentials, called `assertions,' contain predicates which describe the trusted actions permitted by the holders of specific public keys. A signed assertion that can be sent over an untrusted network is also called a `credential assertion.' Credential assertions, which serve the role of certificates, have the same syntax as policy assertions but are also signed by the entity delegating the trust. In this document we assume that applications communicate with a KeyNote evaluator that interprets KeyNote assertions and returns results to applications. However, different hosts and environments may provide a variety of interfaces to the KeyNote evaluator; this document does not aim to specify a KeyNote API. A KeyNote evaluator accepts as input a set of local policy assertions, a set of credential assertions, and a set of attributes, called an `action environment,' that describes a proposed trusted action associated with a set of public keys. The KeyNote evaluator determines whether proposed actions are consistent with local policy by applying the assertion conditions to the action environment. The KeyNote evaluator can return values other than simply true and false, depending on the application and the action-environment definition. Furthermore, KeyNote assertions can pass additional information to the invoking application. 2. KeyNote Syntax All KeyNote assertions are encoded in ASCII strings. Four mandatory fields MUST appear in all assertions: KeyNote-Version, Authorizer, Licensees, and Conditions. Four optional fields MAY appear: Export, Comment, Signature, and Local-Init. All fields MUST start at the beginning of a line; fields may be continued on the following line by indenting with at least one SPACE or TAB character at the beginning of the continuation line. Whitespace (a SPACE, TAB, or NEWLINE character) separates tokens but is otherwise ignored outside of quoted strings. The backslash (\) character is used to `escape' certain characters: \n represents the newline character (ASCII character 10), \r represents the carriage-return character (ASCII character 13), \t represents the tab character (ASCII character 9), and \f represents the form-feed character (ASCII character 12). Outside of a quoted string, \ followed by a newline causes all following whitespace to be ignored (this allows the continuation of long lexical symbols across lines). The constructs \0n, \0nn, and \nnn (where n are octal digits) may be used to represent the ASCII characters with the corresponding octal values (thus, \012 is the same as \n, \101 is A, and \377 is the ASCII character 255). All other characters (usually only double-quotes and the backslash character) may be escaped inside quoted strings by prepending them with a backslash character (e.g., "like \"this\"."). Strings may be quoted or unquoted. A quoted string may contain any characters, including newlines; quotation marks and backslashes must be escaped though. An unquoted string may be continued on a following line by having a backslash at the line break; then any whitespace in the beginning of the following line is ignored. As an example the following three strings are identical: "this string contains a newline followed by one space." this\ string\ contains\ a\ newline\n\ foll\ owed\ by\ one\ space\. "this string contains a newline\012\040followed by one space." 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. Nonterminals are enclosed in angled brackets. All other strings are terminals. A complete sample assertion is shown below. The meaning of the various fields is explained in the following sections. KeyNote-Version: 1 Authorizer: rsa-pkcs1-hex:"acdfa1df" Licensees: dsa-hex:"feeddead" || rsa-pkcs1-hex:"cafe0031" Export: Attr1, Attr2 Local-Init: localattribute = "xxx" Comment: Your average credential assertion which is too long to describe on a single line. Conditions: $foo == "bar" -> {write1 = "yes", return true} Signature: rsa-md5-pkcs1-hex:"f00f2244" 2.1 Key Encoding Keys in KeyNote credential assertions are encoded as : is a case-insensitive ASCII string that describes the key type (e.g., RSA [RSA78] or DSA [DSA94]), encoding (e.g., PKCS1 [PKCS1]), and string encoding (e.g., HEX or BASE64). is an , which is a string starting with a letter and containing letters, digits, underscores, or dashes (in Posix 1003.2 terms, [a-zA-Z][a-zA-Z0-9_-]*). The IANA will provide a registry of reserved names. is a quoted string (which may contain escaped characters, be continued on following lines, etc.), and its format depends on . Hex-encoded keys SHOULD use lower-case digits. Note that the keys used in examples in this document are fictitious and generally shorter than would be required for security. 2.2 Attributes Attributes in KeyNote are denoted by $AttrName in any of the Authorizer, Licensees, and Conditions fields. Whenever an attribute is encountered, a lookup MUST be made in the Local-Init definitions. If that fails, for the Authorizer and Licensees fields this results in the empty string. In the Conditions, a subsequent lookup in the action environment must be made. (For more details on the action environment, see section 4.) If that fails to match as well, the result is the empty string. In case of a match, the corresponding value is the result, in string form. In the Conditions, attributes can also be denoted by @AttrName and &AttrName. These cause the resulting value to be an integer or a floating point number respectively. If $AttrName contains characters other than whitespace, decimal digits and a single '.' character, the resulting value MUST be zero. @AttrName is equivalent to floor(&AttrName). 2.3 Key Comparisons Key comparisons inside KeyNote (performed while trying to match keys in Authorizer and Licensees or the action authorizers (see section 5) should be between canonical forms of the keys. Every algorithm used in KeyNote should define some method for converting keys to this canonical form, and how the comparison for equality of two keys is performed. If the algorithm is unknown or unsupported, the implementation MUST do a case-insensitive string comparison, for comparisons between keys in a Licensees and the action authorizers (since a key that the application knows about but the KeyNote implementation does not, may appear in the action authorizers). Comparisons involving a key in the Authorizer field MUST be between canonical forms, unless the assertion is localy trusted (case-sensitive string comparison is used in that case). This is explained in more detail in section 3.3. 2.4 Return Values Some applications may use KeyNote in a form in which an assertion evaluates to one of two values (true/false). However, KeyNote supports more than two values (the number of supported values, as well as the values themselves, SHOULD be a runtime option set by the invoking application). The set of all possible return values should be a totally ordered one. The return values are the possible values that both Licensees and Conditions can take after they have been evaluated. The KeyNote system will attempt to return the highest possible value from a query using the evaluation rules described in the following sections (in particular, section 6). The meaning and interpretation of these values is application-dependent, and should be defined along with the rest of action-environment details (see section 4). 2.5 Write-Back Environment In addition to returning a non-boolean value to the invoking application, KeyNote assertions can also pass back additional information through a write-back environment mechanism. Assertions cannot lookup information in this write-back environment. The rules of how a write-back attribute is propagated back to the invoking application are given in section 3.4. Section 3.8 contains some additional information on scoping. In some cases, two write-back sets of attributes will be "combined" (section 3.4) using a non-symmetric operation: an ordering of the two write-back sets is defined, and the resulting write-back set is the union of the two sets. Write-back attributes common to both sets will have their values inherited from the second write-back set. In that sense, the second write-back set writes over the first. 3. KeyNote Fields The following sections explain the contents and meaning of the various fields that can appear in a KeyNote assertion. 3.1 The KeyNote-Version field The KeyNote-Version field is of the form KeyNote-Version: where is an ASCII-encoded decimal number. The current version is 1. This field MUST be the first field appearing in a KeyNote assertion. 3.2 The Local-Init field This field initializes action-environment attributes which are specific to this assertion only. A typical use for this field is to assign keys to logical names, so that the Licensees field is more readable. This field is of the form Local-Init: = [, = ]* is an (as defined in 2.2) which can be used as an attribute in the Conditions, Authorizer, and Licensees fields instead of the string . If the Local-Init field defines more than one identifier, it can occupy more than one line and be indented. is a string (quoted or unquoted) as described in section 2. If an initialization identifier is accessed but has not been defined, it should evaluate to the empty string (or zero, if it was accessed as a numeric value). When an initialization identifier is accessed in a Conditions expression, it shadows the value of any existing action-environment identifier for this assertion only (see section 2.2). If an identifier appears more than once in the Local-Init field, the assertion MUST be considered invalid and not processed by the evaluator. 3.3 The Authorizer field The Authorizer field is of the form Authorizer: where is a key encoded as described in section 2.1. The Authorizer field can also be a simple string, of the form Authorizer: for assertions which are trusted directly by the local environment and thus do not require cryptographic verification. is a string (quoted or unquoted) as described in section 2. Strings employed in this fashion will be called "logical tags" for the remainder of this document. Tag comparisons are case-sensitive. Finally, the Authorizer field can be of the form Authorizer: where is a Local-Init identifier (see section 2.2). The form of is defind in section 3.8. The result is treated as a key (see section 2.1) for comparison purposes. If the does not exist in the Local-Init identifiers, the assertion MUST be omitted from processing. A valid input to the KeyNote evaluator MUST contain at least one Policy assertion (in which the authorizer field is the keyword "POLICY", case-insensitive), which will serve as the `root' of a trust structure that authorizes a requested action. 3.4 The Licensees field The Licensees field describes who is being authorized by the Authorizer. This field is of the form Licensees: is given by the following grammar: : () | && | || | -of() | /* Threshold */ | | : | | | , | , | , : $[a-zA-Z0-9][a-zA-Z0-9_]* The format of tokens is described in section 2. The "&&" operator has higher precedence than the "||" operator. is an ASCII-encoded decimal number. If a contains fewer than keys, the assertion MUST be omitted from processing. Only identifiers which appear in the Local-Init can be used as attributes in Licensees (see section 2.2). An attribute is resolved to a string, which is then treated as a key or logical tag. The keys, attributes, or logical tags that appear in the Licensees and the various expressions are treated as variables for the purpose of evaluation. The values these variables take are: - If a key, attribute, or logical tag appears in the action authorizers (see section 5), its value is the highest among the permissible return values. The empty write-back set is associated with it. - Otherwise, if the key, attribute, or logical tag appears in the Authorizer field of one or more assertions, the value it takes is the highest value of those assertions, and the associated write-back set. If more than one assertion share the highest possible value, the write-back set of one is picked arbitrarily. Which one is picked is implementation-dependent and may be non-deterministic. - Otherwise, the value of the key, attribute, or logical tag is the lowest possible. The empty write-back set is associated with it. If the Licencees field is empty, it always evaluates to the highest possible value (which is set by the application), and is used for direct authorization of a Conditions by a policy or a credential. The semantics of the various key expressions are: - A "(..)" expression has the value of the enclosed subexpression. It also inherits the write-back set from the enclosed subexpression. - A "&&" expression has the lower of its two subexpression values. The resulting write-back set is the combination of the write-back sets of the two subexpressions, where the lower-value write-back set writes over variables which appear in the higher-value write-back set. For example, let Licensees: Key1 && Key2 The value of Key1 is "value1" The value of Key2 is "value2" 'value1' is higher than 'value2' in the linear order of return values The write-back set of Key1 is "str1=val1, str2=val2" The write-back set of Key2 is "str1=val3, str4=val4" Then the resulting value will be "value2," and the write-back set will be "str1=val3, str2=val2, str4=val4." If both subexpressions have the same value, then the left subexpression's write-back set writes over the right subexpression's write-back set. In the above setup, the resulting write-back set if the two keys had the same value would be "str1=val1, str2=val2, str4=val4." - A "||" expression has the higher of its two subexpression values. The resulting write-back set is that associated with the returned value. In case of a tie, the left subexpression's write-back set is the resulting write-back set. - A "K-OF(...)" expression has the K-th highest value of those among the keys and logical tags enclosed. Values which appear multiple times are counted as many times as they appear. For example, if K = 3 and the values are (0, 1, 2, 2, 3), the value of the threshold is 2; if the "2" values were only counted once, then the result of the expression would have been "1," not "2." The resulting write-back set is the combination of the write-back sets associated with the K highest values in the list, with the higher write-back sets writing over lower write-back sets. If more than K keys share the K highest values, the leftmost K (as they appear in the keylist) are used. For example, if K = 3 and the values are (0, 1, 2, 2, 3), the resulting write-back set will be that of the right-most "2," written-over by the write-back set of the "2" on its left, and the result written-over by the write-back set of the "3." Notice that in the case of two values (true/false), the above rules of value resolution reduce to boolean logic. 3.5 The Signature field The Signature field is of the form Signature: : The formats of and are identical to those described for keys in section 2.1. The cryptographic algorithm in should be the same as the one in the key appearing in the Authorizer field. The IANA will provide a registry of reserved names. It is not necessary that the encodings of the signature and the authorizer key be the same. The signature is computed over the assertion, beginning at the KeyNote-Version field (including the keyword), up to (and including) the Signature field (the colon following the keyword is also included), concatenated with the field (trailing colon included). This field MUST be last in a KeyNote assertion. Note that the Signatures used in examples in this document are fictitious and generally shorter than would be required for security. 3.6 The Comment field The Comment field is of the form Comment: The interpretation of this field is application-dependent. 3.7 The Export field The Export field is of the form Export: [, ]* where has already been defined in section 2.2. This field contains a list of write-back environment attributes which this assertion is willing to export to its descendants. If this field is present but empty, it is taken to mean "All write-back environment attributes are exported." If it is missing, no write-back environment attribute is exported. See section 2.5 for more details on write-back environments. See section 6 on how the Export field is used in conjunction with write-back environments. 3.8 The Conditions field This field determines the conditions under which the Authorizer trusts the Licensees to perform an action. This field is of the form Conditions: where is given by the following grammar: Program: /* Nothing */ | : -> { } | -> { } : | : "return" /* Case insensitive "return" */ | = , /* WriteBack */ | = , /* WriteBack */ | = , /* WriteBack */ : ( ) | /* Parentheses */ && | /* Logical AND */ || | /* Logical OR */ ! | /* Logical NOT */ | /* Integer boolean expression */ | /* Floating point boolean expr. */ | /* String boolean expression */ "true" | /* Case insensitive keyword */ "false" /* Case insensitive keyword */ : == | != | < | > | <= | >= | : < | > | <= | >= : == | /* String equality */ != | /* String inequality */ < | /* Alphanumeric comparisons */ > | <= | >= | ~= /* Regular expr. matching */ : + | /* String concatenation */ . | /* Also string concatenation */ | /* Quoted or otherwise */ | /* Look in Local-Init and action env. */ $( ) /* Dynamic resolution */ : + | /* Integer operations */ - | * | / | % | ^ | /* Exponentiation */ - | ( ) | | | @( ) /* Dynamic resolution */ : + | /* Floating point operations */ - | * | / | ^ | /* Exponentiation */ - | ( ) | | | &( ) /* Dynamic resolution */ : [0-9]+ : {} . {} : [a-zA-Z0-9][a-zA-Z0-9_]* : $ : @ : & is a quoted or unquoted string, and is described in section 2. The binary numeric operation precedence is (higher to lower) ^, (*, /, %), (+, -). Operators of equal precedence are evaluated left-to-right. String operations (including regexps) in the Conditions can be case-sensitive or case-insensitive, specified as a run-time option. A division (or modulo) by zero causes the enclosing boolean expression to evaluate to the lowest value. The keywords "true," "false," and "return" are not reserved; they can be identifier names (but this practice is discouraged). The "$()" construct causes a lookup of the string resulting from the evaluation of the string expression in the Local-Init attributes (and if that fails to find a match, in the action-environment attributes). If evaluates to the empty string, the enclosing boolean expression MUST evaluate to false. Similarly for the "@()" and "&()" constructs. refers to the POSIX 1003.2 regular expression syntax and semantics. A regular expression is true if the left hand string expression matches . If group matching is used, the number of groups matched MUST be placed in the temporary attribute $0, and the subsequent matches should be placed in the temporary attributes $1, $2, ..., $($0). These values should be discarded when a subsequent regular expression is encountered, or if the current expression does not evaluate to true. If an invalid is encountered, the assertion MUST be omitted from processing. If an Conditions field is empty, it always evaluates to the highest possible return value. If no expressions match, the value of this assertion is the lowest value, and there is no associated write-back set. More than one expression can exist in a Conditions field. The semantics then are that the first expression that evaluates to true, returns a value and a write-back environment. Furthermore, expressions can be nested, using the "-> { ... }" construct. Consequently, an expression can be viewed as a series of boolean expressions that lead to a write-back environment/return value. The first such expression where all the boolean expressions are true `fires.' As an example, consider the Conditions with the following expressions: expression1 -> { expression11 -> {return somevalue} expression12 -> {return someothervalue} } expression2 -> { expression21 -> {return somethirdvalue} } expression3 -> {return justavalue} If expression1 and expression11 are true, then the returned value will be "somevalue." If expression1 is true, expression11 is false, and expression12 is true, "someothervalue" will be returned. If expression1 if false, or both expression11 and expression12 are false, the following expressions will be evaluated. A syntax or semantic error in any of these expressions MUST cause the assertion to be omitted from processing. If a write-back environment block causes an exception (either through a division by zero or through invalid use of one of the "$()," "@()," or "&" constructs), the expressions are considered false. For example, the expression set expression1 -> { expression11 -> {a=1/0, return something} expression12 -> {a=1, return somethingelse} } (assuming all three expressions are true) MUST return "somethingelse." An exception is also raised if the same write-back attribute is used twice in the same block. The return values MUST be checked for validity (using a case-insensitive string comparison) against the (ordered) set of possible return values supplied by the application. If a value is invalid, the assertion MUST be omitted from processing. For the write-back expressions (which are of the form = ), the left subexpression MUST evaluate to a string. The result MUST be treated as the name of an attribute in the write-back environment. All attribute lookups made in the process of constructing the left subexpression string MUST be made among the Local-Init and action-environment attributes. All attribute lookups made in the process of constructing the right subexpression (which can be a string, integer, or floating point expression) are made among the Local-Init and action-environment attributes. The write-back set constructed, is associated with the return value for the purposes of Licensees evaluation (see section 3.4). 4. Action Environments 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 attributes used by assertion predicates. The action environment specifies a collection of values of named attributes that may be examined by KeyNote trust predicates. The exact format for specifying an action environment is determined by the particular KeyNote implementation. In general, an environment may be thought of as a list of assignments to attributes: attribute1=value1 attribute2=value2 ... 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 "@" character) or as a floating point number (through the "&" character) MUST consist entirely of digits and at most one period. In both cases, if the attribute contains any illegal character, the resulting value MUST be zero. The attribute "$Action_Authorizers," MAY hold the keys which have signed the request. This attribute lists the keys of the action authorizers keys (see section 5). 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 which 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. Also 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) $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 suggests.) 5. Action Authorizers The keys which authenticate (sign) a request (i.e., the keys which have signed a message whose trustworthiness KeyNote is evaluating) are placed in an implementation-dependent data structure. Lookups are made in that data structure to match keys in the Licensees of an assertion and keys in the data structure, during the Licensees parse process (section 3.4). Those comparisons are in key-canonical form (as defined by the algorithm name of the key). For logical tags or unsupported algorithms, case-sensitive string comparison is used instead (see section 3.4). 6. KeyNote Action Evaluation This section describes the semantics of KeyNote action evaluation. An implementation is free to use any algorithm that provides equivalent semantics. Initialization: The attribute $App_Domain is assigned the name of the application (e.g., "RFC822-EMAIL"). The keys that sign the request for a trusted action are placed in the implementation-dependent action authorizers data structure. The rest of the action-environment attributes are placed in their respective attributes. The time of day MAY be placed in the attributes $GMTTimeOfDay and $LocalTimeOfDay, using the format YYYYMMDDHHMMSS (e.g., 19980307191512). Any other implementation-dependent attributes and their bindings are also created at this step. For each KeyNote assertion passed to the evaluation engine, the following steps are taken: The Conditions expression is evaluated. If the result is the lowest possible value, then the result of this assertion evaluation is that lowest value and nothing else is evaluated for that assertion. Otherwise, the key expression in the Licensees field is evaluated, and the resulting value of this assertion is the lower of the values of its Conditions and its Licensees expressions. The write-back set of this assertion is the combination of: - The write-back set of this assertion's Conditions (if any) - The write-back set that is the result of this assertion's Licensees, after all the write-back attributes which are not exported (through the Export field, see section 3.7) by this assertion are removed. The Licensees write-back set writes over the Conditions write-back set. The Licensees field public-key expression is evaluated as follows: Let the key expression contain public key PK_i. A variable `PK_i' corresponds to this key. If there is no assertion in which PK_i is the Authorizer, and PK_i does not appear in the action authorizers, the value of the variable `PK_i' is the lowest return value. If PK_i appears in the action authorizers, the value of the variable `PK_i' is the highest return value. If PK_i appears in the Authorizer field of an assertion, the value of the variable 'PK_i' is that of the assertion. If there is more than one assertion where PK_i is the Authorizer, `PK_i' takes the highest value among those assertions. The goal is to construct a directed graph of KeyNote assertions rooted at a POLICY assertion of the evaluator that connects with at least one of the keys in the action authorizers. The value returned to the application (and the associated write-back set) is that of the highest-valued POLICY assertion. Delegation of some authorization from key A to a set of keys B is expressed as an assertion with key A in the Authorizer field, key set B in the Licensees field, and the authorization delegated encoded in the Conditions field. How the expression digraph is constructed is implementation-dependent, in particular because different implementations may use different algorithms for optimizing the graph construction. 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 architecture to support a KeyNote system is therefore rather different from that for a name-based certification scheme. The KeyNote trust-management architecture is based on that of PolicyMaker [BFL96,BFS98]. 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: - 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. - 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 which 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 that assertion. Omitting credentials may, of course, result in legal action environments being disallowed. Selecting appropriate credentials (e.g., from a 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 which require credential revocation can use KeyNote to help specify and implement revocation policies. A future draft will address expiration and revocation services in KeyNote. Because KeyNote is designed to support a variety of applications, several different application interfaces to a KeyNote implementation are possible. In its simplest form, 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. 8. Security Considerations This draft discusses a trust-management system The draft is itself concerned with a security mechanism. 9. Acknowledgments We thank Lorrie Faith Cranor (AT&T Labs - Research) and Jonathan M. Smith (University of Pennsylvania) for their suggestions and comments on earlier versions of this draft. References [BFL96] M. Blaze, J. Feigenbaum, J. Lacy, Decentralized Trust Management, 1996 IEEE Conference on Privacy and Security, Oakland, 1996. [BFS98] M. Blaze, J. Feigenbaum, M. Strauss, Compliance-Checking in the PolicyMaker Trust-Management System, 1998 Financial Crypto Conference [Bra97] S. Bradner, Key words for use in RFCs to Indicate Requirement Level, RFC 2119, March 1997. [DSA94] Digital Signature Standard, FIPS-186, National Institute of Standards, U.S. Department of Commerce, May 1994. [PKCS1] PKCS #1: RSA Encryption Standard, Version 1.5, RSA Laboratories, November 1993. [RSA78] A Method for Obtaining Digital Signatures and Public-Key Cryptosystems, R. L. Rivest, A. Shamir, L. M. Adleman, Communications of the ACM, v21n2, February 1978. Contacts Comments about this document should be discussed on the trustmgt@east.isi.edu mailing list. The archive for that list can be found at http://www.cairn.net/trustmgt/ Questions about this document can also be directed to: Matt Blaze Joan Feigenbaum John Ioannidis mab@research.att.com jf@research.att.com ji@research.att.com AT&T Labs - Research 180 Park Avenue Florham Park, New Jersey 07932-0000 Angelos D. Keromytis Distributed Systems Lab CIS Department, University of Pennsylvania 200 S. 33rd Street Philadelphia, Pennsylvania 19104-6389 Email: angelos@dsl.cis.upenn.edu