1
2
3
4
5
6
7Network Working Group                                   K. Zeilenga, Ed.
8Request for Comments: 3698                           OpenLDAP Foundation
9Updates: 2798                                              February 2004
10Category: Standards Track
11
12
13             Lightweight Directory Access Protocol (LDAP):
14                       Additional Matching Rules
15
16Status 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
24Copyright Notice
25
26   Copyright (C) The Internet Society (2004).  All Rights Reserved.
27
28Abstract
29
30   This document provides a collection of matching rules for use with
31   the Lightweight Directory Access Protocol (LDAP).  As these matching
32   rules are simple adaptations of matching rules specified for use with
33   the X.500 Directory, most are already in wide use.
34
35Table of Contents
36
37   1.  Background and Intended Use. . . . . . . . . . . . . . . . . .  2
38   2.  Matching Rules . . . . . . . . . . . . . . . . . . . . . . . .  2
39       2.1.  booleanMatch . . . . . . . . . . . . . . . . . . . . . .  2
40       2.2.  caseExactMatch . . . . . . . . . . . . . . . . . . . . .  2
41       2.3.  caseExactOrderingMatch . . . . . . . . . . . . . . . . .  3
42       2.4.  caseExactSubstringsMatch . . . . . . . . . . . . . . . .  3
43       2.5.  caseIgnoreListSubstringsMatch. . . . . . . . . . . . . .  3
44       2.6.  directoryStringFirstComponentMatch . . . . . . . . . . .  4
45       2.7.  integerOrderingMatch . . . . . . . . . . . . . . . . . .  4
46       2.8.  keywordMatch . . . . . . . . . . . . . . . . . . . . . .  4
47       2.9.  numericStringOrderingMatch . . . . . . . . . . . . . . .  5
48       2.10. octetStringOrderingMatch . . . . . . . . . . . . . . . .  5
49       2.11. storedPrefixMatch. . . . . . . . . . . . . . . . . . . .  5
50       2.12. wordMatch. . . . . . . . . . . . . . . . . . . . . . . .  6
51   3.  Security Considerations. . . . . . . . . . . . . . . . . . . .  6
52   4.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  6
53   5.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .  7
54   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  7
55
56
57
58Zeilenga                    Standards Track                     [Page 1]
59
60RFC 3698            LDAP: Additional Matching Rules        February 2004
61
62
63       6.1.  Normative References . . . . . . . . . . . . . . . . . .  7
64       6.2.  Informative References . . . . . . . . . . . . . . . . .  7
65   7.  Author's Address . . . . . . . . . . . . . . . . . . . . . . .  8
66   8.  Full Copyright Statement . . . . . . . . . . . . . . . . . . .  9
67
681.  Background and Intended Use
69
70   This document adapts additional X.500 Directory [X.500] matching
71   rules [X.520] for use with the Lightweight Directory Access Protocol
72   (LDAP) [RFC3377].  Most of these rules are widely used today on the
73   Internet, such as in support of the inetOrgPerson [RFC2798] and
74   Policy Core Information Model [RFC3703] LDAP schemas.  The rules are
75   applicable to many other applications.
76
77   This document supersedes the informational matching rules
78   descriptions provided in RFC 2798 that are now provided in this
79   document.  Specifically, section 2 of this document replaces section
80   9.3.3 of RFC 2798.
81
82   Schema definitions are provided using LDAP description formats
83   [RFC2252].  Definitions provided here are formatted (line wrapped)
84   for readability.
85
862.  Matching Rules
87
882.1.  booleanMatch
89
90   The booleanMatch rule compares for equality a asserted Boolean value
91   with an attribute value of BOOLEAN syntax.  The rule returns TRUE if
92   and only if the values are the same, i.e., both are TRUE or both are
93   FALSE.  (Source: X.520)
94
95       ( 2.5.13.13 NAME 'booleanMatch'
96         SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
97
98   The BOOLEAN (1.3.6.1.4.1.1466.115.121.1.7) syntax is described in
99   [RFC2252].
100
1012.2.  caseExactMatch
102
103   The caseExactMatch rule compares for equality the asserted value with
104   an attribute value of DirectoryString syntax.  The rule is identical
105   to the caseIgnoreMatch [RFC2252] rule except that case is not
106   ignored.  (Source: X.520)
107
108
109
110
111
112
113
114Zeilenga                    Standards Track                     [Page 2]
115
116RFC 3698            LDAP: Additional Matching Rules        February 2004
117
118
119       ( 2.5.13.5 NAME 'caseExactMatch'
120         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
121
122   The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
123   described in [RFC2252].
124
1252.3.  caseExactOrderingMatch
126
127   The caseExactOrderingMatch rule compares the collation order of the
128   asserted string with an attribute value of DirectoryString syntax.
129   The rule is identical to the caseIgnoreOrderingMatch [RFC2252] rule
130   except that letters are not folded.  (Source: X.520)
131
132       ( 2.5.13.6 NAME 'caseExactOrderingMatch'
133         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
134
135   The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
136   described in [RFC2252].
137
1382.4.  caseExactSubstringsMatch
139
140   The caseExactSubstringsMatch rule determines whether the asserted
141   value(s) are substrings of an attribute value of DirectoryString
142   syntax.  The rule is identical to the caseIgnoreSubstringsMatch
143   [RFC2252] rule except that case is not ignored.  (Source: X.520)
144
145       ( 2.5.13.7 NAME 'caseExactSubstringsMatch'
146         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
147
148   The SubstringsAssertion (1.3.6.1.4.1.1466.115.121.1.58) syntax is
149   described in [RFC2252].
150
1512.5. caseIgnoreListSubstringsMatch
152
153   The caseIgnoreListSubstringMatch rule compares the asserted substring
154   with an attribute value which is a sequence of DirectoryStrings, but
155   where the case (upper or lower) is not significant for comparison
156   purposes.  The asserted value matches a stored value if and only if
157   the asserted value matches the string formed by concatenating the
158   strings of the stored value.  This matching is done according to the
159   caseIgnoreSubstringsMatch [RFC2252] rule; however, none of the
160   initial, any, or final values of the asserted value are considered to
161   match a substring of the concatenated string which spans more than
162   one of the strings of the stored value.  (Source: X.520)
163
164       ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
165         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
166
167
168
169
170Zeilenga                    Standards Track                     [Page 3]
171
172RFC 3698            LDAP: Additional Matching Rules        February 2004
173
174
175   The SubstringsAssertion (1.3.6.1.4.1.1466.115.121.1.58) syntax is
176   described in [RFC2252].
177
1782.6.  directoryStringFirstComponentMatch
179
180   The directoryStringFirstComponentMatch rule compares for equality the
181   asserted DirectoryString value with an attribute value of type
182   SEQUENCE whose first component is mandatory and of type
183   DirectoryString.  The rule returns TRUE if and only if the attribute
184   value has a first component whose value matches the asserted
185   DirectoryString using the rules of caseIgnoreMatch [RFC2252].  A
186   value of the assertion syntax is derived from a value of the
187   attribute syntax by using the value of the first component of the
188   SEQUENCE.  (Source: X.520)
189
190       ( 2.5.13.31 NAME 'directoryStringFirstComponentMatch'
191         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
192
193   The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
194   described in [RFC2252].
195
1962.7.  integerOrderingMatch
197
198   The integerOrderingMatch rule compares the ordering of the asserted
199   integer with an attribute value of INTEGER syntax.  The rule returns
200   True if the attribute value is less than the asserted value. (Source:
201   X.520)
202
203       ( 2.5.13.15 NAME 'integerOrderingMatch'
204         SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
205
206   The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax is described in
207   [RFC2252].
208
2092.8.  keywordMatch
210
211   The keywordMatch rule compares the asserted string with keywords in
212   an attribute value of DirectoryString syntax.  The rule returns TRUE
213   if and only if the asserted value matches any keyword in the
214   attribute value.  The identification of keywords in an attribute
215   value and of the exactness of match are both implementation specific.
216   (Source: X.520)
217
218       ( 2.5.13.33 NAME 'keywordMatch'
219         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
220
221   The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
222   described in [RFC2252].
223
224
225
226Zeilenga                    Standards Track                     [Page 4]
227
228RFC 3698            LDAP: Additional Matching Rules        February 2004
229
230
2312.9.  numericStringOrderingMatch
232
233   The numericStringOrderingMatch rule compares the collation order of
234   the asserted string with an attribute value of NumericString syntax.
235   The rule is identical to the caseIgnoreOrderingMatch [RFC2252] rule
236   except that all space characters are skipped during comparison (case
237   is irrelevant as characters are numeric).  (Source: X.520)
238
239       ( 2.5.13.9 NAME 'numericStringOrderingMatch'
240         SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
241
242   The NumericString (1.3.6.1.4.1.1466.115.121.1.36) syntax is described
243   in [RFC2252].
244
2452.10.  octetStringOrderingMatch
246
247   The octetStringOrderingMatch rule compares the collation order of the
248   asserted octet string with an attribute value of OCTET STRING syntax.
249   The rule compares octet strings from first octet to last octet, and
250   from the most significant bit to the least significant bit within the
251   octet.  The first occurrence of a different bit determines the
252   ordering of the strings.  A zero bit precedes a one bit.  If the
253   strings are identical but contain different numbers of octets, the
254   shorter string precedes the longer string.  (Source: X.520)
255
256       ( 2.5.13.18 NAME 'octetStringOrderingMatch'
257         SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
258
259   The OCTET STRING (1.3.6.1.4.1.1466.115.121.1.40) syntax is described
260   in [RFC2252].
261
2622.11.  storedPrefixMatch
263
264   The storedPrefixMatch rule determines whether an attribute value,
265   whose syntax is DirectoryString is a prefix (i.e., initial substring)
266   of the asserted value, without regard to the case (upper or lower) of
267   the strings.  The rule returns TRUE if and only if the attribute
268   value is an initial substring of the asserted value with
269   corresponding characters identical except possibly with regard to
270   case.  (Source: X.520)
271
272       ( 2.5.13.41 NAME 'storedPrefixMatch'
273         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
274
275
276
277
278
279
280
281
282Zeilenga                    Standards Track                     [Page 5]
283
284RFC 3698            LDAP: Additional Matching Rules        February 2004
285
286
287   Note: This rule can be used, for example, to compare values in the
288         Directory which are telephone area codes with a purported value
289         which is a telephone number.
290
291   The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
292   described in [RFC2252].
293
2942.12.  wordMatch
295
296   The wordMatch rule compares the asserted string with words in an
297   attribute value of DirectoryString syntax.  The rule returns TRUE if
298   and only if the asserted word matches any word in the attribute
299   value.  Individual word matching is as for the caseIgnoreMatch
300   [RFC2252] matching rule.  The precise definition of a "word" is
301   implementation specific.  (Source: X.520)
302
303       ( 2.5.13.32 NAME 'wordMatch'
304         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
305
306   The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
307   described in [RFC2252].
308
3093.  Security Considerations
310
311   General LDAP security considerations [RFC3377] is applicable to the
312   use of this schema.  Additional considerations are noted above where
313   appropriate.
314
3154.  IANA Considerations
316
317   The Internet Assigned Numbers Authority (IANA) has updated the LDAP
318   descriptors registry [RFC3383] as indicated in the following
319   template:
320
321       Subject: Request for LDAP Descriptor Registration Update
322       Descriptor (short name): see comment
323       Object Identifier: see comments
324       Person & email address to contact for further information:
325           Kurt Zeilenga <kurt@OpenLDAP.org>
326       Usage: see comments
327       Specification: RFC 3698
328       Author/Change Controller: IESG
329       Comments:
330
331
332
333
334
335
336
337
338Zeilenga                    Standards Track                     [Page 6]
339
340RFC 3698            LDAP: Additional Matching Rules        February 2004
341
342
343       The following descriptors have been added:
344
345         NAME                               Type OID
346         ------------------------           ---- ---------
347         booleanMatch                       M    2.5.13.13
348         caseExactMatch                     M    2.5.13.5
349         caseExactOrderingMatch             M    2.5.13.6
350         caseExactSubstringsMatch           M    2.5.13.7
351         caseIgnoreListSubstringsMatch      M    2.5.13.12
352         directoryStringFirstComponentMatch M    2.5.13.31
353         integerOrderingMatch               M    2.5.13.15
354         keywordMatch                       M    2.5.13.33
355         numericStringOrderingMatch         M    2.5.13.9
356         octetStringOrderingMatch           M    2.5.13.18
357         storedPrefixMatch                  M    2.5.13.41
358         wordMatch                          M    2.5.13.32
359
360       where Type M is Matching Rule.
361
362   This document makes no new OID assignments.  It only associates LDAP
363   matching rule descriptions with existing X.500 matching rules.
364
3655.  Acknowledgments
366
367   This document borrows from [X.520], an ITU-T Recommendation.
368
3696.  References
370
3716.1.  Normative References
372
373   [RFC2252]     Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
374                 "Lightweight Directory Access Protocol (v3):  Attribute
375                 Syntax Definitions", RFC 2252, December 1997.
376
377   [RFC3377]     Hodges, J. and R. Morgan, "Lightweight Directory Access
378                 Protocol (v3): Technical Specification", RFC 3377,
379                 September 2002.
380
3816.2.  Informative References
382
383   [RFC2798]     Smith, M., "The LDAP inetOrgPerson Object Class", RFC
384                 2798, April 2000.
385
386   [RFC3383]     Zeilenga, K., "IANA Considerations for LDAP", BCP 64
387                 RFC 3383, September 2002.
388
389   [RFC3703]     Strassner, J., Moore, B., Moats, R. and E. Ellesson,
390                 "Policy Core LDAP Schema", RFC 3703, February 2004.
391
392
393
394Zeilenga                    Standards Track                     [Page 7]
395
396RFC 3698            LDAP: Additional Matching Rules        February 2004
397
398
399   [X.500]       International Telecommunication Union -
400                 Telecommunication Standardization Sector, "The
401                 Directory -- Overview of concepts, models and
402                 services," X.500(1993) (also ISO/IEC 9594-1:1994).
403
404   [X.520]       International Telecommunication Union -
405                 Telecommunication Standardization Sector, "The
406                 Directory: Selected Attribute Types", X.520(1997).
407
4087.  Author's Address
409
410   Kurt D. Zeilenga
411   OpenLDAP Foundation
412
413   EMail: Kurt@OpenLDAP.org
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450Zeilenga                    Standards Track                     [Page 8]
451
452RFC 3698            LDAP: Additional Matching Rules        February 2004
453
454
4558.  Full Copyright Statement
456
457   Copyright (C) The Internet Society (2004).  This document is subject
458   to the rights, licenses and restrictions contained in BCP 78 and
459   except as set forth therein, the authors retain all their rights.
460
461   This document and the information contained herein are provided on an
462   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
463   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
464   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
465   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
466   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
467   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
468
469Intellectual Property
470
471   The IETF takes no position regarding the validity or scope of any
472   Intellectual Property Rights or other rights that might be claimed
473   to pertain to the implementation or use of the technology
474   described in this document or the extent to which any license
475   under such rights might or might not be available; nor does it
476   represent that it has made any independent effort to identify any
477   such rights.  Information on the procedures with respect to
478   rights in RFC documents can be found in BCP 78 and BCP 79.
479
480   Copies of IPR disclosures made to the IETF Secretariat and any
481   assurances of licenses to be made available, or the result of an
482   attempt made to obtain a general license or permission for the use
483   of such proprietary rights by implementers or users of this
484   specification can be obtained from the IETF on-line IPR repository
485   at http://www.ietf.org/ipr.
486
487   The IETF invites any interested party to bring to its attention
488   any copyrights, patents or patent applications, or other
489   proprietary rights that may cover technology that may be required
490   to implement this standard.  Please address the information to the
491   IETF at ietf-ipr@ietf.org.
492
493Acknowledgement
494
495   Funding for the RFC Editor function is currently provided by the
496   Internet Society.
497
498
499
500
501
502
503
504
505
506Zeilenga                    Standards Track                     [Page 9]
507
508