idnits 2.17.1 draft-ietf-spki-cert-theory-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 49 pages 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 8 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 75 has weird spacing: '...for the purpo...' -- 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 (28 May 1999) is 9097 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'PEM' is mentioned on line 365, but not defined == Unused Reference: 'Ab97' is defined on line 1831, but no explicit reference was found in the text == Unused Reference: 'CHAUM' is defined on line 1838, but no explicit reference was found in the text == Unused Reference: 'DvH' is defined on line 1845, but no explicit reference was found in the text == Unused Reference: 'IDENT' is defined on line 1860, but no explicit reference was found in the text == Unused Reference: 'IWG' is defined on line 1863, but no explicit reference was found in the text == Unused Reference: 'KEYKOS' is defined on line 1868, but no explicit reference was found in the text == Unused Reference: 'LAMPSON' is defined on line 1877, but no explicit reference was found in the text == Unused Reference: 'LANDAU' is defined on line 1881, but no explicit reference was found in the text == Unused Reference: 'LEVY' is defined on line 1884, but no explicit reference was found in the text == Unused Reference: 'LINDEN' is defined on line 1887, but no explicit reference was found in the text == Unused Reference: 'PKCS1' is defined on line 1891, but no explicit reference was found in the text == Unused Reference: 'PKLOGIN' is defined on line 1894, but no explicit reference was found in the text == Unused Reference: 'RFC1321' is defined on line 1905, but no explicit reference was found in the text == Unused Reference: 'RFC2045' is defined on line 1908, but no explicit reference was found in the text == Unused Reference: 'RFC2046' is defined on line 1912, but no explicit reference was found in the text == Unused Reference: 'RFC2047' is defined on line 1915, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 1922, but no explicit reference was found in the text == Unused Reference: 'SET' is defined on line 1929, but no explicit reference was found in the text == Unused Reference: 'SEXP' is defined on line 1933, but no explicit reference was found in the text == Unused Reference: 'WEBSTER' is defined on line 1943, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Ab97' -- Possible downref: Non-RFC (?) normative reference: ref. 'BFL' -- Possible downref: Non-RFC (?) normative reference: ref. 'CHAUM' -- Possible downref: Non-RFC (?) normative reference: ref. 'DH' -- Possible downref: Non-RFC (?) normative reference: ref. 'DvH' -- Possible downref: Non-RFC (?) normative reference: ref. 'ECR' -- Possible downref: Non-RFC (?) normative reference: ref. 'ELIEN' -- Possible downref: Non-RFC (?) normative reference: ref. 'HARDY' -- Possible downref: Non-RFC (?) normative reference: ref. 'IDENT' -- Possible downref: Non-RFC (?) normative reference: ref. 'IWG' -- Possible downref: Non-RFC (?) normative reference: ref. 'KEYKOS' -- Possible downref: Non-RFC (?) normative reference: ref. 'KOHNFELDER' -- Possible downref: Non-RFC (?) normative reference: ref. 'LAMPSON' -- Possible downref: Non-RFC (?) normative reference: ref. 'LANDAU' -- Possible downref: Non-RFC (?) normative reference: ref. 'LEVY' -- Possible downref: Non-RFC (?) normative reference: ref. 'LINDEN' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS1' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKLOGIN' -- Possible downref: Non-RFC (?) normative reference: ref. 'R98' ** Obsolete normative reference: RFC 1114 (Obsoleted by RFC 1422) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) ** Downref: Normative reference to an Informational RFC: RFC 2104 -- Possible downref: Non-RFC (?) normative reference: ref. 'SDSI' -- Possible downref: Non-RFC (?) normative reference: ref. 'SET' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEXP' -- Possible downref: Non-RFC (?) normative reference: ref. 'SRC-070' -- Possible downref: Non-RFC (?) normative reference: ref. 'UPKI' -- Possible downref: Non-RFC (?) normative reference: ref. 'WEBSTER' Summary: 9 errors (**), 0 flaws (~~), 26 warnings (==), 27 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SPKI Certificate Theory Carl M. Ellison 2 INTERNET-DRAFT Intel 3 Expires: 3 December 1999 4 Bill Frantz 5 Electric Communities 7 Butler Lampson 8 Microsoft 10 Ron Rivest 11 MIT Laboratory for Computer Science 13 Brian M. Thomas 14 Southwestern Bell 16 Tatu Ylonen 17 SSH 19 28 May 1999 21 SPKI Certificate Theory 22 ---- ----------- ------ 24 26 Status of This Document 28 This document is an Internet-Draft and is in full conformance with 29 all provisions of Section 10 of RFC2026. 31 This draft supersedes the draft filed under the name draft-ietf-spki- 32 cert-theory-05.txt. It contains more clarification in the 33 VIntersect() and AIntersect() descriptions beyond what was in the 34 previous draft. It also has a new section (7.7) on the use of 35 threshold subjects to achieve key lifetime management. 37 This document is one of four. SPKI structure definitions are to be 38 found in draft-ietf-spki-cert-structure-*.txt and examples of 39 certificate uses are to be found in draft-ietf-spki-cert- 40 examples-*.txt. This work derives from the requirements gathered at 41 the beginning of the working group and documented in draft-ietf-spki- 42 cert-req-*.txt. 44 Distribution of this document is unlimited. Comments should be sent 45 to the SPKI (Simple Public Key Infrastructure) Working Group mailing 46 list or to the authors. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF), its areas, and its working groups. Note that 50 other groups may also distribute working documents as Internet- 51 Drafts. 53 Internet-Drafts are draft documents valid for a maximum of six 54 months. Internet-Drafts may be updated, replaced, or obsoleted by 55 other documents at any time. It is not appropriate to use Internet- 56 Drafts as reference material or to cite them other than as a 57 ``working draft'' or ``work in progress.'' 59 The list of current Internet-Drafts can be accessed at 60 http://www.ietf.org/ietf/1id-abstracts.txt 62 The list of Internet-Draft Shadow Directories can be accessed at 63 http://www.ietf.org/shadow.html 65 Copyright (C) The Internet Society (1999). All Rights Reserved. 67 This document and translations of it may be copied and furnished to 68 others, and derivative works that comment on or otherwise explain it 69 or assist in its implmentation may be prepared, copied, published and 70 distributed, in whole or in part, without restriction of any kind, 71 provided that the above copyright notice and this paragraph are 72 included on all such copies and derivative works. However, this 73 document itself may not be modified in any way, such as by removing 74 the copyright notice or references to the Internet Society or other 75 Internet organizations, except as needed for the purpose of 76 developing Internet standards in which case the procedures for 77 copyrights defined in the Internet Standards process must be 78 followed, or as required to translate it into languages other than 79 English. 81 The limited permissions granted above are perpetual and will not be 82 revoked by the Internet Society or its successors or assigns. 84 This document and the information contained herein is provided on an 85 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 86 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 87 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 88 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 89 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 91 Abstract 93 The SPKI Working Group has developed a standard form for digital 94 certificates whose main purpose is authorization rather than 95 authentication. These structures bind either names or explicit 96 authorizations to keys or other objects. The binding to a key can be 97 directly to an explicit key, or indirectly through the hash of the 98 key or a name for it. The name and authorization structures can be 99 used separately or together. We use S-expressions as the standard 100 format for these certificates and define a canonical form for those 101 S-expressions. As part of this development, a mechanism for deriving 102 authorization decisions from a mixture of certificate types was 103 developed and is presented in this document. 105 This document gives the theory behind SPKI certificates and ACLs 106 without going into technical detail about those structures or their 107 uses. 109 Table of Contents 111 Status of This Document....................................1 113 Abstract...................................................3 115 Table of Contents..........................................4 117 1. Overview of Contents....................................6 118 1.1 Glossary...............................................6 120 2. Name Certification......................................8 121 2.1 First Definition of CERTIFICATE........................8 122 2.2 The X.500 Plan and X.509...............................9 123 2.3 X.509, PEM and PGP.....................................9 124 2.4 Rethinking Global Names...............................10 125 2.5 Inescapable Identifiers...............................12 126 2.6 Local Names...........................................12 127 2.6.1 Basic SDSI Names....................................13 128 2.6.2 Compound SDSI Names.................................13 129 2.7 Sources of Global Identifiers.........................13 130 2.8 Fully Qualified SDSI Names............................14 131 2.9 Fully Qualified X.509 Names...........................14 132 2.10 Group Names..........................................15 134 3. Authorization..........................................16 135 3.1 Attribute Certificates................................16 136 3.2 X.509v3 Extensions....................................16 137 3.3 SPKI Certificates.....................................17 138 3.4 ACL Entries...........................................18 140 4. Delegation.............................................19 141 4.1 Depth of Delegation...................................19 142 4.1.1 No control..........................................19 143 4.1.2 Boolean control.....................................19 144 4.1.3 Integer control.....................................20 145 4.1.4 The choice: boolean.................................20 146 4.2 May a Delegator Also Exercise the Permission?.........20 147 4.3 Delegation of Authorization vs. ACLs..................20 149 5. Validity Conditions....................................22 150 5.1 Anti-matter CRLs......................................22 151 5.2 Timed CRLs............................................23 152 5.3 Timed Revalidations...................................23 153 5.4 Setting the Validity Interval.........................24 154 5.5 One-time Revalidations................................24 155 5.6 Short-lived Certificates..............................24 156 5.7 Other possibilities...................................25 157 5.7.1 Micali's Inexpensive On-line Results................25 158 5.7.2 Rivest's Reversal of the CRL Logic..................25 160 6. Tuple Reduction........................................27 161 6.1 5-tuple Defined.......................................28 162 6.2 4-tuple Defined.......................................28 163 6.3 5-tuple Reduction Rules...............................29 164 6.3.1 AIntersect..........................................29 165 6.3.2 VIntersect..........................................31 166 6.3.3 Threshold Subjects..................................32 167 6.3.4 Certificate Path Discovery..........................32 168 6.4 4-tuple Reduction.....................................33 169 6.4.1 4-tuple Threshold Subject Reduction.................33 170 6.4.2 4-tuple Validity Intersection.......................34 171 6.5 Certificate Translation...............................34 172 6.5.1 X.509v1.............................................34 173 6.5.2 PGP.................................................35 174 6.5.3 X.509v3.............................................35 175 6.5.4 X9.57...............................................35 176 6.5.5 SDSI 1.0............................................35 177 6.5.6 SPKI................................................36 178 6.5.7 SSL.................................................36 179 6.6 Certificate Result Certificates.......................37 181 7. Key Management.........................................39 182 7.1 Through Inescapable Names.............................39 183 7.2 Through a Naming Authority............................39 184 7.3 Through Certificates.......................40 185 7.4 Increasing Key Lifetimes..............................40 186 7.5 One Root Per Individual...............................41 187 7.6 Key Revocation Service................................42 188 7.7 Threshold ACL Subjects................................42 190 8. Security Considerations................................44 192 References................................................45 194 Acknowledgments...........................................48 195 Authors' Addresses........................................48 196 Expiration and File Name..................................49 198 1. Overview of Contents 200 This document contains the following sections: 202 Section 2: history of name certification, from 1976 on. 204 Section 3: discussion of authorization, rather than authentication, 205 as the desired purpose of a certificate. 207 Section 4: discussion of delegation. 209 Section 5: discussion of validity conditions: date ranges, CRLs, re- 210 validations and one-time on-line validity tests. 212 Section 6: definition of 5-tuples and their reduction. 214 Section 7: discussion of key management. 216 Section 8: security considerations. 218 The References section lists all documents referred to in the text as 219 well as readings which might be of interest to anyone reading on this 220 topic. 222 The Acknowledgements section, listing contributors primarily at the 223 start of the working group. This section has not been augmented in 224 many months. The archive of working group mail is a more accurate 225 source of such information. 227 The Authors' Addresses section gives the addresses, telephone numbers 228 and e-mail addresses of the authors. 230 1.1 Glossary 232 We use some terms in the body of this document in ways that could be 233 specific to SPKI: 235 ACL: an Access Control List: a list of entries that anchors a 236 certificate chain. Sometimes called a "list of root keys", the ACL 237 is the source of empowerment for certificates. That is, a 238 certificate communicates power from its issuer to its subject, but 239 the ACL is the source of that power (since it theoretically has the 240 owner of the resource it controls as its implicit issuer). An ACL 241 entry has potentially the same content as a certificate body, but has 242 no Issuer (and is not signed). There is most likely one ACL for each 243 resource owner, if not for each controlled resource. 245 CERTIFICATE: a signed instrument that empowers the Subject. It 246 contains at least an Issuer and a Subject. It can contain validity 247 conditions, authorization and delegation information. Certificates 248 come in three categories: ID (mapping ), Attribute (mapping 249 ), and Authorization (mapping 250 ). An SPKI authorization or attribute certificate 251 can pass along all the empowerment it has received from the Issuer or 252 it can pass along only a portion of that empowerment. 254 ISSUER: the signer of a certificate and the source of empowerment 255 that the certificate is communicating to the Subject. 257 KEYHOLDER: the person or other entity that owns and controls a given 258 private key. This entity is said to be the keyholder of the keypair 259 or just the public key, but control of the private key is assumed in 260 all cases. 262 PRINCIPAL: a cryptographic key, capable of generating a digital 263 signature. We deal with public-key signatures in this document but 264 any digital signature method should apply. 266 SPEAKING: A Principal is said to "speak" by means of a digital 267 signature. The statement made is the signed object (often a 268 certificate). The Principal is said to "speak for" the Keyholder. 270 SUBJECT: the thing empowered by a certificate or ACL entry. This can 271 be in the form of a key, a name (with the understanding that the name 272 is mapped by certificate to some key or other object), a hash of some 273 object, or a set of keys arranged in a threshold function. 275 S-EXPRESSION: the data format chosen for SPKI/SDSI. This is a LISP- 276 like parenthesized expression with the limitations that empty lists 277 are not allowed and the first element in any S-expression must be a 278 string, called the "type" of the expression. 280 THRESHOLD SUBJECT: a Subject for an ACL entry or certificate that 281 specifies K of N other Subjects. Conceptually, the power being 282 transmitted to the Subject by the ACL entry or certificate is 283 transmitted in (1/K) amount to each listed subordinate Subject. K of 284 those subordinate Subjects must agree (by delegating their shares 285 along to the same object or key) for that power to be passed along. 286 This mechanism introduces fault tolerance and is especially useful in 287 an ACL entry, providing fault tolerance for "root keys". 289 2. Name Certification 291 Certificates were originally viewed as having one function: binding 292 names to keys or keys to names. This thought can be traced back to 293 the paper by Diffie and Hellman introducing public key cryptography 294 in 1976. Prior to that time, key management was risky, involved and 295 costly, sometimes employing special couriers with briefcases 296 handcuffed to their wrists. 298 Diffie and Hellman thought they had radically solved this problem. 299 "Given a system of this kind, the problem of key distribution is 300 vastly simplified. Each user generates a pair of inverse 301 transformations, E and D, at his terminal. The deciphering 302 transformation, D, must be kept secret but need never be communicated 303 on any channel. The enciphering key, E, can be made public by 304 placing it in a public directory along with the user's name and 305 address. Anyone can then encrypt messages and send them to the user, 306 but no one else can decipher messages intended for him." [DH] 308 This modified telephone book, fully public, took the place of the 309 trusted courier. This directory could be put on-line and therefore 310 be available on demand, worldwide. In considering that prospect, 311 Loren Kohnfelder, in his 1978 bachelor's thesis in electrical 312 engineering from MIT [KOHNFELDER], noted: "Public-key communication 313 works best when the encryption functions can reliably be shared among 314 the communicants (by direct contact if possible). Yet when such a 315 reliable exchange of functions is impossible the next best thing is 316 to trust a third party. Diffie and Hellman introduce a central 317 authority known as the Public File." 319 2.1 First Definition of CERTIFICATE 321 Kohnfelder then noted, "Each individual has a name in the system by 322 which he is referenced in the Public File. Once two communicants 323 have gotten each other's keys from the Public File they can securely 324 communicate. The Public File digitally signs all of its 325 transmissions so that enemy impersonation of the Public File is 326 precluded." In an effort to prevent performance problems, Kohnfelder 327 invented a new construct: a digitally signed data record containing a 328 name and a public key. He called this new construct a CERTIFICATE. 329 Because it was digitally signed, such a certificate could be held by 330 non-trusted parties and passed around from person to person, 331 resolving the performance problems involved in a central directory. 333 2.2 The X.500 Plan and X.509 335 Ten years after Kohnfelder's thesis, the ISO X.509 recommendation was 336 published as part of X.500. X.500 was to be a global, distributed 337 database of named entities: people, computers, printers, etc. In 338 other words, it was to be a global, on-line telephone book. The 339 organizations owning some portion of the name space would maintain 340 that portion and possibly even provide the computers on which it was 341 stored. X.509 certificates were defined to bind public keys to X.500 342 path names (Distinguished Names) with the intention of noting which 343 keyholder had permission to modify which X.500 directory nodes. In 344 fact, the X.509 data record was originally designed to hold a 345 password instead of a public key as the record-access authentication 346 mechanism. 348 The original X.500 plan is unlikely ever to come to fruition. 349 Collections of directory entries (such as employee lists, customer 350 lists, contact lists, etc.) are considered valuable or even 351 confidential by those owning the lists and are not likely to be 352 released to the world in the form of an X.500 directory sub-tree. 353 For an extreme example, imagine the CIA adding its directory of 354 agents to a world-wide X.500 pool. 356 The X.500 idea of a distinguished name (a single, globally unique 357 name that everyone could use when referring to an entity) is also not 358 likely to occur. That idea requires a single, global naming 359 discipline and there are too many entities already in the business of 360 defining names not under a single discipline. Legacy therefore 361 militates against such an idea. 363 2.3 X.509, PEM and PGP 365 The Privacy Enhanced Mail [PEM] effort of the Internet Engineering 366 Task Force [RFC1114] adopted X.509 certificates, but with a different 367 interpretation. Where X.509 was originally intended to mean "the 368 keyholder may modify this portion of the X.500 database", PEM took 369 the certificate to mean "the key speaks for the named person". What 370 had been an access control instrument was now an identity instrument, 371 along the lines envisioned by Diffie, Hellman and Kohnfelder. 373 The insistence on X.509 certificates with a single global root 374 delayed PEM's adoption past its window of viability. RIPEM, by Mark 375 Riordan of MSU, was a version of PEM without X.509 certificates. It 376 was distributed and used by a small community, but fell into disuse. 377 MOSS (a MIME-enhanced version of PEM, produced by TIS (www.tis.com)) 378 made certificate use optional, but received little distribution. 380 At about the same time, in 1991, Phil Zimmermann's PGP was introduced 381 with a different certificate model. Instead of waiting for a single 382 global root and the hierarchy of Certificate Authorities descending 383 from that root, PGP allowed multiple, (hopefully) independent but not 384 specially trusted individuals to sign a association, 385 attesting to its validity. The theory was that with enough such 386 signatures, that association could be trusted because not all of 387 these signer would be corrupt. This was known as the "web of trust" 388 model. It differed from X.509 in the method of assuring trust in the 389 binding, but it still intended to bind a globally unique 390 name to a key. With PEM and PGP, the intention was for a keyholder 391 to be known to anyone in the world by this certified global name. 393 2.4 Rethinking Global Names 395 The assumption that the job of a certificate was to bind a name to a 396 key made sense when it was first published. In the 1970's, people 397 operated in relatively small communities. Relationships formed face 398 to face. Once you knew who someone was, you often knew enough to 399 decide how to behave with that person. As a result, people have 400 reduced this requirement to the simply stated: "know who you're 401 dealing with". 403 Names, in turn, are what we humans use as identifiers of persons. We 404 learn this practice as infants. In the family environment names work 405 as identifiers, even today. What we learn as infants is especially 406 difficult to re-learn later in life. Therefore, it is natural for 407 people to translate the need to know who the keyholder is into a need 408 to know the keyholder's name. 410 Computer applications need to make decisions about keyholders. These 411 decisions are almost never made strictly on the basis of a 412 keyholder's name. There is some other fact about the keyholder of 413 interest to the application (or to the human being running the 414 application). If a name functions at all for security purposes, it 415 is as an index into some database (or human memory) of that other 416 information. To serve in this role, the name must be unique, in 417 order to serve as an index, and there must be some information to be 418 indexed. 420 The names we use to identify people are usually unique, within our 421 local domain, but that is not true on a global scale. It is 422 extremely unlikely that the name by which we know someone, a given 423 name, would function as a unique identifier on the Internet. Given 424 names continue to serve the social function of making the named 425 person feel recognized when addressed by name but they are inadequate 426 as the identifiers envisioned by Diffie, Hellman and Kohnfelder. 428 In the 1970's and even through the early 1990's, relationships formed 429 in person and one could assume having met the keyholder and therefore 430 having acquired knowledge about that person. If a name could be 431 found that was an adequate identifier of that keyholder, then one 432 might use that name to index into memories about the keyholder and 433 then be able to make the relevant decision. 435 In the late 1990's, this is no longer true. With the explosion of 436 the Internet, it is likely that one will encounter keyholders who are 437 complete strangers in the physical world and will remain so. Contact 438 will be made digitally and will remain digital for the duration of 439 the relationship. Therefore, on first encounter there is no body of 440 knowledge to be indexed by any identifier. 442 One might consider building a global database of facts about all 443 persons in the world and making that database available (perhaps for 444 a fee). The name that indexes that database might also serve as a 445 globally unique ID for the person referenced. The database entry 446 under that name could contain all the information needed to allow 447 someone to make a security decision. Since there are multiple 448 decision-makers, each interested in specific information, the 449 database would need to contain the union of multiple sets of 450 information. However, that solution would constitute a massive 451 privacy violation and would probably be rejected as politically 452 impossible. 454 A globally unique ID might even fail when dealing with people we do 455 know. Few of us know the full given names of people with whom we 456 deal. A globally unique name for a person would be larger than the 457 full given name (and probably contain it, out of deference to a 458 person's fondness for his or her own name). It would therefore not 459 be a name by which we know the person, barring a radical change in 460 human behavior. 462 A globally unique ID that contains a person's given name poses a 463 special danger. If a human being is part of the process (e.g., 464 scanning a database of global IDs in order to find the ID of a 465 specific person for the purpose of issuing an attribute certificate), 466 then it is likely that the human operator would pay attention to the 467 familiar portion of the ID (the common name) and pay less attention 468 to the rest. Since the common name is not an adequate ID, this can 469 lead to mistakes. Where there can be mistakes, there is an avenue 470 for attack. 472 Where globally unique identifiers need to be used, perhaps the best 473 ID is one that is uniform in appearance (such as a long number or 474 random looking text string) so that it has no recognizable sub-field. 475 It should also be large enough (from a sparse enough name space) that 476 typographical errors would not yield another valid identifier. 478 2.5 Inescapable Identifiers 480 Some people speak of global IDs as if they were inescapable 481 identifiers, able to prevent someone from doing evil under one name, 482 changing his name and starting over again. To make that scenario 483 come true, one would have to have assignment of such identifiers 484 (probably by governments, at birth) and some mechanism so that it is 485 always possible to get from any flesh and blood person back to his or 486 her identifier. Given that latter mechanism, any Certificate 487 Authority desiring to issue a certificate to a given individual would 488 presumably choose the same, inescapable name for that certificate. A 489 full set of biometrics might suffice, for example, to look up a 490 person without danger of false positive in a database of globally 491 assigned ID numbers and with that procedure one could implement 492 inescapable IDs. 494 The use of an inescapable identifier might be possible in some 495 countries, but in others (such as the US) it would meet strong 496 political opposition. Some countries have government-assigned ID 497 numbers for citizens but also have privacy regulations that prohibit 498 the use of those numbers for routine business. In either of these 499 latter cases, the inescapable ID would not be available for use in 500 routine certificates. 502 There was a concern that commercial Certificate Authorities might 503 have been used to bring inescapable names into existence, bypassing 504 the political process and the opposition to such names in those 505 countries where such opposition is strong. As the (name,key) 506 certificate business is evolving today, there are multiple competing 507 CAs each creating disjoint Distinguished Name spaces. There is also 508 no real block to the creation of new CAs. Therefore a person is able 509 to drop one Distinguished Name and get another, by changing CA, 510 making these names not inescapable. 512 2.6 Local Names 514 Globally unique names may be politically undesirable and relatively 515 useless, in the world of the Internet, but we use names all the time. 517 The names we use are local names. These are the names we write in 518 our personal address books or use as nicknames or aliases with e-mail 519 agents. They can be IDs assigned by corporations (e.g., bank account 520 numbers or employee numbers). Those names or IDs do not need to be 521 globally unique. Rather, they need to be unique for the one entity 522 that maintains that address book, e-mail alias file or list of 523 accounts. More importantly, they need to be meaningful to the person 524 who uses them as indexes. 526 Ron Rivest and Butler Lampson showed with SDSI 1.0 [SDSI] that one 527 can not only use local names locally, one can use local names 528 globally. The clear security advantage and operational simplicity of 529 SDSI names caused us in the SPKI group to adopt SDSI names as part of 530 the SPKI standard. 532 2.6.1 Basic SDSI Names 534 A basic SDSI 2.0 name is an S-expression with two elements: the word 535 "name" and the chosen name. For example, 537 george: (name fred) 539 represents a basic SDSI name "fred" in the name space defined by 540 george. 542 2.6.2 Compound SDSI Names 544 If fred in turn defines a name, for example, 546 fred: (name sam) 548 then george can refer to this same entity as 550 george: (name fred sam) 552 2.7 Sources of Global Identifiers 554 Even though humans use local names, computer systems often need 555 globally unique identifiers. Even in the examples of section 2.6.2 556 above, we needed to make the local names more global and did so by 557 specifying the name-space owner. 559 If we are using public key cryptography, we have a ready source of 560 globally unique identifiers. 562 When one creates a key pair, for use in public key cryptography, the 563 private key is bound to its owner by good key safeguarding practice. 564 If that private key gets loose from its owner, then a basic premise 565 of public key cryptography has been violated and that key is no 566 longer of interest. 568 The private key is also globally unique. If it were not, then the 569 key generation process would be seriously flawed and we would have to 570 abandon this public key system implementation. 572 The private key must be kept secret, so it is not a possible 573 identifier, but each public key corresponds to one private key and 574 therefore to one keyholder. The public key, viewed as a byte string, 575 is therefore an identifier for the keyholder. 577 If there exists a collision-free hash function, then a collision-free 578 hash of the public key is also a globally unique identifier for the 579 keyholder, and probably a shorter one than the public key. 581 2.8 Fully Qualified SDSI Names 583 SDSI local names are of great value to their definer. Each local 584 name maps to one or more public keys and therefore to the 585 corresponding keyholder(s). Through SDSI's name chaining, these 586 local names become useful potentially to the whole world. [See 587 section 2.6.2 for an example of SDSI name chaining.] 589 To a computer system making use of these names, the name string is 590 not enough. One must identify the name space in which that byte 591 string is defined. That name space can be identified globally by a 592 public key. 594 It is SDSI 1.0 convention, preserved in SPKI, that if a (local) SDSI 595 name occurs within a certificate, then the public key of the issuer 596 is the identifier of the name space in which that name is defined. 598 However, if a SDSI name is ever to occur outside of a certificate, 599 the name space within which it is defined must be identified. This 600 gives rise to the Fully Qualified SDSI Name. That name is a public 601 key followed by one or more names relative to that key. If there are 602 two or more names, then the string of names is a SDSI name chain. 603 For example, 605 (name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) jim therese) 607 is a fully qualified SDSI name, using the SHA-1 hash of a public key 608 as the global identifier defining the name space and anchoring this 609 name string. 611 2.9 Fully Qualified X.509 Names 613 An X.509 Distinguished Name can and sometimes must be expressed as a 614 Fully Qualified Name. If the PEM or original X.500 vision of a 615 single root for a global name space had come true, this wouldn't be 616 necessary because all names would be relative to that same one root 617 key. However, there is not now and is not likely ever to be a single 618 root key. Therefore, every X.509 name should be expressed as the 619 pair 621 (name ) 623 if all leaf names descending from that root are unique. If 624 uniqueness is enforced only within each individual CA, then one would 625 build a Fully Qualified Name chain from an X.509 certificate chain, 626 yielding the form 628 (name ... ). 630 2.10 Group Names 632 SPKI/SDSI does not claim to enforce one key per name. Therefore, a 633 named group can be defined by issuing multiple (name,key) 634 certificates with the same name -- one for each group member. 636 3. Authorization 638 Fully qualified SDSI names represent globally unique names, but at 639 every step of their construction the local name used is presumably 640 meaningful to the issuer. Therefore, with SDSI name certificates one 641 can identify the keyholder by a name relevant to someone. 643 However, what an application needs to do, when given a public key 644 certificate or a set of them, is answer the question of whether the 645 remote keyholder is permitted some access. That application must 646 make a decision. The data needed for that decision is almost never 647 the spelling of a keyholder's name. 649 Instead, the application needs to know if the keyholder is authorized 650 for some access. This is the primary job of a certificate, according 651 to the members of the SPKI WG, and the SPKI certificate was designed 652 to meet this need as simply and directly as possible. 654 We realize that the world is not going to switch to SPKI certificates 655 overnight. Therefore, we developed an authorization computation 656 process that can use certificates in any format. That process is 657 described below in section 6. 659 The various methods of establishing authorization are documented 660 below, briefly. (See also [UPKI]) 662 3.1 Attribute Certificates 664 An Attribute Certificate, as defined in X9.57, binds an attribute 665 that could be an authorization to a Distinguished Name. For an 666 application to use this information, it must combine an attribute 667 certificate with an ID certificate, in order to get the full mapping: 669 authorization -> name -> key 671 Presumably the two certificates involved came from different issuers, 672 one an authority on the authorization and the other an authority on 673 names. However, if either of these issuers were subverted, then an 674 attacker could obtain an authorization improperly. Therefore, both 675 the issuers need to be trusted with the authorization decision. 677 3.2 X.509v3 Extensions 679 X.509v3 permits general extensions. These extensions can be used to 680 carry authorization information. This makes the certificate an 681 instrument mapping both: 683 authorization -> key 685 and 687 name -> key 689 In this case, there is only one issuer, who must be an authority on 690 both the authorization and the name. 692 Some propose issuing a master X.509v3 certificate to an individual 693 and letting extensions hold all the attributes or authorizations the 694 individual would need. This would require the issuer to be an 695 authority on all of those authorizations. In addition, this 696 aggregation of attributes would result in shortening the lifetime of 697 the certificate, since each attribute would have its own lifetime. 698 Finally, aggregation of attributes amounts to the building of a 699 dossier and represents a potential privacy violation. 701 For all of these reasons, it is desirable that authorizations be 702 limited to one per certificate. 704 3.3 SPKI Certificates 706 A basic SPKI certificate defines a straight authorization mapping: 708 authorization -> key 710 If someone wants access to a keyholder's name, for logging purposes 711 or even for punishment after wrong-doing, then one can map from key 712 to location information (name, address, phone, ...) to get: 714 authorization -> key -> name 716 This mapping has an apparent security advantage over the attribute 717 certificate mapping. In the mapping above, only the 719 authorization -> key 721 mapping needs to be secure at the level required for the access 722 control mechanism. The 724 key -> name 726 mapping (and the issuer of any certificates involved) needs to be 727 secure enough to satisfy lawyers or private investigators, but a 728 subversion of this mapping does not permit the attacker to defeat the 729 access control. Presumably, therefore, the care with which these 730 certificates (or database entries) are created is less critical than 731 the care with which the authorization certificate is issued. It is 732 also possible that the mapping to name need not be on-line or 733 protected as certificates, since it would be used by human 734 investigators only in unusual circumstances. 736 3.4 ACL Entries 738 SDSI 1.0 defined an ACL, granting authorization to names. It was 739 then like an attribute certificate, except that it did not need to be 740 signed or issued by any key. It was held in local memory and was 741 assumed issued by the owner of the computer and therefore of the 742 resource being controlled. 744 In SPKI, an ACL entry is free to be implemented in any way the 745 developer chooses, since it is never communicated and therefore does 746 not need to be standardized. However, a sample implementation is 747 documented, as a certificate body minus the issuer field. The ACL 748 entry can have a name as a subject, as in SDSI 1.0, or it can have a 749 key as a subject. Examples of the latter include the list of SSL 750 root keys in an SSL capable browser or the file .ssh/authorized_keys 751 in a user's home UNIX directory. Those ACLs are single-purpose, so 752 the individual entries do not carry explicit authorizations, but SPKI 753 uses explicit authorizations so that one can use common authorization 754 computation code to deal with multiple applications. 756 4. Delegation 758 One of the powers of an authorization certificate is the ability to 759 delegate authorizations from one person to another without bothering 760 the owner of the resource(s) involved. One might issue a simple 761 permission (e.g., to read some file) or issue the permission to 762 delegate that permission further. 764 Two issues arose as we considered delegation: the desire to limit 765 depth of delegation and the question of separating delegators from 766 those who can exercise the delegated permission. 768 4.1 Depth of Delegation 770 There were three camps in discussing depth of delegation: no control, 771 boolean control and integer control. There remain camps in favor of 772 each of these, but a decision was reached in favor of boolean 773 control. 775 4.1.1 No control 777 The argument in favor of no control is that if a keyholder is given 778 permission to do something but not the permission to delegate it, 779 then it is possible for that keyholder to loan out the empowered 780 private key or to set up a proxy service, signing challenges or 781 requests for the intended delegate. Therefore, the attempt to 782 restrict the permission to delegate is ineffective and might back- 783 fire, by leading to improper security practices. 785 4.1.2 Boolean control 787 The argument in favor of boolean control is that one might need to 788 specify an inability to delegate. For example, one could imagine the 789 US Commerce Department having a key that is authorized to declare a 790 cryptographic software module exportable and also to delegate that 791 authorization to others (e.g., manufacturers). It is reasonable to 792 assume the Commerce Department would not issue permission to delegate 793 this further. That is, it would want to have a direct legal 794 agreement with each manufacturer and issue a certificate to that 795 manufacturer only to reflect that the legal agreement is in place. 797 4.1.3 Integer control 799 The argument in favor of integer control is that one might want to 800 restrict the depth of delegation in order to control the 801 proliferation of a delegated permission. 803 4.1.4 The choice: boolean 805 Of these three, the group chose boolean control. The subject of a 806 certificate or ACL entry may exercise any permission granted and, if 807 delegation is TRUE, may also delegate that permission or some subset 808 of it to others. 810 The no control argument has logical appeal, but there remains the 811 assumption that a user will value his or her private key enough not 812 to loan it out or that the key will be locked in hardware where it 813 can't be copied to any other user. This doesn't prevent the user 814 from setting up a signing oracle, but lack of network connectivity 815 might inhibit that mechanism. 817 The integer control option was the original design and has appeal, 818 but was defeated by the inability to predict the proper depth of 819 delegation. One can always need to go one more level down, by 820 creating a temporary signing key (e.g., for use in a laptop). 821 Therefore, the initially predicted depth could be significantly off. 822 As for controlling the proliferation of permissions, there is no 823 control on the width of the delegation tree, so control on its depth 824 is not a tight control on proliferation. 826 4.2 May a Delegator Also Exercise the Permission? 828 We decided that a delegator is free to create a new key pair, also 829 controlled by it, and delegate the rights to that key to exercise the 830 delegated permission. Therefore, there was no benefit from 831 attempting to restrict the exercise of a permission by someone 832 permitted to delegate it. 834 4.3 Delegation of Authorization vs. ACLs 836 One concern with defining an authorization certificate is that the 837 function can be performed by traditional ACLs 838 and ID certificates defining groups. Such a mechanism was 839 described in SDSI 1.0. A new mechanism needs to add value or it just 840 complicates life for the developer. 842 The argument for delegated authorization as opposed to ACLs can be 843 seen in the following example. 845 Imagine a firewall proxy permitting telnet and ftp access from the 846 Internet into a network of US DoD machines. Because of the 847 sensitivity of that destination network, strong access control would 848 be desired. One could use public key authentication and public key 849 certificates to establish who the individual keyholder was. Both the 850 private key and the keyholder's certificates could be kept on a 851 Fortezza card. That card holds X.509v1 certificates, so all that can 852 be established is the name of the keyholder. It is then the job of 853 the firewall to keep an ACL, listing named keyholders and the forms 854 of access they are each permitted. 856 Consider the ACL itself. Not only would it be potentially huge, 857 demanding far more storage than the firewall would otherwise require, 858 but it would also need its own ACL. One could not, for example, have 859 someone in the Army have the power to decide whether someone in the 860 Navy got access. In fact, the ACL would probably need not one level 861 of its own ACL, but a nested set of ACLs, eventually reflecting the 862 organization structure of the entire Defense Department. 864 Without the ACLs, the firewall could be implemented in a device with 865 no mass storage, residing in a sealed unit one could easily hold in 866 one hand. With the ACLs, it would need a large mass storage device 867 that would be accessed not only while making access control decisions 868 but also for updating the ACLs. 870 By contrast, let the access be controlled by authorization 871 certificates. The firewall would have an ACL with one entry, 872 granting a key belonging to the Secretary of Defense the right to 873 delegate all access through the firewall. The Secretary would, in 874 turn, issue certificates delegating this permission to delegate to 875 each of his or her subordinates. This process would iterate, until 876 some enlisted man would receive permission to penetrate that firewall 877 for some specific one protocol, but not have permission to delegate 878 that permission. 880 The certificate structure generated would reflect the organization 881 structure of the entire Defense Department, just as the nested ACLs 882 would have, but the control of these certificates (via their issuance 883 and revocation) is distributed and need not show up in that one 884 firewall or be replicated in all firewalls. Each individual 885 delegator of permission performs a simple task, well understood. The 886 application software to allow that delegation is correspondingly 887 simple. 889 5. Validity Conditions 891 A certificate, or an ACL entry, has optional validity conditions. 892 The traditional ones are validity dates: not-before and not-after. 893 The SPKI group resolved, in discussion, that on-line tests of various 894 kinds are also validity conditions. That is, they further refine the 895 valid date range of a certificate. Three kinds of on-line tests are 896 envisioned: CRL, re-validation and one-time. 898 When validity confirmation is provided by some online test, then the 899 issuer of those refinements need not be the issuer of the original 900 certificate. In many cases, the business or security model for the 901 two issuers is different. However, in SPKI, the certificate issuer 902 must specify the issuer of validity confirmations. 904 5.1 Anti-matter CRLs 906 An early form of CRL [Certificate Revocation List] was modeled after 907 the news print book that used to be kept at supermarket checkout 908 stands. Those books held lists of bad checking account numbers and, 909 later, bad credit card numbers. If one's payment instrument wasn't 910 listed in the book, then that instrument was considered good. 912 These books would be issued periodically, and delivered by some means 913 not necessarily taking a constant time. However, when a new book 914 arrived, the clerk would replace the older edition with the new one 915 and start using it. This design was suited to the constraints of the 916 implementation: use of physical books, delivered by physical means. 917 The book held bad account numbers rather than good ones because the 918 list of bad accounts was smaller. 920 An early CRL design followed this model. It had a list of revoked 921 certificate identifiers. It also had a sequence number, so that one 922 could tell which of two CRLs was more recent. A newer CRL would 923 replace an older one. 925 This mode of operation is like wandering anti-matter. When the 926 issuer wants to revoke a certificate, it is listed in the next CRL to 927 go out. If the revocation is urgent, then that CRL can be released 928 immediately. The CRL then follows some dissemination process 929 unrelated to the needs of the consumers of the CRL. If the CRL 930 encounters a certificate it has listed, it effectively annihilates 931 that certificate. If it encounters an older CRL, it annihilates that 932 CRL also, leaving a copies of itself at the verifiers it encounters. 934 However, this process is non-deterministic. The result of the 935 authorization computation is at least timing dependent. Given an 936 active adversary, it can also be a security hole. That is, an 937 adversary can prevent revocation of a given certificate by preventing 938 the delivery of new CRLs. This does not require cryptographic level 939 effort, merely network tampering. 941 SPKI has ruled out the use of wandering anti-matter CRLs for its 942 certificates. Every authorization computation is deterministic, 943 under SPKI rules. 945 5.2 Timed CRLs 947 SPKI permits use of timed CRLs. That is, if a certificate can be 948 referenced in a CRL, then the CRL process is subject to three 949 conditions. 951 1. The certificate must list the key (or its hash) that will sign 952 the CRL and may give one or more locations where that CRL might 953 be fetched. 955 2. The CRL must carry validity dates. 957 3. CRL validity date ranges must not intersect. That is, one may 958 not issue a new CRL to take effect before the expiration of the 959 CRL currently deployed. 961 Under these rules, no certificate that might use a CRL can be 962 processed without a valid CRL and no CRL can be issued to show up as 963 a surprise at the verifier. This yields a deterministic validity 964 computation, independent of clock skew, although clock inaccuracies 965 in the verifier may produce a result not desired by the issuer. The 966 CRL in this case is a completion of the certificate, rather than a 967 message to the world announcing a change of mind. 969 Since CRLs might get very large and since they tend to grow 970 monotonically, one might want to issue changes to CRLs rather than 971 full ones. That is, a CRL might be a full CRL followed by a sequence 972 of delta-CRLs. That sequence of instruments is then treated as a 973 current CRL and the combined CRL must follow the conditions listed 974 above. 976 5.3 Timed Revalidations 978 CRLs are negative statements. The positive version of a CRL is what 979 we call a revalidation. Typically a revalidation would list only one 980 certificate (the one of interest), although it might list a set of 981 certificates (to save digital signature effort). 983 As with the CRL, SPKI demands that this process be deterministic and 984 therefore that the revalidation follow the same rules listed above 985 (in section 5.2). 987 5.4 Setting the Validity Interval 989 Both timed CRLs and timed revalidations have non-0 validity 990 intervals. To set this validity interval, one must answer the 991 question: "How long are you willing to let the world believe and act 992 on a statement you know to be false?" 994 That is, one must assume that the previous CRL or revalidation has 995 just been signed and transmitted to at least one consumer, locking up 996 a time slot. The next available time slot starts after this validity 997 interval ends. That is the earliest one can revoke a certificate one 998 learns to be false. 1000 The answer to that question comes from risk management. It will 1001 probably be based on expected monetary losses, at least in commercial 1002 cases. 1004 5.5 One-time Revalidations 1006 Validity intervals of length zero are not possible. Since 1007 transmission takes time, by the time a CRL was received by the 1008 verifier, it would be out of date and unusable. That assumes perfect 1009 clock synchronization. If clock skew is taken into consideration, 1010 validity intervals need to be that much larger to be meaningful. 1012 For those who want to set the validity interval to zero, SPKI defines 1013 a one-time revalidation. 1015 This form of revalidation has no lifetime beyond the current 1016 authorization computation. One applies for this on-line, one-time 1017 revalidation by submitting a request containing a nonce. That nonce 1018 gets returned in the signed revalidation instrument, in order to 1019 prevent replay attacks. This protocol takes the place of a validity 1020 date range and represents a validity interval of zero, starting and 1021 ending at the time the authorization computation completes. 1023 5.6 Short-lived Certificates 1025 A performance analysis of the various methods of achieving fine-grain 1026 control over the validity interval of a certificate should consider 1027 the possibility of just making the original certificate short-lived, 1028 especially if the online test result is issued by the same key that 1029 issued the certificate. There are cases in which the short-lived 1030 certificate requires fewer signatures and less network traffic than 1031 the various online test options. The use of a short-lived 1032 certificate always requires fewer signature verifications than the 1033 use of certificate plus online test result. 1035 If one wants to issue short-lived certificates, SPKI defines a kind 1036 of online test statement to tell the user of the certificate where a 1037 replacement short-lived certificate might be fetched. 1039 5.7 Other possibilities 1041 There are other possibilities to be considered when choosing a 1042 validity condition model to use. 1044 5.7.1 Micali's Inexpensive On-line Results 1046 Silvio Micali has patented a mechanism for using hash chains to 1047 revalidate or revoke a certificate inexpensively. This mechanism 1048 changes the performance requirements of those models and might 1049 therefore change the conclusion from a performance analysis. [ECR] 1051 5.7.2 Rivest's Reversal of the CRL Logic 1053 Ron Rivest has written a paper [R98] suggesting that the whole 1054 validity condition model is flawed because it assumes that the issuer 1055 (or some entity to which it delegates this responsibility) decides 1056 the conditions under which a certificate is valid. That traditional 1057 model is consistent with a military key management model, in which 1058 there is some central authority responsible for key release and for 1059 determining key validity. 1061 However, in the commercial space, it is the verifier and not the 1062 issuer who is taking a risk by accepting a certificate. It should 1063 therefore be the verifier who decides what level of assurance he 1064 needs before accepting a credential. That verifier needs information 1065 from the issuer, and the more recent that information the better, but 1066 the decision is the verifier's in the end. 1068 This line of thought deserves further consideration, but is not 1069 reflected in the SPKI structure definition. It might even be that 1070 both the issuer and the verifier have stakes in this decision, so 1071 that any replacement validity logic would have to include inputs from 1072 both. 1074 6. Tuple Reduction 1076 The processing of certificates and related objects to yield an 1077 authorization result is the province of the developer of the 1078 application or system. The processing plan presented here is an 1079 example that may be followed, but its primary purpose is to clarify 1080 the semantics of an SPKI certificate and the way it and various other 1081 kinds of certificate might be used to yield an authorization result. 1083 There are three kinds of entity that might be input to the 1084 computation that yields an authorization result: 1086 1. (as a certificate) 1088 2. (as an attribute certificate or ACL entry) 1090 3. (as an authorization certificate or ACL 1091 entry) 1093 These entities are processed in three stages. 1095 1. Individual certificates are verified by checking their 1096 signatures and possibly performing other work. They are then 1097 mapped to intermediate forms, called "tuples" here. 1099 The other work for SPKI or SDSI certificates might include 1100 processing of on-line test results (CRL, re-validation or one- 1101 time validation). 1103 The other work for PGP certificates may include a web-of-trust 1104 computation. 1106 The other work for X.509 certificates depends on the written 1107 documentation for that particular use of X.509 (typically tied 1108 to the root key from which the certificate descended) and could 1109 involve checking information in the parent certificate as well 1110 as additional information in extensions of the certificate in 1111 question. That is, some use X.509 certificates just to define 1112 names. Others use X.509 to communicate an authorization 1113 implicitly (e.g., SSL server certificates). Some might define 1114 extensions of X.509 to carry explicit authorizations. All of 1115 these interpretations are specified in written documentation 1116 associated with the certificate chain and therefore with the 1117 root from which the chain descends. 1119 If on-line tests are involved in the certificate processing, 1120 then the validity dates of those on-line test results are 1121 intersected by VIntersect() [defined in 6.3.2, below] with the 1122 validity dates of the certificate to yield the dates in the 1123 certificate's tuple(s). 1125 2. Uses of names are replaced with simple definitions (keys or 1126 hashes), based on the name definitions available from reducing 1127 name 4-tuples. 1129 3. Authorization 5-tuples are then reduced to a final authorization 1130 result. 1132 6.1 5-tuple Defined 1134 The 5-tuple is an intermediate form, assumed to be held in trusted 1135 memory so that it doesn't need a digital signature for integrity. It 1136 is produced from certificates or other credentials via trusted 1137 software. Its contents are the same as the contents of an SPKI 1138 certificate body, but it might be derived from another form of 1139 certificate or from an ACL entry. 1141 The elements of a 5-tuple are: 1143 1. Issuer: a public key (or its hash), or the reserved word "Self". 1144 This identifies the entity speaking this intermediate result. 1146 2. Subject: a public key (or its hash), a name used to identify a 1147 public key, the hash of an object or a threshold function of 1148 subordinate subjects. This identifies the entity being spoken 1149 about in this intermediate result. 1151 3. Delegation: a boolean. If TRUE, then the Subject is permitted 1152 by the Issuer to further propagate the authorization in this 1153 intermediate result. 1155 4. Authorization: an S-expression. [Rules for combination of 1156 Authorizations are given below.] 1158 5. Validity dates: a not-before date and a not-after date, where 1159 "date" means date and time. If the not-before date is missing 1160 from the source credential then minus infinity is assumed. If 1161 the not-after date is missing then plus infinity is assumed. 1163 6.2 4-tuple Defined 1165 A certificate (such as X.509v1 or SDSI 1.0) carries no 1166 authorization field but does carry a name. Since it is qualitatively 1167 different from an authorization certificate, a separate intermediate 1168 form is defined for it. 1170 The elements of a Name 4-tuple are: 1172 1. Issuer: a public key (or its hash). This identifies the entity 1173 defining this name in its private name space. 1175 2. Name: a byte string 1177 3. Subject: a public key (or its hash), a name, or a threshold 1178 function of subordinate subjects. This defines the name. 1180 4. Validity dates: a not-before date and a not-after date, where 1181 "date" means date and time. If the not-before date is missing 1182 from the source credential then minus infinity is assumed. If 1183 the not-after date is missing then plus infinity is assumed. 1185 6.3 5-tuple Reduction Rules 1187 The two 5-tuples: 1189 + 1191 yield 1193 1195 provided 1197 the two intersections succeed, 1199 S1 = I2 1201 and 1203 D1 = TRUE 1205 If S1 is a threshold subject, there is a slight modification to this 1206 rule, as described below in section 6.3.3. 1208 6.3.1 AIntersect 1210 An authorization is a list of strings or sub-lists, of meaning to and 1211 probably defined by the application that will use this authorization 1212 for access control. Two authorizations intersect by matching, 1213 element for element. If one list is longer than the other but match 1214 at all elements where both lists have elements, then the longer list 1215 is the result of the intersection. This means that additional 1216 elements of a list must restrict the permission granted. 1218 Although actual authorization string definitions are application 1219 dependent, AIntersect provides rules for automatic intersection of 1220 these strings so that application developers can know the semantics 1221 of the strings they use. Special semantics would require special 1222 reduction software. 1224 For example, there might be an ftpd that allows public key access 1225 control, using authorization certificates. Under that service, 1227 (ftp (host ftp.clark.net)) 1229 might imply that the keyholder would be allowed ftp access to all 1230 directories on ftp.clark.net, with all kinds of access (read, write, 1231 delete, ...). This is more general (allows more access) than 1233 (ftp (host ftp.clark.net) (dir /pub/cme)) 1235 which would allow all kinds of access but only in the directory 1236 specified. The intersection of the two would be the second. 1238 Since the AIntersect rules imply position dependency, one could also 1239 define the previous authorization string as: 1241 (ftp ftp.clark.net /pub/cme) 1243 to keep the form compact. 1245 To allow for wild cards, there are a small number of special S- 1246 expressions defined, using "*" as the expression name. 1248 (*) 1249 stands for the set of all S-expressions and byte-strings. 1250 In other words, it will match anything. When intersected 1251 with anything, the result is that other thing. [The 1252 AIntersect rule about lists of different length treats a 1253 list as if it had enough (*) entries implicitly appended to 1254 it to match the length of another list with which it was 1255 being intersected.] 1257 (* set *) 1258 stands for the set of elements listed in the *-form. 1260 (* prefix ) 1261 stands for the set of all byte strings that start with the 1262 one given in the *-form. 1264 (* range ? ?) 1265 stands for the set of all byte strings lexically (or 1266 numerically) between the two limits. The ordering 1267 parameter (alpha, numeric, time, binary, date) specifies 1268 the kind of strings allowed. 1270 AIntersect() is normal set intersection, when *-forms are defined as 1271 they are above and a normal list is taken to mean all lists that 1272 start with those elements. The following examples should give a more 1273 concrete explanation for those who prefer an explanation without 1274 reference to set operations. 1276 AIntersect( (tag (ftp ftp.clark.net cme (* set read write))), 1277 (tag (*)) ) 1279 evaluates to (tag (ftp ftp.clark.net cme (* set read write))) 1281 AIntersect( (tag (* set read write (foo bla) delete)), 1282 (tag (* set write read) ) ) 1284 evaluates to (tag (* set read write)) 1286 AIntersect( (tag (* set read write (foo bla) delete)), 1287 (tag read ) ) 1289 evaluates to (tag read) 1291 AIntersect( (tag (* prefix http://www.clark.net/pub/)), 1292 (tag (* prefix http://www.clark.net/pub/cme/html/)) ) 1294 evaluates to (tag (* prefix http://www.clark.net/pub/cme/html/)) 1296 AIntersect( (tag (* range numeric ge #30# le #39# )), (tag #26#) ) 1298 fails to intersect. 1300 6.3.2 VIntersect 1302 Date range intersection is straight-forward. 1304 V = VIntersect( X, Y ) 1306 is defined as 1308 Vmin = max( Xmin, Ymin ) 1310 Vmax = min( Xmax, Ymax ) 1312 and if Vmin > Vmax, then the intersection failed. 1314 These rules assume that daytimes are expressed in a monotonic form, 1315 as they are in SPKI. 1317 The full SPKI VIntersect() also deals with online tests. In the most 1318 straight-forward implementation, each online test to which a 1319 certificate is subject is evaluated. Each such test carries with it 1320 a validity interval, in terms of dates. That validity interval is 1321 intersected with any present in the certificate, to yield a new, 1322 current validity interval. 1324 It is possible for an implementation of VIntersect() to gather up 1325 online tests that are present in each certificate and include the 1326 union of all those tests in the accumulating tuples. In this case, 1327 the evaluation of those online tests is deferred until the end of the 1328 process. This might be appropriate if the tuple reduction is being 1329 performed not for answering an immediate authorization question but 1330 rather for generation of a summary certificate (Certificate Result 1331 Certificate) that one might hope would be useful for a long time. 1333 6.3.3 Threshold Subjects 1335 A threshold subject is specified by two numbers, K and N [0 K2] 1373 2. [(name K1 N) -> (name K2 N1 N2 ... Nk)] 1375 As with the 5-tuples discussed in the previous section, name 1376 definition 4-tuples should be delivered in the order needed by the 1377 prover. In that case, the rule for name reduction is to replace the 1378 name just defined by its definition. For example, 1380 (name K1 N N1 N2 N3) + [(name K1 N) -> K2] 1382 -> (name K2 N1 N2 N3) 1384 or, in case 2 above, 1386 (name K1 N Na Nb Nc) + [(name K1 N) -> (name K2 N1 N2 ... Nk)] 1388 -> (name K2 N1 N2 ... Nk Na Nb Nc) 1390 With the second form of name definition, one might have names that 1391 temporarily grow. If the prover is providing certificates in order, 1392 then the verifier need only do as it is told. 1394 If the verifier is operating from an unordered pool of tuples, then a 1395 safe rule for name reduction is to apply only those 4-tuples that 1396 define a name as a key. Such applications should bring 4-tuples that 1397 started out in class (2) into class (1), and eventually reduce all 1398 names to keys. Any naming loops are avoided by this process. 1400 6.4.1 4-tuple Threshold Subject Reduction 1402 Some of a threshold subject's subordinate subjects might be names. 1403 Those names must be reduced by application of 4-tuples. The name 1404 reduction process proceeds independently on each name in the 1405 subordinate subject as indicated in 6.3.3 above. 1407 One can reduce individual named subjects in a threshold subject and 1408 leave the subject in threshold form, if one desires. There is no 1409 delegation- or authorization-intersection involved, only a validity- 1410 intersection during name reduction. This might be used by a service 1411 that produces Certificate Result Certificates [see 6.7]. 1413 6.4.2 4-tuple Validity Intersection 1415 Whenever a 4-tuple is used to reduce the subject (or part of the 1416 subject) of another tuple, its validity interval is intersected with 1417 that of the tuple holding the subject being reduced and the 1418 intersection is used in the resulting tuple. Since a 4-tuple 1419 contains no delegation or authorization fields, the delegation 1420 permission and authorization of the tuple being acted upon does not 1421 change. 1423 6.5 Certificate Translation 1425 Any certificate currently defined, as well as ACL entries and 1426 possibly other instruments, can be translated to 5-tuples (or name 1427 tuples) and therefore take part in an authorization computation. The 1428 specific rules for those are given below. 1430 6.5.1 X.509v1 1432 The original X.509 certificate is a certificate. It 1433 translates directly to a name tuple. The form 1435 [Kroot, (name ), K1, validity] 1437 is used if the rules for that particular X.509 hierarchy is that all 1438 leaf names are unique, under that root. If uniqueness of names 1439 applies only to individual CAs in the X.509 hierarchy, then one must 1440 generate 1442 [Kroot, (name CA1 CA2 ... CAk ), K1, validity] 1444 after verifying the certificate chain by the rules appropriate to 1445 that particular chain. 1447 6.5.2 PGP 1449 A PGP certificate is a certificate. It is verified by 1450 web-of-trust rules (as specified in the PGP documentation). Once 1451 verified, it yields name tuples of the form 1453 [Ki, name, K1, validity] 1455 where Ki is a key that signed that PGP (UserID,key) pair. There 1456 would be one tuple produced for each signature on the key, K1. 1458 6.5.3 X.509v3 1460 An X.509v3 certificate may be used to declare a name. It might also 1461 declare explicit authorizations, by way of extensions. It might also 1462 declare an implicit authorization of the form (tag (*)). The actual 1463 set of tuples it yields depends on the documentation associated with 1464 that line of certificates. That documentation could conceptually be 1465 considered associated with the root key of the certificate chain. In 1466 addition, some X.509v3 certificates (such as those used for SET), 1467 have defined extra validity tests for certificate chains depending on 1468 custom extensions. As a result, it is likely that X.509v3 chains 1469 will have to be validated independently, by chain validation code 1470 specific to each root key. After that validation, that root-specific 1471 code can then generate the appropriate multiple tuples from the one 1472 certificate. 1474 6.5.4 X9.57 1476 An X9.57 attribute certificate should yield one or more 5-tuples, 1477 with names as Subject. The code translating the attribute 1478 certificate will have to build a fully-qualified name to represent 1479 the Distinguished Name in the Subject. For any attribute 1480 certificates that refer to an ID certificate explicitly, the Subject 1481 of the 5-tuple can be the key in that ID certificate, bypassing the 1482 construction of name 4-tuples. 1484 6.5.5 SDSI 1.0 1486 A SDSI 1.0 certificate maps directly to one 4-tuple. 1488 6.5.6 SPKI 1490 An SPKI certificate maps directly to one 4- or 5- tuple, depending 1491 respectively on whether it is a name certificate or carries an 1492 authorization. 1494 6.5.7 SSL 1496 An SSL certificate carries a number of authorizations, some 1497 implicitly. The authorization: 1499 (tag (ssl)) 1501 is implicit. In addition, the server certificate carries a DNS name 1502 parameter to be matched against the DNS name of the web page to which 1503 the connection is being made. That might be encoded as: 1505 (tag (dns )) 1507 Meanwhile, there is the "global cert" permission -- the permission 1508 for a US-supplied browser to connect using full strength symmetric 1509 cryptography even though the server is outside the USA. This might 1510 be encoded as: 1512 (tag (us-crypto)) 1514 There are other key usage attributes that would also be encoded as 1515 tag fields, but a full discussion of those fields is left to the 1516 examples document. 1518 An ACL entry for an SSL root key would have the tag: 1520 (tag (* set (ssl) (dns (*)))) 1522 which by the rules of intersection is equivalent to: 1524 (tag (* set (ssl) (dns))) 1526 unless that root key also had the permission from the US Commerce 1527 Department to grant us-crypto permission, in which case the root key 1528 would have: 1530 (tag (* set (ssl) (dns) (us-crypto))) 1532 A CA certificate, used for SSL, would then need only to communicate 1533 down its certificate chain those permissions allocated in the ACL. 1534 Its tag might then translate to: 1536 (tag (*)) 1538 A leaf server certificate for the Datafellows server might, for 1539 example, have a tag field of the form: 1541 (tag (* set (ssl) (dns www.datafellows.com))) 1543 showing that it was empowered to do SSL and to operate from the given 1544 domain name, but not to use US crypto with a US browser. 1546 The use of (* set) for the two attributes in this example could have 1547 been abbreviated as: 1549 (tag (ssl www.datafellows.com)) 1551 while CA certificates might carry: 1553 (tag (ssl (*))) or just (tag (*)) 1555 but separating them, via (* set), allows for a future enhancement of 1556 SSL in which the (ssl) permission is derived from one set of root 1557 keys (those of current CAs) while the (dns) permission is derived 1558 from another set of root keys (those empowered to speak in DNSSEC) 1559 while the (us-crypto) permission might be granted only to a root key 1560 belonging to the US Department of Commerce. The three separate tests 1561 in the verifying code (e.g., the browser) would then involve separate 1562 5-tuple reductions from separate root key ACL entries. 1564 The fact that these three kinds of permission are treated as if ANDed 1565 is derived from the logic of the code that interprets the permissions 1566 and is not expressed in the certificate. That decision is embodied 1567 in the authorization code executed by the verifying application. 1569 6.6 Certificate Result Certificates 1571 Typically, one will reduce a chain of certificates to answer an 1572 authorization question in one of two forms: 1574 1. Is this Subject, S, allowed to do A, under this ACL and with 1575 this set of certificates? 1577 2. What is Subject S allowed to do, under this ACL and with this 1578 set of certificates? 1580 The answer to the second computation can be put into a new 1581 certificate issued by the entity doing the computation. That one 1582 certificate corresponds to the semantics of the underlying 1583 certificates and online test results. We call it a Certificate 1584 Result Certificate. 1586 7. Key Management 1588 Cryptographic keys have limited lifetimes. Keys can be stolen. Keys 1589 might also be discovered through cryptanalysis. If the theft is 1590 noticed, then the key can be replaced as one would replace a credit 1591 card. More likely, the theft will not be noticed. To cover this 1592 case, keys are replaced routinely. 1594 The replacement of a key needs to be announced to those who would use 1595 the new key. It also needs to be accomplished smoothly, with a 1596 minimum of hassle. 1598 Rather than define a mechanism for declaring a key to be bad or 1599 replaced, SPKI defines a mechanism for giving certificates limited 1600 lifetimes so that they can be replaced. That is, under SPKI one does 1601 not declare a key to be bad but rather stops empowering it and 1602 instead empowers some other key. This limitation of a certificate's 1603 lifetime might be by limited lifetime at time of issuance or might be 1604 via the lifetime acquired through an on-line test (CRL, revalidation 1605 or one-time). Therefore, all key lifetime control becomes 1606 certificate lifetime control. 1608 7.1 Through Inescapable Names 1610 If keyholders had inescapable names [see section 2.5, above], then 1611 one could refer to them by those names and define a certificate to 1612 map from an inescapable name to the person's current key. That 1613 certificate could be issued by any CA, since all CAs would use the 1614 inescapable name for the keyholder. The attribute certificates and 1615 ACLs that refer to the keyholder would all refer to this one 1616 inescapable name. 1618 However, there are no inescapable names for keyholders. [See section 1619 2.5, above.] 1621 7.2 Through a Naming Authority 1623 One could conceivably have a governmental body or other entity that 1624 would issue names voluntarily to a keyholder, strictly for the 1625 purpose of key management. One would then receive all authorizations 1626 through that name. There would have to be only one such authority, 1627 however. Otherwise, names would have to be composed of parts: an 1628 authority name and the individual's name. The authority name would, 1629 in turn, have to be granted by some single global authority. 1631 That authority then becomes able to create keys of its own and 1632 certificates to empower them as any individual, and through those 1633 false certificates acquire access rights of any individual in the 1634 world. Such power is not likely to be tolerated. Therefore, such a 1635 central authority is not likely to come to pass. 1637 7.3 Through Certificates 1639 Instead of inescapable names or single-root naming authorities, we 1640 have names assigned by some entity that issues a 1641 certificate. As noted in sections 2.8 and 2.9, above, such names 1642 have no meaning by themselves. They must be fully qualified to have 1643 meaning. 1645 Therefore, in the construct: 1647 (name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) jim) 1649 the name is not 1651 "jim" 1653 but rather 1655 "(name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) jim)" 1657 This name includes a public key (through its hash, in the example 1658 above). That key has a lifetime like any other key, so this name has 1659 not achieved the kind of permanence (free from key lifetimes) that an 1660 inescapable name has. However, it appears to be our only 1661 alternative. 1663 This name could easily be issued by the named keyholder, for the 1664 purpose of key management only. In that case, there is no concern 1665 about access control being subverted by some third-party naming 1666 authority. 1668 7.4 Increasing Key Lifetimes 1670 By the logic above, any name will hang off some public key. The job 1671 is then to increase the lifetime of that public key. Once a key 1672 lifetime exceeds the expected lifetime of any authorization granted 1673 through it, then a succession of new, long-lifetime keys can cover a 1674 keyholder forever. 1676 For a key to have a long lifetime, it needs to be strong against 1677 cryptanalytic attack and against theft. It should be used only on a 1678 trusted machine, running trusted software. It should not be used on 1679 an on-line machine. It should be used very rarely, so that the 1680 attacker has few opportunities to find the key in the clear where it 1681 can be stolen. 1683 Different entities will approach this set of requirements in 1684 different ways. A private individual, making his own naming root key 1685 for this purpose, has the advantage of being too small to invite a 1686 well funded attack as compared to the attacks a commercial CA might 1687 face. 1689 7.5 One Root Per Individual 1691 In the limit, one can have one highly protected naming root key for 1692 each individual. One might have more than one such key per 1693 individual, in order to frustrate attempts to build dossiers, but let 1694 us assume only one key for the immediate discussion. 1696 If there is only one name descending from such a key, then one can 1697 dispense with the name. Authorizations can be assigned to the key 1698 itself, in raw SPKI style, rather than to some name defined under 1699 that key. There is no loss of lifetime -- only a change in the 1700 subject of the certificate the authorizing key uses to delegate 1701 authority. 1703 However, there is one significant difference, under the SPKI 1704 structure. If one delegates some authorization to 1706 (name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) carl) 1708 and a different authorization to 1710 (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) 1712 directly, both without granting the permission to delegate, that key 1713 can delegate at will through certificates in the former 1714 case and not delegate at all in the latter case. 1716 In the case of key management, we desire the ability to delegate from 1717 a long lived, rarely used key to a shorter lived, often used key -- 1718 so in this case, the former mechanism (through a SDSI name) gives 1719 more freedom. 1721 7.6 Key Revocation Service 1723 In either of the models above, key |TLCgPLFlGTzgUbcaYLW8kGTEnUk=| 1724 will issue a certificate. In the first model, it will be a 1725 certificate. In the second, it will be an authorization 1726 certificate delegating all rights through to the more temporary key. 1728 Either of those certificates might want an on-line validity test. 1729 Whether this test is in the form of a CRL, a re-validation or a one- 1730 time test, it will be supplied by some entity that is on-line. 1732 As the world moves to having all machines on-line all the time, this 1733 might be the user's machine. However, until then -- and maybe even 1734 after then -- the user might want to hire some service to perform 1735 this function. That service could run a 24x7 manned desk, to receive 1736 phone calls reporting loss of a key. That authority would not have 1737 the power to generate a new key for the user, only to revoke a 1738 current one. 1740 If, in the worst case, a user loses his master key, then the same 1741 process that occurs today with lost wallets would apply. All issuers 1742 of authorizations through that master key would need to issue new 1743 authorizations through the new master key and, if the old master key 1744 had been stolen, cancel all old authorizations through that key. 1746 7.7 Threshold ACL Subjects 1748 One can take extraordinary measures to protect root keys and thus 1749 increase the lifetimes of those keys. The study of computer fault- 1750 tolerance teaches us that truly long lifetimes can be achieved only 1751 by redundancy and replacement. Both can be achieved by the use of 1752 threshold subjects [section 6.3.3], especially in ACL entries. 1754 If we use a threshold subject in place of a single key subject, in an 1755 ACL (or a certificate), then we achieve redundancy immediately. This 1756 can be redundancy not only of keys but also of algorithms. That is, 1757 the keys in a threshold subject do not need to have the same 1758 algorithm. 1760 Truly long lifetimes come from replacement, not just redundancy. As 1761 soon as a component fails (or a key is assumed compromised), it must 1762 be replaced. 1764 An ACL needs to be access-controlled itself. Assume that the ACL 1765 includes an entry with authorization 1767 (tag (acl-edit)) 1769 Assume also that what might have been a single root authorization 1770 key, K1, is actually a threshold subject 1772 (k-of-n #03# #07# K1 K2 K3 K4 K5 K6 K7) 1774 used in any ACL entry granting a normal authorization. 1776 That same ACL could have the subject of an (acl-edit) entry be 1778 (k-of-n #05# #07# K1 K2 K3 K4 K5 K6 K7) 1780 This use of threshold subject would allow the set of root keys to 1781 elect new members to that set and retire old members. In this 1782 manner, replacement is achieved alongside redundancy and the proper 1783 choice of K and N should allow threshold subject key lifetimes 1784 approaching infinity. 1786 8. Security Considerations 1788 There are three classes of information that can be bound together by 1789 public key certificates: key, name and authorization. There are 1790 therefore three general kinds of certificate, depending on what pair 1791 of items the certificate ties together. If one considers the 1792 direction of mapping between items, there are six classes: name->key, 1793 key->name, authorization->name, name->authorization, 1794 authorization->key, key->authorization. 1796 The SPKI working group concluded that the most important use for 1797 certificates was access control. Given the various kinds of mapping 1798 possible, there are at least two ways to implement access control. 1799 One can use a straight authorization certificate: 1801 (authorization->key) 1803 or one can use an attribute certificate and an ID certificate: 1805 (authorization->name) + (name->key) 1807 There are at least two ways in which the former is more secure than 1808 the latter. 1810 1. Each certificate has an issuer. If that issuer is subverted, 1811 then the attacker can gain access. In the former case, there is 1812 only one issuer to trust. In the latter case, there are two. 1814 2. In the second case, linkage between the certificates is by name. 1815 If the name space of the issuer of the ID certificate is 1816 different from the name space of the issuer of the attribute 1817 certificate, then one of the two issuers must use a foreign name 1818 space. The process of choosing the appropriate name from a 1819 foreign name space is more complex than string matching and 1820 might even involve a human guess. It is subject to mistakes. 1821 Such a mistake can be made by accident or be guided by an 1822 attacker. 1824 This is not to say that one must never use the second construct. If 1825 the two certificates come from the same issuer, and therefore with 1826 the same name space, then both of the security differentiators above 1827 are canceled. 1829 References 1831 [Ab97] Abadi, Martin, "On SDSI's Linked Local Name Spaces", 1832 Proceedings of the 10th IEEE Computer Security Foundations Workshop 1833 (June 1997). 1835 [BFL] Matt Blaze, Joan Feigenbaum and Jack Lacy, "Distributed Trust 1836 Management", Proceedings 1996 IEEE Symposium on Security and Privacy. 1838 [CHAUM] D. Chaum, "Blind Signatures for Untraceable Payments", 1839 Advances in Cryptology -- CRYPTO '82, 1983. 1841 [DH] Whitfield Diffie and Martin Hellman, "New Directions in 1842 Cryptography", IEEE Transactions on Information Theory, November 1843 1976, pp. 644-654 1845 [DvH] J. B. Dennis and E. C. Van Horn, "Programming Semantics for 1846 Multiprogrammed Computations", Communications of the ACM 9(3), March 1847 1966 1849 [ECR] Silvio Micali, "Efficient Certificate Revocation", manuscript, 1850 MIT LCS. 1852 [ELIEN] Jean-Emile Elien, "Certificate Discovery Using SPKI/SDSI 2.0 1853 Certificates", Masters Thesis, MIT LCS, May 1998, 1854 [also .pdf 1855 and 1857 [HARDY] Hardy, Norman, "THE KeyKOS Architecture", Operating Systems 1858 Review, v.19 n.4, October 1985. pp 8-25. 1860 [IDENT] Carl Ellison, "Establishing Identity Without Certification 1861 Authorities", USENIX Security Symposium, July 1996. 1863 [IWG] McConnell and Appel, ``Enabling Privacy, Commerce, Security and 1864 Public Safety in the Global Information Infrastructure'', report of 1865 the Interagency Working Group on Cryptography Policy, May 12, 1996; 1866 (quote from paragraph 5 of the Introduction) 1868 [KEYKOS] Bomberger, Alan, et al., "The KeyKOS(r) Nanokernel 1869 Architecture", Proceedings of the USENIX Workshop on Micro-Kernels 1870 and Other Kernel Architectures, USENIX Association, April 1992. pp 1871 95-112 (In addition, there are KeyKOS papers on the net available 1872 through ) 1874 [KOHNFELDER] Kohnfelder, Loren M., "Towards a Practical Public-key 1875 Cryptosystem", MIT S.B. Thesis, May. 1978. 1877 [LAMPSON] B. Lampson, M. Abadi, M. Burrows, and E. Wobber, 1878 "Authentication in distributed systems: Theory and practice", ACM 1879 Trans. Computer Systems 10, 4 (Nov. 1992), pp 265-310. 1881 [LANDAU] Landau, Charles, "Security in a Secure Capability-Based 1882 System", Operating Systems Review, Oct 1989 pp 2-4 1884 [LEVY] Henry M. Levy, "Capability-Based Computer Systems", Digital 1885 Press, 12 Crosby Dr., Bedford MA 01730, 1984 1887 [LINDEN] T. A. Linden, "Operating System Structures to Support 1888 Security and Reliable Software", Computing Surveys 8(4), December 1889 1976. 1891 [PKCS1] PKCS #1: RSA Encryption Standard, RSA Data Security, Inc., 3 1892 June 1991, Version 1.4. 1894 [PKLOGIN] David Kemp, "The Public Key Login Protocol", working draft, 1895 06/12/1996. 1897 [R98] R. Rivest, "Can We Eliminate Revocation Lists?", to appear in 1898 the Proceedings of Financial Cryptography 1998, 1899 . 1901 [RFC1114] S. Kent, J. Linn, "Privacy Enhancement for Internet 1902 Electronic Mail: Part II -- Certificate-Based Key Management", August 1903 1989. 1905 [RFC1321] R. Rivest, "The MD5 Message-Digest Algorithm", April 16 1906 1992. 1908 [RFC2045] N. Freed and N. Borenstein, "Multipurpose Internet Mail 1909 Extensions (MIME) Part One: Format of Internet Message Bodies", Dec 2 1910 1996. 1912 [RFC2046] N. Freed and N. Borenstein, "Multipurpose Internet Mail 1913 Extensions (MIME) Part Two: Media Types", Dec 2 1996. 1915 [RFC2047] K. Moore, "MIME (Multipurpose Internet Mail Extensions) 1916 Part Three: Message Header Extensions for Non-ASCII Text", Dec 2 1917 1996. 1919 [RFC2065] D. Eastlake and C. Kaufman, "Proposed Standard for DNS 1920 Security", Jan 1997. 1922 [RFC2104] H. Krawczyk, M. Bellare and R. Canetti, "HMAC: Keyed- 1923 Hashing for Message Authentication", Feb 1997. 1925 [SDSI] Ron Rivest and Butler Lampson, "SDSI - A Simple Distributed 1926 Security Infrastructure [SDSI]", 1927 . 1929 [SET] Secure Electronic Transactions -- a protocol designed by VISA, 1930 MasterCard and others, including a certificate structure covering all 1931 participants. See . 1933 [SEXP] Ron Rivest, code and description of S-expressions, 1934 . 1936 [SRC-070] Abadi, Burrows, Lampson and Plotkin, "A Calculus for Access 1937 Control in Distributed Systems", DEC SRC-070, revised August 28, 1938 1991. 1940 [UPKI] C. Ellison, "The nature of a useable PKI", Computer Networks 1941 31 (1999) pp. 823-830. 1943 [WEBSTER] "Webster's Ninth New Collegiate Dictionary", Merriam- 1944 Webster, Inc., 1991. 1946 Acknowledgments 1948 Several independent contributions, published elsewhere on the net or 1949 in print, worked in synergy with our effort. Especially important to 1950 our work were: [SDSI], [BFL] and [RFC2065]. The inspiration we 1951 received from the notion of CAPABILITY in its various forms (SDS-940, 1952 Kerberos, DEC DSSA, [SRC-070], KeyKOS [HARDY]) can not be over-rated. 1954 Significant contributions to this effort by the members of the SPKI 1955 mailing list and especially the following persons (listed in 1956 alphabetic order) are gratefully acknowledged: Steve Bellovin, Mark 1957 Feldman, John Gilmore, Phill Hallam-Baker, Bob Jueneman, David Kemp, 1958 Angelos D. Keromytis, Paul Lambert, Jon Lasser, Jeff Parrett, Bill 1959 Sommerfeld, Simon Spero. 1961 Authors' Addresses 1963 Carl M. Ellison 1964 Intel Corporation 1965 2111 NE 25th Ave M/S JF3-373 1966 Hillsboro OR 97124-5961 USA 1968 Telephone: +1-503-264-2900 1969 FAX: +1-503-264-6225 1970 EMail: carl.m.ellison@intel.com (work, Outlook) 1971 cme@jf.intel.com (work, Eudora) 1972 cme@alum.mit.edu, cme@acm.org (home, Eudora) 1973 Web: http://www.pobox.com/~cme 1975 Bill Frantz 1976 Electric Communities 1977 10101 De Anza Blvd. 1978 Cupertino CA 95014 1980 Telephone: +1 408-342-9576 1981 Email: frantz@netcom.com 1983 Butler Lampson 1984 Microsoft 1985 180 Lake View Ave 1986 Cambridge MA 02138 1988 Telephone: +1 617-547-9580 (voice + FAX) 1989 EMail: blampson@microsoft.com 1990 Ron Rivest 1991 Room 324, MIT Laboratory for Computer Science 1992 545 Technology Square 1993 Cambridge MA 02139 1995 Telephone: +1-617-253-5880 1996 +1-617-258-9738(FAX) 1997 Email: rivest@theory.lcs.mit.edu 1998 Web: http://theory.lcs.mit.edu/~rivest 2000 Brian Thomas 2001 Southwestern Bell 2002 One Bell Center, Room 23Q1 2003 St. Louis MO 63101 USA 2005 Telephone: +1 314-235-3141 2006 +1 314-331-2755(FAX) 2007 EMail: bt0008@entropy.sbc.com 2009 Tatu Ylonen 2010 SSH Communications Security Ltd. 2011 Tekniikantie 12 2012 FIN-02150 ESPOO 2013 Finland 2015 E-mail: ylo@ssh.fi 2017 Expiration and File Name 2019 This draft expires 3 December 1999. 2021 Its file name is draft-ietf-spki-cert-theory-06.txt