source4/ldap_server/devdocs/rfc4530.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                        K. Zeilenga
   8 Request for Comments: 4530                           OpenLDAP Foundation
   9 Category: Standards Track                                      June 2006
  10
  11
  12               Lightweight Directory Access Protocol (LDAP)
  13                     entryUUID Operational Attribute
  14
  15
  16 Status of This Memo
  17
  18    This document specifies an Internet standards track protocol for the
  19    Internet community, and requests discussion and suggestions for
  20    improvements.  Please refer to the current edition of the "Internet
  21    Official Protocol Standards" (STD 1) for the standardization state
  22    and status of this protocol.  Distribution of this memo is unlimited.
  23
  24 Copyright Notice
  25
  26    Copyright (C) The Internet Society (2006).
  27
  28 Abstract
  29
  30    This document describes the LDAP/X.500 'entryUUID' operational
  31    attribute and associated matching rules and syntax.  The attribute
  32    holds a server-assigned Universally Unique Identifier (UUID) for the
  33    object.  Directory clients may use this attribute to distinguish
  34    objects identified by a distinguished name or to locate an object
  35    after renaming.
  36
  37
  38
  39
  40
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58 Zeilenga                    Standards Track                     [Page 1]
  59 \f
  60 RFC 4530                     LDAP entryUUID                    June 2006
  61
  62
  63 Table of Contents
  64
  65    1. Background and Intended Use .....................................2
  66    2. UUID Schema Elements ............................................3
  67       2.1. UUID Syntax ................................................3
  68       2.2. 'uuidMatch' Matching Rule ..................................3
  69       2.3. 'uuidOrderingMatch' Matching Rule ..........................3
  70       2.4. 'entryUUID' Attribute ......................................4
  71    3. Security Considerations .........................................4
  72    4. IANA Considerations .............................................5
  73       4.1. Object Identifier Registration .............................5
  74       4.2. UUID Syntax Registration ...................................5
  75       4.3. 'uuidMatch' Descriptor Registration ........................5
  76       4.4. 'uuidOrderingMatch' Descriptor Registration ................5
  77       4.5. 'entryUUID' Descriptor Registration ........................6
  78    5. Acknowledgements ................................................6
  79    6. References ......................................................6
  80       6.1. Normative References .......................................6
  81       6.2. Informative References .....................................7
  82
  83 1.  Background and Intended Use
  84
  85    In X.500 Directory Services [X.501], such as those accessible using
  86    the Lightweight Directory Access Protocol (LDAP) [RFC4510], an object
  87    is identified by its distinguished name (DN).  However, DNs are not
  88    stable identifiers.  That is, a new object may be identified by a DN
  89    that previously identified another (now renamed or deleted) object.
  90
  91    A Universally Unique Identifier (UUID) is "an identifier unique
  92    across both space and time, with respect to the space of all UUIDs"
  93    [RFC4122].  UUIDs are used in a wide range of systems.
  94
  95    This document describes the 'entryUUID' operational attribute, which
  96    holds the UUID assigned to the object by the server.  Clients may use
  97    this attribute to distinguish objects identified by a particular
  98    distinguished name or to locate a particular object after renaming.
  99
 100    This document defines the UUID syntax, the 'uuidMatch' and
 101    'uuidOrderingMatch' matching rules, and the 'entryUUID' attribute
 102    type.
 103
 104    Schema definitions are provided using LDAP description formats
 105    [RFC4512].  Definitions provided here are formatted (line wrapped)
 106    for readability.
 107
 108
 109
 110
 111
 112
 113
 114 Zeilenga                    Standards Track                     [Page 2]
 115 \f
 116 RFC 4530                     LDAP entryUUID                    June 2006
 117
 118
 119    In this document, the key words "MUST", "MUST NOT", "REQUIRED",
 120    "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
 121    and "OPTIONAL" are to be interpreted as described in BCP 14
 122    [RFC2119].
 123
 124 2.  UUID Schema Elements
 125
 126 2.1.  UUID Syntax
 127
 128    A Universally Unique Identifier (UUID) [RFC4122] is a 16-octet (128-
 129    bit) value that identifies an object.  The ASN.1 [X.680] type UUID is
 130    defined to represent UUIDs as follows:
 131
 132        UUID ::= OCTET STRING (SIZE(16))
 133              -- constrained to an UUID [RFC4122]
 134
 135    In LDAP, UUID values are encoded using the [ASCII] character string
 136    representation described in [RFC4122].  For example,
 137    "597ae2f6-16a6-1027-98f4-d28b5365dc14".
 138
 139    The following is an LDAP syntax description suitable for publication
 140    in subschema subentries.
 141
 142        ( 1.3.6.1.1.16.1 DESC 'UUID' )
 143
 144 2.2.  'uuidMatch' Matching Rule
 145
 146    The 'uuidMatch' matching rule compares an asserted UUID with a stored
 147    UUID for equality.  Its semantics are the same as the
 148    'octetStringMatch' [X.520][RFC4517] matching rule.  The rule differs
 149    from 'octetStringMatch' in that the assertion value is encoded using
 150    the UUID string representation instead of the normal OCTET STRING
 151    string representation.
 152
 153    The following is an LDAP matching rule description suitable for
 154    publication in subschema subentries.
 155
 156        ( 1.3.6.1.1.16.2 NAME 'uuidMatch'
 157            SYNTAX 1.3.6.1.1.16.1 )
 158
 159 2.3.  'uuidOrderingMatch' Matching Rule
 160
 161    The 'uuidOrderingMatch' matching rule compares an asserted UUID with
 162    a stored UUID for ordering.  Its semantics are the same as the
 163    'octetStringOrderingMatch' [X.520][RFC4517] matching rule.  The rule
 164    differs from 'octetStringOrderingMatch' in that the assertion value
 165    is encoded using the UUID string representation instead of the normal
 166    OCTET STRING string representation.
 167
 168
 169
 170 Zeilenga                    Standards Track                     [Page 3]
 171 \f
 172 RFC 4530                     LDAP entryUUID                    June 2006
 173
 174
 175    The following is an LDAP matching rule description suitable for
 176    publication in subschema subentries.
 177
 178        ( 1.3.6.1.1.16.3 NAME 'uuidOrderingMatch'
 179            SYNTAX 1.3.6.1.1.16.1 )
 180
 181    Note that not all UUID variants have a defined ordering; and even
 182    where it does, servers are not obligated to assign UUIDs in any
 183    particular order.  This matching rule is provided for completeness.
 184
 185 2.4.  'entryUUID' Attribute
 186
 187    The 'entryUUID' operational attribute provides the Universally Unique
 188    Identifier (UUID) assigned to the entry.
 189
 190    The following is an LDAP attribute type description suitable for
 191    publication in subschema subentries.
 192
 193        ( 1.3.6.1.1.16.4 NAME 'entryUUID'
 194            DESC 'UUID of the entry'
 195            EQUALITY uuidMatch
 196            ORDERING uuidOrderingMatch
 197            SYNTAX 1.3.6.1.1.16.1
 198            SINGLE-VALUE
 199            NO-USER-MODIFICATION
 200            USAGE directoryOperation )
 201
 202    Servers SHALL generate and assign a new UUID to each entry upon its
 203    addition to the directory and provide that UUID as the value of the
 204    'entryUUID' operational attribute.  An entry's UUID is immutable.
 205
 206    UUID are to be generated in accordance with Section 4 of [RFC4122].
 207    In particular, servers MUST ensure that each generated UUID is unique
 208    in space and time.
 209
 210 3.  Security Considerations
 211
 212    An entry's relative distinguish name (RDN) is composed from attribute
 213    values of the entry, which are commonly descriptive of the object the
 214    entry represents.  Although deployers are encouraged to use naming
 215    attributes whose values are widely disclosable [RFC4514], entries are
 216    often named using information that cannot be disclosed to all
 217    parties.  As UUIDs do not contain any descriptive information of the
 218    object they identify, UUIDs may be used to identify a particular
 219    entry without disclosure of its contents.
 220
 221    General UUID security considerations [RFC4122] apply.
 222
 223
 224
 225
 226 Zeilenga                    Standards Track                     [Page 4]
 227 \f
 228 RFC 4530                     LDAP entryUUID                    June 2006
 229
 230
 231    General LDAP security considerations [RFC4510] apply.
 232
 233 4.  IANA Considerations
 234
 235    The IANA has registered the LDAP values [RFC4520] specified in this
 236    document.
 237
 238 4.1.  Object Identifier Registration
 239
 240        Subject: Request for LDAP OID Registration
 241        Person & email address to contact for further information:
 242            Kurt Zeilenga <kurt@OpenLDAP.org>
 243        Specification: RFC 4530
 244        Author/Change Controller: IESG
 245        Comments:
 246            Identifies the UUID schema elements
 247
 248 4.2.  UUID Syntax Registration
 249
 250        Subject: Request for LDAP Syntax Registration
 251        Object Identifier: 1.3.6.1.1.16.1
 252        Description: UUID
 253        Person & email address to contact for further information:
 254            Kurt Zeilenga <kurt@OpenLDAP.org>
 255        Specification: RFC 4530
 256        Author/Change Controller: IESG
 257        Comments:
 258             Identifies the UUID syntax
 259
 260 4.3.  'uuidMatch' Descriptor Registration
 261
 262        Subject: Request for LDAP Descriptor Registration
 263        Descriptor (short name): uuidMatch
 264        Object Identifier: 1.3.6.1.1.16.2
 265        Person & email address to contact for further information:
 266            Kurt Zeilenga <kurt@OpenLDAP.org>
 267        Usage: Matching Rule
 268        Specification: RFC 4530
 269        Author/Change Controller: IESG
 270
 271 4.4.  'uuidOrderingMatch' Descriptor Registration
 272
 273        Subject: Request for LDAP Descriptor Registration
 274        Descriptor (short name): uuidOrderingMatch
 275        Object Identifier: 1.3.6.1.1.16.3
 276        Person & email address to contact for further information:
 277            Kurt Zeilenga <kurt@OpenLDAP.org>
 278        Usage: Matching Rule
 279
 280
 281
 282 Zeilenga                    Standards Track                     [Page 5]
 283 \f
 284 RFC 4530                     LDAP entryUUID                    June 2006
 285
 286
 287        Specification: RFC 4530
 288        Author/Change Controller: IESG
 289
 290 4.5.  'entryUUID' Descriptor Registration
 291
 292    The IANA has registered the LDAP 'entryUUID' descriptor.
 293
 294        Subject: Request for LDAP Descriptor Registration
 295        Descriptor (short name): entryUUID
 296        Object Identifier: 1.3.6.1.1.16.4
 297        Person & email address to contact for further information:
 298            Kurt Zeilenga <kurt@OpenLDAP.org>
 299        Usage: Attribute Type
 300        Specification: RFC 4530
 301        Author/Change Controller: IESG
 302
 303 5.  Acknowledgements
 304
 305    This document is based upon discussions in the LDAP Update and
 306    Duplication Protocols (LDUP) WG.  Members of the LDAP Directorate
 307    provided review.
 308
 309 6.  References
 310
 311 6.1.  Normative References
 312
 313    [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
 314                  Requirement Levels", BCP 14, RFC 2119, March 1997.
 315
 316    [RFC4122]     Leach, P., Mealling, M., and R. Salz, "A Universally
 317                  Unique IDentifier (UUID) URN Namespace", RFC 4122, July
 318                  2005.
 319
 320    [RFC4510]     Zeilenga, K., Ed., "Lightweight Directory Access
 321                  Protocol (LDAP): Technical Specification Road Map", RFC
 322                  4510, June 2006.
 323
 324    [RFC4512]     Zeilenga, K., "Lightweight Directory Access Protocol
 325                  (LDAP): Directory Information Models", RFC 4512, June
 326                  2006.
 327
 328    [RFC4517]     Legg, S., Ed., "Lightweight Directory Access Protocol
 329                  (LDAP): Syntaxes and Matching Rules", RFC 4517, June
 330                  2006.
 331
 332    [ASCII]       Coded Character Set--7-bit American Standard Code for
 333                  Information Interchange, ANSI X3.4-1986.
 334
 335
 336
 337
 338 Zeilenga                    Standards Track                     [Page 6]
 339 \f
 340 RFC 4530                     LDAP entryUUID                    June 2006
 341
 342
 343    [X.501]       International Telecommunication Union -
 344                  Telecommunication Standardization Sector, "The
 345                  Directory -- Models," X.501(1993) (also ISO/IEC 9594-
 346                  2:1994).
 347
 348    [X.520]       International Telecommunication Union -
 349                  Telecommunication Standardization Sector, "The
 350                  Directory: Selected Attribute Types", X.520(1993) (also
 351                  ISO/IEC 9594-6:1994).
 352
 353    [X.680]       International Telecommunication Union -
 354                  Telecommunication Standardization Sector, "Abstract
 355                  Syntax Notation One (ASN.1) - Specification of Basic
 356                  Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
 357
 358 6.2.  Informative References
 359
 360    [RFC4514]     Zeilenga, K., Ed., "Lightweight Directory Access
 361                  Protocol (LDAP): String Representation of Distinguished
 362                  Names", RFC 4514, June 2006.
 363
 364    [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
 365                  (IANA) Considerations for the Lightweight Directory
 366                  Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
 367
 368 Author's Address
 369
 370    Kurt D. Zeilenga
 371    OpenLDAP Foundation
 372
 373    EMail: Kurt@OpenLDAP.org
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Zeilenga                    Standards Track                     [Page 7]
 395 \f
 396 RFC 4530                     LDAP entryUUID                    June 2006
 397
 398
 399 Full Copyright Statement
 400
 401    Copyright (C) The Internet Society (2006).
 402
 403    This document is subject to the rights, licenses and restrictions
 404    contained in BCP 78, and except as set forth therein, the authors
 405    retain all their rights.
 406
 407    This document and the information contained herein are provided on an
 408    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 409    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 410    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 411    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 412    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 413    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 414
 415 Intellectual Property
 416
 417    The IETF takes no position regarding the validity or scope of any
 418    Intellectual Property Rights or other rights that might be claimed to
 419    pertain to the implementation or use of the technology described in
 420    this document or the extent to which any license under such rights
 421    might or might not be available; nor does it represent that it has
 422    made any independent effort to identify any such rights.  Information
 423    on the procedures with respect to rights in RFC documents can be
 424    found in BCP 78 and BCP 79.
 425
 426    Copies of IPR disclosures made to the IETF Secretariat and any
 427    assurances of licenses to be made available, or the result of an
 428    attempt made to obtain a general license or permission for the use of
 429    such proprietary rights by implementers or users of this
 430    specification can be obtained from the IETF on-line IPR repository at
 431    http://www.ietf.org/ipr.
 432
 433    The IETF invites any interested party to bring to its attention any
 434    copyrights, patents or patent applications, or other proprietary
 435    rights that may cover technology that may be required to implement
 436    this standard.  Please address the information to the IETF at
 437    ietf-ipr@ietf.org.
 438
 439 Acknowledgement
 440
 441    Funding for the RFC Editor function is provided by the IETF
 442    Administrative Support Activity (IASA).
 443
 444
 445
 446
 447
 448
 449
 450 Zeilenga                    Standards Track                     [Page 8]
 451 \f