]> git.sur5r.net Git - openldap/blob - doc/rfc/rfc4530.txt
Fix prev commit
[openldap] / doc / rfc / 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