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