Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters
obsoletes
- rfc-2254 — The String Representation of LDAP Search Filters
Extracted elements (15)
Although both the substring and present grammar productions can generate 'attr=*', this construct is reserved exclusively as a presence filter. This disambiguation rule is stated explicitly to clarify the grammar's intent.
The escaping mechanism using backslash followed by two hex digits was chosen because it eliminates filter-parsing ambiguities and allows any LDAP filter to be represented as a NUL-terminated string. Other octets in the normal set may also use this mechanism, e.g., for non-printing ASCII characters.
The valueencoding rule was introduced (replacing the less precise 'value' rule from RFC 2254) to reduce dependence on descriptive text, with the 'normal' production explicitly restricting filter strings to valid UTF-8 sequences. This was a technical change from RFC 2254.
RFC 2254 did not clearly define 'string representation' and did not state that it must be UTF-8-encoded Unicode. Implementations must accept non-valid UTF-8 input strings for backward compatibility with RFC 2254-era software.
Implementations MUST escape all octets greater than 0x7F that are not part of a valid UTF-8 encoding sequence when generating a string representation of a search filter.
Implementations SHOULD accept as input strings that are not valid UTF-8 strings. This is necessary because RFC 2254 did not clearly define the term 'string representation' and did not specify that the string representation must be UTF-8-encoded Unicode characters.
LDAP search filter ASN.1 definition from RFC 4511: Filter is a CHOICE of and [0], or [1], not [2], equalityMatch [3], substrings [4], greaterOrEqual [5], lessOrEqual [6], present [7], approxMatch [8], extensibleMatch [9]. The Filter is BER-encoded for network transmission.
LDAP search filters are represented as a UTF-8 encoded Unicode string using prefix notation with parenthesized expressions. The grammar supports and (&), or (|), not (!), equality, substring, presence, approximate match, greater-or-equal, less-or-equal, and extensible match filter types.
The extensible match filter has two forms: (attr [dnattrs] [matchingrule] := assertionvalue) or ([dnattrs] matchingrule := assertionvalue). The dnattrs (':dn') component indicates that DN attributes should be considered part of the entry when evaluating the match.
The MatchingRuleAssertion contains optional matchingRule [1] (MatchingRuleId), optional type [2] (AttributeDescription), required matchValue [3] (AssertionValue), and dnAttributes [4] (BOOLEAN, DEFAULT FALSE). When attr is omitted, the matching rule applies to any attribute that supports it.
The substring filter uses the grammar: substring = attr EQUALS [initial] any [final], where any = ASTERISK *(assertionvalue ASTERISK). The presence filter uses 'attr=*', which is grammatically produced by the present production, not the substring production.
The string representation of LDAP search filters itself has no known security implications, but LDAP search filters do, as they are interpreted by LDAP servers to select entries from which data is retrieved. LDAP servers should protect maintained data from unauthorized access. Implementers are referred to RFC 4511 and RFC 4513 security considerations.
For AssertionValues containing UTF-8 character data, each octet of a character to be escaped is replaced by a backslash and two hex digits representing that single octet. For example, the UTF-8 encoding of 'Lučić' (U+004C U+0075 U+010D U+0069 U+0107) is represented as 'Lu\c4\8di\c4\87'.
The filter string grammar is defined in ABNF: filter = LPAREN filtercomp RPAREN, with filtercomp being and/or/not/item. Special characters '*' (0x2A), '(' (0x28), ')' (0x29), '\' (0x5C), and NUL (0x00) must be encoded as backslash followed by two hexadecimal digits (e.g., \2a for '*').
The valueencoding rule defines assertion value encoding: normal = UTF1SUBSET / UTFMB; escaped = ESC HEX HEX. UTF1SUBSET covers %x01-27 / %x2B-5B / %x5D-7F, explicitly excluding NUL, LPAREN, RPAREN, ASTERISK, and ESC.