File: rfc2692.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (787 lines) | stat: -rw-r--r-- 29,569 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787






Network Working Group                                         C. Ellison
Request for Comments: 2692                                         Intel
Category: Experimental                                    September 1999


                           SPKI Requirements

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   The IETF Simple Public Key Infrastructure [SPKI] Working Group is
   tasked with producing a certificate structure and operating procedure
   to meet the needs of the Internet community for trust management in
   as easy, simple and extensible a way as possible.

   The SPKI Working Group first established a list of things one might
   want to do with certificates (attached at the end of this document),
   and then summarized that list of desires into requirements.  This
   document presents that summary of requirements.

Table of Contents

   Charter of the SPKI working group................................2
   Background.......................................................2
   General Requirements.............................................3
   Validity and CRLs................................................4
   Implementation of Certificates...................................4
   List of Certificate Uses.........................................5
   Open Questions..................................................11
   References......................................................12
   Security Considerations.........................................12
   Author's Address................................................13
   Full Copyright Statement........................................14








Ellison                       Experimental                      [Page 1]

RFC 2692                   SPKI Requirements              September 1999


Charter of the SPKI working group

   Many Internet protocols and applications which use the Internet
   employ public key technology for security purposes and require a
   public key infrastructure to manage public keys.

   The task of the working group will be to develop Internet standards
   for an IETF sponsored public key certificate format, associated
   signature and other formats, and key acquisition protocols.  The key
   certificate format and associated protocols are to be simple to
   understand, implement, and use. For purposes of the working group,
   the resulting formats and protocols are to be known as the Simple
   Public Key Infrastructure, or SPKI.

   The SPKI is intended to provide mechanisms to support security in a
   wide range of Internet applications, including IPSEC protocols,
   encrypted electronic mail and WWW documents, payment protocols, and
   any other application which will require the use of public key
   certificates and the ability to access them. It is intended that the
   Simple Public Key Infrastructure will support a range of trust
   models.

Background

   The term certificate traces back to the MIT bachelor's thesis of
   Loren M. Kohnfelder [KOHN].  Kohnfelder, in turn, was responding to a
   suggestion by Diffie and Hellman in their seminal paper [DH].  Diffie
   and Hellman noted that with public key cryptography, one no longer
   needs a secure channel over which to transmit secret keys between
   communicants.  Instead, they suggested, one can publish a modified
   telephone book -- one with public keys in place of telephone numbers.
   One could then look up his or her desired communication partner in
   the directory, find that person's public key and open a secure
   channel to that person.  Kohnfelder took that suggestion and noted
   that an on-line service has the disadvantage of being a performance
   bottleneck.  To replace it, he proposed creation of digitally signed
   directory entries which he called certificates.  In the time since
   1978, the term certificate has frequently been assumed to mean a
   binding between name and key.

   The SPKI team directly addressed the issue of <name,key> bindings and
   realized that such certificates are of extremely limited use for
   trust management.  A keyholder's name is one attribute of the
   keyholder, but as can be seen in the list of needs in this document,
   a person's name is rarely of security interest.  A user of a
   certificate needs to know whether a given keyholder has been granted
   some specific authorization.




Ellison                       Experimental                      [Page 2]

RFC 2692                   SPKI Requirements              September 1999


