idnits 2.17.1 draft-angelos-spki-keynote-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 10) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([Bra97]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 196 has weird spacing: '... in hexadec...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 1998) is 9508 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'SPKI' is defined on line 788, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BFL96' -- Possible downref: Non-RFC (?) normative reference: ref. 'LR97' -- Possible downref: Non-RFC (?) normative reference: ref. 'Zim95' -- Possible downref: Non-RFC (?) normative reference: ref. 'X509' -- Possible downref: Non-RFC (?) normative reference: ref. 'SPKI' Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SPKI Working Group Matt Blaze 2 Internet Draft Joan Feigenbaum 3 expires in six months Angelos D. Keromytis 4 April 1998 6 The KeyNote Trust-Management System 7 draft-angelos-spki-keynote-01.txt (A) 9 Status of this Memo 11 This document is an Internet-Draft. Internet Drafts are working doc- 12 uments of the Internet Engineering Task Force (IETF), its Areas, and 13 its Working Groups. Note that other groups may also distribute work- 14 ing documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months, and may be updated, replaced, or obsoleted by other documents 18 at any time. It is not appropriate to use Internet Drafts as refer- 19 ence material, or to cite them other than as a ``working draft'' or 20 ``work in progress.'' 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 27 (US West Coast). 29 Distribution of this memo is unlimited. 31 Abstract 33 This memo describes KeyNote, a simple trust-management system to 34 support public-key infrastructure. It outlines the syntax and 35 semantics of keynote credentials, describes action environment 36 processing, and describes the application architecture into which a 37 KeyNote implementation would fit. 39 Terminology 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 43 document are to be interpreted as described in [Bra97]. 45 1. Introduction 47 This memo describes KeyNote, a simple trust-management system for 48 public-key infrastructures. Trust management, introduced in the 49 PolicyMaker system [BFL96], is a unified approach to specifying and 50 interpreting security policies, credentials, and relationships that 51 allows direct authorization of security-critical actions. In 52 particular, a trust-management system combines the notion of 53 specifying security policy with the mechanism for specifying security 54 credentials (subsuming the role of "certificates"). Credentials 55 describe a specific delegation of trust among public keys; unlike 56 traditional certificates, which bind keys to names, trust-management 57 credentials bind keys to the authorization to perform specific tasks. 59 KeyNote provides a simple notation for specifying both local 60 security policies and security credentials that can be sent over an 61 untrusted network. Policies and credentials, called "assertions" as 62 in PolicyMaker, contain predicates that describe the trusted 63 actions permitted by the holders of specific public keys. A signed 64 assertion that can be sent over an untrusted network is called a 65 Credential Assertion. Credential assertions, which serve the role 66 of "certificates," have the same syntax as policy assertions with 67 the additional feature that they are signed by the entity 68 delegating the trust. A KeyNote evaluator accepts as input a set of 69 local policy assertions, a collection of credential assertions, and 70 a collection of attributes, called an "action environment," that 71 describes a proposed trusted action associated with a set of public 72 keys. KeyNote determines whether proposed actions are consistent 73 with local policy by applying the assertion predicates to the 74 action environment. 76 Although the basic design of KeyNote is similar in spirit to that of 77 PolicyMaker, KeyNote's features have been simplified to more directly 78 support public-key infrastructure-like applications. The central 79 differences between PolicyMaker and KeyNote are: 80 - KeyNote predicates are written in a simple notation based on 81 C-like expressions and regular expressions. 82 - The KeyNote system always returns a boolean (trusted or not) 83 answer. 84 - Credential signature verification is built in to the KeyNote 85 system. 86 - Assertion syntax is based on a human-readable 87 "RFC-822"-style syntax. 88 - Trusted actions are described by simple attribute/value pairs. 90 2. KeyNote Assertion Format 92 All KeyNote assertions are encoded in ASCII strings. Four mandatory 93 fields MUST appear in all assertions (KEYNOTE-VERSION, SIGNER, 94 KEY-PREDICATE, and ACTION-PREDICATE); three optional fields MAY 95 appear (COMMENT, SIGNATURE, and LOCAL-INIT). 97 The version of KeyNote assertions described in this document is 1. 98 All fields MUST start at the beginning of a line; fields may be 99 continued by indenting with at least one SPACE or TAB character at 100 the beginning of the line. Whitespace separates tokens but is 101 otherwise ignored outside of quoted strings (our grammars below 102 omit whitespace processing in the interest of readability). All 103 name tokens are case-insensitive. It is encouraged that keys be 104 encoded in lower-case hex digits. String comparison of keys for 105 internal purposes (e.g., matching a key in the KEY-PREDICATE of one 106 assertion with a key in the SIGNER field of another assertion) MUST 107 be case insensitive. In the following sections, the notation [X]* 108 means zero or more repetitions of the string X. The notation [X]+ 109 means one or more repetitions of the string X. 111 2.1 Key Encoding 113 Keys are encoded as ALG[:LEN:HEXENC]+, where LEN is an ASCII-encoded 114 decimal number, indicating the number of characters in the HEXENC 115 field. HEXENC is key encoded in hexadecimal digits. If more than 116 one component is needed by the signature algorithm, the extra 117 components are appended. The required number of components is 118 determined by the key type. ALG is an ASCII string that describes 119 the key type (such as RSA or DSA). 121 2.2 The KEYNOTE-VERSION field 123 The KEYNOTE-VERSION field is of the form KEYNOTE-VERSION:VerNumber, 124 where VerNumber is an ASCII-encoded decimal number. The current 125 version is 1. This field MUST be the first field appearing in a 126 KeyNote assertion. 128 2.3 The LOCAL-INIT field 130 The initialization field is of the form: 131 Local-Init: Name = ConstantString [, Name = ConstantString]* 133 Name is an identifier that can be used in the ACTION-PREDICATE and 134 KEY-PREDICATE fields instead of the string ConstantString. If the 135 LOCAL-INIT field defines more than one identifier, it can occupy 136 more than one line and be indented. ConstantString can be composed 137 by concatenating smaller strings using the "+" operator (see the 138 examples). If an initialization identifier is accessed but has 139 not been defined, it should evaluate to the empty string. The 140 initialized identifier ANGELOS_DSA_KEY could, for example, be used 141 in the KEY-PREDICATE field as KEY-PREDICATE: $ANGELOS_DSA_KEY 143 When an initialization identifier is accessed in an 144 ACTION-PREDICATE expression, it shadows the value of any action 145 environment identifier, for this assertion only. If an identifier 146 is declared more than once in the LOCAL-INIT field, the assertion 147 MUST be considered invalid. 149 2.4 The SIGNER field 151 The SIGNER field is of the form SIGNER:KEY, where KEY is a key 152 encoded as described in 2.1 or an initialization constant as 153 described in 2.3. The SIGNER field may instead be of the form 154 SIGNER:Policy. A Policy assertion is one that is trusted 155 directly by the local environment. It can serve as the "root" of a 156 trust structure that authorizes a requested action. A valid input 157 to the KeyNote evaluator must contain at least one Policy 158 assertion. Because they are trusted locally, Policy assertions do 159 not require cryptographic signature verification. 161 2.5 The KEY-PREDICATE field 163 The KEY-PREDICATE field is of the form Key-Predicate:KEY-EXPR. 164 KEY-EXPR is given by the following grammar: 166 KEY-EXPR: (KEY-EXPR) | 167 KEY-EXPR "&&" KEY-EXPR | 168 KEY-EXPR "||" KEY-EXPR | 169 K-of(KEYLIST) | 170 KEY | 171 "$"STRING 173 KEYLIST: KEY | 174 "$"STRING | 175 KEY, KEYLIST | 176 "$"STRING, KEYLIST 178 STRING: [a-zA-Z0-9][a-zA-Z0-9_\.]* 180 The "&&" operator has higher precedence than the "||" operator. 182 "K" is an ASCII-encoded decimal number. A KEYLIST SHOULD contain at 183 least K keys. Whitespace characters (space, tab, newline) in 184 KEY-EXPR MUST be ignored. The semantics of k-OF are that at least 185 K distinct keys from the KEYLIST must authorize a request. If the 186 KEY-EXPR field is empty, it always evaluates to TRUE and is used 187 for direct authorization of a ACTION-PREDICATE by a policy or a 188 credential. 190 2.6 The SIGNATURE field 192 The SIGNATURE field is of the form Signature:NAME[:LEN:SIG]+, where 193 NAME is an ASCII string that indicates the signature type (e.g., 194 RSA-MD5-PKCS1). LEN is an ASCII encoded decimal number that 195 indicates the length of the SIG field. SIG is the signature encoded 196 in hexadecimal digits. If more than one component is needed by 197 the signature algorithm, the extra components are appended. The 198 required number of components is determined by the NAME field 199 value. The signature is computed over the KEYNOTE-VERSION, SIGNER, 200 LOCAL-INIT, KEY-PREDICATE, COMMENT, and ACTION-PREDICATE fields, 201 concatenated with the NAME field, as they appear in the credential. 202 This field MUST be last in a KeyNote assertion. 204 2.7 The COMMENT field 206 The COMMENT field is of the form Comment: .* 207 The interpretation of this field is application-dependent. 209 2.8 The ACTION-PREDICATE field 211 The ACTION-PREDICATE field is of the form ACTION-PREDICATE: EXPR, 212 where EXPR is described by the following grammar: 214 EXPR: "(" EXPR ")" | 215 EXPR "&&" EXPR | /* Logical AND */ 216 EXPR "||" EXPR | /* Logical OR */ 217 "!"EXPR | /* Logical NOT */ 218 NUMEXPR | 219 FLOATEXPR | 220 STRINGEXPR | 221 true | false 223 NUMEXPR: NUMEX < NUMEX | /* Integer expression comparisons */ 224 NUMEX > NUMEX | 225 NUMEX <= NUMEX | 226 NUMEX >= NUMEX | 227 NUMEX == NUMEX | 228 NUMEX != NUMEX 230 FLOATEXPR: FLOATEX < FLOATEX | /* Floating point */ 231 FLOATEX > FLOATEX | 232 FLOATEX <= FLOATEX | 233 FLOATEX >= FLOATEX 235 STRINGEXPR: STR == STR | /* String comparisons */ 236 STR != STR | 237 STR < STR | /* Alphanumeric comparison */ 238 STR > STR | 239 STR <= STR | 240 STR >= STR | 241 STR ~= REGEXP /* Regular expression matching */ 243 STR: STR + STR | /* String concatenation */ 244 STR . STR | /* Also string concatenation */ 245 LITERALSTRING | 246 VARIABLE 247 "$(" STR ")" 249 NUMEX: NUMEX + NUMEX | /* Arithmetic operations */ 250 NUMEX - NUMEX | 251 NUMEX * NUMEX | 252 NUMEX / NUMEX | 253 NUMEX % NUMEX | 254 NUMEX ^ NUMEX | /* Exponentiation */ 255 -NUMEX 256 (NUMEX) | 257 NUMBER | 258 NUMVARIABLE 260 FLOATEX: FLOATEX + FLOATEX | /* Floating point operations */ 261 FLOATEX - FLOATEX | 262 FLOATEX * FLOATEX | 263 FLOATEX / FLOATEX | 264 FLOATEX ^ FLOATEX | /* Exponentiation */ 265 -FLOATEX 266 (FLOATEX) | 267 FLOAT | 268 FLOATVARIABLE 270 NUMBER: [0-9]+ 271 FLOAT: {NUMBER} "." {NUMBER} 272 STRING: [a-zA-Z][a-zA-Z0-9_]* 273 VSTRING: [a-zA-Z0-9][a-zA-Z0-9_]* 274 DQUOTE: \" 275 LITERALSTRING: DQUOTE (([^\"\n])|(\\[.\n]))* DQUOTE 276 VARIABLE: "$"VSTRING 277 NUMVARIABLE: "@"VSTRING 278 FLOATVARIABLE: "&"VSTRING 280 The numeric operation precedence is (higher to lower) ^, (*, /, %), 281 (+, -). Operators of equal precedence are evaluated left-to-right. 282 REGEXP refers to the POSIX 1003.2 regular expression syntax and 283 semantics. Single-backslash ("\") elimination must be performed on 284 LITERALSTRINGs (e.g., "\ac" becomes "ac"). If an ACTION-PREDICATE 285 field is empty, it always evaluates to TRUE. A division (or modulo) 286 by zero cause the enclosing boolean expression to evaluate to false. 287 String operations (including regexps) can be case-sensitive or 288 case-insensitive, specified as a run-time option. 290 3. ACTION ENVIRONMENTS 292 Trusted actions to be evaluated by KeyNote are described by a 293 collection of attribute/value pairs called the Action Environment. 294 An action environment is passed to the KeyNote system as part of 295 each query and provides the values of the variables used by 296 assertion predicates. 298 The action environment specifies a collection of values of named 299 attributes. The attributes may be examined as variables by KeyNote 300 trust predicates. 302 The exact format for specifying an action environment is determined 303 by the particular KeyNote implementation. In general, an 304 environment may be thought of as a list of assignments to 305 variables: 307 ATTRIBUTE1=VALUE1 308 ATTRIBUTE2=VALUE2 309 ... 311 If an action environment attribute is not defined, it MUST 312 evaluate to the empty string (if accessed as a string) or the 313 value zero (if accessed as an integer or a float). 315 An attribute that is accessed as an integer (by prepending the "@" 316 sign) MUST contain only digits. Similarly, an attribute that is 317 accessed as a float (through the "&" sign) MUST consist entirely of 318 digits and at most one period. In both cases if the attribute 319 contains any illegal character, the returned value MUST be zero. 321 Only one attribute, called "$ACTION_SIGNERS", is mandatory. This 322 attribute lists the key or keys associated with the action 323 environment (e.g., signer of the message whose trust is being 324 evaluated by KeyNote). The $ACTION_SIGNERS attribute is used to 325 provide the initial keys to match against the KEY-PREDICATEs. 327 In most cases, the $ACTION_SIGNERS attribute will consist of a 328 single public key (of the ALG:LEN:VAL form specified in the previous 329 section): 331 $ACTION_SIGNERS="dsa:12:abcdef123456" 333 If an action is associated with more than one key, the 334 ACTION_SIGNERS attribute may contain a comma-separated list of keys. 336 $ACTION_SIGNERS="dsa:20:123400000123abd12212, 337 rsa:28:ab34781acc01923cdeff232ff232" 339 The names of all other attributes in the action environment are not 340 specified by KeyNote but must be agreed upon by the writers of any 341 policies and credentials that are to cooperate in a KeyNote query 342 evaluation. By convention, the name of the application domain in 343 which environment attributes should be interpreted is specified in 344 the attribute APP_DOMAIN. The IANA will provide a registry of 345 reserved APP_DOMAIN names with the names and meanings of the 346 attributes they use. Note that an attribute with a particular name 347 may have different meanings in different application domains. Note 348 that the use of the registry is optional; a policy or credential 349 may depend on any attribute names used by the credentials to which 350 trust is deferred. 352 For example, an email application might reserve the APP_DOMAIN 353 "RFC822-EMAIL" and might use the following attributes: 355 $ADDRESS (the email address of a message's sender) 356 $NAME (the human name of the message sender) 357 $ORGANIZATION (the organization name). 359 The values of these attributes may be derived in the obvious way 360 from the email message headers. 362 Note that RFC822-EMAIL is simply a hypothetical example; such a 363 name may or may not appear in the actual registry with these or 364 different attributes. (Indeed, we recognize that the reality of 365 email security is considerably more complex than this example 366 suggests.) 368 4. KeyNote Action Evaluation 370 This section describes the semantics of KeyNote action evaluation. 371 An implementation is free to use any algorithm that provides 372 equivalent semantics. 374 Initialization: 376 The variable $App_Domain is assigned the name of the 377 application (e.g., "RFC822-EMAIL"). 379 The keys that authenticate the request for a trusted action are 380 assigned to the variable $Action_Signers. 382 The rest of the action environment attributes are placed in their 383 respective variables. 385 The time of day MAY be placed in the variables $GMTTimeOfDay and 386 $LocalTimeOfDay, using the format YYYYMMDDHHMMSS (e.g., 387 19980307191512). 389 Any other implementation-dependent variables and their bindings are 390 also created at this step. 392 For each KeyNote assertion passed to the evaluation engine, the 393 following steps are taken: 395 The ACTION-PREDICATE expression is evaluated. If the result is 396 boolean TRUE, and the key expression in the KEY-PREDICATE 397 field is also true, the request is approved. Otherwise, it is 398 rejected. 400 The KEY-PREDICATE field public-key expression is evaluated as 401 follows: 403 Let the key expression contain public key PK_i. A boolean 404 variable `PK_i' corresponds to this key. 406 If there is no assertion in which PK_i is the SIGNER, then the 407 boolean variable `PK_i' is false. 409 If there is at least one assertion in which PK_i is 410 the source, then the boolean variable `PK_i' is true 411 if and only if at least one of those assertions is true. 413 For a request to be approved, there must exist a directed graph 414 of KeyNote assertions rooted at a POLICY assertion of the 415 evaluator that evaluates to TRUE. If such a directed graph cannot 416 be constructed, the request is denied for lack of authorization. 417 Delegation of some authorization from key A to a set of keys B is 418 expressed as an assertion with key A in the SIGNER field, key set B 419 in the KEY-PREDICATE field, and the authorization delegated encoded 420 in the ACTION-PREDICATE field. How the expression digraph is 421 constructed is implementation-dependent, in particular because 422 different implementations may use different algorithms for 423 optimizing the graph construction. 425 5. Examples 427 In the interest of readability, these examples use much shorter 428 keys than would ordinarily be used. Note that the "SIGNATURE" 429 fields in these examples do not represent the result of any real 430 signature calculation. 432 1. TRADITIONAL CA / EMAIL 434 A. A policy unconditionally delegating trust to the holder of RSA 435 key abc123: 437 KEYNOTE-VERSION: 1 438 SIGNER: policy 439 KEY-PREDICATE: rsa-sha1-pkcsX:6:abc123 440 ACTION-PREDICATE: true 442 B. A credential assertion in which RSA Key abc123 trusts either 443 RSA key 4401ff92 or DSA key d1234f to perform actions in which 444 the "app_domain" is "rfc822-email", where the "address" matches 445 the regular expression "^.*@keynote\.research\.att\.com$". In 446 other words, abc123 trusts 4401ff92 and d1234f as certification 447 authorities for the keynote.research.att.com domain. 449 KEYNOTE-VERSION: 1 450 LOCAL-INIT: TRUSTED_PARTY1="dsa-sha1-pkcsX:8:4401" + "ff92", 451 TRUSTED_PARTY2="rsa-sha1-pkcsX:6:d1234f" 452 SIGNER: rsa-sha1-pkcsX:6:abc123 453 KEY-PREDICATE: $TRUSTED_PARTY1 || $TRUSTED_PARTY2 454 ACTION-PREDICATE: ($app_domain == "RFC822-EMAIL") && 455 ($address ~= 456 "^.*@keynote\\.research\\.att\\.com$") 457 SIGNATURE: rsa-md5-pkcsX:8:213354f9 459 C. A certificate credential for a specific user, issued by one of 460 the certification authorities above: 462 KEYNOTE-VERSION: 1 463 SIGNER: dsa-sha1-pkcsX:8:4401ff92 464 KEY-PREDICATE: dsa-sha1-pkcsX:8:12340987 465 ACTION-PREDICATE: (($app_domain == "RFC822-EMAIL") && 466 ($name == "M. Blaze" || $name == "") && 467 ($address == 468 "mab@keynote.research.att.com")) 469 SIGNATURE: dsa-sha1-pkcsX:8:ab23487 471 D. Another certificate credential for a specific user, issued by 472 one of the certification authorities above. This one allows 473 three different keys to sign as jf@keynote.research.att.com 474 (each with a different crypto algorithm). Three credentials 475 in one: 477 KEYNOTE-VERSION: 1 478 SIGNER: dsa-sha1-pkcsX:8:4401ff92= 479 KEY-PREDICATE: dsa-sha1-pkcsX:6:abc991 || 480 rsa-sha1-pkcsX:6:cde773 || 481 rsa-md5-pkcsX:6:fd091a 482 ACTION-PREDICATE: (($app_domain == "RFC822-EMAIL") && 483 ($name == "J. Feigenbaum" || $name == "") && 484 ($address == "jf@keynote.research.att.com")) 485 SIGNATURE: dsa-sha1-pkcsX:8:8912aa 487 Observe that under policy A and credentials B, C and D, the 488 following action environments are accepted: 490 $action_signer = "dsa-sha1-pkcsX:8:12340987" 491 $app_domain = "RFC822-EMAIL" 492 $address = "mab@keynote.research.att.com" 494 and 496 $action_signer = "dsa-sha1-pkcsX:8:12340987" 497 $app_domain = "RFC822-EMAIL" 498 $address = "mab@keynote.research.att.com" 499 $name = "M. Blaze" 501 while the following are not accepted: 503 $action_signer = "dsa-sha1-pkcsX:8:12340987" 504 $app_domain = "RFC822-EMAIL" 505 $address = "angelos@dsl.cis.upenn.edu" 507 and 509 $action_signer = "dsa-sha1-pkcsX:6:abc991" 510 $app_domain = "RFC822-EMAIL" 511 $address = "mab@keynote.research.att.com" 512 $name = "M. Blaze" 514 and 516 $action_signer = "dsa-sha1-pkcsX:8:12340987" 517 $app_domain = "RFC822-EMAIL" 518 $address = "mab@keynote.research.att.com" 519 $name = "J. Feigenbaum" 521 E. Here's a credential that does not allow delegation to another 522 key: 524 KEYNOTE-VERSION: 1 525 LOCAL-INIT: KEY1="dsa-sha1-pkcsX:6:fde995" 526 SIGNER: dsa-sha1-pkcsX:8:4401ff92 527 KEY-PREDICATE: $KEY1 528 ACTION-PREDICATE:($app_domain="RFC822-EMAIL") && 529 ($action_signers=$KEY1) && 530 ($name == "A. Keromytis" || 531 $name == "") && 532 ($address == 533 "angelos@keynote.research.att.com") 534 SIGNATURE: dsa-sha1-pkcsX:8:fed121ab 536 Now, even if we add a credential: 538 KEYNOTE-VERSION: 1 539 SIGNER: dsa-sha1-pkcsX:6:fde995 540 KEY-PREDICATE: dsa-sha1-pkcsX:8:bad22bad 541 ACTION-PREDICATE: true 542 SIGNATURE: dsa-sha1-pkcsX:6:973cc1 544 we still won't accept this action environment: 546 $action_signer = "dsa-sha1-pkcsX:8:bad22bad" 547 $app_domain = "RFC822-EMAIL" 548 $address = "angelos@keynote.research.att.com" 549 $name = "A. Keromytis" 551 Although, of course, we would accept: 553 $action_signer = "dsa-sha1-pkcsX:6:fde995" 554 $app_domain = "RFC822-EMAIL" 555 $address = "angelos@keynote.research.att.com" 556 $name = "A. Keromytis" 558 but not: 560 $action_signer = "dsa-sha1-pkcsX:6:fde995" 561 $app_domain = "RFC822-EMAIL" 562 $address = "angelos@keynote.research.at.com" 563 $name = "Matt Blaze" 565 2. WORKFLOW/ELECTRONIC COMMERCE 567 F. A policy that delegates authority for the "SPEND" application 568 domain to RSA key babe12 when @dollars is less than 569 10000. 571 KEYNOTE-VERSION: 1 572 SIGNER: policy 573 KEY-PREDICATE: rsa-sha1-pkcsX:6:babe12 574 ACTION-PREDICATE: ($app_domain="SPEND") && (@dollars < 10000) 576 G. RSA key babe12 requires the signature of at least 2 577 signers, one of which must be DSA key feed1234 in the 578 "SPEND" application when @dollars is less than 5000 580 KEYNOTE-VERSION: 1 581 SIGNER: rsa-sha1-pkcsX:6:babe12 582 KEY-PREDICATE: dsa-sha1-pkcsX:8:feed1234 && 583 (rsa-sha1-pkcsX:6:abc113 || 584 dsa-sha1-pkcsX:6:bcd987 || 585 dsa-sha1-pkcsX:6:cde333 || 586 dsa-sha1-pkcsX:6:def975 || 587 dsa-sha1-pkcsX:6:978add) 588 ACTION-PREDICATE: ($app_domain="SPEND") && 589 (@dollars < 5000) 590 SIGNATURE: rsa-sha1-pkcsX:6:9867a1 592 H. Any two signers if @dollars < 1000: 594 KEYNOTE-VERSION: 1 595 SIGNER: policy 596 KEY-PREDICATE: 2-of(dsa-sha1-pkcsX:8:feed1234:, 597 rsa-sha1-pkcsX:6:abc113, 598 dsa-sha1-pkcsX:6:bcd987, 599 dsa-sha1-pkcsX:6:cde333, 600 dsa-sha1-pkcsX:6:def975, 601 dsa-sha1-pkcsX:6:978add) 602 ACTION-PREDICATE: ($app_domain="SPEND") && 603 (@dollars < 1000) 605 I. As above, but only one signer required if @dollars < 100. 607 KEYNOTE-VERSION: 1 608 SIGNER: rsa-sha1-pkcsX:6:babe12 609 KEY-PREDICATE: (dsa-sha1-pkcsX:8:feed1234 || 610 rsa-sha1-pkcsX:6:abc123 || 611 dsa-sha1-pkcsX:6:bcd987 || 612 dsa-sha1-pkcsX:6:cde333 || 613 dsa-sha1-pkcsX:6:def975 || 614 dsa-sha1-pkcsX:6:978add) 615 ACTION-PREDICATE: ($app_domain="SPEND") && 616 (@dollars < 100) 618 SIGNATURE: rsa-sha1-pkcsX:6:786123 620 Under policies F and H, and credentials G and I, we accept: 622 $action_signer = "dsa-sha1-pkcsX:6:978add" 623 $app_domain = "SPEND" 624 @dollars = 45 625 $unmentioned_variable="whatever" 627 and 629 $action_signer = "rsa-sha1-pkcsX:6:abc123, 630 dsa-sha1-pkcsX:8:cde333" 631 $app_domain = "SPEND" 632 @dollars = 550 634 and 636 $action_signer = "dsa-sha1-pkcsX:8:feed1234, 637 dsa-sha1-pkcsX:6:cde333" 638 $app_domain = "SPEND" 639 @dollars = 2500 641 and 643 $action_signer = "rsa-sha1-pkcsX:8:babe12" 644 $app_domain = "SPEND" 645 @dollars = 2000 647 However, the following are not accepted: 649 $action_signer = "dsa-sha1-pkcsX:6:def975" 650 $app_domain = "SPEND" 651 @dollars = 550 653 and 655 $action_signer = "dsa-sha1-pkcsX:8:cde333, 656 dsa-sha1-pkcsX:8:978add" 657 $app_domain = "SPEND" 658 @dollars = 2500 660 3. COMMAND AND CONTROL AUTHORIZATION 662 J. A policy that at least two signers are required to authorize 663 the launch of missiles against London or Moscow. 665 KEYNOTE-VERSION: 1 666 SIGNER: policy 667 KEY-PREDICATE: 2-of(dsa-sha1-pkcsX:8:badfeed1, 668 rsa-sha1-pkcsX:8:ff123ad3, 669 dsa-sha1-pkcsX:8:198714fd, 670 dsa-sha1-pkcsX:8:a1984cde, 671 dsa-sha1-pkcsX:6:975135) 672 ACTION-PREDICATE: ($app_domain="NUKE") && 673 ($action="launch") && 674 ($delivery_system="missile") && 675 (($target="moscow") || ($target="london")) 677 6. Trust Management Architecture 679 KeyNote provides a simple mechanism for describing security policy 680 and representing credentials. It differs from traditional 681 certification systems in that the security model is based on 682 binding keys to predicates that describe what the key is authorized 683 by policy to do, rather than on resolving names. The 684 infrastructure and architecture to support a KeyNote system is 685 therefore rather different than that for a name-based certification 686 scheme. The KeyNote trust-management architecture is based on that 687 of PolicyMaker [BFL96]. 689 It is important to understand the separation between the 690 responsibilities of the KeyNote system and those of the application 691 and other support infrastructure. A KeyNote evaluator will 692 determine, based on policy and credential assertions, whether a 693 proposed action is permitted according to policy. The usefulness 694 of this determination depends on a number of factors. First, the 695 action environment attributes and the assignment of their values 696 must reflect accurately the security requirements of the 697 application. Identifying the attributes to include in the action 698 environment is perhaps the most important task in integrating 699 KeyNote into new applications. Second, the policy of the 700 application must be correct and well-formed. In particular, trust 701 must be deferred only to keys and for predicates that should, in 702 fact, be trusted by the application. Finally, KeyNote does not 703 directly enforce policy; it only provides advice to the 704 applications that call it. KeyNote assumes that the application 705 itself is trusted and that the policy assertions are correct. 706 Nothing prevents an application from submitting misleading 707 assertions to KeyNote, or from ignoring KeyNote altogether. 709 It is also up to the application (or some service outside KeyNote) 710 to select the appropriate credentials and policy assertions with 711 which to run a particular query. Note that even if inappropriate 712 credentials are provided to KeyNote, this cannot result in the 713 approval of an illegal action environment (as long as the policy 714 assertions are correct and the the action environment itself is 715 correctly passed to KeyNote). KeyNote is monotonic; adding an 716 assertion to a query can never result in a query being rejected if 717 it would have been accepted without the assertion. Omitting 718 credentials may, of course, result in legal action environments 719 being disallowed. Selecting appropriate credentials (e.g., from a 720 distributed database or "key server") is outside the scope of 721 KeyNote itself, and may properly be handled by the remote client 722 making a request, by the local machine verifying the request, or by 723 a network-based service, depending on the application. 725 In addition, KeyNote does not itself provide credential revocation 726 services, although credentials can be written to expire after some 727 date by including a date test in the predicate. Applications that 728 require credential revocation can use KeyNote to help specify and 729 implement revocation policies. A future draft will address 730 expiration and revocation services in KeyNote. 732 Observe that KeyNote adopts an almost opposite approach from that 733 of a general-purpose name-based certification scheme. In 734 name-based schemes (such as X.509), the infrastructure aims to 735 provide a common application-independent certificate, with each 736 application left to develop its own mechanism to interpret the 737 security semantics of the name. KeyNote, on the other hand, aims 738 to provide a common, application-independent mechanism for use with 739 application-specific credentials and policies. Each application 740 (or class of applications) will develop its own set of attributes, 741 with application-specific credentials and policies created to 742 operate on them. 744 Nevertheless, it is possible to take advantage of an existing 745 general-purpose name-based infrastructure but still use KeyNote to 746 specify policy and trust in some applications. If an X.509 [X509], 747 PGP [Zim95], or SDSI [LR97] -based certificate distribution 748 infrastructure provides reliable bindings between names and keys, 749 these certificates can be converted to KeyNote assertions that 750 verify that an appropriate action environment attribute has the 751 correct name. Policy assertions can be used to specify the X.509, 752 PGP, or SDSI certification authorities that are trusted for various 753 kinds of names, etc. 755 Because KeyNote is designed to support a variety of applications, 756 several different application interfaces to a KeyNote 757 implementation are possible. In the simplest, a KeyNote evaluator 758 would exist as a stand-alone application, with other applications 759 calling it as needed. KeyNote might also be implemented as a 760 library to which applications are linked. Finally, a KeyNote 761 implementation might run as a local trusted service, with local 762 applications communicating their queries via some interprocess 763 communication mechanism. 765 7. Security Considerations 767 This draft discusses a trust-management system for public-key 768 infrastructures. The draft is itself concerned with a security 769 mechanism. 771 References 773 [BFL96] M. Blaze, J. Feigenbaum, J. Lacy, Decentralized Trust 774 Management, 1996 IEEE Conference on Privacy and Security, 775 Oakland, 1996. 777 [LR97] B. Lampson, R. Rivest, SDSI - Simple Distributed System 778 Infrastructure, Draft, 1997. 780 [Zim95] P. Zimmermann, PGP User's Manual, 1995. 782 [Bra97] S. Bradner, Key words for use in RFCs to Indicate 783 Requirement Level, RFC 2119, March 1997. 785 [X509] CCITT, Recommendation X.509: The Directory Authentication 786 Framework, December 1988. 788 [SPKI] C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, and 789 T. Ylonen, SPKI Certificate Theory, Work in Progress, 790 http://www.clark.net/pub/cme/theory.txt 792 Contacts 794 Comments about this document should be discussed on the spki@c2.net 795 mailing list. 797 Questions about this document can also be directed to: 799 Matt Blaze 800 AT&T Labs - Research 801 180 Park Avenue 802 Florham Park, New Jersey 07932 804 mab@research.att.com 806 Joan Feigenbaum 807 AT&T Labs - Research 808 180 Park Avenue 809 Florham Park, New Jersey 07932 811 jf@research.att.com 813 Angelos D. Keromytis 814 Distributed Systems Lab 815 CIS Department, University of Pennsylvania 816 200 S. 33rd Street 817 Philadelphia, Pennsylvania 19104-6389 819 angelos@dsl.cis.upenn.edu