Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions
obsoleted by
- rfc-4510 — Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map
- rfc-4512 — Lightweight Directory Access Protocol (LDAP): Directory Information Models
- rfc-4517 — Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules
- rfc-4523 — Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates
updated by
- rfc-3377 — Lightweight Directory Access Protocol (v3): Technical Specification
Extracted elements (29)
The definition of additional arbitrary syntaxes beyond those listed is strongly deprecated because today's client and server implementations generally cannot dynamically recognize new syntaxes, which hinders interoperability. In most cases, attributes should be defined with the Directory String syntax.
UTC Time (OID 1.3.6.1.4.1.1466.115.121.1.53) is described as historical; new attribute definitions SHOULD use GeneralizedTime instead, implicitly because UTCTime uses a two-digit year and does not unambiguously represent dates beyond 1999.
The IESG warns that until mandatory authentication mechanisms for LDAPv3 are standardized, clients and servers using update functionality are UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL. Implementors are discouraged from deploying update-capable LDAPv3 servers until a mandatory authentication standard is published as an RFC.
The syntax field in AttributeTypeDescription must be a string representation of an OID for the LDAP string syntax definition, plus an optional maximum length indicator in curly braces (e.g., '1.3.6.4.1.1466.0{64}'). The bound is a suggestion to implementations and is not part of the syntax name itself.
All servers MUST implement binary encoding for both generating attribute values in search responses and parsing attribute values in add, compare, and modify requests when the attribute type is recognized and has Binary syntax. Clients requesting all attributes MUST be prepared to receive binary values and SHOULD NOT display unrecognized binary values to users.
Certificate (OID .8), Certificate List (OID .9), and Certificate Pair (OID .10) syntax values MUST only be transferred using binary encoding, by requesting or returning attributes with descriptions such as 'userCertificate;binary'. The RFC 1778 BNF notation for these syntaxes is not recommended.
Servers and clients MUST be prepared to receive encodings of arbitrary Unicode characters in Directory String syntax, including characters not presently assigned to any character set. Servers MUST NOT reject values merely because they contain legal Unicode characters outside the range of printable ASCII.
Servers MUST implement all the attribute types referenced in sections 5.1, 5.2 and 5.3. Servers that recognize additional attribute types MUST publish their definitions in the subschema attributeTypes attribute.
Servers SHOULD provide at least one of the 'SUP' and 'SYNTAX' fields for each AttributeTypeDescription. Schema developers MUST NOT create attribute definitions whose names conflict with attributes defined for use with LDAP in existing standards-track RFCs.
Servers which allow subschema entries to be modified by clients MUST support integerFirstComponentMatch (2.5.13.29) and objectIdentifierFirstComponentMatch (2.5.13.30), as these are the equality matching rules for several subschema attributes. The assertion syntax of these rules differs from the value syntax of the attributes they serve.
Servers which support matching rules and the extensibleMatch SHOULD implement all matching rules defined in section 8. Privately-defined matching rules MUST be published in the subschema matchingRules attribute; if extensibleMatch is supported, applicability to attributes MUST be published in matchingRuleUse.
When encoding OID elements in attribute values, the descriptor (descr) form SHOULD be used in preference to the numeric OID form, as object descriptors are more human-readable. Where assigned and known by the implementation, descriptors SHOULD be used to the greatest extent possible.
AttributeTypeDescription is encoded as a BNF string containing: a numeric OID, optional NAME, DESC, OBSOLETE, SUP, EQUALITY, ORDERING, SUBSTR, SYNTAX (with optional length bound), SINGLE-VALUE, COLLECTIVE, NO-USER-MODIFICATION, and USAGE fields. Terms beginning with 'X-' are reserved for private experiments and MUST be followed by a qdstrings value.
LDAP DSA operational attributes in the root DSE include: namingContexts (1.3.6.1.4.1.1466.101.120.5), altServer (.6), supportedExtension (.7), supportedControl (.13), supportedSASLMechanisms (.14), and supportedLDAPVersion (.15). Servers MUST recognize these names but are not required to provide values for unimplemented features.
MatchingRuleDescription is encoded with a numeric OID, optional NAME, DESC, OBSOLETE, and a required SYNTAX field. MatchingRuleUseDescription associates matching rules with applicable attribute types via an APPLIES field listing attribute type OIDs.
ObjectClassDescription is encoded as a BNF string with a numeric OID, optional NAME, DESC, OBSOLETE, SUP (superior classes), type keyword (ABSTRACT/STRUCTURAL/AUXILIARY, default structural), and MUST/MAY attribute lists. Servers SHOULD implement all object classes in section 7 except extensibleObject, and MUST publish additional classes in the subschema.
Section 8.1 defines equality matching rules including: objectIdentifierMatch (2.5.13.0), distinguishedNameMatch (2.5.13.1), caseIgnoreMatch (2.5.13.2), integerMatch (2.5.13.14), generalizedTimeMatch (2.5.13.27), caseExactIA5Match (1.3.6.1.4.1.1466.109.114.1), and caseIgnoreIA5Match (.114.2). For case-insensitive rules, multiple adjoining whitespace is treated as a single space and leading/trailing whitespace is ignored.
Standard operational attributes defined in section 5.1 include: createTimestamp (2.5.18.1), modifyTimestamp (2.5.18.2), creatorsName (2.5.18.3), modifiersName (2.5.18.4), subschemaSubentry (2.5.18.10), attributeTypes (2.5.21.5), objectClasses (2.5.21.6), matchingRules (2.5.21.4), and matchingRuleUse (2.5.21.8). All are NO-USER-MODIFICATION directoryOperation attributes; servers MUST maintain them per X.501.
Substring matching rules in section 8.3 include caseIgnoreSubstringsMatch (2.5.13.4), telephoneNumberSubstringsMatch (2.5.13.21), and numericStringSubstringsMatch (2.5.13.10), all using the Substring Assertion syntax (OID .58). The Substring Assertion syntax is used only as an assertion value syntax in extensible match, not as an attribute value syntax.
The extensibleObject auxiliary class (OID 1.3.6.1.4.1.1466.101.120.111) permits an entry to optionally hold any attribute, effectively having an implicit MAY list of all attributes. Mandatory attributes of other object classes in the entry remain required. Not all servers implement this class.
The subschema auxiliary class (OID 2.5.20.1) is used in the subschema entry and MAY contain: dITStructureRules, nameForms, ditContentRules, objectClasses, attributeTypes, matchingRules, and matchingRuleUse. The ldapSyntaxes operational attribute may also be present in subschema entries.
Section 4.3.2 defines a table of LDAP syntax OIDs under the arc 1.3.6.1.4.1.1466.115.121.1, covering 54 syntaxes including Directory String (.15), DN (.12), Boolean (.7), Certificate (.8), Binary (.5), OID (.38), GeneralizedTime (.24), INTEGER (.27), and Substring Assertion (.58), each annotated with a human-readable (H-R) flag.
Attributes of directory entries provide descriptive information about real-world people, organizations, or devices. Most countries have privacy laws regarding publication of personal information, which implementors must consider when deploying LDAP directories with read or update access.
The transformation of AttributeValues from X.501 form to LDAP string representation is not always reversible to the same BER/DER form; for example, TeletexString and PrintableString choices both become 'CN=Sam'. Applications requiring DER form for X.509 certificate verification SHOULD NOT use string representations and SHOULD instead use the Binary syntax.
Binary syntax (OID 1.3.6.1.4.1.1466.115.121.1.5) encodes attribute values as BER-encoded instances of the ASN.1 data type wrapped in an OCTET STRING in primitive form. The first byte inside the wrapper is a tag octet.
Directory String (OID 1.3.6.1.4.1.1466.115.121.1.15) is encoded in the UTF-8 form of ISO 10646. PrintableString is encoded as-is; TeletexString is transliterated to UniversalString then UTF-8; UniversalString and BMPString are encoded directly in UTF-8. The form is not indicated in protocol unless carried in binary.
DN (OID 1.3.6.1.4.1.1466.115.121.1.12) values are encoded using the UTF-8 string representation defined in RFC 2253. This representation is not reversible to the ASN.1/X.500 encoding, as the CHOICE of DirectoryString element in an RDN is lost in the string form.
Generalized Time (OID 1.3.6.1.4.1.1466.115.121.1.24) is encoded as a printable string per X.208 and must include a time zone specification; GMT is strongly recommended (e.g., '199412161032Z').
Postal Address (OID 1.3.6.1.4.1.1466.115.121.1.41) encodes multiple address lines as '$'-separated dstrings. Backslash and dollar characters within components are escaped using the '\XX' hex-pair quoting mechanism defined in section 4.3.