diff options
Diffstat (limited to 'doc/rfc/rfc3687.txt')
| -rw-r--r-- | doc/rfc/rfc3687.txt | 2355 |
1 files changed, 2355 insertions, 0 deletions
diff --git a/doc/rfc/rfc3687.txt b/doc/rfc/rfc3687.txt new file mode 100644 index 0000000..a63ab1f --- /dev/null +++ b/doc/rfc/rfc3687.txt @@ -0,0 +1,2355 @@ + + + + + + +Network Working Group S. Legg +Request for Comments: 3687 Adacel Technologies +Category: Standards Track February 2004 + + + Lightweight Directory Access Protocol (LDAP) + and X.500 Component Matching Rules + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + The syntaxes of attributes in a Lightweight Directory Access Protocol + (LDAP) or X.500 directory range from simple data types, such as text + string, integer, or boolean, to complex structured data types, such + as the syntaxes of the directory schema operational attributes. + Matching rules defined for the complex syntaxes usually only provide + the most immediately useful matching capability. This document + defines generic matching rules that can match any user selected + component parts in an attribute value of any arbitrarily complex + attribute syntax. + + + + + + + + + + + + + + + + + + + + +Legg Standards Track [Page 1] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. ComponentAssertion . . . . . . . . . . . . . . . . . . . . . . 5 + 3.1. Component Reference. . . . . . . . . . . . . . . . . . . 6 + 3.1.1. Component Type Substitutions . . . . . . . . . . 7 + 3.1.2. Referencing SET, SEQUENCE and CHOICE Components. 8 + 3.1.3. Referencing SET OF and SEQUENCE OF Components. . 9 + 3.1.4. Referencing Components of Parameterized Types. . 10 + 3.1.5. Component Referencing Example. . . . . . . . . . 10 + 3.1.6. Referencing Components of Open Types . . . . . . 12 + 3.1.6.1. Open Type Referencing Example . . . . . 12 + 3.1.7. Referencing Contained Types. . . . . . . . . . . 14 + 3.1.7.1. Contained Type Referencing Example. . . 14 + 3.2. Matching of Components . . . . . . . . . . . . . . . . . 15 + 3.2.1. Applicability of Existing Matching Rules . . . . 17 + 3.2.1.1. String Matching . . . . . . . . . . . . 17 + 3.2.1.2. Telephone Number Matching . . . . . . . 17 + 3.2.1.3. Distinguished Name Matching . . . . . . 18 + 3.2.2. Additional Useful Matching Rules . . . . . . . . 18 + 3.2.2.1. The rdnMatch Matching Rule. . . . . . . 18 + 3.2.2.2. The presentMatch Matching Rule. . . . . 19 + 3.2.3. Summary of Useful Matching Rules . . . . . . . . 20 + 4. ComponentFilter. . . . . . . . . . . . . . . . . . . . . . . . 21 + 5. The componentFilterMatch Matching Rule . . . . . . . . . . . . 22 + 6. Equality Matching of Complex Components. . . . . . . . . . . . 24 + 6.1. The OpenAssertionType Syntax . . . . . . . . . . . . . . 24 + 6.2. The allComponentsMatch Matching Rule . . . . . . . . . . 25 + 6.3. Deriving Component Equality Matching Rules . . . . . . . 27 + 6.4. The directoryComponentsMatch Matching Rule . . . . . . . 28 + 7. Component Matching Examples. . . . . . . . . . . . . . . . . . 30 + 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 37 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 + 10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 37 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 + 11.1. Normative References. . . . . . . . . . . . . . . . . . 38 + 11.2. Informative References. . . . . . . . . . . . . . . . . 40 + 12. Intellectual Property Statement. . . . . . . . . . . . . . . . 40 + 13. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 41 + 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 42 + + + + + + + + + + +Legg Standards Track [Page 2] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + +1. Introduction + + The structure or data type of data held in an attribute of a + Lightweight Directory Access Protocol (LDAP) [7] or X.500 [19] + directory is described by the attribute's syntax. Attribute syntaxes + range from simple data types, such as text string, integer, or + boolean, to complex data types, for example, the syntaxes of the + directory schema operational attributes. + + In X.500, the attribute syntaxes are explicitly described by Abstract + Syntax Notation One (ASN.1) [13] type definitions. ASN.1 type + notation has a number of simple data types (e.g., PrintableString, + INTEGER, BOOLEAN), and combining types (i.e., SET, SEQUENCE, SET OF, + SEQUENCE OF, and CHOICE) for constructing arbitrarily complex data + types from simpler component types. In LDAP, the attribute syntaxes + are usually described in Augmented Backus-Naur Form (ABNF) [2], + though there is an implied association between the LDAP attribute + syntaxes and the X.500 ASN.1 types. To a large extent, the data + types of attribute values in either an LDAP or X.500 directory are + described by ASN.1 types. This formal description can be exploited + to identify component parts of an attribute value for a variety of + purposes. This document addresses attribute value matching. + + With any complex attribute syntax there is normally a requirement to + partially match an attribute value of that syntax by matching only + selected components of the value. Typically, matching rules specific + to the attribute syntax are defined to fill this need. These highly + specific matching rules usually only provide the most immediately + useful matching capability. Some complex attribute syntaxes don't + even have an equality matching rule let alone any additional matching + rules for partial matching. This document defines a generic way of + matching user selected components in an attribute value of any + arbitrarily complex attribute syntax, where that syntax is described + using ASN.1 type notation. All of the type notations defined in + X.680 [13] are supported. + + Section 3 describes the ComponentAssertion, a testable assertion + about the value of a component of an attribute value of any complex + syntax. + + Section 4 introduces the ComponentFilter assertion, which is an + expression of ComponentAssertions. The ComponentFilter enables more + powerful filter matching of components in an attribute value. + + Section 5 defines the componentFilterMatch matching rule, which + enables a ComponentFilter to be evaluated against attribute values. + + + + + +Legg Standards Track [Page 3] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + Section 6 defines matching rules for component-wise equality matching + of attribute values of any syntax described by an ASN.1 type + definition. + + Examples showing the usage of componentFilterMatch are in Section 7. + + For a new attribute syntax, the Generic String Encoding Rules [9] and + the specifications in sections 3 to 6 of this document make it + possible to fully and precisely define the LDAP-specific encoding, + the LDAP and X.500 binary encoding (and possibly other ASN.1 + encodings in the future), a suitable equality matching rule, and a + comprehensive collection of component matching capabilities, by + simply writing down an ASN.1 type definition for the syntax. These + implicit definitions are also automatically extended if the ASN.1 + type is later extended. The algorithmic relationship between the + ASN.1 type definition, the various encodings and the component + matching behaviour makes directory server implementation support for + the component matching rules amenable to automatic code generation + from ASN.1 type definitions. + + Schema designers have the choice of storing related items of data as + a single attribute value of a complex syntax in some entry, or as a + subordinate entry where the related data items are stored as separate + attribute values of simpler syntaxes. The inability to search + component parts of a complex syntax has been used as an argument for + favouring the subordinate entries approach. The component matching + rules provide the analogous matching capability on an attribute value + of a complex syntax that a search filter has on a subordinate entry. + + Most LDAP syntaxes have corresponding ASN.1 type definitions, though + they are usually not reproduced or referenced alongside the formal + definition of the LDAP syntax. Syntaxes defined with only a + character string encoding, i.e., without an explicit or implied + corresponding ASN.1 type definition, cannot use the component + matching capabilities described in this document unless and until a + semantically equivalent ASN.1 type definition is defined for them. + +2. Conventions + + Throughout this document "type" shall be taken to mean an ASN.1 type + unless explicitly qualified as an attribute type, and "value" shall + be taken to mean an ASN.1 value unless explicitly qualified as an + attribute value. + + + + + + + + +Legg Standards Track [Page 4] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + Note that "ASN.1 value" does not mean a Basic Encoding Rules (BER) + [17] encoded value. The ASN.1 value is an abstract concept that is + independent of any particular encoding. BER is just one possible + encoding of an ASN.1 value. The component matching rules operate at + the abstract level without regard for the possible encodings of a + value. + + Attribute type and matching rule definitions in this document are + provided in both the X.500 [10] and LDAP [4] description formats. + Note that the LDAP descriptions have been rendered with additional + white-space and line breaks for the sake of readability. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED" and "MAY" in this document are + to be interpreted as described in BCP 14, RFC 2119 [1]. The key word + "OPTIONAL" is exclusively used with its ASN.1 meaning. + +3. ComponentAssertion + + A ComponentAssertion is an assertion about the presence, or values + of, components within an ASN.1 value, i.e., an instance of an ASN.1 + type. The ASN.1 value is typically an attribute value, where the + ASN.1 type is the syntax of the attribute. However, a + ComponentAssertion may also be applied to a component part of an + attribute value. The assertion evaluates to either TRUE, FALSE or + Undefined for each tested ASN.1 value. + + A ComponentAssertion is described by the following ASN.1 type + (assumed to be defined with "EXPLICIT TAGS" in force): + + ComponentAssertion ::= SEQUENCE { + component ComponentReference (SIZE(1..MAX)) OPTIONAL, + useDefaultValues BOOLEAN DEFAULT TRUE, + rule MATCHING-RULE.&id, + value MATCHING-RULE.&AssertionType } + + ComponentReference ::= UTF8String + + MATCHING-RULE.&id equates to the OBJECT IDENTIFIER of a matching + rule. MATCHING-RULE.&AssertionType is an open type (formerly known + as the ANY type). + + The "component" field of a ComponentAssertion identifies which + component part of a value of some ASN.1 type is to be tested, the + "useDefaultValues" field indicates whether DEFAULT values are to be + substituted for absent component values, the "rule" field indicates + + + + + +Legg Standards Track [Page 5] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + how the component is to be tested, and the "value" field is an + asserted ASN.1 value against which the component is tested. The + ASN.1 type of the asserted value is determined by the chosen rule. + + The fields of a ComponentAssertion are described in detail in the + following sections. + +3.1. Component Reference + + The component field in a ComponentAssertion is a UTF-8 character + string [6] whose textual content is a component reference, + identifying a component part of some ASN.1 type or value. A + component reference conforms to the following ABNF [2], which extends + the notation defined in Clause 14 of X.680 [13]: + + component-reference = ComponentId *( "." ComponentId ) + ComponentId = identifier / + from-beginning / + count / + from-end / ; extends Clause 14 + content / ; extends Clause 14 + select / ; extends Clause 14 + all + + identifier = lowercase *alphanumeric + *(hyphen 1*alphanumeric) + alphanumeric = uppercase / lowercase / decimal-digit + uppercase = %x41-5A ; "A" to "Z" + lowercase = %x61-7A ; "a" to "z" + hyphen = "-" + + from-beginning = positive-number + count = "0" + from-end = "-" positive-number + content = %x63.6F.6E.74.65.6E.74 ; "content" + select = "(" Value *( "," Value ) ")" + all = "*" + + + positive-number = non-zero-digit *decimal-digit + + decimal-digit = %x30-39 ; "0" to "9" + non-zero-digit = %x31-39 ; "1" to "9" + + + + + + + + +Legg Standards Track [Page 6] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + An <identifier> conforms to the definition of an identifier in ASN.1 + notation (Clause 11.3 of X.680 [13]). It begins with a lowercase + letter and is followed by zero or more letters, digits, and hyphens. + A hyphen is not permitted to be the last character and a hyphen is + not permitted to be followed by another hyphen. + + The <Value> rule is described by the Generic String Encoding Rules + (GSER) [9]. + + A component reference is a sequence of one or more ComponentIds where + each successive ComponentId identifies either an inner component at + the next level of nesting of an ASN.1 combining type, i.e., SET, + SEQUENCE, SET OF, SEQUENCE OF, or CHOICE, or a specific type within + an ASN.1 open type. + + A component reference is always considered in the context of a + particular complex ASN.1 type. When applied to the ASN.1 type the + component reference identifies a specific component type. When + applied to a value of the ASN.1 type a component reference identifies + zero, one or more component values of that component type. The + component values are potentially in a DEFAULT value if + useDefaultValues is TRUE. The specific component type identified by + the component reference determines what matching rules are capable of + being used to match the component values. + + The component field in a ComponentAssertion may also be absent, in + which case the identified component type is the ASN.1 type to which + the ComponentAssertion is applied, and the identified component value + is the whole ASN.1 value. + + A valid component reference for a particular complex ASN.1 type is + constructed by starting with the outermost combining type and + repeatedly selecting one of the permissible forms of ComponentId to + identify successively deeper nested components. A component + reference MAY identify a component with a complex ASN.1 type, i.e., + it is not required that the component type identified by a component + reference be a simple ASN.1 type. + +3.1.1. Component Type Substitutions + + ASN.1 type notation has a number of constructs for referencing other + defined types, and constructs that are irrelevant for matching + purposes. These constructs are not represented in a component + reference in any way and substitutions of the component type are + performed to eliminate them from further consideration. These + substitutions automatically occur prior to each ComponentId, whether + constructing or interpreting a component reference, but do not occur + after the last ComponentId, except as allowed by Section 3.2. + + + +Legg Standards Track [Page 7] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + If the ASN.1 type is an ASN.1 type reference then the component type + is taken to be the actual definition on the right hand side of the + type assignment for the referenced type. + + If the ASN.1 type is a tagged type then the component type is taken + to be the type without the tag. + + If the ASN.1 type is a constrained type (see X.680 [13] and X.682 + [15] for the details of ASN.1 constraint notation) then the component + type is taken to be the type without the constraint. + + If the ASN.1 type is an ObjectClassFieldType (Clause 14 of X.681 + [14]) that denotes a specific ASN.1 type (e.g., MATCHING-RULE.&id + denotes the OBJECT IDENTIFIER type) then the component type is taken + to be the denoted type. Section 3.1.6 describes the case where the + ObjectClassFieldType denotes an open type. + + If the ASN.1 type is a selection type other than one used in the list + of components for a SET or SEQUENCE type then the component type is + taken to be the selected alternative type from the named CHOICE. + + If the ASN.1 type is a TypeFromObject (Clause 15 of X.681 [14]) then + the component type is taken to be the denoted type. + + If the ASN.1 type is a ValueSetFromObjects (Clause 15 of X.681 [14]) + then the component type is taken to be the governing type of the + denoted values. + +3.1.2. Referencing SET, SEQUENCE and CHOICE Components + + If the ASN.1 type is a SET or SEQUENCE type then the <identifier> + form of ComponentId may be used to identify the component type within + that SET or SEQUENCE having that identifier. If <identifier> + references an OPTIONAL component type and that component is not + present in a particular value then there are no corresponding + component values. If <identifier> references a DEFAULT component + type and useDefaultValues is TRUE (the default setting for + useDefaultValues) and that component is not present in a particular + value then the component value is taken to be the default value. If + <identifier> references a DEFAULT component type and useDefaultValues + is FALSE and that component is not present in a particular value then + there are no corresponding component values. + + If the ASN.1 type is a CHOICE type then the <identifier> form of + ComponentId may be used to identify the alternative type within that + CHOICE having that identifier. If <identifier> references an + alternative other than the one used in a particular value then there + are no corresponding component values. + + + +Legg Standards Track [Page 8] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + The COMPONENTS OF notation in Clause 24 of X.680 [13] augments the + defined list of components in a SET or SEQUENCE type by including all + the components of another defined SET or SEQUENCE type respectively. + These included components are referenced directly by identifier as + though they were defined in-line in the SET or SEQUENCE type + containing the COMPONENTS OF notation. + + The SelectionType (Clause 29 of X.680 [13]), when used in the list of + components for a SET or SEQUENCE type, includes a single component + from a defined CHOICE type. This included component is referenced + directly by identifier as though it was defined in-line in the SET or + SEQUENCE type. + + The REAL type is treated as though it is the SEQUENCE type defined in + Clause 20.5 of X.680 [13]. + + The EMBEDDED PDV type is treated as though it is the SEQUENCE type + defined in Clause 33.5 of X.680 [13]. + + The EXTERNAL type is treated as though it is the SEQUENCE type + defined in Clause 8.18.1 of X.690 [17]. + + The unrestricted CHARACTER STRING type is treated as though it is the + SEQUENCE type defined in Clause 40.5 of X.680 [13]. + + The INSTANCE OF type is treated as though it is the SEQUENCE type + defined in Annex C of X.681 [14]. + + The <identifier> form MUST NOT be used on any other ASN.1 type. + +3.1.3. Referencing SET OF and SEQUENCE OF Components + + If the ASN.1 type is a SET OF or SEQUENCE OF type then the + <from-beginning>, <from-end>, <count> and <all> forms of ComponentId + may be used. + + The <from-beginning> form of ComponentId may be used to identify one + instance (i.e., value) of the component type of the SET OF or + SEQUENCE OF type (e.g., if Foo ::= SET OF Bar, then Bar is the + component type), where the instances are numbered from one upwards. + If <from-beginning> references a higher numbered instance than the + last instance in a particular value of the SET OF or SEQUENCE OF type + then there is no corresponding component value. + + The <from-end> form of ComponentId may be used to identify one + instance of the component type of the SET OF or SEQUENCE OF type, + where "-1" is the last instance, "-2" is the second last instance, + + + + +Legg Standards Track [Page 9] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + and so on. If <from-end> references a lower numbered instance than + the first instance in a particular value of the SET OF or SEQUENCE OF + type then there is no corresponding component value. + + The <count> form of ComponentId identifies a notional count of the + number of instances of the component type in a value of the SET OF or + SEQUENCE OF type. This count is not explicitly represented but for + matching purposes it has an assumed ASN.1 type of INTEGER (0..MAX). + A ComponentId of the <count> form, if used, MUST be the last + ComponentId in a component reference. + + The <all> form of ComponentId may be used to simultaneously identify + all instances of the component type of the SET OF or SEQUENCE OF + type. It is through the <all> form that a component reference can + identify more than one component value. However, if a particular + value of the SET OF or SEQUENCE OF type is an empty list, then there + are no corresponding component values. + + Where multiple component values are identified, the remaining + ComponentIds in the component reference, if any, can identify zero, + one or more subcomponent values for each of the higher level + component values. + + The corresponding ASN.1 type for the <from-beginning>, <from-end>, + and <all> forms of ComponentId is the component type of the SET OF or + SEQUENCE OF type. + + The <from-beginning>, <count>, <from-end> and <all> forms MUST NOT be + used on ASN.1 types other than SET OF or SEQUENCE OF. + +3.1.4. Referencing Components of Parameterized Types + + A component reference cannot be formed for a parameterized type + unless the type has been used with actual parameters, in which case + the type is treated as though the DummyReferences [16] have been + substituted with the actual parameters. + +3.1.5. Component Referencing Example + + Consider the following ASN.1 type definitions. + + ExampleType ::= SEQUENCE { + part1 [0] INTEGER, + part2 [1] ExampleSet, + part3 [2] SET OF OBJECT IDENTIFIER, + part4 [3] ExampleChoice } + + + + + +Legg Standards Track [Page 10] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + ExampleSet ::= SET { + option PrintableString, + setting BOOLEAN } + + ExampleChoice ::= CHOICE { + eeny-meeny BIT STRING, + miney-mo OCTET STRING } + + Following are component references constructed with respect to the + type ExampleType. + + The component reference "part1" identifies a component of a value of + ExampleType having the ASN.1 tagged type [0] INTEGER. + + The component reference "part2" identifies a component of a value of + ExampleType having the ASN.1 type of [1] ExampleSet + + The component reference "part2.option" identifies a component of a + value of ExampleType having the ASN.1 type of PrintableString. A + ComponentAssertion could also be applied to a value of ASN.1 type + ExampleSet, in which case the component reference "option" would + identify the same kind of information. + + The component reference "part3" identifies a component of a value of + ExampleType having the ASN.1 type of [2] SET OF OBJECT IDENTIFIER. + + The component reference "part3.2" identifies the second instance of + the part3 SET OF. The instance has the ASN.1 type of OBJECT + IDENTIFIER. + + The component reference "part3.0" identifies the count of the number + of instances in the part3 SET OF. The count has the corresponding + ASN.1 type of INTEGER (0..MAX). + + The component reference "part3.*" identifies all the instances in the + part3 SET OF. Each instance has the ASN.1 type of OBJECT IDENTIFIER. + + The component reference "part4" identifies a component of a value of + ExampleType having the ASN.1 type of [3] ExampleChoice. + + The component reference "part4.miney-mo" identifies a component of a + value of ExampleType having the ASN.1 type of OCTET STRING. + + + + + + + + + +Legg Standards Track [Page 11] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + +3.1.6. Referencing Components of Open Types + + If a sequence of ComponentIds identifies an ObjectClassFieldType + denoting an open type (e.g., ATTRIBUTE.&Type denotes an open type) + then the ASN.1 type of the component varies. An open type is + typically constrained by some other component(s) in an outer + enclosing type, either formally through the use of a component + relation constraint [15], or informally in the accompanying text, so + the actual ASN.1 type of a value of the open type will generally be + known. The constraint will also limit the range of permissible + types. The <select> form of ComponentId may be used to identify one + of these permissible types in an open type. Subcomponents of that + type can then be identified with further ComponentIds. + + The other components constraining the open type are termed the + referenced components [15]. The <select> form contains a list of one + or more values which take the place of the value(s) of the referenced + component(s) to uniquely identify one of the permissible types of the + open type. + + Where the open type is constrained by a component relation + constraint, there is a <Value> in the <select> form for each of the + referenced components in the component relation constraint, appearing + in the same order. The ASN.1 type of each of these values is the + same as the ASN.1 type of the corresponding referenced component. + The type of a referenced component is potentially any ASN.1 type + however it is typically an OBJECT IDENTIFIER or INTEGER, which means + that the <Value> in the <select> form of ComponentId will nearly + always be an <ObjectIdentifierValue> or <IntegerValue> [9]. + Furthermore, component relation constraints typically have only one + referenced component. + + Where the open type is not constrained by a component relation + constraint, the specification introducing the syntax containing the + open type should explicitly nominate the referenced components and + their order, so that the <select> form can be used. + + If an instance of <select> contains a value other than the value of + the referenced component used in a particular value of the outer + enclosing type then there are no corresponding component values for + the open type. + +3.1.6.1. Open Type Referencing Example + + The ASN.1 type AttributeTypeAndValue [10] describes a single + attribute value of a nominated attribute type. + + + + + +Legg Standards Track [Page 12] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + AttributeTypeAndValue ::= SEQUENCE { + type ATTRIBUTE.&id ({SupportedAttributes}), + value ATTRIBUTE.&Type ({SupportedAttributes}{@type}) } + + ATTRIBUTE.&id denotes an OBJECT IDENTIFIER and + ({SupportedAttributes}) constrains the OBJECT IDENTIFIER to be a + supported attribute type. + + ATTRIBUTE.&Type denotes an open type, in this case an attribute + value, and ({SupportedAttributes}{@type}) is a component relation + constraint that constrains the open type to be of the attribute + syntax for the attribute type. The component relation constraint + references only the "type" component, which has the ASN.1 type of + OBJECT IDENTIFIER, thus if the <select> form of ComponentId is used + to identify attribute values of specific attribute types it will + contain a single OBJECT IDENTIFIER value. + + The component reference "value" on AttributeTypeAndValue refers to + the open type. + + One of the X.500 standard attributes is facsimileTelephoneNumber + [12], which is identified with the OBJECT IDENTIFIER 2.5.4.23, and is + defined to have the following syntax. + + FacsimileTelephoneNumber ::= SEQUENCE { + telephoneNumber PrintableString(SIZE(1..ub-telephone-number)), + parameters G3FacsimileNonBasicParameters OPTIONAL } + + The component reference "value.(2.5.4.23)" on AttributeTypeAndValue + specifies an attribute value with the FacsimileTelephoneNumber + syntax. + + The component reference "value.(2.5.4.23).telephoneNumber" on + AttributeTypeAndValue identifies the telephoneNumber component of a + facsimileTelephoneNumber attribute value. The component reference + "value.(facsimileTelephoneNumber)" is equivalent to + "value.(2.5.4.23)". + + If the AttributeTypeAndValue ASN.1 value contains an attribute type + other than facsimileTelephoneNumber then there are no corresponding + component values for the component references "value.(2.5.4.23)" and + "value.(2.5.4.23).telephoneNumber". + + + + + + + + + +Legg Standards Track [Page 13] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + +3.1.7. Referencing Contained Types + + Sometimes the contents of a BIT STRING or OCTET STRING value are + required to be the encodings of other ASN.1 values of specific ASN.1 + types. For example, the extnValue component of the Extension type + component in the Certificate type [11] is an OCTET STRING that is + required to contain a Distinguished Encoding Rules (DER) [17] + encoding of a certificate extension value. It is useful to be able + to refer to the embedded encoded value and its components. An + embedded encoded value is here referred to as a contained value and + its associated type as the contained type. + + If the ASN.1 type is a BIT STRING or OCTET STRING type containing + encodings of other ASN.1 values then the <content> form of + ComponentId may be used to identify the contained type. + Subcomponents of that type can then be identified with further + ComponentIds. + + The contained type may be (effectively) an open type, constrained by + some other component in an outer enclosing type (e.g., in a + certificate Extension, extnValue is constrained by the chosen + extnId). In these cases the next ComponentId, if any, MUST be of the + <select> form. + + For the purpose of building component references, the content of the + extnValue OCTET STRING in the Extension type is assumed to be an open + type having a notional component relation constraint with the extnId + component as the single referenced component, i.e., + + EXTENSION.&ExtnType ({ExtensionSet}{@extnId}) + + The data-value component of the associated types for the EMBEDDED PDV + and CHARACTER STRING types is an OCTET STRING containing the encoding + of a data value described by the identification component. For the + purpose of building component references, the content of the + data-value OCTET STRING in these types is assumed to be an open type + having a notional component relation constraint with the + identification component as the single referenced component. + +3.1.7.1. Contained Type Referencing Example + + The Extension ASN.1 type [11] describes a single certificate + extension value of a nominated extension type. + + + + + + + + +Legg Standards Track [Page 14] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + Extension ::= SEQUENCE { + extnId EXTENSION.&id ({ExtensionSet}), + critical BOOLEAN DEFAULT FALSE, + extnValue OCTET STRING + -- contains a DER encoding of a value of type &ExtnType + -- for the extension object identified by extnId -- } + + EXTENSION.&id denotes an OBJECT IDENTIFIER and ({ExtensionSet}) + constrains the OBJECT IDENTIFIER to be the identifier of a supported + certificate extension. + + The component reference "extnValue" on Extension refers to a + component type of OCTET STRING. The corresponding component values + will be OCTET STRING values. The component reference + "extnValue.content" on Extension refers to the type of the contained + type, which in this case is an open type. + + One of the X.509 [11] standard extensions is basicConstraints, which + is identified with the OBJECT IDENTIFIER 2.5.29.19 and is defined to + have the following syntax. + + BasicConstraintsSyntax ::= SEQUENCE { + cA BOOLEAN DEFAULT FALSE, + pathLenConstraint INTEGER (0..MAX) OPTIONAL } + + The component reference "extnValue.content.(2.5.29.19)" on Extension + specifies a BasicConstraintsSyntax extension value and the component + reference "extnValue.content.(2.5.29.19).cA" identifies the cA + component of a BasicConstraintsSyntax extension value. + +3.2. Matching of Components + + The rule in a ComponentAssertion specifies how the zero, one or more + component values identified by the component reference are tested by + the assertion. Attribute matching rules are used to specify the + semantics of the test. + + Each matching rule has a notional set of attribute syntaxes + (typically one), defined as ASN.1 types, to which it may be applied. + When used in a ComponentAssertion these matching rules apply to the + same ASN.1 types, only in this context the corresponding ASN.1 values + are not necessarily complete attribute values. + + Note that the referenced component type may be a tagged and/or + constrained version of the expected attribute syntax (e.g., + [0] INTEGER, whereas integerMatch would expect simply INTEGER), or an + open type. Additional type substitutions of the kind described in + + + + +Legg Standards Track [Page 15] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + Section 3.1.1 are performed as required to reduce the component type + to the same type as the attribute syntax expected by the matching + rule. + + If a matching rule applies to more than one attribute syntax (e.g., + objectIdentifierFirstComponentMatch [12]) then the minimum number of + substitutions required to conform to any one of those syntaxes is + performed. If a matching rule can apply to any attribute syntax + (e.g., the allComponentsMatch rule defined in Section 6.2) then the + referenced component type is used as is, with no additional + substitutions. + + The value in a ComponentAssertion will be of the assertion syntax + (i.e., ASN.1 type) required by the chosen matching rule. Note that + the assertion syntax of a matching rule is not necessarily the same + as the attribute syntax(es) to which the rule may be applied. + + Some matching rules do not have a fixed assertion syntax (e.g., + allComponentsMatch). The required assertion syntax is determined in + each instance of use by the syntax of the attribute type to which the + matching rule is applied. For these rules the ASN.1 type of the + referenced component is used in place of an attribute syntax to + decide the required assertion syntax. + + The ComponentAssertion is Undefined if: + + a) the matching rule in the ComponentAssertion is not known to the + evaluating procedure, + + b) the matching rule is not applicable to the referenced component + type, even with the additional type substitutions, + + c) the value in the ComponentAssertion does not conform to the + assertion syntax defined for the matching rule, + + d) some part of the component reference identifies an open type in + the tested value that cannot be decoded, or + + e) the implementation does not support the particular combination of + component reference and matching rule. + + If the ComponentAssertion is not Undefined then the + ComponentAssertion evaluates to TRUE if there is at least one + component value for which the matching rule applied to that component + value returns TRUE, and evaluates to FALSE otherwise (which includes + the case where there are no component values). + + + + + +Legg Standards Track [Page 16] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + +3.2.1. Applicability of Existing Matching Rules + +3.2.1.1. String Matching + + ASN.1 has a number of built in restricted character string types with + different character sets and/or different character encodings. A + directory user generally has little interest in the particular + character set or encoding used to represent a character string + component value, and some directory server implementations make no + distinction between the different string types in their internal + representation of values. So rather than define string matching + rules for each of the restricted character string types, the existing + case ignore and case exact string matching rules are extended to + apply to component values of any of the restricted character string + types and any ChoiceOfStrings type [9], in addition to component + values of the DirectoryString type. This extension is only for the + purposes of component matching described in this document. + + The relevant string matching rules are: caseIgnoreMatch, + caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch, caseExactMatch, + caseExactOrderingMatch and caseExactSubstringsMatch. The relevant + restricted character string types are: NumericString, + PrintableString, VisibleString, IA5String, UTF8String, BMPString, + UniversalString, TeletexString, VideotexString, GraphicString and + GeneralString. A ChoiceOfStrings type is a purely syntactic CHOICE + of these ASN.1 string types. Note that GSER [9] declares each and + every use of the DirectoryString{} parameterized type to be a + ChoiceOfStrings type. + + The assertion syntax of the string matching rules is still + DirectoryString regardless of the string syntax of the component + being matched. Thus an implementation will be called upon to compare + a DirectoryString value to a value of one of the restricted character + string types, or a ChoiceOfStrings type. As is the case when + comparing two DirectoryStrings where the chosen alternatives are of + different string types, the comparison proceeds so long as the + corresponding characters are representable in both character sets. + Otherwise matching returns FALSE. + +3.2.1.2. Telephone Number Matching + + Early editions of X.520 [12] gave the syntax of the telephoneNumber + attribute as a constrained PrintableString. The fourth edition of + X.520 equates the ASN.1 type name TelephoneNumber to the constrained + PrintableString and uses TelephoneNumber as the attribute and + assertion syntax. For the purposes of component matching, + + + + + +Legg Standards Track [Page 17] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + telephoneNumberMatch and telephoneNumberSubstringsMatch are permitted + to be applied to any PrintableString value, as well as to + TelephoneNumber values. + +3.2.1.3. Distinguished Name Matching + + The DistinguishedName type is defined by assignment to be the same as + the RDNSequence type, however RDNSequence is sometimes directly used + in other type definitions. For the purposes of component matching, + distinguishedNameMatch is also permitted to be applied to values of + the RDNSequence type. + +3.2.2. Additional Useful Matching Rules + + This section defines additional matching rules that may prove useful + in ComponentAssertions. These rules may also be used in + extensibleMatch search filters [3]. + +3.2.2.1. The rdnMatch Matching Rule + + The distinguishedNameMatch matching rule can match whole + distinguished names but it is sometimes useful to be able to match + specific Relative Distinguished Names (RDNs) in a Distinguished Name + (DN) without regard for the other RDNs in the DN. The rdnMatch + matching rule allows component RDNs of a DN to be tested. + + The LDAP-style definitions for rdnMatch and its assertion syntax are: + + ( 1.2.36.79672281.1.13.3 NAME 'rdnMatch' + SYNTAX 1.2.36.79672281.1.5.0 ) + + ( 1.2.36.79672281.1.5.0 DESC 'RDN' ) + + The LDAP-specific encoding for a value of the RDN syntax is given by + the <RelativeDistinguishedNameValue> rule [9]. + + The X.500-style definition for rdnMatch is: + + rdnMatch MATCHING-RULE ::= { + SYNTAX RelativeDistinguishedName + ID { 1 2 36 79672281 1 13 3 } } + + The rdnMatch rule evaluates to true if the component value and + assertion value are the same RDN, using the same RDN comparison + method as distinguishedNameMatch. + + + + + + +Legg Standards Track [Page 18] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + When using rdnMatch to match components of DNs it is important to + note that the LDAP-specific encoding of a DN [5] reverses the order + of the RDNs. So for the DN represented in LDAP as + "cn=Steven Legg,o=Adacel,c=AU", the RDN "cn=Steven Legg" corresponds + to the component reference "3", or alternatively, "-1". + +3.2.2.2. The presentMatch Matching Rule + + At times it would be useful to test not if a specific value of a + particular component is present, but whether any value of a + particular component is present. The presentMatch matching rule + allows the presence of a particular component value to be tested. + + The LDAP-style definitions for presentMatch and its assertion syntax + are: + + ( 1.2.36.79672281.1.13.5 NAME 'presentMatch' + SYNTAX 1.2.36.79672281.1.5.1 ) + + ( 1.2.36.79672281.1.5.1 DESC 'NULL' ) + + The LDAP-specific encoding for a value of the NULL syntax is given by + the <NullValue> rule [9]. + + The X.500-style definition for presentMatch is: + + presentMatch MATCHING-RULE ::= { + SYNTAX NULL + ID { 1 2 36 79672281 1 13 5 } } + + When used in a extensible match filter item, presentMatch behaves + like the "present" case of a regular search filter. In a + ComponentAssertion, presentMatch evaluates to TRUE if and only if the + component reference identifies one or more component values, + regardless of the actual component value contents. Note that if + useDefaultValues is TRUE then the identified component values may be + (part of) a DEFAULT value. + + The notional count referenced by the <count> form of ComponentId is + taken to be present if the SET OF value is present, and absent + otherwise. Note that in ASN.1 notation an absent SET OF value is + distinctly different from a SET OF value that is present but empty. + It is up to the specification using the ASN.1 notation to decide + whether the distinction matters. Often an empty SET OF component and + an absent SET OF component are treated as semantically equivalent. + If a SET OF value is present, but empty, a presentMatch on the SET OF + component SHALL return TRUE and the notional count SHALL be regarded + as present and equal to zero. + + + +Legg Standards Track [Page 19] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + +3.2.3. Summary of Useful Matching Rules + + The following is a non-exhaustive list of useful matching rules and + the ASN.1 types to which they can be applied, taking account of all + the extensions described in Section 3.2.1, and the new matching rules + defined in Section 3.2.2. + + +================================+==============================+ + | Matching Rule | ASN.1 Type | + +================================+==============================+ + | bitStringMatch | BIT STRING | + +--------------------------------+------------------------------+ + | booleanMatch | BOOLEAN | + +--------------------------------+------------------------------+ + | caseIgnoreMatch | NumericString | + | caseIgnoreOrderingMatch | PrintableString | + | caseIgnoreSubstringsMatch | VisibleString (ISO646String) | + | caseExactMatch | IA5String | + | caseExactOrderingMatch | UTF8String | + | caseExactSubstringsMatch | BMPString (UCS-2, UNICODE) | + | | UniversalString (UCS-4) | + | | TeletexString (T61String) | + | | VideotexString | + | | GraphicString | + | | GeneralString | + | | any ChoiceOfStrings type | + +--------------------------------+------------------------------+ + | caseIgnoreIA5Match | IA5String | + | caseExactIA5Match | | + +--------------------------------+------------------------------+ + | distinguishedNameMatch | DistinguishedName | + | | RDNSequence | + +--------------------------------+------------------------------+ + | generalizedTimeMatch | GeneralizedTime | + | generalizedTimeOrderingMatch | | + +--------------------------------+------------------------------+ + | integerMatch | INTEGER | + | integerOrderingMatch | | + +--------------------------------+------------------------------+ + | numericStringMatch | NumericString | + | numericStringOrderingMatch | | + | numericStringSubstringsMatch | | + +--------------------------------+------------------------------+ + | objectIdentifierMatch | OBJECT IDENTIFIER | + +--------------------------------+------------------------------+ + | octetStringMatch | OCTET STRING | + | octetStringOrderingMatch | | + | octetStringSubstringsMatch | | + + + +Legg Standards Track [Page 20] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + +--------------------------------+------------------------------+ + | presentMatch | any ASN.1 type | + +--------------------------------+------------------------------+ + | rdnMatch | RelativeDistinguishedName | + +--------------------------------+------------------------------+ + | telephoneNumberMatch | PrintableString | + | telephoneNumberSubstringsMatch | TelephoneNumber | + +--------------------------------+------------------------------+ + | uTCTimeMatch | UTCTime | + | uTCTimeOrderingMatch | | + +--------------------------------+------------------------------+ + + Note that the allComponentsMatch matching rule defined in Section 6.2 + can be used for equality matching of values of the ENUMERATED, NULL, + REAL and RELATIVE-OID ASN.1 types, among other things. + +4. ComponentFilter + + The ComponentAssertion allows the value(s) of any one component type + in a complex ASN.1 type to be matched, but there is often a desire to + match the values of more than one component type. A ComponentFilter + is an assertion about the presence, or values of, multiple components + within an ASN.1 value. + + The ComponentFilter assertion, an expression of ComponentAssertions, + evaluates to either TRUE, FALSE or Undefined for each tested ASN.1 + value. + + A ComponentFilter is described by the following ASN.1 type (assumed + to be defined with "EXPLICIT TAGS" in force): + + ComponentFilter ::= CHOICE { + item [0] ComponentAssertion, + and [1] SEQUENCE OF ComponentFilter, + or [2] SEQUENCE OF ComponentFilter, + not [3] ComponentFilter } + + Note: despite the use of SEQUENCE OF instead of SET OF for the "and" + and "or" alternatives in ComponentFilter, the order of the component + filters is not significant. + + A ComponentFilter that is a ComponentAssertion evaluates to TRUE if + the ComponentAssertion is TRUE, evaluates to FALSE if the + ComponentAssertion is FALSE, and evaluates to Undefined otherwise. + + + + + + + +Legg Standards Track [Page 21] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + The "and" of a sequence of component filters evaluates to TRUE if the + sequence is empty or if each component filter evaluates to TRUE, + evaluates to FALSE if at least one component filter is FALSE, and + evaluates to Undefined otherwise. + + The "or" of a sequence of component filters evaluates to FALSE if the + sequence is empty or if each component filter evaluates to FALSE, + evaluates to TRUE if at least one component filter is TRUE, and + evaluates to Undefined otherwise. + + The "not" of a component filter evaluates to TRUE if the component + filter is FALSE, evaluates to FALSE if the component filter is TRUE, + and evaluates to Undefined otherwise. + +5. The componentFilterMatch Matching Rule + + The componentFilterMatch matching rule allows a ComponentFilter to be + applied to an attribute value. The result of the matching rule is + the result of applying the ComponentFilter to the attribute value. + + The LDAP-style definitions for componentFilterMatch and its assertion + syntax are: + + ( 1.2.36.79672281.1.13.2 NAME 'componentFilterMatch' + SYNTAX 1.2.36.79672281.1.5.2 ) + + ( 1.2.36.79672281.1.5.2 DESC 'ComponentFilter' ) + + The LDAP-specific encoding for the ComponentFilter assertion syntax + is specified by GSER [9]. + + As a convenience to implementors, an equivalent ABNF description of + the GSER encoding for ComponentFilter is provided here. In the event + that there is a discrepancy between this ABNF and the encoding + determined by GSER, GSER is to be taken as definitive. The GSER + encoding of a ComponentFilter is described by the following + equivalent ABNF: + + ComponentFilter = filter-item / + and-filter / + or-filter / + not-filter + + filter-item = item-chosen ComponentAssertion + and-filter = and-chosen SequenceOfComponentFilter + or-filter = or-chosen SequenceOfComponentFilter + not-filter = not-chosen ComponentFilter + + + + +Legg Standards Track [Page 22] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + item-chosen = %x69.74.65.6D.3A ; "item:" + and-chosen = %x61.6E.64.3A ; "and:" + or-chosen = %x6F.72.3A ; "or:" + not-chosen = %x6E.6F.74.3A ; "not:" + + SequenceOfComponentFilter = "{" [ sp ComponentFilter + *( "," sp ComponentFilter) ] sp "}" + + ComponentAssertion = "{" [ sp component "," ] + [ sp useDefaultValues "," ] + sp rule "," + sp assertion-value sp "}" + component = component-label msp StringValue + useDefaultValues = use-defaults-label msp BooleanValue + rule = rule-label msp ObjectIdentifierValue + assertion-value = value-label msp Value + + component-label = %x63.6F.6D.70.6F.6E.65.6E.74 ; "component" + use-defaults-label = %x75.73.65.44.65.66.61.75.6C.74.56.61.6C.75 + %x65.73 ; "useDefaultValues" + rule-label = %x72.75.6C.65 ; "rule" + value-label = %x76.61.6C.75.65 ; "value" + + sp = *%x20 ; zero, one or more space characters + msp = 1*%x20 ; one or more space characters + + The ABNF for <Value>, <StringValue>, <ObjectIdentifierValue> and + <BooleanValue> is defined by GSER [9]. + + The ABNF descriptions of LDAP-specific encodings for attribute + syntaxes typically do not clearly or consistently delineate the + component parts of an attribute value. A regular and uniform + character string encoding for arbitrary component data types is + needed to encode the assertion value in a ComponentAssertion. The + <Value> rule from GSER provides a human readable text encoding for a + component value of any arbitrary ASN.1 type. + + The X.500-style definition [10] for componentFilterMatch is: + + componentFilterMatch MATCHING-RULE ::= { + SYNTAX ComponentFilter + ID { 1 2 36 79672281 1 13 2 } } + + A ComponentAssertion can potentially use any matching rule, including + componentFilterMatch, so componentFilterMatch may be nested. The + component references in a nested componentFilterMatch are relative to + + + + + +Legg Standards Track [Page 23] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + the component corresponding to the containing ComponentAssertion. In + Section 7, an example search on the seeAlso attribute shows this + usage. + +6. Equality Matching of Complex Components + + It is possible to test if an attribute value of a complex ASN.1 + syntax is the same as some purported (i.e., assertion) value by using + a complicated ComponentFilter that tests if corresponding components + are the same. However, it would be more convenient to be able to + present a whole assertion value to a matching rule that could do the + component-wise comparison of an attribute value with the assertion + value for any arbitrary attribute syntax. Similarly, the ability to + do a straightforward equality comparison of a component value that is + itself of a complex ASN.1 type would also be convenient. + + It would be difficult to define a single matching rule that + simultaneously satisfies all notions of what the equality matching + semantics should be. For example, in some instances a case sensitive + comparison of string components may be preferable to a case + insensitive comparison. Therefore a basic equality matching rule, + allComponentsMatch, is defined in Section 6.2, and the means to + derive new matching rules from it with slightly different equality + matching semantics are described in Section 6.3. + + The directoryComponentsMatch defined in Section 6.4 is a derivation + of allComponentsMatch that suits typical uses of the directory. + Other specifications are free to derive new rules from + allComponentsMatch or directoryComponentsMatch, that suit their usage + of the directory. + + The allComponentsMatch rule, the directoryComponentsMatch rule and + any matching rules derived from them are collectively called + component equality matching rules. + +6.1. The OpenAssertionType Syntax + + The component equality matching rules have a variable assertion + syntax. In X.500 this is indicated by omitting the optional SYNTAX + field in the MATCHING-RULE information object. The assertion syntax + then defaults to the target attribute's syntax in actual usage, + unless the description of the matching rule says otherwise. The + SYNTAX field in the LDAP-specific encoding of a + MatchingRuleDescription is mandatory, so the OpenAssertionType syntax + is defined to fill the same role. That is, the OpenAssertionType + syntax is semantically equivalent to an omitted SYNTAX field in an + X.500 MATCHING-RULE information object. OpenAssertionType MUST NOT + be used as the attribute syntax in an attribute type definition. + + + +Legg Standards Track [Page 24] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + Unless explicitly varied by the description of a particular matching + rule, if an OpenAssertionType assertion value appears in a + ComponentAssertion its LDAP-specific encoding is described by the + <Value> rule in GSER [9], otherwise its LDAP-specific encoding is the + encoding defined for the syntax of the attribute type to which the + matching rule with the OpenAssertionType assertion syntax is applied. + + The LDAP definition for the OpenAssertionType syntax is: + + ( 1.2.36.79672281.1.5.3 DESC 'OpenAssertionType' ) + +6.2. The allComponentsMatch Matching Rule + + The LDAP-style definition for allComponentsMatch is: + + ( 1.2.36.79672281.1.13.6 NAME 'allComponentsMatch' + SYNTAX 1.2.36.79672281.1.5.3 ) + + The X.500-style definition for allComponentsMatch is: + + allComponentsMatch MATCHING-RULE ::= { + ID { 1 2 36 79672281 1 13 6 } } + + When allComponentsMatch is used in a ComponentAssertion the assertion + syntax is the same as the ASN.1 type of the identified component. + Otherwise, the assertion syntax of allComponentsMatch is the same as + the attribute syntax of the attribute to which the matching rule is + applied. + + Broadly speaking, this matching rule evaluates to true if and only if + corresponding components of the assertion value and the attribute or + component value are the same. + + In detail, equality is determined by the following cases applied + recursively. + + a) Two values of a SET or SEQUENCE type are the same if and only if, + for each component type, the corresponding component values are + either, + + 1) both absent, + + 2) both present and the same, or + + 3) absent or the same as the DEFAULT value for the component, if a + DEFAULT value is defined. + + + + + +Legg Standards Track [Page 25] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + Values of an EMBEDDED PDV, EXTERNAL, unrestricted CHARACTER + STRING, or INSTANCE OF type are compared according to their + respective associated SEQUENCE type (see Section 3.1.2). + + b) Two values of a SEQUENCE OF type are the same if and only if, the + values have the same number of (possibly duplicated) instances and + corresponding instances are the same. + + c) Two values of a SET OF type are the same if and only if, the + values have the same number of instances and each distinct + instance occurs in both values the same number of times, i.e., + both values have the same instances, including duplicates, but in + any order. + + d) Two values of a CHOICE type are the same if and only if, both + values are of the same chosen alternative and the component values + are the same. + + e) Two BIT STRING values are the same if and only if the values have + the same number of bits and corresponding bits are the same. If + the BIT STRING type is defined with a named bit list then trailing + zero bits in the values are treated as absent for the purposes of + this comparison. + + f) Two BOOLEAN values are the same if and only if both are TRUE or + both are FALSE. + + g) Two values of a string type are the same if and only if the values + have the same number of characters and corresponding characters + are the same. Letter case is significant. For the purposes of + allComponentsMatch, the string types are NumericString, + PrintableString, TeletexString (T61String), VideotexString, + IA5String, GraphicString, VisibleString (ISO646String), + GeneralString, UniversalString, BMPString, UTF8String, + GeneralizedTime, UTCTime and ObjectDescriptor. + + h) Two INTEGER values are the same if and only if the integers are + equal. + + i) Two ENUMERATED values are the same if and only if the enumeration + item identifiers are the same (equivalently, if the integer values + associated with the identifiers are equal). + + j) Two NULL values are always the same, unconditionally. + + k) Two OBJECT IDENTIFIER values are the same if and only if the + values have the same number of arcs and corresponding arcs are the + same. + + + +Legg Standards Track [Page 26] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + l) Two OCTET STRING values are the same if and only if the values + have the same number of octets and corresponding octets are the + same. + + m) Two REAL values are the same if and only if they are both the same + special value, or neither is a special value and they have the + same base and represent the same real number. The special values + for REAL are zero, PLUS-INFINITY and MINUS-INFINITY. + + n) Two RELATIVE-OID values are the same if and only if the values + have the same number of arcs and corresponding arcs are the same. + The respective starting nodes for the RELATIVE-OID values are + disregarded in the comparison, i.e., they are assumed to be the + same. + + o) Two values of an open type are the same if and only if both are of + the same ASN.1 type and are the same according to that type. If + the actual ASN.1 type of the values is unknown then the + allComponentsMatch rule evaluates to Undefined. + + Tags and constraints, being part of the type definition and not part + of the abstract values, are ignored for matching purposes. + + The allComponentsMatch rule may be used as the defined equality + matching rule for an attribute. + +6.3. Deriving Component Equality Matching Rules + + A new component equality matching rule with more refined matching + semantics may be derived from allComponentsMatch, or any other + component equality matching rule, using the convention described in + this section. + + The matching behaviour of a derived component equality matching rule + is specified by nominating, for each of one or more identified + components, a commutative equality matching rule that will be used to + match values of that component. This overrides the matching that + would otherwise occur for values of that component using the base + rule for the derivation. These overrides can be conveniently + represented as rows in a table of the following form. + + Component | Matching Rule + ============+=============== + | + | + + + + + + +Legg Standards Track [Page 27] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + Usually, all component values of a particular ASN.1 type are to be + matched the same way. An ASN.1 type reference (e.g., + DistinguishedName) or an ASN.1 built-in type name (e.g., INTEGER) in + the Component column of the table specifies that the nominated + equality matching rule is to be applied to all values of the named + type, regardless of context. + + An ASN.1 type reference with a component reference appended + (separated by a ".") specifies that the nominated matching rule + applies only to the identified components of values of the named + type. Other component values that happen to be of the same ASN.1 + type are not selected. + + Additional type substitutions as described in Section 3.2 are assumed + to be performed to align the component type with the matching rule + assertion syntax. + + Conceptually, the rows in a table for the base rule are appended to + the rows in the table for a derived rule for the purpose of deciding + the matching semantics of the derived rule. Notionally, + allComponentsMatch has an empty table. + + A row specifying values of an outer containing type (e.g., + DistinguishedName) takes precedence over a row specifying values of + an inner component type (e.g., RelativeDistinguishedName), regardless + of their order in the table. Specifying a row for component values + of an inner type is only useful if a value of the type can also + appear on its own, or as a component of values of a different outer + type. For example, if there is a row for DistinguishedName then a + row for RelativeDistinguishedName can only ever apply to + RelativeDistinguishedName component values that are not part of a + DistinguishedName. A row for values of an outer type in the table + for the base rule takes precedence over a row for values of an inner + type in the table for the derived rule. + + Where more than one row applies to a particular component value the + earlier row takes precedence over the later row. Thus rows in the + table for the derived rule take precedence over any rows for the same + component in the table for the base rule. + +6.4. The directoryComponentsMatch Matching Rule + + The directoryComponentsMatch matching rule is derived from the + allComponentsMatch matching rule. + + + + + + + +Legg Standards Track [Page 28] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + The LDAP-style definition for directoryComponentsMatch is: + + ( 1.2.36.79672281.1.13.7 NAME 'directoryComponentsMatch' + SYNTAX 1.2.36.79672281.1.5.3 ) + + The X.500-style definition for directoryComponentsMatch is: + + directoryComponentsMatch MATCHING-RULE ::= { + ID { 1 2 36 79672281 1 13 7 } } + + The matching semantics of directoryComponentsMatch are described by + the following table, using the convention described in Section 6.3. + + ASN.1 Type | Matching Rule + =========================================+======================== + RDNSequence | distinguishedNameMatch + RelativeDistinguishedName | rdnMatch + TelephoneNumber | telephoneNumberMatch + FacsimileTelephoneNumber.telephoneNumber | telephoneNumberMatch + NumericString | numericStringMatch + GeneralizedTime | generalizedTimeMatch + UTCTime | uTCTimeMatch + DirectoryString{} | caseIgnoreMatch + BMPString | caseIgnoreMatch + GeneralString | caseIgnoreMatch + GraphicString | caseIgnoreMatch + IA5String | caseIgnoreMatch + PrintableString | caseIgnoreMatch + TeletexString | caseIgnoreMatch + UniversalString | caseIgnoreMatch + UTF8String | caseIgnoreMatch + VideotexString | caseIgnoreMatch + VisibleString | caseIgnoreMatch + + Notes: + + 1) The DistinguishedName type is defined by assignment to be the same + as the RDNSequence type. Some types (e.g., Name and LocalName) + directly reference RDNSequence rather than DistinguishedName. + Specifying RDNSequence captures all these DN-like types. + + 2) A RelativeDistinguishedName value is only matched by rdnMatch if + it is not part of an RDNSequence value. + + 3) The telephone number component of the FacsimileTelephoneNumber + ASN.1 type [12] is defined as a constrained PrintableString. + PrintableString component values that are part of a + FacsimileTelephoneNumber value can be identified separately from + + + +Legg Standards Track [Page 29] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + other components of PrintableString type by the specifier + FacsimileTelephoneNumber.telephoneNumber, so that + telephoneNumberMatch can be selectively applied. The fourth + edition of X.520 defines the telephoneNumber component of + FacsimileTelephoneNumber to be of the type TelephoneNumber, making + the row for FacsimileTelephoneNumber.telephoneNumber components + redundant. + + The directoryComponentsMatch rule may be used as the defined equality + matching rule for an attribute. + +7. Component Matching Examples + + This section contains examples of search filters using the + componentFilterMatch matching rule. The filters are described using + the string representation of LDAP search filters [18]. Note that + this representation requires asterisks to be escaped in assertion + values (in these examples the assertion values are all + <ComponentAssertion> encodings). The asterisks have not been escaped + in these examples for the sake of clarity, and to avoid confusing the + protocol representation of LDAP search filter assertion values, where + such escaping does not apply. Line breaks and indenting have been + added only as an aid to readability. + + The example search filters using componentFilterMatch are all single + extensible match filter items, though there is no reason why + componentFilterMatch can't be used in more complicated search + filters. + + The first examples describe searches over the objectClasses schema + operational attribute, which has an attribute syntax described by the + ASN.1 type ObjectClassDescription [10], and holds the definitions of + the object classes known to a directory server. The definition of + ObjectClassDescription is as follows: + + ObjectClassDescription ::= SEQUENCE { + identifier OBJECT-CLASS.&id, + name SET OF DirectoryString {ub-schema} OPTIONAL, + description DirectoryString {ub-schema} OPTIONAL, + obsolete BOOLEAN DEFAULT FALSE, + information [0] ObjectClassInformation } + + ObjectClassInformation ::= SEQUENCE { + subclassOf SET OF OBJECT-CLASS.&id OPTIONAL, + kind ObjectClassKind DEFAULT structural, + mandatories [3] SET OF ATTRIBUTE.&id OPTIONAL, + optionals [4] SET OF ATTRIBUTE.&id OPTIONAL } + + + + +Legg Standards Track [Page 30] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + ObjectClassKind ::= ENUMERATED { + abstract (0), + structural (1), + auxiliary (2) } + + OBJECT-CLASS.&id and ATTRIBUTE.&id are equivalent to the OBJECT + IDENTIFIER ASN.1 type. A value of OBJECT-CLASS.&id is an OBJECT + IDENTIFIER for an object class. A value of ATTRIBUTE.&id is an + OBJECT IDENTIFIER for an attribute type. + + The following search filter finds the object class definition for the + object class identified by the OBJECT IDENTIFIER 2.5.6.18: + + (objectClasses:componentFilterMatch:= + item:{ component "identifier", + rule objectIdentifierMatch, value 2.5.6.18 }) + + A match on the "identifier" component of objectClasses values is + equivalent to the objectIdentifierFirstComponentMatch matching rule + applied to attribute values of the objectClasses attribute type. The + componentFilterMatch matching rule subsumes the functionality of the + objectIdentifierFirstComponentMatch, integerFirstComponentMatch and + directoryStringFirstComponentMatch matching rules. + + The following search filter finds the object class definition for the + object class called foobar: + + (objectClasses:componentFilterMatch:= + item:{ component "name.*", + rule caseIgnoreMatch, value "foobar" }) + + An object class definition can have multiple names and the above + filter will match an objectClasses value if any one of the names is + "foobar". + + The component reference "name.0" identifies the notional count of the + number of names in an object class definition. The following search + filter finds object class definitions with exactly one name: + + (objectClasses:componentFilterMatch:= + item:{ component "name.0", rule integerMatch, value 1 }) + + The "description" component of an ObjectClassDescription is defined + to be an OPTIONAL DirectoryString. The following search filter finds + object class definitions that have descriptions, regardless of the + contents of the description string: + + + + + +Legg Standards Track [Page 31] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + (objectClasses:componentFilterMatch:= + item:{ component "description", + rule presentMatch, value NULL }) + + The presentMatch returns TRUE if the description component is present + and FALSE otherwise. + + The following search filter finds object class definitions that don't + have descriptions: + + (objectClasses:componentFilterMatch:= + not:item:{ component "description", + rule presentMatch, value NULL }) + + The following search filter finds object class definitions with the + word "bogus" in the description: + + (objectClasses:componentFilterMatch:= + item:{ component "description", + rule caseIgnoreSubstringsMatch, + value { any:"bogus" } }) + + The assertion value is of the SubstringAssertion syntax, i.e., + + SubstringAssertion ::= SEQUENCE OF CHOICE { + initial [0] DirectoryString {ub-match}, + any [1] DirectoryString {ub-match}, + final [2] DirectoryString {ub-match} } + + The "obsolete" component of an ObjectClassDescription is defined to + be DEFAULT FALSE. An object class is obsolete if the "obsolete" + component is present and set to TRUE. The following search filter + finds all obsolete object classes: + + (objectClasses:componentFilterMatch:= + item:{ component "obsolete", rule booleanMatch, value TRUE }) + + An object class is not obsolete if the "obsolete" component is not + present, in which case it defaults to FALSE, or is present but is + explicitly set to FALSE. The following search filter finds all non- + obsolete object classes: + + (objectClasses:componentFilterMatch:= + item:{ component "obsolete", rule booleanMatch, value FALSE }) + + The useDefaultValues flag in the ComponentAssertion defaults to TRUE + so the componentFilterMatch rule treats an absent "obsolete" + component as being present and set to FALSE. The following search + + + +Legg Standards Track [Page 32] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + filter finds only object class definitions where the "obsolete" + component has been explicitly set to FALSE, rather than implicitly + defaulting to FALSE: + + (objectClasses:componentFilterMatch:= + item:{ component "obsolete", useDefaultValues FALSE, + rule booleanMatch, value FALSE }) + + With the useDefaultValues flag set to FALSE, if the "obsolete" + component is absent the component reference identifies no component + value and the matching rule will return FALSE. The matching rule can + only return TRUE if the component is present and set to FALSE. + + The "information.kind" component of the ObjectClassDescription is an + ENUMERATED type. The allComponentsMatch matching rule can be used to + match values of an ENUMERATED type. The following search filter + finds object class definitions for auxiliary object classes: + + (objectClasses:componentFilterMatch:= + item:{ component "information.kind", + rule allComponentsMatch, value auxiliary }) + + The following search filter finds auxiliary object classes with + commonName (cn or 2.5.4.3) as a mandatory attribute: + + (objectClasses:componentFilterMatch:=and:{ + item:{ component "information.kind", + rule allComponentsMatch, value auxiliary }, + item:{ component "information.mandatories.*", + rule objectIdentifierMatch, value cn } }) + + The following search filter finds auxiliary object classes with + commonName as a mandatory or optional attribute: + + (objectClasses:componentFilterMatch:=and:{ + item:{ component "information.kind", + rule allComponentsMatch, value auxiliary }, + or:{ + item:{ component "information.mandatories.*", + rule objectIdentifierMatch, value cn }, + item:{ component "information.optionals.*", + rule objectIdentifierMatch, value cn } } }) + + Extra care is required when matching optional SEQUENCE OF or SET OF + components because of the distinction between an absent list of + instances and a present, but empty, list of instances. The following + search filter finds object class definitions with less than three + + + + +Legg Standards Track [Page 33] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + names, including object class definitions with a present but empty + list of names, but does not find object class definitions with an + absent list of names: + + (objectClasses:componentFilterMatch:= + item:{ component "name.0", + rule integerOrderingMatch, value 3 }) + + If the "name" component is absent the "name.0" component is also + considered to be absent and the ComponentAssertion evaluates to + FALSE. If the "name" component is present, but empty, the "name.0" + component is also present and equal to zero, so the + ComponentAssertion evaluates to TRUE. To also find the object class + definitions with an absent list of names the following search filter + would be used: + + (objectClasses:componentFilterMatch:=or:{ + not:item:{ component "name", rule presentMatch, value NULL }, + item:{ component "name.0", + rule integerOrderingMatch, value 3 } }) + + Distinguished names embedded in other syntaxes can be matched with a + componentFilterMatch. The uniqueMember attribute type has an + attribute syntax described by the ASN.1 type NameAndOptionalUID. + + NameAndOptionalUID ::= SEQUENCE { + dn DistinguishedName, + uid UniqueIdentifier OPTIONAL } + + The following search filter finds values of the uniqueMember + attribute containing the author's DN: + + (uniqueMember:componentFilterMatch:= + item:{ component "dn", + rule distinguishedNameMatch, + value "cn=Steven Legg,o=Adacel,c=AU" }) + + The DistinguishedName and RelativeDistinguishedName ASN.1 types are + also complex ASN.1 types so the component matching rules can be + applied to their inner components. + + DistinguishedName ::= RDNSequence + + RDNSequence ::= SEQUENCE OF RelativeDistinguishedName + + RelativeDistinguishedName ::= SET SIZE (1..MAX) OF + AttributeTypeAndValue + + + + +Legg Standards Track [Page 34] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + AttributeTypeAndValue ::= SEQUENCE { + type AttributeType ({SupportedAttributes}), + value AttributeValue ({SupportedAttributes}{@type}) } + + AttributeType ::= ATTRIBUTE.&id + + AttributeValue ::= ATTRIBUTE.&Type + + ATTRIBUTE.&Type is an open type. A value of ATTRIBUTE.&Type is + constrained by the type component of AttributeTypeAndValue to be of + the attribute syntax of the nominated attribute type. Note: the + fourth edition of X.500 extends and renames the AttributeTypeAndValue + SEQUENCE type. + + The seeAlso attribute has the DistinguishedName syntax. The + following search filter finds seeAlso attribute values containing the + RDN, "o=Adacel", anywhere in the DN: + + (seeAlso:componentFilterMatch:= + item:{ component "*", rule rdnMatch, value "o=Adacel" }) + + The following search filter finds all seeAlso attribute values with + "cn=Steven Legg" as the RDN of the named entry (i.e., the "first" RDN + in an LDAPDN or the "last" RDN in an X.500 DN): + + (seeAlso:componentFilterMatch:= + item:{ component "-1", + rule rdnMatch, value "cn=Steven Legg" }) + + The following search filter finds all seeAlso attribute values naming + entries in the DIT subtree of "o=Adacel,c=AU": + + (seeAlso:componentFilterMatch:=and:{ + item:{ component "1", rule rdnMatch, value "c=AU" }, + item:{ component "2", rule rdnMatch, value "o=Adacel" } }) + + The following search filter finds all seeAlso attribute values + containing the naming attribute types commonName (cn) and + telephoneNumber in the same RDN: + + (seeAlso:componentFilterMatch:= + item:{ component "*", rule componentFilterMatch, + value and:{ + item:{ component "*.type", + rule objectIdentifierMatch, value cn }, + item:{ component "*.type", + rule objectIdentifierMatch, + value telephoneNumber } } }) + + + +Legg Standards Track [Page 35] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + The following search filter would find all seeAlso attribute values + containing the attribute types commonName and telephoneNumber, but + not necessarily in the same RDN: + + (seeAlso:componentFilterMatch:=and:{ + item:{ component "*.*.type", + rule objectIdentifierMatch, value cn }, + item:{ component "*.*.type", + rule objectIdentifierMatch, value telephoneNumber } }) + + The following search filter finds all seeAlso attribute values + containing the word "Adacel" in any organizationalUnitName (ou) + attribute value in any AttributeTypeAndValue of any RDN: + + (seeAlso:componentFilterMatch:= + item:{ component "*.*.value.(2.5.4.11)", + rule caseIgnoreSubstringsMatch, + value { any:"Adacel" } }) + + The component reference "*.*.value" identifies an open type, in this + case an attribute value. In a particular AttributeTypeAndValue, if + the attribute type is not organizationalUnitName then the + ComponentAssertion evaluates to FALSE. Otherwise the substring + assertion is evaluated against the attribute value. + + Absent component references in ComponentAssertions can be exploited + to avoid false positive matches on multi-valued attributes. For + example, suppose there is a multi-valued attribute named + productCodes, defined to have the Integer syntax + (1.3.6.1.4.1.1466.115.121.1.27). Consider the following search + filter: + + (&(!(productCodes:integerOrderingMatch:=3)) + (productCodes:integerOrderingMatch:=8)) + + An entry whose productCodes attribute contains only the values 1 and + 10 will match the above filter. The first subfilter is satisfied by + the value 10 (10 is not less than 3), and the second subfilter is + satisfied by the value 1 (1 is less than 8). The following search + filter can be used instead to only match entries that have a + productCodes value in the range 3 to 7, because the ComponentFilter + is evaluated against each productCodes value in isolation: + + (productCodes:componentFilterMatch:= and:{ + not:item:{ rule integerOrderingMatch, value 3 }, + item:{ rule integerOrderingMatch, value 8 } }) + + + + + +Legg Standards Track [Page 36] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + An entry whose productCodes attribute contains only the values 1 and + 10 will not match the above filter. + +8. Security Considerations + + The component matching rules described in this document allow for a + compact specification of matching capabilities that could otherwise + have been defined by a plethora of specific matching rules, i.e., + despite their expressiveness and flexibility the component matching + rules do not behave in a way uncharacteristic of other matching + rules, so the security issues for component matching rules are no + different than for any other matching rule. However, because the + component matching rules are applicable to any attribute syntax, + support for them in a directory server may allow searching of + attributes that were previously unsearchable by virtue of there not + being a suitable matching rule. Such attribute types ought to be + properly protected with appropriate access controls. A generic, + interoperable access control mechanism has not yet been developed, + however, and implementors should be aware of the interaction of that + lack with the increased risk of exposure described above. + +9. Acknowledgements + + The author would like to thank Tom Gindin for private email + discussions that clarified and refined the ideas presented in this + document. + +10. IANA Considerations + + The Internet Assigned Numbers Authority (IANA) has updated the LDAP + descriptors registry [8] as indicated by the following templates: + + Subject: Request for LDAP Descriptor Registration + Descriptor (short name): componentFilterMatch + Object Identifier: 1.2.36.79672281.1.13.2 + Person & email address to contact for further information: + Steven Legg <steven.legg@adacel.com.au> + Usage: other (matching rule) + Specification: RFC 3687 + Author/Change Controller: IESG + + + + + + + + + + + +Legg Standards Track [Page 37] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + Subject: Request for LDAP Descriptor Registration + Descriptor (short name): rdnMatch + Object Identifier: 1.2.36.79672281.1.13.3 + Person & email address to contact for further information: + Steven Legg <steven.legg@adacel.com.au> + Usage: other (matching rule) + Specification: RFC 3687 + Author/Change Controller: IESG + + Subject: Request for LDAP Descriptor Registration + Descriptor (short name): presentMatch + Object Identifier: 1.2.36.79672281.1.13.5 + Person & email address to contact for further information: + Steven Legg <steven.legg@adacel.com.au> + Usage: other (matching rule) + Specification: RFC 3687 + Author/Change Controller: IESG + + Subject: Request for LDAP Descriptor Registration + Descriptor (short name): allComponentsMatch + Object Identifier: 1.2.36.79672281.1.13.6 + Person & email address to contact for further information: + Steven Legg <steven.legg@adacel.com.au> + Usage: other (matching rule) + Specification: RFC 3687 + Author/Change Controller: IESG + + Subject: Request for LDAP Descriptor Registration + Descriptor (short name): directoryComponentsMatch + Object Identifier: 1.2.36.79672281.1.13.7 + Person & email address to contact for further information: + Steven Legg <steven.legg@adacel.com.au> + Usage: other (matching rule) + Specification: RFC 3687 + Author/Change Controller: IESG + + The object identifiers have been assigned for use in this + specification by Adacel Technologies, under an arc assigned to Adacel + by Standards Australia. + +11. References + +11.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + + + + +Legg Standards Track [Page 38] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [3] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access + Protocol (v3)", RFC 2251, December 1997. + + [4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight + Directory Access Protocol (v3): Attribute Syntax Definitions", + RFC 2252, December 1997. + + [5] Wahl, M., Kille S. and T. Howes. "Lightweight Directory Access + Protocol (v3): UTF-8 String Representation of Distinguished + Names", RFC 2253, December 1997. + + [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD + 63, RFC 3629, November 2003. + + [7] Hodges, J. and R. Morgan, "Lightweight Directory Access + Protocol (v3): Technical Specification", RFC 3377, September + 2002. + + [8] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) + Considerations for the Lightweight Directory Access Protocol + (LDAP)", BCP 64, RFC 3383, September 2002. + + [9] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1 + Types", RFC 3641, October 2003. + + [10] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994, + Information Technology - Open Systems Interconnection - The + Directory: Models + + [11] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1998, + Information Technology - Open Systems Interconnection - The + Directory: Authentication Framework + + [12] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994, + Information technology - Open Systems Interconnection - The + Directory: Selected attribute types + + [13] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002, + Information technology - Abstract Syntax Notation One (ASN.1): + Specification of basic notation + + [14] ITU-T Recommendation X.681 (07/02) | ISO/IEC 8824-2:2002, + Information technology - Abstract Syntax Notation One (ASN.1): + Information object specification + + + + +Legg Standards Track [Page 39] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + + [15] ITU-T Recommendation X.682 (07/02) | ISO/IEC 8824-3:2002, + Information technology - Abstract Syntax Notation One (ASN.1): + Constraint specification + + [16] ITU-T Recommendation X.683 (07/02) | ISO/IEC 8824-4:2002, + Information technology - Abstract Syntax Notation One (ASN.1): + Parameterization of ASN.1 specifications + + [17] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1, + Information technology - ASN.1 encoding rules: Specification of + Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and + Distinguished Encoding Rules (DER) + +12.2. Informative References + + [18] Howes, T., "The String Representation of LDAP Search Filters", + RFC 2254, December 1997. + + [19] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, + Information Technology - Open Systems Interconnection - The + Directory: Overview of concepts, models and services + +12. Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + + + + + + +Legg Standards Track [Page 40] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + +13. Author's Address + + Steven Legg + Adacel Technologies Ltd. + 250 Bay Street + Brighton, Victoria 3186 + AUSTRALIA + + Phone: +61 3 8530 7710 + Fax: +61 3 8530 7888 + EMail: steven.legg@adacel.com.au + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Legg Standards Track [Page 41] + +RFC 3687 LDAP and X.500 Component Matching Rules February 2004 + + +14. Full Copyright Statement + + Copyright (C) The Internet Society (2004). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Legg Standards Track [Page 42] + |