idnits 2.17.1 draft-ietf-spki-cert-req-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) 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 a Security Considerations section. ** 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. ** The abstract seems to contain references ([SPKI]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 9309 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: 'SPKI' is mentioned on line 43, but not defined == Missing Reference: 'BBB' is mentioned on line 383, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'DH' -- Possible downref: Non-RFC (?) normative reference: ref. 'KOHN' Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SPKI Requirements Carl M. Ellison 2 INTERNET-DRAFT Intel 3 Expires: 29 April 1999 5 24 October 1998 7 SPKI Requirements 8 ---- ------------ 10 12 Status of This Document 14 This document supersedes draft-ietf-spki-cert-req-01.txt. 16 It is a compilation of the requirements for SPKI [Simple Public Key 17 Infrastructure] certificates gathered from the discussion on the SPKI 18 Working Group mailing list. It is provided for information only. 20 Distribution of this document is unlimited. Comments should be sent 21 to the SPKI (Simple Public Key Infrastructure) Working Group mailing 22 list or to the author. 24 This document is an Internet-Draft. Internet-Drafts are working 25 documents of the Internet Engineering Task Force (IETF), its areas, 26 and its working groups. Note that other groups may also distribute 27 working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months. Internet-Drafts may be updated, replaced, or obsoleted by 31 other documents at any time. It is not appropriate to use Internet- 32 Drafts as reference material or to cite them other than as a 33 ``working draft'' or ``work in progress.'' 35 To learn the current status of any Internet-Draft, please check the 36 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 37 Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), 38 nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), 39 munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). 41 Abstract 43 The IETF Simple Public Key Infrastructure [SPKI] Working Group is 44 tasked with producing a certificate structure and operating procedure 45 to meet the needs of the Internet community for trust management in 46 as easy, simple and extensible a way as possible. 48 The SPKI Working Group first established a list of things one might 49 want to do with certificates (attached at the end of this document), 50 and then summarized that list of desires into requirements. This 51 document presents that summary of requirements. 53 Charter of the SPKI working group 55 Many Internet protocols and applications which use the Internet 56 employ public key technology for security purposes and require a 57 public key infrastructure to manage public keys. 59 The task of the working group will be to develop Internet standards 60 for an IETF sponsored public key certificate format, associated 61 signature and other formats, and key acquisition protocols. The key 62 certificate format and associated protocols are to be simple to 63 understand, implement, and use. For purposes of the working group, 64 the resulting formats and protocols are to be known as the Simple 65 Public Key Infrastructure, or SPKI. 67 The SPKI is intended to provide mechanisms to support security in a 68 wide range of Internet applications, including IPSEC protocols, 69 encrypted electronic mail and WWW documents, payment protocols, and 70 any other application which will require the use of public key 71 certificates and the ability to access them. It is intended that the 72 Simple Public Key Infrastructure will support a range of trust 73 models. 75 Table Of Contents 77 Status of This Document....................................1 78 Abstract...................................................1 79 Charter of the SPKI working group..........................2 81 Table Of Contents..........................................3 83 Background.................................................4 85 General Requirements.......................................5 86 Validity and CRLs..........................................6 87 Implementation of Certificates.............................6 89 List of Certificate Uses...................................8 90 Open Questions............................................13 92 References................................................15 93 Author's Address..........................................15 94 Expiration and File Name..................................15 96 Background 98 The term certificate traces back to the MIT bachelor's thesis of 99 Loren M. Kohnfelder [KOHN]. Kohnfelder, in turn, was responding to a 100 suggestion by Diffie and Hellman in their seminal paper [DH]. Diffie 101 and Hellman noted that with public key cryptography, one no longer 102 needs a secure channel over which to transmit secret keys between 103 communicants. Instead, they suggested, one can publish a modified 104 telephone book -- one with public keys in place of telephone numbers. 105 One could then look up his or her desired communication partner in 106 the directory, find that person's public key and open a secure 107 channel to that person. Kohnfelder took that suggestion and noted 108 that an on-line service has the disadvantage of being a performance 109 bottleneck. To replace it, he proposed creation of digitally signed 110 directory entries which he called certificates. In the time since 111 1978, the term certificate has frequently been assumed to mean a 112 binding between name and key. 114 The SPKI team directly addressed the issue of bindings and 115 realized that such certificates are of extremely limited use for 116 trust management. A keyholder's name is one attribute of the 117 keyholder, but as can be seen in the list of needs in this document, 118 a person's name is rarely of security interest. A user of a 119 certificate needs to know whether a given keyholder has been granted 120 some specific authorization. 122 General Requirements 124 We define the term KEYHOLDER of a public key to refer to the person 125 or other entity that controls the corresponding private key. 127 The main purpose of an SPKI certificate is to authorize some action, 128 give permission, grant a capability, etc. to or for a keyholder. 130 The keyholder is most directly identified by the public key itself, 131 although for convenience or other purposes some indirection (delayed 132 binding) may be employed. That indirection can be via a collision- 133 free hash of the public key or via a name, later to be resolved into 134 a key. 136 The definition of attributes or authorizations in a certificate is up 137 to the author of code which uses the certificate. The creation of 138 new authorizations should not require interaction with any other 139 person or organization but rather be under the total control of the 140 author of the code using the certificate. 142 Because SPKI certificates might carry information that the 143 certificate holder might not want to publish, we assume that 144 certificates will be distributed directly by the holder to the 145 verifier. If the holder wishes to use a global repository, similar 146 to the global PGP key server or the DNS database, that is up to the 147 certificate holder and not for the SPKI WG to specify. 149 Because SPKI certificates will carry information that, taken together 150 over all certificates, might constitute a dossier and therefore a 151 privacy violation, each SPKI certificate should carry the minimum 152 information necessary to get a job done. The SPKI certificate is 153 then to be like a single key rather than a key ring or a single 154 credit card rather than a whole wallet. The certificate holder 155 should be able to release a minimum of information in order to prove 156 his or her permission to act. 158 It is necessary for at least some certificates to be anonymous. 160 Because one use of SPKI certificates is in secret balloting and 161 similar applications, an SPKI certificate must be able to assign an 162 attribute to a blinded signature key. 164 One attribute of a keyholder is a name. There are names the 165 keyholder prefers to be called and there are names by which the 166 keyholder is known to various other keyholders. An SPKI certificate 167 must be able to bind a key to such names. The SDSI work of Rivest 168 and Lampson has done an especially good job of defining and using 169 local name spaces, therefore if possible SPKI should support the SDSI 170 name construct. [Note: SPKI and SDSI have merged.] 172 Validity and CRLs 174 An SPKI certificate, like any other, should be able to carry a 175 validity period: dates within which it is valid. It may also be 176 necessary to have on-line refinement of validity. This is frequently 177 achieved via a Certificate Revocation List (CRL) in previous 178 certificate designs. 180 A minimal CRL contains a list of revoked certificates, identified 181 uniquely, a sequence number and a signature. Its method of 182 transmission is not specified. If it encounters some certificate 183 that it lists, then it annihilates that certificate. If it 184 encounters a previous CRL, as indicated by sequence number, then it 185 annihilates that previous CRL. Such a CRL leads to non-deterministic 186 program behavior. Therefore, we take as a requirement that if SPKI 187 uses CRLs, then the certificate that uses it must explicitly tell the 188 verifier where to find the CRL, the CRL must carry explicit validity 189 dates and the dates of a sequence of CRLs must not overlap. Under 190 this set of requirements, behavior of certificate validation is 191 deterministic (aside from the question of clock skew). 193 A CRL is a negative statement. It is the digital equivalent of the 194 little paper books of bad checks or bad credit cards that were 195 distributed to cashiers in the 1970's and before. These have been 196 replaced in the retail world by positive statements -- on-line 197 validation of a single check, ATM card or credit card. 199 SPKI should support both positive and negative on-line validations. 201 Any CRL or revalidation instrument must have its own lifetime. A 202 lifetime of 0 is not possible because of communication delays and 203 clock skews, although one can consider an instrument whose lifetime 204 is "one use" and which is delivered only as part of a 205 challenge/response protocol. 207 Implementation of Certificates 209 The authorization certificates that are envisioned for SPKI (and 210 needed to meet the demands of the list given at the end of this 211 document) should be generated by any user of certificates and 212 potentially any holder of certificates. The code to generate 213 certificates should be written by many different developers, 214 frequently persons acting alone, operating out of garages or dorm 215 rooms. This leads to a number of constraints on the structure and 216 encoding of certificates. In addition, SPKI certificates should be 217 usable in very constrained environments, such as smart cards. The 218 code to process them and the memory to store them should both be as 219 small as possible. 221 An SPKI certificate should be as simple as possible. There should be 222 a bare minimum of fields necessary to get the job done and there 223 should be an absolute minimum of optional fields. In particular, the 224 structure should be specific enough that the creator of a certificate 225 is constrained by the structure definition, not by complaints (or 226 error messages) from the reader of a certificate. 228 An SPKI certificate should be described in as simple a method as 229 possible, relating directly to the kind of structures a C or PASCAL 230 programmer would normally write. 232 No library code should be required for the packing or parsing of SPKI 233 certificates. In particular, ASN.1 is not to be used. 235 A certificate should be signed exactly as it is transmitted. There 236 should be no reformatting called for in the process of checking a 237 certificate's signature (although one might canonicalize white space 238 during certificate input, for example, if the format is text). 240 For efficiency, if possible, an SPKI certificate should be encoded in 241 an LR(0) grammar. That is, neither packing nor parsing of the 242 structure should require a scan of the data. Data should be read 243 into the kind of structure a programmer would want to use without 244 touching the incoming bytes more than once. 246 For efficiency, if possible, an SPKI certificate should be packed and 247 parsed without any recursion. 249 List of Certificate Uses 251 The list below is a brainstorming list, accumulated on the SPKI 252 mailing list, of uses of such certificates. 254 - I need a certificate to give me permission to write electronic 255 checks. 257 - My bank would need a certificate, proving to others that it is a 258 bank capable of cashing electronic checks and permitted to give 259 permission to people to write electronic checks. 261 - My bank would issue a certificate signing the key of a master 262 bank certifier -- perhaps NACHA -- so that I could follow a 263 certificate chain from a key I know (my bank's) to the key of 264 any other bank in the US and, similarly, to any other bank in 265 the world. 267 - I might generate a certificate (a ``reputation voucher'') for a 268 friend to introduce him to another friend -- in which 269 certificate I could testify to my friend's political opinion 270 (e.g., libertarian cypherpunk) or physical characteristics or 271 anything else of interest. 273 - I might have a certificate giving my security clearance, signed 274 by a governmental issuing authority. 276 - I want a certificate for some software I have downloaded and am 277 considering running on my computer -- to make sure it hasn't 278 changed and that some reputable company or person stands behind 279 it. [Douglas Barnes ] 281 - I need certificates to bind names to public keys: 283 - [traditional certificate] binding a key to a name, implying 284 "all the attributes of the real person having this name are 285 transferred to this key by this certificate". This 286 requires unique identification of a person (which is 287 difficult in non-digital space, as it is) and someone 288 trustworthy binding that unique name to the key in 289 question. In this model, a key starts out naked and 290 acquires attributes, permissions and authority from the 291 person bound to it. 293 - [direct certificate] binding a name to a key, implying "I 294 (the person who is able to use the associated private key 295 to make this signature) declare that I go by the name of 296 XXXXXXX." The unique identification of the key is 297 automatic -- from the key itself or a cryptographic hash of 298 the key. The binding is done by the key itself -- in a 299 self-signed certificate. In this model, a key is loaded 300 with attributes, permissions and authority directly by 301 other certificates, not indirectly through some person's 302 name, and this certificate declares only a name or nickname 303 by which the key's owner likes to be addressed. 305 - [personal binding] binding a key to a nickname. This kind 306 of certificate is signed by me, singing someone else's key 307 and binding it to a nickname by which I know that person. 308 It is for my use only -- never given out -- and is a signed 309 certificate to prevent tampering with my own private 310 directory of keys. It says nothing about how I certified 311 the binding to my own satisfaction between the key and my 312 friend. 314 - I might be doing genealogy and be collecting what amounts to 3x5 315 cards with facts to be linked together. Some of these links 316 would be from one content to another reference [e.g., indexing 317 and cross-referencing]. Others might be links to the researcher 318 who collected the fact. By rights, the fact should be signed by 319 that researcher. Viewing only the signature on the fact and the 320 link to the researcher, this electronic 3x5 card becomes a 321 certificate. [Ben Laurie ] 323 - I want to sign a contract to buy a house. What kind of 324 certificate do I need? 326 - I have found someone on the net and she sounds really nice. 327 Things are leading up to cybersex. How do I make sure she's not 328 really some 80-year-old man in a nursing home? 330 - I have met someone on the net and would like a picture of her 331 and her height, weight and other measurements from a trustworthy 332 source. 334 - Can I have a digital marriage license? 336 - Can I have a digital divorce decree? 338 - ..a digital Voter Registration Card? 340 - There are a number of cards one carries in a typical wallet 341 which could become certificates attached to a public key: 343 - health insurance card 345 - prescription drug card 346 - driver's license (for permission to drive) 348 - driver's license (for permission to buy alcohol) 350 - supermarket discount card 352 - supermarket check-cashing card [I know -- anachronism] 354 - Blockbuster Video rental card 356 - ATM card 358 - Credit card 360 - membership card in the ACLU, NRA, Republican party, Operation 361 Rescue, NARAL, ACM, IEEE, ICAR.... 363 - Red Cross blood donor card 365 - Starbuck's Coffee buy-10-get-1-free card 367 - DC Metro fare card 369 - Phone calling card 371 - Alumni Association card 373 - REI Membership card 375 - Car insurance card 377 - claim check for a suitcase 379 - claim check for a pawned radio 381 - authorization for followup visits to a doctor, after surgery 383 - Better Business Bureau [BBB] style reputation certificates 384 [testimonies from satisfied customers] 386 - BBB-style certificate that no complaints exist against a 387 business or doctor or dentist, etc. 389 - LDS Temple Recommend 391 - Stock certificate 393 - Stock option 395 - Car title 396 - deed to land 398 - proof of ownership of electronic equipment with an ID number 400 - time card certificate [activating a digital time clock] 402 - proof of degree earned [PhD, LLD, MD, ...] 404 - permission to write digitally signed prescriptions for drugs 406 - permission to spend up to $X of a company's money 408 - permission to issue nuclear launch codes 410 - I'm a sysadmin, I want to carry a certificate, signed by SAGE, 411 that says I'm good at the things sysadmins are good at. [marcus 412 (m.d.) leech ] 414 - I'm that same sysadmin, I want an ephemeral certificate that 415 grants me root access to certain systems for the day, or the 416 week, or... [marcus (m.d.) leech ] 418 Certain applications *will* want some form of auditing, but the 419 audit identity should be in the domain of the particular 420 application... For instance an "is a system administrator of 421 this host" certificate would probably want to include an audit 422 identity, so you can figure out which of your multiple admins 423 screwed something up. [Bill Sommerfeld 424 ] 426 - I'm an amateur radio operator. I want a signed certificate that 427 says I'm allowed to engage in amateur radio, issued by the DOC. 428 [I currently have a paper version of one]. This would be useful 429 in enforcing access policies to the amateur spectrum; and in 430 tracking abuse of that same spectrum. Heck! extend this 431 concept to all licensed spectrum users. [marcus (m.d.) leech 432 ] 434 - I'm the a purchasing agent for a large corporation. I want to 435 posses a certificate that tells our suppliers that I'm 436 authorized to make purchases up to $15,000. I don't want the 437 suppliers to know my name, lest their sales people bug me too 438 much. I don't want to have to share a single "Megacorp 439 Purchasing Department Certificate" with others doing the same 440 job [the private key would need to be shared--yuck!]. [marcus 441 (m.d.) leech ] 443 - "This signed-key should be considered equivalent to the 444 certifying-key until this certificate expires for the following 445 purposes ..." 447 [This is desirable when you wish to reduce the exposure of 448 long-term keys. One way to do this is to use smart cards, 449 but those typically have slow processors and are connected 450 through low-bandwidth links; however, if you only use the 451 smart card at "login" time to certify a short-term key pair, 452 you get high performance and low exposure of the long term 453 key. 455 I'll note here that this flies in the face of attempts to 456 prevent delegation of certain rights.. Maybe we need a 457 "delegation-allowed" bit -- but there's nothing to stop 458 someone who wishes to delegate against the rules from also 459 loaning out their private key..]. 460 [Bill Sommerfeld ] 462 - "I am the current legitimate owner of a particular chunk of 463 Internet address space." 464 [I'd like to see IPSEC eventually become usable, at least for 465 privacy, without need for prior arrangement between sites, 466 but I think there's a need for a "I own this address"/"I own 467 this address range" certificate in order for IPSEC to coexist 468 with existing ip-address-based firewalls] 469 [Bill Sommerfeld ] 471 - "I am the current legitimate owner of a this DNS name or 472 subtree." [Bill Sommerfeld ] 474 - "I am the legitimate receiver of mail sent to this rfc822 email 475 address. [this might need to be signed by a key which itself 476 had been certified by the appropriate "DNS name owner" 477 certificate]." 478 [This is in case I know someone owns a particular e-mail 479 address but I don't know their key.] 480 [Bill Sommerfeld ] 482 - Encryption keys for E-mail and file encryption [Tatu Ylonen 483 ] 485 - Authentication of people or other entities [Tatu Ylonen 486 ] 488 - Digital signatures (unforgeability) [Tatu Ylonen 489 ] 491 - Timestamping / notary services [Tatu Ylonen ] 493 - Host authentication [Tatu Ylonen ] 495 - Service authentication [Tatu Ylonen ] 496 Other requirements: [Tatu Ylonen ] 498 - Trust model must be a web (people want to choose whom they 499 trust). People must be able to choose whom they trust or 500 consider reliable roots (maybe with varying reliabilities). 502 - Some applications (e.g., notary services) require highly 503 trusted keys; generation complexity is not an issue here 505 - Some applications (e.g., host authentication) require 506 extremely light (or no) bureaucracy. Even communication with 507 the central administrator may be a problem. 509 - Especially in lower-end applications (e.g. host 510 authentication) the people generating the keys (e.g., 511 administrators) will change, and you will no longer want them 512 to be able to certify. On the other hand, you will usually 513 also not want all keys they have generated to expire. This 514 may imply a "certification right expiration" certificate 515 requirement, probably to be implemented together with notary 516 services. 518 - Keys will need to be cached locally to avoid long delays 519 fetching frequently used keys. Cf. current name servers. The 520 key infrastructure may in future get used almost as often as 521 the name server. The caching and performance requirements are 522 similar. 524 - Reliable distribution of key revocations and other 525 certificates (e.g., the ceasing of the right to make new 526 certificates). May involve goals like "will have spread 527 everywhere in 24 hours" or something like that. This 528 interacts with caching. 530 Open Questions 532 Given such certificates, there remain some questions, most to do with 533 proofs of the opposite of what a certificate is designed to do. 534 These do not have answers provided by certificate definition or 535 issuing alone. 537 - Someone digitally signs a threatening e-mail message with my 538 private key and sends it to president@whitehouse.gov. How do I 539 prove that I didn't compose and send the message? What kind of 540 certificate characteristic might help me in this? 541 This is an issue of (non-)repudiation and therefore a 542 matter of private key protection. Although this is of 543 interest to the user of certificates, certificate format, 544 contents or issuing machinery can not ensure the protection 545 of a user's private key or prove whether or not a private 546 key has been stolen or misused. 548 - Can certificates help do a title scan for purchase of a house? 550 Certificates might be employed to carry information in a 551 tamper-proof way, but building the database necessary to 552 record all house titles and all liens is a project not 553 related to certificate structure. 555 - Can a certificate be issued to guarantee that I am not already 556 married, so that I can then get a digital marriage license? 558 The absence of attributes can be determined only if all 559 relevant records are digitized and all parties have 560 inescapable IDs. The former is not likely to happen in our 561 lifetimes and the latter receives political resistance. 563 A certificate can communicate the 'positive' attribute "not 564 already married" or "not registered as a voter in any other 565 district". That assumes that some organization is capable 566 of determining that fact for a given keyholder. The method 567 of determining such a negative fact is not part of the 568 certificate definition. 570 - The assumption in most certificates is that the proper user will 571 protect his private key very well, to prevent anyone else from 572 accessing his funds. However, in some cases the certificate 573 itself might have monetary value [permission to prescribe drugs, 574 permission to buy alcohol, ...]. What is to prevent the holder 575 of such a certificate from loaning out his private key? [Thanks 576 to Bob Jueneman for this one and some of the others.] 578 This is a potential flaw in any system providing 579 authorization and an interesting topic for study. What 580 prevents a doctor or dentist from selling prescriptions for 581 controlled substances to drug abusers? 583 References 585 [DH] Diffie and Hellman, "New Directions in Cryptography", IEEE 586 Transactions on Information Theory IT-22, 6 (Nov. 1976), 644-654 588 [KOHN] Loren Kohnfelder, "Towards a Practical Public-key 589 Cryptosystem", Bachelor's thesis, MIT, May, 1978 591 Author's Address 593 Carl M. Ellison 594 Intel Corporation 595 2111 NE 25th Ave M/S JF3-373 596 Hillsboro OR 97124-5961 USA 598 Telephone: +1-503-264-2900 599 Fax: +1-503-264-6225 600 EMail: carl.m.ellison@intel.com (work, Outlook) 601 cme@jf.intel.com (work, Eudora) 602 cme@alum.mit.edu, cme@acm.org (home, Eudora) 603 Web: http://www.pobox.com/~cme 605 Expiration and File Name 607 This draft expires 29 April 1999. 609 Its file name is draft-ietf-spki-cert-req-02.txt