General Requirements

   We define the term KEYHOLDER of a public key to refer to the person
   or other entity that controls the corresponding private key.

   The main purpose of an SPKI certificate is to authorize some action,
   give permission, grant a capability, etc. to or for a keyholder.

   The keyholder is most directly identified by the public key itself,
   although for convenience or other purposes some indirection (delayed
   binding) may be employed.  That indirection can be via a collision-
   free hash of the public key or via a name, later to be resolved into
   a key.

   The definition of attributes or authorizations in a certificate is up
   to the author of code which uses the certificate.  The creation of
   new authorizations should not require interaction with any other
   person or organization but rather be under the total control of the
   author of the code using the certificate.

   Because SPKI certificates might carry information that the keyholder
   might not want to publish, we assume that certificates will be
   distributed directly by the keyholder to the verifier.  If the
   keyholder wishes to use a global repository, such as LDAP, the global
   PGP key server or the DNS database, that is up to the keyholder and
   not for the SPKI WG to specify.

   Because SPKI certificates will carry information that, taken together
   over all certificates, might constitute a dossier and therefore a
   privacy violation, each SPKI certificate should carry the minimum
   information necessary to get a job done.  The SPKI certificate is
   then to be like a single key rather than a key ring or a single
   credit card rather than a whole wallet.  The keyholder should be able
   to release a minimum of information in order to prove his or her
   permission to act.

   It is necessary for at least some certificates to be anonymous.

   Because one use of SPKI certificates is in secret balloting and
   similar applications, an SPKI certificate must be able to assign an
   attribute to a blinded signature key.

   One attribute of a keyholder is a name.  There are names the
   keyholder prefers to be called and there are names by which the
   keyholder is known to various other keyholders.  An SPKI certificate
   must be able to bind a key to such names.  The SDSI work of Rivest
   and Lampson has done an especially good job of defining and using
   local name spaces, therefore if possible SPKI should support the SDSI



Ellison                       Experimental                      [Page 3]

RFC 2692                   SPKI Requirements              September 1999


   name construct.  [Note: SPKI and SDSI have merged.]

Validity and CRLs

   An SPKI certificate, like any other, should be able to carry a
   validity period: dates within which it is valid.  It may also be
   necessary to have on-line refinement of validity.  This is frequently
   achieved via a Certificate Revocation List (CRL) in previous
   certificate designs.

   A minimal CRL contains a list of revoked certificates, identified
   uniquely, a sequence number and a signature.  Its method of
   transmission is not specified.  If it encounters some certificate
   that it lists, then it annihilates that certificate.  If it
   encounters a previous CRL, as indicated by sequence number, then it
   annihilates that previous CRL.  Such a CRL leads to non-deterministic
   program behavior.  Therefore, we take as a requirement that if SPKI
   uses CRLs, then the certificate that uses it must explicitly tell the
   verifier where to find the CRL, the CRL must carry explicit validity
   dates and the dates of a sequence of CRLs must not overlap.  Under
   this set of requirements, behavior of certificate validation is
   deterministic (aside from the question of clock skew).

   A CRL is a negative statement.  It is the digital equivalent of the
   little paper books of bad checks or bad credit cards that were
   distributed to cashiers in the 1970's and before.  These have been
   replaced in the retail world by positive statements -- on-line
   validation of a single check, ATM card or credit card.

   SPKI should support both positive and negative on-line validations.

   Any CRL or revalidation instrument must have its own lifetime.  A
   lifetime of 0 is not possible because of communication delays and
   clock skews, although one can consider an instrument whose lifetime
   is "one use" and which is delivered only as part of a
   challenge/response protocol.

Implementation of Certificates

   The authorization certificates that are envisioned for SPKI (and
   needed to meet the demands of the list given at the end of this
   document) should be generated by any keyholder empowered to grant or
   delegate the authorization in question.  The code to generate
   certificates should be written by many different developers,
   frequently persons acting alone, operating out of garages or dorm
   rooms.  This leads to a number of constraints on the structure and
   encoding of certificates.  In addition, SPKI certificates should be
   usable in very constrained environments, such as smart cards or small



Ellison                       Experimental                      [Page 4]

RFC 2692                   SPKI Requirements              September 1999


   embedded systems.  The code to process them and the memory to store
   them should both be as small as possible.

   An SPKI certificate should be as simple as possible.  There should be
   a bare minimum of fields necessary to get the job done and there
   should be an absolute minimum of optional fields.  In particular, the
   structure should be specific enough that the creator of a certificate
   is constrained by the structure definition, not by complaints (or
   error messages) from the reader of a certificate.

   An SPKI certificate should be described in as simple a method as
   possible, relating directly to the kind of structures a C or PASCAL
   programmer would normally write.

   No library code should be required for the packing or parsing of SPKI
   certificates.  In particular, ASN.1 is not to be used.

   A certificate should be signed exactly as it is transmitted.  There
   should be no reformatting called for in the process of checking a
   certificate's signature (although one might canonicalize white space
   during certificate input, for example, if the format is text).

   For efficiency, if possible, an SPKI certificate should be encoded in
   an LR(0) grammar.  That is, neither packing nor parsing of the
   structure should require a scan of the data.  Data should be read
   into the kind of structure a programmer would want to use without
   touching the incoming bytes more than once.

   For efficiency, if possible, an SPKI certificate should be packed and
   parsed without any recursion.

