1.\" $OpenBSD: keynote.4,v 1.40 2022/03/31 17:27:17 naddy 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: March 31 2022 $ 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.In sys/types.h 32.In regex.h 33.In 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 RFC 822 message headers. 237A KeyNote assertion contains a sequence of sections, called 238.Sq fields , 239each of which specifying one aspect of the assertion's semantics. 240Fields start with an identifier at the beginning of a line and continue 241until the next field is encountered. 242For example: 243.Bd -literal 244 KeyNote-Version: 2 245 Comment: A simple, if contrived, email certificate for user mab 246 Local-Constants: ATT_CA_key = "RSA:acdfa1df1011bbac" 247 mab_key = "DSA:deadbeefcafe001a" 248 Authorizer: ATT_CA_key 249 Licensees: mab_key 250 Conditions: ((app_domain == "email") # valid for email only 251 && (address == "mab@research.att.com")); 252 Signature: "RSA-SHA1:f00f2244" 253.Ed 254.Pp 255For the exact meanings of all the fields, see the RFC reference at the 256end of this manual, and/or 257.Xr keynote 5 . 258.Pp 259KeyNote semantics resolve the relationship between an application's 260policy and actions requested by other principals, as supported by 261credentials. 262The KeyNote compliance checker processes the assertions against the action 263attribute set to determine the policy compliance value of a requested action. 264These semantics are defined later in this document. 265.Pp 266An important principle in KeyNote's design is 267.Sq assertion monotonicity ; 268the policy compliance value of an action is always positively derived from 269assertions made by trusted principals. 270Removing an assertion never results in increasing the compliance value 271returned by KeyNote for a given query. 272The monotonicity property can simplify the design and analysis of complex 273network-based security protocols; network failures that prevent the 274transmission of credentials can never result in spurious authorization of 275dangerous actions. 276.Pp 277Trusted actions to be evaluated by KeyNote are described by a collection of 278name-value pairs called the 279.Sq action attribute set . 280Action attributes are the mechanism by which applications communicate 281requests to KeyNote and are the primary objects on which KeyNote 282assertions operate. 283An action attribute set is passed to the KeyNote compliance checker with 284each query. 285.Pp 286Each action attribute consists of a name and a value. 287The semantics of the names and values are not interpreted by KeyNote itself; 288they vary from application to application and must be agreed upon by the 289writers of applications and the writers of the policies and credentials that 290will be used by them. 291.Pp 292Action attribute names and values are represented by arbitrary-length 293strings. 294KeyNote guarantees support of attribute names and values up 295to 2048 characters long. 296Applications and assertions should therefore avoid depending on the use of 297attributes with names or values longer than 2048 characters. 298.Pp 299Attribute values are inherently untyped and are represented as 300character strings by default. 301Attribute values may contain any non-NUL ASCII character. 302Numeric attribute 303values should first be converted to an ASCII text representation by the 304invoking application, e.g., the value 1234.5 would be represented by 305the string 306.Qq 1234.5 . 307.Pp 308An 309.Aq AttributeID 310begins with an alphabetic or underscore character and can be followed 311by any number of alphanumerics and underscores. 312Attribute names are case sensitive. 313.Pp 314If an action attribute is not defined, its value is considered to be 315the empty string. 316.Pp 317Attribute names beginning with the 318.Sq _ 319character are reserved for use by the KeyNote runtime environment and 320cannot be passed from applications as part of queries. 321The following special attribute names are used: 322.Bl -tag -width indent 323.It _MIN_TRUST 324Lowest-order (minimum) compliance value in query. 325.It _MAX_TRUST 326Highest-order (maximum) compliance value in query. 327.It _VALUES 328Linearly ordered set of compliance value in query. 329.It _ACTION_AUTHORIZERS 330Names of principals directly authorizing action in query. 331Comma separated. 332.El 333.Pp 334In addition, attributes with names of the form 335.Qq _ Ns Aq N , 336where 337.Aq N 338is an ASCII-encoded integer, are used by the regular expression matching 339mechanism described in 340.Xr keynote 5 . 341.Pp 342By convention, the name of the application domain over which action 343attributes should be interpreted is given in the attribute named 344.Qq app_domain . 345The IANA (or some other suitable authority) will provide a registry 346of reserved app_domain names. 347The registry will list the names and meanings of each application's 348attributes. 349.Pp 350The app_domain convention helps to ensure that credentials are 351interpreted as they were intended. 352An attribute with any given name may be used in many different application 353domains but might have different meanings in each of them. 354However, the use of a global registry is not always required for 355small-scale, closed applications; the only requirement is that the 356policies and credentials made available to the KeyNote compliance checker 357interpret attributes according to the same semantics assumed by the 358application that created them. 359.Pp 360For example, an email application might reserve the app_domain 361.Qq RFC822-EMAIL 362and might use the attributes named 363.Qq address 364(the mail address of a message's sender), 365.Qq name 366(the human name of the message sender), and any 367.Qq organization 368headers present (the organization name). 369The values of these attributes would be derived in the obvious way from 370the email message headers. 371The public key of the message's signer would be given in the 372.Qq _ACTION_AUTHORIZERS 373attribute 374.Sh QUERY SEMANTICS 375The discussion in the following sections assume some familiarity with 376assertion syntax. 377Refer to 378.Xr keynote 5 379for more details on the syntax. 380.Sh QUERY PARAMETERS 381A KeyNote query has four parameters: 382.Bl -bullet -offset "xxx" 383.It 384The identifier of the principal(s) requesting the action. 385.It 386The action attribute set describing the action. 387.It 388The set of compliance values of interest to the application, 389ordered from _MIN_TRUST to _MAX_TRUST. 390.It 391The policy and credential assertions that should be included in 392the evaluation. 393.El 394.Pp 395The mechanism for passing these parameters to the KeyNote evaluator is 396application dependent. 397In particular, an evaluator might provide for some parameters to be passed 398explicitly, while others are looked up externally (e.g., credentials might 399be looked up in a network- based distribution system), while still others 400might be requested from the application as needed by the evaluator, 401through a 402.Sq callback 403mechanism (e.g., for attribute values that represent values from among 404a very large namespace). 405.Sh ACTION REQUESTER 406At least one Principal must be identified in each query as the 407.Sq requester 408of the action. 409Actions may be requested by several principals, each 410considered to have individually requested it. 411This allows policies that require multiple authorizations, e.g., 412.Sq two person control . 413The set of authorizing principals is made available in the special 414attribute 415.Qq _ACTION_AUTHORIZERS ; 416if several principals are authorizers, their identifiers are separated 417with commas. 418.Sh ORDERED COMPLIANCE VALUE SET 419The set of compliance values of interest to an application (and their 420relative ranking to one another) is determined by the invoking 421application and passed to the KeyNote evaluator as a parameter of the 422query. 423In many applications, this will be Boolean, e.g., the ordered 424sets {FALSE, TRUE} or {REJECT, APPROVE}. 425Other applications may require a range of possible values, e.g., 426{No_Access, Limited_Access, Full_Access}. 427Note that applications should 428include in this set only compliance value names that are actually returned 429by the assertions. 430.Pp 431The lowest-order and highest-order compliance value strings given in 432the query are available in the special attributes named 433.Qq _MIN_TRUST 434and 435.Qq _MAX_TRUST , 436respectively. 437The complete set of query compliance values is made 438available in ascending order (from _MIN_TRUST to _MAX_TRUST) in 439the special attribute named 440.Qq _VALUES . 441Values are separated with commas; applications that use assertions 442that make use of the _VALUES attribute should therefore avoid the 443use of compliance value strings that themselves contain commas. 444.Sh PRINCIPAL IDENTIFIER NORMALIZATION 445Principal identifier comparisons among Cryptographic Principal 446Identifiers (that represent keys) in the Authorizer and Licensees 447fields or in an action's direct authorizers are performed after 448normalizing them by conversion to a canonical form. 449.Pp 450Every cryptographic algorithm used in KeyNote defines a method for 451converting keys to their canonical form and that specifies how the 452comparison for equality of two keys is performed. 453If the algorithm named in the identifier is unknown to KeyNote, 454the identifier is treated as opaque. 455.Pp 456Opaque identifiers are compared as case sensitive strings. 457.Pp 458Notice that use of opaque identifiers in the Authorizer field requires 459that the assertion's integrity be locally trusted (since it cannot be 460cryptographically verified by the compliance checker). 461.Sh POLICY COMPLIANCE VALUE CALCULATION 462The Policy Compliance Value of a query is the Principal Compliance 463Value of the principal named 464.Qq POLICY . 465.Sh PRINCIPAL COMPLIANCE VALUE 466The Compliance Value of a principal 467.Aq X 468is the highest order (maximum) of: 469.Bl -bullet -offset "xxx" 470.It 471the Direct Authorization Value of principal 472.Aq X ; 473and 474.It 475the Assertion Compliance Values of all assertions identifying 476.Aq X 477in the Authorizer field. 478.El 479.Sh DIRECT AUTHORIZATION VALUE 480The Direct Authorization Value of a principal 481.Aq X 482is _MAX_TRUST if 483.Aq X 484is listed in the query as an authorizer of the action. 485Otherwise, the Direct Authorization Value of 486.Aq X 487is _MIN_TRUST. 488.Sh ASSERTION COMPLIANCE VALUE 489The Assertion Compliance Value of an assertion is the lowest order 490(minimum) of the assertion's Conditions Compliance Value and its 491Licensee Compliance Value. 492.Sh CONDITIONS COMPLIANCE VALUE 493The Conditions Compliance Value of an assertion is the highest-order 494(maximum) value among all successful clauses listed in the conditions 495section. 496.Pp 497If no clause's test succeeds or the Conditions field is empty, an 498assertion's Conditions Compliance Value is considered to be the 499_MIN_TRUST value, as described previously. 500.Pp 501If an assertion's Conditions field is missing entirely, its Conditions 502Compliance Value is considered to be the _MAX_TRUST value, as defined 503previously. 504.Pp 505The set of successful test clause values is calculated as follows: 506.Pp 507Recall from the grammar of the Conditions field (see 508.Xr keynote 5 509for more details) that each clause in the conditions section has two 510logical parts: a `test' and an optional 511.Sq value , 512which, if present, is separated from the test with the 513.Qq \-> 514token. 515The test subclause is a 516predicate that either succeeds (evaluates to logical 517.Sq true ) 518or fails (evaluates to logical 519.Sq false ) . 520The value subclause is a string 521expression that evaluates to one value from the ordered set of 522compliance values given with the query. 523If the value subclause is missing, it is considered to be _MAX_TRUST. 524That is, the clause 525.Pp 526.Dl foo=="bar"; 527.Pp 528is equivalent to 529.Pp 530.Dl foo=="bar" \-> _MAX_TRUST; 531.Pp 532If the value component of a clause is present, in the simplest case it 533contains a string expression representing a possible compliance value. 534For example, consider an assertion with the following Conditions 535field: 536.Bd -literal 537 Conditions: 538 @user_id == 0 -> "full_access"; # clause (1) 539 @user_id < 1000 -> "user_access"; # clause (2) 540 @user_id < 10000 -> "guest_access"; # clause (3) 541 user_name == "root" -> "full_access"; # clause (4) 542.Ed 543.Pp 544Here, if the value of the 545.Qq user_id 546attribute is 547.Qq 1073 548and the 549.Qq user_name 550attribute is 551.Qq root , 552the possible compliance value set would contain the values 553.Qq guest_access 554(by clause (3)) and 555.Qq full_access 556(by clause (4)). 557If the ordered set of compliance values 558given in the query (in ascending order) is 559.Pf { Qo no_access Qc , 560.Qq guest_access , 561.Qq user_access , 562.Qo full_access Qc Ns } , 563the Conditions Compliance Value of the assertion would be 564.Qq full_access 565(because 566.Qq full_access 567has a higher-order value than 568.Qq guest_access ) . 569If the 570.Qq user_id 571attribute had the value 572.Qq 19283 573and the 574.Qq user_name 575attribute had the value 576.Qq nobody , 577no clause would succeed and the Conditions Compliance Value would be 578.Qq no_access , 579which is the lowest-order possible value (_MIN_TRUST). 580.Pp 581If a clause lists an explicit value, its value string must be named in 582the query ordered compliance value set. 583Values not named in the query 584compliance value set are considered equivalent to _MIN_TRUST. 585.Pp 586The value component of a clause can also contain recursively-nested 587clauses. 588Recursively-nested clauses are evaluated only if their parent test is true. 589That is, 590.Bd -literal 591 a=="b" -> { b=="c" -> "value1"; 592 d=="e" -> "value2"; 593 true -> "value3"; } ; 594.Ed 595.Pp 596is equivalent to 597.Bd -literal 598 (a=="b") && (b=="c") -> "value1"; 599 (a=="b") && (d=="e") -> "value2"; 600 (a=="b") -> "value3"; 601.Ed 602.Pp 603Notice that string comparisons are case sensitive. 604.Pp 605A regular expression comparison 606.Po 607.Qq ~= 608.Pc 609is considered true if the left-hand-side string expression matches 610the right-hand-side regular expression. 611If the POSIX regular expression group matching scheme is 612used, the number of groups matched is placed in the temporary meta- 613attribute 614.Qq _0 615(dereferenced as _0), and each match is placed in 616sequence in the temporary attributes (_1, _2, ..., _N). 617These match-attributes' values are valid only within subsequent references 618made within the same clause. 619Regular expression evaluation is case sensitive. 620.Pp 621A runtime error occurring in the evaluation of a test, such as 622division by zero or an invalid regular expression, causes the test to 623be considered false. 624For 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.Qq Ao K Ac Ns -of Ns Pq Aq List 674expression has the K-th highest order compliance value listed in 675.Aq list . 676Values that appear multiple times are counted with multiplicity. 677For example, if K = 3 and the orders of the listed compliance values are 678(0, 1, 2, 2, 3), the value of the expression is the compliance value of 679order 2. 680.El 681.Pp 682For example, consider the following Licensees field: 683.Pp 684.Dl Licensees: ("alice" && \&"bob") || \&"eve" 685.Pp 686If the Principal Compliance Value is 687.Qq yes 688for principal 689.Qq alice , 690.Qq no 691for principal 692.Qq bob , 693and 694.Qq no 695for principal 696.Qq eve , 697and 698.Qq yes 699is higher order than 700.Qq no 701in the query's Compliance Value Set, then the resulting Licensee Compliance 702Value is 703.Qq no . 704.Pp 705Observe that if there are exactly two possible compliance values 706(e.g., 707.Qq false 708and 709.Qq true ) , 710the rules of Licensee Compliance Value resolution reduce exactly to standard 711Boolean logic. 712.Sh ASSERTION MANAGEMENT 713Assertions may be either signed or unsigned. 714Only signed assertions should be used as credentials or transmitted or 715stored on untrusted media. 716Unsigned assertions should be used only to specify policy and for assertions 717whose integrity has already been verified as conforming 718to local policy by some mechanism external to the KeyNote system 719itself (e.g., X.509 certificates converted to KeyNote assertions by a 720trusted conversion program). 721.Pp 722Implementations that permit signed credentials to be verified by the 723KeyNote compliance checker generally provide two 724.Sq channels 725through which applications can make assertions available. 726Unsigned, locally-trusted assertions are provided over a 727.Sq trusted 728interface, while signed credentials are provided over an 729.Sq untrusted 730interface. 731The KeyNote compliance checker verifies correct signatures for all 732assertions submitted over the untrusted interface. 733The integrity of KeyNote evaluation requires that only assertions trusted 734as reflecting local policy are submitted to KeyNote via the trusted interface. 735.Pp 736Note that applications that use KeyNote exclusively as a local policy 737specification mechanism need use only trusted assertions. 738Other applications might need only a small number of infrequently changed 739trusted assertions to 740.Sq bootstrap 741a policy whose details are specified in signed credentials issued 742by others and submitted over the untrusted interface. 743.Sh FILES 744.Bl -tag -width libkeynote.a -compact 745.It Pa keynote.h 746.It Pa libkeynote.a 747.El 748.Sh EXAMPLES 749A policy that delegates authority for the 750.Qq SPEND 751application domain to RSA key dab212 when the amount given in the 752.Qq dollars 753attribute is less than 10000. 754.Bd -literal 755 Authorizer: "POLICY" 756 Licensees: "RSA:dab212" # the CFO's key 757 Conditions: (app_domain=="SPEND") && (@dollars < 10000); 758.Ed 759.Pp 760RSA key dab212 delegates authorization to any two signers, from a 761list, one of which must be DSA key feed1234 in the 762.Qq SPEND 763application when @dollars < 7500. 764If the amount in @dollars is 2500 or greater, the request is approved 765but logged. 766.Bd -literal 767 KeyNote-Version: 2 768 Comment: This credential specifies a spending policy 769 Authorizer: "RSA:dab212" # the CFO 770 Licensees: "DSA:feed1234" && # The vice president 771 ("RSA:abc123" || # middle manager #1 772 "DSA:bcd987" || # middle manager #2 773 "DSA:cde333" || # middle manager #3 774 "DSA:def975" || # middle manager #4 775 "DSA:978add") # middle manager #5 776 Conditions: (app_domain=="SPEND") # note nested clauses 777 -> { (@(dollars) < 2500) 778 -> _MAX_TRUST; 779 (@(dollars) < 7500) 780 -> "ApproveAndLog"; 781 }; 782 Signature: "RSA-SHA1:9867a1" 783.Ed 784.Pp 785According to this policy, any two signers from the list of managers 786will do if @(dollars) < 1000: 787.Bd -literal 788 KeyNote-Version: 2 789 Authorizer: "POLICY" 790 Licensees: 2-of("DSA:feed1234", # The VP 791 "RSA:abc123", # Middle management clones 792 "DSA:bcd987", 793 "DSA:cde333", 794 "DSA:def975", 795 "DSA:978add") 796 Conditions: (app_domain=="SPEND") && 797 (@(dollars) < 1000); 798.Ed 799.Pp 800A credential from dab212 with a similar policy, but only one signer is 801required if @(dollars) < 500. 802A log entry is made if the amount is at least 100. 803.Bd -literal 804 KeyNote-Version: 2 805 Comment: This one credential is equivalent to six separate 806 credentials, one for each VP and middle manager. 807 Individually, they can spend up to $500, but if 808 it's $100 or more, we log it. 809 Authorizer: "RSA:dab212" # From the CFO 810 Licensees: "DSA:feed1234" || # The VP 811 "RSA:abc123" || # The middle management clones 812 "DSA:bcd987" || 813 "DSA:cde333" || 814 "DSA:def975" || 815 "DSA:978add" 816 Conditions: (app_domain="SPEND") # nested clauses 817 -> { (@(dollars) < 100) -> _MAX_TRUST; 818 (@(dollars) < 500) -> "ApproveAndLog"; 819 }; 820 Signature: "RSA-SHA1:186123" 821.Ed 822.Pp 823Assume a query in which the ordered set of Compliance Values is 824.Pf { Qo Reject Qc , 825.Qq ApproveAndLog , 826.Qo Approve Qc Ns } . 827Under policies E and G, and 828credentials F and H, the Policy Compliance Value is 829.Qq Approve 830(_MAX_TRUST) when: 831.Bd -literal 832 _ACTION_AUTHORIZERS = "DSA:978add" 833 app_domain = "SPEND" 834 dollars = "45" 835 unmentioned_attribute = "whatever" 836 and 837 _ACTION_AUTHORIZERS = "RSA:abc123,DSA:cde333" 838 app_domain = "SPEND" 839 dollars = "550" 840.Ed 841.Pp 842The following return "ApproveAndLog": 843.Bd -literal 844 _ACTION_AUTHORIZERS = "DSA:feed1234,DSA:cde333" 845 app_domain = "SPEND" 846 dollars = "5500" 847 and 848 _ACTION_AUTHORIZERS = "DSA:cde333" 849 app_domain = "SPEND" 850 dollars = "150" 851.Ed 852.Pp 853However, the following return "Reject" (_MIN_TRUST): 854.Bd -literal 855 _ACTION_AUTHORIZERS = "DSA:def975" 856 app_domain = "SPEND" 857 dollars = "550" 858 and 859 _ACTION_AUTHORIZERS = "DSA:cde333,DSA:978add" 860 app_domain = "SPEND" 861 dollars = "5500" 862.Ed 863.Sh SEE ALSO 864.Xr keynote 1 , 865.Xr keynote 3 , 866.Xr keynote 5 867.Rs 868.%A M. Blaze 869.%A J. Feigenbaum 870.%A J. Lacy 871.%D 1996 872.%J IEEE Symposium on Security and Privacy 873.%T Decentralized Trust Management 874.Re 875.Rs 876.%A M. Blaze 877.%A J. Feigenbaum 878.%A M. Strauss 879.%D 1998 880.%J Financial Crypto Conference 881.%T Compliance-Checking in the PolicyMaker Trust Management System 882.Re 883.Sh STANDARDS 884.Rs 885.%A M. Blaze 886.%A J. Feigenbaum 887.%A J. Ioannidis 888.%A A. Keromytis 889.%D September 1999 890.%R RFC 2704 891.%T The KeyNote Trust-Management System Version 2 892.Re 893.Sh AUTHORS 894.An Angelos D. Keromytis Aq Mt angelos@cs.columbia.edu 895.Sh WEB PAGE 896.Lk https://www1.cs.columbia.edu/~angelos/keynote.html 897