Lightweight Directory Access Protocol (LDAP) and X.500 Component Matching Rules
Extracted elements (28)
allComponentsMatch is defined as a basic rule with a separate derivation mechanism (Section 6.3) because no single equality rule satisfies all contexts: for example, case-sensitive vs. case-insensitive string comparison may both be appropriate depending on the application. Derived rules such as directoryComponentsMatch override specific component types.
Component matching operates at the abstract ASN.1 value level, independent of any particular encoding such as BER. This allows the matching rules to apply consistently regardless of which on-wire encoding (BER, DER, GSER, etc.) is used to store or transfer attribute values.
ComponentFilter uses SEQUENCE OF (not SET OF) for the 'and' and 'or' alternatives, but ordering is explicitly stated to be not significant. This choice follows X.500 convention while noting the semantic irrelevance of order, avoiding the need for a SET OF type that would complicate encoding.
Rather than defining separate string matching rules for each ASN.1 restricted character string type, the existing caseIgnoreMatch and caseExactMatch families are extended to apply to all restricted character string types and ChoiceOfStrings types. This avoids a proliferation of per-type rules while maintaining a single DirectoryString assertion syntax.
The component matching framework is designed so that an ASN.1 type definition alone is sufficient to fully specify LDAP encoding (via GSER), binary encoding, an equality matching rule, and all component matching capabilities for a new attribute syntax. This enables automatic code generation from ASN.1 definitions.
Attribute syntaxes defined only with a character string encoding (no explicit or implied 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 provided for them.
distinguishedNameMatch is also permitted to be applied to values of the RDNSequence type (not just DistinguishedName, which is defined by assignment from RDNSequence), because some type definitions directly reference RDNSequence. Similarly, telephoneNumberMatch applies to any PrintableString, not just TelephoneNumber.
REAL, EMBEDDED PDV, EXTERNAL, and unrestricted CHARACTER STRING ASN.1 types are treated as equivalent SEQUENCE types for component referencing (as defined in X.680 and X.690). The INSTANCE OF type is similarly treated as the SEQUENCE type from X.681 Annex C.
The LDAP string representation of a DN reverses the order of RDNs relative to X.500 order. Consequently, in a DistinguishedName value the RDN "cn=Steven Legg" in the DN "cn=Steven Legg,o=Adacel,c=AU" corresponds to component reference "3" (from-beginning) or "-1" (from-end), not "1".
The string matching rules' assertion syntax remains DirectoryString regardless of the component's actual string type. An implementation must compare a DirectoryString assertion to a restricted character string component value; if corresponding characters are not representable in both character sets, matching returns FALSE.
A ComponentAssertion is Undefined if: (a) the matching rule is unknown; (b) the rule is not applicable to the referenced component type even after type substitutions; (c) the assertion value does not conform to the rule's assertion syntax; (d) an open type in the value cannot be decoded; or (e) the implementation does not support the combination.
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. An absent SET OF value is distinct from an empty one.
In the event of a discrepancy between the convenience ABNF provided for ComponentFilter GSER encoding and the encoding determined by applying GSER rules directly, GSER is to be taken as definitive.
OpenAssertionType MUST NOT be used as the attribute syntax in an attribute type definition; it is reserved solely as the LDAP MatchingRuleDescription SYNTAX placeholder for component equality matching rules whose actual assertion syntax varies by usage.
The <count> form of ComponentId, when present in a component reference for a SET OF or SEQUENCE OF type, MUST be the last ComponentId in that component reference.
The <identifier> form of ComponentId MUST NOT be used on any ASN.1 type other than SET, SEQUENCE, or CHOICE. Similarly, the <from-beginning>, <count>, <from-end> and <all> forms MUST NOT be used on ASN.1 types other than SET OF or SEQUENCE OF.
allComponentsMatch (OID 1.2.36.79672281.1.13.6) performs component-wise equality matching for any ASN.1 type, including SET, SEQUENCE, SET OF, SEQUENCE OF, CHOICE, BIT STRING, string types, INTEGER, BOOLEAN, OBJECT IDENTIFIER, OCTET STRING, REAL, RELATIVE-OID, and open types. It uses case-sensitive string comparison and treats trailing zero bits in named-bit BIT STRINGs as absent.
ComponentAssertion is an ASN.1 SEQUENCE with four fields: an optional component reference (UTF8String), a useDefaultValues BOOLEAN defaulting TRUE, a matching rule OID (rule), and an assertion value. It evaluates to TRUE, FALSE, or Undefined for each tested ASN.1 value.
ComponentFilter is an ASN.1 CHOICE of: item (a ComponentAssertion), and (SEQUENCE OF ComponentFilter), or (SEQUENCE OF ComponentFilter), and not (ComponentFilter). It evaluates to TRUE, FALSE, or Undefined using three-valued logic; order within and/or is not significant.
componentFilterMatch (OID 1.2.36.79672281.1.13.2) is the primary matching rule defined by this document. It applies a ComponentFilter assertion to an attribute value and returns the result of evaluating the ComponentFilter. Its LDAP assertion syntax is ComponentFilter encoded via GSER.
ComponentReference is a UTF-8 string conforming to an ABNF grammar that navigates ASN.1 type structure via dot-separated ComponentIds. ComponentId forms include identifier (named field), from-beginning (positive integer), count ("0"), from-end (negative integer), content, select (open type selector), and all ("*").
directoryComponentsMatch (OID 1.2.36.79672281.1.13.7) is derived from allComponentsMatch with overrides for directory-specific types: RDNSequence uses distinguishedNameMatch, RelativeDistinguishedName uses rdnMatch, TelephoneNumber uses telephoneNumberMatch, all string types use caseIgnoreMatch, GeneralizedTime uses generalizedTimeMatch, and UTCTime uses uTCTimeMatch.
OpenAssertionType (OID 1.2.36.79672281.1.5.3) is a placeholder LDAP syntax semantically equivalent to an omitted SYNTAX field in an X.500 MATCHING-RULE; it signals that the assertion syntax is determined at use time by the target attribute's syntax. It MUST NOT be used as an attribute syntax.
presentMatch (OID 1.2.36.79672281.1.13.5) evaluates to TRUE if and only if the component reference identifies one or more component values, regardless of their content. Its assertion syntax is NULL. When used in an extensibleMatch filter it behaves like the "present" filter case.
rdnMatch (OID 1.2.36.79672281.1.13.3) is a new matching rule that evaluates to TRUE if a component value and assertion value are the same RelativeDistinguishedName, using the same comparison method as distinguishedNameMatch. Its assertion syntax is the RDN syntax (OID 1.2.36.79672281.1.5.0).
This document registers five new descriptors in the IANA LDAP Descriptors registry: componentFilterMatch (1.2.36.79672281.1.13.2), rdnMatch (1.2.36.79672281.1.13.3), presentMatch (1.2.36.79672281.1.13.5), allComponentsMatch (1.2.36.79672281.1.13.6), and directoryComponentsMatch (1.2.36.79672281.1.13.7), all as matching rules.
Component matching rules are applicable to any attribute syntax, so their support in a directory server may allow searching of attributes that were previously unsearchable due to a lack of applicable matching rules. Such attribute types ought to be protected with appropriate access controls. The document notes that a generic interoperable access control mechanism for LDAP/X.500 had not yet been developed at time of publication.
The ComponentFilter assertion syntax is encoded for LDAP using GSER (Generic String Encoding Rules). The document provides an equivalent ABNF for implementors: a ComponentFilter is one of filter-item ("item:" + ComponentAssertion), and-filter ("and:" + SequenceOfComponentFilter), or-filter ("or:"), or not-filter ("not:"). ComponentAssertion fields use labels "component", "useDefaultValues", "rule", and "value".