rfc2649.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 564 行 · 第 1/2 页


RFC 2649                LDAP Control and Schema              August 1999


   zombieObject is synthesized by the LDAP server, and may or may not be
   related to the original name of the directory entry that was deleted.
   All changes attributes that were attached to the original entry are
   copied over to the zombieObject.  In addition the LDAP Server MUST
   attach the signature of the Delete operation as the last successful
   change that was made to the entry.

2.  Signed Results Mechanism

   A control is also defined that allows the LDAP v3 client to request
   that the server sign the results that it returns.  It is intended
   that this control is primarily used in concert with the LDAPSearch
   operation.  This control MAY be marked as CRITICAL.  If it is marked
   as CRITICAL and the LDAP Server supports this operation, then all
   search results MUST be returned with a signature as attached in the
   SignedResult control if it is willing to sign results for this user.
   If the server supports this control but does not wish to sign the
   results for this user then the error code unwillingToPerform(53)
   should be returned, and the LDAP search will have failed.  In this
   situation, an appropriate message (e.g. "Unwilling to sign results
   for you!") MUST be included in the errorMessage of the LDAPResult.
   If the LDAPSigType has the value FALSE then the client is requesting
   that the server not sign this operation.  This may be done in
   situations where servers are configured to always sign their
   operations.

   The LDAP control to include in the LDAP request is (OID =
   1.2.840.113549.6.0.1):

      DemandSignedResult ::=  LDAPSigType

      LDAPSigType ::= BOOLEAN

   In response to a DemandSignedResult control, the LDAP v3 server will
   return a SignedResult control in addition to the normal result as
   defined by the operation (assuming that the server understands the
   con- trol, and is willing to perform it).  The SignedResult control
   MUST NOT be marked CRITICAL.  Some LDAP v3 servers may be configured
   to sign all of their operations.  In this situation the server always
   returns a SignedResult control, unless instructed otherwise by the
   DemandSigne-dResult Control.  Since the SignedResult control is not
   marked critical, the LDAP client is allowed to ignore it.  The
   signature field below includes the signature of the enitre LDAPResult
   formatted as an S/MIME pkcs-7/signature object, as defined in [2].







Greenblatt & Richard          Experimental                      [Page 6]

RFC 2649                LDAP Control and Schema              August 1999


   The procedure for creating the signature of the signedResult control
   is the same as the procedure for the creation of the signedOperation
   control.  The LDAP control in the LDAP response is (OID =
   1.2.840.113549.6.0.2):

      SignedResult ::= CHOICE {
           signature     OCTET STRING }

3.  Security Considerations and Other Notes

      The base OIDs are:

      rsadsiLdap ::= {1 2 840 113549 6}
      rsadsiLdapControls ::=  {1 2 840 113549 6 0}
      rsadsiLdapObjectClasses ::= {1 2 840 113549 6 1}
      rsadsiLdapAttributes ::= {1 2 840 113549 6 2}


      The complete ASN.1 module for this specification is:

      SIGNEDOPERATIONS DEFINITIONS ::=
      BEGIN

      SignedOperation ::= CHOICE {
           signbyServer   NULL,
           signatureIncluded   OCTET STRING
       }

      Changes ::= SEQUENCE {
           sequenceNumber [0] INTEGER (0 .. maxInt),
           signedOperation [1] OCTET STRING }

      DemandSignedResult ::=  LDAPSigType

      LDAPSigType ::= BOOLEAN

      SignedResult ::= CHOICE {
           signature     OCTET STRING }


      END










Greenblatt & Richard          Experimental                      [Page 7]

RFC 2649                LDAP Control and Schema              August 1999


   If any of the controls in this specification are supported by an LDAP
   v3 server then that server MUST make available its certificate (if
   any) in the userCertificate attribute of its rootDSE object.  The
   UserCertificate attribute is defined in [6], and contains the public
   key of the server that is used in the creation of the various
   signatures defined in this specification.

   It is not the intention of this specification to provide a mechanism
   that guarantees the origin and integrity of LDAP v3 operations.  Such
   a service is best provided by the use of an underlying protocol such
   as TLS [8].  TLS defines additional features such as encryption and
   compression.  This specification does not define support for
   encrypted operations.

   This memo proposes protocol elements for transmission and storage of
   the digital signatures of LDAP operations.  Though the LDAP server
   may have verified the operation signatures prior to their storage and
   subsequent retrieval, it is prudent for LDAP clients to verify the
   signatures contained in the chained attribute upon their retrieval.
   The issuing Certification Authorities of the signer's certificate
   should also be consulted in order to determine if the signer's
   private key has been compromised or the certificate has been
   otherwise revoked.  Security considerations are discussed throughout
   this memo.

4.  References

   [1] Kaliski, B., "PKCS 7: Cryptographic Message Syntax Version 1-5",
       RFC 2315, March 1998.

   [2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and L.
       Repka., "S/MIME Version 2 Message Specification", RFC 2311, March
       1998.

   [3] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security
       Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
       RFC 1847, October 1995.

   [4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
       Protocol (v3)", RFC 2251, December 1997.

   [5] Howes, T., Smith, M. and F. Dawson, "A MIME Content-Type for
       Directory Information", RFC 2425, September 1998.

   [6] Wahl, M., "A Summary of the X.500(96) User Schema for use with
       LDAPv3", RFC 2256, December 1997.





Greenblatt & Richard          Experimental                      [Page 8]

RFC 2649                LDAP Control and Schema              August 1999


   [7] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December
       1997.

   [8] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
       2246, January 1999.

5.  Authors' Addresses

   Bruce Greenblatt
   San Jose, CA 95119
   USA

   Phone: [phone]
   EMail: [e-mail]


   Pat Richard
   Xcert Software, Inc.
   Suite 1001 - 701 W. Georgia
   Vancouver, BC
   CANADA V6G 1C9

   EMail: [e-mail]




























Greenblatt & Richard          Experimental                      [Page 9]

RFC 2649                LDAP Control and Schema              August 1999


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



















Greenblatt & Richard          Experimental                     [Page 10]