8 draft-legg-ldapext-component-matching-10.txt Adacel Technologies
9 Intended Category: Standard Track April 2, 2003
12 LDAP & X.500 Component Matching Rules
14 Copyright (C) The Internet Society (2003). All Rights Reserved.
19 This document is an Internet-Draft and is in full conformance with
20 all provisions of Section 10 of RFC2026.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF), its areas, and its working groups. Note that
24 other groups may also distribute working documents as
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress".
32 The list of current Internet-Drafts can be accessed at
33 http://www.ietf.org/ietf/1id-abstracts.txt
35 The list of Internet-Draft Shadow Directories can be accessed at
36 http://www.ietf.org/shadow.html.
38 Distribution of this document is unlimited. Comments should be sent
39 to the LDAPEXT working group mailing list <ietf-ldapext@netscape.com>
42 This Internet-Draft expires on 2 October 2003.
47 The syntaxes of attributes in a Lightweight Directory Access Protocol
48 or X.500 directory range from simple data types, such as text string,
49 integer, or boolean, to complex structured data types, such as the
50 syntaxes of the directory schema operational attributes. The
51 matching rules defined for the complex syntaxes, if any, usually only
52 provide the most immediately useful matching capability. This
53 document defines generic matching rules that can match any user
54 selected component parts in an attribute value of any arbitrarily
58 Legg Expires 2 October 2003 [Page 1]
60 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
63 complex attribute syntax.
68 1. Table of Contents ............................................. 2
69 2. Introduction .................................................. 2
70 3. Conventions ................................................... 4
71 4. ComponentAssertion ............................................ 5
72 4.1 Component Reference ....................................... 5
73 4.1.1 Component Type Substitutions ......................... 7
74 4.1.2 Referencing SET, SEQUENCE and CHOICE Components ...... 8
75 4.1.3 Referencing SET OF and SEQUENCE OF Components ........ 9
76 4.1.4 Referencing Components of Parameterized Types ........ 10
77 4.1.5 Component Referencing Example ........................ 10
78 4.1.6 Referencing Components of Open Types ................. 11
79 4.1.6.1 Open Type Referencing Example ................... 12
80 4.1.7 Referencing Contained Types .......................... 13
81 4.1.7.1 Contained Type Referencing Example .............. 14
82 4.2 Matching of Components .................................... 15
83 4.2.1 Applicability of Existing Matching Rules ............. 16
84 4.2.1.1 String Matching ................................. 16
85 4.2.1.2 Telephone Number Matching ....................... 17
86 4.2.1.3 Distinguished Name Matching ..................... 17
87 4.2.2 Additional Useful Matching Rules ..................... 17
88 4.2.2.1 The rdnMatch Matching Rule ...................... 17
89 4.2.2.2 The presentMatch Matching Rule .................. 18
90 4.2.3 Summary of Useful Matching Rules ..................... 19
91 5. ComponentFilter ............................................... 21
92 6. The componentFilterMatch Matching Rule ........................ 22
93 7. Equality Matching of Complex Components ....................... 23
94 7.1 The OpenAssertionType Syntax .............................. 24
95 7.2 The allComponentsMatch Matching Rule ...................... 25
96 7.3 Deriving Component Equality Matching Rules ................ 27
97 7.4 The directoryComponentsMatch Matching Rule ................ 28
98 8. Component Matching Examples ................................... 29
99 9. Security Considerations ....................................... 36
100 10. Acknowledgements ............................................. 37
101 11. Normative References ......................................... 37
102 12. Informative References ....................................... 38
103 13. Copyright Notice ............................................. 38
104 14. Author's Address ............................................. 39
109 The structure or data type of data held in an attribute of an LDAP
110 [RFC3377] or X.500 [18] directory is described by the attribute's
114 Legg Expires 2 October 2003 [Page 2]
116 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
119 syntax. Attribute syntaxes range from simple data types, such as
120 text string, integer, or boolean, to complex data types, for example,
121 the syntaxes of the directory schema operational attributes.
123 In X.500, the attribute syntaxes are explicitly described by ASN.1
124 [11] type definitions. ASN.1 type notation has a number of simple
125 data types (e.g. PrintableString, INTEGER, BOOLEAN), and combining
126 types (i.e. SET, SEQUENCE, SET OF, SEQUENCE OF, and CHOICE) for
127 constructing arbitrarily complex data types from simpler component
128 types. In LDAP, the attribute syntaxes are usually described by ABNF
129 [2] though there is an implied association between the LDAP attribute
130 syntaxes and the X.500 ASN.1 types. To a large extent, the data
131 types of attribute values in either an LDAP or X.500 directory are
132 described by ASN.1 types. This formal description can be exploited
133 to identify component parts of an attribute value for a variety of
134 purposes. This document addresses attribute value matching.
136 With any complex attribute syntax there is normally a requirement to
137 partially match an attribute value of that syntax by matching only
138 selected components of the value. Typically, matching rules specific
139 to the attribute syntax are defined to fill this need. These highly
140 specific matching rules usually only provide the most immediately
141 useful matching capability. Some complex attribute syntaxes don't
142 even have an equality matching rule let alone any additional matching
143 rules for partial matching. This document defines a generic way of
144 matching user selected components in an attribute value of any
145 arbitrarily complex attribute syntax, where that syntax is described
146 using ASN.1 type notation. All of the type notations defined in [11]
149 Section 4 describes the ComponentAssertion, a testable assertion
150 about the value of a component of an attribute value of any complex
153 Section 5 introduces the ComponentFilter assertion, which is an
154 expression of ComponentAssertions. The ComponentFilter enables more
155 powerful filter matching of components in an attribute value.
157 Section 6 defines the componentFilterMatch matching rule, which
158 enables a ComponentFilter to be evaluated against attribute values.
160 Section 7 defines matching rules for component-wise equality matching
161 of attribute values of any syntax described by an ASN.1 type
164 Examples showing the usage of componentFilterMatch are in Section 8.
166 For a new attribute syntax, the Generic String Encoding Rules [7] and
170 Legg Expires 2 October 2003 [Page 3]
172 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
175 the specifications in sections 4 to 7 of this document make it
176 possible to fully and precisely define, the LDAP-specific encoding,
177 the LDAP and X.500 binary encoding (and possibly other encodings in
178 the future, e.g. XML via XER), a suitable equality matching rule, and
179 a comprehensive collection of component matching capabilities, by
180 simply writing down an ASN.1 type definition for the syntax. These
181 implicit definitions are also automatically extended if the ASN.1
182 type is later extended. The algorithmic relationship between the
183 ASN.1 type definition, the various encodings and the component
184 matching behaviour makes directory server implementation support for
185 the component matching rules amenable to automatic code generation
186 from ASN.1 type definitions.
188 Schema designers have the choice of storing related items of data as
189 a single attribute value of a complex syntax in some entry, or as a
190 subordinate entry where the related data items are stored as separate
191 attribute values of simpler syntaxes. The inability to search
192 component parts of a complex syntax has been used as an argument for
193 favouring the subordinate entries approach. The component matching
194 rules provide the analogous matching capability on an attribute value
195 of a complex syntax that a search filter has on a subordinate entry.
197 Most LDAP syntaxes have corresponding ASN.1 type definitions, though
198 they are usually not reproduced or referenced alongside the formal
199 definition of the LDAP syntax. Syntaxes defined with only a
200 character string encoding, i.e. without an explicit or implied
201 corresponding ASN.1 type definition, cannot use the component
202 matching capabilities described in this document unless and until a
203 semantically equivalent ASN.1 type definition is defined for them.
208 Throughout this document "type" shall be taken to mean an ASN.1 type
209 unless explicitly qualified as an attribute type, and "value" shall
210 be taken to mean an ASN.1 value unless explicitly qualified as an
213 Note that "ASN.1 value" does not mean a BER [16] encoded value. The
214 ASN.1 value is an abstract concept that is independent of any
215 particular encoding. BER is just one possible encoding of an ASN.1
216 value. The component matching rules operate at the abstract level
217 without regard for the possible encodings of a value.
219 Attribute type and matching rule definitions in this document are
220 provided in both the X.500 [8] and LDAP [4] description formats. Note
221 that the LDAP descriptions have been rendered with additional
222 white-space and line breaks for the sake of readability.
226 Legg Expires 2 October 2003 [Page 4]
228 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
231 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
232 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
233 document are to be interpreted as described in RFC 2119 [1].
236 4. ComponentAssertion
238 A ComponentAssertion is an assertion about the presence, or values
239 of, components within an ASN.1 value, i.e. an instance of an ASN.1
240 type. The ASN.1 value is typically an attribute value, where the
241 ASN.1 type is the syntax of the attribute. However a
242 ComponentAssertion may also be applied to a component part of an
243 attribute value. The assertion evaluates to either TRUE, FALSE or
244 undefined for each tested ASN.1 value.
246 A ComponentAssertion is described by the following ASN.1 type
247 (assumed to be defined with "EXPLICIT TAGS" in force):
249 ComponentAssertion ::= SEQUENCE {
250 component ComponentReference (SIZE(1..MAX)) OPTIONAL,
251 useDefaultValues BOOLEAN DEFAULT TRUE,
252 rule MATCHING-RULE.&id,
253 value MATCHING-RULE.&AssertionType }
255 ComponentReference ::= UTF8String
257 MATCHING-RULE.&id equates to the OBJECT IDENTIFIER of a matching
258 rule. MATCHING-RULE.&AssertionType is an open type (formally known
261 The "component" field of a ComponentAssertion identifies which
262 component part of a value of some ASN.1 type is to be tested, the
263 "useDefaultValues" field indicates whether DEFAULT values are to be
264 substituted for absent component values, the "rule" field indicates
265 how the component is to be tested, and the "value" field is an
266 asserted ASN.1 value against which the component is tested. The
267 ASN.1 type of the asserted value is determined by the chosen rule.
269 The fields of a ComponentAssertion are described in detail in the
273 4.1 Component Reference
275 The component field in a ComponentAssertion is a UTF8 character
276 string [6] whose textual content is a component reference,
277 identifying a component part of some ASN.1 type or value. A
278 component reference conforms to the following ABNF [2], which extends
282 Legg Expires 2 October 2003 [Page 5]
284 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
287 the notation defined in Clause 14 of [11]:
289 component-reference = ComponentId *( "." ComponentId )
290 ComponentId = identifier /
293 from-end / ; extends Clause 14
294 content / ; extends Clause 14
295 select / ; extends Clause 14
298 identifier = lowercase *alphanumeric
299 *(hyphen 1*alphanumeric)
300 alphanumeric = uppercase / lowercase / decimal-digit
301 uppercase = %x41-5A ; "A" to "Z"
302 lowercase = %x61-7A ; "a" to "z"
305 from-beginning = positive-number
307 from-end = "-" positive-number
308 content = %x63.6F.6E.74.65.6E.74 ; "content"
309 select = "(" Value *( "," Value ) ")"
313 positive-number = non-zero-digit *decimal-digit
315 decimal-digit = %x30-39 ; "0" to "9"
316 non-zero-digit = %x31-39 ; "1" to "9"
318 An <identifier> conforms to the definition of an identifier in ASN.1
319 notation (Clause 11.3 of [11]). It begins with a lowercase letter
320 and is followed by zero or more letters, digits, and hyphens. A
321 hyphen is not permitted to be the last character and a hyphen is not
322 permitted to be followed by another hyphen.
324 The <Value> rule is described in [7].
326 A component reference is a sequence of one or more ComponentIds where
327 each successive ComponentId identifies either an inner component at
328 the next level of nesting of an ASN.1 combining type, i.e. SET,
329 SEQUENCE, SET OF, SEQUENCE OF, or CHOICE, or a specific type within
332 A component reference is always considered in the context of a
333 particular complex ASN.1 type. When applied to the ASN.1 type the
334 component reference identifies a specific component type. When
338 Legg Expires 2 October 2003 [Page 6]
340 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
343 applied to a value of the ASN.1 type a component reference identifies
344 zero, one or more component values of that component type. The
345 component values are potentially in a DEFAULT value if
346 useDefaultValues is TRUE. The specific component type identified by
347 the component reference determines what matching rules are capable of
348 being used to match the component values.
350 The component field in a ComponentAssertion may also be absent, in
351 which case the identified component type is the ASN.1 type to which
352 the ComponentAssertion is applied, and the identified component value
353 is the whole ASN.1 value.
355 A valid component reference for a particular complex ASN.1 type is
356 constructed by starting with the outermost combining type and
357 repeatedly selecting one of the permissible forms of ComponentId to
358 identify successively deeper nested components. A component
359 reference MAY identify a component with a complex ASN.1 type, i.e. it
360 is NOT required that the component type identified by a component
361 reference be a simple ASN.1 type.
364 4.1.1 Component Type Substitutions
366 ASN.1 type notation has a number of constructs for referencing other
367 defined types, and constructs that are irrelevant for matching
368 purposes. These constructs are not represented in a component
369 reference in any way and substitutions of the component type are
370 performed to eliminate them from further consideration. These
371 substitutions automatically occur prior to each ComponentId, whether
372 constructing or interpreting a component reference, but do not occur
373 after the last ComponentId, except as allowed by Section 4.2.
375 If the ASN.1 type is an ASN.1 type reference then the component type
376 is taken to be the actual definition on the right hand side of the
377 type assignment for the referenced type.
379 If the ASN.1 type is a tagged type then the component type is taken
380 to be the type without the tag.
382 If the ASN.1 type is a constrained type (see [11] and [14] for the
383 details of ASN.1 constraint notation) then the component type is
384 taken to be the type without the constraint.
386 If the ASN.1 type is an ObjectClassFieldType (Clause 14 of [13]) that
387 denotes a specific ASN.1 type (e.g. MATCHING-RULE.&id denotes the
388 OBJECT IDENTIFIER type) then the component type is taken to be the
389 denoted type. Section 4.1.6 describes the case where the
390 ObjectClassFieldType denotes an open type.
394 Legg Expires 2 October 2003 [Page 7]
396 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
399 If the ASN.1 type is a selection type other than one used in the list
400 of components for a SET or SEQUENCE type then the component type is
401 taken to be the selected alternative type from the named CHOICE.
403 If the ASN.1 type is a TypeFromObject (Clause 15 of [13]) then the
404 component type is taken to be the denoted type.
406 If the ASN.1 type is a ValueSetFromObjects (Clause 15 of [13]) then
407 the component type is taken to be the governing type of the denoted
411 4.1.2 Referencing SET, SEQUENCE and CHOICE Components
413 If the ASN.1 type is a SET or SEQUENCE type then the <identifier>
414 form of ComponentId MAY be used to identify the component type within
415 that SET or SEQUENCE having that identifier. If <identifier>
416 references an OPTIONAL component type and that component is not
417 present in a particular value then there are no corresponding
418 component values. If <identifier> references a DEFAULT component
419 type and useDefaultValues is TRUE (the default setting for
420 useDefaultValues) and that component is not present in a particular
421 value then the component value is taken to be the default value. If
422 <identifier> references a DEFAULT component type and useDefaultValues
423 is FALSE and that component is not present in a particular value then
424 there are no corresponding component values.
426 If the ASN.1 type is a CHOICE type then the <identifier> form of
427 ComponentId MAY be used to identify the alternative type within that
428 CHOICE having that identifier. If <identifier> references an
429 alternative other than the one used in a particular value then there
430 are no corresponding component values.
432 The COMPONENTS OF notation in Clause 24 of [11] augments the defined
433 list of components in a SET or SEQUENCE type by including all the
434 components of another defined SET or SEQUENCE type respectively.
435 These included components are referenced directly by identifier as
436 though they were defined in-line in the SET or SEQUENCE type
437 containing the COMPONENTS OF notation.
439 The SelectionType (Clause 29 of [11]), when used in the list of
440 components for a SET or SEQUENCE type, includes a single component
441 from a defined CHOICE type. This included component is referenced
442 directly by identifier as though it was defined in-line in the SET or
445 The REAL type is treated as though it is the SEQUENCE type defined in
450 Legg Expires 2 October 2003 [Page 8]
452 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
455 The EMBEDDED PDV type is treated as though it is the SEQUENCE type
456 defined in Clause 32.5 of [11].
458 The EXTERNAL type is treated as though it is the SEQUENCE type
459 defined in Clause 8.18.1 of [16].
461 The unrestricted CHARACTER STRING type is treated as though it is the
462 SEQUENCE type defined in Clause 39.5 of [11].
464 The INSTANCE OF type is treated as though it is the SEQUENCE type
465 defined in Annex C of [13].
467 The <identifier> form MUST NOT be used on any other ASN.1 type.
470 4.1.3 Referencing SET OF and SEQUENCE OF Components
472 If the ASN.1 type is a SET OF or SEQUENCE OF type then the
473 <from-beginning>, <from-end>, <count> and <all> forms of ComponentId
476 The <from-beginning> form of ComponentId MAY be used to identify one
477 instance (i.e. value) of the component type of the SET OF or SEQUENCE
478 OF type (e.g. if Foo ::= SET OF Bar, then Bar is the component type),
479 where the instances are numbered from one upwards. If
480 <from-beginning> references a higher numbered instance than the last
481 instance in a particular value of the SET OF or SEQUENCE OF type then
482 there is no corresponding component value.
484 The <from-end> form of ComponentId MAY be used to identify one
485 instance of the component type of the SET OF or SEQUENCE OF type,
486 where "-1" is the last instance, "-2" is the second last instance,
487 and so on. If <from-end> references a lower numbered instance than
488 the first instance in a particular value of the SET OF or SEQUENCE OF
489 type then there is no corresponding component value.
491 The <count> form of ComponentId identifies a notional count of the
492 number of instances of the component type in a value of the SET OF or
493 SEQUENCE OF type. This count is not explicitly represented but for
494 matching purposes it has an assumed ASN.1 type of INTEGER (0..MAX).
495 A ComponentId of the <count> form, if used, MUST be the last
496 ComponentId in a component reference.
498 The <all> form of ComponentId MAY be used to simultaneously identify
499 all instances of the component type of the SET OF or SEQUENCE OF
500 type. It is through the <all> form that a component reference can
501 identify more than one component value. However, if a particular
502 value of the SET OF or SEQUENCE OF type is an empty list there are no
506 Legg Expires 2 October 2003 [Page 9]
508 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
511 corresponding component values.
513 Where multiple component values are identified, the remaining
514 ComponentIds in the component reference, if any, can identify zero,
515 one or more subcomponent values for each of the higher level
518 The corresponding ASN.1 type for the <from-beginning>, <from-end>,
519 and <all> forms of ComponentId is the component type of the SET OF or
522 The <from-beginning>, <count>, <from-end> and <all> forms MUST NOT be
523 used on ASN.1 types other than SET OF or SEQUENCE OF.
526 4.1.4 Referencing Components of Parameterized Types
528 A component reference cannot be formed for a parameterized type
529 unless the type has been used with actual parameters, in which case
530 the type is treated as though the DummyReferences [15] have been
531 substituted with the actual parameters.
534 4.1.5 Component Referencing Example
536 Consider the following ASN.1 type definitions.
538 ExampleType ::= SEQUENCE {
540 part2 [1] ExampleSet,
541 part3 [2] SET OF OBJECT IDENTIFIER,
542 part4 [3] ExampleChoice }
545 option PrintableString,
548 ExampleChoice ::= CHOICE {
549 eeny-meeny BIT STRING,
550 miney-mo OCTET STRING }
552 Following are component references constructed with respect to the
555 The component reference "part1" identifies a component of a value of
556 ExampleType having the ASN.1 tagged type [0] INTEGER.
558 The component reference "part2" identifies a component of a value of
562 Legg Expires 2 October 2003 [Page 10]
564 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
567 ExampleType having the ASN.1 type of [1] ExampleSet
569 The component reference "part2.option" identifies a component of a
570 value of ExampleType having the ASN.1 type of PrintableString. A
571 ComponentAssertion could also be applied to a value of ASN.1 type
572 ExampleSet, in which case the component reference "option" would
573 identify the same kind of information.
575 The component reference "part3" identifies a component of a value of
576 ExampleType having the ASN.1 type of [2] SET OF OBJECT IDENTIFIER.
578 The component reference "part3.2" identifies the second instance of
579 the part3 SET OF. The instance has the ASN.1 type of OBJECT
582 The component reference "part3.0" identifies the count of the number
583 of instances in the part3 SET OF. The count has the corresponding
584 ASN.1 type of INTEGER (0..MAX).
586 The component reference "part3.*" identifies all the instances in the
587 part3 SET OF. Each instance has the ASN.1 type of OBJECT IDENTIFIER.
589 The component reference "part4" identifies a component of a value of
590 ExampleType having the ASN.1 type of [3] ExampleChoice.
592 The component reference "part4.miney-mo" identifies a component of a
593 value of ExampleType having the ASN.1 type of OCTET STRING.
596 4.1.6 Referencing Components of Open Types
598 If a sequence of ComponentIds identifies an ObjectClassFieldType
599 denoting an open type (e.g. ATTRIBUTE.&Type denotes an open type)
600 then the ASN.1 type of the component varies. An open type is
601 typically constrained by some other component(s) in an outer
602 enclosing type, either formally through the use of a component
603 relation constraint [14], or informally in the accompanying text, so
604 the actual ASN.1 type of a value of the open type will generally be
605 known. The constraint will also limit the range of permissible
606 types. The <select> form of ComponentId MAY be used to identify one
607 of these permissible types in an open type. Subcomponents of that
608 type can then be identified with further ComponentIds.
610 The other components constraining the open type are termed the
611 referenced components (using the terminology in [14]). The <select>
612 form contains a list of one or more values which take the place of
613 the value(s) of the referenced component(s) to uniquely identify one
614 of the permissable types of the open type.
618 Legg Expires 2 October 2003 [Page 11]
620 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
623 Where the open type is constrained by a component relation
624 constraint, there is a <Value> in the <select> form for each of the
625 referenced components in the component relation constraint, appearing
626 in the same order. The ASN.1 type of each of these values is the
627 same as the ASN.1 type of the corresponding referenced component.
628 The type of a referenced component is potentially any ASN.1 type
629 however it is typically an OBJECT IDENTIFIER or INTEGER, which means
630 that the <Value> in the <select> form of ComponentId will nearly
631 always be an <ObjectIdentifierValue> or <IntegerValue> (see [7]).
632 Furthermore, component relation constraints typically have only one
633 referenced component.
635 Where the open type is not constrained by a component relation
636 constraint, the specification introducing the syntax containing the
637 open type SHOULD explicitly nominate the referenced components and
638 their order, so that the <select> form can be used.
640 If an instance of <select> contains a value other than the value of
641 the referenced component used in a particular value of the outer
642 enclosing type then there are no corresponding component values for
646 4.1.6.1 Open Type Referencing Example
648 The ASN.1 type AttributeTypeAndValue from [8] describes a single
649 attribute value of a nominated attribute type.
651 AttributeTypeAndValue ::= SEQUENCE {
652 type ATTRIBUTE.&id ({SupportedAttributes}),
653 value ATTRIBUTE.&Type ({SupportedAttributes}{@type}) }
655 ATTRIBUTE.&id denotes an OBJECT IDENTIFIER and
656 ({SupportedAttributes}) constrains the OBJECT IDENTIFIER to be a
657 supported attribute type.
659 ATTRIBUTE.&Type denotes an open type, in this case an attribute
660 value, and ({SupportedAttributes}{@type}) is a component relation
661 constraint that constrains the open type to be of the attribute
662 syntax for the attribute type. The component relation constraint
663 references only the "type" component, which has the ASN.1 type of
664 OBJECT IDENTIFIER, thus if the <select> form of ComponentId is used
665 to identify attribute values of specific attribute types it will
666 contain a single OBJECT IDENTIFIER value.
668 The component reference "value" on AttributeTypeAndValue refers to
674 Legg Expires 2 October 2003 [Page 12]
676 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
679 One of the X.500 standard attributes is facsimileTelephoneNumber
680 [10], which is identified with the OBJECT IDENTIFIER 2.5.4.23, and is
681 defined to have the following syntax.
683 FacsimileTelephoneNumber ::= SEQUENCE {
684 telephoneNumber PrintableString(SIZE(1..ub-telephone-number)),
685 parameters G3FacsimileNonBasicParameters OPTIONAL }
687 The component reference "value.(2.5.4.23)" on AttributeTypeAndValue
688 specifies an attribute value with the FacsimileTelephoneNumber
691 The component reference "value.(2.5.4.23).telephoneNumber" on
692 AttributeTypeAndValue identifies the telephoneNumber component of a
693 facsimileTelephoneNumber attribute value. The component reference
694 "value.(facsimileTelephoneNumber)" is equivalent to
697 If the AttributeTypeAndValue ASN.1 value contains an attribute type
698 other than facsimileTelephoneNumber then there are no corresponding
699 component values for the component references "value.(2.5.4.23)" and
700 "value.(2.5.4.23).telephoneNumber".
703 4.1.7 Referencing Contained Types
705 Sometimes the contents of a BIT STRING or OCTET STRING value are
706 required to be the encodings of other ASN.1 values of specific ASN.1
707 types. For example, the extnValue component of the Extension type
708 component in the Certificate type [9] is an OCTET STRING that is
709 required to contain a DER encoding of a certificate extension value.
710 It is useful to be able to refer to the embedded encoded value and
711 its components. An embedded encoded value is here referred to as a
712 contained value and its associated type as the contained type.
714 If the ASN.1 type is a BIT STRING or OCTET STRING type containing
715 encodings of other ASN.1 values then the <content> form of
716 ComponentId MAY be used to identify the contained type.
717 Subcomponents of that type can then be identified with further
720 The contained type may be (effectively) an open type, constrained by
721 some other component in an outer enclosing type (e.g. in a
722 certificate Extension, extnValue is constrained by the chosen
723 extnId). In these cases the next ComponentId, if any, MUST be of the
726 For the purpose of building component references, the content of the
730 Legg Expires 2 October 2003 [Page 13]
732 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
735 extnValue OCTET STRING in the Extension type is assumed to be an open
736 type having a notional component relation constraint with the extnId
737 component as the single referenced component, i.e.
739 EXTENSION.&ExtnType ({ExtensionSet}{@extnId})
741 The data-value component of the associated types for the EMBEDDED PDV
742 and CHARACTER STRING types is an OCTET STRING containing the encoding
743 of a data value described by the identification component. For the
744 purpose of building component references, the content of the
745 data-value OCTET STRING in these types is assumed to be an open type
746 having a notional component relation constraint with the
747 identification component as the single referenced component.
750 4.1.7.1 Contained Type Referencing Example
752 The Extension ASN.1 type from [9] describes a single certificate
753 extension value of a nominated extension type.
755 Extension ::= SEQUENCE {
756 extnId EXTENSION.&id ({ExtensionSet}),
757 critical BOOLEAN DEFAULT FALSE,
758 extnValue OCTET STRING
759 -- contains a DER encoding of a value of type &ExtnType
760 -- for the extension object identified by extnId -- }
762 EXTENSION.&id denotes an OBJECT IDENTIFIER and ({ExtensionSet})
763 constrains the OBJECT IDENTIFIER to be the identifier of a supported
764 certificate extension.
766 The component reference "extnValue" on Extension refers to a
767 component type of OCTET STRING. The corresponding component values
768 will be OCTET STRING values. The component reference
769 "extnValue.content" on Extension refers to the type of the contained
770 type, which in this case is an open type.
772 One of the X.509 [X.509] standard extensions is basicConstraints,
773 which is identified with the OBJECT IDENTIFIER 2.5.29.19 and is
774 defined to have the following syntax.
776 BasicConstraintsSyntax ::= SEQUENCE {
777 cA BOOLEAN DEFAULT FALSE,
778 pathLenConstraint INTEGER (0..MAX) OPTIONAL }
780 The component reference "extnValue.content.(2.5.29.19)" on Extension
781 specifies a BasicConstraintsSyntax extension value and the component
782 reference "extnValue.content.(2.5.29.19).cA" identifies the cA
786 Legg Expires 2 October 2003 [Page 14]
788 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
791 component of a BasicConstraintsSyntax extension value.
794 4.2 Matching of Components
796 The rule in a ComponentAssertion specifies how the zero, one or more
797 component values identified by the component reference are tested by
798 the assertion. Attribute matching rules are used to specify the
799 semantics of the test.
801 Each matching rule has a notional set of attribute syntaxes
802 (typically one), defined as ASN.1 types, to which it may be applied.
803 When used in a ComponentAssertion these matching rules apply to the
804 same ASN.1 types, only in this context the corresponding ASN.1 values
805 are not necessarily complete attribute values.
807 Note that the referenced component type may be a tagged and/or
808 constrained version of the expected attribute syntax (e.g. [0]
809 INTEGER, whereas integerMatch would expect simply INTEGER), or an
810 open type. Additional type substitutions of the kind described in
811 Section 4.1.1 are performed as required to reduce the component type
812 to the same type as the attribute syntax expected by the matching
815 If a matching rule applies to more than one attribute syntax (e.g.
816 objectIdentifierFirstComponentMatch [10]) then the minimum number of
817 substitutions required to conform to any one of those syntaxes is
818 performed. If a matching rule can apply to any attribute syntax
819 (e.g. the allComponentsMatch rule defined in Section 7.2) then the
820 referenced component type is used as is, with no additional
823 The value in a ComponentAssertion will be of the assertion syntax
824 (i.e. ASN.1 type) required by the chosen matching rule. Note that
825 the assertion syntax of a matching rule is not necessarily the same
826 as the attribute syntax(es) to which the rule may be applied.
828 Some matching rules do not have a fixed assertion syntax (e.g.
829 allComponentsMatch). The required assertion syntax is determined in
830 each instance of use by the syntax of the attribute type to which the
831 matching rule is applied. For these rules the ASN.1 type of the
832 referenced component is used in place of an attribute syntax to
833 decide the required assertion syntax.
835 The ComponentAssertion is undefined if:
837 a) the matching rule in the ComponentAssertion is not known to the
838 evaluating procedure,
842 Legg Expires 2 October 2003 [Page 15]
844 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
847 b) if the matching rule is not applicable to the referenced component
848 type, even with the additional type substitutions,
850 c) the value in the ComponentAssertion does not conform to the
851 assertion syntax defined for the matching rule,
853 d) some part of the component reference identifies an open type in
854 the tested value that cannot be decoded, or
856 e) the implementation does not support the particular combination of
857 component reference and matching rule.
859 If the ComponentAssertion is not undefined then the
860 ComponentAssertion evaluates to TRUE if there is at least one
861 component value for which the matching rule applied to that component
862 value returns TRUE, and evaluates to FALSE otherwise (which includes
863 the case where there are no component values).
866 4.2.1 Applicability of Existing Matching Rules
868 4.2.1.1 String Matching
870 ASN.1 has a number of built in restricted character string types with
871 different character sets and/or different character encodings. A
872 directory user generally has little interest in the particular
873 character set or encoding used to represent a character string
874 component value, and some directory server implementations make no
875 distinction between the different string types in their internal
876 representation of values. So rather than define string matching
877 rules for each of the restricted character string types, the existing
878 case ignore and case exact string matching rules are extended to
879 apply to component values of any of the restricted character string
880 types and any ChoiceOfStrings type [7], in addition to component
881 values of the DirectoryString type. This extension is only for the
882 purposes of component matching described in this document.
884 The relevant string matching rules are: caseIgnoreMatch,
885 caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch, caseExactMatch,
886 caseExactOrderingMatch and caseExactSubstringsMatch. The relevant
887 restricted character string types are: NumericString,
888 PrintableString, VisibleString, IA5String, UTF8String, BMPString,
889 UniversalString, TeletexString, VideotexString, GraphicString and
890 GeneralString. A ChoiceOfStrings type is a purely syntactic CHOICE
891 of these ASN.1 string types. Note that [7] declares each and every
892 use of the DirectoryString{} parameterized type to be a
893 ChoiceOfStrings type.
898 Legg Expires 2 October 2003 [Page 16]
900 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
903 The assertion syntax of the string matching rules is still
904 DirectoryString regardless of the string syntax of the component
905 being matched. Thus an implementation will be called upon to compare
906 a DirectoryString value to a value of one of the restricted character
907 string types, or a ChoiceOfStrings type. As is the case when
908 comparing two DirectoryStrings where the chosen alternatives are of
909 different string types, the comparison proceeds so long as the
910 corresponding characters are representable in both character sets.
911 Otherwise matching returns FALSE.
914 4.2.1.2 Telephone Number Matching
916 Early editions of X.520 [10] gave the syntax of the telephoneNumber
917 attribute as a constrained PrintableString. The fourth edition of
918 X.520 equates the ASN.1 type name TelephoneNumber to the constrained
919 PrintableString and uses TelephoneNumber as the attribute and
920 assertion syntax. For the purposes of component matching,
921 telephoneNumberMatch and telephoneNumberSubstringsMatch are permitted
922 to be applied to any PrintableString value, as well as to
923 TelephoneNumber values.
926 4.2.1.3 Distinguished Name Matching
928 The DistinguishedName type is defined by assignment to be the same as
929 the RDNSequence type, however RDNSequence is sometimes directly used
930 in other type definitions. For the purposes of component matching,
931 distinguishedNameMatch is also permitted to be applied to values of
932 the RDNSequence type.
935 4.2.2 Additional Useful Matching Rules
937 This section defines additional matching rules that may prove useful
938 in ComponentAssertions. These rules MAY also be used in
939 extensibleMatch search filters [3].
942 4.2.2.1 The rdnMatch Matching Rule
944 The distinguishedNameMatch matching rule can match whole
945 distinguished names but it is sometimes useful to be able to match
946 specific RDNs in a DN without regard for the other RDNs in the DN.
947 The rdnMatch matching rule allows component RDNs of a DN to be
950 The LDAP-style definitions for rdnMatch and its assertion syntax are:
954 Legg Expires 2 October 2003 [Page 17]
956 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
959 ( 1.2.36.79672281.1.13.3 NAME 'rdnMatch'
960 SYNTAX 1.2.36.79672281.1.5.0 )
962 ( 1.2.36.79672281.1.5.0 DESC 'RDN' )
964 The LDAP-specific encoding for a value of the RDN syntax is given by
965 the <RelativeDistinguishedNameValue> rule in [7].
967 The X.500-style definition for rdnMatch is:
969 rdnMatch MATCHING-RULE ::= {
970 SYNTAX RelativeDistinguishedName
971 ID { 1 2 36 79672281 1 13 3 } }
973 The rdnMatch rule evaluates to true if the component value and
974 assertion value are the same RDN, using the same RDN comparison
975 method as distinguishedNameMatch.
977 When using rdnMatch to match components of DNs it is important to
978 note that the LDAP-specific encoding of a DN [5] reverses the order
979 of the RDNs. So for the DN represented in LDAP as "cn=Steven
980 Legg,o=Adacel,c=AU", the RDN "cn=Steven Legg" corresponds to the
981 component reference "3", or alternatively, "-1".
984 4.2.2.2 The presentMatch Matching Rule
986 At times it would be useful to test not if a specific value of a
987 particular component is present, but whether any value of a
988 particular component is present. The presentMatch matching rule
989 allows the presence of a particular component value to be tested.
991 The LDAP-style definitions for presentMatch and its assertion syntax
994 ( 1.2.36.79672281.1.13.5 NAME 'presentMatch'
995 SYNTAX 1.2.36.79672281.1.5.1 )
997 ( 1.2.36.79672281.1.5.1 DESC 'NULL' )
999 The LDAP-specific encoding for a value of the NULL syntax is given by
1000 the <NullValue> rule in [7].
1002 The X.500-style definition for presentMatch is:
1004 presentMatch MATCHING-RULE ::= {
1006 ID { 1 2 36 79672281 1 13 5 } }
1010 Legg Expires 2 October 2003 [Page 18]
1012 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
1015 When used in a extensible match filter item, presentMatch behaves
1016 like the "present" case of a regular search filter. In a
1017 ComponentAssertion, presentMatch evaluates to TRUE if and only if the
1018 component reference identifies one or more component values,
1019 regardless of the actual component value contents. Note that if
1020 useDefaultValues is TRUE then the identified component values may be
1021 (part of) a DEFAULT value.
1023 The notional count referenced by the <count> form of ComponentId is
1024 taken to be present if the SET OF value is present, and absent
1025 otherwise. Note that in ASN.1 notation an absent SET OF value is
1026 distinctly different from a SET OF value that is present but empty.
1027 It is up to the specification using the ASN.1 notation to decide
1028 whether the distinction matters. Often an empty SET OF component and
1029 an absent SET OF component are treated as semantically equivalent.
1030 If a SET OF value is present, but empty, a presentMatch on the SET OF
1031 component SHALL return TRUE and the notional count SHALL be regarded
1032 as present and equal to zero.
1035 4.2.3 Summary of Useful Matching Rules
1037 The following is a non-exhaustive list of useful matching rules and
1038 the ASN.1 types to which they can be applied, taking account of all
1039 the extensions described in Section 4.2.1, and the new matching rules
1040 defined in Section 4.2.2.
1066 Legg Expires 2 October 2003 [Page 19]
1068 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
1071 +================================+==============================+
1072 | Matching Rule | ASN.1 Type |
1073 +================================+==============================+
1074 | bitStringMatch | BIT STRING |
1075 +--------------------------------+------------------------------+
1076 | booleanMatch | BOOLEAN |
1077 +--------------------------------+------------------------------+
1078 | caseIgnoreMatch | NumericString |
1079 | caseIgnoreOrderingMatch | PrintableString |
1080 | caseIgnoreSubstringsMatch | VisibleString (ISO646String) |
1081 | caseExactMatch | IA5String |
1082 | caseExactOrderingMatch | UTF8String |
1083 | caseExactSubstringsMatch | BMPString (UCS-2, UNICODE) |
1084 | | UniversalString (UCS-4) |
1085 | | TeletexString (T61String) |
1086 | | VideotexString |
1089 | | any ChoiceOfStrings type |
1090 +--------------------------------+------------------------------+
1091 | caseIgnoreIA5Match | IA5String |
1092 | caseExactIA5Match | |
1093 +--------------------------------+------------------------------+
1094 | distinguishedNameMatch | DistinguishedName |
1096 +--------------------------------+------------------------------+
1097 | generalizedTimeMatch | GeneralizedTime |
1098 | generalizedTimeOrderingMatch | |
1099 +--------------------------------+------------------------------+
1100 | integerMatch | INTEGER |
1101 | integerOrderingMatch | |
1102 +--------------------------------+------------------------------+
1103 | numericStringMatch | NumericString |
1104 | numericStringOrderingMatch | |
1105 | numericStringSubstringsMatch | |
1106 +--------------------------------+------------------------------+
1107 | objectIdentifierMatch | OBJECT IDENTIFIER |
1108 +--------------------------------+------------------------------+
1109 | octetStringMatch | OCTET STRING |
1110 | octetStringOrderingMatch | |
1111 | octetStringSubstringsMatch | |
1112 +--------------------------------+------------------------------+
1113 | presentMatch | any ASN.1 type |
1114 +--------------------------------+------------------------------+
1115 | rdnMatch | RelativeDistinguishedName |
1116 +--------------------------------+------------------------------+
1117 | telephoneNumberMatch | PrintableString |
1118 | telephoneNumberSubstringsMatch | TelephoneNumber |
1122 Legg Expires 2 October 2003 [Page 20]
1124 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
1127 +--------------------------------+------------------------------+
1128 | uTCTimeMatch | UTCTime |
1129 | uTCTimeOrderingMatch | |
1130 +--------------------------------+------------------------------+
1132 Note that the allComponentsMatch matching rule defined in Section 7.2
1133 can be used for equality matching of values of the ENUMERATED, NULL,
1134 REAL and RELATIVE-OID ASN.1 types, among other things.
1139 The ComponentAssertion allows the value(s) of any one component type
1140 in a complex ASN.1 type to be matched, but there is often a desire to
1141 match the values of more than one component type. A ComponentFilter
1142 is an assertion about the presence, or values of, multiple components
1143 within an ASN.1 value.
1145 The ComponentFilter assertion, an expression of ComponentAssertions,
1146 evaluates to either TRUE, FALSE or undefined for each tested ASN.1
1149 A ComponentFilter is described by the following ASN.1 type (assumed
1150 to be defined with "EXPLICIT TAGS" in force):
1152 ComponentFilter ::= CHOICE {
1153 item [0] ComponentAssertion,
1154 and [1] SEQUENCE OF ComponentFilter,
1155 or [2] SEQUENCE OF ComponentFilter,
1156 not [3] ComponentFilter }
1158 Note: despite the use of SEQUENCE OF instead of SET OF for the "and"
1159 and "or" alternatives in ComponentFilter, the order of the component
1160 filters is not significant.
1162 A ComponentFilter that is a ComponentAssertion evaluates to TRUE if
1163 the ComponentAssertion is TRUE, evaluates to FALSE if the
1164 ComponentAssertion is FALSE, and evaluates to undefined otherwise.
1166 The "and" of a sequence of component filters evaluates to TRUE if the
1167 sequence is empty or if each component filter evaluates to TRUE,
1168 evaluates to FALSE if at least one component filter is FALSE, and
1169 evaluates to undefined otherwise.
1171 The "or" of a sequence of component filters evaluates to FALSE if the
1172 sequence is empty or if each component filter evaluates to FALSE,
1173 evaluates to TRUE if at least one component filter is TRUE, and
1174 evaluates to undefined otherwise.
1178 Legg Expires 2 October 2003 [Page 21]
1180 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
1183 The "not" of a component filter evaluates to TRUE if the component
1184 filter is FALSE, evaluates to FALSE if the component filter is TRUE,
1185 and evaluates to undefined otherwise.
1188 6. The componentFilterMatch Matching Rule
1190 The componentFilterMatch matching rule allows a ComponentFilter to be
1191 applied to an attribute value. The result of the matching rule is
1192 the result of applying the ComponentFilter to the attribute value.
1194 The LDAP-style definitions for componentFilterMatch and its assertion
1197 ( 1.2.36.79672281.1.13.2 NAME 'componentFilterMatch'
1198 SYNTAX 1.2.36.79672281.1.5.2 )
1200 ( 1.2.36.79672281.1.5.2 DESC 'ComponentFilter' )
1202 The LDAP-specific encoding for the ComponentFilter assertion syntax
1203 is specified by the Generic String Encoding Rules in [7].
1205 As a convenience to implementors, an equivalent ABNF description of
1206 the GSER encoding for ComponentFilter is provided here. In the event
1207 that there is a discrepancy between this ABNF and the encoding
1208 determined by [7], [7] is to be taken as definitive. The GSER
1209 encoding of a ComponentFilter is described by the following
1212 ComponentFilter = filter-item /
1217 filter-item = item-chosen ComponentAssertion
1218 and-filter = and-chosen SequenceOfComponentFilter
1219 or-filter = or-chosen SequenceOfComponentFilter
1220 not-filter = not-chosen ComponentFilter
1222 item-chosen = %x69.74.65.6D.3A ; "item:"
1223 and-chosen = %x61.6E.64.3A ; "and:"
1224 or-chosen = %x6F.72.3A ; "or:"
1225 not-chosen = %x6E.6F.74.3A ; "not:"
1227 SequenceOfComponentFilter = "{" [ sp ComponentFilter
1228 *( "," sp ComponentFilter) ] sp "}"
1230 ComponentAssertion = "{" [ sp component "," ]
1234 Legg Expires 2 October 2003 [Page 22]
1236 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
1239 [ sp useDefaultValues "," ]
1241 sp assertion-value sp "}"
1242 component = component-label msp StringValue
1243 useDefaultValues = use-defaults-label msp BooleanValue
1244 rule = rule-label msp ObjectIdentifierValue
1245 assertion-value = value-label msp Value
1247 component-label = %x63.6F.6D.70.6F.6E.65.6E.74 ; "component"
1248 use-defaults-label = %x75.73.65.44.65.66.61.75.6C.74.56.61.6C.75
1249 %x65.73 ; "useDefaultValues"
1250 rule-label = %x72.75.6C.65 ; "rule"
1251 value-label = %x76.61.6C.75.65 ; "value"
1253 sp = *%x20 ; zero, one or more space characters
1254 msp = 1*%x20 ; one or more space characters
1256 The ABNF for <Value>, <StringValue>, <ObjectIdentifierValue> and
1257 <BooleanValue> is defined in [7].
1259 The ABNF descriptions of LDAP-specific encodings for attribute
1260 syntaxes typically do not clearly or consistently delineate the
1261 component parts of an attribute value. A regular and uniform
1262 character string encoding for arbitrary component data types is
1263 needed to encode the assertion value in a ComponentAssertion. The
1264 <Value> rule from [7] provides a human readable text encoding for a
1265 component value of any arbitrary ASN.1 type.
1267 The X.500-style definition [8] for componentFilterMatch is:
1269 componentFilterMatch MATCHING-RULE ::= {
1270 SYNTAX ComponentFilter
1271 ID { 1 2 36 79672281 1 13 2 } }
1273 A ComponentAssertion can potentially use any matching rule, including
1274 componentFilterMatch, so componentFilterMatch MAY be nested. The
1275 component references in a nested componentFilterMatch are relative to
1276 the component corresponding to the containing ComponentAssertion. In
1277 Section 8, an example search on the seeAlso attribute shows this
1281 7. Equality Matching of Complex Components
1283 It is possible to test if an attribute value of a complex ASN.1
1284 syntax is the same as some purported (i.e. assertion) value by using
1285 a complicated ComponentFilter that tests if corresponding components
1286 are the same. However, it would be more convenient to be able to
1290 Legg Expires 2 October 2003 [Page 23]
1292 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
1295 present a whole assertion value to a matching rule that could do the
1296 component-wise comparison of an attribute value with the assertion
1297 value for any arbitrary attribute syntax. Similarly, the ability to
1298 do a straightforward equality comparison of a component value that is
1299 itself of a complex ASN.1 type would also be convenient.
1301 It would be difficult to define a single matching rule that
1302 simultaneously satisfies all notions of what the equality matching
1303 semantics should be. For example, in some instances a case sensitive
1304 comparison of string components may be preferable to a case
1305 insensitive comparison. Therefore a basic equality matching rule,
1306 allComponentsMatch, is defined in Section 7.2, and the means to
1307 derive new matching rules from it with slightly different equality
1308 matching semantics are described in Section 7.3.
1310 The directoryComponentsMatch defined in Section 7.4 is a derivation
1311 of allComponentsMatch that suits typical uses of the directory.
1312 Other specifications are free to derive new rules from
1313 allComponentsMatch or directoryComponentsMatch, that suit their usage
1316 The allComponentsMatch rule, the directoryComponentsMatch rule and
1317 any matching rules derived from them are collectively called
1318 component equality matching rules.
1321 7.1 The OpenAssertionType Syntax
1323 The component equality matching rules have a variable assertion
1324 syntax. In X.500 this is indicated by omitting the optional SYNTAX
1325 field in the MATCHING-RULE information object. The assertion syntax
1326 then defaults to the target attribute's syntax in actual usage,
1327 unless the description of the matching rule says otherwise. The
1328 SYNTAX field in the LDAP-specific encoding of a
1329 MatchingRuleDescription is mandatory, so the OpenAssertionType syntax
1330 is defined to fill the same role. That is, the OpenAssertionType
1331 syntax is semantically equivalent to an omitted SYNTAX field in an
1332 X.500 MATCHING-RULE information object. OpenAssertionType MUST NOT
1333 be used as the attribute syntax in an attribute type definition.
1335 Unless explicitly varied by the description of a particular matching
1336 rule, if an OpenAssertionType assertion value appears in a
1337 ComponentAssertion its LDAP-specific encoding is described by the
1338 <Value> rule in [7], otherwise its LDAP-specific encoding is the
1339 encoding defined for the syntax of the attribute type to which the
1340 matching rule with the OpenAssertionType assertion syntax is applied.
1342 The LDAP definition for the OpenAssertionType syntax is:
1346 Legg Expires 2 October 2003 [Page 24]
1348 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
1351 ( 1.2.36.79672281.1.5.3 DESC 'OpenAssertionType' )
1354 7.2 The allComponentsMatch Matching Rule
1356 The LDAP-style definition for allComponentsMatch is:
1358 ( 1.2.36.79672281.1.13.6 NAME 'allComponentsMatch'
1359 SYNTAX 1.2.36.79672281.1.5.3 )
1361 The X.500-style definition for allComponentsMatch is:
1363 allComponentsMatch MATCHING-RULE ::= {
1364 ID { 1 2 36 79672281 1 13 6 } }
1366 When allComponentsMatch is used in a ComponentAssertion the assertion
1367 syntax is the same as the ASN.1 type of the identified component.
1368 Otherwise, the assertion syntax of allComponentsMatch is the same as
1369 the attribute syntax of the attribute to which the matching rule is
1372 Broadly speaking, this matching rule evaluates to true if and only if
1373 corresponding components of the assertion value and the attribute or
1374 component value are the same.
1376 In detail, equality is determined by the following cases applied
1379 a) Two values of a SET or SEQUENCE type are the same if and only if,
1380 for each component type, the corresponding component values are
1385 2) both present and the same, or
1387 3) absent or the same as the DEFAULT value for the component, if a
1388 DEFAULT value is defined.
1390 Values of an EMBEDDED PDV, EXTERNAL, unrestricted CHARACTER
1391 STRING, or INSTANCE OF type are compared according to their
1392 respective associated SEQUENCE type (see Section 4.1.2).
1394 b) Two values of a SEQUENCE OF type are the same if and only if, the
1395 values have the same number of (possibly duplicated) instances and
1396 corresponding instances are the same.
1398 c) Two values of a SET OF type are the same if and only if, the
1402 Legg Expires 2 October 2003 [Page 25]
1404 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
1407 values have the same number of instances and each distinct
1408 instance occurs in both values the same number of times, i.e. both
1409 values have the same instances, including duplicates, but in any
1412 d) Two values of a CHOICE type are the same if and only if, both
1413 values are of the same chosen alternative and the component values
1416 e) Two BIT STRING values are the same if and only if the values have
1417 the same number of bits and corresponding bits are the same. If
1418 the BIT STRING type is defined with a named bit list then trailing
1419 zero bits in the values are treated as absent for the purposes of
1422 f) Two BOOLEAN values are the same if and only if both are TRUE or
1425 g) Two values of a string type are the same if and only if the values
1426 have the same number of characters and corresponding characters
1427 are the same. Letter case is significant. For the purposes of
1428 allComponentsMatch, the string types are NumericString,
1429 PrintableString, TeletexString (T61String), VideotexString,
1430 IA5String, GraphicString, VisibleString (ISO646String),
1431 GeneralString, UniversalString, BMPString, UTF8String,
1432 GeneralizedTime, UTCTime and ObjectDescriptor.
1434 h) Two INTEGER values are the same if and only if the integers are
1437 i) Two ENUMERATED values are the same if and only if the enumeration
1438 item identifiers are the same (equivalently, if the integer values
1439 associated with the identifiers are equal).
1441 j) Two NULL values are always the same, unconditionally.
1443 k) Two OBJECT IDENTIFIER values are the same if and only if the
1444 values have the same number of arcs and corresponding arcs are the
1447 l) Two OCTET STRING values are the same if and only if the values
1448 have the same number of octets and corresponding octets are the
1451 m) Two REAL values are the same if and only if they are both the same
1452 special value, or neither is a special value and they have the
1453 same base and represent the same real number. The special values
1454 for REAL are zero, PLUS-INFINITY and MINUS-INFINITY.
1458 Legg Expires 2 October 2003 [Page 26]
1460 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
1463 n) Two RELATIVE-OID [12] values are the same if and only if the
1464 values have the same number of arcs and corresponding arcs are the
1465 same. The respective starting nodes for the RELATIVE-OID values
1466 are disregarded in the comparison, i.e. they are assumed to be the
1469 o) Two values of an open type are the same if and only if both are of
1470 the same ASN.1 type and are the same according to that type. If
1471 the actual ASN.1 type of the values is unknown then the
1472 allComponentsMatch rule evaluates to undefined.
1474 Tags and constraints, being part of the type definition and not part
1475 of the abstract values, are ignored for matching purposes.
1477 The allComponentsMatch rule MAY be used as the defined equality
1478 matching rule for an attribute.
1481 7.3 Deriving Component Equality Matching Rules
1483 A new component equality matching rule with more refined matching
1484 semantics may be derived from allComponentsMatch, or any other
1485 component equality matching rule, using the convention described in
1488 The matching behaviour of a derived component equality matching rule
1489 is specified by nominating, for each of one or more identified
1490 components, a commutative equality matching rule that will be used to
1491 match values of that component. This overrides the matching that
1492 would otherwise occur for values of that component using the base
1493 rule for the derivation. These overrides can be conveniently
1494 represented as rows in a table of the following form.
1496 Component | Matching Rule
1497 ============+===============
1501 Usually, all component values of a particular ASN.1 type are to be
1502 matched the same way. An ASN.1 type reference (e.g.
1503 DistinguishedName) or an ASN.1 built-in type name (e.g. INTEGER) in
1504 the Component column of the table specifies that the nominated
1505 equality matching rule is to be applied to all values of the named
1506 type, regardless of context.
1508 An ASN.1 type reference with a component reference appended
1509 (separated by a ".") specifies that the nominated matching rule
1510 applies only to the identified components of values of the named
1514 Legg Expires 2 October 2003 [Page 27]
1516 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
1519 type. Other component values that happen to be of the same ASN.1
1520 type are not selected.
1522 Additional type substitutions as described in Section 4.2 are assumed
1523 to be performed to align the component type with the matching rule
1526 Conceptually, the rows in a table for the base rule are appended to
1527 the rows in the table for a derived rule for the purpose of deciding
1528 the matching semantics of the derived rule. Notionally,
1529 allComponentsMatch has an empty table.
1531 A row specifying values of an outer containing type (e.g.
1532 DistinguishedName) takes precedence over a row specifying values of
1533 an inner component type (e.g. RelativeDistinguishedName), regardless
1534 of their order in the table. Specifying a row for component values
1535 of an inner type is only useful if a value of the type can also
1536 appear on its own, or as a component of values of a different outer
1537 type. For example, if there is a row for DistinguishedName then a
1538 row for RelativeDistinguishedName can only ever apply to
1539 RelativeDistinguishedName component values that are not part of a
1540 DistinguishedName. A row for values of an outer type in the table
1541 for the base rule takes precedence over a row for values of an inner
1542 type in the table for the derived rule.
1544 Where more than one row applies to a particular component value the
1545 earlier row takes precedence over the later row. Thus rows in the
1546 table for the derived rule take precedence over any rows for the same
1547 component in the table for the base rule.
1550 7.4 The directoryComponentsMatch Matching Rule
1552 The directoryComponentsMatch matching rule is derived from the
1553 allComponentsMatch matching rule.
1555 The LDAP-style definition for directoryComponentsMatch is:
1557 ( 1.2.36.79672281.1.13.7 NAME 'directoryComponentsMatch'
1558 SYNTAX 1.2.36.79672281.1.5.3 )
1560 The X.500-style definition for directoryComponentsMatch is:
1562 directoryComponentsMatch MATCHING-RULE ::= {
1563 ID { 1 2 36 79672281 1 13 7 } }
1565 The matching semantics of directoryComponentsMatch are described by
1566 the following table, using the convention described in Section 7.3.
1570 Legg Expires 2 October 2003 [Page 28]
1572 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
1575 ASN.1 Type | Matching Rule
1576 =========================================+========================
1577 RDNSequence | distinguishedNameMatch
1578 RelativeDistinguishedName | rdnMatch
1579 TelephoneNumber | telephoneNumberMatch
1580 FacsimileTelephoneNumber.telephoneNumber | telephoneNumberMatch
1581 NumericString | numericStringMatch
1582 GeneralizedTime | generalizedTimeMatch
1583 UTCTime | uTCTimeMatch
1584 DirectoryString{} | caseIgnoreMatch
1585 BMPString | caseIgnoreMatch
1586 GeneralString | caseIgnoreMatch
1587 GraphicString | caseIgnoreMatch
1588 IA5String | caseIgnoreMatch
1589 PrintableString | caseIgnoreMatch
1590 TeletexString | caseIgnoreMatch
1591 UniversalString | caseIgnoreMatch
1592 UTF8String | caseIgnoreMatch
1593 VideotexString | caseIgnoreMatch
1594 VisibleString | caseIgnoreMatch
1598 1) The DistinguishedName type is defined by assignment to be the same
1599 as the RDNSequence type. Some types (e.g. Name and LocalName)
1600 directly reference RDNSequence rather than DistinguishedName.
1601 Specifying RDNSequence captures all these DN-like types.
1603 2) A RelativeDistinguishedName value is only matched by rdnMatch if
1604 it is not part of an RDNSequence value.
1606 3) The telephone number component of the FacsimileTelephoneNumber
1607 ASN.1 type [10] is defined as a constrained PrintableString.
1608 PrintableString component values that are part of a
1609 FacsimileTelephoneNumber value can be identified separately from
1610 other components of PrintableString type by the specifier
1611 FacsimileTelephoneNumber.telephoneNumber, so that
1612 telephoneNumberMatch can be selectively applied. The fourth
1613 edition of X.520 defines the telephoneNumber component of
1614 FacsimileTelephoneNumber to be of the type TelephoneNumber, making
1615 the row for FacsimileTelephoneNumber.telephoneNumber components
1618 The directoryComponentsMatch rule MAY be used as the defined equality
1619 matching rule for an attribute.
1622 8. Component Matching Examples
1626 Legg Expires 2 October 2003 [Page 29]
1628 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
1631 This section contains examples of search filters using the
1632 componentFilterMatch matching rule. The filters are described using
1633 the string representation of LDAP search filters from [17]. Note
1634 that [17] requires asterisks to be escaped in assertion values (in
1635 these examples the assertion values are all <ComponentAssertion>
1636 encodings). The asterisks have not been escaped in these examples
1637 for the sake of clarity, and to avoid confusing the LDAP protocol
1638 representation of search filter assertion values, where such escaping
1639 does not apply. Line breaks and indenting have been added only as an
1642 The example search filters are all single extensible match filter
1643 items, though there is no reason why componentFilterMatch can't be
1644 used in more complicated search filters.
1646 The first examples describe searches over the objectClasses schema
1647 operational attribute, which has an attribute syntax described by the
1648 ASN.1 type ObjectClassDescription [8], and holds the definitions of
1649 the object classes known to a directory server. The definition of
1650 ObjectClassDescription is as follows:
1652 ObjectClassDescription ::= SEQUENCE {
1653 identifier OBJECT-CLASS.&id,
1654 name SET OF DirectoryString {ub-schema} OPTIONAL,
1655 description DirectoryString {ub-schema} OPTIONAL,
1656 obsolete BOOLEAN DEFAULT FALSE,
1657 information [0] ObjectClassInformation }
1659 ObjectClassInformation ::= SEQUENCE {
1660 subclassOf SET OF OBJECT-CLASS.&id OPTIONAL,
1661 kind ObjectClassKind DEFAULT structural,
1662 mandatories [3] SET OF ATTRIBUTE.&id OPTIONAL,
1663 optionals [4] SET OF ATTRIBUTE.&id OPTIONAL }
1665 ObjectClassKind ::= ENUMERATED {
1670 OBJECT-CLASS.&id and ATTRIBUTE.&id are equivalent to the OBJECT
1671 IDENTIFIER ASN.1 type. A value of OBJECT-CLASS.&id is an OBJECT
1672 IDENTIFIER for an object class. A value of ATTRIBUTE.&id is an
1673 OBJECT IDENTIFIER for an attribute type.
1675 The following search filter finds the object class definition for the
1676 object class identified by the OBJECT IDENTIFIER 2.5.6.18:
1678 (objectClasses:componentFilterMatch:=
1682 Legg Expires 2 October 2003 [Page 30]
1684 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
1687 item:{ component "identifier",
1688 rule objectIdentifierMatch, value 2.5.6.18 })
1690 A match on the "identifier" component of objectClasses values is
1691 equivalent to the objectIdentifierFirstComponentMatch matching rule
1692 applied to attribute values of the objectClasses attribute type. The
1693 componentFilterMatch matching rule subsumes the functionality of the
1694 objectIdentifierFirstComponentMatch, integerFirstComponentMatch and
1695 directoryStringFirstComponentMatch matching rules.
1697 The following search filter finds the object class definition for the
1698 object class called foobar:
1700 (objectClasses:componentFilterMatch:=
1701 item:{ component "name.*",
1702 rule caseIgnoreMatch, value "foobar" })
1704 An object class definition can have multiple names and the above
1705 filter will match an objectClasses value if any one of the names is
1708 The component reference "name.0" identifies the notional count of the
1709 number of names in an object class definition. The following search
1710 filter finds object class definitions with exactly one name:
1712 (objectClasses:componentFilterMatch:=
1713 item:{ component "name.0", rule integerMatch, value 1 })
1715 The "description" component of an ObjectClassDescription is defined
1716 to be an OPTIONAL DirectoryString. The following search filter finds
1717 object class definitions that have descriptions, regardless of the
1718 contents of the description string:
1720 (objectClasses:componentFilterMatch:=
1721 item:{ component "description",
1722 rule presentMatch, value NULL })
1724 The presentMatch returns TRUE if the description component is present
1725 and FALSE otherwise.
1727 The following search filter finds object class definitions that don't
1730 (objectClasses:componentFilterMatch:=
1731 not:item:{ component "description",
1732 rule presentMatch, value NULL })
1734 The following search filter finds object class definitions with the
1738 Legg Expires 2 October 2003 [Page 31]
1740 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
1743 word "bogus" in the description:
1745 (objectClasses:componentFilterMatch:=
1746 item:{ component "description",
1747 rule caseIgnoreSubstringsMatch,
1748 value { any:"bogus" } })
1750 The assertion value is of the SubstringAssertion syntax, i.e.
1752 SubstringAssertion ::= SEQUENCE OF CHOICE {
1753 initial [0] DirectoryString {ub-match},
1754 any [1] DirectoryString {ub-match},
1755 final [2] DirectoryString {ub-match} }
1757 The "obsolete" component of an ObjectClassDescription is defined to
1758 be DEFAULT FALSE. An object class is obsolete if the "obsolete"
1759 component is present and set to TRUE. The following search filter
1760 finds all obsolete object classes:
1762 (objectClasses:componentFilterMatch:=
1763 item:{ component "obsolete", rule booleanMatch, value TRUE })
1765 An object class is not obsolete if the "obsolete" component is not
1766 present, in which case it defaults to FALSE, or is present but is
1767 explicitly set to FALSE. The following search filter finds all non-
1768 obsolete object classes:
1770 (objectClasses:componentFilterMatch:=
1771 item:{ component "obsolete", rule booleanMatch, value FALSE })
1773 The useDefaultValues flag in the ComponentAssertion defaults to TRUE
1774 so the componentFilterMatch rule treats an absent "obsolete"
1775 component as being present and set to FALSE. The following search
1776 filter finds only object class definitions where the "obsolete"
1777 component has been explicitly set to FALSE, rather than implicitly
1778 defaulting to FALSE:
1780 (objectClasses:componentFilterMatch:=
1781 item:{ component "obsolete", useDefaultValues FALSE,
1782 rule booleanMatch, value FALSE })
1784 With the useDefaultValues flag set to FALSE, if the "obsolete"
1785 component is absent the component reference identifies no component
1786 value and the matching rule will return FALSE. The matching rule can
1787 only return TRUE if the component is present and set to FALSE.
1789 The "information.kind" component of the ObjectClassDescription is an
1790 ENUMERATED type. The allComponentsMatch matching rule can be used to
1794 Legg Expires 2 October 2003 [Page 32]
1796 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
1799 match values of an ENUMERATED type. The following search filter
1800 finds object class definitions for auxiliary object classes:
1802 (objectClasses:componentFilterMatch:=
1803 item:{ component "information.kind",
1804 rule allComponentsMatch, value auxiliary })
1806 The following search filter finds auxiliary object classes with
1807 commonName (cn or 2.5.4.3) as a mandatory attribute:
1809 (objectClasses:componentFilterMatch:=and:{
1810 item:{ component "information.kind",
1811 rule allComponentsMatch, value auxiliary },
1812 item:{ component "information.mandatories.*",
1813 rule objectIdentifierMatch, value cn } })
1815 The following search filter finds auxiliary object classes with
1816 commonName as a mandatory or optional attribute:
1818 (objectClasses:componentFilterMatch:=and:{
1819 item:{ component "information.kind",
1820 rule allComponentsMatch, value auxiliary },
1822 item:{ component "information.mandatories.*",
1823 rule objectIdentifierMatch, value cn },
1824 item:{ component "information.optionals.*",
1825 rule objectIdentifierMatch, value cn } } })
1827 Extra care is required when matching optional SEQUENCE OF or SET OF
1828 components because of the distinction between an absent list of
1829 instances and a present, but empty, list of instances. The following
1830 search filter finds object class definitions with less than three
1831 names, including object class definitions with a present but empty
1832 list of names, but does not find object class definitions with an
1833 absent list of names:
1835 (objectClasses:componentFilterMatch:=
1836 item:{ component "name.0",
1837 rule integerOrderingMatch, value 3 })
1839 If the "name" component is absent the "name.0" component is also
1840 considered to be absent and the ComponentAssertion evaluates to
1841 FALSE. If the "name" component is present, but empty, the "name.0"
1842 component is also present and equal to zero, so the
1843 ComponentAssertion evaluates to TRUE. To also find the object class
1844 definitions with an absent list of names the following search filter
1850 Legg Expires 2 October 2003 [Page 33]
1852 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
1855 (objectClasses:componentFilterMatch:=or:{
1856 not:item:{ component "name", rule presentMatch, value NULL },
1857 item:{ component "name.0",
1858 rule integerOrderingMatch, value 3 } })
1860 Distinguished names embedded in other syntaxes can be matched with a
1861 componentFilterMatch. The uniqueMember attribute type has an
1862 attribute syntax described by the ASN.1 type NameAndOptionalUID.
1864 NameAndOptionalUID ::= SEQUENCE {
1865 dn DistinguishedName,
1866 uid UniqueIdentifier OPTIONAL }
1868 The following search filter finds values of the uniqueMember
1869 attribute containing the author's DN:
1871 (uniqueMember:componentFilterMatch:=
1872 item:{ component "dn",
1873 rule distinguishedNameMatch,
1874 value "cn=Steven Legg,o=Adacel,c=AU" })
1876 The DistinguishedName and RelativeDistinguishedName ASN.1 types are
1877 also complex ASN.1 types so the component matching rules can be
1878 applied to their inner components.
1880 DistinguishedName ::= RDNSequence
1882 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
1884 RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
1885 AttributeTypeAndValue
1887 AttributeTypeAndValue ::= SEQUENCE {
1888 type AttributeType ({SupportedAttributes}),
1889 value AttributeValue ({SupportedAttributes}{@type}) }
1891 AttributeType ::= ATTRIBUTE.&id
1893 AttributeValue ::= ATTRIBUTE.&Type
1895 ATTRIBUTE.&Type is an open type. A value of ATTRIBUTE.&Type is
1896 constrained by the type component of AttributeTypeAndValue to be of
1897 the attribute syntax of the nominated attribute type. Note: the
1898 fourth edition of X.500 extends and renames the AttributeTypeAndValue
1901 The seeAlso attribute has the DistinguishedName syntax. The
1902 following search filter finds seeAlso attribute values containing the
1906 Legg Expires 2 October 2003 [Page 34]
1908 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
1911 RDN, "o=Adacel", anywhere in the DN:
1913 (seeAlso:componentFilterMatch:=
1914 item:{ component "*", rule rdnMatch, value "o=Adacel" })
1916 The following search filter finds all seeAlso attribute values with
1917 "cn=Steven Legg" as the RDN of the named entry (i.e. the "first" RDN
1918 in an LDAPDN or the "last" RDN in an X.500 DN):
1920 (seeAlso:componentFilterMatch:=
1921 item:{ component "-1",
1922 rule rdnMatch, value "cn=Steven Legg" })
1924 The following search filter finds all seeAlso attribute values naming
1925 entries in the DIT subtree of "o=Adacel,c=AU":
1927 (seeAlso:componentFilterMatch:=and:{
1928 item:{ component "1", rule rdnMatch, value "c=AU" },
1929 item:{ component "2", rule rdnMatch, value "o=Adacel" } })
1931 The following search filter finds all seeAlso attribute values
1932 containing the naming attribute types commonName (cn) and
1933 telephoneNumber in the same RDN:
1935 (seeAlso:componentFilterMatch:=
1936 item:{ component "*", rule componentFilterMatch,
1938 item:{ component "*.type",
1939 rule objectIdentifierMatch, value cn },
1940 item:{ component "*.type",
1941 rule objectIdentifierMatch,
1942 value telephoneNumber } } })
1944 The following search filter would find all seeAlso attribute values
1945 containing the attribute types commonName and telephoneNumber, but
1946 not necessarily in the same RDN:
1948 (seeAlso:componentFilterMatch:=and:{
1949 item:{ component "*.*.type",
1950 rule objectIdentifierMatch, value cn },
1951 item:{ component "*.*.type",
1952 rule objectIdentifierMatch, value telephoneNumber } })
1954 The following search filter finds all seeAlso attribute values
1955 containing the word "Adacel" in any organizationalUnitName (ou)
1956 attribute value in any AttributeTypeAndValue of any RDN:
1958 (seeAlso:componentFilterMatch:=
1962 Legg Expires 2 October 2003 [Page 35]
1964 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
1967 item:{ component "*.*.value.(2.5.4.11)",
1968 rule caseIgnoreSubstringsMatch,
1969 value { any:"Adacel" } })
1971 The component reference "*.*.value" identifies an open type, in this
1972 case an attribute value. In a particular AttributeTypeAndValue, if
1973 the attribute type is not organizationalUnitName then the
1974 ComponentAssertion evaluates to FALSE. Otherwise the substring
1975 assertion is evaluated against the attribute value.
1977 Absent component references in ComponentAssertions can be exploited
1978 to avoid false positive matches on multi-valued attributes. For
1979 example, suppose there is a multi-valued attribute named
1980 productCodes, defined to have the Integer syntax
1981 (1.3.6.1.4.1.1466.115.121.1.27). Consider the following search
1984 (&(!(productCodes:integerOrderingMatch:=3))
1985 (productCodes:integerOrderingMatch:=8))
1987 An entry whose productCodes attribute contains only the values 1 and
1988 10 will match the above filter. The first subfilter is satisfied by
1989 the value 10 (10 is not less than 3), and the second subfilter is
1990 satisfied by the value 1 (1 is less than 8). The following search
1991 filter can be used instead to only match entries that have a
1992 productCodes value in the range 3 to 7, because the ComponentFilter
1993 is evaluated against each productCodes value in isolation:
1995 (productCodes:componentFilterMatch:= and:{
1996 not:item:{ rule integerOrderingMatch, value 3 },
1997 item:{ rule integerOrderingMatch, value 8 } })
1999 An entry whose productCodes attribute contains only the values 1 and
2000 10 will not match the above filter.
2003 9. Security Considerations
2005 The component matching rules described in this document allow for a
2006 compact specification of matching capabilities that could otherwise
2007 have been defined by a plethora of specific matching rules, i.e.
2008 despite their expressiveness and flexibility the component matching
2009 rules do not behave in a way uncharacteristic of other matching
2010 rules, so the security issues for component matching rules are no
2011 different than for any other matching rule. However, because the
2012 component matching rules are applicable to any attribute syntax,
2013 support for them in a directory server may allow searching of
2014 attributes that were previously unsearchable by virtue of there not
2018 Legg Expires 2 October 2003 [Page 36]
2020 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
2023 being a suitable matching rule. Such attribute types ought to be
2024 properly protected with appropriate access controls.
2027 10. Acknowledgements
2029 The author would like to thank Tom Gindin for private email
2030 discussions that clarified and refined the ideas presented in this
2034 11. Normative References
2036 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
2037 Levels", BCP 14, RFC 2119, March 1997.
2039 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax
2040 Specifications: ABNF", RFC 2234, November 1997.
2042 [3] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
2043 Protocol (v3)", RFC 2251, December 1997.
2045 [4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
2046 Directory Access Protocol (v3): Attribute Syntax Definitions",
2047 RFC 2252, December 1997.
2049 [5] Wahl, M., Kille S. and T. Howes. "Lightweight Directory Access
2050 Protocol (v3): UTF-8 String Representation of Distinguished
2051 Names", RFC 2253, December 1997.
2053 [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2056 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
2057 Protocol (v3): Technical Specification", RFC 3377, September
2060 [7] Legg, S., "Generic String Encoding Rules for ASN.1 Types",
2061 draft-legg-ldap-gser-xx.txt, a work in progress, October 2002.
2063 [8] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
2064 Information Technology - Open Systems Interconnection - The
2067 [9] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1998,
2068 Information Technology - Open Systems Interconnection - The
2069 Directory: Authentication Framework
2074 Legg Expires 2 October 2003 [Page 37]
2076 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
2079 [10] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
2080 Information Technology - Open Systems Interconnection - The
2081 Directory: Selected attribute types
2083 [11] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998
2084 Information Technology - Abstract Syntax Notation One (ASN.1):
2085 Specification of basic notation
2087 [12] ITU-T Recommendation X.680 - Amendment 1 (06/99) | ISO/IEC
2088 8824-1:1998/Amd 1:2000 Relative object identifiers
2090 [13] ITU-T Recommendation X.681 (1997) | ISO/IEC 8824-2:1998
2091 Information Technology - Abstract Syntax Notation One (ASN.1):
2092 Information object specification
2094 [14] ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998
2095 Information Technology - Abstract Syntax Notation One (ASN.1):
2096 Constraint specification
2098 [15] ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998
2099 Information Technology - Abstract Syntax Notation One (ASN.1):
2100 Parameterization of ASN.1 specifications
2102 [16] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998
2103 Information Technology - ASN.1 encoding rules: Specification of
2104 Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
2105 Distinguished Encoding Rules (DER)
2108 12. Informative References
2110 [17] Howes, T., "The String Representation of LDAP Search Filters",
2111 RFC 2254, December 1997.
2113 [18] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
2114 Information Technology - Open Systems Interconnection - The
2115 Directory: Overview of concepts, models and services
2118 13. Copyright Notice
2120 Copyright (C) The Internet Society (2003). All Rights Reserved.
2122 This document and translations of it may be copied and furnished to
2123 others, and derivative works that comment on or otherwise explain it
2124 or assist in its implementation may be prepared, copied, published
2125 and distributed, in whole or in part, without restriction of any
2126 kind, provided that the above copyright notice and this paragraph are
2130 Legg Expires 2 October 2003 [Page 38]
2132 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
2135 included on all such copies and derivative works. However, this
2136 document itself may not be modified in any way, such as by removing
2137 the copyright notice or references to the Internet Society or other
2138 Internet organizations, except as needed for the purpose of
2139 developing Internet standards in which case the procedures for
2140 copyrights defined in the Internet Standards process must be
2141 followed, or as required to translate it into languages other than
2144 The limited permissions granted above are perpetual and will not be
2145 revoked by the Internet Society or its successors or assigns.
2147 This document and the information contained herein is provided on an
2148 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2149 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2150 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2151 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2152 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2155 14. Author's Address
2158 Adacel Technologies Ltd.
2160 Brighton, Victoria 3186
2163 Phone: +61 3 8530 7710
2164 Fax: +61 3 8530 7888
2165 EMail: steven.legg@adacel.com.au
2168 Appendix A - Changes From Previous Drafts
2170 A.1 Changes in Draft 01
2172 Section 4.1.7 was added to enable component matching of values
2173 embedded in encoded form into BIT STRINGs or OCTET STRINGs. In
2174 particular, this is to allow component matching of values in
2175 Certificate extensions. The <content> rule was added in Section 4.1
2176 to allow the OCTET STRING contents to be treated as either raw octets
2177 or as an embedded value.
2179 References to a companion document summarizing the ASN.1 types of
2180 LDAP syntaxes were removed to avoid holding up this document.
2182 The OpenType syntax was renamed to OpenAssertionType.
2186 Legg Expires 2 October 2003 [Page 39]
2188 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
2191 Object identifiers for the new syntax and matching rule definitions
2192 have been allocated from an arc belonging to Adacel Technologies Ltd.
2194 A.2 Changes in Draft 02
2196 The context specific tagging in the ComponentAssertion ASN.1 type was
2197 unnecessary and has been removed.
2199 The encoding of OpenAssertionType assertion values outside of
2200 ComponentAssertions has been clarified, and the description of
2201 OpenAssertionType has been promoted to its own section.
2203 A.3 Changes in Draft 03
2205 The default matching by allComponentsMatch of component values of BIT
2206 STRING types with named bit lists has been changed to ignore trailing
2209 Typographical errors in the <SafeUTF8Character> rule have been fixed.
2211 A.4 Changes in Draft 04
2213 When the matching rule in a ComponentAssertion has a variable
2214 assertion syntax it is not possible to determine the syntax of the
2215 value component from the ComponentAssertion alone when the associated
2216 component reference has referenced through an open type. Deducing
2217 what that syntax should be from inspection of the other
2218 ComponentAssertions in a ComponentFilter is difficult to implement in
2219 any comprehensive way. The <select> form of ComponentId has been
2220 introduced so that the syntax can always be determined from the
2221 contents of the ComponentAssertion alone. This not only simplifies
2222 implementation but can lead to simpler ComponentFilters since there
2223 is no longer a requirement to test that the components constraining
2224 an open type have particular values. The open type referencing
2225 example has been changed accordingly. The contained type referencing
2226 example has also been changed because it is an example of a contained
2229 The presentationAddressMatch rule is not commutative so it has been
2230 removed from the table defining directoryComponentsMatch. The default
2231 behaviour of allComponentsMatch is already a suitable commutative
2232 substitute for matching PresentationAddress values.
2234 The null character has been included in the range of legal characters
2235 for <SafeUTF8Character>.
2237 The ASN.1 type of the notional iteration count associated with SET OF
2238 and SEQUENCE OF values has been refined to INTEGER (0..MAX).
2242 Legg Expires 2 October 2003 [Page 40]
2244 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
2247 The encoding rules in Section 8 (now draft-legg-ldap-gser-xx.txt)
2248 have been formally named the Generic String Encoding Rules (GSER) and
2249 a transfer syntax object identifier has been assigned.
2251 The term "LDAP string encoding" has been replaced by the term "native
2252 LDAP-specific encoding" to align with terminology anticipated to be
2253 used in the revision of RFC 2252.
2255 A.5 Changes in Draft 05
2257 Reformatted the draft to conform to recent and proposed RFC editorial
2260 The use of the <oid> rule from RFC 2252 has been replaced by a local
2261 definition to specifically outlaw leading zero characters in OBJECT
2262 IDENTIFIER components.
2264 Provisions for the RELATIVE-OID ASN.1 type defined in Amendment 1 to
2265 X.680 have been added.
2267 The comparison of REAL values has been clarified and the GSER
2268 encoding of REAL values has been extended.
2270 Removed extraneous spaces from example DNs.
2272 A.6 Changes in Draft 06
2274 An ABNF syntax error in the <exponent> rule was fixed.
2276 A.7 Changes in Draft 07
2278 The term "native LDAP encoding" has been replaced by the term "LDAP-
2279 specific encoding" to align with terminology anticipated to be used
2280 in the revision of RFC 2252.
2282 Section 8 has been extracted to become a separate Internet draft,
2283 draft-legg-ldap-gser-00.txt. The specifications for ChoiceOfStrings
2284 types have also been moved to this new Internet draft. Various
2285 editorial changes have been made to this draft to accommodate this
2288 A.8 Changes in Draft 08
2290 The enumeratedMatch matching rule duplicates a subset of the
2291 functionality of allComponentsMatch so it has been removed. The
2292 enumeratedMatch rule has been replaced by allComponentsMatch in the
2293 examples. The description of the OpenAssertionType syntax has been
2294 moved into Section 7.
2298 Legg Expires 2 October 2003 [Page 41]
2300 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
2303 A.9 Changes in Draft 09
2305 The associated type for the EXTERNAL type has been changed from the
2306 one defined in X.680 for ASN.1 value notation to the one defined in
2309 A.10 Changes in Draft 10
2311 The definition of ComponentAssertion has been changed to make the
2312 "component" field optional, and non-empty when present. This change
2313 allows the specification of search filters where all the assertions
2314 must match the same value of an attribute. Normally each assertion is
2315 free to match any of the values of a multi-valued attribute.
2316 Corresponding changes have been made to the ABNF in Section 6. An
2317 illustrative example has been added to Section 8.
2319 Conditions on whether a ComponentAssertion returns FALSE or undefined
2320 when some part of the component references identifies an open type
2321 have been removed from Section 4.2. The changes in draft 04 that
2322 introduced the <select> form of ComponentId made these conditions
2323 unnecessary and inappropriate.
2354 Legg Expires 2 October 2003 [Page 42]
projects / openldap / blob