RFC 4519
Lightweight Directory Access Protocol (LDAP): Schema for User Applications
Lightweight Directory Access Protocol (LDAP): Schema for User Applications 🎀
okay bestie, this is RFC 4519 💖 It's a Standards Track doc from June 2006, written by A. Sciberras, Ed. of eB2Bcom. It obsoletes RFC 2256 and updates RFC 2247, RFC 2798, and RFC 2377 🦋 It's the schema part of the LDAP spec, the list of user-info attribute types and object classes that lots of directories (like White Pages) use. Let's go ✨
Status of This Memo 📜
ok so this doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 If you want to check where it stands, look at the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share it with everyone 💅
Copyright Notice ⚖️
Copyright (C) The Internet Society (2006). 💜
Abstract ✨
this document is an integral part of the Lightweight Directory Access Protocol (LDAP) technical spec, and it's giving attribute types and object classes for LDAP directory clients, used across many directory services like White Pages 📇 Lots of LDAP directories use these as their schema basis, which is iconic 👑 It does not cover attributes for administering directory servers, and it doesn't include directory objects made for specific uses in other documents. Not in scope, bestie 🙈
Table of Contents 🗂️
1. Introduction ....................................................3
1.1. Relationship with Other Specifications .....................3
1.2. Conventions ................................................4
1.3. General Issues .............................................4
2. Attribute Types .................................................4
2.1. 'businessCategory' .........................................5
2.2. 'c' ........................................................5
2.3. 'cn' .......................................................5
2.4. 'dc' .......................................................6
2.5. 'description' ..............................................6
2.6. 'destinationIndicator' .....................................7
2.7. 'distinguishedName' ........................................7
2.8. 'dnQualifier' ..............................................8
2.9. 'enhancedSearchGuide' ......................................8
2.10. 'facsimileTelephoneNumber' ................................9
2.11. 'generationQualifier' .....................................9
2.12. 'givenName' ...............................................9
2.13. 'houseIdentifier' .........................................9
2.14. 'initials' ...............................................10
2.15. 'internationalISDNNumber' ................................10
2.16. 'l' ......................................................10
2.17. 'member' .................................................11
2.18. 'name' ...................................................11
2.19. 'o' ......................................................11
2.20. 'ou' .....................................................12
2.21. 'owner' ..................................................12
2.22. 'physicalDeliveryOfficeName' .............................12
2.23. 'postalAddress' ..........................................13
2.24. 'postalCode' .............................................13
2.25. 'postOfficeBox' ..........................................14
2.26. 'preferredDeliveryMethod' ................................14
2.27. 'registeredAddress' ......................................14
2.28. 'roleOccupant' ...........................................15
2.29. 'searchGuide' ............................................15
2.30. 'seeAlso' ................................................15
2.31. 'serialNumber' ...........................................16
2.32. 'sn' .....................................................16
2.33. 'st' .....................................................16
2.34. 'street' .................................................17
2.35. 'telephoneNumber' ........................................17
2.36. 'teletexTerminalIdentifier' ..............................17
2.37. 'telexNumber' ............................................18
2.38. 'title' ..................................................18
2.39. 'uid' ....................................................18
2.40. 'uniqueMember' ...........................................19
2.41. 'userPassword' ...........................................19
2.42. 'x121Address' ............................................20
2.43. 'x500UniqueIdentifier' ...................................20
3. Object Classes .................................................20
3.1. 'applicationProcess' ......................................21
3.2. 'country' .................................................21
3.3. 'dcObject' ................................................21
3.4. 'device' ..................................................21
3.5. 'groupOfNames' ............................................22
3.6. 'groupOfUniqueNames' ......................................22
3.7. 'locality' ................................................23
3.8. 'organization' ............................................23
3.9. 'organizationalPerson' ....................................24
3.10. 'organizationalRole' .....................................24
3.11. 'organizationalUnit' .....................................24
3.12. 'person' .................................................25
3.13. 'residentialPerson' ......................................25
3.14. 'uidObject' ..............................................26
4. IANA Considerations ............................................26
5. Security Considerations ........................................28
6. Acknowledgements ...............................................28
7. References .....................................................29
7.1. Normative References ......................................29
7.2. Informative References ....................................30
Appendix A Changes Made Since RFC 2256 ...........................321. Introduction 🌸
okay so this doc gives you an overview of attribute types and object classes meant for LDAP directory clients across lots of directory services, like White Pages 📇 They were first specified in the X.500 [X.500] documents, and now they're the basis for the schema in tons of LDAP directories, which is so iconic 🔥 Again, no admin-of-the-server attributes here, and no objects for specific uses from other docs 💅
1.1. Relationship with Other Specifications 🦋
this doc is an integral part of the LDAP technical spec [RFC4510]. That spec obsoletes the earlier LDAP technical spec, RFC 3377, completely 💀 Now for RFC 2256, which is the one this doc obsoletes. Sections 6 and 8 of RFC 2256 are obsoleted by [RFC4517]. Sections 5.1, 5.2, 7.1, and 7.2 of RFC 2256 are obsoleted by [RFC4512]. Everything else from RFC 2256 is obsoleted by this document ✨
The 'dc' attribute type and 'dcObject' object class from RFC 2247 are superseded by sections 2.4 and 3.3 of this document. The rest of RFC 2247 stays in force, so it's not all gone 🫶
This document updates RFC 2798 by swapping out the informative description of the 'uid' attribute type for the definitive one in Section 2.39 of this document 🎀
This document also updates RFC 2377 by replacing the informative description of the 'uidObject' object class with the definitive description in Section 3.14 of this document 🌈
Some schema elements from the previous LDAP Technical Specification aren't in this revision. PKI-related schema elements are now specified in [RFC4523] 🔐 Unless they get brought back in future technical specs, the rest are considered Historic 🕰️
the descriptions in this document SHALL be considered definitive for use in LDAP. No debate, bestie 👑
1.2. Conventions 💜
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🧚
1.3. General Issues 🍓
this doc references Syntaxes defined in Section 3 of [RFC4517], and Matching Rules defined in Section 4 of [RFC4517] 🔍
The definitions of Attribute Types and Object Classes are written using the Augmented Backus-Naur Form (ABNF) [RFC4234] of AttributeTypeDescription and ObjectClassDescription given in [RFC4512]. Lines have been folded for readability 📏 When these values get transferred as attribute values in the LDAP Protocol, they won't contain line breaks, so no surprises 😭
2. Attribute Types 💖
the attribute types in this section hold user information 🧸
There is no requirement that servers implement the 'searchGuide' and 'teletexTerminalIdentifier' attribute types. Honestly, their use is greatly discouraged 💀
An LDAP server implementation SHOULD recognize the rest of the attribute types described in this section ✨
2.1. 'businessCategory' 💼
the 'businessCategory' attribute type describes the kinds of business an organization does. Each kind is one value of this multi-valued attribute 🏢 (Source: X.520 [X.520])
( 2.5.4.15 NAME 'businessCategory'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax [RFC4517] 🔤
Examples: "banking", "transportation", and "real estate" 🏦🚌🏡
2.2. 'c' 🌍
the 'c' ('countryName' in X.500) attribute type holds a two-letter ISO 3166 [ISO3166] country code 🗺️ (Source: X.520 [X.520])
( 2.5.4.6 NAME 'c'
SUP name
SYNTAX 1.3.6.1.4.1.1466.115.121.1.11
SINGLE-VALUE )1.3.6.1.4.1.1466.115.121.1.11 refers to the Country String syntax [RFC4517] 🌏
Examples: "DE", "AU" and "FR" 🇩🇪🇦🇺🇫🇷
2.3. 'cn' 🧑🤝🧑
the 'cn' ('commonName' in X.500) attribute type holds names of an object. Each name is one value of this multi-valued attribute 🏷️ If the object is a person, it's usually the person's full name, so yes, it's giving main character energy 💅 (Source: X.520 [X.520])
( 2.5.4.3 NAME 'cn'
SUP name )Examples: "Martin K Smith", "Marty Smith" and "printer12" 🖨️💜
2.4. 'dc' 🎀
Okay bestie, so 'dc' (that's 'domainComponent' from RFC 1274 🦋) holds one label of a DNS domain name [RFC1034][RFC2181] that names a host [RFC1123]. Think one chunk, not the whole name ✨. A value is an ASCII string that follows this ABNF [RFC4234]:
label = (ALPHA / DIGIT) [*61(ALPHA / DIGIT / HYPHEN) (ALPHA / DIGIT)]
ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
DIGIT = %x30-39 ; "0"-"9"
HYPHEN = %x2D ; hyphen ("-")For LDAP, the IA5String encoding is literally just the characters of the ASCII label, no extra steps 💅. Equality matching is case insensitive, same as DNS is today 🌸. (Source: RFC 2247 [RFC2247] and RFC 1274 [RFC 1274])
( 0.9.2342.19200300.100.1.25 NAME 'dc'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE )1.3.6.1.4.1.1466.115.121.1.26 is the IA5 String syntax [RFC4517], so it's giving standard vibes 🧚
Examples: "example" and "com" are valid 💖 but "example.com" is NOT, because it has multiple domain components. One label per value, periodt 😭
Heads up: the directory service will NOT check that values follow the host label restrictions [RFC1123] in the <label> production above. Keeping those labels properly restricted is the directory client's job 🫶
Directory applications that support International Domain Names SHALL use the ToASCII method [RFC3490] to produce the domain component label 🔥. The special considerations in Section 4 of RFC 3490 [RFC3490] should be taken, depending on whether the domain component is used for "stored" or "query" purposes 🦋.
2.5. 'description' 🌈
The 'description' attribute type holds human-readable descriptive phrases about the object 💜. Each description is one value of this multi-valued attribute ✨. (Source: X.520 [X.520])
( 2.5.4.13 NAME 'description'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax [RFC4517] 🎀
Examples: "a color printer", "Maintenance is done every Monday, at 1pm.", and "distribution list for all technical staff" 🍓
2.6. 'destinationIndicator' 🛩️
The 'destinationIndicator' attribute type holds country and city strings tied to the object (the addressee) so the Public Telegram Service can get the message where it needs to go 📮. The strings are built following CCITT Recommendations F.1 [F.1] and F.31 [F.31]. Each string is one value of this multi-valued attribute 💅. (Source: X.520 [X.520])
( 2.5.4.27 NAME 'destinationIndicator'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax [RFC4517] ✨
Examples: "AASD" as a destination indicator for Sydney, Australia 🦘 and "GBLD" as a destination indicator for London, United Kingdom 🇬🇧.
It's noted that the directory will NOT make sure values of this attribute follow the F.1 and F.31 CCITT Recommendations 🙈. Making sure the destination indicators it stores here are properly built is the application's responsibility.
2.7. 'distinguishedName' 🗝️
The 'distinguishedName' attribute type is NOT used as the name of the object itself. Instead, it's a base type that some user attribute types with a DN syntax can inherit from 🧬.
Values of this type itself are unlikely to show up in an entry. LDAP server implementations that don't support attribute subtyping need not recognize this attribute in requests. Client implementations MUST NOT assume that LDAP servers are capable of performing attribute subtyping. Bestie, do not assume that 💀 (Source: X.520 [X.520])
( 2.5.4.49 NAME 'distinguishedName'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )1.3.6.1.4.1.1466.115.121.1.12 refers to the DN syntax [RFC4517] 🌸
2.8. 'dnQualifier' 🫧
The 'dnQualifier' attribute type holds disambiguating information strings that get added to the relative distinguished name of an entry 🔍. It's for when you merge data from multiple sources, so entries that would otherwise share a name don't clash 💥. Each string is one value of this multi-valued attribute. It is recommended that a value of the 'dnQualifier' attribute be the same for all entries from a particular source 🦋. (Source: X.520 [X.520])
( 2.5.4.46 NAME 'dnQualifier'
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax [RFC4517] 🎀
Examples: "20050322123345Z", where timestamps can be used to disambiguate information ⏰, and "123456A", where serial numbers can be used to disambiguate information 🔢.
2.9. 'enhancedSearchGuide' 🔎
The 'enhancedSearchGuide' attribute type holds sets of information that directory clients use when building search filters 🧭. Each set is one value of this multi-valued attribute. (Source: X.520 [X.520])
( 2.5.4.47 NAME 'enhancedSearchGuide'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )1.3.6.1.4.1.1466.115.121.1.21 refers to the Enhanced Guide syntax [RFC4517] ✨
Examples: "person#(sn$APPROX)#wholeSubtree" and "organizationalUnit#(ou$SUBSTR)#oneLevel" 👑
2.10. 'facsimileTelephoneNumber' 📠
The 'facsimileTelephoneNumber' attribute type holds telephone numbers (and, optionally, the parameters) for facsimile terminals 🖨️. Each telephone number is one value of this multi-valued attribute. (Source: X.520 [X.520])
( 2.5.4.23 NAME 'facsimileTelephoneNumber'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )1.3.6.1.4.1.1466.115.121.1.22 refers to the Facsimile Telephone Number syntax [RFC4517] 💜
Examples: "+61 3 9896 7801" and "+81 3 347 7418$fineResolution" 🌏
2.11. 'generationQualifier' 👑
The 'generationQualifier' attribute type holds name strings that are typically the suffix part of a person's name 💅. Each string is one value of this multi-valued attribute. (Source: X.520 [X.520])
( 2.5.4.44 NAME 'generationQualifier'
SUP name )Examples: "III", "3rd", and "Jr." 🌟
2.12. 'givenName' 🌷
The 'givenName' attribute type holds name strings that are the part of a person's name that is NOT their surname 💖. Each string is one value of this multi-valued attribute. (Source: X.520 [X.520])
( 2.5.4.42 NAME 'givenName'
SUP name )Examples: "Andrew", "Charles", and "Joanne" 🫶
2.13. 'houseIdentifier' 🏡
The 'houseIdentifier' attribute type holds identifiers for a building within a location 🏘️. Each identifier is one value of this multi-valued attribute. (Source: X.520 [X.520])
( 2.5.4.51 NAME 'houseIdentifier'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax [RFC4517] 🎀
Example: "20" to represent the house number 20 🍓
2.14. 'initials' 🖋️
The 'initials' attribute type holds strings of initials for some or all of an individual's names, EXCEPT the surname(s) 🦋. Each string is one value of this multi-valued attribute. (Source: X.520 [X.520])
( 2.5.4.43 NAME 'initials'
SUP name )Examples: "K. A." and "K" ✨
2.15. 'internationalISDNNumber' 📞
The 'internationalISDNNumber' attribute type holds Integrated Services Digital Network (ISDN) addresses, as defined in the International Telecommunication Union (ITU) Recommendation E.164 [E.164] 🌍. Each address is one value of this multi-valued attribute. (Source: X.520 [X.520])
( 2.5.4.25 NAME 'internationalISDNNumber'
EQUALITY numericStringMatch
SUBSTR numericStringSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax [RFC4517] 🔢
Example: "0198 333 333" 💫
2.16. 'l' 🏙️
The 'l' attribute type ('localityName' in X.500) holds names of a locality or place, such as a city, county, or other geographic region 🗺️. Each name is one value of this multi-valued attribute. (Source: X.520 [X.520])
( 2.5.4.7 NAME 'l'
SUP name )Examples: "Geneva", "Paris", and "Edinburgh" ✈️
2.17. 'member' 👯
The 'member' attribute type holds the distinguished names of objects that are on a list or in a group 💜. Each name is one value of this multi-valued attribute. (Source: X.520 [X.520])
( 2.5.4.31 NAME 'member'
SUP distinguishedName )Examples: "cn=James Clarke,ou=Finance,o=Widget\, Inc." and "cn=John Xerri,ou=Finance,o=Widget\, Inc." may be two members of the financial team (group) at Widget, Inc., in which case, both of these distinguished names would be present as individual values of the member attribute 🧁.
2.18. 'name' 🏷️
The 'name' attribute type is the attribute supertype that user attribute types with the name syntax inherit from 🌳. Such attribute types are typically used for naming. The attribute type is multi-valued.
Values of this type itself are unlikely to show up in an entry. LDAP server implementations that don't support attribute subtyping need not recognize this attribute in requests. Client implementations MUST NOT assume that LDAP servers are capable of performing attribute subtyping 🙈 (Source: X.520 [X.520])
( 2.5.4.41 NAME 'name'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax [RFC4517] 🎀
2.19. 'o' 🏢
The 'o' attribute type ('organizationName' in X.500) holds the names of an organization 💼. Each name is one value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.10 NAME 'o'
SUP name )Examples: "Widget", "Widget, Inc.", and "Widget, Incorporated." 🌸
2.20. 'ou' 🧩
The 'ou' attribute type ('organizationalUnitName' in X.500) holds the names of an organizational unit 🏗️. Each name is one value of this multi-valued attribute. (Source: X.520 [X.520])
( 2.5.4.11 NAME 'ou'
SUP name )Examples: "Finance", "Human Resources", and "Research and Development" 💅
2.21. 'owner' 👑
The 'owner' attribute type holds the distinguished names of objects that have an ownership responsibility for the object that is owned 🔑. Each owner's name is one value of this multi-valued attribute. (Source: X.520 [X.520])
( 2.5.4.32 NAME 'owner'
SUP distinguishedName )Example: The mailing list object, whose DN is "cn=All Employees,ou=Mailing List,o=Widget\, Inc.", is owned by the Human Resources Director 📬.
Therefore, the value of the 'owner' attribute within the mailing list object would be the DN of the director (role): "cn=Human Resources Director,ou=employee,o=Widget\, Inc." 🦋
2.22. 'physicalDeliveryOfficeName' 🎀
okay so the physicalDeliveryOfficeName attribute type holds the names a Postal Service uses to identify a post office 📮 (Source: X.520 [X.520])
( 2.5.4.19 NAME 'physicalDeliveryOfficeName'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax [RFC4517] 💅
Examples: "Bremerhaven, Main" and "Bremerhaven, Bonnstrasse" 🌸
2.23. 'postalAddress' 💌
the postalAddress attribute type holds the addresses a Postal Service uses to take care of things for the object 📬 each address is its own value in this multi-valued attribute, so you can stack as many as you want 🫶 (Source: X.520 [X.520])
( 2.5.4.16 NAME 'postalAddress'
EQUALITY caseIgnoreListMatch
SUBSTR caseIgnoreListSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax [RFC4517] ✨
Example: "15 Main St.$Ottawa$Canada" 🍓
2.24. 'postalCode' 🦋
the postalCode attribute type holds the codes a Postal Service uses to identify its postal service zones 🗺️ each code is one value of this multi-valued attribute (Source: X.520 [X.520])
( 2.5.4.17 NAME 'postalCode'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax [RFC4517] 💜
Example: "22180", to identify Vienna, VA, in the USA 🇺🇸
2.25. 'postOfficeBox' 📫
the postOfficeBox attribute type holds the postal box identifiers a Postal Service uses when a customer sets up mail at a box on the Postal Service's own premises 🏢 each postal box identifier is a single value of this multi-valued attribute (Source: X.520 [X.520])
( 2.5.4.18 NAME 'postOfficeBox'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax [RFC4517] 🌈
Example: "Box 45" 🎀
2.26. 'preferredDeliveryMethod' 🌟
the preferredDeliveryMethod attribute type says how the object would most like to get a message 💌 (Source: X.520 [X.520])
( 2.5.4.28 NAME 'preferredDeliveryMethod'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
SINGLE-VALUE )1.3.6.1.4.1.1466.115.121.1.14 refers to the Delivery Method syntax [RFC4517] 🧚
Example: if the mhs-delivery Delivery Method is preferred over telephone-delivery, and telephone-delivery is preferred over all the other methods, the value would be: "mhs $ telephone" 📞 that's a whole ranking situation, honestly iconic 👑
2.27. 'registeredAddress' 📮
the registeredAddress attribute type holds postal addresses that are good for telegrams or expedited documents, where the recipient has to accept delivery 🚨 each address is one value of this multi-valued attribute (Source: X.520 [X.520])
( 2.5.4.26 NAME 'registeredAddress'
SUP postalAddress
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax [RFC4517] 💅
Example: "Receptionist$Widget, Inc.$15 Main St.$Ottawa$Canada" 🏢
2.28. 'roleOccupant' 👑
the roleOccupant attribute type holds the distinguished names of objects (usually people) who do the job of a role object 💼 each distinguished name is one value of this multi-valued attribute (Source: X.520 [X.520])
( 2.5.4.33 NAME 'roleOccupant'
SUP distinguishedName )Example: the role object "cn=Human Resources Director,ou=Position,o=Widget\, Inc." is filled by two people, whose object names are "cn=Mary Smith,ou=employee,o=Widget\, Inc." and "cn=James Brown,ou=employee,o=Widget\, Inc.". So the roleOccupant attribute will hold both of those distinguished names, because they're the occupants of that role 🙌
2.29. 'searchGuide' 🔍
the searchGuide attribute type holds sets of info that clients use when they build search filters 🛠️ it's been superseded by enhancedSearchGuide, which I covered above in Section 2.9 🦋 each set is one value of this multi-valued attribute (Source: X.520 [X.520])
( 2.5.4.14 NAME 'searchGuide'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )1.3.6.1.4.1.1466.115.121.1.25 refers to the Guide syntax [RFC4517] ✨
Example: "person#sn$EQ" 🌸
2.30. 'seeAlso' 🔗
the seeAlso attribute type holds the distinguished names of objects that are related to the subject object 💕 each related object name is one value of this multi-valued attribute (Source: X.520 [X.520])
( 2.5.4.34 NAME 'seeAlso'
SUP distinguishedName )Example: the person object "cn=James Brown,ou=employee,o=Widget\, Inc." is related to the role objects "cn=Football Team Captain,ou=sponsored activities,o=Widget\, Inc." and "cn=Chess Team,ou=sponsored activities,o=Widget\, Inc.". Since the role objects are related to the person object, the seeAlso attribute will contain the distinguished name of each role object as its own separate value 🫶
2.31. 'serialNumber' 🔢
the serialNumber attribute type holds the serial numbers of devices 🖨️ each serial number is one value of this multi-valued attribute (Source: X.520 [X.520])
( 2.5.4.5 NAME 'serialNumber'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax [RFC4517] 💜
Examples: "WI-3005" and "XF551426" 🎀
2.32. 'sn' 🌷
the sn (that's surname in X.500) attribute type holds name strings for a person's family names 💖 each string is one value of this multi-valued attribute (Source: X.520 [X.520])
( 2.5.4.4 NAME 'sn'
SUP name )Example: "Smith" 🌈
2.33. 'st' 🗺️
the st (that's stateOrProvinceName in X.500) attribute type holds the full names of states or provinces 🇺🇸 each name is one value of this multi-valued attribute (Source: X.520 [X.520])
( 2.5.4.8 NAME 'st'
SUP name )Example: "California" ☀️
2.34. 'street' 🏡
the street (that's streetAddress in X.500) attribute type holds the site info from a postal address, like the street name, the place, the avenue, and the house number 🏠 each street is one value of this multi-valued attribute (Source: X.520 [X.520])
( 2.5.4.9 NAME 'street'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax [RFC4517] 💅
Example: "15 Main St." 🍓
2.35. 'telephoneNumber' 📱
the telephoneNumber attribute type holds telephone numbers that follow the ITU Recommendation E.123 [E.123] 📞 each number is one value of this multi-valued attribute (Source: X.520 [X.520])
( 2.5.4.20 NAME 'telephoneNumber'
EQUALITY telephoneNumberMatch
SUBSTR telephoneNumberSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )1.3.6.1.4.1.1466.115.121.1.50 refers to the Telephone Number syntax [RFC4517] ✨
Example: "+1 234 567 8901" 🦋
2.36. 'teletexTerminalIdentifier' 🥀
ngl this one is kind of sad 😭 the withdrawal of Recommendation F.200 means this attribute got withdrawn too (Source: X.520 [X.520])
( 2.5.4.22 NAME 'teletexTerminalIdentifier'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )1.3.6.1.4.1.1466.115.121.1.51 refers to the Teletex Terminal Identifier syntax [RFC4517] 🕰️
2.37. 'telexNumber' 📠
the telexNumber attribute type holds sets of strings that make up a telex number, a country code, and an answerback code for a telex terminal 🧾 each set is one value of this multi-valued attribute (Source: X.520 [X.520])
( 2.5.4.21 NAME 'telexNumber'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )1.3.6.1.4.1.1466.115.121.1.52 refers to the Telex Number syntax [RFC4517] 💜
Example: "12345$023$ABCDE" 🌸
2.38. 'title' 👑
the title attribute type holds a person's title in their organizational context, so like, their job title in the company 💼 each title is one value of this multi-valued attribute (Source: X.520 [X.520])
( 2.5.4.12 NAME 'title'
SUP name )Examples: "Vice President", "Software Engineer", and "CEO" 💅✨
2.39. 'uid' 🔑
the uid (that's userid in RFC 1274) attribute type holds the computer system login names that go with the object 🔐 each name is one value of this multi-valued attribute (Source: RFC 2798 [RFC2798] and RFC 1274 [RFC1274])
( 0.9.2342.19200300.100.1.1 NAME 'uid'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax [RFC4517] 🌈
Examples: "s9709015", "admin", and "Administrator" 🧚
2.40. 'uniqueMember' 🧩
the uniqueMember attribute type holds the distinguished names of an object that's on a list or in a group 🫂 the object's relative distinguished names include a value that tells it apart from other objects when a distinguished name has been reused 🙈 each distinguished name is one value of this multi-valued attribute (Source: X.520 [X.520])
( 2.5.4.50 NAME 'uniqueMember'
EQUALITY uniqueMemberMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )1.3.6.1.4.1.1466.115.121.1.34 refers to the Name and Optional UID syntax [RFC4517] ✨
Example: if "ou=1st Battalion,o=Defense,c=US" was a battalion that got disbanded, and then a new battalion came along with the "same" name, the new one would get a unique identifier value added, so it becomes "ou=1st Battalion, o=Defense,c=US#'010101'B" 🎖️ the glow-up is real 💀
2.41. 'userPassword' 🔒
the userPassword attribute holds octet strings that are known only to the user and to the system the user has access to 🤫 each string is one value of this multi-valued attribute (Source: X.509 [X.509])
( 2.5.4.35 NAME 'userPassword'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )1.3.6.1.4.1.1466.115.121.1.40 refers to the Octet String syntax [RFC4517] 💅
The application SHOULD prepare textual strings used as passwords by transcoding them to Unicode, applying SASLprep [RFC4013], and encoding them as UTF-8 🫶 whether a password counts as textual is a local client matter, so that's up to the client 🦋
Passwords are stored using an Octet String syntax and are not encrypted. Sending cleartext passwords is strongly discouraged wherever the underlying transport service can't guarantee confidentiality, because it may result in the password being disclosed to unauthorized parties 😭🚨
An example of needing multiple values in the userPassword attribute is an environment where the user has to use a different password every month, generated by some automated system 📅 during transitional periods, like the last and first day of the periods, it may be necessary to let two passwords for the two consecutive periods be valid in the system 🌙☀️
2.42. 'x121Address' 🌐
the x121Address attribute type holds data network addresses as defined by ITU Recommendation X.121 [X.121] 📡 each address is one value of this multi-valued attribute (Source: X.520 [X.520])
( 2.5.4.24 NAME 'x121Address'
EQUALITY numericStringMatch
SUBSTR numericStringSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax [RFC4517] 🌸
Example: "36111222333444555" 🎀
2.43. 'x500UniqueIdentifier' 🎀
okay so the 'x500UniqueIdentifier' attribute type holds binary strings 🫶 they're there to tell objects apart when a distinguished name has been reused 👀 each string is one value of this multi-valued attribute ✨
in X.520 [X.520], this one is called 'uniqueIdentifier' 💅 and it's a totally different attribute type from both the 'uid' and 'uniqueIdentifier' LDAP attribute types 🙈 the 'uniqueIdentifier' attribute type is defined in [RFC4524] 🌸 (Source: X.520 [X.520])
( 2.5.4.45 NAME 'x500UniqueIdentifier'
EQUALITY bitStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )1.3.6.1.4.1.1466.115.121.1.6 is the Bit String syntax [RFC4517] 🦋
3. Object Classes 🧚
LDAP servers SHOULD recognize all the Object Classes listed here as values of the 'objectClass' attribute (see [RFC4512]) 🔥
3.1. 'applicationProcess' 💻
the 'applicationProcess' object class is the basis of an entry that represents an application running in a computer system 🫧 (Source: X.521 [X.521])
( 2.5.6.11 NAME 'applicationProcess'
SUP top
STRUCTURAL
MUST cn
MAY ( seeAlso $
ou $
l $
description ) )3.2. 'country' 🌍
the 'country' object class is the basis of an entry that represents a country 💖 (Source: X.521 [X.521])
( 2.5.6.2 NAME 'country'
SUP top
STRUCTURAL
MUST c
MAY ( searchGuide $
description ) )3.3. 'dcObject' 🍓
the 'dcObject' object class lets an entry contain domain component information ✨ it's defined as auxiliary because it gets used alongside an existing structural object class, which is so clever 🧠 (Source: RFC 2247 [RFC2247])
( 1.3.6.1.4.1.1466.344 NAME 'dcObject'
SUP top
AUXILIARY
MUST dc )3.4. 'device' 🖥️
the 'device' object class is the basis of an entry that represents an appliance, computer, or network element 🔌 (Source: X.521 [X.521])
( 2.5.6.14 NAME 'device'
SUP top
STRUCTURAL
MUST cn
MAY ( serialNumber $
seeAlso $
owner $
ou $
o $
l $
description ) )3.5. 'groupOfNames' 👯
the 'groupOfNames' object class is the basis of an entry that represents a set of named objects, plus info about why the set exists or who looks after it 🫶 (Source: X.521 [X.521])
( 2.5.6.9 NAME 'groupOfNames'
SUP top
STRUCTURAL
MUST ( member $
cn )
MAY ( businessCategory $
seeAlso $
owner $
ou $
o $
description ) )3.6. 'groupOfUniqueNames' 💜
the 'groupOfUniqueNames' object class is the same as 'groupOfNames' except the object names are never repeated or reassigned within a set scope 🔐 (Source: X.521 [X.521])
( 2.5.6.17 NAME 'groupOfUniqueNames'
SUP top
STRUCTURAL
MUST ( uniqueMember $
cn )
MAY ( businessCategory $
seeAlso $
owner $
ou $
o $
description ) )3.7. 'locality' 🏡
the 'locality' object class is the basis of an entry that represents a place in the physical world 🗺️ (Source: X.521 [X.521])
( 2.5.6.3 NAME 'locality'
SUP top
STRUCTURAL
MAY ( street $
seeAlso $
searchGuide $
st $
l $
description ) )3.8. 'organization' 🏢
the 'organization' object class is the basis of an entry that represents a structured group of people 💅 (Source: X.521 [X.521])
( 2.5.6.4 NAME 'organization'
SUP top
STRUCTURAL
MUST o
MAY ( userPassword $ searchGuide $ seeAlso $
businessCategory $ x121Address $ registeredAddress $
destinationIndicator $ preferredDeliveryMethod $
telexNumber $ teletexTerminalIdentifier $
telephoneNumber $ internationalISDNNumber $
facsimileTelephoneNumber $ street $ postOfficeBox $
postalCode $ postalAddress $ physicalDeliveryOfficeName $
st $ l $ description ) )3.9. 'organizationalPerson' 👩💼
the 'organizationalPerson' object class is the basis of an entry that represents a person in relation to an organization 💼 (Source: X.521 [X.521])
( 2.5.6.7 NAME 'organizationalPerson'
SUP person
STRUCTURAL
MAY ( title $ x121Address $ registeredAddress $
destinationIndicator $ preferredDeliveryMethod $
telexNumber $ teletexTerminalIdentifier $
telephoneNumber $ internationalISDNNumber $
facsimileTelephoneNumber $ street $ postOfficeBox $
postalCode $ postalAddress $ physicalDeliveryOfficeName $
ou $ st $ l ) )3.10. 'organizationalRole' 🎭
the 'organizationalRole' object class is the basis of an entry that represents a job, function, or position in an organization 🌟 (Source: X.521 [X.521])
( 2.5.6.8 NAME 'organizationalRole'
SUP top
STRUCTURAL
MUST cn
MAY ( x121Address $ registeredAddress $ destinationIndicator $
preferredDeliveryMethod $ telexNumber $
teletexTerminalIdentifier $ telephoneNumber $
internationalISDNNumber $ facsimileTelephoneNumber $
seeAlso $ roleOccupant $ preferredDeliveryMethod $
street $ postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ ou $ st $ l $
description ) )3.11. 'organizationalUnit' 🧩
the 'organizationalUnit' object class is the basis of an entry that represents a piece of an organization 🍰 (Source: X.521 [X.521])
( 2.5.6.5 NAME 'organizationalUnit'
SUP top
STRUCTURAL
MUST ou
MAY ( businessCategory $ description $ destinationIndicator $
facsimileTelephoneNumber $ internationalISDNNumber $ l $
physicalDeliveryOfficeName $ postalAddress $ postalCode $
postOfficeBox $ preferredDeliveryMethod $
registeredAddress $ searchGuide $ seeAlso $ st $ street $
telephoneNumber $ teletexTerminalIdentifier $
telexNumber $ userPassword $ x121Address ) )3.12 'person' 🧑
the 'person' object class is the basis of an entry that represents a human being 💖 (Source: X.521 [X.521])
( 2.5.6.6 NAME 'person'
SUP top
STRUCTURAL
MUST ( sn $
cn )
MAY ( userPassword $
telephoneNumber $
seeAlso $ description ) )3.13. 'residentialPerson' 🏠
the 'residentialPerson' object class is the basis of an entry that includes a person's residence as part of how the person is represented 🌷 (Source: X.521 [X.521])
( 2.5.6.10 NAME 'residentialPerson'
SUP person
STRUCTURAL
MUST l
MAY ( businessCategory $ x121Address $ registeredAddress $
destinationIndicator $ preferredDeliveryMethod $
telexNumber $ teletexTerminalIdentifier $
telephoneNumber $ internationalISDNNumber $
facsimileTelephoneNumber $ preferredDeliveryMethod $
street $ postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ st $ l ) )3.14. 'uidObject' 🪪
the 'uidObject' object class lets an entry contain user identification info 🫧 it's defined as auxiliary because it gets used alongside an existing structural object class, iykyk 💅 (Source: RFC 2377 [RFC2377])
( 1.3.6.1.1.3.1 NAME 'uidObject'
SUP top
AUXILIARY
MUST uid )4. IANA Considerations ✨
okay so IANA (the Internet Assigned Numbers Authority) updated the LDAP descriptors registry, and this is the template they used for it 💅
Subject: Request for LDAP Descriptor Registration Update
Descriptor (short name): see comments
Object Identifier: see comments
Person & email address to contact for further information:
Andrew Sciberras <andrew.sciberras@eb2bcom.com>
Usage: (A = attribute type, O = Object Class) see comment
Specification: RFC 4519
Author/Change Controller: IESGbestie, the comments section is the main event 🎀 Every descriptor (short name) listed below now refers to RFC 4519. If a name needs to be reserved instead of being assigned an Object Identifier, its OID shows up as RESERVED 🌸
NAME Type OID
------------------------ ---- ----------------------------
applicationProcess O 2.5.6.11
businessCategory A 2.5.4.15
c A 2.5.4.6
cn A 2.5.4.3
commonName A 2.5.4.3
country O 2.5.6.2
countryName A 2.5.4.6
dc A 0.9.2342.19200300.100.1.25
dcObject O 1.3.6.1.4.1.1466.344
description A 2.5.4.13
destinationIndicator A 2.5.4.27
device O 2.5.6.14
NAME Type OID
------------------------ ---- ----------------------------
distinguishedName A 2.5.4.49
dnQualifier A 2.5.4.46
domainComponent A 0.9.2342.19200300.100.1.25
enhancedSearchGuide A 2.5.4.47
facsimileTelephoneNumber A 2.5.4.23
generationQualifier A 2.5.4.44
givenName A 2.5.4.42
gn A RESERVED
groupOfNames O 2.5.6.9
groupOfUniqueNames O 2.5.6.17
houseIdentifier A 2.5.4.51
initials A 2.5.4.43
internationalISDNNumber A 2.5.4.25
l A 2.5.4.7
locality O 2.5.6.3
localityName A 2.5.4.7
member A 2.5.4.31
name A 2.5.4.41
o A 2.5.4.10
organization O 2.5.6.4
organizationName A 2.5.4.10
organizationalPerson O 2.5.6.7
organizationalRole O 2.5.6.8
organizationalUnit O 2.5.6.5
organizationalUnitName A 2.5.4.11
ou A 2.5.4.11
owner A 2.5.4.32
person O 2.5.6.6
physicalDeliveryOfficeName A 2.5.4.19
postalAddress A 2.5.4.16
postalCode A 2.5.4.17
postOfficeBox A 2.5.4.18
preferredDeliveryMethod A 2.5.4.28
registeredAddress A 2.5.4.26
residentialPerson O 2.5.6.10
roleOccupant A 2.5.4.33
searchGuide A 2.5.4.14
seeAlso A 2.5.4.34
serialNumber A 2.5.4.5
sn A 2.5.4.4
st A 2.5.4.8
street A 2.5.4.9
surname A 2.5.4.4
telephoneNumber A 2.5.4.20
teletexTerminalIdentifier A 2.5.4.22
telexNumber A 2.5.4.21
NAME Type OID
------------------------ ---- ----------------------------
title A 2.5.4.12
uid A 0.9.2342.19200300.100.1.1
uidObject O 1.3.6.1.1.3.1
uniqueMember A 2.5.4.50
userid A 0.9.2342.19200300.100.1.1
userPassword A 2.5.4.35
x121Address A 2.5.4.24
x500UniqueIdentifier A 2.5.4.455. Security Considerations 🔥
okay bestie, this part is serious, so let's get into it 🫶 Attributes in directory entries describe the real-world things they represent, and those can be people, organizations, or devices. Most countries have privacy laws about publishing info on people, so that matters a LOT 😭
Sending cleartext passwords is strongly discouraged when the transport underneath can't guarantee confidentiality and integrity. The reason is simple: the password could end up in the hands of someone who isn't supposed to have it 💀
Having multiple values for the 'userPassword' attribute is kind of a vibe-check situation, so be careful 🙈 Resetting or deleting a password as an administrator, without knowing the old one, gets tricky or even impossible when there are several values for different applications.
Applications that want to swap out the 'userPassword' value(s) for new ones should use modify/replaceValues (or modify/deleteAttribute+addAttribute). Server implementations are also encouraged to offer administrative controls that, when turned on, limit the 'userPassword' attribute to one value 🌈
Last thing, and it's an important one 👑 When this is used for authentication purposes [RFC4513], the user only has to prove they know one of the values, not all of them.
6. Acknowledgements 🌸
The definitions this document is built on were developed by committees for telecommunications and international standards, which is very impressive ngl 🧚
This document is an update of RFC 2256 by Mark Wahl. RFC 2256 came out of the IETF ASID Working Group 💜
The 'dc' attribute type definition and the 'dcObject' object class definition in this document supersede the specification in RFC 2247 by S. Kille, M. Wahl, A. Grimstad, R. Huber, and S. Sataluri 🦋
The 'uid' attribute type definition in this document supersedes the specification of the 'userid' in RFC 1274 by P. Barker and S. Kille, and the uid in RFC 2798 by M. Smith ✨
The 'uidObject' object class definition in this document supersedes the specification of the 'uidObject' in RFC 2377 by A. Grimstad, R. Huber, S. Sataluri, and M. Wahl 🎀
This document is based on input from the IETF LDAPBIS working group. The author would like to thank S. Legg and K. Zeilenga for their significant contribution to this update, and also Kathy Dally, who edited early versions of this document 🫶
7. References 📚
7.1. Normative References
- [E.123] Notation for national and international telephone numbers, ITU-T Recommendation E.123, 1988
- [E.164] The international public telecommunication numbering plan, ITU-T Recommendation E.164, 1997
- [F.1] Operational Provisions For The International Public Telegram Service Transmission System, CCITT Recommendation F.1, 1992
- [F.31] Telegram Retransmission System, CCITT Recommendation F.31, 1988
- [ISO3166] ISO 3166, "Codes for the representation of names of countries".
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
- [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
- [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
- [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
- [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
- [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
- [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
- [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
- [X.121] International numbering plan for public data networks, ITU-T Recommendation X.121, 1996
- [X.509] The Directory: Authentication Framework, ITU-T Recommendation X.509, 1993
- [X.520] The Directory: Selected Attribute Types, ITU-T Recommendation X.520, 1993
- [X.521] The Directory: Selected Object Classes. ITU-T Recommendation X.521, 1993
7.2. Informative References
- [RFC1274] Barker, P. and S. Kille, "The COSINE and Internet X.500 Schema", RFC 1274, November 1991.
- [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri, "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247, January 1998.
- [RFC2377] Grimstad, A., Huber, R., Sataluri, S., and M. Wahl, "Naming Plan for Internet Directory-Enabled Applications", RFC 2377, September 1998.
- [RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object Class", RFC 2798, April 2000.
- [RFC4513] Harrison R., Ed., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
- [RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates", RFC 4523, June 2006.
- [RFC4524] Zeilenga, E., Ed., "COSINE LDAP/X.500 Schema", RFC 4524, June 2006.
- [X.500] ITU-T Recommendations X.500 (1993) | ISO/IEC 9594-1:1994, Information Technology - Open Systems Interconnection - The Directory: Overview of concepts, models and services.
Appendix A. Changes Made Since RFC 2256 🧚
okay so this appendix is the glow-up log 💖 It lists everything that changed between RFC 2256 and RFC 4519. Quick reminder that it's informational only and not a normative part of the spec 🫶
- Replaced the document title ✨
- Removed the IESG Note 🧹
- Dependencies on RFC 1274 have been eliminated 👋
- Added a Security Considerations section and an IANA Considerations section 🔐
- Deleted the conformance requirement for subschema object classes in favor of a statement in [RFC4517] 📜
- Added explanation to attribute types and to each object class 🧠
- Removed Section 4, Syntaxes, and Section 6, Matching Rules, (moved to [RFC4517]) 🚚
- Removed the certificate-related attribute types:
authorityRevocationList,cACertificate,certificateRevocationList,crossCertificatePair,deltaRevocationList,supportedAlgorithms, anduserCertificate. Also removed the certificate-related Object Classes:certificationAuthority,certificationAuthority-V2,cRLDistributionPoint,strongAuthenticationUser, anduserSecurityInformation. LDAP PKI is now discussed in [RFC4523] 🔑 - Removed the
dmdName,knowledgeInformation,presentationAddress,protocolInformation, andsupportedApplicationContextattribute types and thedmd,applicationEntity, anddSAobject classes 🗑️ - Deleted the
aliasedObjectNameandobjectClassattribute type definitions. Deleted thealiasandtopobject class definitions. They are included in [RFC4512] 📦 - Added the
dcattribute type from RFC 2247, making the distinction between 'stored' and 'query' values when preparing IDN strings 🌐 - Numerous editorial changes 💅
- Removed upper bound after the SYNTAX oid in all attribute definitions where it appeared ✂️
- Added text about Unicode, SASLprep [RFC4013], and UTF-8 for
userPassword🔤 - Included definitions, comments and references for
dcObjectanduidObject🎀 - Replaced PKI schema references to use RFC 4523 🔁
- Spelt out and referenced ABNF on first usage 📖
- Removed Section 2.4 (Source). Replaced the source table with explicit references for each definition 🗂️
- All references to an attribute type or object class are enclosed in single quotes 💬
- The layout of attribute type definitions has been changed to provide consistency throughout the document. The new layout is:
> Section Heading
> Description of Attribute type
> Multivalued description
> Source Information
> Definition
> Example
> Additional CommentsAdding this consistent output included the addition of examples to some definitions 🪄
- References to alternate names for attributes types are provided with a reference to where they were originally specified 🏷️
- Clarification of the description of
distinguishedNameandname, in regards to these attribute types being supertypes 🧩 - Spelt out ISDN on first usage 📞
- Inserted a reference to [RFC4517] for the
teletexTerminalIdentifierdefinition's SYNTAX OID 🔗 - Additional names were added to the IANA Considerations. Names include
commonName,dcObject,domainComponent,GN,localityName,organizationName,organizationUnitName,surname,uidObjectanduserid🙌 - Renamed all instances of supercede to supersede ✏️
- Moved [F.1], [F.31] and [RFC4013] from informative to normative references 📚
- Changed the
cdefinition to be consistent with X.500 🌍
Author's Address 🖋️
Here's where the author lives, bestie 🦋
Andrew Sciberras
eB2Bcom
Suite 3, Woodhouse Corporate Centre,
935 Station Street,
Box Hill North, Victoria 3129
AUSTRALIA
Phone: +61 3 9896 7833
EMail: andrew.sciberras@eb2bcom.comFull Copyright Statement ⚖️
Copyright (C) The Internet Society (2006). 💜
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🔍
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 🌸
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 🫶✨
📦 where this page comes from
- ietf: rfc4519 2006-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms