rfc2559.txt

RFC 的详细文档！

     UnbindRequest

   The subset of each operation REQUIRED is given below.

7.1.  Bind

   The full LDAP v2 Bind Request is defined in RFC 1777.

   An application providing a LDAP repository modify service MUST
   implement the following subset of this operation:

      BindRequest ::=
        [APPLICATION 0] SEQUENCE {
           version      INTEGER (2),
           name         LDAPDN,
           simpleauth [0] OCTET STRING
           }

   A LDAP repository modify service MUST implement authenticated access.

   The BindResponse subsets needed are the same as those described in
   Section 5.1.2.





Boeyen, et al.              Standards Track                     [Page 7]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999


7.2.  Modify

7.2.1.  Modify Request

   The full LDAPv2 ModifyRequest is defined in RFC 1777.

   An application providing a LDAP repository modify service MUST
   implement the following subset of the ModifyRequest protocol unit.

      ModifyRequest ::=
        [APPLICATION 6] SEQUENCE {
       object         LDAPDN,
       modification   SEQUENCE OF SEQUENCE {
                        operation     ENUMERATED {
                                        add     (0),
                                        delete  (1)
                                      },
                        modification  SEQUENCE {
                                      type   AttributeType,
                                      values SET OF
                                             AttributeValue
                                      }
                      }
        }

   All aspects of the ModifyRequest MUST be supported, except for the
   following:

   - Only the add and delete values of operation need to be supported

7.2.2.  Modify Response

   The full LDAPv2 ModifyResponse is defined in RFC 1777.

   An application providing a LDAP repository modify service MUST
   implement the full ModifyResponse.

7.3.  Add

7.3.1.  Add Request

   The full LDAPv2 AddRequest is defined in RFC 1777.

   An application providing a LDAP repository modify service MUST
   implement the full AddRequest.






Boeyen, et al.              Standards Track                     [Page 8]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999


7.3.2.  Add Response

   The full LDAPv2 AddResponse is defined in RFC 1777.

   An application providing a LDAP repository modify service MUST
   implement the full AddResponse.

7.4.  Delete

7.4.1.  Delete Request

   The full LDAPv2 DelRequest is defined in RFC 1777.

   An application providing a LDAP repository modify service MUST
   implement the full DelRequest.

7.4.2.  Delete Response

   The full LDAPv2 DelResponse is defined in RFC 1777.

   An application providing a LDAP repository modify service MUST
   implement the full DelResponse.

7.5.  Unbind

   An application providing a LDAP repository modify service MUST
   implement the full UnbindRequest.

8.  Non-standard attribute value encodings

   When conveyed in LDAP requests and results, attributes defined in
   X.500 are to be encoded using string representations defined in RFC
   1778, The String Representation of Standard Attribute Syntaxes.
   These string encodings were based on the attribute definitions from
   X.500(1988).  Thus, the string representations of the PKI information
   elements are for version 1 certificates and version 1 revocation
   lists.  Since this specification uses version 3 certificates and
   version 2 revocation lists, as defined in X.509(1997), the RFC 1778
   string encoding of these attributes is inappropriate.

   For this reason, these attributes MUST be encoded using a syntax
   similar to the syntax "Undefined" from section 2.1 of RFC 1778:
   values of these attributes are encoded as if they were values of type
   "OCTET STRING", with the string value of the encoding being the DER-
   encoding of the value itself.  For example, when writing a
   userCertificate to the repository, the CA generates a DER-encoding of
   the certificate and uses that encoding as the value of the
   userCertificate attribute in the LDAP Modify request.This encoding



Boeyen, et al.              Standards Track                     [Page 9]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999


   style is consistent with the encoding scheme proposed for LDAPv3,
   which is now being defined within the IETF.

   Note that certificates and revocation lists will be transferred using
   this mechanism rather than the string encodings in RFC 1778 and
   client systems which do not understand this encoding may experience
   problems with these attributes.

9.  Transport

   An application providing a LDAP repository read service, LDAP
   repository search service, or LDAP repository modify service MUST
   support LDAPv2 transport over TCP, as defined in Section 3.1 of RFC
   1777.

   An application providing a LDAP repository read service, LDAP
   repository search service, or LDAP repository modify service MAY
   support LDAPv2 transport over other reliable transports as well.

10.  Security Considerations

   Since the elements of information which are key to the PKI service
   (certificates and CRLs) are both digitally signed pieces of
   information, additional integrity service is NOT REQUIRED.  As
   neither information element need be kept secret and anonymous access
   to such information, for retrieval purposes is generally acceptable,
   privacy service is NOT REQUIRED for information retrieval requests.

   CAs have additional requirements, including modification of PKI
   information.  Simple authentication alone is not sufficient for these
   purposes. It is RECOMMENDED that some stronger means of
   authentication and/or (if simple authentication is used) some means
   of protecting the privacy of the password is used, (e.g.  accept
   modifications only via physically secure networks, use IPsec, use SSH
   or TLS or SSL tunnel). Without such authentication, it is possible
   that a denial-of-service attack could occur where the attacker
   replaces valid certificates with bogus ones.

   For the LDAP repository modify service, profiled in section 7, there
   are some specific security considerations with respect to access
   control. These controls apply to a repository which is under the same
   management control as the CA. Organizations operating directories are
   NOT REQUIRED to provide external CAs access permission to their
   directories.







Boeyen, et al.              Standards Track                    [Page 10]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999


   The CA MUST have access control permissions allowing it to:

      For CA entries:
         - add, modify and delete all PKI attributes for its own
           directory entry;
         - add, modify and delete all values of these attributes.

      For CRL distribution point entries (if used):
         - create, modify and delete entries of object class
           cRLDistributionPoint immediately subordinate to its own
           entry;
         - add, modify and delete all attributes, and all values of
           these attributes for these entries.

      For subscriber (end-entity) entries:
         - add, modify and delete the attribute userCertificate and all
           values of that attribute, issued by this CA to/from these
           entries.

   The CA is the ONLY entity with these permissions.

   An application providing LDAP repository read, LDAP repository
   search, or LDAP repository modify service as defined in this
   specification is NOT REQUIRED to implement any additional security
   features other than those described herein, however an implementation
   SHOULD do so.

11.  References

   [1]  Yeong, Y., Howes, T. and S. Kille, "Lightweight Directory Access
        Protocol", RFC 1777, March 1995.

   [2]  Howes, T., Kille, S., Yeong, W. and C. Robbins, "The String
        Representation of Standard Attribute Syntaxes", RFC 1778, March
        1995.

   [3]  Bradner, S., "Key Words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.













Boeyen, et al.              Standards Track                    [Page 11]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999


12.  Authors' Addresses

   Sharon Boeyen
   Entrust Technologies Limited
   750 Heron Road
   Ottawa, Ontario
   Canada K1V 1A7

   EMail: [e-mail]


   Tim Howes
   Netscape Communications Corp.
   501 E. Middlefield Rd.
   Mountain View, CA 94043
   USA

   EMail: [e-mail]


   Patrick Richard
   Xcert Software Inc.
   Suite 1001, 701 W. Georgia Street
   P.O. Box 10145
   Pacific Centre
   Vancouver, B.C.
   Canada V7Y 1C6

   EMail: [e-mail]






















Boeyen, et al.              Standards Track                    [Page 12]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999


13.  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.
























Boeyen, et al.              Standards Track                    [Page 13]