8 draft-legg-ldapext-component-matching-08.txt Adacel Technologies
9 Intended Category: Standard Track April 19, 2002
12 LDAP & X.500 Component Matching Rules
14 Copyright (C) The Internet Society (2002). 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 19 October 2002.
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 19 October 2002 [Page 1]
60 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
63 complex attribute syntax.
68 1. Abstract ...................................................... 1
69 2. Table of Contents ............................................. 2
70 3. Introduction .................................................. 2
71 4. Conventions ................................................... 4
72 5. ComponentAssertion ............................................ 5
73 5.1 Component Reference ....................................... 5
74 5.1.1 Component Type Substitutions ......................... 7
75 5.1.2 Referencing SET, SEQUENCE and CHOICE Components ...... 8
76 5.1.3 Referencing SET OF and SEQUENCE OF Components ........ 9
77 5.1.4 Referencing Components of Parameterized Types ........ 10
78 5.1.5 Component Referencing Example ........................ 10
79 5.1.6 Referencing Components of Open Types ................. 11
80 5.1.6.1 Open Type Referencing Example ................... 12
81 5.1.7 Referencing Contained Types .......................... 13
82 5.1.7.1 Contained Type Referencing Example .............. 14
83 5.2 Matching of Components .................................... 15
84 5.2.1 Applicability of Existing Matching Rules ............. 16
85 5.2.1.1 String Matching ................................. 16
86 5.2.1.2 Telephone Number Matching ....................... 17
87 5.2.1.3 Distinguished Name Matching ..................... 17
88 5.2.2 Additional Useful Matching Rules ..................... 17
89 5.2.2.1 The rdnMatch Matching Rule ...................... 18
90 5.2.2.2 The presentMatch Matching Rule .................. 18
91 5.2.3 Summary of Useful Matching Rules ..................... 19
92 6. ComponentFilter ............................................... 21
93 7. The componentFilterMatch Matching Rule ........................ 22
94 8. Equality Matching of Complex Components ....................... 23
95 8.1 The OpenAssertionType Syntax .............................. 24
96 8.2 The allComponentsMatch Matching Rule ...................... 25
97 8.3 Deriving Component Equality Matching Rules ................ 27
98 8.4 The directoryComponentsMatch Matching Rule ................ 28
99 9. Component Matching Examples ................................... 29
100 10. Security Considerations ...................................... 36
101 11. Acknowledgements ............................................. 36
102 12. Normative References ......................................... 36
103 13. Informative References ....................................... 37
104 14. Intellectual Property Notice ................................. 38
105 15. Copyright Notice ............................................. 38
106 16. Author's Address ............................................. 39
114 Legg Expires 19 October 2002 [Page 2]
116 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
119 The structure or data type of data held in an attribute of an LDAP
120 [3] or X.500 [18] directory is described by the attribute's syntax.
121 Attribute syntaxes range from simple data types, such as text string,
122 integer, or boolean, to complex data types, for example, the syntaxes
123 of the directory schema operational attributes.
125 In X.500, the attribute syntaxes are explicitly described by ASN.1
126 [11] type definitions. ASN.1 type notation has a number of simple
127 data types (e.g. PrintableString, INTEGER, BOOLEAN), and combining
128 types (i.e. SET, SEQUENCE, SET OF, SEQUENCE OF, and CHOICE) for
129 constructing arbitrarily complex data types from simpler component
130 types. In LDAP, the attribute syntaxes are usually described by ABNF
131 [2] though there is an implied association between the LDAP attribute
132 syntaxes and the X.500 ASN.1 types. To a large extent, the data
133 types of attribute values in either an LDAP or X.500 directory are
134 described by ASN.1 types. This formal description can be exploited
135 to identify component parts of an attribute value for a variety of
136 purposes. This document addresses attribute value matching.
138 With any complex attribute syntax there is normally a requirement to
139 partially match an attribute value of that syntax by matching only
140 selected components of the value. Typically, matching rules specific
141 to the attribute syntax are defined to fill this need. These highly
142 specific matching rules usually only provide the most immediately
143 useful matching capability. Some complex attribute syntaxes don't
144 even have an equality matching rule let alone any additional matching
145 rules for partial matching. This document defines a generic way of
146 matching user selected components in an attribute value of any
147 arbitrarily complex attribute syntax, where that syntax is described
148 using ASN.1 type notation. All of the type notations defined in [11]
151 Section 5 describes the ComponentAssertion, a testable assertion
152 about the value of a component of an attribute value of any complex
155 Section 6 introduces the ComponentFilter assertion, which is an
156 expression of ComponentAssertions. The ComponentFilter enables more
157 powerful filter matching of components in an attribute value.
159 Section 7 defines the componentFilterMatch matching rule, which
160 enables a ComponentFilter to be evaluated against attribute values.
162 Section 8 defines matching rules for component-wise equality matching
163 of attribute values of any syntax described by an ASN.1 type
166 Examples showing the usage of componentFilterMatch are in Section 9.
170 Legg Expires 19 October 2002 [Page 3]
172 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
175 For a new attribute syntax, the Generic String Encoding Rules [7] and
176 the specifications in sections 5 to 8 of this document make it
177 possible to fully and precisely define, the LDAP-specific encoding,
178 the LDAP and X.500 binary encoding (and possibly other encodings in
179 the future, e.g. XML via XER), a suitable equality matching rule, and
180 a comprehensive collection of component matching capabilities, by
181 simply writing down an ASN.1 type definition for the syntax. These
182 implicit definitions are also automatically extended if the ASN.1
183 type is later extended. The algorithmic relationship between the
184 ASN.1 type definition, the various encodings and the component
185 matching behaviour makes directory server implementation support for
186 the component matching rules amenable to automatic code generation
187 from ASN.1 type definitions.
189 Schema designers have the choice of storing related items of data as
190 a single attribute value of a complex syntax in some entry, or as a
191 subordinate entry where the related data items are stored as separate
192 attribute values of simpler syntaxes. The inability to search
193 component parts of a complex syntax has been used as an argument for
194 favouring the subordinate entries approach. The component matching
195 rules provide the analogous matching capability on an attribute value
196 of a complex syntax that a search filter has on a subordinate entry.
198 Most LDAP syntaxes have corresponding ASN.1 type definitions, though
199 they are usually not reproduced or referenced alongside the formal
200 definition of the LDAP syntax. Syntaxes defined with only a
201 character string encoding, i.e. without an explicit or implied
202 corresponding ASN.1 type definition, cannot use the component
203 matching capabilities described in this document unless and until a
204 semantically equivalent ASN.1 type definition is defined for them.
209 Throughout this document "type" shall be taken to mean an ASN.1 type
210 unless explicitly qualified as an attribute type, and "value" shall
211 be taken to mean an ASN.1 value unless explicitly qualified as an
214 Note that "ASN.1 value" does not mean a BER [19] encoded value. The
215 ASN.1 value is an abstract concept that is independent of any
216 particular encoding. BER is just one possible encoding of an ASN.1
217 value. The component matching rules operate at the abstract level
218 without regard for the possible encodings of a value.
220 Attribute type and matching rule definitions in this document are
221 provided in both the X.500 [8] and LDAP [4] description formats. Note
222 that the LDAP descriptions have been rendered with additional
226 Legg Expires 19 October 2002 [Page 4]
228 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
231 white-space and line breaks for the sake of readability.
233 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
235 document are to be interpreted as described in RFC 2119 [1].
238 5. ComponentAssertion
240 A ComponentAssertion is an assertion about the presence, or values
241 of, components within an ASN.1 value, i.e. an instance of an ASN.1
242 type. The ASN.1 value is typically an attribute value, where the
243 ASN.1 type is the syntax of the attribute. However a
244 ComponentAssertion may also be applied to a component part of an
245 attribute value. The assertion evaluates to either TRUE, FALSE or
246 undefined for each tested ASN.1 value.
248 A ComponentAssertion is described by the following ASN.1 type
249 (assumed to be defined with "EXPLICIT TAGS" in force):
251 ComponentAssertion ::= SEQUENCE {
252 component ComponentReference,
253 useDefaultValues BOOLEAN DEFAULT TRUE,
254 rule MATCHING-RULE.&id,
255 value MATCHING-RULE.&AssertionType }
257 ComponentReference ::= UTF8String
259 MATCHING-RULE.&id equates to the OBJECT IDENTIFIER of a matching
260 rule. MATCHING-RULE.&AssertionType is an open type (formally known
263 The "component" field of a ComponentAssertion identifies which
264 component part of a value of some ASN.1 type is to be tested, the
265 "useDefaultValues" field indicates whether DEFAULT values are to be
266 substituted for absent component values, the "rule" field indicates
267 how the component is to be tested, and the "value" field is an
268 asserted ASN.1 value against which the component is tested. The
269 ASN.1 type of the asserted value is determined by the chosen rule.
271 The fields of a ComponentAssertion are described in detail in the
275 5.1 Component Reference
277 The component field in a ComponentAssertion is a UTF8 character
278 string [6] whose textual content is a component reference,
282 Legg Expires 19 October 2002 [Page 5]
284 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
287 identifying a component part of some ASN.1 type or value. A
288 component reference conforms to the following ABNF [2], which extends
289 the notation defined in Clause 14 of [11]:
291 component-reference = ComponentId *( "." ComponentId )
292 ComponentId = identifier /
295 from-end / ; extends Clause 14
296 content / ; extends Clause 14
297 select / ; extends Clause 14
300 identifier = lowercase *alphanumeric
301 *(hyphen 1*alphanumeric)
302 alphanumeric = uppercase / lowercase / decimal-digit
303 uppercase = %x41-5A ; "A" to "Z"
304 lowercase = %x61-7A ; "a" to "z"
307 from-beginning = positive-number
309 from-end = "-" positive-number
310 content = %x63.6F.6E.74.65.6E.74 ; "content"
311 select = "(" Value *( "," Value ) ")"
315 positive-number = non-zero-digit *decimal-digit
317 decimal-digit = %x30-39 ; "0" to "9"
318 non-zero-digit = %x31-39 ; "1" to "9"
320 An <identifier> conforms to the definition of an identifier in ASN.1
321 notation (Clause 11.3 of [11]). It begins with a lowercase letter
322 and is followed by zero or more letters, digits, and hyphens. A
323 hyphen is not permitted to be the last character and a hyphen is not
324 permitted to be followed by another hyphen.
326 The <Value> rule is described in [7].
328 A component reference is a sequence of one or more ComponentIds where
329 each successive ComponentId identifies either an inner component at
330 the next level of nesting of an ASN.1 combining type, i.e. SET,
331 SEQUENCE, SET OF, SEQUENCE OF, or CHOICE, or a specific type within
334 A component reference is always considered in the context of a
338 Legg Expires 19 October 2002 [Page 6]
340 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
343 particular complex ASN.1 type. When applied to the ASN.1 type the
344 component reference identifies a specific component type. When
345 applied to a value of the ASN.1 type a component reference identifies
346 zero, one or more component values of that component type. The
347 component values are potentially in a DEFAULT value if
348 useDefaultValues is TRUE. The specific component type identified by
349 the component reference determines what matching rules are capable of
350 being used to match the component values.
352 An empty string for a component reference, which would identify the
353 whole ASN.1 value, is NOT supported since assertions about a whole
354 value are already possible by the direct application of a matching
355 rule to an attribute value.
357 A valid component reference for a particular complex ASN.1 type is
358 constructed by starting with the outermost combining type and
359 repeatedly selecting one of the permissible forms of ComponentId to
360 identify successively deeper nested components. A component
361 reference MAY identify a component with a complex ASN.1 type, i.e. it
362 is NOT required that the component type identified by a component
363 reference be a simple ASN.1 type.
366 5.1.1 Component Type Substitutions
368 ASN.1 type notation has a number of constructs for referencing other
369 defined types, and constructs that are irrelevant for matching
370 purposes. These constructs are not represented in a component
371 reference in any way and substitutions of the component type are
372 performed to eliminate them from further consideration. These
373 substitutions automatically occur prior to each ComponentId, whether
374 constructing or interpreting a component reference, but do not occur
375 after the last ComponentId, except as allowed by Section 5.2.
377 If the ASN.1 type is an ASN.1 type reference then the component type
378 is taken to be the actual definition on the right hand side of the
379 type assignment for the referenced type.
381 If the ASN.1 type is a tagged type then the component type is taken
382 to be the type without the tag.
384 If the ASN.1 type is a constrained type (see [11] and [14] for the
385 details of ASN.1 constraint notation) then the component type is
386 taken to be the type without the constraint.
388 If the ASN.1 type is an ObjectClassFieldType (Clause 14 of [13]) that
389 denotes a specific ASN.1 type (e.g. MATCHING-RULE.&id denotes the
390 OBJECT IDENTIFIER type) then the component type is taken to be the
394 Legg Expires 19 October 2002 [Page 7]
396 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
399 denoted type. Section 5.1.6 describes the case where the
400 ObjectClassFieldType denotes an open type.
402 If the ASN.1 type is a selection type other than one used in the list
403 of components for a SET or SEQUENCE type then the component type is
404 taken to be the selected alternative type from the named CHOICE.
406 If the ASN.1 type is a TypeFromObject (Clause 15 of [13]) then the
407 component type is taken to be the denoted type.
409 If the ASN.1 type is a ValueSetFromObjects (Clause 15 of [13]) then
410 the component type is taken to be the governing type of the denoted
414 5.1.2 Referencing SET, SEQUENCE and CHOICE Components
416 If the ASN.1 type is a SET or SEQUENCE type then the <identifier>
417 form of ComponentId MAY be used to identify the component type within
418 that SET or SEQUENCE having that identifier. If <identifier>
419 references an OPTIONAL component type and that component is not
420 present in a particular value then there are no corresponding
421 component values. If <identifier> references a DEFAULT component
422 type and useDefaultValues is TRUE (the default setting for
423 useDefaultValues) and that component is not present in a particular
424 value then the component value is taken to be the default value. If
425 <identifier> references a DEFAULT component type and useDefaultValues
426 is FALSE and that component is not present in a particular value then
427 there are no corresponding component values.
429 If the ASN.1 type is a CHOICE type then the <identifier> form of
430 ComponentId MAY be used to identify the alternative type within that
431 CHOICE having that identifier. If <identifier> references an
432 alternative other than the one used in a particular value then there
433 are no corresponding component values.
435 The COMPONENTS OF notation in Clause 24 of [11] augments the defined
436 list of components in a SET or SEQUENCE type by including all the
437 components of another defined SET or SEQUENCE type respectively.
438 These included components are referenced directly by identifier as
439 though they were defined in-line in the SET or SEQUENCE type
440 containing the COMPONENTS OF notation.
442 The SelectionType (Clause 29 of [11]), when used in the list of
443 components for a SET or SEQUENCE type, includes a single component
444 from a defined CHOICE type. This included component is referenced
445 directly by identifier as though it was defined in-line in the SET or
450 Legg Expires 19 October 2002 [Page 8]
452 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
455 The REAL type is treated as though it is the SEQUENCE type defined in
458 The EMBEDDED PDV type is treated as though it is the SEQUENCE type
459 defined in Clause 32.5 of [11].
461 The EXTERNAL type is treated as though it is the SEQUENCE type
462 defined in Clause 33.5 of [11].
464 The unrestricted CHARACTER STRING type is treated as though it is the
465 SEQUENCE type defined in Clause 39.5 of [11].
467 The INSTANCE OF type is treated as though it is the SEQUENCE type
468 defined in Annex C of [13].
470 The <identifier> form MUST NOT be used on any other ASN.1 type.
473 5.1.3 Referencing SET OF and SEQUENCE OF Components
475 If the ASN.1 type is a SET OF or SEQUENCE OF type then the
476 <from-beginning>, <from-end>, <count> and <all> forms of ComponentId
479 The <from-beginning> form of ComponentId MAY be used to identify one
480 instance (i.e. value) of the component type of the SET OF or SEQUENCE
481 OF type (e.g. if Foo ::= SET OF Bar, then Bar is the component type),
482 where the instances are numbered from one upwards. If
483 <from-beginning> references a higher numbered instance than the last
484 instance in a particular value of the SET OF or SEQUENCE OF type then
485 there is no corresponding component value.
487 The <from-end> form of ComponentId MAY be used to identify one
488 instance of the component type of the SET OF or SEQUENCE OF type,
489 where "-1" is the last instance, "-2" is the second last instance,
490 and so on. If <from-end> references a lower numbered instance than
491 the first instance in a particular value of the SET OF or SEQUENCE OF
492 type then there is no corresponding component value.
494 The <count> form of ComponentId identifies a notional count of the
495 number of instances of the component type in a value of the SET OF or
496 SEQUENCE OF type. This count is not explicitly represented but for
497 matching purposes it has an assumed ASN.1 type of INTEGER (0..MAX).
498 A ComponentId of the <count> form MUST be the last ComponentId in a
501 The <all> form of ComponentId MAY be used to simultaneously identify
502 all instances of the component type of the SET OF or SEQUENCE OF
506 Legg Expires 19 October 2002 [Page 9]
508 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
511 type. It is through the <all> form that a component reference can
512 identify more than one component value. However, if a particular
513 value of the SET OF or SEQUENCE OF type is an empty list there are no
514 corresponding component values.
516 Where multiple component values are identified, the remaining
517 ComponentIds in the component reference, if any, can identify zero,
518 one or more subcomponent values for each of the higher level
521 The corresponding ASN.1 type for the <from-beginning>, <from-end>,
522 and <all> forms of ComponentId is the component type of the SET OF or
525 The <from-beginning>, <count>, <from-end> and <all> forms MUST NOT be
526 used on ASN.1 types other than SET OF or SEQUENCE OF.
529 5.1.4 Referencing Components of Parameterized Types
531 A component reference cannot be formed for a parameterized type
532 unless the type has been used with actual parameters, in which case
533 the type is treated as though the DummyReferences [15] have been
534 substituted with the actual parameters.
537 5.1.5 Component Referencing Example
539 Consider the following ASN.1 type definitions.
541 ExampleType ::= SEQUENCE {
543 part2 [1] ExampleSet,
544 part3 [2] SET OF OBJECT IDENTIFIER,
545 part4 [3] ExampleChoice }
548 option PrintableString,
551 ExampleChoice ::= CHOICE {
552 eeny-meeny BIT STRING,
553 miney-mo OCTET STRING }
555 Following are component references constructed with respect to the
558 The component reference "part1" identifies a component of a value of
562 Legg Expires 19 October 2002 [Page 10]
564 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
567 ExampleType having the ASN.1 tagged type [0] INTEGER.
569 The component reference "part2" identifies a component of a value of
570 ExampleType having the ASN.1 type of [1] ExampleSet
572 The component reference "part2.option" identifies a component of a
573 value of ExampleType having the ASN.1 type of PrintableString. A
574 ComponentAssertion could also be applied to a value of ASN.1 type
575 ExampleSet, in which case the component reference "option" would
576 identify the same kind of information.
578 The component reference "part3" identifies a component of a value of
579 ExampleType having the ASN.1 type of [2] SET OF OBJECT IDENTIFIER.
581 The component reference "part3.2" identifies the second instance of
582 the part3 SET OF. The instance has the ASN.1 type of OBJECT
585 The component reference "part3.0" identifies the count of the number
586 of instances in the part3 SET OF. The count has the corresponding
587 ASN.1 type of INTEGER (0..MAX).
589 The component reference "part3.*" identifies all the instances in the
590 part3 SET OF. Each instance has the ASN.1 type of OBJECT IDENTIFIER.
592 The component reference "part4" identifies a component of a value of
593 ExampleType having the ASN.1 type of [3] ExampleChoice.
595 The component reference "part4.miney-mo" identifies a component of a
596 value of ExampleType having the ASN.1 type of OCTET STRING.
599 5.1.6 Referencing Components of Open Types
601 If a sequence of ComponentIds identifies an ObjectClassFieldType
602 denoting an open type (e.g. ATTRIBUTE.&Type denotes an open type)
603 then the ASN.1 type of the component varies. An open type is
604 typically constrained by some other component(s) in an outer
605 enclosing type, either formally through the use of a component
606 relation constraint [14], or informally in the accompanying text, so
607 the actual ASN.1 type of a value of the open type will generally be
608 known. The constraint will also limit the range of permissible
609 types. The <select> form of ComponentId MAY be used to identify one
610 of these permissible types in an open type. Subcomponents of that
611 type can then be identified with further ComponentIds.
613 The other components constraining the open type are termed the
614 referenced components (using the terminology in [14]). The <select>
618 Legg Expires 19 October 2002 [Page 11]
620 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
623 form contains a list of one or more values which take the place of
624 the value(s) of the referenced component(s) to uniquely identify one
625 of the permissable types of the open type.
627 Where the open type is constrained by a component relation
628 constraint, there is a <Value> in the <select> form for each of the
629 referenced components in the component relation constraint, appearing
630 in the same order. The ASN.1 type of each of these values is the
631 same as the ASN.1 type of the corresponding referenced component.
632 The type of a referenced component is potentially any ASN.1 type
633 however it is typically an OBJECT IDENTIFIER or INTEGER, which means
634 that the <Value> in the <select> form of ComponentId will nearly
635 always be an <ObjectIdentifierValue> or <IntegerValue> (see [7]).
636 Furthermore, component relation constraints typically have only one
637 referenced component.
639 Where the open type is not constrained by a component relation
640 constraint, the specification introducing the syntax containing the
641 open type SHOULD explicitly nominate the referenced components and
642 their order, so that the <select> form can be used.
644 If an instance of <select> contains a value other than the value of
645 the referenced component used in a particular value of the outer
646 enclosing type then there are no corresponding component values for
650 5.1.6.1 Open Type Referencing Example
652 The ASN.1 type AttributeTypeAndValue from [8] describes a single
653 attribute value of a nominated attribute type.
655 AttributeTypeAndValue ::= SEQUENCE {
656 type ATTRIBUTE.&id ({SupportedAttributes}),
657 value ATTRIBUTE.&Type ({SupportedAttributes}{@type}) }
659 ATTRIBUTE.&id denotes an OBJECT IDENTIFIER and
660 ({SupportedAttributes}) constrains the OBJECT IDENTIFIER to be a
661 supported attribute type.
663 ATTRIBUTE.&Type denotes an open type, in this case an attribute
664 value, and ({SupportedAttributes}{@type}) is a component relation
665 constraint that constrains the open type to be of the attribute
666 syntax for the attribute type. The component relation constraint
667 references only the "type" component, which has the ASN.1 type of
668 OBJECT IDENTIFIER, thus if the <select> form of ComponentId is used
669 to identify attribute values of specific attribute types it will
670 contain a single OBJECT IDENTIFIER value.
674 Legg Expires 19 October 2002 [Page 12]
676 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
679 The component reference "value" on AttributeTypeAndValue refers to
682 One of the X.500 standard attributes is facsimileTelephoneNumber
683 [10], which is identified with the OBJECT IDENTIFIER 2.5.4.23, and is
684 defined to have the following syntax.
686 FacsimileTelephoneNumber ::= SEQUENCE {
687 telephoneNumber PrintableString(SIZE(1..ub-telephone-number)),
688 parameters G3FacsimileNonBasicParameters OPTIONAL }
690 The component reference "value.(2.5.4.23)" on AttributeTypeAndValue
691 specifies an attribute value with the FacsimileTelephoneNumber
694 The component reference "value.(2.5.4.23).telephoneNumber" on
695 AttributeTypeAndValue identifies the telephoneNumber component of a
696 facsimileTelephoneNumber attribute value. The component reference
697 "value.(facsimileTelephoneNumber)" is equivalent to
700 If the AttributeTypeAndValue ASN.1 value contains an attribute type
701 other than facsimileTelephoneNumber then there are no corresponding
702 component values for the component references "value.(2.5.4.23)" and
703 "value.(2.5.4.23).telephoneNumber".
706 5.1.7 Referencing Contained Types
708 Sometimes the contents of a BIT STRING or OCTET STRING value are
709 required to be the encodings of other ASN.1 values of specific ASN.1
710 types. For example, the extnValue component of the Extension type
711 component in the Certificate type [9] is an OCTET STRING that is
712 required to contain a DER encoding of a certificate extension value.
713 It is useful to be able to refer to the embedded encoded value and
714 its components. An embedded encoded value is here referred to as a
715 contained value and its associated type as the contained type.
717 If the ASN.1 type is a BIT STRING or OCTET STRING type containing
718 encodings of other ASN.1 values then the <content> form of
719 ComponentId MAY be used to identify the contained type.
720 Subcomponents of that type can then be identified with further
723 The contained type may be (effectively) an open type, constrained by
724 some other component in an outer enclosing type (e.g. in a
725 certificate Extension, extnValue is constrained by the chosen
726 extnId). In these cases the next ComponentId, if any, MUST be of the
730 Legg Expires 19 October 2002 [Page 13]
732 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
737 For the purpose of building component references, the content of the
738 extnValue OCTET STRING in the Extension type is assumed to be an open
739 type having a notional component relation constraint with the extnId
740 component as the single referenced component, i.e.
742 EXTENSION.&ExtnType ({ExtensionSet}{@extnId})
744 The data-value component of the associated types for the EXTERNAL,
745 EMBEDDED PDV and CHARACTER STRING types is an OCTET STRING containing
746 the encoding of a data value described by the identification
747 component. For the purpose of building component references, the
748 content of the data-value OCTET STRING in these types is assumed to
749 be an open type having a notional component relation constraint with
750 the identification component as the single referenced component.
753 5.1.7.1 Contained Type Referencing Example
755 The Extension ASN.1 type from [9] describes a single certificate
756 extension value of a nominated extension type.
758 Extension ::= SEQUENCE {
759 extnId EXTENSION.&id ({ExtensionSet}),
760 critical BOOLEAN DEFAULT FALSE,
761 extnValue OCTET STRING
762 -- contains a DER encoding of a value of type &ExtnType
763 -- for the extension object identified by extnId -- }
765 EXTENSION.&id denotes an OBJECT IDENTIFIER and ({ExtensionSet})
766 constrains the OBJECT IDENTIFIER to be the identifier of a supported
767 certificate extension.
769 The component reference "extnValue" on Extension refers to a
770 component type of OCTET STRING. The corresponding component values
771 will be OCTET STRING values. The component reference
772 "extnValue.content" on Extension refers to the type of the contained
773 type, which in this case is an open type.
775 One of the X.509 [X.509] standard extensions is basicConstraints,
776 which is identified with the OBJECT IDENTIFIER 2.5.29.19 and is
777 defined to have the following syntax.
779 BasicConstraintsSyntax ::= SEQUENCE {
780 cA BOOLEAN DEFAULT FALSE,
781 pathLenConstraint INTEGER (0..MAX) OPTIONAL }
786 Legg Expires 19 October 2002 [Page 14]
788 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
791 The component reference "extnValue.content.(2.5.29.19)" on Extension
792 specifies a BasicConstraintsSyntax extension value and the component
793 reference "extnValue.content.(2.5.29.19).cA" identifies the cA
794 component of a BasicConstraintsSyntax extension value.
797 5.2 Matching of Components
799 The rule in a ComponentAssertion specifies how the zero, one or more
800 component values identified by the component reference are tested by
801 the assertion. Attribute matching rules are used to specify the
802 semantics of the test.
804 Each matching rule has a notional set of attribute syntaxes
805 (typically one), defined as ASN.1 types, to which it may be applied.
806 When used in a ComponentAssertion these matching rules apply to the
807 same ASN.1 types, only in this context the corresponding ASN.1 values
808 are not complete attribute values.
810 Note that the referenced component type may be a tagged and/or
811 constrained version of the expected attribute syntax (e.g. [0]
812 INTEGER, whereas integerMatch would expect simply INTEGER), or an
813 open type. Additional type substitutions of the kind described in
814 Section 5.1.1 are performed as required to reduce the component type
815 to the same type as the attribute syntax expected by the matching
816 rule. If an open type is encountered the actual ASN.1 type of the
817 component value is substituted before continuing.
819 If a matching rule applies to more than one attribute syntax (e.g.
820 objectIdentifierFirstComponentMatch [10]) then the minimum number of
821 substitutions required to conform to any one of those syntaxes are
822 performed. If a matching rule can apply to any attribute syntax
823 (e.g. the allComponentsMatch rule defined in Section 8.2) then the
824 referenced component type is used as is, with no additional
827 The value in a ComponentAssertion will be of the assertion syntax
828 (i.e. ASN.1 type) required by the chosen matching rule. Note that
829 the assertion syntax of a matching rule is not necessarily the same
830 as the attribute syntax(es) to which the rule may be applied.
832 Some matching rules do not have a fixed assertion syntax (e.g.
833 allComponentsMatch). The required assertion syntax is determined in
834 each instance of use by the syntax of the attribute type to which the
835 matching rule is applied. For these rules the ASN.1 type of the
836 referenced component is used in place of an attribute syntax to
837 decide the required assertion syntax.
842 Legg Expires 19 October 2002 [Page 15]
844 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
847 The ComponentAssertion is undefined if:
849 a) the matching rule in the ComponentAssertion is not known to the
850 evaluating procedure,
852 b) if no part of the component reference identifies an open type and
853 the matching rule is not applicable to the referenced component
854 type, even with the additional type substitutions,
856 c) the value in the ComponentAssertion does not conform to the
857 assertion syntax defined for the matching rule,
859 d) an open type in the tested value cannot be decoded, or
861 e) the implementation does not support the particular combination of
862 component reference and matching rule.
864 If the ComponentAssertion is not undefined then the
865 ComponentAssertion evaluates to TRUE if there is at least one
866 component value for which the matching rule applied to that component
867 value returns TRUE, and evaluates to FALSE otherwise (which includes
868 the case where there are no component values).
870 If some part of the component reference identifies an open type and
871 the matching rule is not applicable to the referenced component type
872 the ComponentAssertion evaluates to FALSE.
875 5.2.1 Applicability of Existing Matching Rules
877 5.2.1.1 String Matching
879 ASN.1 has a number of built in restricted character string types with
880 different character sets and/or different character encodings. A
881 directory user generally has little interest in the particular
882 character set or encoding used to represent a character string
883 component value, and some directory server implementations make no
884 distinction between the different string types in their internal
885 representation of values. So rather than define string matching
886 rules for each of the restricted character string types, the existing
887 case ignore and case exact string matching rules are extended to
888 apply to component values of any of the restricted character string
889 types and any ChoiceOfStrings type [7], in addition to component
890 values of the DirectoryString type. This extension is only for the
891 purposes of component matching described in this document.
893 The relevant string matching rules are: caseIgnoreMatch,
894 caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch, caseExactMatch,
898 Legg Expires 19 October 2002 [Page 16]
900 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
903 caseExactOrderingMatch and caseExactSubstringsMatch. The relevant
904 restricted character string types are: NumericString,
905 PrintableString, VisibleString, IA5String, UTF8String, BMPString,
906 UniversalString, TeletexString, VideotexString, GraphicString and
907 GeneralString. A ChoiceOfStrings type is a purely syntactic CHOICE
908 of these ASN.1 string types. Note that [7] declares each and every
909 use of the DirectoryString{} parameterized type to be a
910 ChoiceOfStrings type.
912 The assertion syntax of the string matching rules is still
913 DirectoryString regardless of the string syntax of the component
914 being matched. Thus an implementation will be called upon to compare
915 a DirectoryString value to a value of one of the restricted character
916 string types, or a ChoiceOfStrings type. As is the case when
917 comparing two DirectoryStrings where the chosen alternatives are of
918 different string types, the comparison proceeds so long as the
919 corresponding characters are representable in both character sets.
920 Otherwise matching returns FALSE.
923 5.2.1.2 Telephone Number Matching
925 Early editions of X.520 [10] gave the syntax of the telephoneNumber
926 attribute as a constrained PrintableString. The fourth edition of
927 X.520 equates the ASN.1 type name TelephoneNumber to the constrained
928 PrintableString and uses TelephoneNumber as the attribute and
929 assertion syntax. For the purposes of component matching,
930 telephoneNumberMatch and telephoneNumberSubstringsMatch are permitted
931 to be applied to any PrintableString value, as well as to
932 TelephoneNumber values.
935 5.2.1.3 Distinguished Name Matching
937 The DistinguishedName type is defined by assignment to be the same as
938 the RDNSequence type, however RDNSequence is sometimes directly used
939 in other type definitions. For the purposes of component matching,
940 distinguishedNameMatch is also permitted to be applied to values of
941 the RDNSequence type.
944 5.2.2 Additional Useful Matching Rules
946 This section defines additional matching rules that may prove useful
947 in ComponentAssertions. These rules MAY also be used in
948 extensibleMatch search filters [3].
954 Legg Expires 19 October 2002 [Page 17]
956 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
959 5.2.2.1 The rdnMatch Matching Rule
961 The distinguishedNameMatch matching rule can match whole
962 distinguished names but it is sometimes useful to be able to match
963 specific RDNs in a DN without regard for the other RDNs in the DN.
964 The rdnMatch matching rule allows component RDNs of a DN to be
967 The LDAP-style definitions for rdnMatch and its assertion syntax are:
969 ( 1.2.36.79672281.1.13.3 NAME 'rdnMatch'
970 SYNTAX 1.2.36.79672281.1.5.0 )
972 ( 1.2.36.79672281.1.5.0 DESC 'RDN' )
974 The LDAP-specific encoding for a value of the RDN syntax is given by
975 the <RelativeDistinguishedNameValue> rule in [7].
977 The X.500-style definition for rdnMatch is:
979 rdnMatch MATCHING-RULE ::= {
980 SYNTAX RelativeDistinguishedName
981 ID { 1 2 36 79672281 1 13 3 } }
983 The rdnMatch rule evaluates to true if the component value and
984 assertion value are the same RDN, using the same RDN comparison
985 method as distinguishedNameMatch.
987 When using rdnMatch to match components of DNs it is important to
988 note that the LDAP-specific encoding of a DN [5] reverses the order
989 of the RDNs. So for the DN represented in LDAP as "cn=Steven
990 Legg,o=Adacel,c=AU", the RDN "cn=Steven Legg" corresponds to the
991 component reference "3", or alternatively, "-1".
994 5.2.2.2 The presentMatch Matching Rule
996 At times it would be useful to test not if a specific value of a
997 particular component is present, but whether any value of a
998 particular component is present. The presentMatch matching rule
999 allows the presence of a particular component value to be tested.
1001 The LDAP-style definitions for presentMatch and its assertion syntax
1004 ( 1.2.36.79672281.1.13.5 NAME 'presentMatch'
1005 SYNTAX 1.2.36.79672281.1.5.1 )
1010 Legg Expires 19 October 2002 [Page 18]
1012 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
1015 ( 1.2.36.79672281.1.5.1 DESC 'NULL' )
1017 The LDAP-specific encoding for a value of the NULL syntax is given by
1018 the <NullValue> rule in [7].
1020 The X.500-style definition for presentMatch is:
1022 presentMatch MATCHING-RULE ::= {
1024 ID { 1 2 36 79672281 1 13 5 } }
1026 When used in a extensible match filter item, presentMatch behaves
1027 like the "present" case of a regular search filter. In a
1028 ComponentAssertion, presentMatch evaluates to TRUE if and only if the
1029 component reference identifies one or more component values,
1030 regardless of the actual component value contents. Note that if
1031 useDefaultValues is TRUE then the identified component values may be
1032 (part of) a DEFAULT value.
1034 The notional count referenced by the <count> form of ComponentId is
1035 taken to be present if the SET OF value is present, and absent
1036 otherwise. Note that in ASN.1 notation an absent SET OF value is
1037 distinctly different from a SET OF value that is present but empty.
1038 It is up to the specification using the ASN.1 notation to decide
1039 whether the distinction matters. Often an empty SET OF component and
1040 an absent SET OF component are treated as semantically equivalent.
1041 If a SET OF value is present, but empty, a presentMatch on the SET OF
1042 component SHALL return TRUE and the notional count SHALL be regarded
1043 as present and equal to zero.
1046 5.2.3 Summary of Useful Matching Rules
1048 The following is a non-exhaustive list of useful matching rules and
1049 the ASN.1 types to which they can be applied, taking account of all
1050 the extensions described in Section 5.2.1, and the new matching rules
1051 defined in Section 5.2.2.
1066 Legg Expires 19 October 2002 [Page 19]
1068 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
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 19 October 2002 [Page 20]
1124 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
1127 +--------------------------------+------------------------------+
1128 | uTCTimeMatch | UTCTime |
1129 | uTCTimeOrderingMatch | |
1130 +--------------------------------+------------------------------+
1132 Note that the allComponentsMatch matching rule defined in Section 8.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 19 October 2002 [Page 21]
1180 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
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 7. 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 19 October 2002 [Page 22]
1236 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
1239 [ sp useDefaultValues "," ]
1241 sp assertion-value sp "}"
1242 component = component-label msp
1243 dquote component-reference dquote
1244 useDefaultValues = use-defaults-label msp BooleanValue
1245 rule = rule-label msp ObjectIdentifierValue
1246 assertion-value = value-label msp Value
1248 component-label = %x63.6F.6D.70.6F.6E.65.6E.74 ; "component"
1249 use-defaults-label = %x75.73.65.44.65.66.61.75.6C.74.56.61.6C.75
1250 %x65.73 ; "useDefaultValues"
1251 rule-label = %x72.75.6C.65 ; "rule"
1252 value-label = %x76.61.6C.75.65 ; "value"
1254 sp = *%x20 ; zero, one or more space characters
1255 msp = 1*%x20 ; one or more space characters
1256 dquote = %x22 ; " (double quote)
1258 The ABNF for <Value>, <ObjectIdentifierValue> and <BooleanValue> is
1261 The ABNF descriptions of LDAP-specific encodings for attribute
1262 syntaxes typically do not clearly or consistently delineate the
1263 component parts of an attribute value. A regular and uniform
1264 character string encoding for arbitrary component data types is
1265 needed to encode the assertion value in a ComponentAssertion. The
1266 <Value> rule from [7] provides a human readable text encoding for a
1267 component value of any arbitrary ASN.1 type.
1269 The X.500-style definition [8] for componentFilterMatch is:
1271 componentFilterMatch MATCHING-RULE ::= {
1272 SYNTAX ComponentFilter
1273 ID { 1 2 36 79672281 1 13 2 } }
1275 A ComponentAssertion can potentially use any matching rule, including
1276 componentFilterMatch, so componentFilterMatch MAY be nested. The
1277 component references in a nested componentFilterMatch are relative to
1278 the component corresponding to the containing ComponentAssertion. In
1279 Section 9, an example search on the seeAlso attribute shows this
1283 8. Equality Matching of Complex Components
1285 It is possible to test if an attribute value of a complex ASN.1
1286 syntax is the same as some purported (i.e. assertion) value by using
1290 Legg Expires 19 October 2002 [Page 23]
1292 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
1295 a complicated ComponentFilter that tests if corresponding components
1296 are the same. However, it would be more convenient to be able to
1297 present a whole assertion value to a matching rule that could do the
1298 component-wise comparison of an attribute value with the assertion
1299 value for any arbitrary attribute syntax. Similarly, the ability to
1300 do a straightforward equality comparison of a component value that is
1301 itself of a complex ASN.1 type would also be convenient.
1303 It would be difficult to define a single matching rule that
1304 simultaneously satisfies all notions of what the equality matching
1305 semantics should be. For example, in some instances a case sensitive
1306 comparison of string components may be preferable to a case
1307 insensitive comparison. Therefore a basic equality matching rule,
1308 allComponentsMatch, is defined in Section 8.2, and the means to
1309 derive new matching rules from it with slightly different equality
1310 matching semantics are described in Section 8.3.
1312 The directoryComponentsMatch defined in Section 8.4 is a derivation
1313 of allComponentsMatch that suits typical uses of the directory.
1314 Other specifications are free to derive new rules from
1315 allComponentsMatch or directoryComponentsMatch, that suit their usage
1318 The allComponentsMatch rule, the directoryComponentsMatch rule and
1319 any matching rules derived from them are collectively called
1320 component equality matching rules.
1323 8.1 The OpenAssertionType Syntax
1325 The component equality matching rules have a variable assertion
1326 syntax. In X.500 this is indicated by omitting the optional SYNTAX
1327 field in the MATCHING-RULE information object. The assertion syntax
1328 then defaults to the target attribute's syntax in actual usage,
1329 unless the description of the matching rule says otherwise. The
1330 SYNTAX field in the LDAP-specific encoding of a
1331 MatchingRuleDescription is mandatory, so the OpenAssertionType syntax
1332 is defined to fill the same role. That is, the OpenAssertionType
1333 syntax is semantically equivalent to an omitted SYNTAX field in an
1334 X.500 MATCHING-RULE information object. OpenAssertionType MUST NOT
1335 be used as the attribute syntax in an attribute type definition.
1337 Unless explicitly varied by the description of a particular matching
1338 rule, if an OpenAssertionType assertion value appears in a
1339 ComponentAssertion its LDAP-specific encoding is described by the
1340 <Value> rule in [7], otherwise its LDAP-specific encoding is the
1341 encoding defined for the syntax of the attribute type to which the
1342 matching rule with the OpenAssertionType assertion syntax is applied.
1346 Legg Expires 19 October 2002 [Page 24]
1348 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
1351 The LDAP definition for the OpenAssertionType syntax is:
1353 ( 1.2.36.79672281.1.5.3 DESC 'OpenAssertionType' )
1356 8.2 The allComponentsMatch Matching Rule
1358 The LDAP-style definition for allComponentsMatch is:
1360 ( 1.2.36.79672281.1.13.6 NAME 'allComponentsMatch'
1361 SYNTAX 1.2.36.79672281.1.5.3 )
1363 The X.500-style definition for allComponentsMatch is:
1365 allComponentsMatch MATCHING-RULE ::= {
1366 ID { 1 2 36 79672281 1 13 6 } }
1368 When allComponentsMatch is used in a ComponentAssertion the assertion
1369 syntax is the same as the ASN.1 type of the identified component.
1370 Otherwise, the assertion syntax of allComponentsMatch is the same as
1371 the attribute syntax of the attribute to which the matching rule is
1374 Broadly speaking, this matching rule evaluates to true if and only if
1375 corresponding components of the assertion value and the attribute or
1376 component value are the same.
1378 In detail, equality is determined by the following cases applied
1381 a) Two values of a SET or SEQUENCE type are the same if and only if,
1382 for each component type, the corresponding component values are
1387 2) both present and the same, or
1389 3) absent or the same as the DEFAULT value for the component, if a
1390 DEFAULT value is defined.
1392 Values of an EMBEDDED PDV, EXTERNAL, unrestricted CHARACTER
1393 STRING, or INSTANCE OF type are compared according to their
1394 respective SEQUENCE type (see Section 5.1.2).
1396 b) Two values of a SEQUENCE OF type are the same if and only if, the
1397 values have the same number of (possibly duplicated) instances and
1398 corresponding instances are the same.
1402 Legg Expires 19 October 2002 [Page 25]
1404 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
1407 c) Two values of a SET OF type are the same if and only if, the
1408 values have the same number of instances and each distinct
1409 instance occurs in both values the same number of times, i.e. both
1410 values have the same instances, including duplicates, but in any
1413 d) Two values of a CHOICE type are the same if and only if, both
1414 values are of the same chosen alternative and the component values
1417 e) Two BIT STRING values are the same if and only if the values have
1418 the same number of bits and corresponding bits are the same. If
1419 the BIT STRING type is defined with a named bit list then trailing
1420 zero bits in the values are treated as absent for the purposes of
1423 f) Two BOOLEAN values are the same if and only if both are TRUE or
1426 g) Two values of a string type are the same if and only if the values
1427 have the same number of characters and corresponding characters
1428 are the same. Letter case is significant. For the purposes of
1429 allComponentsMatch, the string types are NumericString,
1430 PrintableString, TeletexString (T61String), VideotexString,
1431 IA5String, GraphicString, VisibleString (ISO646String),
1432 GeneralString, UniversalString, BMPString, UTF8String,
1433 GeneralizedTime, UTCTime and ObjectDescriptor.
1435 h) Two INTEGER values are the same if and only if the integers are
1438 i) Two ENUMERATED values are the same if and only if the enumeration
1439 item identifiers are the same (equivalently, if the integer values
1440 associated with the identifiers are equal).
1442 j) Two NULL values are always the same, unconditionally.
1444 k) Two OBJECT IDENTIFIER values are the same if and only if the
1445 values have the same number of arcs and corresponding arcs are the
1448 l) Two OCTET STRING values are the same if and only if the values
1449 have the same number of octets and corresponding octets are the
1452 m) Two REAL values are the same if and only if they are both the same
1453 special value, or neither is a special value and they have the
1454 same base and represent the same real number. The special values
1458 Legg Expires 19 October 2002 [Page 26]
1460 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
1463 for REAL are zero, PLUS-INFINITY and MINUS-INFINITY.
1465 n) Two RELATIVE-OID [12] values are the same if and only if the
1466 values have the same number of arcs and corresponding arcs are the
1467 same. The respective starting nodes for the RELATIVE-OID values
1468 are disregarded in the comparison, i.e. they are assumed to be the
1471 o) Two values of an open type are the same if and only if both are of
1472 the same ASN.1 type and are the same according to that type.
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 8.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 19 October 2002 [Page 27]
1516 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
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 5.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 8.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 8.3.
1570 Legg Expires 19 October 2002 [Page 28]
1572 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
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 9. Component Matching Examples
1626 Legg Expires 19 October 2002 [Page 29]
1628 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
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 19 October 2002 [Page 30]
1684 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
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 19 October 2002 [Page 31]
1740 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
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 19 October 2002 [Page 32]
1796 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
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 19 October 2002 [Page 33]
1852 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
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 19 October 2002 [Page 34]
1908 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
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 19 October 2002 [Page 35]
1964 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
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.
1978 10. Security Considerations
1980 The component matching rules described in this document allow for a
1981 compact specification of matching capabilities that could otherwise
1982 have been defined by a plethora of specific matching rules, i.e.
1983 despite their expressiveness and flexibility the component matching
1984 rules do not behave in a way uncharacteristic of other matching
1985 rules, so the security issues for component matching rules are no
1986 different than for any other matching rule. However, because the
1987 component matching rules are applicable to any attribute syntax,
1988 support for them in a directory server may allow searching of
1989 attributes that were previously unsearchable by virtue of there not
1990 being a suitable matching rule. Such attribute types ought to be
1991 properly protected with appropriate access controls.
1994 11. Acknowledgements
1996 The author would like to thank Tom Gindin for private email
1997 discussions that clarified and refined the ideas presented in this
2001 12. Normative References
2003 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
2004 Levels", BCP 14, RFC 2119, March 1997.
2006 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax
2007 Specifications: ABNF", RFC 2234, November 1997.
2009 [3] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
2010 Protocol (v3)", RFC 2251, December 1997.
2012 [4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
2013 Directory Access Protocol (v3): Attribute Syntax Definitions",
2014 RFC 2252, December 1997.
2018 Legg Expires 19 October 2002 [Page 36]
2020 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
2023 [5] Wahl, M., Kille S. and T. Howes. "Lightweight Directory Access
2024 Protocol (v3): UTF-8 String Representation of Distinguished
2025 Names", RFC 2253, December 1997.
2027 [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2030 [7] Legg, S., "Generic String Encoding Rules for ASN.1 Types",
2031 draft-legg-ldap-gser-xx.txt, a work in progress, March 2002.
2033 [8] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
2034 Information Technology - Open Systems Interconnection - The
2037 [9] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1998,
2038 Information Technology - Open Systems Interconnection - The
2039 Directory: Authentication Framework
2041 [10] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
2042 Information Technology - Open Systems Interconnection - The
2043 Directory: Selected attribute types
2045 [11] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998
2046 Information Technology - Abstract Syntax Notation One (ASN.1):
2047 Specification of basic notation
2049 [12] ITU-T Recommendation X.680 - Amendment 1 (06/99) | ISO/IEC
2050 8824-1:1998/Amd 1:2000 Relative object identifiers
2052 [13] ITU-T Recommendation X.681 (1997) | ISO/IEC 8824-2:1998
2053 Information Technology - Abstract Syntax Notation One (ASN.1):
2054 Information object specification
2056 [14] ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998
2057 Information Technology - Abstract Syntax Notation One (ASN.1):
2058 Constraint specification
2060 [15] ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998
2061 Information Technology - Abstract Syntax Notation One (ASN.1):
2062 Parameterization of ASN.1 specifications
2065 13. Informative References
2067 [16] Hovey, R. and S. Bradner, "The Organizations Involved in the
2068 IETF Standards Process", BCP 11, RFC 2028, October 1996.
2070 [17] Howes, T., "The String Representation of LDAP Search Filters",
2074 Legg Expires 19 October 2002 [Page 37]
2076 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
2079 RFC 2254, December 1997.
2081 [18] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
2082 Information Technology - Open Systems Interconnection - The
2083 Directory: Overview of concepts, models and services
2085 [19] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998
2086 Information Technology - ASN.1 encoding rules: Specification of
2087 Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
2088 Distinguished Encoding Rules (DER)
2091 14. Intellectual Property Notice
2093 The IETF takes no position regarding the validity or scope of any
2094 intellectual property or other rights that might be claimed to
2095 pertain to the implementation or use of the technology described in
2096 this document or the extent to which any license under such rights
2097 might or might not be available; neither does it represent that it
2098 has made any effort to identify any such rights. Information on the
2099 IETF's procedures with respect to rights in standards-track and
2100 standards-related documentation can be found in BCP-11. [16] Copies
2101 of claims of rights made available for publication and any assurances
2102 of licenses to be made available, or the result of an attempt made to
2103 obtain a general license or permission for the use of such
2104 proprietary rights by implementors or users of this specification can
2105 be obtained from the IETF Secretariat.
2107 The IETF invites any interested party to bring to its attention any
2108 copyrights, patents or patent applications, or other proprietary
2109 rights which may cover technology that may be required to practice
2110 this standard. Please address the information to the IETF Executive
2114 15. Copyright Notice
2116 Copyright (C) The Internet Society (2002). All Rights Reserved.
2118 This document and translations of it may be copied and furnished to
2119 others, and derivative works that comment on or otherwise explain it
2120 or assist in its implementation may be prepared, copied, published
2121 and distributed, in whole or in part, without restriction of any
2122 kind, provided that the above copyright notice and this paragraph are
2123 included on all such copies and derivative works. However, this
2124 document itself may not be modified in any way, such as by removing
2125 the copyright notice or references to the Internet Society or other
2126 Internet organizations, except as needed for the purpose of
2130 Legg Expires 19 October 2002 [Page 38]
2132 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
2135 developing Internet standards in which case the procedures for
2136 copyrights defined in the Internet Standards process must be
2137 followed, or as required to translate it into languages other than
2140 The limited permissions granted above are perpetual and will not be
2141 revoked by the Internet Society or its successors or assigns.
2143 This document and the information contained herein is provided on an
2144 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2145 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2146 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2147 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2148 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2151 16. Author's Address
2154 Adacel Technologies Ltd.
2155 405-409 Ferntree Gully Road
2156 Mount Waverley, Victoria 3149
2159 Phone: +61 3 9451 2107
2160 Fax: +61 3 9541 2121
2161 EMail: steven.legg@adacel.com.au
2164 17. Appendix A - Changes From Previous Drafts
2166 17.1 Changes in Draft 01
2168 Section 4.1.7 (now 5.1.7) was added to enable component matching of
2169 values embedded in encoded form into BIT STRINGs or OCTET STRINGs.
2170 In particular, this is to allow component matching of values in
2171 Certificate extensions. The <content> rule was added in Section 4.1
2172 (now 5.1) to allow the OCTET STRING contents to be treated as either
2173 raw octets or as an embedded value.
2175 References to a companion document summarizing the ASN.1 types of
2176 LDAP syntaxes were removed to avoid holding up this document.
2178 The OpenType syntax was renamed to OpenAssertionType.
2180 Object identifiers for the new syntax and matching rule definitions
2181 have been allocated from an arc belonging to Adacel Technologies Ltd.
2186 Legg Expires 19 October 2002 [Page 39]
2188 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
2191 17.2 Changes in Draft 02
2193 The context specific tagging in the ComponentAssertion ASN.1 type was
2194 unnecessary and has been removed.
2196 The encoding of OpenAssertionType assertion values outside of
2197 ComponentAssertions has been clarified, and the description of
2198 OpenAssertionType has been promoted to its own section.
2200 17.3 Changes in Draft 03
2202 The default matching by allComponentsMatch of component values of BIT
2203 STRING types with named bit lists has been changed to ignore trailing
2206 Typographical errors in the <SafeUTF8Character> rule have been fixed.
2208 17.4 Changes in Draft 04
2210 When the matching rule in a ComponentAssertion has a variable
2211 assertion syntax it is not possible to determine the syntax of the
2212 value component from the ComponentAssertion alone when the associated
2213 component reference has referenced through an open type. Deducing
2214 what that syntax should be from inspection of the other
2215 ComponentAssertions in a ComponentFilter is difficult to implement in
2216 any comprehensive way. The <select> form of ComponentId has been
2217 introduced so that the syntax can always be determined from the
2218 contents of the ComponentAssertion alone. This not only simplifies
2219 implementation but can lead to simpler ComponentFilters since there
2220 is no longer a requirement to test that the components constraining
2221 an open type have particular values. The open type referencing
2222 example has been changed accordingly. The contained type referencing
2223 example has also been changed because it is an example of a contained
2226 The presentationAddressMatch rule is not commutative so it has been
2227 removed from the table defining directoryComponentsMatch. The default
2228 behaviour of allComponentsMatch is already a suitable commutative
2229 substitute for matching PresentationAddress values.
2231 The null character has been included in the range of legal characters
2232 for <SafeUTF8Character>.
2234 The ASN.1 type of the notional iteration count associated with SET OF
2235 and SEQUENCE OF values has been refined to INTEGER (0..MAX).
2237 The encoding rules in Section 8 (now draft-legg-ldap-gser-xx.txt)
2238 have been formally named the Generic String Encoding Rules (GSER) and
2242 Legg Expires 19 October 2002 [Page 40]
2244 INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
2247 a transfer syntax object identifier has been assigned.
2249 The term "LDAP string encoding" has been replaced by the term "native
2250 LDAP-specific encoding" to align with terminology anticipated to be
2251 used in the revision of RFC 2252.
2253 17.5 Changes in Draft 05
2255 Reformatted the draft to conform to recent and proposed RFC editorial
2258 The use of the <oid> rule from RFC 2252 has been replaced by a local
2259 definition to specifically outlaw leading zero characters in OBJECT
2260 IDENTIFIER components.
2262 Provisions for the RELATIVE-OID ASN.1 type defined in Amendment 1 to
2263 X.680 have been added.
2265 The comparison of REAL values has been clarified and the GSER
2266 encoding of REAL values has been extended.
2268 Removed extraneous spaces from example DNs.
2270 17.6 Changes in Draft 06
2272 An ABNF syntax error in the <exponent> rule was fixed.
2274 17.7 Changes in Draft 07
2276 The term "native LDAP encoding" has been replaced by the term "LDAP-
2277 specific encoding" to align with terminology anticipated to be used
2278 in the revision of RFC 2252.
2280 Section 8 has been extracted to become a separate Internet draft,
2281 draft-legg-ldap-gser-00.txt. The specifications for ChoiceOfStrings
2282 types have also been moved to this new Internet draft. Various
2283 editorial changes have been made to this draft to accommodate this
2286 17.8 Changes in Draft 08
2288 The enumeratedMatch matching rule duplicates a subset of the
2289 functionality of allComponentsMatch so it has been removed. The
2290 enumeratedMatch rule has been replaced by allComponentsMatch in the
2291 examples. The description of the OpenAssertionType syntax has been
2292 moved into Section 8.
2298 Legg Expires 19 October 2002 [Page 41]
projects / openldap / blob