]> git.sur5r.net Git - openldap/blob - doc/rfc/rfc2247.txt
Fix prev commit
[openldap] / doc / rfc / rfc2247.txt
1
2
3
4
5
6
7 Network Working Group                                           S. Kille
8 Request for Comments: 2247                                    Isode Ltd.
9 Category: Standards Track                                        M. Wahl
10                                                      Critical Angle Inc.
11                                                              A. Grimstad
12                                                                     AT&T
13                                                                 R. Huber
14                                                                     AT&T
15                                                              S. Sataluri
16                                                                     AT&T
17                                                             January 1998
18
19
20
21             Using Domains in LDAP/X.500 Distinguished Names
22
23
24 Status of this Memo
25
26    This document specifies an Internet standards track protocol for the
27    Internet community, and requests discussion and suggestions for
28    improvements.  Please refer to the current edition of the "Internet
29    Official Protocol Standards" (STD 1) for the standardization state
30    and status of this protocol.  Distribution of this memo is unlimited.
31
32 Copyright Notice
33
34    Copyright (C) The Internet Society (1998).  All Rights Reserved.
35
36 1. Abstract
37
38    The Lightweight Directory Access Protocol (LDAP) uses X.500-
39    compatible distinguished names [3] for providing unique
40    identification of entries.
41
42    This document defines an algorithm by which a name registered with
43    the Internet Domain Name Service [2] can be represented as an LDAP
44    distinguished name.
45
46 2. Background
47
48    The Domain (Nameserver) System (DNS) provides a hierarchical resource
49    labeling system.   A name is made up of an ordered set of components,
50    each of which are short strings. An example domain name with two
51    components would be "CRITICAL-ANGLE.COM".
52
53
54
55
56
57
58 Kille, et. al.              Standards Track                     [Page 1]
59 \f
60 RFC 2247              Using Domains in LDAP/X.500           January 1998
61
62
63    LDAP-based directories provide a more general hierarchical naming
64    framework. A primary difference in specification of distinguished
65    names from domain names is that each component of an distinguished
66    name has an explicit attribute type indication.
67
68    X.500 does not mandate any particular naming structure.  It does
69    contain suggested naming structures which are based on geographic and
70    national regions, however there is not currently an established
71    registration infrastructure in many regions which would be able to
72    assign or ensure uniqueness of names.
73
74    The mechanism described in this document automatically provides an
75    enterprise a distinguished name for each domain name it has obtained
76    for use in the Internet.  These distinguished names may be used to
77    identify objects in an LDAP directory.
78
79    An example distinguished name represented in the LDAP string format
80    [3] is "DC=CRITICAL-ANGLE,DC=COM".  As with a domain name, the most
81    significant component, closest to the root of the namespace, is
82    written last.
83
84    This document does not define how to represent objects which do not
85    have domain names.  Nor does this document define the procedure to
86    locate an enterprise's LDAP directory server, given their domain
87    name.  Such procedures may be defined in future RFCs.
88
89 3. Mapping Domain Names into Distinguished Names
90
91    This section defines a subset of the possible distinguished name
92    structures for use in representing names allocated in the Internet
93    Domain Name System.  It is possible to algorithmically transform any
94    Internet domain name into a distinguished name, and to convert these
95    distinguished names back into the original domain names.
96
97    The algorithm for transforming a domain name is to begin with an
98    empty distinguished name (DN) and then attach Relative Distinguished
99    Names (RDNs) for each component of the domain, most significant (e.g.
100    rightmost) first. Each of these RDNs is a single
101    AttributeTypeAndValue, where the type is the attribute "DC" and the
102    value is an IA5 string containing the domain name component.
103
104    Thus the domain name "CS.UCL.AC.UK" can be transformed into
105
106         DC=CS,DC=UCL,DC=AC,DC=UK
107
108
109
110
111
112
113
114 Kille, et. al.              Standards Track                     [Page 2]
115 \f
116 RFC 2247              Using Domains in LDAP/X.500           January 1998
117
118
119    Distinguished names in which there are one or more RDNs, all
120    containing only the attribute type DC, can be mapped back into domain
121    names. Note that this document does not define a domain name
122    equivalence for any other distinguished names.
123
124 4. Attribute Type Definition
125
126    The DC (short for domainComponent) attribute type is defined as
127    follows:
128
129     ( 0.9.2342.19200300.100.1.25 NAME 'dc' EQUALITY caseIgnoreIA5Match
130      SUBSTR caseIgnoreIA5SubstringsMatch
131      SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
132
133    The value of this attribute is a string holding one component of a
134    domain name.  The encoding of IA5String for use in LDAP is simply the
135    characters of the string itself.  The equality matching rule is case
136    insensitive, as is today's DNS.
137
138 5. Object Class Definitions
139
140    An object with a name derived from its domain name using the
141    algorithm of section 3 is represented as an entry in the directory.
142    The "DC" attribute is present in the entry and used as the RDN.
143
144    An attribute can only be present in an entry held by an LDAP server
145    when that attribute is permitted by the entry's object class.
146
147    This section defines two object classes.  The first, dcObject, is
148    intended to be used in entries for which there is an appropriate
149    structural object class.  For example, if the domain represents a
150    particular organization, the entry would have as its structural
151    object class 'organization', and the 'dcObject' class would be an
152    auxiliary class.  The second, domain, is a structural object class
153    used for entries in which no other information is being stored. The
154    domain object class is typically used for entries that are
155    placeholders or whose domains do not correspond to real-world
156    entities.
157
158 5.1. The dcObject object class
159
160    The dcObject object class permits the dc attribute to be present in
161    an entry.  This object class is defined as auxiliary, as it would
162    typically be used in conjunction with an existing structural object
163    class, such as organization, organizationalUnit or locality.
164
165    The following object class, along with the dc attribute, can be added
166    to any entry.
167
168
169
170 Kille, et. al.              Standards Track                     [Page 3]
171 \f
172 RFC 2247              Using Domains in LDAP/X.500           January 1998
173
174
175    ( 1.3.6.1.4.1.1466.344 NAME 'dcObject' SUP top AUXILIARY MUST dc )
176
177    An example entry would be:
178
179    dn: dc=critical-angle,dc=com
180    objectClass: top
181    objectClass: organization
182    objectClass: dcObject
183    dc: critical-angle
184    o: Critical Angle Inc.
185
186 5.2. The domain object class
187
188    If the entry does not correspond to an organization, organizational
189    unit or other type of object for which an object class has been
190    defined, then the "domain" object class can be used.  The "domain"
191    object class requires that the "DC" attribute be present, and permits
192    several other attributes to be present in the entry.
193
194    The entry will have as its structural object class the "domain"
195    object class.
196
197 ( 0.9.2342.19200300.100.4.13 NAME 'domain' SUP top STRUCTURAL
198  MUST dc
199  MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
200  x121Address $ registeredAddress $ destinationIndicator $
201  preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
202  telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $
203  street $ postOfficeBox $ postalCode $ postalAddress $
204  physicalDeliveryOfficeName $ st $ l $ description $ o $
205  associatedName ) )
206
207    The optional attributes of the domain class are used for describing
208    the object represented by this domain, and may also be useful when
209    searching.  These attributes are already defined for use with LDAP
210    [4].
211
212    An example entry would be:
213
214    dn: dc=tcp,dc=critical-angle,dc=com
215    objectClass: top
216    objectClass: domain
217    dc: tcp
218    description: a placeholder entry used with SRV records
219
220    The DC attribute is used for naming entries of the domain class, and
221    this can be represented in X.500 servers by the following name form
222    rule.
223
224
225
226 Kille, et. al.              Standards Track                     [Page 4]
227 \f
228 RFC 2247              Using Domains in LDAP/X.500           January 1998
229
230
231     ( 1.3.6.1.4.1.1466.345 NAME 'domainNameForm' OC domain MUST ( dc ) )
232
233 6. References
234
235    [1] The Directory: Selected Attribute Types. ITU-T Recommendation
236        X.520, 1993.
237
238    [2] Mockapetris, P., " Domain Names - Concepts and Facilities,"
239        STD 13, RFC 1034, November 1987.
240
241    [3] Kille, S., and M. Wahl, " Lightweight Directory Access Protocol
242        (v3): UTF-8 String Representation of Distinguished Names", RFC
243        2253, December 1997.
244
245    [4] Wahl, M., "A Summary of the X.500(96) User Schema for use with
246        LDAP", RFC 2256, December 1997.
247
248 7. Security Considerations
249
250    This memo describes how attributes of objects may be discovered and
251    retrieved.  Servers should ensure that an appropriate security policy
252    is maintained.
253
254    An enterprise is not restricted in the information which it may store
255    in DNS or LDAP servers.  A client which contacts an untrusted server
256    may have incorrect or misleading information returned (e.g. an
257    organization's server may claim to hold naming contexts representing
258    domain names which have not been delegated to that organization).
259
260 8. Authors' Addresses
261
262    Steve Kille
263    Isode Ltd.
264    The Dome
265    The Square
266    Richmond, Surrey
267    TW9 1DT
268    England
269
270    Phone:  +44-181-332-9091
271    EMail:  S.Kille@ISODE.COM
272
273
274
275
276
277
278
279
280
281
282 Kille, et. al.              Standards Track                     [Page 5]
283 \f
284 RFC 2247              Using Domains in LDAP/X.500           January 1998
285
286
287    Mark Wahl
288    Critical Angle Inc.
289    4815 W. Braker Lane #502-385
290    Austin, TX 78759
291    USA
292
293    Phone:  (1) 512 372 3160
294    EMail:  M.Wahl@critical-angle.com
295
296
297    Al Grimstad
298    AT&T
299    Room 1C-429, 101 Crawfords Corner Road
300    Holmdel, NJ 07733-3030
301    USA
302
303    EMail: alg@att.com
304
305
306    Rick Huber
307    AT&T
308    Room 1B-433, 101 Crawfords Corner Road
309    Holmdel, NJ 07733-3030
310    USA
311
312    EMail: rvh@att.com
313
314
315    Sri Sataluri
316    AT&T
317    Room 4G-202, 101 Crawfords Corner Road
318    Holmdel, NJ 07733-3030
319    USA
320
321    EMail: sri@att.com
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338 Kille, et. al.              Standards Track                     [Page 6]
339 \f
340 RFC 2247              Using Domains in LDAP/X.500           January 1998
341
342
343 9.  Full Copyright Statement
344
345    Copyright (C) The Internet Society (1998).  All Rights Reserved.
346
347    This document and translations of it may be copied and furnished to
348    others, and derivative works that comment on or otherwise explain it
349    or assist in its implementation may be prepared, copied, published
350    and distributed, in whole or in part, without restriction of any
351    kind, provided that the above copyright notice and this paragraph are
352    included on all such copies and derivative works.  However, this
353    document itself may not be modified in any way, such as by removing
354    the copyright notice or references to the Internet Society or other
355    Internet organizations, except as needed for the purpose of
356    developing Internet standards in which case the procedures for
357    copyrights defined in the Internet Standards process must be
358    followed, or as required to translate it into languages other than
359    English.
360
361    The limited permissions granted above are perpetual and will not be
362    revoked by the Internet Society or its successors or assigns.
363
364    This document and the information contained herein is provided on an
365    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
366    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
367    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
368    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
369    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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 Kille, et. al.              Standards Track                     [Page 7]
395 \f