1.\" $OpenBSD: keynote.4,v 1.17 2000/09/17 02:11:12 aaron Exp $ 2.\" 3.\" The author of this code is Angelos D. Keromytis (angelos@dsl.cis.upenn.edu) 4.\" 5.\" This code was written by Angelos D. Keromytis in Philadelphia, PA, USA, 6.\" in April-May 1998 7.\" 8.\" Copyright (C) 1998, 1999 by Angelos D. Keromytis. 9.\" 10.\" Permission to use, copy, and modify this software without fee 11.\" is hereby granted, provided that this entire notice is included in 12.\" all copies of any software which is or includes a copy or 13.\" modification of this software. 14.\" You may use this code under the GNU public license if you so wish. Please 15.\" contribute changes back to the author. 16.\" 17.\" THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR 18.\" IMPLIED WARRANTY. IN PARTICULAR, THE AUTHORS MAKES NO 19.\" REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE 20.\" MERCHANTABILITY OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR 21.\" PURPOSE. 22.\" 23.Dd May 22, 1999 24.Dt KEYNOTE 4 25.\" .TH KeyNote 4 local 26.Os 27.Sh NAME 28.Nm keynote 29.Nd a trust-management system 30.Sh SYNOPSIS 31.Fd #include <sys/types.h> 32.Fd #include <regex.h> 33.Fd #include <keynote.h> 34.Fd Link options: -lkeynote -lm -lcrypto 35.Sh DESCRIPTION 36For more details on 37.Nm KeyNote , 38see RFC 2704. 39.Pp 40Details on the API, assertion syntax, and command-line tool are given in 41the man pages listed at the end of this manual. 42.Pp 43Trust management, introduced in the PolicyMaker system, is a unified 44approach to specifying and interpreting security policies, 45credentials, and relationships; it allows direct authorization of 46security-critical actions. A trust-management system provides 47standard, general-purpose mechanisms for specifying application 48security policies and credentials. Trust-management credentials 49describe a specific delegation of trust and subsume the role of public 50key certificates; unlike traditional certificates, which bind keys to 51names, credentials can bind keys directly to the authorization to 52perform specific tasks. 53.Pp 54A trust-management system has five basic components: 55 56.nf 57* A language for describing `actions,' which are operations with 58 security consequences that are to be controlled by the system. 59 60* A mechanism for identifying `principals,' which are entities that 61 can be authorized to perform actions. 62 63* A language for specifying application `policies,' which govern the 64 actions that principals are authorized to perform. 65 66* A language for specifying `credentials,' which allow principals 67 to delegate authorization to other principals. 68 69* A `compliance checker,' which provides a service to applications 70 for determining how an action requested by principals should be 71 handled, given a policy and a set of credentials. 72.fi 73 74The trust-management approach has a number of advantages over other 75mechanisms for specifying and controlling authorization, especially 76when security policy is distributed over a network or is otherwise 77decentralized. 78.Pp 79Trust management unifies the notions of security policy, credentials, 80access control, and authorization. An application that uses a 81trust-management system can simply ask the compliance checker whether 82a requested action should be allowed. Furthermore, policies and 83credentials are written in standard languages that are shared by all 84trust-managed applications; the security configuration mechanism for 85one application carries exactly the same syntactic and semantic 86structure as that of another, even when the semantics of the 87applications themselves are quite different. 88.Pp 89Trust-management policies are easy to distribute across networks, 90helping to avoid the need for application-specific distributed policy 91configuration mechanisms, access control lists, and certificate 92parsers and interpreters. 93.Pp 94For a general discussion of the use of trust management in distributed 95system security, see the papers listed at the end of this manual. 96.Pp 97KeyNote is a simple and flexible trust-management system designed to 98work well for a variety of large- and small- scale Internet-based 99applications. It provides a single, unified language for both local 100policies and credentials. KeyNote policies and credentials, called 101`assertions,' contain predicates that describe the trusted actions 102permitted by the holders of specific public keys. KeyNote assertions 103are essentially small, highly-structured programs. A signed assertion, 104which can be sent over an untrusted network, is also called a 105`credential assertion.' Credential assertions, which also serve the 106role of certificates, have the same syntax as policy assertions but 107are also signed by the principal delegating the trust. 108.Pp 109In KeyNote: 110 111.nf 112* Actions are specified as a collection of name-value pairs. 113 114* Principal names can be any convenient string and can directly 115 represent cryptographic public keys. 116 117* The same language is used for both policies and credentials. 118 119* The policy and credential language is concise, highly expressive, 120 human readable and writable, and compatible with a variety of 121 storage and transmission media, including electronic mail. 122 123* The compliance checker returns an application-configured `policy 124 compliance value' that describes how a request should be handled 125 by the application. Policy compliance values are always 126 positively derived from policy and credentials, facilitating 127 analysis of KeyNote-based systems. 128 129* Compliance checking is efficient enough for high-performance and 130 real-time applications. 131.fi 132 133In KeyNote, the authority to perform trusted actions is associated 134with one or more `principals.' A principal may be a physical entity, a 135process in an operating system, a public key, or any other convenient 136abstraction. KeyNote principals are identified by a string called a 137`Principal Identifier.' In some cases, a Principal Identifier will 138contain a cryptographic key interpreted by the KeyNote system (e.g., 139for credential signature verification). In other cases, Principal 140Identifiers may have a structure that is opaque to KeyNote. 141.Pp 142Principals perform two functions of concern to KeyNote: They request 143`actions' and they issue `assertions.' Actions are any trusted 144operations that an application places under KeyNote control. 145Assertions delegate the authorization to perform actions to other 146principals. 147.Pp 148Actions are described to the KeyNote compliance checker in terms of a 149collection of name-value pairs called an `action attribute set.' The 150action attribute set is created by the invoking application. Its 151structure and format are described in detail elsewhere of this 152document. 153.Pp 154KeyNote provides advice to applications on the interpretation of 155policy with regard to specific requested actions. Applications invoke 156the KeyNote compliance checker by issuing a `query' containing a 157proposed action attribute set and identifying the principal(s) 158requesting it. The KeyNote system determines and returns an 159appropriate `policy compliance value' from an ordered set of possible 160responses. 161.Pp 162The policy compliance value returned from a KeyNote query advises the 163application how to process the requested action. In the simplest case, 164the compliance value is Boolean (e.g., "reject" or "approve"). 165Assertions can also be written to select from a range of possible 166compliance values, when appropriate for the application (e.g., "no 167access", "restricted access", "full access"). Applications can 168configure the relative ordering (from `weakest' to `strongest') of 169compliance values at query time. 170.Pp 171Assertions are the basic programming unit for specifying policy and 172delegating authority. Assertions describe the conditions under which a 173principal authorizes actions requested by other principals. An 174assertion identifies the principal that made it, which other 175principals are being authorized, and the conditions under which the 176authorization applies. The syntax of assertions is given 177.Xr keynote 5 . 178.Pp 179A special principal, whose identifier is "POLICY", provides the root 180of trust in KeyNote. "POLICY" is therefore considered to be authorized 181to perform any action. 182.Pp 183Assertions issued by the "POLICY" principal are called `policy 184assertions' and are used to delegate authority to otherwise untrusted 185principals. The KeyNote security policy of an application consists of 186a collection of policy assertions. 187.Pp 188When a principal is identified by a public key, it can digitally sign 189assertions and distribute them over untrusted networks for use by 190other KeyNote compliance checkers. These signed assertions are also 191called `credentials,' and serve a role similar to that of traditional 192public key certificates. Policies and credentials share the same 193syntax and are evaluated according to the same semantics. A principal 194can therefore convert its policy assertions into credentials simply by 195digitally signing them. 196.Pp 197KeyNote is designed to encourage the creation of human-readable 198policies and credentials that are amenable to transmission and storage 199over a variety of media. Its assertion syntax is inspired by the 200format of RFC822-style message headers. A KeyNote assertion contains a 201sequence of sections, called `fields,' each of which specifying one 202aspect of the assertion's semantics. Fields start with an identifier 203at the beginning of a line and continue until the next field is 204encountered. For example: 205 206.nf 207 KeyNote-Version: 2 208 Comment: A simple, if contrived, email certificate for user mab 209 Local-Constants: ATT_CA_key = "RSA:acdfa1df1011bbac" 210 mab_key = "DSA:deadbeefcafe001a" 211 Authorizer: ATT_CA_key 212 Licensees: mab_key 213 Conditions: ((app_domain == "email") # valid for email only 214 && (address == "mab@research.att.com")); 215 Signature: "RSA-SHA1:f00f2244" 216.fi 217 218For the exact meanings of all the fields, see the RFC reference at the 219end of this manual, and/or 220.Xr keynote 5 . 221.Pp 222KeyNote semantics resolve the relationship between an application's 223policy and actions requested by other principals, as supported by 224credentials. The KeyNote compliance checker processes the assertions 225against the action attribute set to determine the policy compliance 226value of a requested action. These semantics are defined later in this 227document. 228.Pp 229An important principle in KeyNote's design is `assertion 230monotonicity'; the policy compliance value of an action is always 231positively derived from assertions made by trusted principals. 232Removing an assertion never results in increasing the compliance value 233returned by KeyNote for a given query. The monotonicity property can 234simplify the design and analysis of complex network-based security 235protocols; network failures that prevent the transmission of 236credentials can never result in spurious authorization of dangerous 237actions. 238.Pp 239Trusted actions to be evaluated by KeyNote are described by a 240collection of name-value pairs called the `action attribute set'. 241Action attributes are the mechanism by which applications communicate 242requests to KeyNote and are the primary objects on which KeyNote 243assertions operate. An action attribute set is passed to the KeyNote 244compliance checker with each query. 245.Pp 246Each action attribute consists of a name and a value. The semantics of 247the names and values are not interpreted by KeyNote itself; they vary 248from application to application and must be agreed upon by the writers 249of applications and the writers of the policies and credentials that 250will be used by them. 251.Pp 252Action attribute names and values are represented by arbitrary-length 253strings. KeyNote guarantees support of attribute names and values up 254to 2048 characters long. Applications and assertions should therefore 255avoid depending on the use of attributes with names or values 256longer than 2048 characters. 257.Pp 258Attribute values are inherently untyped and are represented as 259character strings by default. Attribute values may contain any non- 260NUL ASCII character. Numeric attribute values should first be 261converted to an ASCII text representation by the invoking application, 262e.g., the value 1234.5 would be represented by the string "1234.5". 263.Pp 264An <AttributeID> begins with an alphabetic or underscore character and 265can be followed by any number of alphanumerics and underscores. 266Attribute names are case-sensitive. 267.Pp 268If an action attribute is not defined its value is considered to be 269the empty string. 270.Pp 271Attribute names beginning with the "_" character are reserved for use 272by the KeyNote runtime environment and cannot be passed from 273applications as part of queries. The following special attribute names 274are used: 275 276.Bl -tag -width indent 277.It _MIN_TRUST 278Lowest-order (minimum) compliance value in query. 279.It _MAX_TRUST 280Highest-order (maximum) compliance value in query. 281.It _VALUES 282Linearly ordered set of compliance value in query. 283.It _ACTION_AUTHORIZERS 284Names of principals directly authorizing action in query. Comma 285separated. 286.El 287.Pp 288In addition, attributes with names of the form "_<N>", where <N> is an 289ASCII-encoded integer, are used by the regular expression matching 290mechanism described in 291.Xr keynote 5 . 292.Pp 293By convention, the name of the application domain over which action 294attributes should be interpreted is given in the attribute named 295"app_domain". The IANA (or some other suitable authority) will provide 296a registry of reserved app_domain names. The registry will list the 297names and meanings of each application's attributes. 298.Pp 299The app_domain convention helps to ensure that credentials are 300interpreted as they were intended. An attribute with any given name 301may be used in many different application domains but might have 302different meanings in each of them. However, the use of a global 303registry is not always required for small-scale, closed applications; 304the only requirement is that the policies and credentials made 305available to the KeyNote compliance checker interpret attributes 306according to the same semantics assumed by the application that 307created them. 308.Pp 309For example, an email application might reserve the app_domain 310"RFC822-EMAIL" and might use the attributes named "address" (the mail 311address of a message's sender), "name" (the human name of the message 312sender), and any "organization" headers present (the organization 313name). The values of these attributes would be derived in the obvious 314way from the email message headers. The public key of the message's 315signer would be given in the "_ACTION_AUTHORIZERS" attribute. 316.Pp 317.Sh QUERY SEMANTICS 318The discussion in the following sections assume some familiarity with 319assertion syntax. Please refer to 320.Xr keynote 5 321for more details on the syntax. 322.Pp 323.Sh QUERY PARAMETERS 324A KeyNote query has four parameters: 325 326.nf 327* The identifier of the principal(s) requesting the action. 328 329* The action attribute set describing the action. 330 331* The set of compliance values of interest to the application, 332 ordered from _MIN_TRUST to _MAX_TRUST 333 334* The policy and credential assertions that should be included in 335 the evaluation. 336.fi 337 338The mechanism for passing these parameters to the KeyNote evaluator is 339application dependent. In particular, an evaluator might provide for 340some parameters to be passed explicitly, while others are looked up 341externally (e.g., credentials might be looked up in a network- based 342distribution system), while still others might be requested from the 343application as needed by the evaluator, through a `callback' mechanism 344(e.g., for attribute values that represent values from among a very 345large namespace). 346.Pp 347.Sh ACTION REQUESTER 348At least one Principal must be identified in each query as the 349`requester' of the action. Actions may be requested by several 350principals, each considered to have individually requested it. This 351allows policies that require multiple authorizations, e.g., `two 352person control'. The set of authorizing principals is made available 353in the special attribute "_ACTION_AUTHORIZERS"; if several principals 354are authorizers, their identifiers are separated with commas. 355.Pp 356.Sh ORDERED COMPLIANCE VALUE SET 357The set of compliance values of interest to an application (and their 358relative ranking to one another) is determined by the invoking 359application and passed to the KeyNote evaluator as a parameter of the 360query. In many applications, this will be Boolean, e.g., the ordered 361sets {FALSE, TRUE} or {REJECT, APPROVE}. Other applications may 362require a range of possible values, e.g., {No_Access, Limited_Access, 363Full_Access}. Note that applications should include in this set only 364compliance value names that are actually returned by the assertions. 365.Pp 366The lowest-order and highest-order compliance value strings given in 367the query are available in the special attributes named "_MIN_TRUST" 368and "_MAX_TRUST", respectively. The complete set of query compliance 369values is made available in ascending order (from _MIN_TRUST to 370_MAX_TRUST) in the special attribute named "_VALUES". Values are 371separated with commas; applications that use assertions that make use 372of the _VALUES attribute should therefore avoid the use of compliance 373value strings that themselves contain commas. 374.Pp 375.Sh PRINCIPAL IDENTIFIER NORMALIZATION 376Principal identifier comparisons among Cryptographic Principal 377Identifiers (that represent keys) in the Authorizer and Licensees 378fields or in an action's direct authorizers are performed after 379normalizing them by conversion to a canonical form. 380.Pp 381Every cryptographic algorithm used in KeyNote defines a method for 382converting keys to their canonical form and that specifies how the 383comparison for equality of two keys is performed. If the algorithm 384named in the identifier is unknown to KeyNote, the identifier is 385treated as opaque. 386.Pp 387Opaque identifiers are compared as case-sensitive strings. 388.Pp 389Notice that use of opaque identifiers in the Authorizer field requires 390that the assertion's integrity be locally trusted (since it cannot be 391cryptographically verified by the compliance checker). 392.Pp 393 394.Sh POLICY COMPLIANCE VALUE CALCULATION 395The Policy Compliance Value of a query is the Principal Compliance 396Value of the principal named "POLICY". 397.Pp 398.Sh PRINCIPAL COMPLIANCE VALUE 399The Compliance Value of a principal <X> is the highest order (maximum) 400of: 401 402.nf 403- the Direct Authorization Value of principal <X>; and 404 405- the Assertion Compliance Values of all assertions identifying 406 <X> in the Authorizer field. 407.fi 408.Sh DIRECT AUTHORIZATION VALUE 409The Direct Authorization Value of a principal <X> is _MAX_TRUST if <X> 410is listed in the query as an authorizer of the action. Otherwise, the 411Direct Authorization Value of <X> is _MIN_TRUST. 412.Pp 413.Sh ASSERTION COMPLIANC VALUE 414The Assertion Compliance Value of an assertion is the lowest order 415(minimum) of the assertion's Conditions Compliance Value and its 416Licensee Compliance Value. 417.Pp 418.Sh CONDITIONS COMPLIANCE VALUE 419The Conditions Compliance Value of an assertion is the highest-order 420(maximum) value among all successful clauses listed in the conditions 421section. 422.Pp 423If no clause's test succeeds or the Conditions field is empty, an 424assertion's Conditions Compliance Value is considered to be the 425_MIN_TRUST value, as described previously. 426.Pp 427If an assertion's Conditions field is missing entirely, its Conditions 428Compliance Value is considered to be the _MAX_TRUST value, as defined 429previously. 430.Pp 431The set of successful test clause values is calculated as follows: 432.Pp 433Recall from the grammar of the Conditions field (see 434.Xr keynote 5 435for more details) that each clause in the conditions section has two 436logical parts: a `test' and an optional `value', which, if present, is 437separated from the test with the "->" token. The test subclause is a 438predicate that either succeeds (evaluates to logical `true') or fails 439(evaluates to logical `false'). The value subclause is a string 440expression that evaluates to one value from the ordered set of 441compliance values given with the query. If the value subclause is 442missing, it is considered to be _MAX_TRUST. That is, the clause 443.Bd -literal 444 foo=="bar"; 445.Ed 446 447is equivalent to 448.Bd literal 449 foo=="bar" -> _MAX_TRUST; 450.Ed 451 452If the value component of a clause is present, in the simplest case it 453contains a string expression representing a possible compliance value. 454For example, consider an assertion with the following Conditions 455field: 456.Bd -literal 457 Conditions: 458 @user_id == 0 -> "full_access"; # clause (1) 459 @user_id < 1000 -> "user_access"; # clause (2) 460 @user_id < 10000 -> "guest_access"; # clause (3) 461 user_name == "root" -> "full_access"; # clause (4) 462.Ed 463 464Here, if the value of the "user_id" attribute is "1073" and the 465"user_name" attribute is "root", the possible compliance value set 466would contain the values "guest_access" (by clause (3)) and 467"full_access" (by clause (4)). If the ordered set of compliance values 468given in the query (in ascending order) is {"no_access", 469"guest_access", "user_access", "full_access"}, the Conditions 470Compliance Value of the assertion would be "full_access" (because 471"full_access" has a higher-order value than "guest_access"). If the 472"user_id" attribute had the value "19283" and the "user_name" 473attribute had the value "nobody", no clause would succeed and the 474Conditions Compliance Value would be "no_access", which is the 475lowest-order possible value (_MIN_TRUST). 476.Pp 477If a clause lists an explicit value, its value string must be named in 478the query ordered compliance value set. Values not named in the query 479compliance value set are considered equivalent to _MIN_TRUST. 480.Pp 481The value component of a clause can also contain recursively-nested 482clauses. Recursively-nested clauses are evaluated only if their parent 483test is true. That is, 484.Bd -literal 485 a=="b" -> { b=="c" -> "value1"; 486 d=="e" -> "value2"; 487 true -> "value3"; } ; 488.Ed 489 490is equivalent to 491.Bd -literal 492 (a=="b") && (b=="c") -> "value1"; 493 (a=="b") && (d=="e") -> "value2"; 494 (a=="b") -> "value3"; 495.Ed 496 497Notice that string comparisons are case-sensitive. 498.Pp 499A regular expression comparison ("~=") is considered true if the 500left-hand-side string expression matches the right-hand-side regular 501expression. If the POSIX regular expression group matching scheme is 502used, the number of groups matched is placed in the temporary meta- 503attribute "_0" (dereferenced as _0), and each match is placed in 504sequence in the temporary attributes (_1, _2, ..., _N). These 505match-attributes' values are valid only within subsequent references 506made within the same clause. Regular expression evaluation is case- 507sensitive. 508.Pp 509A runtime error occurring in the evaluation of a test, such as 510division by zero or an invalid regular expression, causes the test to 511be considered false. For example: 512.Bd -literal 513 foo == "bar" -> { 514 @a == 1/0 -> "oneval"; # subclause 1 515 @a == 2 -> "anotherval"; # subclause 2 516 }; 517.Ed 518 519Here, subclause 1 triggers a runtime error. Subclause 1 is therefore 520false (and has the value _MIN_TRUST). Subclause 2, however, would be 521evaluated normally. 522.Pp 523An invalid <RegExpr> is considered a runtime error and causes the test 524in which it occurs to be considered false. 525.Pp 526.Sh LICENSEE COMPLIANCE VALUE 527The Licensee Compliance Value of an assertion is calculated by 528evaluating the expression in the Licensees field, based on the 529Principal Compliance Value of the principals named there. 530.Pp 531If an assertion's Licensees field is empty, its Licensee Compliance 532Value is considered to be _MIN_TRUST. If an assertion's Licensees 533field is missing altogether, its Licensee Compliance Value is 534considered to be _MAX_TRUST. 535.Pp 536For each principal named in the Licensees field, its Principal 537Compliance Value is substituted for its name. If no Principal 538Compliance Value can be found for some named principal, its name is 539substituted with the _MIN_TRUST value. 540.Pp 541The licensees expression (see 542.Xr keynote 5 ) 543is evaluated as follows: 544 545.nf 546* A "(...)" expression has the value of the enclosed subexpression. 547 548* A "&&" expression has the lower-order (minimum) of its two 549 subexpression values. 550 551* A "||" expression has the higher-order (maximum) of its two 552 subexpression values. 553 554* A "<K>-of(<List>)" expression has the K-th highest order 555 compliance value listed in <list>. Values that appear multiple 556 times are counted with multiplicity. For example, if K = 3 and 557 the orders of the listed compliance values are (0, 1, 2, 2, 3), 558 the value of the expression is the compliance value of order 2. 559.fi 560 561For example, consider the following Licensees field: 562.Bd -literal 563 Licensees: ("alice" && "bob") || "eve" 564.Ed 565 566If the Principal Compliance Value is "yes" for principal "alice", "no" 567for principal "bob", and "no" for principal "eve", and "yes" is higher 568order than "no" in the query's Compliance Value Set, then the 569resulting Licensee Compliance Value is "no". 570.Pp 571Observe that if there are exactly two possible compliance values 572(e.g., "false" and "true"), the rules of Licensee Compliance Value 573resolution reduce exactly to standard Boolean logic. 574.Pp 575.Sh ASSERTION MANAGEMENT 576Assertions may be either signed or unsigned. Only signed assertions 577should be used as credentials or transmitted or stored on untrusted 578media. Unsigned assertions should be used only to specify policy and 579for assertions whose integrity has already been verified as conforming 580to local policy by some mechanism external to the KeyNote system 581itself (e.g., X.509 certificates converted to KeyNote assertions by a 582trusted conversion program). 583.Pp 584Implementations that permit signed credentials to be verified by the 585KeyNote compliance checker generally provide two `channels' through 586which applications can make assertions available. Unsigned, 587locally-trusted assertions are provided over a `trusted' interface, 588while signed credentials are provided over an `untrusted' interface. 589The KeyNote compliance checker verifies correct signatures for all 590assertions submitted over the untrusted interface. The integrity of 591KeyNote evaluation requires that only assertions trusted as reflecting 592local policy are submitted to KeyNote via the trusted interface. 593.Pp 594Note that applications that use KeyNote exclusively as a local policy 595specification mechanism need use only trusted assertions. Other 596applications might need only a small number of infrequently changed 597trusted assertions to `bootstrap' a policy whose details are specified 598in signed credentials issued by others and submitted over the 599untrusted interface. 600.Pp 601.Sh EXAMPLES 602A policy that delegates authority for the "SPEND" application domain 603to RSA key dab212 when the amount given in the "dollars" attribute is 604less than 10000. 605.Bd -literal 606 Authorizer: "POLICY" 607 Licensees: "RSA:dab212" # the CFO's key 608 Conditions: (app_domain=="SPEND") && (@dollars < 10000); 609.Ed 610 611RSA key dab212 delegates authorization to any two signers, from a 612list, one of which must be DSA key feed1234 in the "SPEND" application 613when @dollars < 7500. If the amount in @dollars is 2500 or greater, 614the request is approved but logged. 615.Bd -literal 616 KeyNote-Version: 2 617 Comment: This credential specifies a spending policy 618 Authorizer: "RSA:dab212" # the CFO 619 Licensees: "DSA:feed1234" && # The vice president 620 ("RSA:abc123" || # middle manager #1 621 "DSA:bcd987" || # middle manager #2 622 "DSA:cde333" || # middle manager #3 623 "DSA:def975" || # middle manager #4 624 "DSA:978add") # middle manager #5 625 Conditions: (app_domain=="SPEND") # note nested clauses 626 -> { (@(dollars) < 2500) 627 -> _MAX_TRUST; 628 (@(dollars) < 7500) 629 -> "ApproveAndLog"; 630 }; 631 Signature: "RSA-SHA1:9867a1" 632.Ed 633 634According to this policy, any two signers from the list of managers 635will do if @(dollars) < 1000: 636.Bd -literal 637 KeyNote-Version: 2 638 Authorizer: "POLICY" 639 Licensees: 2-of("DSA:feed1234", # The VP 640 "RSA:abc123", # Middle management clones 641 "DSA:bcd987", 642 "DSA:cde333", 643 "DSA:def975", 644 "DSA:978add") 645 Conditions: (app_domain=="SPEND") && 646 (@(dollars) < 1000); 647.Ed 648 649A credential from dab212 with a similar policy, but only one signer is 650required if @(dollars) < 500. A log entry is made if the amount is at 651least 100. 652.Bd -literal 653 KeyNote-Version: 2 654 Comment: This one credential is equivalent to six separate 655 credentials, one for each VP and middle manager. 656 Individually, they can spend up to $500, but if 657 it's $100 or more, we log it. 658 Authorizer: "RSA:dab212" # From the CFO 659 Licensees: "DSA:feed1234" || # The VP 660 "RSA:abc123" || # The middle management clones 661 "DSA:bcd987" || 662 "DSA:cde333" || 663 "DSA:def975" || 664 "DSA:978add" 665 Conditions: (app_domain="SPEND") # nested clauses 666 -> { (@(dollars) < 100) -> _MAX_TRUST; 667 (@(dollars) < 500) -> "ApproveAndLog"; 668 }; 669 Signature: "RSA-SHA1:186123" 670.Ed 671 672Assume a query in which the ordered set of Compliance Values is 673{"Reject", "ApproveAndLog", "Approve"}. Under policies E and G, and 674credentials F and H, the Policy Compliance Value is "Approve" 675(_MAX_TRUST) when: 676.Bd -literal 677 _ACTION_AUTHORIZERS = "DSA:978add" 678 app_domain = "SPEND" 679 dollars = "45" 680 unmentioned_attribute = "whatever" 681 and 682 _ACTION_AUTHORIZERS = "RSA:abc123,DSA:cde333" 683 app_domain = "SPEND" 684 dollars = "550" 685.Ed 686 687The following return "ApproveAndLog": 688.Bd -literal 689 _ACTION_AUTHORIZERS = "DSA:feed1234,DSA:cde333" 690 app_domain = "SPEND" 691 dollars = "5500" 692 and 693 _ACTION_AUTHORIZERS = "DSA:cde333" 694 app_domain = "SPEND" 695 dollars = "150" 696.Ed 697 698However, the following return "Reject" (_MIN_TRUST): 699.Bd -literal 700 _ACTION_AUTHORIZERS = "DSA:def975" 701 app_domain = "SPEND" 702 dollars = "550" 703 and 704 _ACTION_AUTHORIZERS = "DSA:cde333,DSA:978add" 705 app_domain = "SPEND" 706 dollars = "5500" 707.Ed 708.Pp 709.Sh FILES 710.Fd keynote.h 711.Fd libkeynote.a 712.Sh SEE ALSO 713.Xr keynote 1 , 714.Xr keynote 3 , 715.Xr keynote 5 716.Bl -tag -width "AAAAAAA" 717.It ``The KeyNote Trust-Management System, Version 2'' 718M. Blaze, J. Feigenbaum, A. D. Keromytis, 719Internet Drafts, RFC 2704. 720.It ``Decentralized Trust Management'' 721M. Blaze, J. Feigenbaum, J. Lacy, 7221996 IEEE Conference on Privacy and Security 723.It ``Compliance-Checking in the PolicyMaker Trust Management System'' 724M. Blaze, J. Feigenbaum, M. Strauss, 7251998 Financial Crypto Conference 726.El 727.Sh AUTHOR 728Angelos D. Keromytis (angelos@dsl.cis.upenn.edu) 729.Sh WEB PAGE 730http://www.cis.upenn.edu/~keynote 731.Sh BUGS 732None that we know of. 733If you find any, please report them at 734.Bd -literal -offset indent -compact 735keynote@research.att.com 736.Ed 737