< draft-ietf-ldapext-sigops-03.txt		draft-ietf-ldapext-sigops-04.txt >
	LDAP Extensions Working Group Bruce Greenblatt		LDAP Extensions Working Group Bruce Greenblatt
	Internet Draft Pat Richard		Internet Draft Pat Richard
	<draft-ietf-ldapext-sigops-03.txt>		<draft-ietf-ldapext-sigops-04.txt>
	Expires in six months		Expires in six months
	Signed Directory Operations Using S/MIME		An LDAP Control and Schema for Holding Operation Signatures
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas, and		documents of the Internet Engineering Task Force (IETF), its areas, and
	its working groups. Note that other groups may also distribute working		its working groups. Note that other groups may also distribute working
	documents as Internet-Drafts.		documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months. Internet-Drafts may be updated, replaced, or made obsolete by		months. Internet-Drafts may be updated, replaced, or made obsolete by
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	Abstract		Abstract
	In many environments clients require the ability to validiate the		In many environments clients require the ability to validiate the
	source and integrity of information provided by the directory. This		source and integrity of information provided by the directory. This
	document describes an LDAP message control which allows for the		document describes an LDAP message control which allows for the
	retrieval of digitally signed information. This document defines an LDAP		retrieval of digitally signed information. This document defines an LDAP
	v3 based mechanism for signing directory operations in order to create a		v3 based mechanism for signing directory operations in order to create a
	secure journal of changes that have been made to each directory entry.		secure journal of changes that have been made to each directory entry.
	Both client and server based signatures are supported. An object class		Both client and server based signatures are supported. An object class
	for subsequent retrieval are 'journal entries' is also defined. This		for subsequent retrieval are "journal entries" is also defined. This
	document specifies LDAP v3 controls that enable this functionality. It		document specifies LDAP v3 controls that enable this functionality. It
	also defines an LDAP v3 schema that allows for subsequent browsing of		also defines an LDAP v3 schema that allows for subsequent browsing of
	the journal information.		the journal information.
	1. Introduction		1. Introduction
			This document is an Internet-Draft and is in full conformance with
			all provisions of Section 10 of RFC2026.
	In many environments clients require the ability to validiate the		In many environments clients require the ability to validiate the
	source and integrity of information provided by the directory. This		source and integrity of information provided by the directory. This
	document describes an LDAP message control which allows for the		document describes an LDAP message control which allows for the
	retrieval of digitally signed information. The perspective of this doc-		retrieval of digitally signed information. The perspective of this doc-
	ument is that the origin of the information that is stored in LDAP v3		ument is that the origin of the information that is stored in LDAP v3
	accessible directories is the LDAP v3 client that creates the informa-		accessible directories is the LDAP v3 client that creates the informa-
	tion. The source and integrity of the information is guaranteed by		tion. The source and integrity of the information is guaranteed by
	allowing for the digital signing of the operations that make changes to		allowing for the digital signing of the operations that make changes to
	entries in the directory. The source and integrity of an individual		entries in the directory. The source and integrity of an individual
	LDAP connection can be guaranteed by making use of an underlying session		LDAP connection can be guaranteed by making use of an underlying session
	skipping to change at page 7, line 12 ¶		skipping to change at page 7, line 12 ¶
	the LDAP client is allowed to ignore it. The signature field below		the LDAP client is allowed to ignore it. The signature field below
	includes the signature of the enitre LDAPResult formatted as an S/MIME		includes the signature of the enitre LDAPResult formatted as an S/MIME
	pkcs-7/signature object, as defined in [2]. The procedure for creating		pkcs-7/signature object, as defined in [2]. The procedure for creating
	the signature of the signedResult control is the same as the procedure		the signature of the signedResult control is the same as the procedure
	for the creation of the signedOperation control. The LDAP control in		for the creation of the signedOperation control. The LDAP control in
	the LDAP response is (OID = 1.2.840.113549.6.0.2):		the LDAP response is (OID = 1.2.840.113549.6.0.2):
	SignedResult ::= CHOICE {		SignedResult ::= CHOICE {
	signature OCTET STRING }		signature OCTET STRING }
	Do there need to be other kinds of signed results???		3. Security Considerations and Other Notes
	3. Notes
	The base OIDs are:		The base OIDs are:
	rsadsiLdap ::= {1 2 840 113549 6}		rsadsiLdap ::= {1 2 840 113549 6}
	rsadsiLdapControls ::= {1 2 840 113549 6 0}		rsadsiLdapControls ::= {1 2 840 113549 6 0}
	rsadsiLdapObjectClasses ::= {1 2 840 113549 6 1}		rsadsiLdapObjectClasses ::= {1 2 840 113549 6 1}
	rsadsiLdapAttributes ::= {1 2 840 113549 6 2}		rsadsiLdapAttributes ::= {1 2 840 113549 6 2}
	The complete ASN.1 module for this specification is:		The complete ASN.1 module for this specification is:
	skipping to change at page 8, line 4 ¶		skipping to change at page 7, line 43 ¶
	signedOperation [1] OCTET STRING }		signedOperation [1] OCTET STRING }
	DemandSignedResult ::= LDAPSigType		DemandSignedResult ::= LDAPSigType
	LDAPSigType ::= BOOLEAN		LDAPSigType ::= BOOLEAN
	SignedResult ::= CHOICE {		SignedResult ::= CHOICE {
	signature OCTET STRING }		signature OCTET STRING }
	END		END
	If any of the controls in this specification are supported by an		If any of the controls in this specification are supported by an
	LDAP v3 server then that server MUST make available its certificate (if		LDAP v3 server then that server MUST make available its certificate (if
	any) in the userCertificate attribute of its rootDSE object. The		any) in the userCertificate attribute of its rootDSE object. The
	UserCertificate attribute is defined in [6], and contains the public key		UserCertificate attribute is defined in [6], and contains the public key
	of the server that is used in the creation of the various signatures		of the server that is used in the creation of the various signatures
	defined in this specification.		defined in this specification.
	It is not the intention of this specification to provide a mecha-		It is not the intention of this specification to provide a mecha-
	nism that guarantees the origin and integrity of LDAP v3 operations.		nism that guarantees the origin and integrity of LDAP v3 operations.
	Such a service is best provided by the use of an underlying protocol		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		such as TLS [8]. TLS defines additional features such as encryption and
	compression. This specification does not define support for encrypted		compression. This specification does not define support for encrypted
	operations.		operations.
			This draft 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 sig-
			natures 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. Secu-
			rity considerations are discussed throughout this draft.
	4. References		4. References
	[1] RFC 2315 PKCS 7: Cryptographic Message Syntax Version 1-5. B.		[1] RFC 2315 PKCS 7: Cryptographic Message Syntax Version 1-5. B.
	Kaliski. March 1998.		Kaliski. March 1998.
	[2] RFC 2311 S/MIME Version 2 Message Specification. S. Dusse, P.		[2] RFC 2311 S/MIME Version 2 Message Specification. S. Dusse, P.
	Hoffman, B. Ramsdell, L. Lundblade, L. Repka. March 1998.		Hoffman, B. Ramsdell, L. Lundblade, L. Repka. March 1998.
	[3] RFC 1847 Security Multiparts for MIME: Multipart/Signed and		[3] RFC 1847 Security Multiparts for MIME: Multipart/Signed and
	Multipart/Encrypted. J. Galvin, S. Murphy, S. Crocker & N. Freed. Octo-		Multipart/Encrypted. J. Galvin, S. Murphy, S. Crocker & N. Freed. Octo-
	skipping to change at page 9, line 4 ¶		skipping to change at page 9, line 6 ¶
	[6] RFC 2256 A Summary of the X.500(96) User Schema for use with		[6] RFC 2256 A Summary of the X.500(96) User Schema for use with
	LDAPv3. M. Wahl. December 1997.		LDAPv3. M. Wahl. December 1997.
	[7] RFC 2255 The LDAP URL Format. T. Howes, M. Smith. December		[7] RFC 2255 The LDAP URL Format. T. Howes, M. Smith. December
	1997.		1997.
	[8] Internet Draft, work in progress, "The TLS Protocol Version		[8] Internet Draft, work in progress, "The TLS Protocol Version
	1.0", Tim Dierks, Chris Allen., 11/12/1997.		1.0", Tim Dierks, Chris Allen., 11/12/1997.
	5. Author's Addresses		5. Author's Addresses
	Bruce Greenblatt		Bruce Greenblatt
	San Jose, CA 95119		San Jose, CA 95119
	USA		USA
	Email: bruceg@innetix.com		Email: bgreenblatt@directory-applications.com
	Phone: +1-408-224-5349		Phone: +1-408-224-5349
	Pat Richard		Pat Richard
	Xcert Software, Inc.		Xcert Software, Inc.
	Suite 1001 - 701 W. Georgia		Suite 1001 - 701 W. Georgia
	Vancouver, BC		Vancouver, BC
	CANADA V6G 1C9		CANADA V6G 1C9
	Email: patr@xcert.com		Email: patr@xcert.com
	Table of Contents		TTaabbllee ooff CCoonntteennttss
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1 Audit Trail Mechanism . . . . . . . . . . . . . . . . . . . . . 2		1.1 Audit Trail Mechanism . . . . . . . . . . . . . . . . . . . . . 2
	1.2. Handling the Delete Operation . . . . . . . . . . . . . . . . . 5		1.2. Handling the Delete Operation . . . . . . . . . . . . . . . . . 5
	2. Signed Results Mechanism . . . . . . . . . . . . . . . . . . . . 6		2. Signed Results Mechanism . . . . . . . . . . . . . . . . . . . . 6
	3. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3. Security Considerations and Other Notes . . . . . . . . . . . . 7
	4. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8		4. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	5. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8		5. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
End of changes. 12 change blocks.
	9 lines changed or deleted		22 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/