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.
Abstract
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.
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].
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)
answer.
- Credential signature verification is built in to the KeyNote
system.
- 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
appear (COMMENT, SIGNATURE, and LOCAL-INIT).
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).
2.2 The KEYNOTE-VERSION field
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
in the KEY-PREDICATE field as KEY-PREDICATE: $ANGELOS_DSA_KEY
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 |
KEY-EXPR "||" KEY-EXPR |
K-of(KEYLIST) |
KEY |
"$"STRING
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
credential.
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,
LOCAL-INIT, KEY-PREDICATE, COMMENT, and ACTION-PREDICATE fields,
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.
2.8 The ACTION-PREDICATE field
The ACTION-PREDICATE field is of the form ACTION-PREDICATE: EXPR,
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 */
LITERALSTRING |
VARIABLE
"$(" 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
(NUMEX) |
NUMBER |
NUMVARIABLE
FLOATEX: FLOATEX + FLOATEX | /* Floating point operations */
FLOATEX - FLOATEX |
FLOATEX * FLOATEX |
FLOATEX / FLOATEX |
FLOATEX ^ FLOATEX | /* Exponentiation */
-FLOATEX
(FLOATEX) |
FLOAT |
FLOATVARIABLE
NUMBER: [0-9]+
FLOAT: {NUMBER} "." {NUMBER}
STRING: [a-zA-Z][a-zA-Z0-9_]*
VSTRING: [a-zA-Z0-9][a-zA-Z0-9_]*
DQUOTE: \"
LITERALSTRING: DQUOTE (([^\"\n])|(\\[.\n]))* DQUOTE
VARIABLE: "$"VSTRING
NUMVARIABLE: "@"VSTRING
FLOATVARIABLE: "&"VSTRING
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.
3. 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 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
variables:
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 "@"
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
section):
$ACTION_SIGNERS="dsa:12:abcdef123456"
If an action is associated with more than one key, the
ACTION_SIGNERS attribute may contain a comma-separated list of keys.
$ACTION_SIGNERS="dsa:20:123400000123abd12212,
rsa:28:ab34781acc01923cdeff232ff232"
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
suggests.)
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.
Initialization:
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.,
19980307191512).
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
rejected.
The KEY-PREDICATE field public-key expression is evaluated as
follows:
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.
1. TRADITIONAL CA / EMAIL
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",
TRUSTED_PARTY2="rsa-sha1-pkcsX:6:d1234f"
SIGNER: rsa-sha1-pkcsX:6:abc123
KEY-PREDICATE: $TRUSTED_PARTY1 || $TRUSTED_PARTY2
ACTION-PREDICATE: ($app_domain == "RFC822-EMAIL") &&
($address ~=
"^.*@keynote\\.research\\.att\\.com$")
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 ==
"mab@keynote.research.att.com"))
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 ||
rsa-md5-pkcsX:6:fd091a
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"
and
$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"
and
$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"
and
$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
key:
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 ==
"angelos@keynote.research.att.com")
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
2. WORKFLOW/ELECTRONIC COMMERCE
F. A policy that delegates authority for the "SPEND" application
domain to RSA key babe12 when @dollars is less than
10000.
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 ||
dsa-sha1-pkcsX:6:978add)
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:,
rsa-sha1-pkcsX:6:abc113,
dsa-sha1-pkcsX:6:bcd987,
dsa-sha1-pkcsX:6:cde333,
dsa-sha1-pkcsX:6:def975,
dsa-sha1-pkcsX:6:978add)
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 ||
dsa-sha1-pkcsX:6:978add)
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
$unmentioned_variable="whatever"
and
$action_signer = "rsa-sha1-pkcsX:6:abc123,
dsa-sha1-pkcsX:8:cde333"
$app_domain = "SPEND"
@dollars = 550
and
$action_signer = "dsa-sha1-pkcsX:8:feed1234,
dsa-sha1-pkcsX:6:cde333"
$app_domain = "SPEND"
@dollars = 2500
and
$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
and
$action_signer = "dsa-sha1-pkcsX:8:cde333,
dsa-sha1-pkcsX:8:978add"
$app_domain = "SPEND"
@dollars = 2500
3. COMMAND AND CONTROL AUTHORIZATION
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,
rsa-sha1-pkcsX:8:ff123ad3,
Blaze/Feigenbaum/Keromytis expires in six months [Page 12]
DRAFT KeyNote April 1998
dsa-sha1-pkcsX:8:198714fd,
dsa-sha1-pkcsX:8:a1984cde,
dsa-sha1-pkcsX:6:975135)
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
mechanism.
Blaze/Feigenbaum/Keromytis expires in six months [Page 14]
DRAFT KeyNote April 1998
References
[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,
http://www.clark.net/pub/cme/theory.txt
Contacts
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
mab@research.att.com
Joan Feigenbaum
AT&T Labs - Research
180 Park Avenue
Florham Park, New Jersey 07932
jf@research.att.com
Angelos D. Keromytis
Distributed Systems Lab
CIS Department, University of Pennsylvania
200 S. 33rd Street
Philadelphia, Pennsylvania 19104-6389
angelos@dsl.cis.upenn.edu
Blaze/Feigenbaum/Keromytis expires in six months [Page 15]