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