idnits 2.17.1 draft-ietf-spki-cert-theory-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 6 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (24 October 1998) is 9288 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 322, but not defined == Unused Reference: 'Ab97' is defined on line 1631, but no explicit reference was found in the text == Unused Reference: 'CHAUM' is defined on line 1638, but no explicit reference was found in the text == Unused Reference: 'DvH' is defined on line 1645, but no explicit reference was found in the text == Unused Reference: 'IDENT' is defined on line 1655, but no explicit reference was found in the text == Unused Reference: 'IWG' is defined on line 1658, but no explicit reference was found in the text == Unused Reference: 'KEYKOS' is defined on line 1663, but no explicit reference was found in the text == Unused Reference: 'LAMPSON' is defined on line 1672, but no explicit reference was found in the text == Unused Reference: 'LANDAU' is defined on line 1676, but no explicit reference was found in the text == Unused Reference: 'LEVY' is defined on line 1679, but no explicit reference was found in the text == Unused Reference: 'LINDEN' is defined on line 1682, but no explicit reference was found in the text == Unused Reference: 'PKCS1' is defined on line 1686, but no explicit reference was found in the text == Unused Reference: 'PKLOGIN' is defined on line 1689, but no explicit reference was found in the text == Unused Reference: 'RFC1321' is defined on line 1700, but no explicit reference was found in the text == Unused Reference: 'RFC2045' is defined on line 1703, but no explicit reference was found in the text == Unused Reference: 'RFC2046' is defined on line 1707, but no explicit reference was found in the text == Unused Reference: 'RFC2047' is defined on line 1710, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 1717, but no explicit reference was found in the text == Unused Reference: 'SET' is defined on line 1724, but no explicit reference was found in the text == Unused Reference: 'SEXP' is defined on line 1728, but no explicit reference was found in the text == Unused Reference: 'WEBSTER' is defined on line 1735, 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. '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. 'WEBSTER' Summary: 12 errors (**), 0 flaws (~~), 23 warnings (==), 25 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPKI Certificate Theory Carl M. Ellison 3 INTERNET-DRAFT Intel 4 Expires: 29 April 1999 5 Bill Frantz 6 Electric Communities 8 Butler Lampson 9 Microsoft 11 Ron Rivest 12 MIT Laboratory for Computer Science 14 Brian M. Thomas 15 Southwestern Bell 17 Tatu Ylonen 18 SSH 20 24 October 1998 22 SPKI Certificate Theory 23 ---- ----------- ------ 25 27 Status of This Document 29 This draft supersedes the draft filed under the name draft-ietf-spki- 30 cert-theory-02.txt. It has been completely rewritten from that 31 previous version. 33 This document is one of four. SPKI structure definitions are to be 34 found in draft-ietf-spki-cert-structure-*.txt and examples of 35 certificate uses are to be found in draft-ietf-spki-cert- 36 examples-*.txt. This work derives from the requirements gathered at 37 the beginning of the working group and documented in draft-ietf-spki- 38 cert-req-*.txt. 40 Distribution of this document is unlimited. Comments should be sent 41 to the SPKI (Simple Public Key Infrastructure) Working Group mailing 42 list or to the authors. 44 This document is an Internet-Draft. Internet-Drafts are working 45 documents of the Internet Engineering Task Force (IETF), its areas, 46 and its working groups. Note that other groups may also distribute 47 working documents as Internet-Drafts. 49 Internet-Drafts are draft documents valid for a maximum of six 50 months. Internet-Drafts may be updated, replaced, or obsoleted by 51 other documents at any time. It is not appropriate to use Internet- 52 Drafts as reference material or to cite them other than as a 53 ``working draft'' or ``work in progress.'' 55 To learn the current status of any Internet-Draft, please check the 56 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 57 Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), 58 nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), 59 munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). 61 Abstract 63 The SPKI Working Group has developed a standard form for digital 64 certificates whose main purpose is authorization rather than 65 authentication. These structures bind either names or explicit 66 authorizations to keys or other objects. The binding to a key can be 67 directly to an explicit key, or indirectly through the hash of the 68 key or a name for it. The name and authorization structures can be 69 used separately or together. We use S-expressions as the standard 70 format for these certificates and define a canonical form for those 71 S-expressions. As part of this development, a mechanism for deriving 72 authorization decisions from a mixture of certificate types was 73 developed and is presented in this document. 75 This document gives the theory behind SPKI certificates and ACLs 76 without going into technical detail about those structures or their 77 uses. 79 Table of Contents 81 Status of This Document....................................1 83 Abstract...................................................3 85 Table of Contents..........................................4 87 1. Overview of Contents....................................6 88 1.1 Glossary...............................................6 90 2. Name Certification......................................8 91 2.1 First Definition of CERTIFICATE........................8 92 2.2 The X.500 Plan and X.509...............................9 93 2.3 X.509, PEM and PGP.....................................9 94 2.4 Rethinking Global Names...............................10 95 2.5 Inescapable Identifiers...............................11 96 2.6 Local Names...........................................12 97 2.6.1 Basic SDSI Names....................................12 98 2.6.2 Compound SDSI Names.................................13 99 2.7 Sources of Global Identifiers.........................13 100 2.8 Fully Qualified SDSI Names............................14 101 2.9 Fully Qualified X.509 Names...........................14 102 2.10 Group Names..........................................15 104 3. Authorization..........................................16 105 3.1 Attribute Certificates................................16 106 3.2 X.509v3 Extensions....................................16 107 3.3 SPKI Certificates.....................................17 108 3.4 ACL Entries...........................................18 110 4. Delegation.............................................19 111 4.1 Depth of Delegation...................................19 112 4.1.1 No control..........................................19 113 4.1.2 Boolean control.....................................19 114 4.1.3 Integer control.....................................20 115 4.1.4 The choice: boolean.................................20 116 4.2 May a Delegator Also Exercise the Permission?.........20 117 4.3 Delegation of Authorization vs. ACLs..................20 119 5. Validity Conditions....................................22 120 5.1 Anti-matter CRLs......................................22 121 5.2 Timed CRLs............................................23 122 5.3 Timed Revalidations...................................23 123 5.4 Setting the Validity Interval.........................23 124 5.5 One-time Revalidations................................24 125 5.6 Short-lived Certificates..............................24 126 5.7 Other possibilities...................................24 127 5.7.1 Micali's Inexpensive On-line Results................25 128 5.7.2 Rivest's Reversal of the CRL Logic..................25 130 6. Tuple Reduction........................................26 131 6.1 5-tuple Defined.......................................27 132 6.2 4-tuple Defined.......................................27 133 6.3 5-tuple Reduction Rules...............................28 134 6.3.1 AIntersect..........................................28 135 6.3.2 VIntersect..........................................30 136 6.3.3 Threshold Subjects..................................30 137 6.3.4 Reduction Direction.................................31 138 6.3.5 5-tuple Reduction Infinite Loops....................32 139 6.4 4-tuple Reduction.....................................32 140 6.5 Certificate Translation...............................33 141 6.5.1 X.509v1.............................................33 142 6.5.2 PGP.................................................34 143 6.5.3 X.509v3.............................................34 144 6.5.4 X9.57...............................................34 145 6.5.5 SDSI................................................34 146 6.5.6 SPKI................................................35 147 6.6 Implicit Authorizations...............................35 149 7. Key Management.........................................36 150 7.1 Through Inescapable Names.............................36 151 7.2 Through a Naming Authority............................36 152 7.3 Through Certificates.......................37 153 7.4 Increasing Key Lifetimes..............................37 154 7.5 One Root Per Individual...............................38 155 7.6 Key Revocation Service................................38 157 8. Security Considerations................................40 159 References................................................41 161 Acknowledgments...........................................44 162 Authors' Addresses........................................44 163 Expiration and File Name..................................45 165 1. Overview of Contents 167 This document contains the following sections: 169 Section 2: history of name certification, from 1976 on. 171 Section 3: discussion of authorization, rather than authentication, 172 as the desired purpose of a certificate. 174 Section 4: discussion of delegation. 176 Section 5: discussion of validity conditions: date ranges, CRLs, re- 177 validations and one-time on-line validity tests. 179 Section 6: definition of 5-tuples and their reduction. 181 Section 7: discussion of key management. 183 Section 8: security considerations. 185 The References section lists all documents referred to in the text as 186 well as readings which might be of interest to anyone reading on this 187 topic. 189 The Acknowledgements section, listing contributors primarily at the 190 start of the working group. This section has not been augmented in 191 many months. The archive of working group mail is a more accurate 192 source of such information. 194 The Authors' Addresses section gives the addresses, telephone numbers 195 and e-mail addresses of the authors. 197 1.1 Glossary 199 We use some terms in the body of this document in ways that could be 200 specific to SPKI: 202 ACL: a list of entries that anchors a certificate chain. Sometimes 203 called a "list of root keys", the ACL is the source of empowerment 204 for certificates. That is, a certificate communicates power from its 205 issuer to its subject, but the ACL is the source that power (since it 206 theoretically has the owner of the resource being controlled as its 207 implicit issuer). An ACL entry has potentially the same content as a 208 certificate body, but has no Issuer (and is not signed). There is 209 most likely one ACL for each resource owner, if not for each 210 controlled resource. 212 CERTIFICATE: a signed instrument that empowers the Subject. It 213 contains at least an Issuer and a Subject. It can contain validity 214 conditions, authorization and delegation information. Certificates 215 come in three categories: ID (mapping ), Attribute (mapping 216 ), and Authorization (mapping 217 ). An SPKI authorization or attribute certificate 218 can pass along all the empowerment it has received from the Issuer or 219 it can pass along only a portion of that empowerment. 221 ISSUER: the signer of a certificate and the source of empowerment 222 that the certificate is communicating to the Subject. 224 KEYHOLDER: the person or other entity that owns and controls a given 225 private key. This entity is said to be the keyholder of the keypair 226 or just the public key, but control of the private key is assumed in 227 all cases. 229 PRINCIPAL: a cryptographic key, capable of generating a digital 230 signature. We deal with public-key signatures in this document but 231 any digital signature method should apply. 233 SPEAKING: A Principal is said to "speak" by means of a digital 234 signature. The statement made is the signed object (often a 235 certificate). The Principal is said to "speak for" the Keyholder. 237 SUBJECT: the thing empowered by a certificate or ACL entry. This can 238 be in the form of a key, a name (with the understanding that the name 239 is mapped by certificate to some key or other object), a hash of some 240 object, or a set of keys arranged in a threshold function. 242 S-EXPRESSION: the data format chosen for SPKI/SDSI. This is a LISP- 243 like parenthesized expression with the limitations that empty lists 244 are not allowed and the first element in any S-expression must be a 245 string, called the "type" of the expression. 247 THRESHOLD SUBJECT: a Subject for an ACL entry or certificate that 248 specifies K of N other Subjects. Conceptually, the power being 249 transmitted to the Subject by the ACL entry or certificate is 250 transmitted in (1/K) amount to each listed subordinate Subject. K of 251 those subordinate Subjects must agree (by passing their shares along 252 to the same object or key) for that power to be passed along. This 253 mechanism introduces fault tolerance and is especially useful in an 254 ACL entry, providing fault tolerance for "root keys". 256 2. Name Certification 258 Certificates were originally viewed as having one function: binding 259 names to keys or keys to names. This thought can be traced back to 260 the paper by Diffie and Hellman introducing public key cryptography 261 in 1976. Prior to that time, key management was risky, involved and 262 costly, sometimes employing special couriers with briefcases 263 handcuffed to their wrists. 265 Diffie and Hellman thought they had radically solved this problem. 266 "Given a system of this kind, the problem of key distribution is 267 vastly simplified. Each user generates a pair of inverse 268 transformations, E and D, at his terminal. The deciphering 269 transformation, D, must be kept secret but need never be communicated 270 on any channel. The enciphering key, E, can be made public by 271 placing it in a public directory along with the user's name and 272 address. Anyone can then encrypt messages and send them to the user, 273 but no one else can decipher messages intended for him." [DH] 275 This modified telephone book, fully public, took the place of the 276 trusted courier. This directory could be put on-line and therefore 277 be available on demand, worldwide. In considering that prospect, 278 Loren Kohnfelder, in his 1978 bachelor's thesis in electrical 279 engineering from MIT [KOHNFELDER], noted: "Public-key communication 280 works best when the encryption functions can reliably be shared among 281 the communicants (by direct contact if possible). Yet when such a 282 reliable exchange of functions is impossible the next best thing is 283 to trust a third party. Diffie and Hellman introduce a central 284 authority known as the Public File." 286 2.1 First Definition of CERTIFICATE 288 Kohnfelder then noted, "Each individual has a name in the system by 289 which he is referenced in the Public File. Once two communicants 290 have gotten each other's keys from the Public File they can securely 291 communicate. The Public File digitally signs all of its 292 transmissions so that enemy impersonation of the Public File is 293 precluded." In an effort to prevent performance problems, Kohnfelder 294 invented a new construct: a digitally signed data record containing a 295 name and a public key. He called this new construct a CERTIFICATE. 296 Because it was digitally signed, such a certificate could be held by 297 non-trusted parties and passed around from person to person, 298 resolving the performance problems involved in a central directory. 300 2.2 The X.500 Plan and X.509 302 Ten years after Kohnfelder's thesis, the ISO X.509 recommendation was 303 published as part of X.500. X.500 was to be a global, distributed 304 database of named entities: people, computers, printers, etc. In 305 other words, it was to be a global, on-line telephone book. The 306 organizations owning some portion of the name space would maintain 307 that portion and possibly even provide the computers on which it was 308 stored. X.509 certificates were defined to bind public keys to X.500 309 path names (Distinguished Names) with the intention of noting which 310 keyholder had permission to modify which X.500 directory nodes. 312 The original X.500 plan is unlikely ever to come to fruition. 313 Collections of directory entries (such as employee lists, customer 314 lists, contact lists, etc.) are considered valuable or even 315 confidential by those owning the lists and are not likely to be 316 released to the world in the form of an X.500 directory sub-tree. 317 For an extreme example, imagine the CIA adding its directory of 318 agents to a world-wide X.500 pool. 320 2.3 X.509, PEM and PGP 322 The Privacy Enhanced Mail [PEM] effort of the Internet Engineering 323 Task Force [RFC1114] adopted X.509 certificates, but with a different 324 interpretation. Where X.509 was originally intended to mean "the 325 keyholder may modify this portion of the X.500 database", PEM took 326 the certificate to mean "the key speaks for the named person". What 327 had been an access control instrument was now an identity instrument, 328 along the lines envisioned by Diffie, Hellman and Kohnfelder. 330 The insistence on X.509 certificates with a single global root 331 delayed PEM's adoption past its window of viability. RIPEM, by Mark 332 Riordan of MSU, was a version of PEM without X.509 certificates. It 333 was distributed and used by a small community, but fell into disuse. 334 MOSS (a MIME-enhanced version of PEM, produced by TIS (www.tis.com)) 335 made certificate use optional, but received little distribution. 337 At about the same time, in 1991, Phil Zimmermann's PGP was introduced 338 with a different certificate model. Instead of waiting for a single 339 global root and the hierarchy of Certificate Authorities descending 340 from that root, PGP allowed multiple, (hopefully) independent but not 341 specially trusted individuals to sign a association, 342 attesting to its validity. The theory was that with enough such 343 signatures, that association could be trusted. This was known as the 344 "web of trust" model. It differed from X.509 in the method of 345 assuring trust in the binding, but it still intended to 346 bind a globally unique name to a key. With PEM and PGP, the 347 intention was for a keyholder to be known to anyone in the world by 348 this certified global name. 350 2.4 Rethinking Global Names 352 The assumption that the job of a certificate was to bind a name to a 353 key made sense when it was first published. In the 1970's, people 354 operated in relatively small communities. Relationships formed face 355 to face. Once you knew who someone was, you often knew enough to 356 decide how to behave with that person. As a result, people have 357 reduced this requirement to the simply stated: "know who you're 358 dealing with". 360 Names, in turn, are what we humans use as identifiers of persons. 361 Therefore, it was natural for people to translate the need to know 362 who the keyholder was into a need to know the keyholder's name. 364 Computer applications need to make decisions about keyholders. These 365 decisions are almost never made strictly on the basis of a 366 keyholder's name. There is some other fact about the keyholder of 367 interest to the application (or to the human being running the 368 application). If a name functions at all, it is as an index into 369 some database (or human memory) of that other information. 371 The assumption that names are valid identifiers remains true in much 372 of daily life, but is not true on a global scale. It is extremely 373 unlikely that the name by which we know someone, a given name, would 374 function as a unique identifier on the Internet. Given names 375 continue to serve the social function of making the named person feel 376 better when addressed by name, but they are almost never globally 377 unique. Therefore they are inadequate as the identifiers envisioned 378 by Diffie, Hellman and Kohnfelder. 380 In the 1970's and even through the early 1990's, relationships formed 381 in person and one could assume having met the keyholder and therefore 382 having acquired knowledge about that person. If a name could be 383 found that was an adequate identifier of that keyholder, then one 384 might use that name to index into memories about the keyholder and 385 then be able to make the relevant decision. 387 In the late 1990's, this is no longer true. With the explosion of 388 the Internet, it is likely that one will encounter keyholders who are 389 complete strangers in the physical world and will remain so. Contact 390 will be made digitally and will remain digital for the duration of 391 the relationship. In that case, a globally unique name would not 392 succeed in accessing information about a person encountered for the 393 first time on the net because there is no physical-world relationship 394 giving information to be accessed and there is no digital 395 relationship yet established through which cyberspace information can 396 be gathered. 398 One might remedy this situation by assigning everyone a globally 399 unique and unchangeable name and then using that name to index a 400 global database of facts about the person. This might bring us back 401 to the mode of operation we were accustomed to in small towns. 402 However, that solution would constitute a massive privacy violation 403 and would probably be rejected as politically impossible. 405 A globally unique ID might even fail when dealing with people we do 406 know. Few of us know the full given names of people with whom we 407 deal. A globally unique name for a person would be larger than the 408 full given name (and probably contain it, out of deference to a 409 person's fondness for his or her own name). It would therefore not 410 be a name by which we know the person, barring a radical change in 411 human behavior. 413 A globally unique ID that contains a person's given name poses a 414 special danger. If a human being is part of the process (e.g., 415 scanning a database of global IDs in order to find the ID of a 416 specific person for the purpose of issuing an attribute certificate), 417 then it is likely that the human operator would pay attention to the 418 familiar portion of the ID (the common name) and pay less attention 419 to the rest. Since the common name is not an adequate ID, this can 420 lead to mistakes. Where there can be mistakes, there is an avenue 421 for attack. 423 Perhaps the best globally unique identifier is one that is uniform in 424 appearance (such as a long number or random looking text string) so 425 that it has no recognizable sub-field. It should also be large 426 enough (from a sparse enough name space) that typographical errors 427 would not yield another valid identifier. 429 2.5 Inescapable Identifiers 431 Some people speak of global IDs as if they were inescapable 432 identifiers, able to prevent someone from doing evil under one name, 433 changing his name and starting over again. To make that scenario 434 come true, one would have to have assignment of such identifiers 435 (probably by governments, at birth) and some mechanism so that it is 436 always possible to get from any flesh and blood person back to his or 437 her identifier. Given that latter mechanism, any Certificate 438 Authority desiring to issue a certificate to a given individual would 439 presumably choose the same, inescapable name for that certificate. A 440 full set of biometrics might suffice, for example, to look up a 441 person without danger of false positive in a database of globally 442 assigned ID numbers and with that procedure one could implement 443 inescapable IDs. 445 Such an inescapable identifier would be a great boon to a police 446 state and for that reason alone one can expect it to be defeated 447 politically in one way or another. In the US, this falls under the 448 category of a national ID card or national ID number and has been 449 strongly opposed politically. In some countries that do have 450 national ID numbers, there are laws against being required to 451 disclose those numbers except for official government purposes. In 452 those countries, such a number would uniquely identify a person but 453 not become universally used. In particular, it would not be 454 available for use in certificates. 456 There was a concern that commercial Certificate Authorities might 457 have been used to bring inescapable names into existence, bypassing 458 the political process and the opposition to such names. As the 459 (name,key) certificate business is evolving today, there are multiple 460 competing CAs each creating disjoint Distinguished Name spaces. 461 There is also no real block to the creation of new CAs. Therefore a 462 person is able to drop one Distinguished Name and get another, by 463 changing CA, making these names not inescapable. 465 2.6 Local Names 467 Globally unique names may be politically undesirable and relatively 468 useless, in the world of the Internet, but we use names all the time. 470 The names we use are local names. These are the names we write in 471 our personal address books or use as nicknames with e-mail agents. 472 They can be IDs assigned by corporations (e.g., bank account numbers 473 or employee numbers). Those names or IDs do not need to be globally 474 unique. Rather, they need to be unique for the one entity that 475 maintains that address book, e-mail alias file or list of accounts. 477 Ron Rivest and Butler Lampson showed with SDSI 1.0 [SDSI] that one 478 can not only use local names locally, one can use local names 479 globally. The clear security advantage and operational simplicity of 480 SDSI names caused us in the SPKI group to adopt SDSI names as part of 481 the SPKI standard. 483 2.6.1 Basic SDSI Names 485 A basic SDSI 2.0 name is an S-expression with two elements: the word 486 "name" and the chosen name. For example, 488 (name fred) // george 490 is a basic SDSI name, where the comment indicates that the name is in 491 the name space defined by george. 493 2.6.2 Compound SDSI Names 495 If fred in turn defines a name, for example, 497 (name sam) // fred 499 then one can refer to this same entity as 501 (name fred sam) // george 503 relative to george's name space (assuming the definition in 2.6.1). 505 2.7 Sources of Global Identifiers 507 Even though humans use local names, computer systems often need 508 globally unique identifiers. 510 If we are using public key cryptography, we have a ready source of 511 globally unique identifiers. 513 When one creates a key pair, for use in public key cryptography, the 514 private key is bound to its owner by good key safeguarding practice. 515 If that private key gets loose from its owner, then a basic premise 516 of public key cryptography has been violated and that key is no 517 longer of interest. 519 The private key is also globally unique. If it were not, then the 520 key generation process would be seriously flawed and we would have to 521 abandon this public key system implementation. 523 The private key must be kept secret, so it is not a possible 524 identifier, but each public key corresponds to one private key and 525 therefore to one keyholder. The public key, viewed as a byte string, 526 is therefore an identifier for the keyholder. 528 If there exists a collision-free hash function, then a collision-free 529 hash of the public key is also a globally unique identifier for the 530 keyholder, and probably a shorter one than the public key. 532 2.8 Fully Qualified SDSI Names 534 SDSI local names are of great value to their definer. Each local 535 name maps to one or more public keys and therefore to the 536 corresponding keyholder(s). Through SDSI's name chaining, these 537 local names become useful potentially to the whole world. [See 538 section 2.6.2 for an example of SDSI name chaining.] 540 To a computer system making use of these names, the name string is 541 not enough. One must identify the name space in which that byte 542 string is defined. That name space can be identified globally by a 543 public key. 545 It is SDSI 1.0 convention, preserved in SPKI, that if a relative SDSI 546 name occurs within a certificate, then the public key of the issuer 547 is the identifier of the name space in which that name is defined. 549 However, if a SDSI name is ever to occur outside of a certificate, 550 the name space within which it is defined must be identified. This 551 gives rise to the Fully Qualified SDSI Name. That name is a public 552 key followed by one or more names relative to that key. If there are 553 two or more names, then the string of names is a SDSI name chain. 554 For example, 556 (name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) jim therese) 558 is a fully qualified SDSI name, using the SHA-1 hash of a public key 559 as the global identifier defining the name space and anchoring this 560 name string. 562 2.9 Fully Qualified X.509 Names 564 An X.509 Distinguished Name can and sometimes must be expressed as a 565 Fully Qualified Name. If the PEM or original X.500 vision of a 566 single root for a global name space had come true, this wouldn't be 567 necessary because all names would be relative to that same one root 568 key. However, there is not a single root key and is not likely ever 569 to be a single root key. Therefore, every X.509 name should be 570 expressed as the pair 572 (name ) 574 if all leaf names descending from that root are unique. If 575 uniqueness is enforced only within each individual CA, then one would 576 build a Fully Qualified Name chain from an X.509 certificate chain, 577 yielding the form 579 (name ... ). 581 2.10 Group Names 583 SPKI/SDSI does not claim to enforce one key per name. Therefore, a 584 named group can be defined by issuing multiple (name,key) 585 certificates with the same name -- one for each group member. 587 3. Authorization 589 Fully qualified SDSI names represent globally unique names, but at 590 every step of their construction the local name used is presumably 591 meaningful to the issuer. Therefore, with SDSI name certificates one 592 can identify the keyholder by some name relevant to someone. 594 However, what an application needs to do, when given a public key 595 certificate or a set of them, is answer the question of whether the 596 remote keyholder is permitted some access. That application must 597 make a decision. The data needed for that decision is almost never 598 the spelling of a keyholder's name. 600 Instead, the application needs to know if the keyholder is authorized 601 for some access. This is the primary job of a certificate, according 602 to the members of the SPKI WG, and the SPKI certificate was designed 603 to meet this need as simply and directly as possible. 605 We realize that the world is not going to switch to SPKI certificates 606 overnight. Therefore, we developed an authorization computation 607 process that can use certificates in any format. That process is 608 described below in section 6. 610 The various methods of establishing authorization are documented 611 below, briefly. 613 3.1 Attribute Certificates 615 An Attribute Certificate, as defined in X9.57, binds an attribute 616 that could be an authorization to a Distinguished Name. For an 617 application to use this information, it must combine an attribute 618 certificate with an ID certificate, in order to get the full mapping: 620 authorization -> name -> key 622 Presumably the two certificates involved came from different issuers, 623 one an authority on the authorization and the other an authority on 624 names. However, if either of these issuers were subverted, then an 625 attacker could obtain an authorization improperly. Therefore, both 626 the issuers need to be trusted with the authorization decision. 628 3.2 X.509v3 Extensions 630 X.509v3 permits general extensions. These extensions can be used to 631 carry authorization information. This makes the certificate an 632 instrument mapping both: 634 authorization -> key 636 and 638 name -> key 640 In this case, there is only one issuer, who must be an authority on 641 both the authorization and the name. 643 Some propose issuing a master X.509v3 certificate to an individual 644 and letting extensions hold all the attributes or authorizations the 645 individual would need. This would require the issuer to be an 646 authority on all of those authorizations. 648 As Steve Kent has observed, this aggregation of attributes would also 649 result in shortening the lifetime of the certificate, since each 650 attribute would have its own lifetime. 652 Finally, aggregation of attributes amounts to the building of a 653 dossier and represents a potential privacy violation. 655 For all of these reasons, it is desirable that authorizations be 656 limited to one per certificate. 658 3.3 SPKI Certificates 660 A basic SPKI certificate defines a straight authorization mapping: 662 authorization -> key 664 If someone wants access to a keyholder's name, for logging purposes 665 or even for punishment after wrong-doing, then one can map from key 666 to location information (name, address, phone, ...) to get: 668 authorization -> key -> name 670 This mapping has an apparent security advantage over the attribute 671 certificate mapping. In the mapping above, only the 673 authorization -> key 675 mapping needs to be secure at the level required for the access 676 control mechanism. The 678 key -> name 680 mapping (and the issuer of any certificates involved) needs to be 681 secure enough to satisfy lawyers or private investigators, but a 682 subversion of this mapping does not permit the attacker to defeat the 683 access control. Presumably, therefore, the care with which these 684 certificates (or database entries) are created is less critical than 685 the care with which the authorization certificate is issued. 687 3.4 ACL Entries 689 SDSI 1.0 defined an ACL, granting authorization to names. It was 690 then like an attribute certificate, except that it did not need to be 691 signed or issued by any key. It was held in local memory and was 692 assumed issued by the owner of the computer and therefore of the 693 resource being controlled. 695 In SPKI, an ACL entry is free to be implemented however the developer 696 chooses, since it is never communicated and therefore does not need 697 to be standardized. However, a sample implementation is documented, 698 as a certificate body minus the issuer field. The ACL entry can have 699 a name as a subject, as in SDSI 1.0, or it can have a key as a 700 subject. Examples of the latter include the list of SSL root keys in 701 an SSL capable browser or the file .ssh/authorized_keys in a user's 702 home UNIX directory. Those ACLs are single-purpose, so the 703 individual entries do not carry explicit authorizations. 705 4. Delegation 707 One of the powers of an authorization certificate is the ability to 708 delegate authorizations from one person to another without bothering 709 the owner of the resource(s) involved. One might issue a simple 710 permission (e.g., to read some file) or issue the permission to 711 delegate that permission further. 713 Two issues arose as we considered delegation: the desire to limit 714 depth of delegation and the question of separating delegators from 715 those who can exercise the delegated permission. 717 4.1 Depth of Delegation 719 There were three camps in discussing depth of delegation: no control, 720 boolean control and integer control. There remain camps in favor of 721 each of these, but a decision was reached in favor of boolean 722 control. 724 4.1.1 No control 726 The argument in favor of no control is that if a keyholder is given 727 permission to do something but not the permission to delegate it, 728 then it is possible for that keyholder to loan out the empowered 729 private key or to set up a proxy service, signing challenges or 730 requests for the intended delegate. Therefore, the attempt to 731 restrict the permission to delegate is ineffective and might back- 732 fire, by leading to improper security practices. 734 4.1.2 Boolean control 736 The argument in favor of boolean control is that one might need to 737 specify an inability to delegate. For example, one could imagine the 738 US Commerce Department having a key that is authorized to declare a 739 cryptographic software module exportable and also to delegate that 740 authorization to others (e.g., manufacturers). It is reasonable to 741 assume the Commerce Department would not issue permission to delegate 742 this further. That is, it would want to have a direct legal 743 agreement with each manufacturer and issue a certificate to that 744 manufacturer only to reflect that the legal agreement is in place. 746 4.1.3 Integer control 748 The argument in favor of integer control is that one might want to 749 restrict the depth of delegation in order to control the 750 proliferation of a delegated permission. 752 4.1.4 The choice: boolean 754 Of these three, the group chose boolean control. The subject of a 755 certificate or ACL entry may exercise any permission granted and, if 756 delegation is TRUE, may also delegate that permission or some subset 757 of it to others. 759 The no control argument has logical appeal, but there remains the 760 assumption that a user will value his or her private key enough not 761 to loan it out or that the key will be locked in hardware where it 762 can't be copied to any other user. This doesn't prevent the user 763 from setting up a signing oracle, but lack of network connectivity 764 might inhibit that mechanism. 766 The integer control option was the original design and has appeal, 767 but was defeated by the inability to predict the proper depth of 768 delegation. One can always need to go one more level down, by 769 creating a temporary signing key (e.g., for use in a laptop). 770 Therefore, the initially predicted depth could be significantly off. 771 As for controlling the proliferation of permissions, there is no 772 control on the width of the delegation tree, so control on its depth 773 is not a tight control on proliferation. 775 4.2 May a Delegator Also Exercise the Permission? 777 We decided that a delegator is free to create a new private key, also 778 controlled by it, and delegate the rights to that key to exercise the 779 delegated permission. Therefore, there was no benefit from 780 attempting to restrict the exercise of a permission by someone 781 permitted to delegate it. 783 4.3 Delegation of Authorization vs. ACLs 785 One concern with defining an authorization certificate is that the 786 function can be performed by traditional ACLs 787 and ID certificates defining groups. Such a mechanism was 788 described in SDSI 1.0. A new mechanism needs to add value or it just 789 complicates life for the developer. 791 The argument for delegated authorization as opposed to ACLs can be 792 seen in the following example. 794 Imagine a firewall proxy permitting telnet and ftp access from the 795 Internet into a network of US DoD machines. Because of the 796 sensitivity of that destination network, strong access control would 797 be desired. One could use public key authentication and public key 798 certificates to establish who the individual keyholder was. Both the 799 private key and the keyholder's certificates could be kept on a 800 Fortezza card. That card holds X.509v1 certificates, so all that can 801 be established is the name of the keyholder. It is then the job of 802 the firewall to keep an ACL, listing named keyholders and the forms 803 of access they are each permitted. 805 Consider the ACL itself. Not only would it be potentially huge, 806 demanding far more storage than the firewall would otherwise require, 807 but it would also need its own ACL. One could not, for example, have 808 someone in the Army have the power to decide whether someone in the 809 Navy got access. In fact, the ACL would probably need not one level 810 of its own ACL, but a nested set of ACLs, eventually reflecting the 811 organization structure of the entire Defense Department. 813 Without the ACLs, the firewall could be implemented in a device with 814 no mass storage, residing in a sealed unit one could easily hold in 815 one hand. With the ACLs, it would need a large mass storage device 816 that would be accessed not only while making access control decisions 817 but also for updating the ACLs. 819 By contrast, let the access be controlled by authorization 820 certificates. The firewall would have an ACL with one entry, 821 granting a key belonging to the Secretary of Defense the right to 822 delegate all access through the firewall. The Secretary would, in 823 turn, issue certificates delegating this permission to delegate to 824 each of his or her subordinates. This process would iterate, until 825 some enlisted man would receive permission to penetrate that firewall 826 for some specific one protocol, but not have permission to delegate 827 that permission. 829 The certificate structure generated would reflect the organization 830 structure of the entire Defense Department, just as the nested ACLs 831 would have, but the control of these certificates (via their issuance 832 and revocation) is distributed and need not show up in that one 833 firewall or be replicated in all firewalls. Each individual 834 delegator of permission performs a simple task, well understood. The 835 application software to allow that delegation is correspondingly 836 simple. 838 5. Validity Conditions 840 A certificate, or an ACL entry, has optional validity conditions. 841 The traditional ones are validity dates: not-before and not-after. 842 The SPKI group resolved, in discussion, that on-line tests of various 843 kinds are also validity conditions. That is, they further refine the 844 valid date range of a certificate. Three kinds of on-line tests are 845 envisioned: CRL, re-validation and one-time. 847 5.1 Anti-matter CRLs 849 An early form of CRL [Certificate Revocation List] was modeled after 850 the news print book that used to be kept at supermarket checkout 851 stands. Those books held lists of bad checking account numbers and, 852 later, bad credit card numbers. If one's payment instrument wasn't 853 listed in the book, then that instrument was considered good. 855 These books would be issued periodically, and delivered by some means 856 not necessarily taking a constant time. However, when a new book 857 arrived, the clerk would replace the older edition with the new one 858 and start using it. 860 An early CRL design followed this model. It had a list of revoked 861 certificate identifiers. It also had a sequence number, so that one 862 could tell whether the CRL was more recent than the one currently on 863 the virtual checkout stand. A newer CRL would replace an older one. 865 This mode of operation is like wandering anti-matter. When the 866 issuer wants to revoke a certificate, it is listed in the next CRL to 867 go out. If the revocation is urgent, then that CRL can be released 868 immediately. The CRL then follows some dissemination process 869 unrelated to the needs of the consumers of the CRL. If the CRL 870 encounters a certificate it has listed, it effectively annihilates 871 that certificate. If it encounters an older CRL, it annihilates that 872 CRL also, leaving a copy of itself at the verifier it has 873 encountered. 875 However, this process is non-deterministic. The result of the 876 authorization computation is at least timing dependent. Given an 877 active adversary, it can also be a security hole. That is, an 878 adversary can prevent revocation of a given certificate by preventing 879 the delivery of new CRLs. This does not require cryptographic level 880 effort, merely network tampering. 882 SPKI has ruled out the use of wandering anti-matter CRLs for its 883 certificates. Every authorization computation is deterministic, 884 under SPKI rules. 886 5.2 Timed CRLs 888 SPKI permits use of timed CRLs. That is, if a certificate can be 889 referenced in a CRL, then the CRL process is subject to three 890 conditions. 892 1. The certificate must list the key (or its hash) that will sign 893 the CRL and may give one or more locations where that CRL might 894 be fetched. 896 2. The CRL must carry validity dates. 898 3. CRL validity date ranges must not intersect. That is, one may 899 not issue a new CRL to take effect before the expiration of the 900 CRL currently deployed. 902 Under these rules, no certificate can be processed without a valid 903 CRL and no CRL can be issued to show up as a surprise at the 904 verifier. This yields a deterministic validity computation, 905 independent of clock skew, although clock inaccuracies in the 906 verifier may produce a result not desired by the issuer. 908 5.3 Timed Revalidations 910 CRLs are a negative statement. The positive version of this 911 statement is one we call a revalidation. Typically a revalidation 912 would list only one certificate (the one of interest), although it 913 might list a set of certificates (to save digital signature effort). 915 As with the CRL, SPKI demands that this process be deterministic and 916 therefore that the revalidation follow the same rules listed above 917 (in section 5.2). 919 5.4 Setting the Validity Interval 921 Both timed CRLs and timed revalidations have non-0 validity 922 intervals. To set this validity interval, one must answer the 923 question: "How long are you willing to let the world believe and act 924 on a statement you know to be false?" 926 That is, one must assume that the previous CRL or revalidation has 927 just been signed and transmitted to at least one consumer, locking up 928 a time slot. The next available time slot starts after this validity 929 interval ends. That is the earliest one can revoke a certificate one 930 learns to be false. 932 The answer to that question comes from risk management. It will 933 probably be based on expected monetary losses, at least in commercial 934 cases. 936 5.5 One-time Revalidations 938 Validity intervals of length zero are not possible. Since 939 transmission takes time, by the time a CRL was received by the 940 verifier, it would be out of date and unusable. That assumes perfect 941 clock synchronization. If clock skew is taken into consideration, 942 validity intervals need to be that much larger. 944 For those who want to set the validity interval to zero, SPKI defines 945 a one-time revalidation. 947 This form of revalidation has no lifetime beyond the current 948 authorization computation. One applies for this on-line, one-time 949 revalidation by submitting a request containing a nonce. That nonce 950 gets returned in the signed revalidation instrument, in order to 951 prevent replay attacks. This protocol takes the place of a validity 952 date range and represents a validity interval of zero, starting and 953 ending at the time the authorization computation completes. 955 5.6 Short-lived Certificates 957 If validity intervals are greater than zero, and if the on-line test 958 result is signed by the same key as the issuer of the certificate, 959 then it makes sense to issue short-lived certificates instead of a 960 long-lived certificate and a short-lived on-line test result. The 961 issuer ends up generating fewer signatures this way. 963 An on-line test result message might be smaller than a full 964 certificate, so communication costs might still encourage the 965 separation of these functions, but this is a decision that must be 966 made on a per-application and per-issuer basis. The decision will 967 almost certainly hinge on performance, since all of these options 968 have equivalent security semantics. 970 5.7 Other possibilities 972 There are other possibilities to be considered when choosing a 973 validity condition model to use. 975 5.7.1 Micali's Inexpensive On-line Results 977 Silvio Micali has patented a mechanism for using hash chains to 978 revalidate or revoke a certificate inexpensively. This mechanism 979 changes the performance requirements of those models and might 980 therefore change the conclusion from a performance analysis. [ECR] 982 5.7.2 Rivest's Reversal of the CRL Logic 984 Ron Rivest has written a paper [R98] suggesting that the whole 985 validity condition model is flawed because it assumes that the issuer 986 (or some entity to which it delegates this responsibility) decides 987 the conditions under which a certificate is valid. That traditional 988 model is consistent with a military key management model, in which 989 there is some central authority responsible for key release and for 990 determining key validity. 992 However, in the commercial space, it is the verifier and not the 993 issuer who is taking a risk by accepting a certificate. It should 994 therefore be the verifier who decides what level of assurance he 995 needs before accepting a credential. That verifier needs information 996 from the issuer, and the more recent that information the better, but 997 the decision is the verifier's in the end. 999 This line of thought deserves further consideration, but is not 1000 reflected in the SPKI structure definition. It might even be that 1001 both the issuer and the verifier have stakes in this decision, so 1002 that any replacement validity logic would have to include inputs from 1003 both. 1005 6. Tuple Reduction 1007 The processing of certificates and related objects to yield an 1008 authorization result is the province of the developer of the 1009 application or system. The processing plan presented here is an 1010 example that may be followed, but its primary purpose is to clarify 1011 the semantics of an SPKI certificate and the way it and various other 1012 kinds of certificate might be used to yield an authorization result. 1014 There are three kinds of entity that might be input to the 1015 computation that yields an authorization result: 1017 1. (as a certificate) 1019 2. (as an attribute certificate or ACL entry) 1021 3. (as an authorization certificate or ACL 1022 entry) 1024 These entities are processed in three stages. 1026 1. Individual certificates are verified by checking their 1027 signatures and possibly performing other work. They are then 1028 mapped to intermediate forms, called "tuples" here. 1030 The other work for SPKI or SDSI certificates might include 1031 processing of on-line test results (CRL, re-validation or one- 1032 time validation). 1034 The other work for PGP certificates may include a web-of-trust 1035 computation. 1037 The other work for X.509 certificates depends on the written 1038 documentation for that particular use of X.509 (typically tied 1039 to the root key from which the certificate descended) and could 1040 involve checking information in the parent certificate as well 1041 as additional information in extensions of the certificate in 1042 question. That is, some use X.509 certificates just to define 1043 names. Others use X.509 to communicate an authorization 1044 implicitly (e.g., SSL server certificates). Some might define 1045 extensions of X.509 to carry explicit authorizations. All of 1046 these interpretations are specified in written documentation 1047 associated with the certificate chain and therefore with the 1048 root from which the chain descends. 1050 If on-line tests are involved in the certificate processing, 1051 then the validity dates of those on-line test results are 1052 intersected by VIntersect() [defined in 6.3.2, below] with the 1053 validity dates of the certificate to yield the dates in the 1054 certificate's tuple(s). 1056 2. Uses of names are replaced with simple definitions (keys or 1057 hashes), based on the name definitions available from reducing 1058 name 4-tuples. 1060 3. Authorization 5-tuples are then reduced to a final authorization 1061 result. 1063 6.1 5-tuple Defined 1065 The 5-tuple is an intermediate form, assumed to be held in trusted 1066 memory so that it doesn't need a digital signature for integrity. It 1067 is produced from certificates or other credentials via trusted 1068 software. Its contents are the same as the contents of an SPKI 1069 certificate body, but it might be derived from another form of 1070 certificate or from an ACL entry. 1072 The elements of a 5-tuple are: 1074 1. Issuer: a public key (or its hash), or the reserved word "Self". 1075 This identifies the entity speaking this intermediate result. 1077 2. Subject: a public key (or its hash), a name used to identify a 1078 public key, the hash of an object or a threshold function of 1079 subordinate subjects. This identifies the entity being spoken 1080 about in this intermediate result. 1082 3. Delegation: a boolean. If TRUE, then the Subject is permitted 1083 by the Issuer to further propagate the authorization in this 1084 intermediate result. 1086 4. Authorization: an S-expression. [Rules for combination of 1087 Authorizations are given below.] 1089 5. Validity dates: a not-before date and a not-after date, where 1090 "date" means date and time. If the not-before date is missing 1091 from the source credential then minus infinity is assumed. If 1092 the not-after date is missing then plus infinity is assumed. 1094 6.2 4-tuple Defined 1096 A certificate (such as X.509v1 or SDSI 1.0) carries no 1097 authorization field but does carry a name. Since it is qualitatively 1098 different from an authorization certificate, a separate intermediate 1099 form is defined for it. 1101 The elements of a Name 4-tuple are: 1103 1. Issuer: a public key (or its hash). This identifies the entity 1104 defining this name in its private name space. 1106 2. Name: a byte string 1108 3. Subject: a public key (or its hash), a name, or a threshold 1109 function of subordinate subjects. This defines the name. 1111 4. Validity dates: a not-before date and a not-after date, where 1112 "date" means date and time. If the not-before date is missing 1113 from the source credential then minus infinity is assumed. If 1114 the not-after date is missing then plus infinity is assumed. 1116 6.3 5-tuple Reduction Rules 1118 The two 5-tuples: 1120 + 1122 yield 1124 1126 provided 1128 the two intersections succeed, 1130 I1 = S2 1132 and 1134 D1 = TRUE 1136 If S1 is a threshold subject, there is a slight modification to this 1137 rule, as described below in section 6.3.3. 1139 6.3.1 AIntersect 1141 An authorization is a list of strings or sub-lists, of meaning to and 1142 probably defined by the application that will use this authorization 1143 for access control. Two authorizations intersect by matching, 1144 element for element. If one list is longer than the other but match 1145 at all elements where both lists have elements, then the longer list 1146 is the result of the intersection. This means that additional 1147 elements of a list must restrict the permission granted. 1149 Although actual authorization string definitions are application 1150 dependent, AIntersect provides rules for automatic intersection of 1151 these strings so that application developers can know the semantics 1152 of the strings they use. Special semantics would require special 1153 reduction software. 1155 For example, there might be an ftpd that allows public key access 1156 control, using authorization certificates. Under that service, 1158 (ftp (host ftp.clark.net)) 1160 might imply that the keyholder would be allowed ftp access to all 1161 directories on ftp.clark.net, with all kinds of access (read, write, 1162 delete, ...). This is more general (allows more access) than 1164 (ftp (host ftp.clark.net) (dir /pub/cme)) 1166 which would allow all kinds of access but only in and below the 1167 directory specified. The intersection of the two would be the 1168 second. 1170 Since the AIntersect rules imply position dependency, one could also 1171 define the previous authorization string as: 1173 (ftp ftp.clark.net /pub/cme) 1175 to keep the form compact. 1177 To allow for wild cards, there are a small number of special S- 1178 expressions defined, using "*" as the expression name. 1180 (*) 1181 stands for the set of all S-expressions and byte-strings. 1182 In other words, it will match anything. When intersected 1183 with anything, the result is that other thing. 1185 (* set *) 1186 stands for the set of elements listed in the *-form. 1188 (* prefix ) 1189 stands for the set of all byte strings that start with the 1190 one given in the *-form. 1192 (* range ? ?) 1193 stands for the set of all byte strings lexically (or 1194 numerically) between the two limits. The ordering 1195 parameter (alpha, numeric, time, binary, date) specifies 1196 the kind of strings allowed. 1198 AIntersect() is normal set intersection, when *-forms are defined as 1199 they are above and a normal list is taken to mean all lists that 1200 start with those elements. The following examples should give a more 1201 concrete explanation for those who prefer an explanation without 1202 reference to set operations. 1204 AIntersect( (tag (ftp ftp.clark.net cme (* set read write))), 1205 (tag (*)) ) 1207 evaluates to (tag (ftp ftp.clark.net cme (* set read write))) 1209 AIntersect( (tag (* set read write (foo bla) delete)), (tag write) ) 1211 evaluates to (tag write) 1213 AIntersect( (tag (* prefix http://www.clark.net/pub/)), 1214 (tag (* prefix http://www.clark.net/pub/cme/html/)) ) 1216 evaluates to (tag (* prefix http://www.clark.net/pub/cme/html/)) 1218 AIntersect( (tag (* range numeric ge #30# le #39# )), (tag #26#) ) 1220 fails to intersect. 1222 6.3.2 VIntersect 1224 Date range intersection is straight-forward. 1226 V = VIntersect( X, Y ) 1228 is defined as 1230 Vmin = max( Xmin, Ymin ) 1232 Vmax = min( Xmax, Ymax ) 1234 and if Vmin > Vmax, then the intersection failed. 1236 These rules assume that daytimes are expressed in a monotonic form, 1237 as they are in SPKI. 1239 6.3.3 Threshold Subjects 1241 Given the 5-tuple: 1243 1244 if S1 is a threshold subject, then each individual subject in that 1245 threshold list is a candidate for reduction. That is, for example, 1247 + 1249 would map to 1251 1254 if I2 = S11. 1256 The delegation field is temporarily ternary, with the following logic 1257 table: 1259 D1 D2 1260 TRUE FALSE 1261 +------+------+ 1262 TRUE | TRUE | MID | 1263 +------+------+ 1264 MID | MID | MID | 1265 +------+------+ 1266 FALSE | STOP | STOP | 1267 +------+------+ 1269 That is, if D1 = FALSE, the reduction stops and there is no D3 value. 1270 D3 takes on the value MID if it is intended to become FALSE, once the 1271 threshold subject has been reduced. 1273 Whenever the k-of-n list has K subjects the same, the k-of-n 1274 structure is replaced by that single subject. This applies to nested 1275 threshold subjects as well as to single-level. Once the subject of 1276 the tuple has no thresholds, then the delegation field is mapped back 1277 to a boolean value by mapping MID to FALSE. 1279 6.3.4 Reduction Direction 1281 It is anticipated that most if not all reduction operations will be 1282 in the order provided by the prover. However, the rules above are 1283 defined as if one were dealing with a pool of tuples and wanted to 1284 reduce that pool. That mode of operation is available to the 1285 developer if it is seen as desirable for some reason. 1287 The tuple reduction rules are independent of direction of operation. 1288 One can start at either end of a chain of 5-tuples. However, it is 1289 likely that the right side of that chain will be free from *-forms. 1290 Since the intersection of a *-form with something free from *-forms 1291 is likely to be free from *-forms, the reduction from right to left 1292 may be easier. However, this is a question left to the individual 1293 developer to resolve according to taste. 1295 6.3.5 5-tuple Reduction Infinite Loops 1297 It is possible for someone to define loops of certificates. 1299 If one is processing certificates in order, as provided by a caller, 1300 then the caller will have avoided any loop and presented a finite 1301 amount of work for the verifier to do. This is likely to be the most 1302 common case. 1304 The prover (caller) needs to present a string of certificates in the 1305 proper order, if the verifier expects that. The prover might find 1306 that string by examining an unordered pool of certificates, but it is 1307 more likely that the prover will have been handed a certificate 1308 string when granted the permission to do something and will merely 1309 hand that string along to the verifier. If the prover delegates some 1310 permission, then it appends the new delegation certificate (and any 1311 name resolution certificates) to the string it had been handed, and 1312 passes that new string along to the entity to whom permission was 1313 being delegated. 1315 If one is processing certificates from an unordered pool, then one 1316 can work right to left, and start with a single 5-tuple (the desired 1317 end result) as the right hand element of a pairwise reduction. The 1318 active set of right hand elements would then acquire reduction 1319 results and one could reduce the unordered set by choosing one tuple 1320 in the active set as the right element and one tuple from the 1321 inactive set as the left element. Each new element in the active set 1322 would be tested against the inactive set only once. Therefore, the 1323 process would terminate even if there were certification loops 1324 present in the set. 1326 There are other possible algorithms for breaking such loops. As was 1327 mentioned elsewhere, the actual algorithm for tuple reduction is a 1328 matter for individual developers to decide. 1330 6.4 4-tuple Reduction 1332 There will be name 4-tuples in two different classes: 1334 1. [(name K1 N) -> K2] 1335 2. [(name K1 N) -> (name K2 N1 N2 ... Nk)] 1337 As with the 5-tuples discussed in the previous section, name 1338 definition 4-tuples should be delivered in the order needed by the 1339 prover. In that case, the rule for name reduction is to replace the 1340 name just defined by its definition. For example, 1342 (name K1 N N1 N2 N3) + [(name K1 N) -> K2] 1344 -> (name K2 N1 N2 N3) 1346 With the second form of name definition, one might have names that 1347 temporarily grow. If the prover is providing certificates in order, 1348 then the verifier need only do as it is told. 1350 If the verifier is operating from an unordered pool of tuples, then a 1351 safe rule for name reduction is to apply only those tuples in class 1352 (1). Such applications should bring tuples that started out in class 1353 (2) into class (1), and eventually reduce all names to keys. Any 1354 naming loops are avoided by this process. 1356 6.5 Certificate Translation 1358 Any certificate currently defined, as well as ACL entries and 1359 possibly other instruments, can be translated to 5-tuples (or name 1360 tuples) and therefore take part in an authorization computation. The 1361 specific rules for those are given below. 1363 6.5.1 X.509v1 1365 The original X.509 certificate is a certificate. It 1366 translates directly to a name tuple. The form 1368 [Kroot, (name ), K1, validity] 1370 is used if the rules for that particular X.509 hierarchy is that all 1371 leaf names are unique, under that root. If uniqueness of names 1372 applies only to individual CAs in the X.509 hierarchy, then one must 1373 generate 1375 [Kroot, (name CA1 CA2 ... CAk ), K1, validity] 1377 6.5.2 PGP 1379 A PGP certificate is a certificate. It is verified by 1380 web-of-trust rules (as specified in the PGP documentation). Once 1381 verified, it yields name tuples of the form 1383 [Ki, name, K1, validity] 1385 where Ki is each key that signed that PGP (UserID,key) pair. 1387 6.5.3 X.509v3 1389 An X.509v3 certificate may be used to declare a name. It might also 1390 declare explicit authorizations, by way of extensions. It might also 1391 declare an implicit authorization of the form (tag (*)). The actual 1392 set of tuples it yields depends on the documentation associated with 1393 that line of certificates. That documentation could conceptually be 1394 considered associated with the root key of the certificate chain. In 1395 addition, some X.509v3 certificates (such as those used for SET), 1396 have defined extra validity tests for certificate chains depending on 1397 custom extensions. As a result, it is likely that X.509v3 chains 1398 will have to be validated independently, by chain validation code 1399 specific to each root key. After that validation, that root-specific 1400 code can then generate the appropriate tuples. 1402 6.5.4 X9.57 1404 An X9.57 attribute certificate should yield one or more 5-tuples, 1405 with names as Subject. The code translating the attribute 1406 certificate will have to build a fully-qualified name to represent 1407 the Distinguished Name in the Subject. For any attribute 1408 certificates that refer to an ID certificate explicitly, the Subject 1409 of the 5-tuple can be the key in that ID certificate, bypassing the 1410 construction of name 4-tuples. 1412 6.5.5 SDSI 1414 A SDSI certificate maps directly to one 4-tuple. 1416 6.5.6 SPKI 1418 An SPKI certificate maps directly to one 5-tuple. 1420 6.6 Implicit Authorizations 1422 Some certificates in use today carry no authorization fields. 1423 Perhaps the most commonly known example is an SSL server certificate. 1424 It has the form of certificate but is used to authorize 1425 the establishment of an SSL connection while the name it carries is 1426 not used in the authorization computation. 1428 For this to work, the root key from which such a certificate descends 1429 is in an ACL carrying that authorization (again, implicitly) and all 1430 of the certificates in the chain are interpreted as having an 1431 authorization field of 1433 (tag (*)) 1435 This interpretation of that certificate is a function of the root key 1436 and the software that interprets the certificate chain, in current 1437 implementations. When such certificates are translated to 5-tuples, 1438 they must generate authorization tuples rather than name tuples. 1440 7. Key Management 1442 Cryptographic keys have limited lifetimes. Keys can be stolen. Keys 1443 might also be discovered through cryptanalysis. If the theft is 1444 noticed, then the key can be replaced as one would replace a credit 1445 card. More likely, the theft will not be noticed. To cover this 1446 case, keys are replaced routinely. 1448 The replacement of a key needs to be announced to those who would use 1449 the new key. It also needs to be accomplished smoothly, with a 1450 minimum of hassle. 1452 7.1 Through Inescapable Names 1454 If keyholders had inescapable names [see section 2.5, above], then 1455 one could refer to them by those names and define a certificate to 1456 map from an inescapable name to the person's current key. That 1457 certificate could be issued by any CA, since all CAs would use the 1458 inescapable name for the keyholder. The attribute certificates and 1459 ACLs that refer to the keyholder would all refer to this one 1460 inescapable name. 1462 However, there are no inescapable names for keyholders. There are 1463 not likely ever to be, considering the political dangers of such 1464 names. 1466 7.2 Through a Naming Authority 1468 One could conceivably have a governmental body or other entity that 1469 would issue names voluntarily to a keyholder, strictly for the 1470 purpose of key management. One would then receive all authorizations 1471 through that name. There would have to be only one such authority, 1472 however. Otherwise, names would have to be composed of parts: an 1473 authority name and the individual's name. The authority name would, 1474 in turn, have to be granted by some single global authority. 1476 That authority then becomes able to create keys of its own and 1477 certificates to empower them as any individual, and through those 1478 false certificates acquire access rights of any individual in the 1479 world. Such power is not likely to be tolerated. Therefore, such a 1480 central authority is not likely to come to pass. 1482 7.3 Through Certificates 1484 Instead of inescapable names or single-root naming authorities, we 1485 have names assigned by some entity that issues a 1486 certificate. As noted in sections 2.8 and 2.9, above, such names 1487 have no meaning by themselves. They must be fully qualified to have 1488 meaning. 1490 Therefore, in the construct: 1492 (name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) jim) 1494 the name is not 1496 "jim" 1498 but rather 1500 "(name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) jim)" 1502 This name includes a public key (through its hash, in the example 1503 above). That key has a lifetime like any other key, so this name has 1504 not achieved the kind of permanence (free from key lifetimes) that an 1505 inescapable name has. 1507 This name could easily be issued by the named keyholder, for the 1508 purpose of key management only. In that case, there is no concern 1509 about access control being subverted by some third-party naming 1510 authority. 1512 7.4 Increasing Key Lifetimes 1514 By the logic above, any name will hang off some public key. The job 1515 is then to increase the lifetime of that public key. Once a key 1516 lifetime exceeds the expected lifetime of any authorization granted 1517 through it, then a succession of new, long-lifetime keys can cover a 1518 keyholder forever. 1520 For a key to have a long lifetime, it needs to be strong against 1521 cryptanalytic attack and against theft. It should be used only on a 1522 trusted machine, running trusted software. It should not be used on 1523 an on-line machine. It should be used very rarely, so that the 1524 attacker has few opportunities to find the key in the clear where it 1525 can be stolen. 1527 Different entities will approach this set of requirements in 1528 different ways. A private individual, making his own naming root key 1529 for this purpose, has the advantage of being too small to invite a 1530 well funded attack as compared to the attacks a commercial CA might 1531 face. 1533 7.5 One Root Per Individual 1535 In the limit, one can have one highly protected naming root key for 1536 each individual. One will probably have more than one such key per 1537 individual, but let us assume only one for the immediate discussion. 1539 If there is only one name descending from such a key, then one can 1540 dispense with the name. Authorizations can be assigned to the key 1541 itself, in raw SPKI style, rather than to some name defined under 1542 that key. There is no loss of lifetime -- only a change in the 1543 subject of the certificate the authorizing key uses to delegate 1544 authority. 1546 However, there is one key difference, under the SPKI structure. If 1547 one delegates some authorization to 1549 (name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) carl) 1551 and a different authorization to 1553 (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) 1555 directly, both without granting the permission to delegate, that key 1556 can delegate at will through certificates in the former 1557 case and not delegate at all in the latter case. 1559 In the case of key management, we desire the ability to delegate from 1560 a long lived, rarely used key to a shorter lived, often used key -- 1561 so in this case, the former mechanism (through a SDSI name) gives 1562 more freedom. 1564 7.6 Key Revocation Service 1566 In either of the models above, key |TLCgPLFlGTzgUbcaYLW8kGTEnUk=| 1567 will issue a certificate. In the first model, it will be a 1568 certificate. In the second, it will be an authorization 1569 certificate delegating all rights through to the more temporary key. 1571 Either of those certificates might want an on-line validity test. 1572 Whether this test is in the form of a CRL, a re-validation or a one- 1573 time test, it will be supplied by some entity that is on-line. 1575 As the world moves to having all machines on-line all the time, this 1576 might be the user's machine. However, until then -- and maybe even 1577 after then -- the user might want to hire some service to perform 1578 this function. That service could run a 24x7 manned desk, to receive 1579 phone calls reporting loss of a key. That authority would not have 1580 the power to generate a new key for the user, only to revoke a 1581 current one. 1583 If, in the worst case, a user loses his master key, then the same 1584 process that occurs today with lost wallets would apply. All issuers 1585 of authorizations through that master key would need to issue new 1586 authorizations through the new master key and, if the old master key 1587 had been stolen, cancel all old authorizations through that key. 1589 8. Security Considerations 1591 There are three classes of information that can be bound together by 1592 public key certificates: key, name and authorization. There are 1593 therefore three general kinds of certificate, depending on what pair 1594 of items the certificate ties together. If one considers the 1595 direction of mapping between items, there are six classes: name->key, 1596 key->name, authorization->name, name->authorization, 1597 authorization->key, key->authorization. 1599 The SPKI working group concluded that the most important use for 1600 certificates was access control. Given the various kinds of mapping 1601 possible, there are at least two ways to implement access control. 1602 One can use a straight authorization certificate: 1604 (authorization->key) 1606 or one can use an attribute certificate and an ID certificate: 1608 (authorization->name) + (name->key) 1610 There are at least two ways in which the former is more secure than 1611 the latter. 1613 1. Each certificate has an issuer. If that issuer is subverted, 1614 then the attacker can gain access. In the former case, there is 1615 only one issuer to trust. In the latter case, there are two. 1617 2. In the second case, linkage between the certificates is by name. 1618 If the name space of the issuer of the ID certificate is 1619 different from the name space of the issuer of the attribute 1620 certificate, then there is an increased chance of mistake in 1621 choosing the proper name for the attribute certificate. Such a 1622 mistake can be made by accident or guided by an attacker. 1624 This is not to say that one must never use the second construct. If 1625 the two certificates come from the same issuer, and therefore with 1626 the same name space, then both of the security differentiators above 1627 are canceled. 1629 References 1631 [Ab97] Abadi, Martin, "On SDSI's Linked Local Name Spaces", 1632 Proceedings of the 10th IEEE Computer Security Foundations Workshop 1633 (June 1997). 1635 [BFL] Matt Blaze, Joan Feigenbaum and Jack Lacy, "Distributed Trust 1636 Management", Proceedings 1996 IEEE Symposium on Security and Privacy. 1638 [CHAUM] D. Chaum, "Blind Signatures for Untraceable Payments", 1639 Advances in Cryptology -- CRYPTO '82, 1983. 1641 [DH] Whitfield Diffie and Martin Hellman, "New Directions in 1642 Cryptography", IEEE Transactions on Information Theory, November 1643 1976, pp. 644-654 1645 [DvH] J. B. Dennis and E. C. Van Horn, "Programming Semantics for 1646 Multiprogrammed Computations", Communications of the ACM 9(3), March 1647 1966 1649 [ECR] Silvio Micali, "Efficient Certificate Revocation", manuscript, 1650 MIT LCS. 1652 [HARDY] Hardy, Norman, "THE KeyKOS Architecture", Operating Systems 1653 Review, v.19 n.4, October 1985. pp 8-25. 1655 [IDENT] Carl Ellison, "Establishing Identity Without Certification 1656 Authorities", USENIX Security Symposium, July 1996. 1658 [IWG] McConnell and Appel, ``Enabling Privacy, Commerce, Security and 1659 Public Safety in the Global Information Infrastructure'', report of 1660 the Interagency Working Group on Cryptography Policy, May 12, 1996; 1661 (quote from paragraph 5 of the Introduction) 1663 [KEYKOS] Bomberger, Alan, et al., "The KeyKOS(r) Nanokernel 1664 Architecture", Proceedings of the USENIX Workshop on Micro-Kernels 1665 and Other Kernel Architectures, USENIX Association, April 1992. pp 1666 95-112 (In addition, there are KeyKOS papers on the net available 1667 through ) 1669 [KOHNFELDER] Kohnfelder, Loren M., "Towards a Practical Public-key 1670 Cryptosystem", MIT S.B. Thesis, May. 1978. 1672 [LAMPSON] B. Lampson, M. Abadi, M. Burrows, and E. Wobber, 1673 "Authentication in distributed systems: Theory and practice", ACM 1674 Trans. Computer Systems 10, 4 (Nov. 1992), pp 265-310. 1676 [LANDAU] Landau, Charles, "Security in a Secure Capability-Based 1677 System", Operating Systems Review, Oct 1989 pp 2-4 1679 [LEVY] Henry M. Levy, "Capability-Based Computer Systems", Digital 1680 Press, 12 Crosby Dr., Bedford MA 01730, 1984 1682 [LINDEN] T. A. Linden, "Operating System Structures to Support 1683 Security and Reliable Software", Computing Surveys 8(4), December 1684 1976. 1686 [PKCS1] PKCS #1: RSA Encryption Standard, RSA Data Security, Inc., 3 1687 June 1991, Version 1.4. 1689 [PKLOGIN] David Kemp, "The Public Key Login Protocol", working draft, 1690 06/12/1996. 1692 [R98] R. Rivest, "Can We Eliminate Revocation Lists?", to appear in 1693 the Proceedings of Financial Cryptography 1998, 1694 . 1696 [RFC1114] S. Kent, J. Linn, "Privacy Enhancement for Internet 1697 Electronic Mail: Part II -- Certificate-Based Key Management", August 1698 1989. 1700 [RFC1321] R. Rivest, "The MD5 Message-Digest Algorithm", April 16 1701 1992. 1703 [RFC2045] N. Freed and N. Borenstein, "Multipurpose Internet Mail 1704 Extensions (MIME) Part One: Format of Internet Message Bodies", Dec 2 1705 1996. 1707 [RFC2046] N. Freed and N. Borenstein, "Multipurpose Internet Mail 1708 Extensions (MIME) Part Two: Media Types", Dec 2 1996. 1710 [RFC2047] K. Moore, "MIME (Multipurpose Internet Mail Extensions) 1711 Part Three: Message Header Extensions for Non-ASCII Text", Dec 2 1712 1996. 1714 [RFC2065] D. Eastlake and C. Kaufman, "Proposed Standard for DNS 1715 Security", Jan 1997. 1717 [RFC2104] H. Krawczyk, M. Bellare and R. Canetti, "HMAC: Keyed- 1718 Hashing for Message Authentication", Feb 1997. 1720 [SDSI] Ron Rivest and Butler Lampson, "SDSI - A Simple Distributed 1721 Security Infrastructure [SDSI]", 1722 . 1724 [SET] Secure Electronic Transactions -- a protocol designed by VISA, 1725 MasterCard and others, including a certificate structure covering all 1726 participants. See . 1728 [SEXP] Ron Rivest, code and description of S-expressions, 1729 . 1731 [SRC-070] Abadi, Burrows, Lampson and Plotkin, "A Calculus for Access 1732 Control in Distributed Systems", DEC SRC-070, revised August 28, 1733 1991. 1735 [WEBSTER] "Webster's Ninth New Collegiate Dictionary", Merriam- 1736 Webster, Inc., 1991. 1738 Acknowledgments 1740 Several independent contributions, published elsewhere on the net or 1741 in print, worked in synergy with our effort. Especially important to 1742 our work were: [SDSI], [BFL] and [RFC2065]. The inspiration we 1743 received from the notion of CAPABILITY in its various forms (SDS-940, 1744 Kerberos, DEC DSSA, [SRC-070], KeyKOS [HARDY]) can not be over-rated. 1746 Significant contributions to this effort by the members of the SPKI 1747 mailing list and especially the following persons (listed in 1748 alphabetic order) are gratefully acknowledged: Steve Bellovin, Mark 1749 Feldman, John Gilmore, Phill Hallam-Baker, Bob Jueneman, David Kemp, 1750 Angelos D. Keromytis, Paul Lambert, Jon Lasser, Jeff Parrett, Bill 1751 Sommerfeld, Simon Spero. 1753 Authors' Addresses 1755 Carl M. Ellison 1756 Intel Corporation 1757 2111 NE 25th Ave M/S JF3-373 1758 Hillsboro OR 97124-5961 USA 1760 Telephone: +1-503-264-2900 1761 FAX: +1-503-264-6225 1762 EMail: carl.m.ellison@intel.com (work, Outlook) 1763 cme@jf.intel.com (work, Eudora) 1764 cme@alum.mit.edu, cme@acm.org (home, Eudora) 1765 Web: http://www.pobox.com/~cme 1767 Bill Frantz 1768 Electric Communities 1769 10101 De Anza Blvd. 1770 Cupertino CA 95014 1772 Telephone: +1 408-342-9576 1773 Email: frantz@netcom.com 1775 Butler Lampson 1776 Microsoft 1777 180 Lake View Ave 1778 Cambridge MA 02138 1780 Telephone: +1 617-547-9580 (voice + FAX) 1781 EMail: blampson@microsoft.com 1782 Ron Rivest 1783 Room 324, MIT Laboratory for Computer Science 1784 545 Technology Square 1785 Cambridge MA 02139 1787 Telephone: +1-617-253-5880 1788 +1-617-258-9738(FAX) 1789 Email: rivest@theory.lcs.mit.edu 1790 Web: http://theory.lcs.mit.edu/~rivest 1792 Brian Thomas 1793 Southwestern Bell 1794 One Bell Center, Room 23Q1 1795 St. Louis MO 63101 USA 1797 Telephone: +1 314-235-3141 1798 +1 314-331-2755(FAX) 1799 EMail: bt0008@entropy.sbc.com 1801 Tatu Ylonen 1802 SSH Communications Security Ltd. 1803 Tekniikantie 12 1804 FIN-02150 ESPOO 1805 Finland 1807 E-mail: ylo@ssh.fi 1809 Expiration and File Name 1811 This draft expires 29 April 1999. 1813 Its file name is draft-ietf-spki-cert-theory-03.txt