added rfc for certificate requests.

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/protocol/rfc2986.txt b/doc/protocol/rfc2986.txt
new file mode 100644
index 0000000000..ec8f1e3318
--- /dev/null
+++ b/doc/protocol/rfc2986.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                         M. Nystrom
+Request for Comments: 2986                                    B. Kaliski
+Obsoletes: 2314                                             RSA Security
+Category: Informational                                    November 2000
+
+
+          PKCS #10: Certification Request Syntax Specification
+                              Version 1.7
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This memo represents a republication of PKCS #10 v1.7 from RSA
+   Laboratories' Public-Key Cryptography Standards (PKCS) series, and
+   change control is retained within the PKCS process.  The body of this
+   document, except for the security considerations section, is taken
+   directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document.
+
+   This memo describes a syntax for certification requests.
+
+Table of Contents
+
+   1.  Introduction ................................................. 2
+   2.  Definitions and notation ..................................... 2
+   2.1  Definitions ................................................. 2
+   2.2  Notation .................................................... 4
+   3.  Overview ..................................................... 4
+   4.  Certification request syntax ................................. 5
+   4.1  CertificationRequestInfo .................................... 5
+   4.2  CertificationRequest ........................................ 7
+   5.  Security Considerations ...................................... 8
+   6.  Authors' Addresses ........................................... 8
+   A.  ASN.1 module ................................................. 9
+   B.  Intellectual property considerations ........................ 10
+   C.  Revision history ............................................ 10
+   D.  References .................................................. 11
+   E.  Contact information & About PKCS ............................ 12
+   Full Copyright Statement ........................................ 14
+
+
+
+
+Nystrom & Kaliski            Informational                      [Page 1]
+
+RFC 2986       Certification Request Syntax Specification  November 2000
+
+
+1. Introduction
+
+   This document describes syntax for certification requests.  A
+   certification request consists of a distinguished name, a public key,
+   and optionally a set of attributes, collectively signed by the entity
+   requesting certification.  Certification requests are sent to a
+   certification authority, which transforms the request into an X.509
+   [9] public-key certificate.  (In what form the certification
+   authority returns the newly signed certificate is outside the scope
+   of this document.  A PKCS #7 [2] message is one possibility.)
+
+   The intention of including a set of attributes is twofold: to provide
+   other information about a given entity , or a "challenge password" by
+   which the entity may later request certificate revocation; and to
+   provide attributes for inclusion in X.509 certificates.  A non-
+   exhaustive list of attributes is given in PKCS #9 [3].
+
+   Certification authorities may also require non-electronic forms of
+   request and may return non-electronic replies.  It is expected that
+   descriptions of such forms, which are outside the scope of this
+   document, will be available from certification authorities.
+
+   The preliminary intended application of this document is to support
+   PKCS #7 cryptographic messages, but it is expected that other
+   applications will be developed (see e.g. [4]).
+
+2. Definitions and notation
+
+ 2.1 Definitions
+
+   For the purposes of this document, the following definitions apply.
+
+   ALGORITHM       An information object class defined in X.509 to
+                   describe objects composed of an algorithm (a unique
+                   object identifier) and its parameters (any ASN.1
+                   type).  The values of objects in this class can be
+                   represented by the ASN.1 type AlgorithmIdentifier{}.
+                   ALGORITHM is defined as the "useful" information
+                   object class TYPE-IDENTIFIER, specified in [11],
+                   Annex A.
+
+   AlgorithmIdentifier{}
+                   A useful parameterized version of X.509 type
+                   AlgorithmIdentifier is defined in this document.
+                   This type tightly binds pairs of algorithm object
+                   identifiers to their associated parameter types.
+                   When referenced, the single parameter of
+                   AlgorithmIdentifier{} specifies a constraint on the
+
+
+
+Nystrom & Kaliski            Informational                      [Page 2]
+
+RFC 2986       Certification Request Syntax Specification  November 2000
+
+
+                   pairs of values that may appear in that instance of
+                   the type.  The encoded values of
+                   AlgorithmIdentifier{} are equivalent to those of type
+                   AlgorithmIdentifier.
+
+   ASN.1           Abstract Syntax Notation One, as defined in the ASN.1
+                   standards ([10], [11], [12], and [13]).
+
+   ATTRIBUTE       This class describes objects composed of an attribute
+                   (a unique object identifier) and an associated set of
+                   attribute values (any ASN.1 type).  The values of
+                   objects in this class can be represented by type
+                   Attribute{}.
+
+   Attribute{}     A useful parameterized version of X.501 [8] type
+                   Attribute is defined in this document.  This type
+                   tightly binds pairs of attribute type object
+                   identifiers to one or more attribute values types.
+                   In the ASN.1 open type notation, an attribute type is
+                   defined as ATTRIBUTE.&id and an attribute value as
+                   ATTRIBUTE.&Type.  When referenced, the single
+                   parameter of Attribute{} specifies a constraint on
+                   the pairs of values that may appear in an instance of
+                   the type.  The encoded values of Attribute{} are
+                   equivalent to those of type Attribute.
+
+   BER             Basic Encoding Rules for ASN.1, as defined in X.690
+                   ([14]).
+
+   Certificate     A type that binds a subject entity's distinguished
+                   name to a public key with a digital signature.  This
+                   type is defined in X.509.  This type also contains
+                   the distinguished name of the certificate issuer (the
+                   signer), an issuer-specific serial number, the
+                   issuer's signature algorithm identifier, a validity
+                   period, and an optional set of certificate
+                   extensions.
+
+   DER             Distinguished Encoding Rules for ASN.1, as defined in
+                   X.690.  DER is a subset of BER.
+
+   Name            A type that uniquely identifies or "distinguishes"
+                   objects in an X.500 [7] directory.  This type is
+                   defined in X.501.  In an X.509 certificate, the type
+                   identifies the certificate issuer and the certificate
+                   subject, the entity whose public key is certified.
+
+
+
+
+
+Nystrom & Kaliski            Informational                      [Page 3]
+
+RFC 2986       Certification Request Syntax Specification  November 2000
+
+
+  2.2 Notation
+
+   No special notation is used in this document.
+
+3. Overview
+
+   A certification request consists of three parts: "certification
+   request information," a signature algorithm identifier, and a digital
+   signature on the certification request information.  The
+   certification request information consists of the entity's
+   distinguished name, the entity's public key, and a set of attributes
+   providing other information about the entity.
+
+   The process by which a certification request is constructed involves
+   the following steps:
+
+        1. A CertificationRequestInfo value containing a subject
+           distinguished name, a subject public key, and optionally a
+           set of attributes is constructed by an entity requesting
+           certification.
+
+        2. The CertificationRequestInfo value is signed with the subject
+           entity's private key.  (See Section 4.2.)
+
+        3. The CertificationRequestInfo value, a signature algorithm
+           identifier, and the entity's signature are collected together
+           into a CertificationRequest value, defined below.
+
+   A certification authority fulfills the request by authenticating the
+   requesting entity and verifying the entity's signature, and, if the
+   request is valid, constructing an X.509 certificate from the
+   distinguished name and public key, the issuer name, and the
+   certification authority's choice of serial number, validity period,
+   and signature algorithm.  If the certification request contains any
+   PKCS #9 attributes, the certification authority may also use the
+   values in these attributes as well as other information known to the
+   certification authority to construct X.509 certificate extensions.
+
+   In what form the certification authority returns the new certificate
+   is outside the scope of this document.  One possibility is a PKCS #7
+   cryptographic message with content type signedData, following the
+   degenerate case where there are no signers.  The return message may
+   include a certification path from the new certificate to the
+   certification authority.  It may also include other certificates such
+   as cross-certificates that the certification authority considers
+   helpful, and it may include certificate-revocation lists (CRLs).
+   Another possibility is that the certification authority inserts the
+   new certificate into a central database.
+
+
+
+Nystrom & Kaliski            Informational                      [Page 4]
+
+RFC 2986       Certification Request Syntax Specification  November 2000
+
+
+   Note 1 - An entity would typically send a certification request after
+   generating a public-key/private-key pair, but may also do so after a
+   change in the entity's distinguished name.
+
+   Note 2 - The signature on the certification request prevents an
+   entity from requesting a certificate with another party's public key.
+   Such an attack would give the entity the minor ability to pretend to
+   be the originator of any message signed by the other party.  This
+   attack is significant only if the entity does not know the message
+   being signed and the signed part of the message does not identify the
+   signer.  The entity would still not be able to decrypt messages
+   intended for the other party, of course.
+
+   Note 3 - How the entity sends the certification request to a
+   certification authority is outside the scope of this document.  Both
+   paper and electronic forms are possible.
+
+   Note 4 - This document is not compatible with the certification
+   request syntax for Privacy-Enhanced Mail, as described in RFC 1424
+   [5].  The syntax here differs in three respects: It allows a set of
+   attributes; it does not include issuer name, serial number, or
+   validity period; and it does not require an "innocuous" message to be
+   signed.  This document is designed to minimize request size, an
+   important feature for certification authorities accepting requests on
+   paper.
+
+4. Certification request syntax
+
+   This section is divided into two parts.  The first part describes the
+   certification-request-information type CertificationRequestInfo, and
+   the second part describes the top-level type CertificationRequest.
+
+ 4.1 CertificationRequestInfo
+
+   Certification request information shall have ASN.1 type
+   CertificationRequestInfo:
+
+   CertificationRequestInfo ::= SEQUENCE {
+        version       INTEGER { v1(0) } (v1,...),
+        subject       Name,
+        subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
+        attributes    [0] Attributes{{ CRIAttributes }}
+   }
+
+   SubjectPublicKeyInfo { ALGORITHM : IOSet} ::= SEQUENCE {
+        algorithm        AlgorithmIdentifier {{IOSet}},
+        subjectPublicKey BIT STRING
+   }
+
+
+
+Nystrom & Kaliski            Informational                      [Page 5]
+
+RFC 2986       Certification Request Syntax Specification  November 2000
+
+
+   PKInfoAlgorithms ALGORITHM ::= {
+        ...  -- add any locally defined algorithms here -- }
+
+   Attributes { ATTRIBUTE:IOSet } ::= SET OF Attribute{{ IOSet }}
+
+   CRIAttributes  ATTRIBUTE  ::= {
+        ... -- add any locally defined attributes here -- }
+
+   Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
+        type   ATTRIBUTE.&id({IOSet}),
+        values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type})
+   }
+
+   The components of type CertificationRequestInfo have the following
+   meanings:
+
+        version is the version number, for compatibility with future
+          revisions of this document.  It shall be 0 for this version of
+          the standard.
+
+        subject is the distinguished name of the certificate subject
+          (the entity whose public key is to be certified).
+
+        subjectPublicKeyInfo contains information about the public key
+          being certified.  The information identifies the entity's
+          public-key algorithm (and any associated parameters); examples
+          of public-key algorithms include the rsaEncryption object
+          identifier from PKCS #1 [1].  The information also includes a
+          bit-string representation of the entity's public key.  For the
+          public-key algorithm just mentioned, the bit string contains
+          the DER encoding of a value of PKCS #1 type RSAPublicKey.  The
+          values of type SubjectPublicKeyInfo{} allowed for
+          subjectPKInfo are constrained to the values specified by the
+          information object set PKInfoAlgorithms, which includes the
+          extension marker (...).  Definitions of specific algorithm
+          objects are left to specifications that reference this
+          document.  Such specifications will be interoperable with
+          their future versions if any additional algorithm objects are
+          added after the extension marker.
+
+        attributes is a collection of attributes providing additional
+          information about the subject of the certificate.  Some
+          attribute types that might be useful here are defined in PKCS
+          #9.  An example is the challenge-password attribute, which
+          specifies a password by which the entity may request
+          certificate revocation.  Another example is information to
+          appear in X.509 certificate extensions (e.g. the
+          extensionRequest attribute from PKCS #9).  The values of type
+
+
+
+Nystrom & Kaliski            Informational                      [Page 6]
+
+RFC 2986       Certification Request Syntax Specification  November 2000
+
+
+          Attributes{} allowed for attributes are constrained to the
+          values specified by the information object set CRIAttributes.
+          Definitions of specific attribute objects are left to
+          specifications that reference this document.  Such
+          specifications will be interoperable with their future
+          versions if any additional attribute objects are added after
+          the extension marker.
+
+ 4.2 CertificationRequest
+
+   A certification request shall have ASN.1 type CertificationRequest:
+
+   CertificationRequest ::= SEQUENCE {
+        certificationRequestInfo CertificationRequestInfo,
+        signatureAlgorithm AlgorithmIdentifier{{ SignatureAlgorithms }},
+        signature          BIT STRING
+   }
+
+   AlgorithmIdentifier {ALGORITHM:IOSet } ::= SEQUENCE {
+        algorithm          ALGORITHM.&id({IOSet}),
+        parameters         ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL
+   }
+
+   SignatureAlgorithms ALGORITHM ::= {
+        ... -- add any locally defined algorithms here -- }
+
+   The components of type CertificationRequest have the following
+   meanings:
+
+        certificateRequestInfo is the "certification request
+          information." It is the value being signed.
+
+        signatureAlgorithm identifies the signature algorithm (and any
+          associated parameters) under which the certification-request
+          information is signed.  For example, a specification might
+          include an ALGORITHM object for PKCS #1's
+          md5WithRSAEncryption in the information object set
+          SignatureAlgorithms:
+
+          SignatureAlgorithms ALGORITHM ::= {
+               ...,
+               { NULL IDENTIFIED BY md5WithRSAEncryption }
+          }
+
+        signature is the result of signing the certification request
+          information with the certification request subject's private
+          key.
+
+
+
+
+Nystrom & Kaliski            Informational                      [Page 7]
+
+RFC 2986       Certification Request Syntax Specification  November 2000
+
+
+   The signature process consists of two steps:
+
+        1. The value of the certificationRequestInfo component is DER
+           encoded, yielding an octet string.
+
+        2. The result of step 1 is signed with the certification request
+           subject's private key under the specified signature
+           algorithm, yielding a bit string, the signature.
+
+   Note - An equivalent syntax for CertificationRequest could be
+   written:
+
+   CertificationRequest ::= SIGNED { EncodedCertificationRequestInfo }
+        (CONSTRAINED BY { -- Verify or sign encoded
+         -- CertificationRequestInfo -- })
+
+   EncodedCertificationRequestInfo ::=
+        TYPE-IDENTIFIER.&Type(CertificationRequestInfo)
+
+   SIGNED { ToBeSigned } ::= SEQUENCE {
+        toBeSigned ToBeSigned,
+        algorithm  AlgorithmIdentifier { {SignatureAlgorithms} },
+        signature  BIT STRING
+   }
+
+5. Security Considerations
+
+   Security issues are discussed throughout this memo.
+
+6. Authors' Addresses
+
+   Magnus Nystrom
+   RSA Security
+   Box 10704
+   S-121 29 Stockholm
+   Sweden
+
+   EMail: magnus@rsasecurity.com
+
+
+   Burt Kaliski
+   RSA Security
+   20 Crosby Drive
+   Bedford, MA 01730 USA
+
+   EMail: bkaliski@rsasecurity.com
+
+
+
+
+
+Nystrom & Kaliski            Informational                      [Page 8]
+
+RFC 2986       Certification Request Syntax Specification  November 2000
+
+
+APPENDICES
+
+A. ASN.1 Module
+
+   This appendix includes all of the ASN.1 type and value definitions
+   contained in this document in the form of the ASN.1 module PKCS-10.
+
+   PKCS-10 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+   pkcs-10(10) modules(1) pkcs-10(1)}
+
+   DEFINITIONS IMPLICIT TAGS ::=
+
+   BEGIN
+
+   -- EXPORTS All --
+
+   -- All types and values defined in this module are exported for use
+   -- in other ASN.1 modules.
+
+   IMPORTS
+
+   informationFramework, authenticationFramework
+        FROM UsefulDefinitions {joint-iso-itu-t(2) ds(5) module(1)
+        usefulDefinitions(0) 3}
+
+   ATTRIBUTE, Name
+        FROM InformationFramework informationFramework
+
+   ALGORITHM
+        FROM AuthenticationFramework authenticationFramework;
+
+   -- Certificate requests
+   CertificationRequestInfo ::= SEQUENCE {
+        version       INTEGER { v1(0) } (v1,...),
+        subject       Name,
+        subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
+        attributes    [0] Attributes{{ CRIAttributes }}
+   }
+
+   SubjectPublicKeyInfo {ALGORITHM: IOSet} ::= SEQUENCE {
+        algorithm        AlgorithmIdentifier {{IOSet}},
+        subjectPublicKey BIT STRING
+   }
+
+   PKInfoAlgorithms ALGORITHM ::= {
+        ...  -- add any locally defined algorithms here -- }
+
+   Attributes { ATTRIBUTE:IOSet } ::= SET OF Attribute{{ IOSet }}
+
+
+
+Nystrom & Kaliski            Informational                      [Page 9]
+
+RFC 2986       Certification Request Syntax Specification  November 2000
+
+
+   CRIAttributes  ATTRIBUTE  ::= {
+        ... -- add any locally defined attributes here -- }
+
+   Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
+        type   ATTRIBUTE.&id({IOSet}),
+        values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type})
+   }
+
+   CertificationRequest ::= SEQUENCE {
+        certificationRequestInfo CertificationRequestInfo,
+        signatureAlgorithm AlgorithmIdentifier{{ SignatureAlgorithms }},
+        signature          BIT STRING
+   }
+
+   AlgorithmIdentifier {ALGORITHM:IOSet } ::= SEQUENCE {
+        algorithm  ALGORITHM.&id({IOSet}),
+        parameters ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL
+   }
+
+   SignatureAlgorithms ALGORITHM ::= {
+        ... -- add any locally defined algorithms here -- }
+
+   END
+
+B. Intellectual property considerations
+
+   RSA Security makes no patent claims on the general constructions
+   described in this document, although specific underlying techniques
+   may be covered.
+
+   License to copy this document is granted provided that it is
+   identified as "RSA Security Inc.  Public-Key Cryptography Standards
+   (PKCS)" in all material mentioning or referencing this document.
+
+   RSA Security makes no representations regarding intellectual property
+   claims by other parties.  Such determination is the responsibility of
+   the user.
+
+C. Revision history
+
+   Version 1.0
+
+         Version 1.0 was the previous version of this document (also
+         published as "version 1.5" in [6]).
+
+
+
+
+
+
+
+Nystrom & Kaliski            Informational                     [Page 10]
+
+RFC 2986       Certification Request Syntax Specification  November 2000
+
+
+   Version 1.7
+
+         This version incorporates several editorial changes, including
+         updates to the references, and changes to ASN.1 type
+         definitions.  The following substantive changes have been made:
+
+         - This version refers to X.680-X.690, the current international
+           standards for ASN.1 and its encoding rules.  All references
+           to X.208 and X.209 have been eliminated.
+
+         - The X.690 standard requires that the encoded values of SET OF
+           components be sorted in ascending order under DER.
+           Regardless of this, applications should not rely on the
+           ordering of attribute components.
+
+         - All references to PKCS #6 Extended-Certificate Syntax
+           Standard have been removed.  With the addition of extensions
+           to X.509 version 3 certificates, RSA Laboratories is
+           withdrawing support for PKCS #6.
+
+   Note - The reason for using version 1.7 for this document is to avoid
+   confusion with [6], which is named version 1.5, and an unsupported
+   PKCS #10 version named Version 1.6.
+
+D. References
+
+   [1]  RSA Laboratories. PKCS #1: RSA Encryption Standard. Version 2.0,
+        October 1998.
+
+   [2]  RSA Laboratories. PKCS #7: Cryptographic Message Syntax
+        Standard.  Version 1.5, November 1993.
+
+   [3]  RSA Laboratories. PKCS #9: Selected Attribute Types. Version
+        2.0, February 2000.
+
+   [4]  Adams, C. and S. Farrell, "Internet X.509 Public Key
+        Infrastructure - Certificate Management Protocols", RFC 2510,
+        March 1999.
+
+   [5]  Kaliski, B., "Privacy Enhancement for Internet Electronic Mail:
+        Part IV: Key Certification and Related Services", RFC 1424,
+        February 1993.
+
+   [6]  Kaliski, B., "PKCS #10: Certification Request Syntax Version
+        1.5", RFC 2314, March 1998.
+
+
+
+
+
+
+Nystrom & Kaliski            Informational                     [Page 11]
+
+RFC 2986       Certification Request Syntax Specification  November 2000
+
+
+   [7]  ITU-T Recommendation X.500 (1997) | ISO/IEC 9594-1:1998,
+        Information technology - Open Systems Interconnection - The
+        Directory: Overview of concepts, models and services.
+
+   [8]  ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1995,
+        Information technology - Open Systems Interconnection - The
+        Directory: Models.
+
+   [9]  ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1998,
+        Information technology - Open Systems Interconnection -The
+        Directory:  Authentication framework.
+
+   [10] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998,
+        Information Technology - Abstract Syntax Notation One (ASN.1):
+        Specification of Basic Notation.
+
+   [11] ITU-T Recommendation X.681 (1997) | ISO/IEC 8824-2:1998,
+        Information Technology - Abstract Syntax Notation One (ASN.1):
+        Information Object Specification.
+
+   [12] ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998,
+        Information Technology - Abstract Syntax Notation One (ASN.1):
+        Constraint Specification.
+
+   [13] ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998,
+        Information Technology - Abstract Syntax Notation One (ASN.1):
+        Parameterization of ASN.1 Specifications.
+
+   [14] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998,
+        Information Technology - ASN.1 Encoding Rules: Specification of
+        Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
+        Distinguished Encoding Rules (DER).
+
+E. Contact Information & About PKCS
+
+   The Public-Key Cryptography Standards are specifications produced by
+   RSA Laboratories in cooperation with secure systems developers
+   worldwide for the purpose of accelerating the deployment of public-
+   key cryptography.  First published in 1991 as a result of meetings
+   with a small group of early adopters of public-key technology, the
+   PKCS documents have become widely referenced and implemented.
+   Contributions from the PKCS series have become part of many formal
+   and de facto standards, including ANSI X9 documents, PKIX, SET,
+   S/MIME, and SSL.
+
+
+
+
+
+
+
+Nystrom & Kaliski            Informational                     [Page 12]
+
+RFC 2986       Certification Request Syntax Specification  November 2000
+
+
+   Further development of PKCS occurs through mailing list discussions
+   and occasional workshops, and suggestions for improvement are
+   welcome.  For more information, contact:
+
+        PKCS Editor
+        RSA Laboratories
+        20 Crosby Drive
+        Bedford, MA  01730 USA
+        pkcs-editor@rsasecurity.com
+        http://www.rsasecurity.com/rsalabs/pkcs
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nystrom & Kaliski            Informational                     [Page 13]
+
+RFC 2986       Certification Request Syntax Specification  November 2000
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society 2000. All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others provided that the above copyright notice and this paragraph
+   are included on all such copies.  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 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nystrom & Kaliski            Informational                     [Page 14]
+