From: Kurt Zeilenga <kurt@openldap.org>
Date: Wed, 5 Dec 2001 23:16:35 +0000 (+0000)
Subject: Misc I-D updates
X-Git-Tag: LDBM_PRE_GIANT_RWLOCK~759
X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=8362bc91f5b761b922837fcbc8131c9956668523;p=openldap
Misc I-D updates
Misc schema updates
---
diff --git a/doc/drafts/draft-ietf-ldapext-locate-xx.txt b/doc/drafts/draft-ietf-ldapext-locate-xx.txt
index 88d6cd2b01..5df1a32760 100644
--- a/doc/drafts/draft-ietf-ldapext-locate-xx.txt
+++ b/doc/drafts/draft-ietf-ldapext-locate-xx.txt
@@ -1,7 +1,9 @@
+
+
INTERNET-DRAFT Michael P. Armijo
-<draft-ietf-ldapext-locate-04.txt> Levon Esibov
-August, 2000 Paul Leach
-Expires: February, 2001 Microsoft Corporation
+<draft-ietf-ldapext-locate-06.txt> Levon Esibov
+November 13, 2001 Paul Leach
+Expires: May 13, 2002 Microsoft Corporation
R.L. Morgan
University of Washington
@@ -32,8 +34,12 @@ Status of this Memo
ietf-ldapext-locate-04.txt>, and expires on February 25, 2001.
Please send comments to the authors.
+ Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
-1. Abstract
+Abstract
A Lightweight Directory Access Protocol (LDAP) request must be
directed to an appropriate server for processing. This document
@@ -41,7 +47,20 @@ Status of this Memo
the Domain Name System.
-2. Introduction
+
+
+
+
+
+
+
+Armijo, Esibov, Leach and Morgan [Page 1]
+
+INTERNET-DRAFT Discovering LDAP Services with DNS Novemeber 13, 2001
+
+
+
+1. Introduction
The LDAPv3 protocol [1] is designed to be a lightweight access
protocol for directory services supporting X.500 models. As a
@@ -85,13 +104,20 @@ Status of this Memo
names, and use of domain-name-based DNs is becoming common.
-3. Mapping Distinguished Names into Domain Names
+
+2. Mapping Distinguished Names into Domain Names
This section defines a method of converting a DN into a DNS domain
name for use in the server location method described below. Some
DNs cannot be converted into a domain name. Converted DNs result
in a fully qualified domain name.
+Armijo, Esibov, Leach and Morgan [Page 2]
+
+INTERNET-DRAFT Discovering LDAP Services with DNS Novemeber 13, 2001
+
+
+
The output domain name is initially empty. The DN is processed in
right-to-left order (i.e., beginning with the first RDN in the
sequence of RDNs). An RDN is able to be converted if it (1)
@@ -114,12 +140,13 @@ Status of this Memo
example.net.
The determined DNS name will be submitted as a DNS query using the
- algorithm defined in section 4.
+ algorithm defined in section 3.
-4. Locating LDAP servers through DNS
- LDAP server location information is to be stored using DNS Service
+3. Locating LDAPv3 servers through DNS
+
+ LDAPv3 server location information is to be stored using DNS Service
Location Record (SRV)[5]. The data in a SRV record contains the DNS
name of the server that provides the LDAP service, corresponding
Port number, and parameters that enable the client to choose an
@@ -128,17 +155,31 @@ Status of this Memo
_<Service>._<Proto>.<Domain>
- where <Service> is always "ldap", and <Proto> is a protocol that can
- be either "udp" or "tcp". <Domain> is the domain name formed by
- converting the DN of a naming context mastered by the LDAP Server
- into a domain name using the algorithm in Section 3. Note that
- "ldap" is the symbolic name for the LDAP service in Assigned
- Numbers[6], as required by [5].
+ where <Service> is "ldap", and <Proto> is "tcp". <Domain> is the
+ domain name formed by converting the DN of a naming context mastered
+ by the LDAP Server into a domain name using the algorithm in
+ Section 2. Note that "ldap" is the symbolic name for the LDAP
+ service in Assigned Numbers[6], as required by [5].
+
+
+
+
+
+
+
+
+
+
+Armijo, Esibov, Leach and Morgan [Page 3]
+
+INTERNET-DRAFT Discovering LDAP Services with DNS Novemeber 13, 2001
+
+
Presence of such records enables clients to find the LDAP servers
using standard DNS query [4]. A client (or server) seeking an LDAP
server for a particular DN converts that DN to a domain name using
- the algorithm of Section 3, does a SRV record query using the DNS
+ the algorithm of Section 2, does a SRV record query using the DNS
name formed as described in the preceding paragraph, and interprets
the response as described in [5] to determine a host (or hosts) to
contact. As an example, a client that searches for an LDAP server
@@ -160,6 +201,12 @@ Status of this Memo
portion of the constructed fully qualified domain name.
+
+4. IANA Considerations
+
+ This document does not require any IANA actions.
+
+
5. Security Considerations
DNS responses can typically be easily spoofed. Clients using this
@@ -168,12 +215,24 @@ Status of this Memo
intended to contact. See [7] for more information on security
threats and security mechanisms.
+ The client MUST use the server hostname it used to open the LDAP
+ connection as the value to compare against the server name as
+ expressed in the server's certificate. The client MUST NOT use the
+ server's canonical DNS name or any other derived form of name.
+
This document describes a method that uses DNS SRV records to
discover LDAP servers. All security considerations related to DNS
SRV records are inherited by this document. See the security
considerations section in [5] for more details.
+
+
+Armijo, Esibov, Leach and Morgan [Page 4]
+
+INTERNET-DRAFT Discovering LDAP Services with DNS Novemeber 13, 2001
+
+
6. References
[1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
@@ -196,9 +255,17 @@ Status of this Memo
[6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994.
- [7] Wahl, M., Alvestrand, H., Hodges, J. and Morgan, R.,
+ [7] Wahl, M., Alvestrand, H., Hodges, J. and Morgan, R.,
"Authentication Methods for LDAP", RFC 2829, May 2000.
+ [8] Hodges, J., Morgan, R., Wahl, M., "Lightweight Directory Access
+ Protocol (v3): Extension for Transport Layer Security", RFC 2830,
+ May 2000.
+
+
+
+
+
7. Authors' Addresses
@@ -217,6 +284,12 @@ Status of this Memo
Redmond, WA 98052
levone@microsoft.com
+
+
+Armijo, Esibov, Leach and Morgan [Page 5]
+
+INTERNET-DRAFT Discovering LDAP Services with DNS Novemeber 13, 2001
+
RL "Bob" Morgan
University of Washington
4545 15th Ave NE
@@ -227,7 +300,63 @@ Status of this Memo
EMail: rlmorgan@washington.edu
URI: http://staff.washington.edu/rlmorgan/
- Expires February 25, 2001
+8. Intellectual Property Statement
+
+The IETF takes no position regarding the validity or scope of any
+intellectual property or other rights that might be claimed to pertain
+to the implementation or use of the technology described in this
+document or the extent to which any license under such rights might or
+might not be available; neither does it represent that it has made any
+effort to identify any such rights. Information on the IETF's
+procedures with respect to rights in standards-track and standards-
+related documentation can be found in BCP-11. Copies of claims of
+rights made available for publication and any assurances of licenses to
+be made available, or the result of an attempt made to obtain a general
+license or permission for the use of such proprietary rights by
+implementors or users of this specification can be obtained from the
+IETF Secretariat.
+
+The IETF invites any interested party to bring to its attention any
+copyrights, patents or patent applications, or other proprietary rights
+which may cover technology that may be required to practice this
+standard. Please address the information to the IETF Executive
+Director.
+
+
+9. Full Copyright Statement
+
+Copyright (C) The Internet Society (2001). 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
+
+
+Armijo, Esibov, Leach and Morgan [Page 6]
+
+INTERNET-DRAFT Discovering LDAP Services with DNS Novemeber 13, 2001
+
+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."
+
+
+10. Expiration Date
+ This documentis filed as <draft-ietf-ldapext-locate-06.txt>, and
+ expires May 13, 2002.
+Armijo, Esibov, Leach and Morgan [Page 7]
\ No newline at end of file
diff --git a/servers/slapd/schema/core.schema b/servers/slapd/schema/core.schema
index c93fb23dbb..f09804d60f 100644
--- a/servers/slapd/schema/core.schema
+++ b/servers/slapd/schema/core.schema
@@ -137,13 +137,13 @@ attributetype ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
#
attributetype ( 2.5.4.41 NAME 'name'
- DESC 'RFC2256: common supertype of name attributes'
+ DESC 'RFC2256: common supertype of name attributes'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
attributetype ( 2.5.4.49 NAME 'distinguishedName'
- DESC 'RFC2256: common supertype of distingushed name attributes'
+ DESC 'RFC2256: common supertype of distingushed name attributes'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
@@ -152,7 +152,7 @@ attributetype ( 2.5.4.49 NAME 'distinguishedName'
#
attributetype ( 2.5.4.0 NAME 'objectClass'
- DESC 'RFC2256: object classes of the entity'
+ DESC 'RFC2256: object classes of the entity'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
@@ -162,7 +162,7 @@ attributetype ( 2.5.4.1 NAME ( 'aliasedObjectName' 'aliasedEntryName' )
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
attributetype ( 2.5.4.2 NAME 'knowledgeInformation'
- DESC 'RFC2256: knowledge information'
+ DESC 'RFC2256: knowledge information'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
@@ -368,7 +368,7 @@ attributetype ( 2.5.4.43 NAME 'initials'
DESC 'RFC2256: initials of some or all of names, but not the surname(s).'
SUP name )
-attributetype ( 2.5.4.44 NAME 'generationQualifier'
+attributetype ( 2.5.4.44 NAME 'generationQualifier'
DESC 'RFC2256: name qualifier indicating a generation'
SUP name )
@@ -567,7 +567,8 @@ objectclass ( 2.5.6.19 NAME 'cRLDistributionPoint'
MAY ( certificateRevocationList $ authorityRevocationList $
deltaRevocationList ) )
-objectclass ( 2.5.6.20 NAME 'dmd' SUP top STRUCTURAL
+objectclass ( 2.5.6.20 NAME 'dmd'
+ SUP top STRUCTURAL
MUST ( dmdName )
MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
x121Address $ registeredAddress $ destinationIndicator $
@@ -584,8 +585,9 @@ objectclass ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
DESC 'RFC2252: extensible object'
SUP top AUXILIARY )
-objectclass ( 2.5.20.1 NAME 'subschema' AUXILIARY
- DESC 'RFC2252: controlling subschema (subentry)'
+objectclass ( 2.5.20.1 NAME 'subschema'
+ DESC 'RFC2252: controlling subschema (subentry)'
+ AUXILIARY
MAY ( dITStructureRules $ nameForms $ ditContentRules $
objectClasses $ attributeTypes $ matchingRules $
matchingRuleUse ) )
@@ -599,13 +601,15 @@ objectclass ( 2.5.6.21 NAME 'pkiUser'
SUP top AUXILIARY
MUST userCertificate )
-objectclass ( 2.5.6.22 NAME 'pkiCA' SUP top AUXILIARY
+objectclass ( 2.5.6.22 NAME 'pkiCA'
DESC 'RFC2587: PKI certificate authority'
+ SUP top AUXILIARY
MAY ( authorityRevocationList $ certificateRevocationList $
cACertificate $ crossCertificatePair ) )
-objectclass ( 2.5.6.23 NAME 'deltaCRL' SUP top AUXILIARY
+objectclass ( 2.5.6.23 NAME 'deltaCRL'
DESC 'RFC2587: PKI user'
+ SUP top AUXILIARY
MAY deltaRevocationList )
@@ -699,7 +703,8 @@ objectclass ( 2.16.840.1.113730.3.2.6 NAME 'referral'
#
# LDAPsubEntry
# likely to change!
-objectclass ( 2.16.840.1.113719.2.142.6.1.1 NAME 'LDAPsubEntry'
+objectclass ( 2.16.840.1.113719.2.142.6.1.1
+ NAME 'LDAPsubEntry'
DESC 'LDAP Subentry'
SUP top STRUCTURAL MAY cn )
@@ -797,6 +802,8 @@ attributetype ( 1.3.6.1.4.1.4203.1.3.2
SYNTAX 1.3.6.1.4.1.4203.1.1.1
SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
+# OpenLDAP Access Control Information
+# Experimental
attributetype ( 1.3.6.1.4.1.4203.666.1.5
NAME 'OpenLDAPaci'
DESC 'OpenLDAP access control information (experimental)'
@@ -804,19 +811,10 @@ attributetype ( 1.3.6.1.4.1.4203.666.1.5
SYNTAX 1.3.6.1.4.1.4203.666.2.1
USAGE directoryOperation )
-#
-# Author: Ando <ando@OpenLDAP.org>
-# Subject: Monitor schema items
-# Date: 2001/07/09
-# Status: Work in Progress
-#
-
-#
# monitorSubEntry
-#
-# Notes: in 'cn' (inherited from 'LDAPsubEntry') it holds the name
-# of the subsystem it is monitoring
-#
+# Notes: in 'cn' (inherited from 'LDAPsubEntry') it holds the name
+# of the subsystem it is monitoring
+# Experimental!
#objectclass ( 1.3.6.1.4.1.4203.666.X.Y.Z
# NAME 'monitorSubEntry'
# DESC 'OpenLDAP ancestor class for system monitoring'
diff --git a/servers/slapd/schema/cosine.schema b/servers/slapd/schema/cosine.schema
index 69283fd997..6ae5c593ae 100644
--- a/servers/slapd/schema/cosine.schema
+++ b/servers/slapd/schema/cosine.schema
@@ -10,7 +10,7 @@
#
# Note: It seems that the pilot schema evolved beyond what was
# described in RFC1274. However, this document attempts to describes
-# RFC1274 as published.
+# RFC1274 as published.
#
# Depends on core.schema
@@ -1258,7 +1258,7 @@ objectclass ( 0.9.2342.19200300.100.4.14 NAME 'RFC822localPart'
#
objectclass ( 0.9.2342.19200300.100.4.15 NAME 'dNSDomain'
SUP 'domain' STRUCTURAL
- MAY ( ARecord $ MDRecord $ MXRecord $ NSRecord $
+ MAY ( ARecord $ MDRecord $ MXRecord $ NSRecord $
SOARecord $ CNAMERecord )
)
@@ -1276,6 +1276,7 @@ objectclass ( 0.9.2342.19200300.100.4.15 NAME 'dNSDomain'
# ::= {pilotObjectClass 17}
#
objectclass ( 0.9.2342.19200300.100.4.17 NAME 'domainRelatedObject'
+ DESC 'RFC1274: an object related to an domain'
SUP top AUXILIARY
MUST associatedDomain )
diff --git a/servers/slapd/schema/inetorgperson.schema b/servers/slapd/schema/inetorgperson.schema
index 3112dd265c..525a70714d 100644
--- a/servers/slapd/schema/inetorgperson.schema
+++ b/servers/slapd/schema/inetorgperson.schema
@@ -6,12 +6,12 @@
# Definition of an X.500 Attribute Type and an Object Class to Hold
# Uniform Resource Identifiers (URIs) [RFC2079]
# (core.schema)
-#
+#
# A Summary of the X.500(96) User Schema for use with LDAPv3 [RFC2256]
# (core.schema)
#
# The COSINE and Internet X.500 Schema [RFC1274] (cosine.schema)
-
+
# carLicense
# This multivalued field is used to record the values of the license or
# registration plate associated with an individual.
@@ -72,7 +72,7 @@ attributetype ( 2.16.840.1.113730.3.1.4
# Interchange Format [JFIF].
# Note that the jpegPhoto attribute type was defined for use in the
# Internet X.500 pilots but no referencable definition for it could be
-# located.
+# located.
attributetype ( 0.9.2342.19200300.100.1.60
NAME 'jpegPhoto'
DESC 'RFC2798: a JPEG image'
@@ -139,4 +139,4 @@ objectclass ( 2.16.840.1.113730.3.2.2
photo $ roomNumber $ secretary $ uid $ userCertificate $
x500uniqueIdentifier $ preferredLanguage $
userSMIMECertificate $ userPKCS12 )
- )
+ )