INTERNET-DRAFT S. Legg draft-legg-ldapext-component-matching-01.txt Adacel Technologies May 7, 2001 LDAP & X.500 Component Matching Rules Copyright (C) The Internet Society (2001). All Rights Reserved. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this document is unlimited. Comments should be sent to the LDAPEXT working group mailing list or to the author. This Internet-Draft expires on 7 November 2001. 1. Abstract The syntaxes of attributes in an 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. The matching rules defined for the complex syntaxes, if any, 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. Generic Legg Expires 7 November 2001 [Page 1] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 string encodings for attribute and assertion values of arbitrary syntax are also defined. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Table of Contents 1. Abstract 1 2. Table of Contents 2 3. Introduction 3 4. ComponentAssertion 5 4.1 Component Reference 5 4.1.1 Component Type Substitutions 7 4.1.2 Referencing SET, SEQUENCE and CHOICE Components 8 4.1.3 Referencing SET OF and SEQUENCE OF Components 9 4.1.4 Referencing Components of Parameterized Types 10 4.1.5 Component Referencing Example 10 4.1.6 Referencing Components of Open Types 11 4.1.6.1 Open Type Referencing Example 12 4.1.7 Referencing Contained Types 12 4.1.7.1 Contained Type Referencing Example 13 4.2 Matching of Components 14 4.2.1 Applicability of Existing Matching Rules 16 4.2.1.1 String Matching 16 4.2.1.2 Telephone Number Matching 18 4.2.1.3 Distinguished Name Matching 18 4.2.2 Additional Useful Matching Rules 18 4.2.2.1 The rdnMatch Matching Rule 18 4.2.2.2 The enumeratedMatch Matching Rule 19 4.2.2.3 The presentMatch Matching Rule 20 4.2.3 Summary of Useful Matching Rules 21 5. ComponentFilter 22 6. The componentFilterMatch Matching Rule 23 7. Equality Matching of Complex Components 25 7.1 The allComponentsMatch Matching Rule 25 7.2 Deriving Component Equality Matching Rules 27 7.3 The directoryComponentsMatch Matching Rule 28 8. String Encodings for Values of Arbitrary ASN.1 Types 30 9. Component Matching Examples 36 10. Security Considerations 42 11. Acknowledgements 43 12. References 43 13. Intellectual Property Notice 44 14. Copyright Notice 45 15. Author's Address 45 Legg Expires 7 November 2001 [Page 2] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 3. Introduction The structure or data type of data held in an attribute of an LDAP [RFC2251] or X.500 [X500] 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 ASN.1 [X680] 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 attributes syntaxes are usually described by ABNF [RFC2234] 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 [X680] are supported. Section 4 describes the ComponentAssertion, a testable assertion about the value of a component of an attribute value of any complex syntax. Section 5 introduces the ComponentFilter assertion, which is an expression of ComponentAssertions. The ComponentFilter enables more powerful filter matching of components in an attribute value. Section 6 defines the componentFilterMatch matching rule, which enables a ComponentFilter to be evaluated against attribute values. Section 7 defines matching rules for component-wise equality matching of values of any syntax described by an ASN.1 type definition. Legg Expires 7 November 2001 [Page 3] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 The LDAP string encodings for attribute syntaxes defined in ABNF do not clearly or consistently delineate the component parts of an attribute value. A regular and uniform string encoding for arbitrary component data types is needed for the assertion syntax of the componentFilterMatch matching rule. Section 8 defines a human readable text encoding (based on ASN.1 value notation) for an ASN.1 value of any ASN.1 type. Though primarily intended for assertion syntaxes in component matching rules, these generic string encoding rules could also be used for new attribute syntaxes, or in other domains where human readable renderings of ASN.1 values would be useful. Note that "ASN.1 value" does not mean a BER 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. Examples showing the usage of componentFilterMatch are in Section 9. For a new attribute syntax, the specifications in sections 4 to 8 of this document make it possible to fully and precisely define, the LDAP string encoding, the LDAP and X.500 binary encoding (and possibly other encodings in the future, e.g. XML via XER), 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 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. Legg Expires 7 November 2001 [Page 4] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 In the remainder of this document "type" will be taken to mean an ASN.1 type unless explicitly qualified as an attribute type, and "value" will be taken to mean an ASN.1 value unless explicitly qualified as an attribute value. 4. 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 [0] ComponentReference, useDefaultValues [1] BOOLEAN DEFAULT TRUE, rule [2] MATCHING-RULE.&id, value [3] MATCHING-RULE.&AssertionType } ComponentReference ::= UTF8String MATCHING-RULE.&id equates to the OBJECT IDENTIFIER of a matching rule. MATCHING-RULE.&AssertionType is an open type (formally 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 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. 4.1 Component Reference The component field in a ComponentAssertion is a UTF8 character string [RFC2279] whose textual content is a component reference, identifying a component part of some ASN.1 type or value. A Legg Expires 7 November 2001 [Page 5] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 component reference conforms to the following ABNF [RFC2234], which extends the notation defined in Clause 14 of [X680]: component-reference = ComponentId *( "." ComponentId ) ComponentId = identifier / from-beginning / count / from-end / ; extends Clause 14 content / ; 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" all = "*" positive-number = non-zero-digit *decimal-digit decimal-digit = %x30-39 ; "0" to "9" non-zero-digit = %x31-39 ; "1" to "9" An conforms to the definition of an identifier in ASN.1 notation (Clause 11.3 of [X680]). 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. A component reference is a sequence of one or more ComponentIds where each successive ComponentId identifies an inner component at the next level of nesting of the ASN.1 combining types, i.e. SET, SEQUENCE, SET OF, SEQUENCE OF, and CHOICE. 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. Legg Expires 7 November 2001 [Page 6] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 An empty string for a component reference, which would identify the whole ASN.1 value, is NOT supported since assertions about a whole value are already possible by the direct application of a matching rule to an attribute 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. 4.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 4.2. 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 then the component type is taken to be the type without the constraint. If the ASN.1 type is an ObjectClassFieldType (Clause 14 of [X681]) 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 4.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 [X681]) then the component type is taken to be the denoted type. Legg Expires 7 November 2001 [Page 7] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 If the ASN.1 type is a ValueSetFromObjects (Clause 15 of [X681]) then the component type is taken to be the governing type of the denoted values. 4.1.2 Referencing SET, SEQUENCE and CHOICE Components If the ASN.1 type is a SET or SEQUENCE type then the form of ComponentId MAY be used to identify the component type within that SET or SEQUENCE having that identifier. If references an OPTIONAL component type and that component is not present in a particular value then there are no corresponding component values. If 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 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 form of ComponentId MAY be used to identify the alternative type within that CHOICE having that identifier. If references an alternative other than the one used in a particular value then there are no corresponding component values. The COMPONENTS OF notation in Clause 24 of [X680] 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 [X680]), 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 [X680]. The EMBEDDED PDV type is treated as though it is the SEQUENCE type defined in Clause 32.5 of [X680]. The EXTERNAL type is treated as though it is the SEQUENCE type defined in Clause 33.5 of [X680]. Legg Expires 7 November 2001 [Page 8] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 The unrestricted CHARACTER STRING type is treated as though it is the SEQUENCE type defined in Clause 39.5 of [X680]. The INSTANCE OF type is treated as though it is the SEQUENCE type defined in Annex C of [X681]. The form MUST NOT be used on any other ASN.1 type. 4.1.3 Referencing SET OF and SEQUENCE OF Components If the ASN.1 type is a SET OF or SEQUENCE OF type then the , , and forms of ComponentId can be used. The 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 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 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, and so on. If 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 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. A ComponentId of the form MUST be the last ComponentId in a component reference. The 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 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 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. Legg Expires 7 November 2001 [Page 9] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 The corresponding ASN.1 type for the , , and forms of ComponentId is the component type of the SET OF or SEQUENCE OF type. The , , and forms MUST NOT be used on ASN.1 types other than SET OF or SEQUENCE OF. 4.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 [X683] have been substituted with the actual parameters. 4.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 } 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. Legg Expires 7 November 2001 [Page 10] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 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. 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. 4.1.6 Referencing Components of Open Types If a sequence of ComponentIds identifies an ObjectClassFieldType that denotes an open type (e.g. MATCHING-RULE.&AssertionType denotes an open type) then the ASN.1 type of the component varies. An open type is typically constrained by some other component in an outer enclosing type (e.g. in a ComponentAssertion, MATCHING- RULE.&AssertionType is constrained by the chosen matching rule) 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. When constructing a component reference, any one of the permitted types may be chosen as the implied component type, and subcomponents of that type can be identified with further ComponentIds. However note that the remainder of the component reference is potentially ambiguous in that it may also identify subcomponents of some other permitted type. If a different type is used in a particular value of the open type then the component reference may still be compatible and yield component values. If the component reference is not compatible there will be no corresponding component values. Users of ComponentAssertion SHOULD NOT rely on the component reference being compatible with only one of the permitted types in an open type. Instead the ComponentAssertion should be combined with another ComponentAssertion, on the component that constrains the open type, to verify that the open type is of the expected type. The Legg Expires 7 November 2001 [Page 11] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 method for combining ComponentAssertions is described in Section 5. 4.1.6.1 Open Type Referencing Example The ASN.1 type AttributeTypeAndValue from [X501] describes a single attribute value of a nominated attribute type. 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 (see [X680] and [X682] for the details of ASN.1 constraint notation). ATTRIBUTE.&Type denotes an open type and ({SupportedAttributes}{@type}) constrains it to be of the attribute syntax for the attribute type. The component reference "value" on AttributeTypeAndValue refers to an open type, in this case an attribute value. One of the X.500 standard attributes is facsimileTelephoneNumber [X520], which is defined to have the following syntax. FacsimileTelephoneNumber ::= SEQUENCE { telephoneNumber PrintableString (SIZE(1.. ub-telephone-number)), parameters G3FacsimileNonBasicParameters OPTIONAL } If the attribute type is facsimileTelephoneNumber, or any other attribute with the same attribute syntax, the component reference "value.telephoneNumber" on AttributeTypeAndValue is compatible, but it would also be compatible with any other attribute whose syntax is a SET, SEQUENCE or CHOICE with a component identified as "telephoneNumber". In practice there should be another ComponentAssertion on AttributeTypeAndValue with a component reference of "type" to test whether the attribute type is indeed facsimileTelephoneNumber. 4.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 Legg Expires 7 November 2001 [Page 12] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 component in the Certificate type [X509] is an OCTET STRING that is required to contain a DER 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 form of ComponentId MAY be used to identify the contained type. The handling of BIT STRINGs and OCTET STRINGs with contained types is otherwise similar to the handling of open types. The ASN.1 type of a contained value is typically constrained, possibly informally, by some other component in an outer enclosing type (e.g. in a certificate Extension, extnValue is constrained by the chosen extnId) so the actual ASN.1 type of a contained value will generally be known. When constructing a component reference, any one of the permitted contained types may be chosen as the implied contained type, and subcomponents of that type can be identified with further ComponentIds. However note that the remainder of the component reference is potentially ambiguous in that it may also identify subcomponents of some other permitted contained type. If the content of the BIT STRING or OCTET STRING is the encoding of a value of a different type then the component reference may still be compatible and yield component values. If the component reference is not compatible there will be no corresponding component values. Users of ComponentAssertion SHOULD NOT rely on the component reference being compatible with only one of the permitted contained types. Instead the ComponentAssertion should be combined with another ComponentAssertion, on the component that constrains the contents of the BIT STRING or OCTET STRING, to verify that the contained value is of the expected contained type. 4.1.7.1 Contained Type Referencing Example The ASN.1 type Extension from [X509] describes a single certificate extension value of a nominated extension type. 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 -- } Legg Expires 7 November 2001 [Page 13] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 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 varies from extension to extension. One of the X.509 standard extensions is basicConstraints, which is defined [X509] to have the following syntax. BasicConstraintsSyntax ::= SEQUENCE { cA BOOLEAN DEFAULT FALSE, pathLenConstraint INTEGER (0..MAX) OPTIONAL } If the extension identifier in an Extension value is 2.5.29.19, the component reference "extnValue.content" on Extension refers to a component type of BasicConstraintsSyntax and the component reference "extnValue.content.cA" refers to a component type of BOOLEAN. In practice there should be another ComponentAssertion on Extension with a component reference of "extnId" to test whether the extension identifier is indeed 2.5.29.19. 4.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 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 Section 4.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 an open type is encountered the actual ASN.1 type of the component value is substituted before continuing. Legg Expires 7 November 2001 [Page 14] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 If a matching rule applies to more than one attribute syntax (e.g. objectIdentifierFirstComponentMatch [X520]) then the minimum number of substitutions required to conform to any one of those syntaxes are performed. If a matching rule can apply to any attribute syntax (e.g. the allComponentsMatch rule defined in Section 7.1) 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: i) the matching rule in the ComponentAssertion is not known to the evaluating procedure, ii) if no part of the component reference identifies an open type and the matching rule is not applicable to the referenced component type, even with the additional type substitutions, iii) the value in the ComponentAssertion does not conform to the assertion syntax defined for the matching rule, iv) an open type in the tested value cannot be decoded, or v) 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). If some part of the component reference identifies an open type and the matching rule is not applicable to the referenced component type the ComponentAssertion evaluates to FALSE. Legg Expires 7 November 2001 [Page 15] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 4.2.1 Applicability of Existing Matching Rules 4.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, 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. 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. 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. It is not uncommon for ASN.1 specifications to define types that are a CHOICE between two or more alternative ASN.1 string types, where the particular alternative chosen carries no semantic significance (DirectoryString being a prime example). Such types are defined to avoid having to use a complicated character encoding for all values when most values could use a simpler string type, or to deal with evolving requirements that compel the use of a broader character set while still maintaining backward compatibility. It is convenient to also be able to use the existing character string matching rules on types that are a purely syntactic choice of string types. While there are certain ASN.1 constructs that betray the semantic Legg Expires 7 November 2001 [Page 16] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 significance of the alternatives within a CHOICE type, the absence of those constructs does not necessarily mean a CHOICE type is purely syntactic. Therefore, it is necessary for specifications to declare the purely syntactic CHOICE types so that they may be matched with the existing string matching rules. These CHOICE types will be referred to as ChoiceOfStrings types. The string matching rules above are extended to also apply to any ChoiceOfStrings type. To be eligible to be declared a ChoiceOfStrings type an ASN.1 type MUST satisfy the following conditions. i) The type is a CHOICE type. ii) The component type of each alternative is one of the following ASN.1 restricted string types: NumericString, PrintableString, TeletexString (T61String), VideotexString, IA5String, GraphicString, VisibleString (ISO646String), GeneralString, BMPString, UniversalString or UTF8String. iii) All the alternatives are of different restricted string types, i.e. no two alternatives have the same ASN.1 restricted string type. iv) Either none of the alternatives has a constraint, or all of the alternatives have exactly the same constraint. Tagging on the alternative types is ignored. Consider the ASN.1 parameterized type definition of DirectoryString. DirectoryString { INTEGER : maxSize } ::= CHOICE { teletexString TeletexString (SIZE (1..maxSize)), printableString PrintableString (SIZE (1..maxSize)), bmpString BMPString (SIZE (1..maxSize)), universalString UniversalString (SIZE (1..maxSize)), uTF8String UTF8String (SIZE (1..maxSize)) } Any use of the DirectoryString parameterized type with an actual parameter defines a ASN.1 type that satisfies the above conditions. Recognising that the alternative within a DirectoryString carries no semantic significance, this document declares (each and every use of) DirectoryString{} to be a ChoiceOfStrings type. Other specifications MAY declare other types satisfying the above conditions to be ChoiceOfStrings types. The declaration SHOULD be made at the point where the ASN.1 type is defined, otherwise it SHOULD be made at the point where it is introduced as, or in, an attribute syntax. Legg Expires 7 November 2001 [Page 17] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 4.2.1.2 Telephone Number Matching Early editions of X.520 [X520] 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, telephoneNumberMatch and telephoneNumberSubstringsMatch are permitted to be applied to any PrintableString value, as well as to TelephoneNumber values. 4.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. 4.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 [RFC2251]. 4.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 RDNs in a 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 string encoding for a value of the RDN syntax is given by in Section 8. The X.500-style definition for rdnMatch is: rdnMatch MATCHING-RULE ::= { Legg Expires 7 November 2001 [Page 18] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 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. When using rdnMatch to match components of DNs it is important to note that the LDAP string encoding of a DN [RFC2253] 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". 4.2.2.2 The enumeratedMatch Matching Rule There is no existing matching rule that could be used to match a value of an arbitrary ENUMERATED type. The enumeratedMatch matching rule is defined to fill this role. It may be applied to values of any ENUMERATED type, or any INTEGER type (typically those with a named number list). The LDAP-style definitions for enumeratedMatch and its assertion syntax are: ( 1.2.36.79672281.1.13.4 NAME 'enumeratedMatch' SYNTAX 1.2.36.79672281.1.5.3 ) ( 1.2.36.79672281.1.5.3 DESC 'OpenAssertionType' ) This matching rule has 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 string 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. In general, the LDAP string encoding for the OpenAssertionType syntax is described by in Section 8. Since enumeratedMatch only applies to values of an ENUMERATED or INTEGER type, assertion values for enumeratedMatch are constrained to the string encoding given by or respectively, in Section 8. Legg Expires 7 November 2001 [Page 19] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 The X.500-style definition for enumeratedMatch is: enumeratedMatch MATCHING-RULE ::= { ID { 1 2 36 79672281 1 13 4 } } The enumeratedMatch rule evaluates to true if the component value and assertion value are the same. The enumeratedMatch rule MAY be used as the equality matching rule for an attribute. 4.2.2.3 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 string encoding for a value of the NULL syntax is given by in Section 8. 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 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 Legg Expires 7 November 2001 [Page 20] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 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. 4.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 within Section 4.2.1, and the new matching rules defined in Section 4.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 | +--------------------------------+------------------------------+ | enumeratedMatch | ENUMERATED | | | INTEGER | +--------------------------------+------------------------------+ | generalizedTimeMatch | GeneralizedTime | | generalizedTimeOrderingMatch | | +--------------------------------+------------------------------+ | integerMatch | INTEGER | | integerOrderingMatch | | Legg Expires 7 November 2001 [Page 21] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 +--------------------------------+------------------------------+ | numericStringMatch | NumericString | | numericStringOrderingMatch | | | numericStringSubstringsMatch | | +--------------------------------+------------------------------+ | objectIdentifierMatch | OBJECT IDENTIFIER | +--------------------------------+------------------------------+ | octetStringMatch | OCTET STRING | | octetStringOrderingMatch | | | octetStringSubstringsMatch | | +--------------------------------+------------------------------+ | presentMatch | any ASN.1 type | +--------------------------------+------------------------------+ | rdnMatch | RelativeDistinguishedName | +--------------------------------+------------------------------+ | telephoneNumberMatch | PrintableString | | telephoneNumberSubstringsMatch | TelephoneNumber | +--------------------------------+------------------------------+ | uTCTimeMatch | UTCTime | | uTCTimeOrderingMatch | | +--------------------------------+------------------------------+ 5. 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. Legg Expires 7 November 2001 [Page 22] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 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. 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. 6. 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 string encoding of a ComponentAssertion is defined by the following ABNF: ComponentAssertion = "{" sp component "," [ sp useDefaultValues "," ] sp rule "," sp assertion-value sp "}" component = component-label msp dquote component-reference dquote useDefaultValues = use-defaults-label msp BooleanValue rule = rule-label msp MatchingRuleId 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.65.73 Legg Expires 7 November 2001 [Page 23] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 ; "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 dquote = %x22 ; " (double quote) The matching rule in a ComponentAssertion is described by , which is defined in [RFC2251]. The ABNF for and is defined in Section 8. The LDAP string encoding of a ComponentFilter is defined by the following 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 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 "}" Note that the string encodings of ComponentAssertion and ComponentFilter conform to the generic string encodings defined in Section 8 (in the event that there is a discrepancy between the above ABNF and Section 8, Section 8 is to be taken as definitive). The X.500-style definition [X501] 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 the component corresponding to the containing ComponentAssertion. In Section 9, an example search on the seeAlso attribute shows this usage. Legg Expires 7 November 2001 [Page 24] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 7. 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 7.1, and the means to derive new matching rules from it with slightly different equality matching semantics is described in Section 7.2. The directoryComponentsMatch defined in Section 7.3 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. 7.1 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 Legg Expires 7 November 2001 [Page 25] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 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, i) both absent, ii) both present and the same, or iii) absent or the same as the DEFAULT value for the component, if a DEFAULT value is defined. Values of a REAL, EMBEDDED PDV, EXTERNAL, unrestricted CHARACTER STRING, or INSTANCE OF type are compared according to their respective SEQUENCE type (see Section 4.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. 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, Legg Expires 7 November 2001 [Page 26] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 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. 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 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. 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. 7.2 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, an 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 Expires 7 November 2001 [Page 27] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 | 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 4.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. 7.3 The directoryComponentsMatch Matching Rule The directoryComponentsMatch matching rule is derived from the allComponentsMatch matching rule. Legg Expires 7 November 2001 [Page 28] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 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 7.2. ASN.1 Type | Matching Rule =========================================+========================= RDNSequence | distinguishedNameMatch RelativeDistinguishedName | rdnMatch TelephoneNumber | telephoneNumberMatch FacsimileTelephoneNumber.telephoneNumber | telephoneNumberMatch PresentationAddress | presentationAddressMatch 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 [X520] is defined as a constrained PrintableString. PrintableString component values that are part of a Legg Expires 7 November 2001 [Page 29] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 FacsimileTelephoneNumber value can be identified separately from 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. 8. String Encodings for Values of Arbitrary ASN.1 Types This section defines a human readable UTF8 string encoding for an ASN.1 value of any given ASN.1 type. The primary use of this encoding method is for the string encoding of assertion values appearing in ComponentAssertions, however the encoding method can also be nominated to define the string encoding for new attribute syntaxes. The string encodings are based on ASN.1 value notation [X680], with changes to accommodate the notation's use as a transfer syntax, and to support well established ad-hoc string encodings for directory data types. Referencing this section is sufficient to define the string encoding of values of a specific ASN.1 type, though other specifications may wish to provide a condensed, customized version of the ABNF as a convenience for the implementor (for example, as has been done for ComponentAssertion and ComponentFilter in Section 6). Such a specification SHOULD state that if there is a discrepancy between the customized ABNF and the encoding defined in this section, that the encoding described by this section takes precedence. The string encoding of a value of any ASN.1 type is described by the following ABNF: Value = BitStringValue / BooleanValue / ChoiceValue / EmbeddedPDVValue / EnumeratedValue / ExternalValue / GeneralizedTimeValue / IntegerValue / InstanceOfValue / Legg Expires 7 November 2001 [Page 30] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 NullValue / ObjectDescriptorValue / ObjectIdentifierValue / OctetStringValue / RealValue / SequenceOfValue / SequenceValue / SetOfValue / SetValue / StringValue / UTCTimeValue / VariantEncoding A value of a type with a defined type name is encoded according to the type definition on the right hand side of the type assignment for the type name. A value of a type denoted by the use of a parameterized type with actual parameters is encoded according to the parameterized type with the DummyReferences substituted with the actual parameters. A value of a tagged or constrained type is encoded as a value of the type without the tag or constraint, respectively. Tags do not appear in the string encodings defined by this document. A value of an open type denoted by an ObjectClassFieldType is encoded according to the specific type of the value. A value of a fixed type denoted by an ObjectClassFieldType is encoded according to that fixed type. A value of a selection type is encoded according to the type referenced by the selection type. A value of a type described by TypeFromObject notation is encoded according to the denoted type. A value of a type described by ValueSetFromObjects notation is encoded according to the governing type. ASN.1 identifiers figure prominently in the string encodings. The ABNF for an identifier was first given in Section 4.1 but is repeated here for convenience. The case of letters in an identifier is always significant. identifier = lowercase *alphanumeric *(hyphen 1*alphanumeric) alphanumeric = uppercase / lowercase / decimal-digit uppercase = %x41-5A ; "A" to "Z" Legg Expires 7 November 2001 [Page 31] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 lowercase = %x61-7A ; "a" to "z" decimal-digit = %x30-39 ; "0" to "9" hyphen = "-" A value of the BIT STRING type is encoded according to the rule. If the definition of the BIT STRING type includes a named bit list, the form of rule MAY be used. If the number of bits in a BIT STRING value is a multiple of four the form of MAY be used. The form of is used otherwise. BitStringValue = bstring / hstring / bit-list The rule encodes the one bits in the bit string value as a comma separated list of identifiers. Each MUST be one of those in the named bit list. An MUST NOT appear more than once in the same . The rule encodes each bit as the character "0" or "1" in order from the first bit to the last bit. The rule encodes each group of four bits as a hexadecimal number where the first bit is the most significant. An odd number of hexadecimal digits is permitted. bit-list = "{" [ sp identifier *( "," sp identifier) ] sp "}" hstring = squote *hexadecimal-digit squote %x48 ; '...'H hexadecimal-digit = %x30-39 / ; "0" to "9" %x41-46 ; "A" to "F" bstring = squote *binary-digit squote %x42 ; '...'B binary-digit = "0" / "1" sp = *%x20 ; zero, one or more space characters squote = %x27 ; ' (single quote) A value of the BOOLEAN type is encoded according to the rule. BooleanValue = %x54.52.55.45 / ; "TRUE" %x46.41.4C.53.45 ; "FALSE" A value of the INTEGER type is encoded according to the rule. If the definition of the INTEGER type includes a named number list, the form of MAY be used, in which case the MUST be one of those in the named number list. IntegerValue = "0" / positive-number / Legg Expires 7 November 2001 [Page 32] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 ("-" positive-number) / identifier positive-number = non-zero-digit *decimal-digit non-zero-digit = %x31-39 ; "1" to "9" A value of the ENUMERATED type is encoded according to the rule. The MUST be one of those in the list of enumerations in the definition of the ENUMERATED type. EnumeratedValue = identifier A value of the NULL type is encoded according to the rule. NullValue = %x4E.55.4C.4C ; "NULL" An OBJECT IDENTIFIER value is encoded using the string representation described by the rule in [RFC2252]. ObjectIdentifierValue = oid The rule allows either a dotted decimal representation of the OBJECT IDENTIFIER value or an object descriptor name, i.e. . An object descriptor name is potentially ambiguous and should be used with care. A value of the OCTET STRING type is encoded according to the rule. The octets are encoded in order from the first octet to the last octet. Each octet is encoded as a pair of hexadecimal digits where the first digit corresponds to the four most significant bits of the octet. If the hexadecimal string does not have an even number of digits the four least significant bits in the last octet are assumed to be zero. OctetStringValue = hstring The contents of a string value are encoded as a UTF8 character string between double quotes. Depending on the ASN.1 string type, and an application's internal representation of that string type, a translation to or from the UTF8 character encoding may be required. NumericString, PrintableString, IA5String, VisibleString (ISO646String) are compatible with UTF8 and do not require any translation. BMPString (UCS-2) and UniversalString (UCS-4) have a direct mapping to and from UTF8 [RFC2279]. For the remaining string types see [X680]. Any embedded double quotes in the resulting UTF8 character string are escaped by repeating the double quotes character. Legg Expires 7 November 2001 [Page 33] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 StringValue = dquote *SafeUTF8Character dquote dquote = %x22 ; " (double quote) SafeUTF8Character = %x01-21 / %x23-7F / ; ASCII minus dquote dquote dquote / ; escaped double quote %xCO-DF %x80-BF / ; 2 byte UTF8 character %xEO-EF 2(%x80-BF) / ; 3 byte UTF8 character %xFO-F7 3(%x80-BF) / ; 4 byte UTF8 character %xF8-FB 4(%x80-BF) / ; 5 byte UTF8 character %xFC-FD 5(%x80-BF) ; 6 byte UTF8 character A value of the GeneralizedTime type, UTCTime type or ObjectDescriptor type is encoded as a string value. GeneralizedTime and UTCTime use the VisibleString character set so the conversion to UTF8 is trivial. ObjectDescriptor uses the GraphicString type. GeneralizedTimeValue = StringValue UTCTimeValue = StringValue ObjectDescriptorValue = StringValue A value of a CHOICE type is encoded according to the rule. The encoding MAY be used if the corresponding CHOICE type has been declared a ChoiceOfStrings type. This document declares DirectoryString to be a ChoiceOfStrings type (see Section 4.2.1.1). The form of is used otherwise. ChoiceValue = IdentifiedChoiceValue / ChoiceOfStringsValue IdentifiedChoiceValue = identifier ":" Value ChoiceOfStringsValue = StringValue For implementations that recognise the internal structure of the DirectoryString CHOICE type (e.g. X.500 directories), if the character string between the quotes in a contains only characters that are permitted in a PrintableString the DirectoryString is assumed to use the printableString alternative, otherwise it is assumed to use the uTF8String alternative. The rule MAY be used for a value of type DirectoryString to indicate a different alternative to the one that would otherwise be assumed from the string contents. No matter what alternative is chosen, the will still be a UTF8 encoded character string, however it is a syntax error if the characters in the UTF8 string cannot be represented in the string type of the chosen alternative. Legg Expires 7 November 2001 [Page 34] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 Implementations that don't care about the internal structure of a DirectoryString value MUST be able to parse the form for a DirectoryString value, though the particular identifier found will be of no interest. A value of a SEQUENCE type is encoded according to the rule. The rule encodes a comma separated list of the particular component values present in the SEQUENCE value, where each component value is preceded by the corresponding identifier from the SEQUENCE type definition. The components are encoded in the order of their definition in the SEQUENCE type. SequenceValue = ComponentList ComponentList = "{" [ sp NamedValue *( "," sp NamedValue) ] sp "}" NamedValue = identifier msp Value msp = 1*%x20 ; one or more space characters A value of a SET type is encoded according to the rule. The components are encoded in the order of their definition in the SET type (i.e. just like a SEQUENCE value). This is a deliberate departure from ASN.1 value notation where the components of a SET can be written in any order. SetValue = ComponentList SEQUENCE and SET type definitions are sometimes extended by the inclusion of additional component types, so an implementation SHOULD be capable of skipping over any encoding with an identifier that is not recognised, on the assumption that the sender is using a more recent definition of the SEQUENCE or SET type. A value of a SEQUENCE OF type is encoded according to the rule, as a comma separated list of the instances in the value. Each instance is encoded according to the component type of the SEQUENCE OF type. SequenceOfValue = "{" [ sp Value *( "," sp Value) ] sp "}" A value of a SET OF type is encoded according to the rule, as a list of the instances in the value. Each instance is encoded according to the component type of the SET OF type. SetOfValue = "{" [ sp Value *( "," sp Value) ] sp "}" A value of an EMBEDDED PDV, EXTERNAL, unrestricted CHARACTER STRING, or INSTANCE OF type is encoded according to the corresponding Legg Expires 7 November 2001 [Page 35] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 SEQUENCE type (see Section 4.1.2). EmbeddedPDVValue = SequenceValue ExternalValue = SequenceValue InstanceOfValue = SequenceValue A value of the REAL type is encoded as "0" if it is zero, or as the corresponding SEQUENCE type otherwise (see Section 4.1.2). RealValue = "0" / ; zero REAL value SequenceValue ; non-zero REAL value The values of some named complex ASN.1 types have special string encodings. These special encodings are always used instead of the encoding that would otherwise apply based on the type definition. VariantEncoding = RDNSequenceValue / RelativeDistinguishedNameValue / ORAddressValue A value of the RDNSequence type, i.e. a distinguished name, is encoded according to the rule, as a quoted LDAPDN character string. The character string is first derived according to the rule in Section 3 of [RFC2253], and then it is encoded as if it were a UTF8String value, i.e. between double quotes with any embedded double quotes escaped by being repeated. RDNSequenceValue = StringValue A RelativeDistinguishedName value that is not part of an RDNSequence value is encoded according to the rule as a quoted character string. The character string is first derived according to the rule in Section 3 of [RFC2253], and then it is encoded as if it were a UTF8String value. RelativeDistinguishedNameValue = StringValue A value of the ORAddress type is encoded according to the rule as a quoted character string. The character string is first derived according to the textual representation of MTS.ORAddress from [RFC2156], and then it is encoded as if it were an IA5String value. ORAddressValue = StringValue 9. Component Matching Examples Legg Expires 7 November 2001 [Page 36] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 This section contains examples of search filters using the componentFilterMatch matching rule. The filters are described using the string representation of LDAP search filters from [RFC2254]. Additional line breaks and indenting have been added only as an aid to readability. The example search filters 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 [X501], 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 } 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 Legg Expires 7 November 2001 [Page 37] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 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. (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" } }) Legg Expires 7 November 2001 [Page 38] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 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 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 following search filter finds object class definitions for auxiliary object classes. (objectClasses:componentFilterMatch:= item:{ component "information.kind", rule enumeratedMatch, value auxiliary }) The following search filter finds auxiliary object classes with Legg Expires 7 November 2001 [Page 39] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 commonName (cn or 2.5.4.3) as a mandatory attribute: (objectClasses:componentFilterMatch:=and:{ item:{ component "information.kind", rule enumeratedMatch, 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 enumeratedMatch, 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 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 { Legg Expires 7 November 2001 [Page 40] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 dn DistinguishedName, uid UniqueIdentifier OPTIONAL } The following search filter finds values of the uniqueMember attribute containing the author's DN: (uniqueMember:componentFilterMatch:={ 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 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 Legg Expires 7 November 2001 [Page 41] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 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 } } }) 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 AttributeTypeAndValue of any RDN: (seeAlso:componentFilterMatch:= item:{ component "*.*.value", rule caseIgnoreSubstringsMatch, value { any:"Adacel" } }) The component reference "*.*.value" identifies an open type. If the actual ASN.1 type of a value of this component is not compatible with the caseIgnoreSubstringsMatch then the ComponentAssertion evaluates to FALSE. Otherwise the substring assertion is evaluated against the component value. 10. 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. Legg Expires 7 November 2001 [Page 42] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 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. The generic string encodings in Section 8 do not necessarily enable the exact octet encoding of values of TeletexString, VideotexString, GraphicString or GeneralString to be reconstructed, so a transformation from DER to generic string encoding and back to DER may not reproduce the original DER encoding. This has consequences for the verification of digital signatures. 11. Acknowledgements The author would like to thank Tom Gindin for private email discussions that clarified and refined the ideas presented in this document. 12. References [BCP-11] - R. Hovey, S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [RFC2119] - S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119. [RFC2156] - S. Kille, "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998. [RFC2234] - D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC2251] - M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [RFC2252] - M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [RFC2253] M. Wahl, S. Kille, T. Howes. "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", Legg Expires 7 November 2001 [Page 43] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 RFC2253, December 1997. [RFC2254] - T. Howes, "The String Representation of LDAP Search Filters", RFC 2254, December 1997. [RFC2279] - F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [X500] - ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, Information Technology - Open Systems Interconnection - The Directory: Overview of concepts, models and services [X501] - ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994, Information Technology - Open Systems Interconnection - The Directory: Models [X509] - ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1998, Information Technology - Open Systems Interconnection - The Directory: Authentication Framework [X520] - ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994, Information Technology - Open Systems Interconnection - The Directory: Selected attribute types [X680] - ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998 Information Technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation [X681] - ITU-T Recommendation X.681 (1997) | ISO/IEC 8824-2:1998 Information Technology - Abstract Syntax Notation One (ASN.1): Information object specification [X682] - ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998 Information Technology - Abstract Syntax Notation One (ASN.1): Constraint specification [X683] - ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998 Information Technology - Abstract Syntax Notation One (ASN.1): Parameterization of ASN.1 specifications 13. Intellectual Property Notice 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 Legg Expires 7 November 2001 [Page 44] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 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. [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. 14. Copyright Notice Copyright (C) The Internet Society (2001). 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 assigns. 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. 15. Author's Address Steven Legg Legg Expires 7 November 2001 [Page 45] INTERNET-DRAFT LDAP & X.500 Component Matching Rules May 7, 2001 Adacel Technologies Ltd. 250 Bay Street Brighton, Victoria 3186 AUSTRALIA Phone: +61 3 8530 7808 Fax: +61 3 9596 2960 EMail: steven.legg@adacel.com.au 12. Appendix A - Changes From Previous Drafts 12.1 Changes in Draft 01 Section 4.1.7 was added to enable component matching of values embedded in encoded form into BIT STRINGS or OCTET STRINGS. In particular, this is to allow component matching of values in Certificate extensions. The production was added in Section 4.1 to allow the OCTET STRING contents to be treated as either raw octets or as an embedded value. References to a companion document summarizing the ASN.1 types of LDAP syntaxes were removed to avoid holding up this document. The OpenType syntax was renamed to OpenAssertionType. Object identifiers for the new syntax and matching rule definitions have been allocated from an arc belonging to Adacel Technologies Ltd. Legg Expires 7 November 2001 [Page 46]