home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2559.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  23.1 KB  |  732 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                      S. Boeyen
  8. Request for Comments: 2559                                   Entrust
  9. Updates: 1778                                               T. Howes
  10. Category: Standards Track                                   Netscape
  11.                                                           P. Richard
  12.                                                                Xcert
  13.                                                           April 1999
  14.  
  15.  
  16.                 Internet X.509 Public Key Infrastructure
  17.                      Operational Protocols - LDAPv2
  18.  
  19. Status of this Memo
  20.  
  21.    This document specifies an Internet standards track protocol for the
  22.    Internet community, and requests discussion and suggestions for
  23.    improvements.  Please refer to the current edition of the "Internet
  24.    Official Protocol Standards" (STD 1) for the standardization state
  25.    and status of this protocol.  Distribution of this memo is unlimited.
  26.  
  27. Copyright Notice
  28.  
  29.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  30.  
  31. 1.  Abstract
  32.  
  33.    The protocol described in this document is designed to satisfy some
  34.    of the operational requirements within the Internet X.509 Public Key
  35.    Infrastructure (IPKI).  Specifically, this document addresses
  36.    requirements to provide access to Public Key Infrastructure (PKI)
  37.    repositories for the purposes of retrieving PKI information and
  38.    managing that same information.  The mechanism described in this
  39.    document is based on the Lightweight Directory Access Protocol (LDAP)
  40.    v2, defined in RFC 1777, defining a profile of that protocol for use
  41.    within the IPKI and updates encodings for certificates and revocation
  42.    lists from RFC 1778. Additional mechanisms addressing PKIX
  43.    operational requirements are specified in separate documents.
  44.  
  45.    The key words 'MUST', 'REQUIRED', 'SHOULD', 'RECOMMENDED', and 'MAY'
  46.    in this document are to be interpreted as described in RFC 2119.
  47.  
  48. 2.  Introduction
  49.  
  50.    This specification is part of a multi-part standard for development
  51.    of a Public Key Infrastructure (PKI) for the Internet. This
  52.    specification addresses requirements to provide retrieval of X.509
  53.    PKI information, including certificates and CRLs from a repository.
  54.    This specification also addresses requirements to add, delete and
  55.  
  56.  
  57.  
  58. Boeyen, et al.              Standards Track                     [Page 1]
  59.  
  60. RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999
  61.  
  62.  
  63.    modify PKI information in a repository. A profile based on the LDAP
  64.    version 2 protocol is provided to satisfy these requirements.
  65.  
  66. 3.  Model
  67.  
  68.    The PKI components, as defined in PKIX Part 1, which are involved in
  69.    PKIX operational protocol interactions include:
  70.  
  71.       -  End Entities
  72.       -  Certification Authorities (CA)
  73.       -  Repository
  74.  
  75.    End entities and CAs using LDAPv2, retrieve PKI information from the
  76.    repository using a subset of the LDAPv2 protocol.
  77.  
  78.    CAs populate the repository with PKI information using a subset of
  79.    the LDAPv2 protocol.
  80.  
  81. 4.  Lightweight Directory Access Protocol (LDAP)
  82.  
  83.    The following sections examine the retrieval of PKI information from
  84.    a repository and management of PKI information in a repository. A
  85.    profile of the LDAPv2 protocol is defined for providing these
  86.    services.
  87.  
  88.    Section 5 satisfies the requirement to retrieve PKI information (a
  89.    certificate, CRL, or other information of interest) from an entry in
  90.    the repository, where the retrieving entity (either an end entity or
  91.    a CA) has knowledge of the name of the entry. This is termed
  92.    "repository read".
  93.  
  94.    Section 6 satisfies the same requirement as 5 for the situation where
  95.    the name of the entry is not known, but some other related
  96.    information which may optionally be used as a filter against
  97.    candidate entries in the repository, is known.  This is termed
  98.    "repository search".
  99.  
  100.    Section 7 satisfies the requirement of CAs to add, delete and modify
  101.    PKI information information (a certificate, CRL, or other information
  102.    of interest)in the repository. This is termed "repository modify".
  103.  
  104.    The subset of LDAPv2 needed to support each of these functions is
  105.    described below.  Note that the repository search service is a
  106.    superset of the repository read service in terms of the LDAPv2
  107.    functionality needed.
  108.  
  109.    Note that all tags are implicit by default in the ASN.1 definitions
  110.    that follow.
  111.  
  112.  
  113.  
  114. Boeyen, et al.              Standards Track                     [Page 2]
  115.  
  116. RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999
  117.  
  118.  
  119. 5.  LDAP Repository Read
  120.  
  121.    To retrieve information from an entry corresponding to the subject or
  122.    issuer name of a certificate, requires a subset of the following
  123.    three LDAP operations:
  124.  
  125.      BindRequest (and BindResponse)
  126.      SearchRequest (and SearchResponse)
  127.      UnbindRequest
  128.  
  129.    The subset of each REQUIRED operation is given below.
  130.  
  131. 5.1.  Bind
  132.  
  133. 5.1.1.  Bind Request
  134.  
  135.    The full LDAP v2 Bind Request is defined in RFC 1777.
  136.  
  137.    An application providing a LDAP repository read service MUST
  138.    implement the following subset of this operation:
  139.  
  140.       BindRequest ::=
  141.         [APPLICATION 0] SEQUENCE {
  142.            version      INTEGER (2),
  143.            name         LDAPDN, -- MUST accept NULL LDAPDN
  144.            simpleauth [0] OCTET STRING  -- MUST accept NULL simple
  145.            }
  146.  
  147.    An application providing a LDAP repository read service MAY implement
  148.    other aspects of the BindRequest as well.
  149.  
  150.    Different services may have different security requirements.  Some
  151.    services may allow anonymous search, others may require
  152.    authentication. Those services allowing anonymous search may choose
  153.    only to allow search based on certain criteria and not others.
  154.  
  155.    A LDAP repository read service SHOULD implement some level of
  156.    anonymous search access. A LDAP repository read service MAY implement
  157.    authenticated search access.
  158.  
  159. 5.1.2.  Bind Response
  160.  
  161.    The full LDAPv2 BindResponse is described in RFC 1777.
  162.  
  163.    An application providing a LDAP repository read service MUST
  164.    implement this entire protocol element, though only the following
  165.    error codes may be returned from a Bind operation:
  166.  
  167.  
  168.  
  169.  
  170. Boeyen, et al.              Standards Track                     [Page 3]
  171.  
  172. RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999
  173.  
  174.  
  175.        success                      (0),
  176.        operationsError              (1),
  177.        protocolError                (2),
  178.        authMethodNotSupported       (7),
  179.        noSuchObject                 (32),
  180.        invalidDNSyntax              (34),
  181.        inappropriateAuthentication  (48),
  182.        invalidCredentials           (49),
  183.        busy                         (51),
  184.        unavailable                  (52),
  185.        unwillingToPerform           (53),
  186.        other                        (80)
  187.  
  188. 5.2.  Search
  189.  
  190. 5.2.1.  Search Request
  191.  
  192.    The full LDAPv2 SearchRequest is defined in RFC 1777.
  193.  
  194.    An application providing a LDAP repository read service MUST
  195.    implement the following subset of the SearchRequest.
  196.  
  197.       SearchRequest ::=
  198.         [APPLICATION 3] SEQUENCE {
  199.            baseObject     LDAPDN,
  200.            scope             ENUMERATED {
  201.                              baseObject   (0),
  202.                                         },
  203.            derefAliases   ENUMERATED {
  204.                              neverDerefAliases   (0),
  205.                                      },
  206.            sizeLimit      INTEGER (0),
  207.            timeLimit      INTEGER (0),
  208.            attrsOnly      BOOLEAN, -- FALSE only
  209.            filter         Filter,
  210.            attributes     SEQUENCE OF AttributeType
  211.                                }
  212.  
  213.       Filter ::=
  214.         CHOICE {
  215.           present        [7] AttributeType, -- "objectclass" only
  216.                  }
  217.  
  218.    This subset of the LDAPv2 SearchRequest allows the LDAPv2 "read"
  219.    operation: a base object search with a filter testing for the
  220.    existence of the objectClass attribute.
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Boeyen, et al.              Standards Track                     [Page 4]
  227.  
  228. RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999
  229.  
  230.  
  231.    An application providing a LDAP repository read service MAY implement
  232.    other aspects of the SearchRequest as well.
  233.  
  234. 5.2.2.
  235.  
  236.    The full LDAPv2 SearchResponse is defined in RFC 1777.
  237.  
  238.    An application providing a LDAP repository read service over LDAPv2
  239.    MUST implement the full SearchResponse.
  240.  
  241.    Note that in the case of multivalued attributes such as
  242.    userCertificate a SearchResponse containing this attribute will
  243.    include all values, assuming the requester has sufficient access
  244.    permissions.  The application/relying party may need to select an
  245.    appropriate value to be used. Also note that retrieval of a
  246.    certificate from a named entry does not guarantee that the
  247.    certificate will include that same Distinguished Name (DN) and in
  248.    some cases the subject DN in the certificate may be NULL.
  249.  
  250. 5.3.  Unbind
  251.  
  252.    The full LDAPv2 UnbindRequest is defined in RFC 1777.
  253.  
  254.    An application providing a LDAP repository read service MUST
  255.    implement the full UnbindRequest.
  256.  
  257. 6.  LDAP Repository Search
  258.  
  259.    To search, using arbitrary criteria, for an entry in a repository
  260.    containing a certificate, CRL, or other information of interest,
  261.    requires a subset of the following three LDAP operations:
  262.  
  263.      BindRequest (and BindResponse)
  264.      SearchRequest (and SearchResponse)
  265.      UnbindRequest
  266.  
  267.    The subset of each operation REQUIRED is given below.
  268.  
  269. 6.1.  Bind
  270.  
  271.    The BindRequest and BindResponse subsets needed are the same as those
  272.    described in Section 5.1.
  273.  
  274.    The full LDAP v2 Bind Request is defined in RFC 1777.
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Boeyen, et al.              Standards Track                     [Page 5]
  283.  
  284. RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999
  285.  
  286.  
  287. 6.2.  Search
  288.  
  289. 6.2.1.  Search Request
  290.  
  291.    The full LDAPv2 SearchRequest is defined in RFC 1777.
  292.  
  293.    An application providing a LDAP repository search service MUST
  294.    implement the following subset of the SearchRequest protocol unit.
  295.  
  296.       SearchRequest ::=
  297.         [APPLICATION 3] SEQUENCE {
  298.            baseObject     LDAPDN,
  299.            scope          ENUMERATED {
  300.                                baseObject     (0),
  301.                                singleLevel    (1),
  302.                                wholeSubtree   (2)
  303.                                      },
  304.            derefAliases   ENUMERATED {
  305.                                neverDerefAliases     (0),
  306.                                      },
  307.            sizeLimit      INTEGER (0 .. maxInt),
  308.            timeLimit      INTEGER (0 .. maxInt),
  309.            attrsOnly      BOOLEAN,  -- FALSE only
  310.            filter         Filter,
  311.            attributes     SEQUENCE OF AttributeType
  312.                                 }
  313.  
  314.    All aspects of the SearchRequest MUST be supported, except for the
  315.    following:
  316.  
  317.    - Only the neverDerefAliases value of derefAliases needs to be
  318.      supported
  319.  
  320.    - Only the FALSE value for attrsOnly needs to be supported
  321.  
  322.    This subset provides a more general search capability.  It is a
  323.    superset of the SearchRequest subset defined in Section 5.2.1. The
  324.    elements added to this service are:
  325.  
  326.    - singleLevel and wholeSubtree scope needs to be supported
  327.  
  328.    - sizeLimit is included
  329.  
  330.    - timeLimit is included
  331.  
  332.    - Enhanced filter capability
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Boeyen, et al.              Standards Track                     [Page 6]
  339.  
  340. RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999
  341.  
  342.  
  343.    An application providing a LDAP repository search service MAY
  344.    implement other aspects of the SearchRequest as well.
  345.  
  346. 6.2.2.  Search Response
  347.  
  348.    The full LDAPv2 SearchResponse is defined in RFC 1777.
  349.  
  350.    An application providing a LDAP repository search service over LDAPv2
  351.    MUST implement the full SearchResponse.
  352.  
  353. 6.3.  Unbind
  354.  
  355.    An application providing a LDAP repository search service MUST
  356.    implement the full UnbindRequest.
  357.  
  358. 7.  LDAP Repository Modify
  359.  
  360.    To add, delete and modify PKI information in a repository  requires a
  361.    subset of the following LDAP operations:
  362.  
  363.      BindRequest (and BindResponse)
  364.      ModifyRequest (and ModifyResponse)
  365.      AddRequest (and AddResponse)
  366.      DelRequest (and DelResponse
  367.      UnbindRequest
  368.  
  369.    The subset of each operation REQUIRED is given below.
  370.  
  371. 7.1.  Bind
  372.  
  373.    The full LDAP v2 Bind Request is defined in RFC 1777.
  374.  
  375.    An application providing a LDAP repository modify service MUST
  376.    implement the following subset of this operation:
  377.  
  378.       BindRequest ::=
  379.         [APPLICATION 0] SEQUENCE {
  380.            version      INTEGER (2),
  381.            name         LDAPDN,
  382.            simpleauth [0] OCTET STRING
  383.            }
  384.  
  385.    A LDAP repository modify service MUST implement authenticated access.
  386.  
  387.    The BindResponse subsets needed are the same as those described in
  388.    Section 5.1.2.
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Boeyen, et al.              Standards Track                     [Page 7]
  395.  
  396. RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999
  397.  
  398.  
  399. 7.2.  Modify
  400.  
  401. 7.2.1.  Modify Request
  402.  
  403.    The full LDAPv2 ModifyRequest is defined in RFC 1777.
  404.  
  405.    An application providing a LDAP repository modify service MUST
  406.    implement the following subset of the ModifyRequest protocol unit.
  407.  
  408.       ModifyRequest ::=
  409.         [APPLICATION 6] SEQUENCE {
  410.        object         LDAPDN,
  411.        modification   SEQUENCE OF SEQUENCE {
  412.                         operation     ENUMERATED {
  413.                                         add     (0),
  414.                                         delete  (1)
  415.                                       },
  416.                         modification  SEQUENCE {
  417.                                       type   AttributeType,
  418.                                       values SET OF
  419.                                              AttributeValue
  420.                                       }
  421.                       }
  422.         }
  423.  
  424.    All aspects of the ModifyRequest MUST be supported, except for the
  425.    following:
  426.  
  427.    - Only the add and delete values of operation need to be supported
  428.  
  429. 7.2.2.  Modify Response
  430.  
  431.    The full LDAPv2 ModifyResponse is defined in RFC 1777.
  432.  
  433.    An application providing a LDAP repository modify service MUST
  434.    implement the full ModifyResponse.
  435.  
  436. 7.3.  Add
  437.  
  438. 7.3.1.  Add Request
  439.  
  440.    The full LDAPv2 AddRequest is defined in RFC 1777.
  441.  
  442.    An application providing a LDAP repository modify service MUST
  443.    implement the full AddRequest.
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Boeyen, et al.              Standards Track                     [Page 8]
  451.  
  452. RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999
  453.  
  454.  
  455. 7.3.2.  Add Response
  456.  
  457.    The full LDAPv2 AddResponse is defined in RFC 1777.
  458.  
  459.    An application providing a LDAP repository modify service MUST
  460.    implement the full AddResponse.
  461.  
  462. 7.4.  Delete
  463.  
  464. 7.4.1.  Delete Request
  465.  
  466.    The full LDAPv2 DelRequest is defined in RFC 1777.
  467.  
  468.    An application providing a LDAP repository modify service MUST
  469.    implement the full DelRequest.
  470.  
  471. 7.4.2.  Delete Response
  472.  
  473.    The full LDAPv2 DelResponse is defined in RFC 1777.
  474.  
  475.    An application providing a LDAP repository modify service MUST
  476.    implement the full DelResponse.
  477.  
  478. 7.5.  Unbind
  479.  
  480.    An application providing a LDAP repository modify service MUST
  481.    implement the full UnbindRequest.
  482.  
  483. 8.  Non-standard attribute value encodings
  484.  
  485.    When conveyed in LDAP requests and results, attributes defined in
  486.    X.500 are to be encoded using string representations defined in RFC
  487.    1778, The String Representation of Standard Attribute Syntaxes.
  488.    These string encodings were based on the attribute definitions from
  489.    X.500(1988).  Thus, the string representations of the PKI information
  490.    elements are for version 1 certificates and version 1 revocation
  491.    lists.  Since this specification uses version 3 certificates and
  492.    version 2 revocation lists, as defined in X.509(1997), the RFC 1778
  493.    string encoding of these attributes is inappropriate.
  494.  
  495.    For this reason, these attributes MUST be encoded using a syntax
  496.    similar to the syntax "Undefined" from section 2.1 of RFC 1778:
  497.    values of these attributes are encoded as if they were values of type
  498.    "OCTET STRING", with the string value of the encoding being the DER-
  499.    encoding of the value itself.  For example, when writing a
  500.    userCertificate to the repository, the CA generates a DER-encoding of
  501.    the certificate and uses that encoding as the value of the
  502.    userCertificate attribute in the LDAP Modify request.This encoding
  503.  
  504.  
  505.  
  506. Boeyen, et al.              Standards Track                     [Page 9]
  507.  
  508. RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999
  509.  
  510.  
  511.    style is consistent with the encoding scheme proposed for LDAPv3,
  512.    which is now being defined within the IETF.
  513.  
  514.    Note that certificates and revocation lists will be transferred using
  515.    this mechanism rather than the string encodings in RFC 1778 and
  516.    client systems which do not understand this encoding may experience
  517.    problems with these attributes.
  518.  
  519. 9.  Transport
  520.  
  521.    An application providing a LDAP repository read service, LDAP
  522.    repository search service, or LDAP repository modify service MUST
  523.    support LDAPv2 transport over TCP, as defined in Section 3.1 of RFC
  524.    1777.
  525.  
  526.    An application providing a LDAP repository read service, LDAP
  527.    repository search service, or LDAP repository modify service MAY
  528.    support LDAPv2 transport over other reliable transports as well.
  529.  
  530. 10.  Security Considerations
  531.  
  532.    Since the elements of information which are key to the PKI service
  533.    (certificates and CRLs) are both digitally signed pieces of
  534.    information, additional integrity service is NOT REQUIRED.  As
  535.    neither information element need be kept secret and anonymous access
  536.    to such information, for retrieval purposes is generally acceptable,
  537.    privacy service is NOT REQUIRED for information retrieval requests.
  538.  
  539.    CAs have additional requirements, including modification of PKI
  540.    information.  Simple authentication alone is not sufficient for these
  541.    purposes. It is RECOMMENDED that some stronger means of
  542.    authentication and/or (if simple authentication is used) some means
  543.    of protecting the privacy of the password is used, (e.g.  accept
  544.    modifications only via physically secure networks, use IPsec, use SSH
  545.    or TLS or SSL tunnel). Without such authentication, it is possible
  546.    that a denial-of-service attack could occur where the attacker
  547.    replaces valid certificates with bogus ones.
  548.  
  549.    For the LDAP repository modify service, profiled in section 7, there
  550.    are some specific security considerations with respect to access
  551.    control. These controls apply to a repository which is under the same
  552.    management control as the CA. Organizations operating directories are
  553.    NOT REQUIRED to provide external CAs access permission to their
  554.    directories.
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Boeyen, et al.              Standards Track                    [Page 10]
  563.  
  564. RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999
  565.  
  566.  
  567.    The CA MUST have access control permissions allowing it to:
  568.  
  569.       For CA entries:
  570.          - add, modify and delete all PKI attributes for its own
  571.            directory entry;
  572.          - add, modify and delete all values of these attributes.
  573.  
  574.       For CRL distribution point entries (if used):
  575.          - create, modify and delete entries of object class
  576.            cRLDistributionPoint immediately subordinate to its own
  577.            entry;
  578.          - add, modify and delete all attributes, and all values of
  579.            these attributes for these entries.
  580.  
  581.       For subscriber (end-entity) entries:
  582.          - add, modify and delete the attribute userCertificate and all
  583.            values of that attribute, issued by this CA to/from these
  584.            entries.
  585.  
  586.    The CA is the ONLY entity with these permissions.
  587.  
  588.    An application providing LDAP repository read, LDAP repository
  589.    search, or LDAP repository modify service as defined in this
  590.    specification is NOT REQUIRED to implement any additional security
  591.    features other than those described herein, however an implementation
  592.    SHOULD do so.
  593.  
  594. 11.  References
  595.  
  596.    [1]  Yeong, Y., Howes, T. and S. Kille, "Lightweight Directory Access
  597.         Protocol", RFC 1777, March 1995.
  598.  
  599.    [2]  Howes, T., Kille, S., Yeong, W. and C. Robbins, "The String
  600.         Representation of Standard Attribute Syntaxes", RFC 1778, March
  601.         1995.
  602.  
  603.    [3]  Bradner, S., "Key Words for use in RFCs to Indicate Requirement
  604.         Levels", BCP 14, RFC 2119, March 1997.
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Boeyen, et al.              Standards Track                    [Page 11]
  619.  
  620. RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999
  621.  
  622.  
  623. 12.  Authors' Addresses
  624.  
  625.    Sharon Boeyen
  626.    Entrust Technologies Limited
  627.    750 Heron Road
  628.    Ottawa, Ontario
  629.    Canada K1V 1A7
  630.  
  631.    EMail: sharon.boeyen@entrust.com
  632.  
  633.  
  634.    Tim Howes
  635.    Netscape Communications Corp.
  636.    501 E. Middlefield Rd.
  637.    Mountain View, CA 94043
  638.    USA
  639.  
  640.    EMail: howes@netscape.com
  641.  
  642.  
  643.    Patrick Richard
  644.    Xcert Software Inc.
  645.    Suite 1001, 701 W. Georgia Street
  646.    P.O. Box 10145
  647.    Pacific Centre
  648.    Vancouver, B.C.
  649.    Canada V7Y 1C6
  650.  
  651.    EMail: patr@xcert.com
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Boeyen, et al.              Standards Track                    [Page 12]
  675.  
  676. RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999
  677.  
  678.  
  679. 13.  Full Copyright Statement
  680.  
  681.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  682.  
  683.    This document and translations of it may be copied and furnished to
  684.    others, and derivative works that comment on or otherwise explain it
  685.    or assist in its implementation may be prepared, copied, published
  686.    and distributed, in whole or in part, without restriction of any
  687.    kind, provided that the above copyright notice and this paragraph are
  688.    included on all such copies and derivative works.  However, this
  689.    document itself may not be modified in any way, such as by removing
  690.    the copyright notice or references to the Internet Society or other
  691.    Internet organizations, except as needed for the purpose of
  692.    developing Internet standards in which case the procedures for
  693.    copyrights defined in the Internet Standards process must be
  694.    followed, or as required to translate it into languages other than
  695.    English.
  696.  
  697.    The limited permissions granted above are perpetual and will not be
  698.    revoked by the Internet Society or its successors or assigns.
  699.  
  700.    This document and the information contained herein is provided on an
  701.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  702.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  703.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  704.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  705.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  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. Boeyen, et al.              Standards Track                    [Page 13]
  731.  
  732.