Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option
Extracted elements (16)
The binary option is not a tagging option, so its presence does not specify an attribute subtype. An attribute description with or without the binary option references exactly the same attribute, and supertype/subtype relationships are not altered by its presence or absence.
The binary option was originally defined in RFC 2251 but was removed from the revised LDAP technical specification (RFC 4510) due to implementation inconsistencies. RFC 4522 reintroduces it only for attribute syntaxes that specifically require it (e.g., certificate syntax), without attempting to resolve the known inconsistencies from the original definition.
The presence or absence of the binary option only affects the transfer of attribute and assertion values in the protocol; servers store any particular attribute value in a format of their choosing. This separates wire encoding from storage format.
The requirement to preserve the exact BER encoding for certificate-syntax attributes is a property of those syntaxes themselves, not of the binary option. Without this requirement, LDAP clients would need to re-encode values using Distinguished Encoding Rules (DER), which could alter the byte representation.
When a particular attribute is requested both explicitly (with binary option in one description but not another) and implicitly (via supertypes or '*'), the effect with respect to binary transfer is implementation defined. Implementations may differ in behavior for such conflicting requests.
An attribute description SHALL be treated as unrecognized if it contains the binary option and the syntax of the attribute does not have an associated ASN.1 type, or the BER encoding of values of that type is not supported.
Attributes of a syntax with the binary transfer requirement, if returned, SHALL be returned in the binary form (with the binary option and BER-encoded values) regardless of whether the binary option was present in the request.
Attributes of a syntax without the binary transfer requirement SHOULD be returned in the form explicitly requested: binary if the binary option was in the request, non-binary otherwise. A server MAY omit an attribute from the result if it does not support the requested encoding.
Regardless of the encoding chosen, a particular attribute value MUST be returned at most once in a search result.
The requested attributes list in an LDAP search MAY contain attribute descriptions with the binary option, but MUST NOT contain two attribute descriptions with the same attribute type and the same tagging options even if only one has the binary option.
When all user attributes are requested (empty list or '*'), attributes of a syntax with the binary transfer requirement SHALL be returned in the binary form. Attributes without a binary transfer requirement and with a defined LDAP-specific encoding SHOULD NOT be returned in the binary form.
Where the binary option is present in an attribute description, the associated attribute values or assertion values MUST be BER encoded. The contents octets of the associated AttributeValue or AssertionValue OCTET STRING are a complete BER encoding of the relevant value.
Certain attribute syntaxes have a 'binary transfer requirement': they are defined without an LDAP-specific encoding and must be transferred in BER-encoded form. Certificate, certificate list, certificate pair, and supported algorithm syntaxes (RFC 4523) are canonical examples and additionally require that the exact BER encoding be preserved.
The binary option is an attribute option indicated by the string 'binary' (case insensitive) in an attribute description. It specifies that the associated attribute values or assertion values are encoded according to BER as used by X.500 directories, rather than the normal LDAP-specific encoding.
IANA updated the LDAP attribute description option registry (BCP 64, RFC 4520) to register the 'binary' option. It is not a family of options. The specification is RFC 4522 and the change controller is the IESG.
When interpreting security-sensitive fields, particularly fields used to grant or deny access, implementations MUST ensure that any matching rule comparisons are done on the underlying abstract value, regardless of the particular encoding (LDAP-specific or BER) used.