1.\" $OpenBSD: keynote.4,v 1.32 2013/07/16 15:21:11 schwarze 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 $Mdocdate: July 16 2013 $ 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. 625For example: 626.Bd -literal 627 foo == "bar" -> { 628 @a == 1/0 -> "oneval"; # subclause 1 629 @a == 2 -> "anotherval"; # subclause 2 630 }; 631.Ed 632.Pp 633Here, subclause 1 triggers a runtime error. 634Subclause 1 is therefore false (and has the value _MIN_TRUST). 635Subclause 2, however, would be evaluated normally. 636.Pp 637An invalid 638.Aq RegExpr 639is considered a runtime error and causes the test 640in which it occurs to be considered false. 641.Sh LICENSEE COMPLIANCE VALUE 642The Licensee Compliance Value of an assertion is calculated by 643evaluating the expression in the Licensees field, based on the 644Principal Compliance Value of the principals named there. 645.Pp 646If an assertion's Licensees field is empty, its Licensee Compliance 647Value is considered to be _MIN_TRUST. 648If an assertion's Licensees field is missing altogether, its Licensee 649Compliance Value is considered to be _MAX_TRUST. 650.Pp 651For each principal named in the Licensees field, its Principal 652Compliance Value is substituted for its name. 653If no Principal Compliance Value can be found for some named principal, 654its name is substituted with the _MIN_TRUST value. 655.Pp 656The licensees expression (see 657.Xr keynote 5 ) 658is evaluated as follows: 659.Bl -bullet -offset "xxx" 660.It 661A 662.Qq (...) 663expression has the value of the enclosed subexpression. 664.It 665A 666.Qq \&\& 667expression has the lower-order (minimum) of its two subexpression values. 668.It 669A 670.Qq \|\| 671expression has the higher-order (maximum) of its two subexpression values. 672.It 673A 674.Qq Ao K Ac Ns -of Ns Pq Aq List 675expression has the K-th highest order compliance value listed in 676.Aq list . 677Values that appear multiple times are counted with multiplicity. 678For example, if K = 3 and the orders of the listed compliance values are 679(0, 1, 2, 2, 3), the value of the expression is the compliance value of 680order 2. 681.El 682.Pp 683For example, consider the following Licensees field: 684.Pp 685.Dl Licensees: (\&"alice\&" && \&"bob\&") || \&"eve\&" 686.Pp 687If the Principal Compliance Value is 688.Qq yes 689for principal 690.Qq alice , 691.Qq no 692for principal 693.Qq bob , 694and 695.Qq no 696for principal 697.Qq eve , 698and 699.Qq yes 700is higher order than 701.Qq no 702in the query's Compliance Value Set, then the resulting Licensee Compliance 703Value is 704.Qq no . 705.Pp 706Observe that if there are exactly two possible compliance values 707(e.g., 708.Qq false 709and 710.Qq true ) , 711the rules of Licensee Compliance Value resolution reduce exactly to standard 712Boolean logic. 713.Sh ASSERTION MANAGEMENT 714Assertions may be either signed or unsigned. 715Only signed assertions should be used as credentials or transmitted or 716stored on untrusted media. 717Unsigned assertions should be used only to specify policy and for assertions 718whose integrity has already been verified as conforming 719to local policy by some mechanism external to the KeyNote system 720itself (e.g., X.509 certificates converted to KeyNote assertions by a 721trusted conversion program). 722.Pp 723Implementations that permit signed credentials to be verified by the 724KeyNote compliance checker generally provide two 725.Sq channels 726through which applications can make assertions available. 727Unsigned, locally-trusted assertions are provided over a 728.Sq trusted 729interface, while signed credentials are provided over an 730.Sq untrusted 731interface. 732The KeyNote compliance checker verifies correct signatures for all 733assertions submitted over the untrusted interface. 734The integrity of KeyNote evaluation requires that only assertions trusted 735as reflecting local policy are submitted to KeyNote via the trusted interface. 736.Pp 737Note that applications that use KeyNote exclusively as a local policy 738specification mechanism need use only trusted assertions. 739Other applications might need only a small number of infrequently changed 740trusted assertions to 741.Sq bootstrap 742a policy whose details are specified in signed credentials issued 743by others and submitted over the untrusted interface. 744.Sh FILES 745.Bl -tag -width libkeynote.a -compact 746.It Pa keynote.h 747.It Pa libkeynote.a 748.El 749.Sh EXAMPLES 750A policy that delegates authority for the 751.Qq SPEND 752application domain to RSA key dab212 when the amount given in the 753.Qq dollars 754attribute is less than 10000. 755.Bd -literal 756 Authorizer: "POLICY" 757 Licensees: "RSA:dab212" # the CFO's key 758 Conditions: (app_domain=="SPEND") && (@dollars < 10000); 759.Ed 760.Pp 761RSA key dab212 delegates authorization to any two signers, from a 762list, one of which must be DSA key feed1234 in the 763.Qq SPEND 764application when @dollars < 7500. 765If the amount in @dollars is 2500 or greater, the request is approved 766but logged. 767.Bd -literal 768 KeyNote-Version: 2 769 Comment: This credential specifies a spending policy 770 Authorizer: "RSA:dab212" # the CFO 771 Licensees: "DSA:feed1234" && # The vice president 772 ("RSA:abc123" || # middle manager #1 773 "DSA:bcd987" || # middle manager #2 774 "DSA:cde333" || # middle manager #3 775 "DSA:def975" || # middle manager #4 776 "DSA:978add") # middle manager #5 777 Conditions: (app_domain=="SPEND") # note nested clauses 778 -> { (@(dollars) < 2500) 779 -> _MAX_TRUST; 780 (@(dollars) < 7500) 781 -> "ApproveAndLog"; 782 }; 783 Signature: "RSA-SHA1:9867a1" 784.Ed 785.Pp 786According to this policy, any two signers from the list of managers 787will do if @(dollars) < 1000: 788.Bd -literal 789 KeyNote-Version: 2 790 Authorizer: "POLICY" 791 Licensees: 2-of("DSA:feed1234", # The VP 792 "RSA:abc123", # Middle management clones 793 "DSA:bcd987", 794 "DSA:cde333", 795 "DSA:def975", 796 "DSA:978add") 797 Conditions: (app_domain=="SPEND") && 798 (@(dollars) < 1000); 799.Ed 800.Pp 801A credential from dab212 with a similar policy, but only one signer is 802required if @(dollars) < 500. 803A log entry is made if the amount is at least 100. 804.Bd -literal 805 KeyNote-Version: 2 806 Comment: This one credential is equivalent to six separate 807 credentials, one for each VP and middle manager. 808 Individually, they can spend up to $500, but if 809 it's $100 or more, we log it. 810 Authorizer: "RSA:dab212" # From the CFO 811 Licensees: "DSA:feed1234" || # The VP 812 "RSA:abc123" || # The middle management clones 813 "DSA:bcd987" || 814 "DSA:cde333" || 815 "DSA:def975" || 816 "DSA:978add" 817 Conditions: (app_domain="SPEND") # nested clauses 818 -> { (@(dollars) < 100) -> _MAX_TRUST; 819 (@(dollars) < 500) -> "ApproveAndLog"; 820 }; 821 Signature: "RSA-SHA1:186123" 822.Ed 823.Pp 824Assume a query in which the ordered set of Compliance Values is 825.Pf { Ns Qo Reject Qc , 826.Qq ApproveAndLog , 827.Qo Approve Qc Ns } . 828Under policies E and G, and 829credentials F and H, the Policy Compliance Value is 830.Qq Approve 831(_MAX_TRUST) when: 832.Bd -literal 833 _ACTION_AUTHORIZERS = "DSA:978add" 834 app_domain = "SPEND" 835 dollars = "45" 836 unmentioned_attribute = "whatever" 837 and 838 _ACTION_AUTHORIZERS = "RSA:abc123,DSA:cde333" 839 app_domain = "SPEND" 840 dollars = "550" 841.Ed 842.Pp 843The following return "ApproveAndLog": 844.Bd -literal 845 _ACTION_AUTHORIZERS = "DSA:feed1234,DSA:cde333" 846 app_domain = "SPEND" 847 dollars = "5500" 848 and 849 _ACTION_AUTHORIZERS = "DSA:cde333" 850 app_domain = "SPEND" 851 dollars = "150" 852.Ed 853.Pp 854However, the following return "Reject" (_MIN_TRUST): 855.Bd -literal 856 _ACTION_AUTHORIZERS = "DSA:def975" 857 app_domain = "SPEND" 858 dollars = "550" 859 and 860 _ACTION_AUTHORIZERS = "DSA:cde333,DSA:978add" 861 app_domain = "SPEND" 862 dollars = "5500" 863.Ed 864.Sh SEE ALSO 865.Xr keynote 1 , 866.Xr keynote 3 , 867.Xr keynote 5 868.Rs 869.%A M. Blaze 870.%A J. Feigenbaum 871.%A J. Lacy 872.%D 1996 873.%J IEEE Symposium on Security and Privacy 874.%T Decentralized Trust Management 875.Re 876.Rs 877.%A M. Blaze 878.%A J. Feigenbaum 879.%A M. Strauss 880.%D 1998 881.%J Financial Crypto Conference 882.%T Compliance-Checking in the PolicyMaker Trust Management System 883.Re 884.Sh STANDARDS 885.Rs 886.%A M. Blaze 887.%A J. Feigenbaum 888.%A J. Ioannidis 889.%A A. Keromytis 890.%D September 1999 891.%R RFC 2704 892.%T The KeyNote Trust-Management System Version 2 893.Re 894.Sh AUTHORS 895.An Angelos D. Keromytis Aq Mt angelos@cs.columbia.edu 896.Sh WEB PAGE 897.Lk http://www1.cs.columbia.edu/~angelos/keynote.html 898.Sh BUGS 899None that we know of. 900If you find any, please report them at 901.Aq Mt keynote@research.att.com . 902