doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc2649.txt b/doc/rfc/rfc2649.txt
new file mode 100644
index 0000000..fb5f38e
--- /dev/null
+++ b/doc/rfc/rfc2649.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                       B. Greenblatt
+Request for Comments: 2649                                     P. Richard
+Category: Experimental                                        August 1999
+
+
+      An LDAP Control and Schema for Holding Operation Signatures
+
+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
+
+   In many environments clients require the ability to validiate the
+   source and integrity of information provided by the directory.  This
+   document describes an LDAP message control which allows for the
+   retrieval of digitally signed information. This document defines an
+   LDAP v3 based mechanism for signing directory operations in order to
+   create a secure journal of changes that have been made to each
+   directory entry.  Both client and server based signatures are
+   supported.  An object class for subsequent retrieval are "journal
+   entries" is also defined.  This document specifies LDAP v3 controls
+   that enable this functionality.  It also defines an LDAP v3 schema
+   that allows for subsequent browsing of the journal information.
+
+Table of Contents
+
+   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   1.1 Audit Trail Mechanism  . . . . . . . . . . . . . . . . . . .   2
+   1.2. Handling the Delete Operation . . . . . . . . . . . . . . .   5
+   2. Signed Results Mechanism  . . . . . . . . . . . . . . . . . .   6
+   3. Security Considerations and Other Notes   . . . . . . . . . .   7
+   4. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
+   5. Authors' Addresses  . . . . . . . . . . . . . . . . . . . . .   9
+   6. Full Copyright Statement  . . . . . . . . . . . . . . . . . .  10
+
+
+
+
+
+
+
+
+
+Greenblatt & Richard          Experimental                      [Page 1]
+
+RFC 2649                LDAP Control and Schema              August 1999
+
+
+1.  Introduction
+
+   In many environments clients require the ability to validiate the
+   source and integrity of information provided by the directory.  This
+   document describes an LDAP message control which allows for the
+   retrieval of digitally signed information.  The perspective of this
+   document is that the origin of the information that is stored in LDAP
+   v3 accessible directories is the LDAP v3 client that creates the
+   information.  The source and integrity of the information is
+   guaranteed by allowing for the digital signing of the operations that
+   make changes to entries in the directory.  The source and integrity
+   of an individual LDAP connection can be guaranteed by making use of
+   an underlying session layer that provides such services, such as TLS.
+   Note that the integrity of an individual connection does not, in and
+   of itself guarantee the integrity of the data that comes across the
+   connection.  This is due to the fact that the LDAP server is only
+   capable of providing information that it has stored.  In distributed
+   and replicated environments, the fact that an entry has been
+   successfully retrieved from a server may not be completely
+   reassuring, if the entry in question was replicated from an untrusted
+   domain.
+
+   By making use of public key technology, and creating digitally signed
+   transactions that are created by the LDAP v3 client as entries are
+   created and modified, a complete journal of the history of the entry
+   is available.  Since each entry in the journal has been digitally
+   signed with the private key of the creator, or modifier of the entry,
+   the source and integrity of the directory entry can be validated by
+   verifying the signature of each entry in the journal.  Note that not
+   all of the journal entries will have been signed by the same user.
+
+1.1.  Audit Trail Mechanism
+
+   Signed directory operations is a straightforward application of
+   S/MIME technology that also leverages the extensible framework that
+   is provided by LDAP version 3.  LDAP version 3 is defined in [4], and
+   S/MIME is defined in [2].  The security used in S/MIME is based in
+   the definitions in [1].  The basic idea is that the submitter of an
+   LDAP operation that changes the directory information includes an
+   LDAP version 3 control that includes either a signature of the
+   operation, or a request that the LDAP server sign the operation on
+   the behalf of the LDAP client.  The result of the operation (in
+   addition to the change of the directory information), is additional
+   information that is attached to directory objects, that includes the
+   audit trail of signed operations.  The LDAP control is (OID =
+   1.2.840.113549.6.0.0):
+
+
+
+
+
+Greenblatt & Richard          Experimental                      [Page 2]
+
+RFC 2649                LDAP Control and Schema              August 1999
+
+
+      SignedOperation ::= CHOICE {
+           signbyServer   NULL,
+           signatureIncluded   OCTET STRING
+       }
+
+   If the SignatureIncluded CHOICE is used, then the OCTET string is
+   just an S/MIME message of the multipart/signed variety, that is
+   composed of a single piece, that is the signature of the directory
+   operation.  Multipart/signed MIME objects are defined in [3].  If the
+   SignbyServer CHOICE us used, then the LDAP server creates the
+   signature on behalf of the client, using its own identity and not the
+   identity of the client, in order to produce the audit trail entry.
+   In either case the successful result of processing the control is the
+   creation of additional information in the directory entry that is
+   being modified or created. The signature of the LDAP operation is
+   computed on the LDAPMessage prior to the inclusion of the
+   SignedOperation control. The procedure is as follows:
+
+      - Build LDAPMessage without the SignedOperation control
+      - Compute signature on the above LDAPMessage
+      - Create new LDAPMessage that includes the old MessageID,
+        protocolOp and any control fields from the previous LDAPMessage,
+        plus  the computed signature formatted as an S/MIME message.
+
+   No control is defined for the server to return in the LDAPResult as
+   defined in [4].  The LDAP server MAY attempt to parse and verify the
+   signature included in the SignedOperation control, but is not
+   required to.  The server can accept the signed operation without
+   verifying the signature.  Signature verification can be quite a
+   lengthy operation, requiring complex certificate chain traversals.
+   This allows a more timely creation of the audit trail by the server.
+   Any LDAP client browsing the directory that retrieves the 'Changes'
+   (defined in the following paragraphs) attributes, should verify the
+   signature of each value according to the local signature verification
+   policies.  Even if the LDAP server verifies the signature contained
+   in the singed operation, the LDAP client has no way of knowing what
+   policies were followed by the server in order to verify the
+   signature.
+
+   If the LDAP server is unable to verify the signature and wishes to
+   return an error then the error code unwillingToPerform(53) should be
+   returned, and the entire LDAP operation fails.  In this situation, an
+   appropriate message (e.g. "Unable to verify signature") MAY be
+   included in the errorMessage of the LDAPResult.  The SignedOperation
+   Control MAY be marked CRITICAL, and if it is CRITICAL then if the
+   LDAP Server performs the LDAP operation, then must include the
+   signature in the signedAuditTrail information.
+
+
+
+
+Greenblatt & Richard          Experimental                      [Page 3]
+
+RFC 2649                LDAP Control and Schema              August 1999
+
+
+      The schema definition for the signedAuditTrail information is:
+
+      ( 1.2.840.113549.6.1.0
+      NAME 'signedAuditTrail'
+      SUP top
+      AUXILIARY
+      MUST (
+      Changes
+      )
+         )
+
+      The format of the Changes attribute is:
+
+      ( 1.2.840.113549.6.2.0
+      NAME 'Changes'
+      DESC 'a set of changes applied to an entry'
+      SYNTAX 'Binary' )
+
+      The actual format of the Changes attribute is:
+
+      Changes ::= SEQUENCE {
+           sequenceNumber [0] INTEGER (0 .. maxInt),
+           signedOperation [1] OCTET STRING }
+
+   The SignedOperation attribute is a multipart/signed S/MIME message.
+   Part 1 of the message is the directory operation, and part 2 is the
+   signature.  Sequence number 0 (if present) always indicates the
+   starting point directory object as represented by the definitions in
+   "A MIME Content-Type for Directory Information", as defined in [5].
+   Subsequent sequence numbers indicate the sequence of changes that
+   have been made to this directory object.  Note that the sequence of
+   the changes can be verified due to the fact that the signed directory
+   object will have a timestamp as part of the signature object, and
+   that the sequence numbering as part of the change attribute should be
+   considered to be an unverified aid to the LDAP client.  Sequence
+   numbers are meaningful only within the context of a single directory
+   entry, and LDAP servers are not expected to maintain these sequence
+   numbers across all entries in the directory.
+
+   Some LDAP servers will only allow operations that include the
+   SignedOperation control.  This is indicated by the inclusion of a
+   'signedDirectoryOperationSupport' attribute in the rootDSE.  This
+   attribute is defined as:
+
+
+
+
+
+
+
+
+Greenblatt & Richard          Experimental                      [Page 4]
+
+RFC 2649                LDAP Control and Schema              August 1999
+
+
+      1.2.840.113549.6.2.2
+      NAME 'signedDirectoryOperationSupport'
+      DESC 'how many of the LDAP operations must be signed'
+      SYNTAX 'Integer' SINGLE-VALUE )
+
+   The 'signedDirectoryOperationSupport' attribute above may have one of
+   the values, '0', '1' or '2' with the following meanings:
+
+      - '0' Directory Operations may be signed
+      - '1' Directory Operations must always be signed
+      - '2' Directory Operations must never be signed
+
+   Some LDAP servers will desire that the audit trail be continuous, and
+   not contain any gaps that would result from unsigned operations.
+   Such server will include a signature on each LDAP operation that
+   changes a directory entry, even when the LDAP client does not include
+   a signed-Operation control.
+
+1.2.  Handling the Delete Operation
+
+   The LDAP Delete operation represents an interesting case for Signed
+   Directory Operations.  This is due to the case that subsequent to the
+   successful completion of the Delete Operation, the object that would
+   have held the latest 'Changes' attribute no longer exists.  In order
+   to handle this situation, a new object class is defined to represent
+   a directory object that has been deleted.
+
+      ( 1.2.840.113549.6.1.2
+      NAME 'zombieObject'
+      SUP top
+      STRUCTURAL
+      MUST (
+      Cn $ Changes $ OriginalObject
+      )
+         )
+
+      The format of the OriginalObject attribute is:
+
+      ( 1.2.840.113549.6.2.1
+      NAME OriginalObject
+      DESC 'The LDAP URL of an object that has been deleted from the
+      directory' SYNTAX 'Binary' )
+
+   The OriginalObject attribute contains the URL of the object that was
+   deleted from the directory.  It is formatted in accordance with RFC
+   2255.  Directory servers that comply with this specification SHOULD
+   create a zombieObject when performing the delete Operation that
+   contains a SignedOperation LDAPControl.  The Cn attribute of the
+
+
+
+Greenblatt & Richard          Experimental                      [Page 5]
+
+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: +1-408-224-5349
+   EMail: bgreenblatt@directory-applications.com
+
+
+   Pat Richard
+   Xcert Software, Inc.
+   Suite 1001 - 701 W. Georgia
+   Vancouver, BC
+   CANADA V6G 1C9
+
+   EMail: patr@xcert.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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]
+