ietf-corpus

rfc-4515

Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters

M. Smith (Editor), T. Howes
date2006-06 streamIETF areaapp wgldapbis statusPROPOSED STANDARD pages12 canonicalhttps://www.rfc-editor.org/rfc/rfc4515 doi10.17487/RFC4515 errataview
Lightweight Directory Access Protocol (LDAP) search filters are transmitted in the LDAP protocol using a binary representation that is appropriate for use on the network. This document defines a human-readable string representation of LDAP search filters that is appropriate for use in LDAP URLs (RFC 4516) and in other applications. [STANDARDS-TRACK]

obsoletes

Extracted elements (15)

design-rationale §3

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.

ldap

design-rationale §3

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.

ldap

design-rationale §A.1

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.

ldap

interoperability-note §3

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.

ldap

normative-requirement §3 MUST

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.

ldap

normative-requirement §3 SHOULD

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, security

protocol-element §2

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

protocol-element §3

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.

ldap

protocol-element §3

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.

ldap

protocol-element §2

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.

ldap

protocol-element §3

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.

ldap

security-consideration §5

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.

ldap, security

wire-format §4

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'.

ldap

wire-format §3

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 '*').

ldap

wire-format §3

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.

ldap