idnits 2.17.1 draft-blaze-ietf-trustmgt-keynote-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 36 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1646 has weird spacing: '...att.com jf@r...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1999) is 9080 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'BFL96' -- Possible downref: Non-RFC (?) normative reference: ref. 'BFS98' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bla99' ** Obsolete normative reference: RFC 822 (ref. 'Cro82') (Obsoleted by RFC 2822) -- Possible downref: Non-RFC (?) normative reference: ref. 'DSA94' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS1' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA78' Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Matt Blaze 2 INTERNET DRAFT Joan Feigenbaum 3 Expires 31 October 1999 John Ioannidis 4 AT&T Labs - Research 5 Angelos D. Keromytis 6 U. of Pennsylvania 7 June 1999 9 The KeyNote Trust-Management System 10 Version 2 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Please direct comments to one of the authors (for the authors contact 19 information, see the end of this document), and/or to the 20 trustmgt@east.isi.edu mailing list. 22 Internet Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working Groups. Note that 24 other groups may also distribute working documents as Internet 25 Drafts. 27 Internet-Drafts draft documents are valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress". 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Distribution of this memo is unlimited. 40 Abstract 42 This memo describes version 2 of the KeyNote trust-management system. 43 It specifies the syntax and semantics of KeyNote `assertions,' 44 describes `action attribute' processing, and outlines the application 45 architecture into which a KeyNote implementation can be fit. The 46 KeyNote architecture and language are useful as building blocks for 47 the trust management aspects of a variety of Internet protocols and 48 services. 50 1. Introduction 52 Trust management, introduced in the PolicyMaker system [BFL96], is a 53 unified approach to specifying and interpreting security policies, 54 credentials, and relationships; it allows direct authorization of 55 security-critical actions. A trust-management system provides 56 standard, general-purpose mechanisms for specifying application 57 security policies and credentials. Trust-management credentials 58 describe a specific delegation of trust and subsume the role of 59 public key certificates; unlike traditional certificates, which bind 60 keys to names, credentials can bind keys directly to the 61 authorization to perform specific tasks. 63 A trust-management system has five basic components: 65 * A language for describing `actions,' which are operations with 66 security consequences that are to be controlled by the system. 68 * A mechanism for identifying `principals,' which are entities that 69 can be authorized to perform actions. 71 * A language for specifying application `policies,' which govern the 72 actions that principals are authorized to perform. 74 * A language for specifying `credentials,' which allow principals 75 to delegate authorization to other principals. 77 * A `compliance checker,' which provides a service to applications 78 for determining how an action requested by principals should be 79 handled, given a policy and a set of credentials. 81 The trust-management approach has a number of advantages over other 82 mechanisms for specifying and controlling authorization, especially 83 when security policy is distributed over a network or is otherwise 84 decentralized. 86 Trust management unifies the notions of security policy, credentials, 87 access control, and authorization. An application that uses a trust- 88 management system can simply ask the compliance checker whether a 89 requested action should be allowed. Furthermore, policies and 90 credentials are written in standard languages that are shared by all 91 trust-managed applications; the security configuration mechanism for 92 one application carries exactly the same syntactic and semantic 93 structure as that of another, even when the semantics of the 94 applications themselves are quite different. 96 Trust-management policies are easy to distribute across networks, 97 helping to avoid the need for application-specific distributed policy 98 configuration mechanisms, access control lists, and certificate 99 parsers and interpreters. 101 For a general discussion of the use of trust management in 102 distributed system security, see [Bla99]. 104 KeyNote is a simple and flexible trust-management system designed to 105 work well for a variety of large- and small- scale Internet-based 106 applications. It provides a single, unified language for both local 107 policies and credentials. KeyNote policies and credentials, called 108 `assertions,' contain predicates that describe the trusted actions 109 permitted by the holders of specific public keys. KeyNote assertions 110 are essentially small, highly-structured programs. A signed 111 assertion, which can be sent over an untrusted network, is also 112 called a `credential assertion.' Credential assertions, which also 113 serve the role of certificates, have the same syntax as policy 114 assertions but are also signed by the principal delegating the trust. 116 In KeyNote: 118 * Actions are specified as a collection of name-value pairs. 120 * Principal names can be any convenient string and can directly 121 represent cryptographic public keys. 123 * The same language is used for both policies and credentials. 125 * The policy and credential language is concise, highly expressive, 126 human readable and writable, and compatible with a variety of 127 storage and transmission media, including electronic mail. 129 * The compliance checker returns an application-configured `policy 130 compliance value' that describes how a request should be handled 131 by the application. Policy compliance values are always 132 positively derived from policy and credentials, facilitating 133 analysis of KeyNote-based systems. 135 * Compliance checking is efficient enough for high-performance and 136 real-time applications. 138 This document describes the KeyNote policy and credential assertion 139 language, the structure of KeyNote action descriptions, and the 140 KeyNote model of computation. 142 We assume that applications communicate with a locally trusted 143 KeyNote compliance checker via a `function call' style interface, 144 sending a collection of KeyNote policy and credential assertions plus 145 an action description as input and accepting the resulting policy 146 compliance value as output. However, the requirements of different 147 applications, hosts, and environments may give rise to a variety of 148 different interfaces to KeyNote compliance checkers; this document 149 does not aim to specify a complete compliance checker API. 151 2. KeyNote Concepts 153 In KeyNote, the authority to perform trusted actions is associated 154 with one or more `principals.' A principal may be a physical entity, 155 a process in an operating system, a public key, or any other 156 convenient abstraction. KeyNote principals are identified by a 157 string called a `Principal Identifier.' In some cases, a Principal 158 Identifier will contain a cryptographic key interpreted by the 159 KeyNote system (e.g., for credential signature verification). In 160 other cases, Principal Identifiers may have a structure that is 161 opaque to KeyNote. 163 Principals perform two functions of concern to KeyNote: They request 164 `actions' and they issue `assertions.' Actions are any trusted 165 operations that an application places under KeyNote control. 166 Assertions delegate the authorization to perform actions to other 167 principals. 169 Actions are described to the KeyNote compliance checker in terms of a 170 collection of name-value pairs called an `action attribute set.' The 171 action attribute set is created by the invoking application. Its 172 structure and format are described in detail in Section 3 of this 173 document. 175 KeyNote provides advice to applications on the interpretation of 176 policy with regard to specific requested actions. Applications 177 invoke the KeyNote compliance checker by issuing a `query' containing 178 a proposed action attribute set and identifying the principal(s) 179 requesting it. The KeyNote system determines and returns an 180 appropriate `policy compliance value' from an ordered set of possible 181 responses. 183 The policy compliance value returned from a KeyNote query advises the 184 application how to process the requested action. In the simplest 185 case, the compliance value is Boolean (e.g., "reject" or "approve"). 186 Assertions can also be written to select from a range of possible 187 compliance values, when appropriate for the application (e.g., "no 188 access", "restricted access", "full access"). Applications can 189 configure the relative ordering (from `weakest' to `strongest') of 190 compliance values at query time. 192 Assertions are the basic programming unit for specifying policy and 193 delegating authority. Assertions describe the conditions under which 194 a principal authorizes actions requested by other principals. An 195 assertion identifies the principal that made it, which other 196 principals are being authorized, and the conditions under which the 197 authorization applies. The syntax of assertions is given in Section 198 4. 200 A special principal, whose identifier is "POLICY", provides the root 201 of trust in KeyNote. "POLICY" is therefore considered to be 202 authorized to perform any action. 204 Assertions issued by the "POLICY" principal are called `policy 205 assertions' and are used to delegate authority to otherwise untrusted 206 principals. The KeyNote security policy of an application consists 207 of a collection of policy assertions. 209 When a principal is identified by a public key, it can digitally sign 210 assertions and distribute them over untrusted networks for use by 211 other KeyNote compliance checkers. These signed assertions are also 212 called `credentials,' and serve a role similar to that of traditional 213 public key certificates. Policies and credentials share the same 214 syntax and are evaluated according to the same semantics. A 215 principal can therefore convert its policy assertions into 216 credentials simply by digitally signing them. 218 KeyNote is designed to encourage the creation of human-readable 219 policies and credentials that are amenable to transmission and 220 storage over a variety of media. Its assertion syntax is inspired by 221 the format of RFC822-style message headers [Cro82]. A KeyNote 222 assertion contains a sequence of sections, called `fields,' each of 223 which specifying one aspect of the assertion's semantics. Fields 224 start with an identifier at the beginning of a line and continue 225 until the next field is encountered. For example: 227 KeyNote-Version: 2 228 Comment: A simple, if contrived, email certificate for user mab 229 Local-Constants: ATT_CA_key = "RSA:acdfa1df1011bbac" 230 mab_key = "DSA:deadbeefcafe001a" 231 Authorizer: ATT_CA_key 232 Licensees: mab_key 233 Conditions: ((app_domain == "email") # valid for email only 234 && (address == "mab@research.att.com")); 235 Signature: "RSA-SHA1:f00f2244" 237 The meanings of the various sections are described in Sections 4 and 238 5 of this document. 240 KeyNote semantics resolve the relationship between an application's 241 policy and actions requested by other principals, as supported by 242 credentials. The KeyNote compliance checker processes the assertions 243 against the action attribute set to determine the policy compliance 244 value of a requested action. These semantics are defined in Section 245 5. 247 An important principle in KeyNote's design is `assertion 248 monotonicity'; the policy compliance value of an action is always 249 positively derived from assertions made by trusted principals. 250 Removing an assertion never results in increasing the compliance 251 value returned by KeyNote for a given query. The monotonicity 252 property can simplify the design and analysis of complex network- 253 based security protocols; network failures that prevent the 254 transmission of credentials can never result in spurious 255 authorization of dangerous actions. A detailed discussion of 256 monotonicity and safety in trust management can be found in [BFL96] 257 and [BFS98]. 259 3. Action Attributes 261 Trusted actions to be evaluated by KeyNote are described by a 262 collection of name-value pairs called the `action attribute set.' 263 Action attributes are the mechanism by which applications communicate 264 requests to KeyNote and are the primary objects on which KeyNote 265 assertions operate. An action attribute set is passed to the KeyNote 266 compliance checker with each query. 268 Each action attribute consists of a name and a value. The semantics 269 of the names and values are not interpreted by KeyNote itself; they 270 vary from application to application and must be agreed upon by the 271 writers of applications and the writers of the policies and 272 credentials that will be used by them. 274 Action attribute names and values are represented by arbitrary-length 275 strings. KeyNote guarantees support of attribute names and values up 276 to 2048 characters long. The handling of longer attribute names or 277 values is not specified and is KeyNote- implementation-dependent. 278 Applications and assertions should therefore avoid depending on the 279 the use of attributes with names or values longer than 2048 280 characters. The length of an attribute value is represented by an 281 implementation-specific mechanism (e.g., NUL-terminated strings, an 282 explicit length field, etc.). 284 Attribute values are inherently untyped and are represented as 285 character strings by default. Attribute values may contain any non- 286 NUL ASCII character. Numeric attribute values should first be 287 converted to an ASCII text representation by the invoking 288 application, e.g., the value 1234.5 would be represented by the 289 string "1234.5". 291 Attribute names are of the form: 293 :: {Any string starting with a-z, A-Z, or the 294 underscore character, followed by any number of 295 a-z, A-Z, 0-9, or underscore characters} ; 297 That is, an begins with an alphabetic or underscore 298 character and can be followed by any number of alphanumerics and 299 underscores. Attribute names are case-sensitive. 301 The exact mechanism for passing the action attribute set to the 302 compliance checker is determined by the KeyNote implementation. 303 Depending on specific requirements, an implementation may provide a 304 mechanism for including the entire attribute set as an explicit 305 parameter of the query, or it may provide some form of callback 306 mechanism invoked as each attribute is dereferenced, e.g., for access 307 to kernel variables. 309 If an action attribute is not defined its value is considered to be 310 the empty string. 312 Attribute names beginning with the "_" character are reserved for use 313 by the KeyNote runtime environment and cannot be passed from 314 applications as part of queries. The following special attribute 315 names are used: 317 Name Purpose 318 ------------------------ ------------------------------------ 319 _MIN_TRUST Lowest-order (minimum) compliance 320 value in query; see Section 5.1. 322 _MAX_TRUST Highest-order (maximum) compliance 323 value in query; see Section 5.1. 325 _VALUES Linearly ordered set of compliance 326 values in query; see Section 5.1. 327 Comma separated. 329 _ACTION_AUTHORIZERS Names of principals directly 330 authorizing action in query. 331 Comma separated. 333 In addition, attributes with names of the form "_", where is 334 an ASCII-encoded integer, are used by the regular expression matching 335 mechanism described in Section 5. 337 The assignment and semantics of any other attribute names beginning 338 with "_" is unspecified and implementation-dependent. 340 The names of other attributes in the action attribute set are not 341 specified by KeyNote but must be agreed upon by the writers of any 342 policies and credentials that are to inter-operate in a specific 343 KeyNote query evaluation. 345 By convention, the name of the application domain over which action 346 attributes should be interpreted is given in the attribute named 347 "app_domain". The IANA (or some other suitable authority) will 348 provide a registry of reserved app_domain names. The registry will 349 list the names and meanings of each application's attributes. 351 The app_domain convention helps to ensure that credentials are 352 interpreted as they were intended. An attribute with any given name 353 may be used in many different application domains but might have 354 different meanings in each of them. However, the use of a global 355 registry is not always required for small-scale, closed applications; 356 the only requirement is that the policies and credentials made 357 available to the KeyNote compliance checker interpret attributes 358 according to the same semantics assumed by the application that 359 created them. 361 For example, an email application might reserve the app_domain 362 "RFC822-EMAIL" and might use the attributes named "address" (the 363 email address of a message's sender), "name" (the human name of the 364 message sender), and any "organization" headers present (the 365 organization name). The values of these attributes would be derived 366 in the obvious way from the email message headers. The public key of 367 the message's signer would be given in the "_ACTION_AUTHORIZERS" 368 attribute. 370 Note that "RFC822-EMAIL" is a hypothetical example; such a name may 371 or may not appear in the actual registry with these or different 372 attributes. (Indeed, we recognize that the reality of email security 373 is considerably more complex than this example might suggest.) 375 4. KeyNote Assertion Syntax 377 In the following sections, the notation [X]* means zero or more 378 repetitions of character string X. The notation [X]+ means one or 379 more repetitions of X. The notation * means zero or more 380 repetitions of non-terminal . The notation + means one or more 381 repetitions of X, whereas ? means zero or one repetitions of X. 382 Nonterminal grammar symbols are enclosed in angled brackets. Quoted 383 strings in grammar productions represent terminals. 385 4.1 Basic Structure 387 :: ? ? 388 ? ? 389 ? ? ; 391 All KeyNote assertions are encoded in ASCII. 393 KeyNote assertions are divided into sections, called `fields,' that 394 serve various semantic functions. Each field starts with an 395 identifying label at the beginning of a line, followed by the ":" 396 character and the field's contents. There can be at most one field 397 per line. 399 A field may be continued over more than one line by indenting 400 subsequent lines with at least one ASCII SPACE or TAB character. 401 Whitespace (a SPACE, TAB, or NEWLINE character) separates tokens but 402 is otherwise ignored outside of quoted strings. Comments with a 403 leading octothorp character (see Section 4.2) may begin in any 404 column. 406 One mandatory field is required in all assertions: 408 Authorizer 410 Six optional fields may also appear: 412 Comment 413 Conditions 414 KeyNote-Version 415 Licensees 416 Local-Constants 417 Signature 419 All field names are case-insensitive. The "KeyNote-Version" field, 420 if present, appears first. The "Signature" field, if present, 421 appears last. Otherwise, fields may appear in any order. Each field 422 may appear at most once in any assertion. 424 Blank lines are not permitted in assertions. Multiple assertions 425 stored in a file (e.g., in application policy configurations), 426 therefore, can be separated from one another unambiguously by the use 427 of blank lines between them. 429 4.2 Comments 431 :: "#" {ASCII characters} ; 433 The octothorp character ("#", ASCII 35 decimal) can be used to 434 introduce comments. Outside of quoted strings (see Section 4.3), all 435 characters from the "#" character through the end of the current line 436 are ignored. However, commented text is included in the computation 437 of assertion signatures (see Section 4.6.7). 439 4.3 Strings 441 A `string' is a lexical object containing a sequence of characters. 442 Strings may contain any non-NUL characters, including newlines and 443 nonprintable characters. Strings may be given as literals, computed 444 from complex expressions, or dereferenced from attribute names. 446 4.3.1 String Literals 448 :: "\"" {see description below} "\"" ; 450 A string literal directly represents the value of a string. String 451 literals must be quoted by preceding and following them with the 452 double-quote character (ASCII 34 decimal). 454 A printable character may be `escaped' inside a quoted string literal 455 by preceding it with the backslash character (ASCII 92 decimal) 456 (e.g., "like \"this\"."). This permits the inclusion of the double- 457 quote and backslash characters inside string literals. 459 A similar escape mechanism is also used to represent non-printable 460 characters. "\n" represents the newline character (ASCII character 461 10 decimal), "\r" represents the carriage-return character (ASCII 462 character 13 decimal), "\t" represents the tab character (ASCII 463 character 9 decimal), and "\f" represents the form-feed character 464 (ASCII character 12 decimal). A backslash character followed by a 465 newline suppresses all subsequent whitespace (including the newline) 466 up to the next non-whitespace character (this allows the continuation 467 of long string constants across lines). Un-escaped newline and 468 return characters are illegal inside string literals. 470 The constructs "\0o", "\0oo", and "\ooo" (where o represents any 471 octal digit) may be used to represent any non-NUL ASCII characters 472 with their corresponding octal values (thus, "\012" is the same as 473 "\n", "\101" is "A", and "\377" is the ASCII character 255 decimal). 474 However, the NUL character cannot be encoded in this manner; "\0", 475 "\00", and "\000" are converted to the strings "0", "00", and "000" 476 respectively. Similarly, all other escaped characters have the 477 leading backslash removed (e.g., "\a" becomes "a", and "\\" becomes 478 "\"). The following four strings are equivalent: 480 "this string contains a newline\n followed by one space." 481 "this string contains a newline\n \ 482 followed by one space." 484 "this str\ 485 ing contains a \ 486 newline\n followed by one space." 488 "this string contains a newline\012\040followed by one space." 490 4.3.2 String Expressions 492 In general, anywhere a quoted string literal is allowed, a `string 493 expression' can be used. A string expression constructs a string 494 from string constants, dereferenced attributes (described in Section 495 4.4), and a string concatenation operator. String expressions may be 496 parenthesized. 498 :: "." /* String concatenation */ 499 | /* Quoted string */ 500 | "(" ")" 501 | /* See Section 4.4 */ 502 | "$" ; /* See Section 4.4 */ 504 The "$" operator has higher precedence than the "." operator. 506 4.4 Dereferenced Attributes 508 Action attributes provide the primary mechanism for applications to 509 pass information to assertions. Attribute names are strings from a 510 limited character set ( as defined in Section 3), and 511 attribute values are represented internally as strings. An attribute 512 is dereferenced simply by using its name. In general, KeyNote allows 513 the use of an attribute anywhere a string literal is permitted. 515 Attributes are dereferenced as strings by default. When required, 516 dereferenced attributes can be converted to integers or floating 517 point numbers with the type conversion operators "@" and "&". Thus, 518 an attribute named "foo" having the value "1.2" may be interpreted as 519 the string "1.2" (foo), the integer value 1 (@foo), or the floating 520 point value 1.2 (&foo). 522 Attributes converted to integer and floating point numbers are 523 represented according to the ANSI C `long' and `float' types, 524 respectively. In particular, integers range from -2147483648 to 525 2147483647, whilst floats range from 1.17549435E-38F to 526 3.40282347E+38F. 528 Any uninitialized attribute has the empty-string value when 529 dereferenced as a string and the value zero when dereferenced as an 530 integer or float. 532 Attribute names may be given literally or calculated from string 533 expressions and may be recursively dereferenced. In the simplest 534 case, an attribute is dereferenced simply by using its name outside 535 of quotes; e.g., the string value of the attribute named "foo" is by 536 reference to `foo' (outside of quotes). The "$" construct 537 dereferences the attribute named in the string expression . 538 For example, if the attribute named "foo" contains the string "bar", 539 the attribute named "bar" contains the string "xyz", and the 540 attribute "xyz" contains the string "qua", the following string 541 comparisons are all true: 543 foo == "bar" 544 $("foo") == "bar" 545 $foo == "xyz" 546 $(foo) == "xyz" 547 $$foo == "qua" 549 If evaluates to an invalid or uninitialized attribute name, 550 its value is considered to be the empty string (or zero if used as a 551 numeric). 553 The token is defined as: 555 :: ; 557 4.5 Principal Identifiers 559 Principals are represented as ASCII strings called `Principal 560 Identifiers.' Principal Identifiers may be arbitrary labels whose 561 structure is not interpreted by the KeyNote system or they may encode 562 cryptographic keys that are used by KeyNote for credential signature 563 verification. 565 :: 566 | ; 568 4.5.1 Opaque Principal Identifiers 570 Principal Identifiers that are used by KeyNote only as labels are 571 said to be `opaque.' Opaque identifiers are encoded in assertions as 572 strings (see Section 4.3): 574 :: ; 576 Opaque identifier strings should not contain the ":" character. 578 4.5.2 Cryptographic Principal Identifiers 580 Principal Identifiers that are used by KeyNote as keys, e.g., to 581 verify credential signatures, are said to be `cryptographic.' 582 Cryptographic identifiers are also lexically encoded as strings: 584 :: ; 586 Unlike Opaque Identifiers, however, Cryptographic Identifier strings 587 have a special form. To be interpreted by KeyNote (for signature 588 verification), an identifier string should be of the form: 590 :: ":" ; 592 "ALGORITHM" is an ASCII substring that describes the algorithms to be 593 used in interpreting the key's bits. The ALGORITHM identifies the 594 major cryptographic algorithm (e.g., RSA [RSA78], DSA [DSA94], etc.), 595 structured format (e.g., PKCS1 [PKCS1]), and key bit encoding (e.g., 596 HEX or BASE64). By convention, the ALGORITHM substring starts with 597 an alphabetic character and can contain letters, digits, underscores, 598 or dashes (i.e., it should match the regular expression "[a-zA-Z][a- 599 zA-Z0-9_-]*"). The IANA (or some other appropriate authority) will 600 provide a registry of reserved algorithm identifiers. 602 "ENCODEDBITS" is a substring of characters representing the key's 603 bits, the encoding and format of which depends on the ALGORITHM. By 604 convention, hexadecimal encoded keys use lower-case ASCII characters. 606 Cryptographic Principal Identifiers are converted to a normalized 607 canonical form for the purposes of any internal comparisons between 608 them; see Section 5.2. 610 Note that the keys used in examples throughout this document are 611 fictitious and generally much shorter than would be required for 612 security in practice. 614 4.6 KeyNote Fields 616 4.6.1 The KeyNote-Version Field 618 The KeyNote-Version field identifies the version of the KeyNote 619 assertion language under which the assertion was written. The 620 KeyNote-Version field is of the form 622 :: "KeyNote-Version:" ; 623 :: 624 | ; 626 where is an ASCII-encoded string. Assertions in 627 production versions of KeyNote use decimal digits in the version 628 representing the version number of the KeyNote language under which 629 they are to be interpreted. Assertions written to conform with this 630 document should be identified with the version string "2" (or the 631 integer 2). The KeyNote-Version field, if included, should appear 632 first. 634 4.6.2 The Local-Constants Field 636 This field adds or overrides action attributes in the current 637 assertion only. This mechanism allows the use of short names for 638 (frequently lengthy) cryptographic principal identifiers, especially 639 to make the Licensees field more readable. The Local-Constants field 640 is of the form: 642 :: "Local-Constants:" ; 643 :: /* can be empty */ 644 | "=" ; 646 is an attribute name from the action attribute 647 namespace as defined in Section 3. The name is available for use as 648 an attribute in any subsequent field. If the Local-Constants field 649 defines more than one identifier, it can occupy more than one line 650 and be indented. is a string literal as described in 651 Section 4.3. Attributes defined in the Local-Constants field 652 override any attributes with the same name passed in with the action 653 attribute set. 655 An attribute may be initialized at most once in the Local-Constants 656 field. If an attribute is initialized more than once in an 657 assertion, the entire assertion is considered invalid and is not 658 considered by the KeyNote compliance checker in evaluating queries. 660 4.6.3 The Authorizer Field 662 The Authorizer identifies the Principal issuing the assertion. This 663 field is of the form 665 :: "Authorizer:" ; 666 :: 667 | ; 669 The Principal Identifier may be given directly or by reference to the 670 attribute namespace (as defined in Section 4.4). 672 4.6.4 The Licensees Field 673 The Licensees field identifies the principals authorized by the 674 assertion. More than one principal can be authorized, and 675 authorization can be distributed across several principals through 676 the use of `and' and threshold constructs. This field is of the form 678 :: "Licensees:" ; 680 :: /* can be empty */ 681 | ; 683 :: "(" ")" 684 | "&&" 685 | "||" 686 | "-of(" ")" /* Threshold */ 687 | 688 | ; 690 :: 691 | 692 | "," ; 694 :: {Decimal number starting with a digit from 1 to 9} ; 696 The "&&" operator has higher precedence than the "||" operator. 697 is an ASCII-encoded positive decimal integer. If a 698 contains fewer than principals, the entire assertion is omitted 699 from processing. 701 4.6.5 The Conditions Field 703 This field gives the `conditions' under which the Authorizer trusts 704 the Licensees to perform an action. `Conditions' are predicates that 705 operate on the action attribute set. The Conditions field is of the 706 form: 708 :: "Conditions:" ; 710 :: /* Can be empty */ 711 | ";" ; 713 :: "->" "{" "}" 714 | "->" 715 | ; 717 :: ; 719 :: ; 720 :: "(" ")" /* Parentheses */ 721 | "&&" /* Logical AND */ 722 | "||" /* Logical OR */ 723 | "!" /* Logical NOT */ 724 | 725 | 726 | 727 | "true" /* case insensitive */ 728 | "false" ; /* case insensitive */ 730 :: "==" 731 | "!=" 732 | "<" 733 | ">" 734 | "<=" 735 | ">=" ; 737 :: "<" 738 | ">" 739 | "<=" 740 | ">=" ; 742 :: "==" /* String equality */ 743 | "!=" /* String inequality */ 744 | "<" /* Alphanum. comparisons */ 745 | ">" 746 | "<=" 747 | ">=" 748 | "~=" ; /* Reg. expr. matching */ 750 :: "+" /* Integer */ 751 | "-" 752 | "*" 753 | "/" 754 | "%" 755 | "^" /* Exponentiation */ 756 | "-" 757 | "(" ")" 758 | 759 | "@" ; 761 :: "+" /* Floating point */ 762 | "-" 763 | "*" 764 | "/" 765 | "^" /* Exponentiation */ 766 | "-" 767 | "(" ")" 768 | 769 | "&" ; 771 :: {Decimal number of at least one digit} ; 772 :: "." ; 774 is a quoted string as defined in Section 4.3 775 is defined in Section 3. 777 The operation precedence classes are (from highest to lowest): 779 { (, ) } 780 {unary -, @, &, $} 781 {^} 782 {*, /, %} 783 {+, -, .} 785 Operators in the same precedence class are evaluated left-to-right. 787 Note the inability to test for floating point equality, as most 788 floating point implementations (hardware or otherwise) do not 789 guarantee accurate equality testing. 791 Also note that integer and floating point expressions can only be 792 used within clauses of condition fields, but in no other KeyNote 793 field. 795 The keywords "true" and "false" are not reserved; they can be used as 796 attribute or principal identifier names (although this practice makes 797 assertions difficult to understand and is discouraged). 799 is a standard regular expression, conforming to the POSIX 800 1003.2 regular expression syntax and semantics. 802 Any string expression (or attribute) containing the ASCII 803 representation of a numeric value can be converted to an integer or 804 float with the use of the "@" and "&" operators, respectively. Any 805 fractional component of an attribute value dereferenced as an integer 806 is rounded down. If an attribute dereferenced as a number cannot be 807 properly converted (e.g., it contains invalid characters or is empty) 808 its value is considered to be zero. 810 4.6.6 The Comment Field 812 The Comment field allows assertions to be annotated with information 813 describing their purpose. It is of the form 815 :: "Comment:" ; 817 No interpretation of the contents of this field is performed by 818 KeyNote. Note that this is one of two mechanisms for including 819 comments in KeyNote assertions; comments can also be inserted 820 anywhere in an assertion's body by preceeding them with the "#" 821 character (except inside string literals). 823 4.6.7 The Signature Field 825 The Signature field identifies a signed assertions and gives the 826 encoded digital signature of the principal identified in the 827 Authorizer field. The Signature field is of the form: 829 :: "Signature:" ; 831 :: ; 833 The string should be of the form: 835 :: ":" ; 837 The formats of the "ALGORITHM" and "ENCODEDBITS" substrings are as 838 described for Cryptographic Principal Identifiers in Section 4.4.2 839 The algorithm name should be the same as that of the principal 840 appearing in the Authorizer field. The IANA (or some other suitable 841 authority) will provide a registry of reserved names. It is not 842 necessary that the encodings of the signature and the authorizer key 843 be the same. 845 If the signature field is included, the principal named in the 846 Authorizer field must be a Cryptographic Principal Indentifier, the 847 algorithm must be known to the KeyNote implementation, and the 848 signature must be correct for the assertion body and authorizer key. 850 The signature is computed over the assertion text, beginning with the 851 first field (including the field identifier string), up to (but not 852 including) the Signature field identifier. The newline preceeding 853 the signature field identifier is the last character included in 854 signature calculation. The signature is always the last field in a 855 KeyNote assertion. Text following this field is not considered part 856 of the assertion. 858 The algorithms for computing and verifying signatures must be 859 configured into each KeyNote implementation and are defined and 860 documented separately. 862 Note that all signatures used in examples in this document are 863 fictitious and generally much shorter than would be required for 864 security in practice. 866 5. Query Evaluation Semantics 868 The KeyNote compliance checker finds and returns the Policy 869 Compliance Value of queries, as defined in Section 5.3, below. 871 5.1 Query Parameters 873 A KeyNote query has four parameters: 875 * The identifier of the principal(s) requesting the action. 877 * The action attribute set describing the action. 879 * The set of compliance values of interest to the application, 880 ordered from _MIN_TRUST to _MAX_TRUST 882 * The policy and credential assertions that should be included 883 in the evaluation. 885 The mechanism for passing these parameters to the KeyNote evaluator 886 is application dependent. In particular, an evaluator might provide 887 for some parameters to be passed explicitly, while others are looked 888 up externally (e.g., credentials might be looked up in a network- 889 based distribution system), while still others might be requested 890 from the application as needed by the evaluator, through a `callback' 891 mechanism (e.g., for attribute values that represent values from 892 among a very large namespace). 894 5.1.1 Action Requester 896 At least one Principal must be identified in each query as the 897 `requester' of the action. Actions may be requested by several 898 principals, each considered to have individually requested it. This 899 allows policies that require multiple authorizations, e.g., `two 900 person control.' The set of authorizing principals is made available 901 in the special attribute "_ACTION_AUTHORIZERS"; if several principals 902 are authorizers, their identifiers are separated with commas. 904 5.1.2 Ordered Compliance Value Set 906 The set of compliance values of interest to an application (and their 907 relative ranking to one another) is determined by the invoking 908 application and passed to the KeyNote evaluator as a parameter of the 909 query. In many applications, this will be Boolean, e.g., the ordered 910 sets {FALSE, TRUE} or {REJECT, APPROVE}. Other applications may 911 require a range of possible values, e.g., {No_Access, Limited_Access, 912 Full_Access}. Note that applications should include in this set only 913 compliance values names that are actually returned by the assertions. 915 The lowest-order and highest-order compliance value strings given in 916 the query are available in the special attributes named "_MIN_TRUST" 917 and "_MAX_TRUST", respectively. The complete set of query compliance 918 values is made available in ascending order (from _MIN_TRUST to 919 _MAX_TRUST) in the special attribute named "_VALUES". Values are 920 separated with commas; applications that use assertions that make use 921 of the _VALUES attribute should therefore avoid the use of compliance 922 value strings that themselves contain commas. 924 5.2 Principal Identifier Normalization 926 Principal identifier comparisons among Cryptographic Principal 927 Identifiers (that represent keys) in the Authorizer and Licensees 928 fields or in an action's direct authorizers are performed after 929 normalizing them by conversion to a canonical form. 931 Every cryptographic algorithm used in KeyNote defines a method for 932 converting keys to their canonical form and that specifies how the 933 comparison for equality of two keys is performed. If the algorithm 934 named in the identifier is unknown to KeyNote, the identifier is 935 treated as opaque. 937 Opaque identifiers are compared as case-sensitive strings. 939 Notice that use of opaque identifiers in the Authorizer field 940 requires that the assertion's integrity be locally trusted (since it 941 cannot be cryptographically verified by the compliance checker). 943 5.3 Policy Compliance Value Calculation 945 The Policy Compliance Value of a query is the Principal Compliance 946 Value of the principal named "POLICY". This value is defined as 947 follows: 949 5.3.1 Principal Compliance Value 951 The Compliance Value of a principal is the highest order 952 (maximum) of: 954 - the Direct Authorization Value of principal ; and 956 - the Assertion Compliance Values of all assertions identifying 957 in the Authorizer field. 959 5.3.2 Direct Authorization Value 961 The Direct Authorization Value of a principal is _MAX_TRUST if 962 is listed in the query as an authorizer of the action. 964 Otherwise, the Direct Authorization Value of is _MIN_TRUST. 966 5.3.3 Assertion Compliance Value 968 The Assertion Compliance Value of an assertion is the lowest order 969 (minimum) of the assertion's Conditions Compliance Value and its 970 Licensee Compliance Value. 972 5.3.4 Conditions Compliance Value 974 The Conditions Compliance Value of an assertion is the highest- order 975 (maximum) value among all successful clauses listed in the conditions 976 section. 978 If no clause's test succeeds or the Conditions field is empty, an 979 assertion's conditions compliance value is considered to be the 980 _MIN_TRUST value, as defined Section 5.1. 982 If an assertion's Conditions field is missing entirely, its 983 conditions compliance value is considered to be the _MAX_TRUST value, 984 as defined in Section 5.1. 986 The set of successful test clause values is calculated as follows: 988 Recall from the grammar of section 4.6.5 that each clause in the 989 conditions section has two logical parts: a `test' and an optional 990 `value,' which, if present, is separated from the test with the "->" 991 token. The test subclause is a predicate that either succeeds 992 (evaluates to logical `true') or fails (evaluates to logical 993 `false'). The value subclause is a string expression that evaluates 994 to one value from the ordered set of compliance values given with the 995 query. If the value subclause is missing, it is considered to be 996 _MAX_TRUST. That is, the clause 998 foo=="bar"; 1000 is equivalent to 1002 foo=="bar" -> _MAX_TRUST; 1004 If the value component of a clause is present, in the simplest case 1005 it contains a string expression representing a possible compliance 1006 value. For example, consider an assertion with the following 1007 Conditions field: 1009 Conditions: 1010 @user_id == 0 -> "full_access"; # clause (1) 1011 @user_id < 1000 -> "user_access"; # clause (2) 1012 @user_id < 10000 -> "guest_access"; # clause (3) 1013 user_name == "root" -> "full_access"; # clause (4) 1015 Here, if the value of the "user_id" attribute is "1073" and the 1016 "user_name" attribute is "root", the possible compliance value set 1017 would contain the values "guest_access" (by clause (3)) and 1018 "full_access" (by clause (4)). If the ordered set of compliance 1019 values given in the query (in ascending order) is {"no_access", 1020 "guest_access", "user_access", "full_access"}, the conditions 1021 compliance value of the assertion would be "full_access" (because 1022 "full_access" has a higher-order value than "guest_access"). If the 1023 "user_id" attribute had the value "19283" and the "user_name" 1024 attribute had the value "nobody", no clause would succeed and the 1025 conditions compliance value would be "no_access", which is the 1026 lowest-order possible value (_MIN_TRUST). 1028 If a clause lists an explicit value, its value string must be named 1029 in the query ordered compliance value set. Values not named in the 1030 query compliance value set are considered equivalent to _MIN_TRUST. 1032 The value component of a clause can also contain recursively-nested 1033 clauses. Recursively-nested clauses are evaluated only if their 1034 parent test is true. That is, 1036 a=="b" -> { b=="c" -> "value1"; 1037 d=="e" -> "value2"; 1038 true -> "value3"; } ; 1040 is equivalent to 1042 (a=="b") && (b=="c") -> "value1"; 1043 (a=="b") && (d=="e") -> "value2"; 1044 (a=="b") -> "value3"; 1046 String comparisons are case-sensitive. 1048 A regular expression comparison ("~=") is considered true if the 1049 left-hand-side string expression matches the right-hand-side regular 1050 expression. If the POSIX regular expression group matching scheme is 1051 used, the number of groups matched is placed in the temporary meta- 1052 attribute "_0" (dereferenced as _0), and each match is placed in 1053 sequence in the temporary attributes (_1, _2, ..., _N). These match 1054 attributes values are valid only within subsequent references made 1055 within the same clause. Regular expression evaluation is case- 1056 sensitive. 1058 A runtime error occurring in the evaluation of a test, such as 1059 division by zero or an invalid regular expression, causes the test to 1060 be considered false. For example: 1062 foo == "bar" -> { 1063 @a == 1/0 -> "oneval"; # subclause 1 1064 @a == 2 -> "anotherval"; # subclause 2 1065 }; 1067 Here, subclause 1 triggers a runtime error. Subclause 1 is therefore 1068 false (and has the value _MIN_TRUST). Subclause 2, however, would be 1069 evaluated normally. 1071 An invalid is considered a runtime error and causes the 1072 test in which it occurs to be considered false. 1074 5.3.5 Licensee Compliance Value 1076 The Licensee Compliance Value of an assertion is calculated by 1077 evaluating the expression in the Licensees field, based on the 1078 Principal Compliance Value of the principals named there. 1080 If an assertion's Licensees field is empty, its Licensee Compliance 1081 Value is considered to be _MIN_TRUST. If an assertion's Licensees 1082 field is missing altogether, its Licensee Compliance Value is 1083 considered to be _MAX_TRUST. 1085 For each principal named in the Licensees field, its Principal 1086 Compliance Value is substituted for its name. If no Principal 1087 Compliance Value can be found for some named principal, its name is 1088 substituted with the _MIN_TRUST value. 1090 The licensees expression (as defined in Section 4.6.4) is evaluated 1091 as follows: 1093 * A "(...)" expression has the value of the enclosed subexpression. 1095 * A "&&" expression has the lower-order (minimum) of its two 1096 subexpression values. 1098 * A "||" expression has the higher-order (maximum) of its two 1099 subexpression values. 1101 * A "-of()" expression has the K-th highest order 1102 compliance value listed in . Values that appear multiple 1103 times are counted with multiplicity. For example, if K = 3 and 1104 the orders of the listed compliance values are (0, 1, 2, 2, 3), 1105 the value of the expression is the compliance value of order 2. 1107 For example, consider the following Licensees field: 1109 Licensees: ("alice" && "bob") || "eve" 1111 If the Principal Compliance Value is "yes" for principal "alice", 1112 "no" for principal "bob", and "no" for principal "eve", and "yes" is 1113 higher order than "no" in the query's Compliance Value Set, then the 1114 resulting Licensee Compliance Value is "no". 1116 Observe that if there are exactly two possible compliance values 1117 (e.g., "false" and "true"), the rules of Licensee Compliance Value 1118 resolution reduce exactly to standard Boolean logic. 1120 5.4 Assertion Management 1122 Assertions may be either signed or unsigned. Only signed assertions 1123 should be used as credentials or transmitted or stored on untrusted 1124 media. Unsigned assertions should be used only to specify policy and 1125 for assertions whose integrity has already been verified as 1126 conforming to local policy by some mechanism external to the KeyNote 1127 system itself (e.g., X.509 certificates converted to KeyNote 1128 assertions by a trusted conversion program). 1130 Implementations that permit signed credentials to be verified by the 1131 KeyNote compliance checker generally provide two `channels' through 1132 which applications can make assertions available. Unsigned, locally- 1133 trusted assertions are provided over a `trusted' interface, while 1134 signed credentials are provided over an `untrusted' interface. The 1135 KeyNote compliance checker verifies correct signatures for all 1136 assertions submitted over the untrusted interface. The integrity of 1137 KeyNote evaluation requires that only assertions trusted as 1138 reflecting local policy are submitted to KeyNote via the trusted 1139 interface. 1141 Note that applications that use KeyNote exclusively as a local policy 1142 specification mechanism need use only trusted assertions. Other 1143 applications might need only a small number of infrequently changed 1144 trusted assertions to `bootstrap' a policy whose details are 1145 specified in signed credentials issued by others and submitted over 1146 the untrusted interface. 1148 5.5 Implementation Issues 1150 Informally, the semantics of KeyNote evaluation can be thought of as 1151 involving the construction a directed graph of KeyNote assertions 1152 rooted at a POLICY assertion that connects with at least one of the 1153 principals that requested the action. 1155 Delegation of some authorization from principal to a set of 1156 principals is expressed as an assertion with principal given 1157 in the Authorizer field, principal set given in the Licensees 1158 field, and the authorization to be delegated encoded in the 1159 Conditions field. How the expression digraph is constructed is 1160 implementation-dependent and implementations may use different 1161 algorithms for optimizing the graph's construction. Some 1162 implementations might use a `bottom up' traversal starting at the 1163 principals that requested the action, others might follow a `top 1164 down' approach starting at the POLICY assertions, and still others 1165 might employ other heuristics entirely. 1167 Implementations are encouraged to employ mechanisms for recording 1168 exceptions (such as division by zero or syntax error), and reporting 1169 them to the invoking application if requested. Such mechanisms are 1170 outside the scope of this document. 1172 6. Examples 1174 In this section, we give examples of KeyNote assertions that might be 1175 used in hypothetical applications. These examples are intended 1176 primarily to illustrate features of KeyNote assertion syntax and 1177 semantics, and do not necessarily represent the best way to integrate 1178 KeyNote into applications. 1180 In the interest of readability, we use much shorter keys than would 1181 ordinarily be used in practice. Note that the Signature fields in 1182 these examples do not represent the result of any real signature 1183 calculation. 1185 1. TRADITIONAL CA / EMAIL 1187 A. A policy unconditionally authorizing RSA key abc123 for all 1188 actions. This essentially defers the ability to specify 1189 policy to the holder of the secret key corresponding to 1190 abc123: 1192 Authorizer: "POLICY" 1193 Licensees: "RSA:abc123" 1195 B. A credential assertion in which RSA Key abc123 trusts either 1196 RSA key 4401ff92 (called `Alice') or DSA key d1234f (called 1197 `Bob') to perform actions in which the "app_domain" is 1198 "RFC822-EMAIL", where the "address" matches the regular 1199 expression "^.*@keynote\.research\.att\.com$". In other 1200 words, abc123 trusts Alice and Bob as certification 1201 authorities for the keynote.research.att.com domain. 1203 KeyNote-Version: 2 1204 Local-Constants: Alice="DSA:4401ff92" # Alice's key 1205 Bob="RSA:d1234f" # Bob's key 1206 Authorizer: "RSA:abc123" 1207 Licensees: Alice || Bob 1208 Conditions: (app_domain == "RFC822-EMAIL") && 1209 (address ~= # only applies to one domain 1210 "^.*@keynote\\.research\\.att\\.com$"); 1211 Signature: "RSA-SHA1:213354f9" 1213 C. A certificate credential for a specific user whose email 1214 address is mab@keynote.research.att.com and whose name, if 1215 present, must be "M. Blaze". The credential was issued by the 1216 `Alice' authority (whose key is certified in Example B 1217 above): 1219 KeyNote-Version: 2 1220 Authorizer: "DSA:4401ff92" # the Alice CA 1221 Licensees: "DSA:12340987" # mab's key 1222 Conditions: ((app_domain == "RFC822-EMAIL") && 1223 (name == "M. Blaze" || name == "") && 1224 (address == "mab@keynote.research.att.com")); 1225 Signature: "DSA-SHA1:ab23487" 1227 D. Another certificate credential for a specific user, also 1228 issued by the `Alice' authority. This example allows three 1229 different keys to sign as jf@keynote.research.att.com (each 1230 for a different cryptographic algorithm). This is, in 1231 effect, three credentials in one: 1233 KeyNote-Version: "2" 1234 Authorizer: "DSA:4401ff92" # the Alice CA 1235 Licensees: "DSA:abc991" || # jf's DSA key 1236 "RSA:cde773" || # jf's RSA key 1237 "BFIK:fd091a" # jf's BFIK key 1238 Conditions: ((app_domain == "RFC822-EMAIL") && 1239 (name == "J. Feigenbaum" || name == "") && 1240 (address == "jf@keynote.research.att.com")); 1241 Signature: "DSA-SHA1:8912aa" 1243 Observe that under policy A and credentials B, C and D, the 1244 following action attribute sets are accepted (they return 1245 _MAX_TRUST): 1247 _ACTION_AUTHORIZERS = "dsa:12340987" 1248 app_domain = "RFC822-EMAIL" 1249 address = "mab@keynote.research.att.com" 1250 and 1251 _ACTION_AUTHORIZERS = "dsa:12340987" 1252 app_domain = "RFC822-EMAIL" 1253 address = "mab@keynote.research.att.com" 1254 name = "M. Blaze" 1256 while the following are not accepted (they return 1257 _MIN_TRUST): 1259 _ACTION_AUTHORIZERS = "dsa:12340987" 1260 app_domain = "RFC822-EMAIL" 1261 address = "angelos@dsl.cis.upenn.edu" 1262 and 1263 _ACTION_AUTHORIZERS = "dsa:abc991" 1264 app_domain = "RFC822-EMAIL" 1265 address = "mab@keynote.research.att.com" 1266 name = "M. Blaze" 1267 and 1268 _ACTION_AUTHORIZERS = "dsa:12340987" 1269 app_domain = "RFC822-EMAIL" 1270 address = "mab@keynote.research.att.com" 1271 name = "J. Feigenbaum" 1273 2. WORKFLOW/ELECTRONIC COMMERCE 1275 E. A policy that delegates authority for the "SPEND" application 1276 domain to RSA key dab212 when the amount given in the 1277 "dollars" attribute is less than 10000. 1279 Authorizer: "POLICY" 1280 Licensees: "RSA:dab212" # the CFO's key 1281 Conditions: (app_domain=="SPEND") && (@dollars < 10000); 1283 F. RSA key dab212 delegates authorization to any two signers, 1284 from a list, one of which must be DSA key feed1234 in the 1285 "SPEND" application when @dollars < 7500. If the amount in 1286 @dollars is 2500 or greater, the request is approved but 1287 logged. 1289 KeyNote-Version: 2 1290 Comment: This credential specifies a spending policy 1291 Authorizer: "RSA:dab212" # the CFO 1292 Licensees: "DSA:feed1234" && # The vice president 1293 ("RSA:abc123" || # middle manager #1 1294 "DSA:bcd987" || # middle manager #2 1295 "DSA:cde333" || # middle manager #3 1296 "DSA:def975" || # middle manager #4 1297 "DSA:978add") # middle manager #5 1298 Conditions: (app_domain=="SPEND") # note nested clauses 1299 -> { (@(dollars) < 2500) 1300 -> _MAX_TRUST; 1301 (@(dollars) < 7500) 1302 -> "ApproveAndLog"; 1303 }; 1304 Signature: "RSA-SHA1:9867a1" 1306 G. According to this policy, any two signers from the list of 1307 managers will do if @(dollars) < 1000: 1309 KeyNote-Version: 2 1310 Authorizer: "POLICY" 1311 Licensees: 2-of("DSA:feed1234", # The VP 1312 "RSA:abc123", # Middle management clones 1313 "DSA:bcd987", 1314 "DSA:cde333", 1315 "DSA:def975", 1316 "DSA:978add") 1317 Conditions: (app_domain=="SPEND") && 1318 (@(dollars) < 1000); 1320 H. A credential from dab212 with a similar policy, but only one 1321 signer is required if @(dollars) < 500. A log entry is made if 1322 the amount is at least 100. 1324 KeyNote-Version: 2 1325 Comment: This one credential is equivalent to six separate 1326 credentials, one for each VP and middle manager. 1327 Individually, they can spend up to $500, but if 1328 it's $100 or more, we log it. 1329 Authorizer: "RSA:dab212" # From the CFO 1330 Licensees: "DSA:feed1234" || # The VP 1331 "RSA:abc123" || # The middle management clones 1332 "DSA:bcd987" || 1333 "DSA:cde333" || 1334 "DSA:def975" || 1335 "DSA:978add" 1336 Conditions: (app_domain="SPEND") # nested clauses 1337 -> { (@(dollars) < 100) -> _MAX_TRUST; 1338 (@(dollars) < 500) -> "ApproveAndLog"; 1339 }; 1340 Signature: "RSA-SHA1:186123" 1342 Assume a query in which the ordered set of Compliance Values is 1343 {"Reject", "ApproveAndLog", "Approve"}. Under policies E and G, 1344 and credentials F and H, the Policy Compliance Value is 1345 "Approve" (_MAX_TRUST) when: 1347 _ACTION_AUTHORIZERS = "DSA:978add" 1348 app_domain = "SPEND" 1349 dollars = "45" 1350 unmentioned_attribute = "whatever" 1351 and 1352 _ACTION_AUTHORIZERS = "RSA:abc123,DSA:cde333" 1353 app_domain = "SPEND" 1354 dollars = "550" 1356 The following return "ApproveAndLog": 1358 _ACTION_AUTHORIZERS = "DSA:feed1234,DSA:cde333" 1359 app_domain = "SPEND" 1360 dollars = "5500" 1361 and 1362 _ACTION_AUTHORIZERS = "DSA:cde333" 1363 app_domain = "SPEND" 1364 dollars = "150" 1366 However, the following return "Reject" (_MIN_TRUST): 1368 _ACTION_AUTHORIZERS = "DSA:def975" 1369 app_domain = "SPEND" 1370 dollars = "550" 1371 and 1372 _ACTION_AUTHORIZERS = "DSA:cde333,DSA:978add" 1373 app_domain = "SPEND" 1374 dollars = "5500" 1376 7. Trust-Management Architecture 1378 KeyNote provides a simple mechanism for describing security policy 1379 and representing credentials. It differs from traditional 1380 certification systems in that the security model is based on binding 1381 keys to predicates that describe what the key is authorized by policy 1382 to do, rather than on resolving names. The infrastructure and 1383 architecture to support a KeyNote system is therefore rather 1384 different from that required for a name-based certification scheme. 1385 The KeyNote trust-management architecture is based on that of 1386 PolicyMaker [BFL96,BFS98]. 1388 It is important to understand the separation between the 1389 responsibilities of the KeyNote system and those of the application 1390 and other support infrastructure. A KeyNote compliance checker will 1391 determine, based on policy and credential assertions, whether a 1392 proposed action is permitted according to policy. The usefulness of 1393 KeyNote output as a policy enforcement mechanism depends on a number 1394 of factors: 1396 * The action attributes and the assignment of their values must 1397 reflect accurately the security requirements of the application. 1398 Identifying the attributes to include in the action attribute set 1399 is perhaps the most important task in integrating KeyNote into 1400 new applications. 1402 * The policy of the application must be correct and well-formed. 1403 In particular, trust must be deferred only to principals that 1404 should, in fact, be trusted by the application. 1406 * The application itself must be trustworthy. KeyNote does not 1407 directly enforce policy; it only provides advice to the 1408 applications that call it. In other words, KeyNote assumes that 1409 the application itself is trusted and that the policy assertions 1410 it specifies are correct. Nothing prevents an application from 1411 submitting misleading or incorrect assertions to KeyNote or from 1412 ignoring KeyNote altogether. 1414 It is also up to the application (or some service outside KeyNote) to 1415 select the appropriate credentials and policy assertions with which 1416 to run a particular query. Note, however, that even if inappropriate 1417 credentials are provided to KeyNote, this cannot result in the 1418 approval of an illegal action (as long as the policy assertions are 1419 correct and the the action attribute set itself is correctly passed 1420 to KeyNote). 1422 KeyNote is monotonic; adding an assertion to a query can never result 1423 in a query's having a lower compliance value that it would have had 1424 without the assertion. Omitting credentials may, of course, result 1425 in legal actions being disallowed. Selecting appropriate credentials 1426 (e.g., from a distributed database or `key server') is outside the 1427 scope of the KeyNote language and may properly be handled by a remote 1428 client making a request, by the local application receiving the 1429 request, or by a network-based service, depending on the application. 1431 In addition, KeyNote does not itself provide credential revocation 1432 services, although credentials can be written to expire after some 1433 date by including a date test in the predicate. Applications that 1434 require credential revocation can use KeyNote to help specify and 1435 implement revocation policies. A future document will address 1436 expiration and revocation services in KeyNote. 1438 Because KeyNote is designed to support a variety of applications, 1439 several different application interfaces to a KeyNote implementation 1440 are possible. In its simplest form, a KeyNote compliance checker 1441 would exist as a stand-alone application, with other applications 1442 calling it as needed. KeyNote might also be implemented as a library 1443 to which applications are linked. Finally, a KeyNote implementation 1444 might run as a local trusted service, with local applications 1445 communicating their queries via some interprocess communication 1446 mechanism. 1448 8. Security Considerations 1450 Trust management is itself a security service. Bugs in or incorrect 1451 use of a KeyNote compliance checker implementation could have 1452 security implications for any applications in which it is used. 1454 9. IANA Considerations 1456 This document contains three identifiers to be maintained by the 1457 IANA. This section explains the criteria to be used by the IANA to 1458 assign additional identifiers in each of these lists. 1460 9.1 app_domain Identifiers 1462 The only requirement on IANA on allocation of these identifiers is 1463 that they be unique strings. These strings are case-sensitive for 1464 KeyNote purposes, however it is strongly recommended that IANA 1465 assigns different capitalizations of the same string only to the same 1466 organization. 1468 9.2 Public Key Format Identifiers 1470 These strings uniquely identify a public key algorithm as used in the 1471 KeyNote system for representing keys. Requests for assignment of new 1472 identifiers must be accompanied by an RFC-style document which 1473 describes the details of this encoding. Example strings are "rsa- 1474 hex:" and "dsa-base64:". These strings are case-insensitive. 1476 9.3 Signature Algorithm Identifiers 1478 These strings uniquely identify a public key algorithm as used in the 1479 KeyNote system for representing public key signatures. Requests for 1480 assignment of new identifiers must be accompanied by an RFC-style 1481 document which describes the details of this encoding. Example 1482 strings are "sig-rsa-md5-hex:" and "sig-dsa-sha1-base64:". Note that 1483 all such strings must begin with the prefix "sig-". These strings 1484 are case-insensitive. 1486 A. Acknowledgments 1487 We thank Lorrie Faith Cranor (AT&T Labs - Research) and Jonathan M. 1488 Smith (University of Pennsylvania) for their suggestions and comments 1489 on earlier versions of this. 1491 B. Full BNF (alphabetical order) 1493 :: {see section 4.4.2} ; 1495 :: ? ? 1496 ? ? 1497 ? ? ; 1499 :: "" | "=" 1500 ; 1502 :: {Any string starting with a-z, A-Z, or the 1503 underscore character, followed by any number of 1504 a-z, A-Z, 0-9, or underscore characters} ; 1506 :: "Authorizer:" ; 1508 :: | ; 1510 :: "->" "{" "}" 1511 | "->" | ; 1513 :: "#" {ASCII characters} ; 1515 :: "Comment:" {Free-form text} ; 1517 :: "Conditions:" ; 1519 :: "" | ";" ; 1521 :: ; 1523 :: {see section 4.4.2} ; 1525 :: "+" | "-" 1526 | "*" | "/" 1527 | "^" | "-" 1528 | "(" ")" | | "&" ; 1530 :: "<" | ">" 1531 | "<=" 1532 | ">=" ; 1534 :: "." ; 1536 :: ":" ; 1538 :: {Decimal number of at least one digit} ; 1540 :: "+" | "-" 1541 | "*" | "/" 1542 | "%" | "^" 1543 | "-" | "(" ")" | 1544 | "@" ; 1546 :: "==" | "!=" 1547 | "<" | ">" 1548 | "<=" | ">=" ; 1550 :: {Decimal number starting with a digit from 1 to 9} ; 1552 :: ; 1554 :: "" | ; 1556 :: "Licensees:" ; 1558 :: "Local-Constants:" ; 1560 :: ; 1562 :: "(" ")" | "&&" 1563 | "||" 1564 | "-of(" ")" | 1565 | ; 1567 :: | ; 1569 :: | 1570 | "," ; 1572 :: {POSIX 1003.2 Regular Expression} 1574 :: "(" ")" | "&&" 1575 | "||" | "!" 1576 | | | 1577 | "true" | "false" ; 1579 :: ; 1581 :: "Signature:" ; 1582 :: "." | | "(" ")" 1583 | | "$" ; 1585 :: {see section 4.3.1} ; 1587 :: "==" | "!=" 1588 | "<" | ">" 1589 | "<=" | ">=" 1590 | "~=" ; 1592 :: ; 1594 :: ; 1596 :: "KeyNote-Version:" ; 1598 :: | ; 1600 References 1602 [BFL96] M. Blaze, J. Feigenbaum, J. Lacy. Decentralized Trust 1603 Management. Proceedings of the 17th IEEE Symp. on Security 1604 and Privacy. pp 164-173. IEEE Computer Society, 1605 1996. Available at 1606 1608 [BFS98] M. Blaze, J. Feigenbaum, M. Strauss. Compliance-Checking in 1609 the PolicyMaker Trust-Management System. Proc. 2nd 1610 Financial Crypto Conference. Anguila 1998. LNCS #1465, pp 1611 251-265, Springer-Verlag, 1998. Available at 1612 1614 [Bla99] M. Blaze, J. Feigenbaum, J. Ioannidis, A. Keromytis. The 1615 Role of Trust Management in Distributed System Security. 1616 Chapter in Secure Internet Programming: Security Issues for 1617 Mobile and Distributed Objects (Vitek and Jensen, eds.). 1618 Springer-Verlag, 1999. Available at 1619 . 1621 [Cro82] D. H. Crocker. Standard for the Format of ARPA Internet 1622 Text Messages. RFC 822. August 1982. 1624 [DSA94] Digital Signature Standard. FIPS-186. National Institute of 1625 Standards, U.S. Department of Commerce. May 1994. 1627 [PKCS1] PKCS #1: RSA Encryption Standard, Version 1.5. RSA 1628 Laboratories. November 1993. 1630 [RSA78] R. L. Rivest, A. Shamir, L. M. Adleman. A Method for 1631 Obtaining Digital Signatures and Public-Key Cryptosystems. 1632 Communications of the ACM, v21n2. pp 120-126. February 1633 1978. 1635 Contacts 1637 Comments about this document should be discussed on the 1638 trustmgt@east.isi.edu mailing list. The archive for that list can be 1639 found at http://www.cairn.net/trustmgt/. 1641 Questions about this document can also be directed to the authors as 1642 a group at the keynote@research.att.com alias, or to the individual 1643 authors at: 1645 Matt Blaze Joan Feigenbaum John Ioannidis 1646 mab@research.att.com jf@research.att.com ji@research.att.com 1648 AT&T Labs - Research 1649 180 Park Avenue 1650 Florham Park, New Jersey 07932-0000 1652 Angelos D. Keromytis 1653 Distributed Systems Lab 1654 CIS Department, University of Pennsylvania 1655 200 S. 33rd Street 1656 Philadelphia, Pennsylvania 19104-6389 1657 Email: angelos@dsl.cis.upenn.edu 1659 Full Copyright Statement 1661 Copyright (C) The Internet Society (1999). All Rights Reserved. 1663 This document and translations of it may be copied and furnished to 1664 others, and derivative works that comment on or otherwise explain it 1665 or assist in its implementation may be prepared, copied, published 1666 and distributed, in whole or in part, without restriction of any 1667 kind, provided that the above copyright notice and this paragraph are 1668 included on all such copies and derivative works. However, this 1669 document itself may not be modified in any way, such as by removing 1670 the copyright notice or references to the Internet Society or other 1671 Internet organizations, except as needed for the purpose of 1672 developing Internet standards in which case the procedures for 1673 copyrights defined in the Internet Standards process must be 1674 followed, or as required to translate it into languages other than 1675 English. 1677 The limited permissions granted above are perpetual and will not be 1678 revoked by the Internet Society or its successors or assigns. 1680 This document and the information contained herein is provided on an 1681 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1682 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1683 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1684 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1685 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.