List of Certificate Uses

   The list below is a brainstorming list, accumulated on the SPKI
   mailing list, of uses of such certificates.

      -  I need a certificate to give me permission to write electronic
         checks.

      -  My bank would need a certificate, proving to others that it is
         a bank capable of cashing electronic checks and permitted to
         give permission to people to write electronic checks.









Ellison                       Experimental                      [Page 5]

RFC 2692                   SPKI Requirements              September 1999


      -  My bank would issue a certificate signing the key of a master
         bank certifier -- perhaps NACHA -- so that I could follow a
         certificate chain from a key I know (my bank's) to the key of
         any other bank in the US and, similarly, to any other bank in
         the world.

      -  I might generate a certificate (a "reputation voucher") for a
         friend to introduce him to another friend -- in which
         certificate I could testify to my friend's political opinion
         (e.g., libertarian cypherpunk) or physical characteristics or
         anything else of interest.

      -  I might have a certificate giving my security clearance, signed
         by a governmental issuing authority.

      -  I want a certificate for some software I have downloaded and am
         considering running on my computer -- to make sure it hasn't
         changed and that some reputable company or person stands behind
         it.

      -  I need certificates to bind names to public keys:

         -  [traditional certificate] binding a key to a name, implying
            "all the attributes of the real person having this name are
            transferred to this key by this certificate".  This requires
            unique identification of a person (which is difficult in
            non-digital space, as it is) and someone trustworthy binding
            that unique name to the key in question.  In this model, a
            key starts out naked and acquires attributes, permissions
            and authority from the person bound to it.

         -  [direct certificate] binding a name to a key, implying "I
            (the person who is able to use the associated private key to
            make this signature) declare that I go by the name of
            XXXXXXX."  The unique identification of the key is automatic
            -- from the key itself or a cryptographic hash of the key.
            The binding is done by the key itself -- in a self-signed
            certificate.  In this model, a key is loaded with
            attributes, permissions and authority directly by other
            certificates, not indirectly through some person's name, and
            this certificate declares only a name or nickname by which
            the key's owner likes to be addressed.

         -  [personal binding] binding a key to a nickname.  This kind
            of certificate is signed by me, singing someone else's key
            and binding it to a nickname by which I know that person.
            It is for my use only -- never given out -- and is a signed
            certificate to prevent tampering with my own private



Ellison                       Experimental                      [Page 6]

RFC 2692                   SPKI Requirements              September 1999


            directory of keys.  It says nothing about how I certified
            the binding to my own satisfaction between the key and my
            friend.

      -  I might be doing genealogy and be collecting what amounts to
         3x5 cards with facts to be linked together.  Some of these
         links would be from one content to another reference [e.g.,
         indexing and cross-referencing].  Others might be links to the
         researcher who collected the fact.  By rights, the fact should
         be signed by that researcher.  Viewing only the signature on
         the fact and the link to the researcher, this electronic 3x5
         card becomes a certificate.

      -  I want to sign a contract to buy a house.  What kind of
         certificate do I need?

      -  I have found someone on the net and she sounds really nice.
         Things are leading up to cybersex.  How do I make sure she's
         not really some 80-year-old man in a nursing home?

      -  I have met someone on the net and would like a picture of her
         and her height, weight and other measurements from a
         trustworthy source.

      -  Can I have a digital marriage license?

      -  Can I have a digital divorce decree?

      -  ..a digital Voter Registration Card?

      -  There are a number of cards one carries in a typical wallet
         which could become certificates attached to a public key:

      -  health insurance card

      -  prescription drug card

      -  driver's license (for permission to drive)

      -  driver's license (for permission to buy alcohol)

      -  supermarket discount card

      -  supermarket check-cashing card [I know -- anachronism]

      -  Blockbuster Video rental card

      -  ATM card



Ellison                       Experimental                      [Page 7]

RFC 2692                   SPKI Requirements              September 1999


      -  Credit card

      -  membership card in the ACLU, NRA, Republican party, Operation
         Rescue, NARAL, ACM, IEEE, ICAR....

      -  Red Cross blood donor card

      -  Starbuck's Coffee buy-10-get-1-free card

      -  DC Metro fare card

      -  Phone calling card

      -  Alumni Association card

      -  REI Membership card

      -  Car insurance card

      -  claim check for a suitcase

      -  claim check for a pawned radio

      -  authorization for followup visits to a doctor, after surgery

      -  Better Business Bureau [BBB] style reputation certificates
         [testimonies from satisfied customers]

      -  BBB-style certificate that no complaints exist against a
         business or doctor or dentist, etc.

      -  LDS Temple Recommend

      -  Stock certificate

      -  Stock option

      -  Car title

      -  deed to land

      -  proof of ownership of electronic equipment with an ID number

      -  time card certificate [activating a digital time clock]

      -  proof of degree earned [PhD, LLD, MD, ...]

      -  permission to write digitally signed prescriptions for drugs



Ellison                       Experimental                      [Page 8]

RFC 2692                   SPKI Requirements              September 1999


      -  permission to spend up to $X of a company's money

      -  permission to issue nuclear launch codes

      -  I'm a sysadmin, I want to carry a certificate, signed by SAGE,
         that says I'm good at the things sysadmins are good at.

      -  I'm that same sysadmin, I want an ephemeral certificate that
         grants me root access to certain systems for the day, or the
         week, or...

         Certain applications *will* want some form of auditing, but the
         audit identity should be in the domain of the particular
         application...  For instance an "is a system administrator of
         this host" certificate would probably want to include an audit
         identity, so you can figure out which of your multiple admins
         screwed something up.

      -  I'm an amateur radio operator.  I want a signed certificate
         that says I'm allowed to engage in amateur radio, issued by the
         DOC.  [I currently have a paper version of one].  This would be
         useful in enforcing access policies to the amateur spectrum;
         and in tracking abuse of that same spectrum.  Heck!  extend
         this concept to all licensed spectrum users.

      -  I'm the a purchasing agent for a large corporation.  I want to
         posses a certificate that tells our suppliers that I'm
         authorized to make purchases up to $15,000.  I don't want the
         suppliers to know my name, lest their sales people bug me too
         much.  I don't want to have to share a single "Megacorp
         Purchasing Department Certificate" with others doing the same
         job [the private key would need to be shared--yuck!].

      -  "This signed-key should be considered equivalent to the
         certifying-key until this certificate expires for the following
         purposes ..."
            [This is desirable when you wish to reduce the exposure of
            long-term keys.  One way to do this is to use smart cards,
            but those typically have slow processors and are connected
            through low-bandwidth links; however, if you only use the
            smart card at "login" time to certify a short-term key pair,
            you get high performance and low exposure of the long term
            key.








Ellison                       Experimental                      [Page 9]

RFC 2692                   SPKI Requirements              September 1999


            I'll note here that this flies in the face of attempts to
            prevent delegation of certain rights.  Maybe we need a
            "delegation-allowed" bit -- but there's nothing to stop
            someone who wishes to delegate against the rules from also
            loaning out their private key.].

      -  "I am the current legitimate owner of a particular chunk of
         Internet address space."
            [I'd like to see IPSEC eventually become usable, at least
            for privacy, without need for prior arrangement between
            sites, but I think there's a need for a "I own this
            address"/"I own this address range" certificate in order for
            IPSEC to coexist with existing ip-address-based firewalls.]

      -  "I am the current legitimate owner of a this DNS name or
         subtree."

      -  "I am the legitimate receiver of mail sent to this rfc822 email
         address.  [this might need to be signed by a key which itself
         had been certified by the appropriate "DNS name owner"
         certificate]."
            [This is in case I know someone owns a particular e-mail
            address but I don't know their key.]

      -  Encryption keys for E-mail and file encryption

      -  Authentication of people or other entities

      -  Digital signatures (unforgeability)

      -  Timestamping / notary services

      -  Host authentication

      -  Service authentication

         Other requirements:

         -  Trust model must be a web (people want to choose whom they
            trust).  People must be able to choose whom they trust or
            consider reliable roots (maybe with varying reliabilities).

         -  Some applications (e.g., notary services) require highly
            trusted keys; generation complexity is not an issue here.

         -  Some applications (e.g., host authentication) require
            extremely light (or no) bureaucracy.  Even communication
            with the central administrator may be a problem.



Ellison                       Experimental                     [Page 10]

RFC 2692                   SPKI Requirements              September 1999


         -  Especially in lower-end applications (e.g. host
            authentication) the people generating the keys (e.g.,
            administrators) will change, and you will no longer want
            them to be able to certify.  On the other hand, you will
            usually also not want all keys they have generated to
            expire.  This may imply a "certification right expiration"
            certificate requirement, probably to be implemented together
            with notary services.

         -  Keys will need to be cached locally to avoid long delays
            fetching frequently used keys.  Cf. current name servers.
            The key infrastructure may in future get used almost as
            often as the name server.  The caching and performance
            requirements are similar.

         -  Reliable distribution of key revocations and other
            certificates (e.g., the ceasing of the right to make new
            certificates).  May involve goals like "will have spread
            everywhere in 24 hours" or something like that.  This
            interacts with caching.

Open Questions

   Given such certificates, there remain some questions, most to do with
   proofs of the opposite of what a certificate is designed to do.
   These do not have answers provided by certificate definition or
   issuing alone.

   -  Someone digitally signs a threatening e-mail message with my
      private key and sends it to president@whitehouse.gov.  How do I
      prove that I didn't compose and send the message?  What kind of
      certificate characteristic might help me in this?

         This is an issue of (non-)repudiation and therefore a matter of
         private key protection.  Although this is of interest to the
         user of certificates, certificate format, contents or issuing
         machinery can not ensure the protection of a user's private key
         or prove whether or not a private key has been stolen or
         misused.

   -  Can certificates help do a title scan for purchase of a house?

         Certificates might be employed to carry information in a
         tamper-proof way, but building the database necessary to record
         all house titles and all liens is a project not related to
         certificate structure.





Ellison                       Experimental                     [Page 11]

RFC 2692                   SPKI Requirements              September 1999


   -  Can a certificate be issued to guarantee that I am not already
      married, so that I can then get a digital marriage license?

         The absence of attributes can be determined only if all
         relevant records are digitized and all parties have inescapable
         IDs.  The former is not likely to happen in our lifetimes and
         the latter receives political resistance.

         A certificate can communicate the 'positive' attribute "not
         already married" or "not registered as a voter in any other
         district".  That assumes that some organization is capable of
         determining that fact for a given keyholder.  The method of
         determining such a negative fact is not part of the certificate
         definition.

   -  The assumption in most certificates is that the proper user will
      protect his private key very well, to prevent anyone else from
      accessing his funds.  However, in some cases the certificate
      itself might have monetary value [permission to prescribe drugs,
      permission to buy alcohol, ...].  What is to prevent the holder of
      such a certificate from loaning out his private key?

         This is a potential flaw in any system providing authorization
         and an interesting topic for study.  What prevents a doctor or
         dentist from selling prescriptions for controlled substances to
         drug abusers?

References

   [DH]   Diffie and Hellman, "New Directions in Cryptography", IEEE
          Transactions on Information Theory IT-22, 6 (Nov. 1976), 644-
          654.

   [KOHN] Loren Kohnfelder, "Towards a Practical Public-key
          Cryptosystem", Bachelor's thesis, MIT, May, 1978.

Security Considerations

   Security issues are discussed throughout this memo.












Ellison                       Experimental                     [Page 12]

RFC 2692                   SPKI Requirements              September 1999


Author's Address

   Carl M. Ellison
   Intel Corporation
   2111 NE 25th Ave   M/S JF3-212
   Hillsboro OR 97124-5961 USA

   Phone: +1-503-264-2900
   Fax:   +1-503-264-6225
   EMail: carl.m.ellison@intel.com
          cme@alum.mit.edu
   Web:   http://www.pobox.com/~cme







































Ellison                       Experimental                     [Page 13]

RFC 2692                   SPKI Requirements              September 1999


Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Ellison                       Experimental                     [Page 14]