A Summary of the X.500(96) User Schema for use with LDAPv3
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-4519 — Lightweight Directory Access Protocol (LDAP): Schema for User Applications
- 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 (30)
IESG approved this Proposed Standard despite the lack of mandatory authentication to encourage implementation and interoperability testing, to support read-only application deployments (e.g., LDAPv3 as a query language), and to avoid blocking other Internet standards that depend on LDAPv3 query capability.
The Guide syntax (OID 1.3.6.1.4.1.1466.115.121.1.25) is retained for compatibility with RFC 1778 but should not be used for defining new attributes; the Enhanced Guide syntax supersedes it by adding a mandatory search scope specifier.
Until mandatory authentication mechanisms for LDAPv3 are standardized, clients and servers implementing update functionality are UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL. Implementors are discouraged from deploying LDAPv3 update functionality.
An LDAP server implementation SHOULD recognize all attribute types described in section 5 of this document.
Client implementations MUST NOT assume that LDAP servers are capable of performing attribute subtyping, as server implementations which do not support subtyping need not recognize supertype attributes (name, distinguishedName) in requests.
Clients which wish to store and retrieve the supportedAlgorithms attribute MUST use 'supportedAlgorithms;binary', in which the value is transferred as a binary encoding. No printable representation is defined.
LDAP servers MUST recognize the object classes 'top' and 'subschema'. LDAP servers SHOULD recognize all other object classes listed in section 7.
Servers SHOULD recognize the syntaxes defined in section 6. Syntax name descriptions are not carried in protocol and are not guaranteed to be unique.
Transfer of cleartext passwords are strongly discouraged where the underlying transport service cannot guarantee confidentiality and may result in disclosure of the password to unauthorized parties.
Certificate-related binary attributes — userCertificate (2.5.4.36), cACertificate (2.5.4.37), authorityRevocationList (2.5.4.38), certificateRevocationList (2.5.4.39), and crossCertificatePair (2.5.4.40) — must each be stored and requested using the ';binary' attribute option.
The aliasedObjectName attribute (OID 2.5.4.1) uses distinguishedNameMatch equality and DN syntax; it is SINGLE-VALUE and used by the directory service when an entry is an alias.
The certificationAuthority object class (2.5.6.16) is AUXILIARY and requires authorityRevocationList, certificateRevocationList, and cACertificate; crossCertificatePair is optional. The V2 variant (2.5.6.16.2) also allows deltaRevocationList.
The country object class (2.5.6.2) is STRUCTURAL, requires attribute c (ISO 3166 two-letter code), and optionally allows searchGuide and description. The c attribute (OID 2.5.4.6) is SINGLE-VALUE.
The distinguishedName attribute (OID 2.5.4.49) is a base type from which DN-syntax attributes inherit; it uses distinguishedNameMatch equality. It is unlikely to hold values directly in entries.
The dmd object class (2.5.6.20) is a new STRUCTURAL class from X.500(96) representing a directory management domain; it requires dmdName and allows the same optional attributes as organization.
The dnQualifier attribute (OID 2.5.4.46) specifies disambiguating information added to an entry's RDN when merging data from multiple sources; it is recommended that all entries from the same source share the same dnQualifier value.
The name attribute (OID 2.5.4.41) is the supertype for string attributes typically used for naming (cn, sn, o, ou, etc.); it uses caseIgnoreMatch equality and a 32768-character DirectoryString syntax.
The objectClass attribute (OID 2.5.4.0) uses objectIdentifierMatch equality and OID syntax. It is present in every entry with at least two values; one must be 'top' or 'alias'.
The octetStringMatch matching rule (OID 2.5.13.17) uses Octet String syntax; servers implementing extensibleMatch SHOULD allow this rule with all attribute types whose value syntax matches its assertion syntax.
The person object class (2.5.6.6) is STRUCTURAL, requires both sn and cn, and optionally allows userPassword, telephoneNumber, seeAlso, and description.
The strongAuthenticationUser object class (2.5.6.15) is AUXILIARY and requires the userCertificate attribute, enabling certificate-based authentication for directory entries.
The userPassword attribute (OID 2.5.4.35) uses octetStringMatch equality and Octet String syntax with a 128-octet bound. Passwords are stored unencrypted.
The x500UniqueIdentifier attribute (OID 2.5.4.45) uses bitStringMatch equality and Bit String syntax; it distinguishes between objects when a distinguished name has been reused, and differs from both 'uid' and 'uniqueIdentifier'.
Three new attributes introduced in X.500(96): supportedAlgorithms (2.5.4.52, Supported Algorithm syntax, binary-only), deltaRevocationList (2.5.4.53, Certificate List syntax, binary-only), and dmdName (2.5.4.54, inherits from name supertype).
Attributes of directory entries describe real-world objects including people; most countries have privacy laws regarding publication of personal information, which implementors must consider when deploying directories.
The userPassword attribute stores passwords as unencrypted octet strings. Cleartext password transfer over transports that cannot guarantee confidentiality is strongly discouraged as it risks disclosure to unauthorized parties.
The Delivery Method syntax (OID 1.3.6.1.4.1.1466.115.121.1.14) encodes as '$'-delimited tokens from the set: any, mhs, physical, telex, teletex, g3fax, g4fax, ia5, videotex, telephone.
The Enhanced Guide syntax (OID 1.3.6.1.4.1.1466.115.121.1.21) encodes as 'woid # criteria # subset' where subset is 'baseobject', 'oneLevel', or 'wholeSubtree'. Example: 'person#(sn)#oneLevel'. This syntax supersedes the older Guide syntax.
The Teletex Terminal Identifier syntax (OID 1.3.6.1.4.1.1466.115.121.1.51) encodes as a printable string terminal ID followed by zero or more '$key:value' parameter pairs; keys are graphic, control, misc, page, or private.
The Telex Number syntax (OID 1.3.6.1.4.1.1466.115.121.1.52) encodes as 'actual-number $ country $ answerback', all printable strings representing the number, country code, and answerback code respectively.