summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2247.txt
blob: be40b102ef48e526617ef7bc56877c674c12beef (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
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
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
Network Working Group                                           S. Kille
Request for Comments: 2247                                    Isode Ltd.
Category: Standards Track                                        M. Wahl
                                                     Critical Angle Inc.
                                                             A. Grimstad
                                                                    AT&T
                                                                R. Huber
                                                                    AT&T
                                                             S. Sataluri
                                                                    AT&T
                                                            January 1998



            Using Domains in LDAP/X.500 Distinguished Names


Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

1. Abstract

   The Lightweight Directory Access Protocol (LDAP) uses X.500-
   compatible distinguished names [3] for providing unique
   identification of entries.

   This document defines an algorithm by which a name registered with
   the Internet Domain Name Service [2] can be represented as an LDAP
   distinguished name.

2. Background

   The Domain (Nameserver) System (DNS) provides a hierarchical resource
   labeling system.   A name is made up of an ordered set of components,
   each of which are short strings. An example domain name with two
   components would be "CRITICAL-ANGLE.COM".






Kille, et. al.              Standards Track                     [Page 1]
^L
RFC 2247              Using Domains in LDAP/X.500           January 1998


   LDAP-based directories provide a more general hierarchical naming
   framework. A primary difference in specification of distinguished
   names from domain names is that each component of an distinguished
   name has an explicit attribute type indication.

   X.500 does not mandate any particular naming structure.  It does
   contain suggested naming structures which are based on geographic and
   national regions, however there is not currently an established
   registration infrastructure in many regions which would be able to
   assign or ensure uniqueness of names.

   The mechanism described in this document automatically provides an
   enterprise a distinguished name for each domain name it has obtained
   for use in the Internet.  These distinguished names may be used to
   identify objects in an LDAP directory.

   An example distinguished name represented in the LDAP string format
   [3] is "DC=CRITICAL-ANGLE,DC=COM".  As with a domain name, the most
   significant component, closest to the root of the namespace, is
   written last.

   This document does not define how to represent objects which do not
   have domain names.  Nor does this document define the procedure to
   locate an enterprise's LDAP directory server, given their domain
   name.  Such procedures may be defined in future RFCs.

3. Mapping Domain Names into Distinguished Names

   This section defines a subset of the possible distinguished name
   structures for use in representing names allocated in the Internet
   Domain Name System.  It is possible to algorithmically transform any
   Internet domain name into a distinguished name, and to convert these
   distinguished names back into the original domain names.

   The algorithm for transforming a domain name is to begin with an
   empty distinguished name (DN) and then attach Relative Distinguished
   Names (RDNs) for each component of the domain, most significant (e.g.
   rightmost) first. Each of these RDNs is a single
   AttributeTypeAndValue, where the type is the attribute "DC" and the
   value is an IA5 string containing the domain name component.

   Thus the domain name "CS.UCL.AC.UK" can be transformed into

        DC=CS,DC=UCL,DC=AC,DC=UK







Kille, et. al.              Standards Track                     [Page 2]
^L
RFC 2247              Using Domains in LDAP/X.500           January 1998


   Distinguished names in which there are one or more RDNs, all
   containing only the attribute type DC, can be mapped back into domain
   names. Note that this document does not define a domain name
   equivalence for any other distinguished names.

4. Attribute Type Definition

   The DC (short for domainComponent) attribute type is defined as
   follows:

    ( 0.9.2342.19200300.100.1.25 NAME 'dc' EQUALITY caseIgnoreIA5Match
     SUBSTR caseIgnoreIA5SubstringsMatch
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

   The value of this attribute is a string holding one component of a
   domain name.  The encoding of IA5String for use in LDAP is simply the
   characters of the string itself.  The equality matching rule is case
   insensitive, as is today's DNS.

5. Object Class Definitions

   An object with a name derived from its domain name using the
   algorithm of section 3 is represented as an entry in the directory.
   The "DC" attribute is present in the entry and used as the RDN.

   An attribute can only be present in an entry held by an LDAP server
   when that attribute is permitted by the entry's object class.

   This section defines two object classes.  The first, dcObject, is
   intended to be used in entries for which there is an appropriate
   structural object class.  For example, if the domain represents a
   particular organization, the entry would have as its structural
   object class 'organization', and the 'dcObject' class would be an
   auxiliary class.  The second, domain, is a structural object class
   used for entries in which no other information is being stored. The
   domain object class is typically used for entries that are
   placeholders or whose domains do not correspond to real-world
   entities.

5.1. The dcObject object class

   The dcObject object class permits the dc attribute to be present in
   an entry.  This object class is defined as auxiliary, as it would
   typically be used in conjunction with an existing structural object
   class, such as organization, organizationalUnit or locality.

   The following object class, along with the dc attribute, can be added
   to any entry.



Kille, et. al.              Standards Track                     [Page 3]
^L
RFC 2247              Using Domains in LDAP/X.500           January 1998


   ( 1.3.6.1.4.1.1466.344 NAME 'dcObject' SUP top AUXILIARY MUST dc )

   An example entry would be:

   dn: dc=critical-angle,dc=com
   objectClass: top
   objectClass: organization
   objectClass: dcObject
   dc: critical-angle
   o: Critical Angle Inc.

5.2. The domain object class

   If the entry does not correspond to an organization, organizational
   unit or other type of object for which an object class has been
   defined, then the "domain" object class can be used.  The "domain"
   object class requires that the "DC" attribute be present, and permits
   several other attributes to be present in the entry.

   The entry will have as its structural object class the "domain"
   object class.

( 0.9.2342.19200300.100.4.13 NAME 'domain' SUP top STRUCTURAL
 MUST dc
 MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
 x121Address $ registeredAddress $ destinationIndicator $
 preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
 telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $
 street $ postOfficeBox $ postalCode $ postalAddress $
 physicalDeliveryOfficeName $ st $ l $ description $ o $
 associatedName ) )

   The optional attributes of the domain class are used for describing
   the object represented by this domain, and may also be useful when
   searching.  These attributes are already defined for use with LDAP
   [4].

   An example entry would be:

   dn: dc=tcp,dc=critical-angle,dc=com
   objectClass: top
   objectClass: domain
   dc: tcp
   description: a placeholder entry used with SRV records

   The DC attribute is used for naming entries of the domain class, and
   this can be represented in X.500 servers by the following name form
   rule.



Kille, et. al.              Standards Track                     [Page 4]
^L
RFC 2247              Using Domains in LDAP/X.500           January 1998


    ( 1.3.6.1.4.1.1466.345 NAME 'domainNameForm' OC domain MUST ( dc ) )

6. References

   [1] The Directory: Selected Attribute Types. ITU-T Recommendation
       X.520, 1993.

   [2] Mockapetris, P., " Domain Names - Concepts and Facilities,"
       STD 13, RFC 1034, November 1987.

   [3] Kille, S., and M. Wahl, " Lightweight Directory Access Protocol
       (v3): UTF-8 String Representation of Distinguished Names", RFC
       2253, December 1997.

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

7. Security Considerations

   This memo describes how attributes of objects may be discovered and
   retrieved.  Servers should ensure that an appropriate security policy
   is maintained.

   An enterprise is not restricted in the information which it may store
   in DNS or LDAP servers.  A client which contacts an untrusted server
   may have incorrect or misleading information returned (e.g. an
   organization's server may claim to hold naming contexts representing
   domain names which have not been delegated to that organization).

8. Authors' Addresses

   Steve Kille
   Isode Ltd.
   The Dome
   The Square
   Richmond, Surrey
   TW9 1DT
   England

   Phone:  +44-181-332-9091
   EMail:  S.Kille@ISODE.COM










Kille, et. al.              Standards Track                     [Page 5]
^L
RFC 2247              Using Domains in LDAP/X.500           January 1998


   Mark Wahl
   Critical Angle Inc.
   4815 W. Braker Lane #502-385
   Austin, TX 78759
   USA

   Phone:  (1) 512 372 3160
   EMail:  M.Wahl@critical-angle.com


   Al Grimstad
   AT&T
   Room 1C-429, 101 Crawfords Corner Road
   Holmdel, NJ 07733-3030
   USA

   EMail: alg@att.com


   Rick Huber
   AT&T
   Room 1B-433, 101 Crawfords Corner Road
   Holmdel, NJ 07733-3030
   USA

   EMail: rvh@att.com


   Sri Sataluri
   AT&T
   Room 4G-202, 101 Crawfords Corner Road
   Holmdel, NJ 07733-3030
   USA

   EMail: sri@att.com
















Kille, et. al.              Standards Track                     [Page 6]
^L
RFC 2247              Using Domains in LDAP/X.500           January 1998


9.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  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.
























Kille, et. al.              Standards Track                     [Page 7]
^L