1
2
3
4
5
6
7Network Working Group                                        K. Zeilenga
8Request for Comments: 5020                                 Isode Limited
9Category: Standards Track                                    August 2007
10
11
12       The Lightweight Directory Access Protocol (LDAP) entryDN
13                         Operational Attribute
14
15Status of This Memo
16
17   This document specifies an Internet standards track protocol for the
18   Internet community, and requests discussion and suggestions for
19   improvements.  Please refer to the current edition of the "Internet
20   Official Protocol Standards" (STD 1) for the standardization state
21   and status of this protocol.  Distribution of this memo is unlimited.
22
23Copyright Notice
24
25   Copyright (C) The IETF Trust (2007).
26
27Abstract
28
29   This document describes the Lightweight Directory Access Protocol
30   (LDAP) / X.500 'entryDN' operational attribute.  The attribute
31   provides a copy of the entry's distinguished name for use in
32   attribute value assertions.
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58Zeilenga                    Standards Track                     [Page 1]
59
60RFC 5020                      LDAP entryDN                   August 2007
61
62
631.  Background and Intended Use
64
65   In X.500 Directory Services [X.501], such as those accessible using
66   the Lightweight Directory Access Protocol (LDAP) [RFC4510], an entry
67   is identified by its distinguished name (DN) [RFC4512].  However, as
68   an entry's DN is not an attribute of the entry, it is not possible to
69   perform attribute value assertions [RFC4511] against it.
70
71   This document describes the 'entryDN' operational attribute which
72   holds a copy of the entry's distinguished name.  This attribute may
73   be used in search filters.  For instance, searching the subtree
74   <dc=example,dc=com> with the filter:
75
76      (entryDN:componentFilterMatch:=or:{
77          item:{ component "3", rule rdnMatch, value "ou=A" },
78          item:{ component "3", rule rdnMatch, value "ou=B" } })
79
80   would return entries in the subtree <ou=A,dc=example,dc=com> and
81   entries in subtree <ou=B,dc=example,dc=com>, but would not return any
82   other entries in the subtree <dc=example,dc=com>.
83
84   In the above paragraph, DNs are presented using the string
85   representation defined in [RFC4514], and the example search filter is
86   presented using the string representation defined in [RFC4515] with
87   whitespace (line breaks and indentation) added to improve
88   readability.  The 'componentFilterMatch' and 'rdnMatch' rules are
89   specified in [RFC3687].
90
91   Schema definitions are provided using LDAP description formats
92   [RFC4512].  Definitions provided here are formatted (line wrapped)
93   for readability.
94
952.  'entryDN' Operational Attribute
96
97   The 'entryDN' operational attribute provides a copy of the entry's
98   current DN.
99
100   The following is an LDAP attribute type description suitable for
101   publication in subschema subentries.
102
103      ( 1.3.6.1.1.20 NAME 'entryDN'
104          DESC 'DN of the entry'
105          EQUALITY distinguishedNameMatch
106          SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
107          SINGLE-VALUE
108          NO-USER-MODIFICATION
109          USAGE directoryOperation )
110
111
112
113
114Zeilenga                    Standards Track                     [Page 2]
115
116RFC 5020                      LDAP entryDN                   August 2007
117
118
119   Note that the DN of the entry cannot be modified through this
120   attribute.
121
1223.  Security Considerations
123
124   As this attribute only provides an additional mechanism to access an
125   entry's DN, the introduction of this attribute is not believed to
126   introduce new security considerations.
127
1284.  IANA Considerations
129
1304.1.  Object Identifier Registration
131
132   IANA has registered (upon Standards Action) an LDAP Object Identifier
133   [RFC4520] for use in this document.
134
135      Subject: Request for LDAP OID Registration
136      Person & email address to contact for further information:
137          Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
138      Specification: RFC 5020
139      Author/Change Controller: IESG
140      Comments:
141          Identifies the 'entryDN' attribute type
142
1434.2.  'entryDN' Descriptor Registration
144
145   IANA has registered (upon Standards Action) the LDAP 'entryDN'
146   descriptor [RFC4520].
147
148      Subject: Request for LDAP Descriptor Registration
149      Descriptor (short name): entryDN
150      Object Identifier: 1.3.6.1.1.20
151      Person & email address to contact for further information:
152          Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
153      Usage: Attribute Type
154      Specification: RFC 5020
155      Author/Change Controller: IESG
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170Zeilenga                    Standards Track                     [Page 3]
171
172RFC 5020                      LDAP entryDN                   August 2007
173
174
1755.  References
176
1775.1.  Normative References
178
179   [RFC4510]   Zeilenga, K., Ed., "Lightweight Directory Access Protocol
180               (LDAP): Technical Specification Road Map", RFC 4510, June
181               2006.
182
183   [RFC4512]   Zeilenga, K., Ed., "Lightweight Directory Access Protocol
184               (LDAP): Directory Information Models", RFC 4512, June
185               2006.
186
187   [X.501]     International Telecommunication Union - Telecommunication
188               Standardization Sector, "The Directory -- Models,"
189               X.501(1993) (also ISO/IEC 9594-2:1994).
190
1915.2.  Informative References
192
193   [RFC3687]   Legg, S., "Lightweight Directory Access Protocol (LDAP)
194               and X.500 Component Matching Rules", RFC 3687, February
195               2004.
196
197   [RFC4511]   Sermersheim, J., Ed., "Lightweight Directory Access
198               Protocol (LDAP): The Protocol", RFC 4511, June 2006.
199
200   [RFC4514]   Zeilenga, K., Ed., "Lightweight Directory Access Protocol
201               (LDAP): String Representation of Distinguished Names",
202               RFC 4514, June 2006.
203
204   [RFC4515]   Smith, M., Ed., and T. Howes, "Lightweight Directory
205               Access Protocol (LDAP): String Representation of Search
206               Filters", RFC 4515, June 2006.
207
208   [RFC4520]   Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
209               Considerations for the Lightweight Directory Access
210               Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
211
212Author's Address
213
214   Kurt D. Zeilenga
215   Isode Limited
216
217   EMail: Kurt.Zeilenga@Isode.COM
218
219
220
221
222
223
224
225
226Zeilenga                    Standards Track                     [Page 4]
227
228RFC 5020                      LDAP entryDN                   August 2007
229
230
231Full Copyright Statement
232
233   Copyright (C) The IETF Trust (2007).
234
235   This document is subject to the rights, licenses and restrictions
236   contained in BCP 78, and except as set forth therein, the authors
237   retain all their rights.
238
239   This document and the information contained herein are provided on an
240   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
241   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
242   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
243   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
244   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
245   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
246
247Intellectual Property
248
249   The IETF takes no position regarding the validity or scope of any
250   Intellectual Property Rights or other rights that might be claimed to
251   pertain to the implementation or use of the technology described in
252   this document or the extent to which any license under such rights
253   might or might not be available; nor does it represent that it has
254   made any independent effort to identify any such rights.  Information
255   on the procedures with respect to rights in RFC documents can be
256   found in BCP 78 and BCP 79.
257
258   Copies of IPR disclosures made to the IETF Secretariat and any
259   assurances of licenses to be made available, or the result of an
260   attempt made to obtain a general license or permission for the use of
261   such proprietary rights by implementers or users of this
262   specification can be obtained from the IETF on-line IPR repository at
263   http://www.ietf.org/ipr.
264
265   The IETF invites any interested party to bring to its attention any
266   copyrights, patents or patent applications, or other proprietary
267   rights that may cover technology that may be required to implement
268   this standard.  Please address the information to the IETF at
269   ietf-ipr@ietf.org.
270
271Acknowledgement
272
273   Funding for the RFC Editor function is currently provided by the
274   Internet Society.
275
276
277
278
279
280
281
282Zeilenga                    Standards Track                     [Page 5]
283
284