git.sur5r.net Git - openldap/blob - 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