RFC 4517
Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules
Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules 💖
RFC 4517 ✨
Okay bestie, here's the title block 🎀 This is RFC 4517, titled "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules." It came out of the Network Working Group in June 2006, and it's a Standards Track doc. The editor is S. Legg, Ed., from eB2Bcom 💅 It obsoletes RFC 2252 and RFC 2256, and it updates RFC 3698.
Status of This Memo 📜
This doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🦋 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸
Copyright Notice ©️
Copyright (C) The Internet Society (2006).
Abstract 🌈
Okay so every attribute stored in a Lightweight Directory Access Protocol (LDAP) directory has a defined syntax, and it's what keeps the structure and format of its values in check. This is only relevant if those values get transferred in the LDAP protocol 🧚 The comparison semantics for a syntax's values aren't part of the syntax definition. Instead, they come from separately defined matching rules. Those matching rules take an argument, called an assertion value, which also has its own defined syntax 👑 This document sets up a base set of syntaxes and matching rules for defining attributes in LDAP directories. It's giving foundation vibes ✨
Table of Contents 🍓
1. Introduction ....................................................3
2. Conventions .....................................................4
3. Syntaxes ........................................................4
3.1. General Considerations .....................................5
3.2. Common Definitions .........................................5
3.3. Syntax Definitions .........................................6
3.3.1. Attribute Type Description ..........................6
3.3.2. Bit String ..........................................6
3.3.3. Boolean .............................................7
3.3.4. Country String ......................................7
3.3.5. Delivery Method .....................................8
3.3.6. Directory String ....................................8
3.3.7. DIT Content Rule Description ........................9
3.3.8. DIT Structure Rule Description .....................10
3.3.9. DN .................................................10
3.3.10. Enhanced Guide ....................................11
3.3.11. Facsimile Telephone Number ........................12
3.3.12. Fax ...............................................12
3.3.13. Generalized Time ..................................13
3.3.14. Guide .............................................14
3.3.15. IA5 String ........................................15
3.3.16. Integer ...........................................15
3.3.17. JPEG ..............................................15
3.3.18. LDAP Syntax Description ...........................16
3.3.19. Matching Rule Description .........................16
3.3.20. Matching Rule Use Description .....................17
3.3.21. Name and Optional UID .............................17
3.3.22. Name Form Description .............................18
3.3.23. Numeric String ....................................18
3.3.24. Object Class Description ..........................18
3.3.25. Octet String ......................................19
3.3.26. OID ...............................................19
3.3.27. Other Mailbox .....................................20
3.3.28. Postal Address ....................................20
3.3.29. Printable String ..................................21
3.3.30. Substring Assertion ...............................22
3.3.31. Telephone Number ..................................23
3.3.32. Teletex Terminal Identifier .......................23
3.3.33. Telex Number ......................................24
3.3.34. UTC Time ..........................................24
4. Matching Rules .................................................25
4.1. General Considerations ....................................25
4.2. Matching Rule Definitions .................................27
4.2.1. bitStringMatch .....................................27
4.2.2. booleanMatch .......................................28
4.2.3. caseExactIA5Match ..................................28
4.2.4. caseExactMatch .....................................29
4.2.5. caseExactOrderingMatch .............................29
4.2.6. caseExactSubstringsMatch ...........................30
4.2.7. caseIgnoreIA5Match .................................30
4.2.8. caseIgnoreIA5SubstringsMatch .......................31
4.2.9. caseIgnoreListMatch ................................31
4.2.10. caseIgnoreListSubstringsMatch .....................32
4.2.11. caseIgnoreMatch ...................................33
4.2.12. caseIgnoreOrderingMatch ...........................33
4.2.13. caseIgnoreSubstringsMatch .........................34
4.2.14. directoryStringFirstComponentMatch ................34
4.2.15. distinguishedNameMatch ............................35
4.2.16. generalizedTimeMatch ..............................36
4.2.17. generalizedTimeOrderingMatch ......................36
4.2.18. integerFirstComponentMatch ........................36
4.2.19. integerMatch ......................................37
4.2.20. integerOrderingMatch ..............................37
4.2.21. keywordMatch ......................................38
4.2.22. numericStringMatch ................................38
4.2.23. numericStringOrderingMatch ........................39
4.2.24. numericStringSubstringsMatch ......................39
4.2.25. objectIdentifierFirstComponentMatch ...............40
4.2.26. objectIdentifierMatch .............................40
4.2.27. octetStringMatch ..................................41
4.2.28. octetStringOrderingMatch ..........................41
4.2.29. telephoneNumberMatch ..............................42
4.2.30. telephoneNumberSubstringsMatch ....................42
4.2.31. uniqueMemberMatch .................................43
4.2.32. wordMatch .........................................44
5. Security Considerations ........................................44
6. Acknowledgements ...............................................44
7. IANA Considerations ............................................45
8. References .....................................................46
8.1. Normative References ......................................46
8.2. Informative References ....................................48
Appendix A. Summary of Syntax Object Identifiers ..................49
Appendix B. Changes from RFC 2252 .................................491. Introduction 💫
Every attribute in an LDAP directory [RFC4510] whose values can be sent over the LDAP protocol [RFC4511] has a defined syntax (aka its data type), and that syntax keeps the structure and format of the values in line 💅 Comparison semantics aren't baked into the syntax. They're handled by separately defined matching rules instead. Matching rules take an argument, an assertion value, which also has a defined syntax. This document is giving you the base set of syntaxes and matching rules you need to define attributes for LDAP directories 🌸
Bestie, readers are advised to get familiar with the Directory Information Models [RFC4512] before reading the rest of this doc 📖 Section 3 has the definitions for the base set of LDAP syntaxes, and Section 4 has the definitions for the base set of LDAP matching rules 🧚
This document is an integral part of the LDAP technical specification [RFC4510], and it obsoletes the previous LDAP technical specification, RFC 3377, in its entirety 🦋
Here's the obsoleting tea ☕ Sections 4, 5, and 7 of RFC 2252 are obsoleted by [RFC4512]. The rest of RFC 2252 is obsoleted by this document. Sections 6 and 8 of RFC 2256 are obsoleted by this document. The rest of RFC 2256 is obsoleted by [RFC4519] and [RFC4512]. Everything except Section 2.11 of RFC 3698 is obsoleted by this document 😭
A bunch of schema elements from the last LDAP revision didn't make it into this one 💀 Public Key Infrastructure schema elements now live in [RFC4523]. Anything that isn't reintroduced in future technical specifications is considered Historic, so that's that 🥀
The changes from RFC 2252 are listed in Appendix B of this document 🎀
2. Conventions 🌷
Okay so when this doc uses the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", they're meant to be read as described in BCP 14, RFC 2119 [RFC2119]. Those are the official BCP 14 vibes, so don't freestyle them 🫶
Syntax definitions follow the <SyntaxDescription> ABNF [RFC4234] rule from [RFC4512]. Matching rule definitions follow the <MatchingRuleDescription> ABNF rule from [RFC4512] too. The one difference is that the definitions in this doc are line-wrapped so they're easier to read ✨ When they get sent as attribute values in the LDAP protocol (like the values of the ldapSyntaxes and matchingRules attributes [RFC4512], respectively), those values won't have any line breaks, so keep that in mind 💜
3. Syntaxes 🍓
Syntax definitions limit the structure of attribute values stored in an LDAP directory. They also decide how attribute and assertion values are represented when they're transferred in the LDAP protocol 💖
Syntaxes that are needed for directory operation, or that are commonly used, are specified in this section 🌈 Servers SHOULD recognize every syntax listed in this document. They aren't required to otherwise support them, but they MAY recognise or support other syntaxes too. Still, defining extra arbitrary syntaxes is discouraged, because it will hinder interoperability 🙈 Client and server implementations typically can't dynamically recognize new syntaxes either, so keep it simple, bestie 🧚
3.1. General Considerations
okay so bestie 💖 this part is about how values get written down for the wire 🎀 Each syntax says how its attribute or assertion values get represented when they're sent over the LDAP protocol [RFC4511]. This is called the LDAP-specific encoding, to tell it apart from other ways of encoding attribute values, like the Basic Encoding Rules (BER) encoding [BER] that X.500 [X.500] directories use 🧚
The LDAP-specific encoding of any attribute syntax always produces octet-aligned values ✨ As much as possible, encoding rules for LDAP syntaxes should make character strings that clients implementing LDAP can display with little or no translation 💅 BUT clients MUST NOT assume that the LDAP-specific encoding of a value from an unrecognized syntax is a human-readable character string 🙈 There are a few cases, like the JPEG syntax, where a human-readable version just isn't reasonable 💀
Each LDAP syntax is uniquely identified by an object identifier [ASN.1] written in dotted-decimal format. Syntaxes don't get short descriptive names, sorry not sorry 🦋 These object identifiers aren't meant to be shown to users. The ones for the syntaxes defined in this document are summarised in Appendix A.
A suggested minimum upper bound on the number of characters in a value with a string-based syntax, or the number of octets in a value for every other syntax, MAY be shown by appending the bound inside curly braces after the syntax's OBJECT IDENTIFIER in an attribute type definition (see the <noidlen> rule in [RFC4512]) 🌸 That bound isn't considered part of the syntax identifier, so it doesn't change which syntax you're using.
For example, 1.3.6.1.4.1.1466.115.121.1.15{64} in an attribute definition suggests that the directory server will allow a value of the attribute to be up to 64 characters long, although it may allow longer character strings. Note that a single character of the Directory String syntax can be encoded in more than one octet, since UTF-8 [RFC3629] is a variable-length encoding. Therefore, a 64-character string may be more than 64 octets in length 🫶
3.2. Common Definitions
The following ABNF rules get used in a bunch of the syntax definitions in Section 3.3 🎀
PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
PLUS / COMMA / HYPHEN / DOT / EQUALS /
SLASH / COLON / QUESTION / SPACE
PrintableString = 1*PrintableCharacter
IA5String = *(%x00-7F)
SLASH = %x2F ; forward slash ("/")
COLON = %x3A ; colon (":")
QUESTION = %x3F ; question mark ("?")The <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, <COMMA>, <HYPHEN>, <DOT>, <EQUALS>, and <SPACE> rules are defined in [RFC4512] 💜
3.3. Syntax Definitions
3.3.1. Attribute Type Description
A value of the Attribute Type Description syntax is the definition of an attribute type 📚 The LDAP-specific encoding of a value of this syntax is defined by the <AttributeTypeDescription> rule in [RFC4512].
For example, the following definition of the createTimestamp attribute type from [RFC4512] is also a value of the Attribute Type Description syntax. (Note: Line breaks have been added for readability; they are not part of the value when transferred in protocol.) 🌈
( 2.5.18.1 NAME 'createTimestamp'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )The LDAP definition for the Attribute Type Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )This syntax corresponds to the AttributeTypeDescription ASN.1 type from [X.501] ✨
3.3.2. Bit String
A value of the Bit String syntax is a sequence of binary digits 🔥 The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
BitString = SQUOTE *binary-digit SQUOTE "B"
binary-digit = "0" / "1"The <SQUOTE> rule is defined in [RFC4512].
Example:
'0101111101'BThe LDAP definition for the Bit String syntax is:
( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )This syntax corresponds to the BIT STRING ASN.1 type from [ASN.1] 🦋
3.3.3. Boolean
A value of the Boolean syntax is one of the Boolean values, true or false 👑 The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
Boolean = "TRUE" / "FALSE"The LDAP definition for the Boolean syntax is:
( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1] 🍓
3.3.4. Country String
A value of the Country String syntax is one of the two-character codes from ISO 3166 [ISO3166] for representing a country 🌍 The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
CountryString = 2(PrintableCharacter)The <PrintableCharacter> rule is defined in Section 3.2.
Examples:
US
AUThe LDAP definition for the Country String syntax is:
( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )This syntax corresponds to the following ASN.1 type from [X.520]:
PrintableString (SIZE (2)) -- ISO 3166 codes only3.3.5. Delivery Method
A value of the Delivery Method syntax is a sequence of items that indicate, in preference order, the service(s) by which an entity is willing and/or capable of receiving messages 📬 The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
DeliveryMethod = pdm *( WSP DOLLAR WSP pdm )
pdm = "any" / "mhs" / "physical" / "telex" / "teletex" /
"g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"The <WSP> and <DOLLAR> rules are defined in [RFC4512].
Example:
telephone $ videotexThe LDAP definition for the Delivery Method syntax is:
( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )This syntax corresponds to the following ASN.1 type from [X.520]:
SEQUENCE OF INTEGER {
any-delivery-method (0),
mhs-delivery (1),
physical-delivery (2),
telex-delivery (3),
teletex-delivery (4),
g3-facsimile-delivery (5),
g4-facsimile-delivery (6),
ia5-terminal-delivery (7),
videotex-delivery (8),
telephone-delivery (9) }3.3.6. Directory String
A value of the Directory String syntax is a string of one or more arbitrary characters from the Universal Character Set (UCS) [UCS] 🌏 A zero-length character string is not permitted. The LDAP-specific encoding of a value of this syntax is the UTF-8 encoding [RFC3629] of the character string. Such encodings conform to the following ABNF:
DirectoryString = 1*UTF8The <UTF8> rule is defined in [RFC4512].
Example:
This is a value of Directory String containing #!%#@.Servers and clients MUST be prepared to receive arbitrary UCS code points, including code points outside the range of printable ASCII and code points not presently assigned to any character. This one is a big deal, bestie 😭
Attribute type definitions using the Directory String syntax should not restrict the format of Directory String values, for example by requiring that the character string conforms to specific patterns described by ABNF. A new syntax should be defined in such cases 🙅♀️
The LDAP definition for the Directory String syntax is:
( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )This syntax corresponds to the DirectoryString parameterized ASN.1 type from [X.520].
The DirectoryString ASN.1 type allows a choice between the TeletexString, PrintableString, or UniversalString ASN.1 types from [ASN.1]. However, note that the chosen alternative is not indicated in the LDAP-specific encoding of a Directory String value 🤔
Implementations that convert Directory String values from the LDAP-specific encoding to the BER encoding used by X.500 must choose an alternative that permits the particular characters in the string, and must convert the characters from the UTF-8 encoding into the character encoding of the chosen alternative. When converting Directory String values from the BER encoding to the LDAP-specific encoding, the characters must be converted from the character encoding of the chosen alternative into the UTF-8 encoding. These conversions SHOULD be done in a manner consistent with the Transcode step of the string preparation algorithms [RFC4518] for LDAP 🔁
3.3.7. DIT Content Rule Description
A value of the DIT Content Rule Description syntax is the definition of a DIT (Directory Information Tree) content rule 🌳 The LDAP-specific encoding of a value of this syntax is defined by the <DITContentRuleDescription> rule in [RFC4512].
Example:
( 2.5.6.4 DESC 'content rule for organization'
NOT ( x121Address $ telexNumber ) )Note: A line break has been added for readability; it is not part of the value.
The LDAP definition for the DIT Content Rule Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.16
DESC 'DIT Content Rule Description' )This syntax corresponds to the DITContentRuleDescription ASN.1 type from [X.501] 🎀
3.3.8. DIT Structure Rule Description
A value of the DIT Structure Rule Description syntax is the definition of a DIT structure rule 🧩 The LDAP-specific encoding of a value of this syntax is defined by the <DITStructureRuleDescription> rule in [RFC4512].
Example:
( 2 DESC 'organization structure rule' FORM 2.5.15.3 )The LDAP definition for the DIT Structure Rule Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.17
DESC 'DIT Structure Rule Description' )This syntax corresponds to the DITStructureRuleDescription ASN.1 type from [X.501] 💜
3.3.9. DN
A value of the DN syntax is the (purported) distinguished name (DN) of an entry [RFC4512] 🦋 The LDAP-specific encoding of a value of this syntax is defined by the <distinguishedName> rule from the string representation of distinguished names [RFC4514].
Examples (from [RFC4514]):
UID=jsmith,DC=example,DC=net
OU=Sales+CN=J. Smith,DC=example,DC=net
CN=John Smith\, III,DC=example,DC=net
CN=Before\0dAfter,DC=example,DC=net
1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com
CN=Lu\C4\8Di\C4\87The LDAP definition for the DN syntax is:
( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )The DN syntax corresponds to the DistinguishedName ASN.1 type from [X.501]. Note that a BER encoded distinguished name (as used by X.500) re-encoded into the LDAP-specific encoding is not necessarily reversible to the original BER encoding, since the chosen string type in any DirectoryString components of the distinguished name is not indicated in the LDAP-specific encoding of the distinguished name (see Section 3.3.6). It's giving "read the fine print" energy 🙈✨
3.3.10. Enhanced Guide ✨
okay so the Enhanced Guide syntax is giving search criteria 💅 Those criteria are combos of attribute types and filter operators, and you use them to build filters that hunt down entries of specific object classes. The big upgrade over the plain Guide syntax is that you get to say how deep the search should go 🔍🌸
The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
EnhancedGuide = object-class SHARP WSP criteria WSP
SHARP WSP subset
object-class = WSP oid WSP
subset = "baseobject" / "oneLevel" / "wholeSubtree"
criteria = and-term *( BAR and-term )
and-term = term *( AMPERSAND term )
term = EXCLAIM term /
attributetype DOLLAR match-type /
LPAREN criteria RPAREN /
true /
false
match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX"
true = "?true"
false = "?false"
BAR = %x7C ; vertical bar ("|")
AMPERSAND = %x26 ; ampersand ("&")
EXCLAIM = %x21 ; exclamation mark ("!")The <SHARP>, <WSP>, <oid>, <LPAREN>, <RPAREN>, <attributetype>, and <DOLLAR> rules are defined in [RFC4512] 🎀
The LDAP definition for the Enhanced Guide syntax is:
( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
Example:
person#(sn$EQ)#oneLevelThe Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type from [X.520]. That EnhancedGuide type references the Criteria ASN.1 type, also from [X.520] 🧚 The <true> rule stands for an empty "and" expression in a value of the Criteria type, and the <false> rule stands for an empty "or" expression in a value of the Criteria type. iykyk 🫶
3.3.11. Facsimile Telephone Number 📠
a value of the Facsimile Telephone Number syntax is a subscriber number for a fax machine on the public switched telephone network. The LDAP-specific encoding is defined by this ABNF:
fax-number = telephone-number *( DOLLAR fax-parameter )
telephone-number = PrintableString
fax-parameter = "twoDimensional" /
"fineResolution" /
"unlimitedLength" /
"b4Length" /
"a3Width" /
"b4Width" /
"uncompressed"the <telephone-number> is a string of printable characters that follows the internationally agreed format for international telephone numbers [E.123]. The <PrintableString> rule is defined in Section 3.2, and the <DOLLAR> rule is defined in [RFC4512] 💖
The LDAP definition for the Facsimile Telephone Number syntax is:
( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number')This syntax corresponds to the FacsimileTelephoneNumber ASN.1 type from [X.520].
3.3.12. Fax 🖨️
a value of the Fax syntax is an image made with the Group 3 facsimile process [FAX] to copy an object, like a memo 📄 The LDAP-specific encoding is the string of octets for a Group 3 Fax image, as defined in [FAX].
The LDAP definition for the Fax syntax is:
( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )The ASN.1 type that goes with the Fax syntax is defined like this, assuming EXPLICIT TAGS:
Fax ::= CHOICE {
g3-facsimile [3] G3FacsimileBodyPart
}The G3FacsimileBodyPart ASN.1 type is defined in [X.420].
3.3.13. Generalized Time ⏰
a value of the Generalized Time syntax is a character string that represents a date and time. The LDAP-specific encoding is a restricted version of the format defined in [ISO8601], described by this ABNF:
GeneralizedTime = century year month day hour
[ minute [ second / leap-second ] ]
[ fraction ]
g-time-zone
century = 2(%x30-39) ; "00" to "99"
year = 2(%x30-39) ; "00" to "99"
month = ( %x30 %x31-39 ) ; "01" (January) to "09"
/ ( %x31 %x30-32 ) ; "10" to "12"
day = ( %x30 %x31-39 ) ; "01" to "09"
/ ( %x31-32 %x30-39 ) ; "10" to "29"
/ ( %x33 %x30-31 ) ; "30" to "31"
hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23"
minute = %x30-35 %x30-39 ; "00" to "59"
second = ( %x30-35 %x30-39 ) ; "00" to "59"
leap-second = ( %x36 %x30 ) ; "60"
fraction = ( DOT / COMMA ) 1*(%x30-39)
g-time-zone = %x5A ; "Z"
/ g-differential
g-differential = ( MINUS / PLUS ) hour [ minute ]
MINUS = %x2D ; minus sign ("-")The <DOT>, <COMMA>, and <PLUS> rules are defined in [RFC4512] 🧃
ngl this part is a little tricky 🙈 The ABNF will happily match strings that aren't real dates or times, like February 31, 1994. Those strings SHOULD be considered invalid for this syntax, so don't let them slide 💀
The time value is coordinated universal time (the same thing as Greenwich Mean Time) when the "Z" form of <g-time-zone> is used. Otherwise, the value is a local time in the time zone shown by <g-differential>, and you can get the coordinated universal time by subtracting the differential from the local time. The "Z" form of <g-time-zone> SHOULD be used in preference to <g-differential> 🌈
If <minute> is left out, <fraction> is a fraction of an hour. If <minute> is there but <second> and <leap-second> are left out, <fraction> is a fraction of a minute. Otherwise, <fraction> is a fraction of a second ✨
Examples:
199412161032Z
199412160532-0500Both example values are the exact same coordinated universal time: 10:32 AM, December 16, 1994. Two ways to say the same moment, periodt 💅
The LDAP definition for the Generalized Time syntax is:
( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )This syntax corresponds to the GeneralizedTime ASN.1 type from [ASN.1], with one constraint: local time without a differential SHALL NOT be used 🚫
3.3.14. Guide 🧭
a value of the Guide syntax suggests criteria, which are combos of attribute types and filter operators, to use when building filters that search for entries of particular object classes. The Guide syntax is obsolete and should not be used for defining new attribute types 🥀
The LDAP-specific encoding is defined by this ABNF:
Guide = [ object-class SHARP ] criteriaThe <object-class> and <criteria> rules are defined in Section 3.3.10. The <SHARP> rule is defined in [RFC4512] 🎀
The LDAP definition for the Guide syntax is:
( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )The Guide syntax corresponds to the Guide ASN.1 type from [X.520].
3.3.15. IA5 String 🔤
a value of the IA5 String syntax is a string of zero, one, or more characters from International Alphabet 5 (IA5) [T.50], which is the international version of ASCII. The LDAP-specific encoding is the unconverted string of characters, and it has to match the <IA5String> rule in Section 3.2 🦋
The LDAP definition for the IA5 String syntax is:
( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )This syntax corresponds to the IA5String ASN.1 type from [ASN.1].
3.3.16. Integer 🔢
a value of the Integer syntax is a whole number of unlimited magnitude 🌟 The LDAP-specific encoding is the optionally signed decimal digit string for the number. For example, the number 1321 is written as the character string "1321". The encoding is defined by this ABNF:
Integer = ( HYPHEN LDIGIT *DIGIT ) / numberThe <HYPHEN>, <LDIGIT>, <DIGIT>, and <number> rules are defined in [RFC4512] 💜
The LDAP definition for the Integer syntax is:
( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )This syntax corresponds to the INTEGER ASN.1 type from [ASN.1].
3.3.17. JPEG 📸
a value of the JPEG syntax is an image in the JPEG File Interchange Format (JFIF), as described in [JPEG]. The LDAP-specific encoding is the sequence of octets of the JFIF encoding of the image 🌸
The LDAP definition for the JPEG syntax is:
( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )The JPEG syntax corresponds to this ASN.1 type:
JPEG ::= OCTET STRING (CONSTRAINED BY
{ -- contents octets are an image in the --
-- JPEG File Interchange Format -- })3.3.18. LDAP Syntax Description 📖
a value of the LDAP Syntax Description syntax is the description of an LDAP syntax. The LDAP-specific encoding is defined by the <SyntaxDescription> rule in [RFC4512] 🪞
The LDAP definition for the LDAP Syntax Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )The above LDAP definition is itself a legal value of the LDAP Syntax Description syntax. Very meta, very iconic 🤌
The ASN.1 type that goes with the LDAP Syntax Description syntax is defined as follows, assuming EXPLICIT TAGS:
LDAPSyntaxDescription ::= SEQUENCE {
identifier OBJECT IDENTIFIER,
description DirectoryString { ub-schema } OPTIONAL }The DirectoryString parameterized ASN.1 type is defined in [X.520].
The value of ub-schema (an integer) is implementation defined. A non-normative definition appears in [X.520] 🙃
3.3.19. Matching Rule Description 🧩
a value of the Matching Rule Description syntax is the definition of a matching rule. The LDAP-specific encoding is defined by the <MatchingRuleDescription> rule in [RFC4512] 🎯
Example:
( 2.5.13.2 NAME 'caseIgnoreMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )Note: A line break has been added for readability; it is not part of the syntax. Not part of the syntax, just vibes for your eyeballs 👀
The LDAP definition for the Matching Rule Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )This syntax corresponds to the MatchingRuleDescription ASN.1 type from [X.501].
3.3.20. Matching Rule Use Description 🎀
a value of the Matching Rule Use Description syntax shows which attribute types a matching rule can be applied to in an extensibleMatch search filter [RFC4511] 🔍 The LDAP-specific encoding is defined by the <MatchingRuleUseDescription> rule in [RFC4512] 💅
Example:
( 2.5.13.16 APPLIES ( givenName $ surname ) )The LDAP definition for the Matching Rule Use Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.31
DESC 'Matching Rule Use Description' )This syntax corresponds to the MatchingRuleUseDescription ASN.1 type from [X.501] 🦋
3.3.21. Name and Optional UID 💖
okay so a value of this syntax is a distinguished name [RFC4512] for an entity, and it can optionally come with a unique identifier 🦋. that ID is there to tell the entity apart from others that have the exact same DN. main character energy for sure ✨
the LDAP-specific encoding is defined by this ABNF:
NameAndOptionalUID = distinguishedName [ SHARP BitString ]the <BitString> rule is in Section 3.3.2. the <distinguishedName> rule is in [RFC4514]. the <SHARP> rule is in [RFC4512].
ngl the # character can show up in a DN's string form, but when a <distinguishedName> gets encoded inside a <NameAndOptionalUID>, it does NOT get extra escaping 🙈 so don't go escaping it again, bestie.
Example:
1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'Bthe LDAP definition for this syntax is:
( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )this syntax lines up with the NameAndOptionalUID ASN.1 type from [X.520] 🎀
3.3.22. Name Form Description 📝
a value of this syntax is the definition of a name form, which controls how entries are allowed to be named 👑 the LDAP-specific encoding is given by the <NameFormDescription> rule in [RFC4512].
Example:
( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o )the LDAP definition for the Name Form Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )and this one corresponds to the NameFormDescription ASN.1 type from [X.501] 🌸
3.3.23. Numeric String 🔢
a value of the Numeric String syntax is one or more numerals and spaces, so it's giving number soup with gaps 🍓 the LDAP-specific encoding is the unconverted string of characters, and it follows this ABNF:
NumericString = 1*(DIGIT / SPACE)the <DIGIT> and <SPACE> rules are defined in [RFC4512].
Example:
15 079 672 281the LDAP definition for the Numeric String syntax is:
( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )it corresponds to the NumericString ASN.1 type from [ASN.1] 💅
3.3.24. Object Class Description 🧚
a value of this syntax is the definition of an object class 💜 the LDAP-specific encoding is defined by the <ObjectClassDescription> rule in [RFC4512].
Example:
( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c
MAY ( searchGuide $ description ) )Note: a line break was added here for readability. it isn't part of the syntax, so don't go copying it in 🙏
the LDAP definition for the Object Class Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )this syntax corresponds to the ObjectClassDescription ASN.1 type from [X.501] ✨
3.3.25. Octet String 🫧
a value of the Octet String syntax is zero, one, or more arbitrary octets, which is a total free-for-all honestly 🌈 the LDAP-specific encoding is the unconverted sequence of octets, following this ABNF:
OctetString = *OCTETthe <OCTET> rule is defined in [RFC4512]. values of this syntax are not generally human-readable, so don't expect to read them with your eyes 👀
the LDAP definition for the Octet String syntax is:
( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )it corresponds to the OCTET STRING ASN.1 type from [ASN.1] 💖
3.3.26. OID 🦄
a value of the OID syntax is an object identifier: two or more non-negative integers that uniquely identify some object or item of specification 🔥 a bunch of OIDs used in LDAP also have IANA registered names [RFC4520], which is super convenient.
the LDAP-specific encoding is defined by the <oid> rule in [RFC4512].
Examples:
1.2.3.4
cnthe LDAP definition for the OID syntax is:
( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )it corresponds to the OBJECT IDENTIFIER ASN.1 type from [ASN.1] 👑
3.3.27. Other Mailbox 📬
a value of the Other Mailbox syntax identifies an electronic mailbox inside a particular named mail system 💌 the LDAP-specific encoding is defined by this ABNF:
OtherMailbox = mailbox-type DOLLAR mailbox
mailbox-type = PrintableString
mailbox = IA5Stringthe <mailbox-type> rule is the kind of mail system the mailbox lives in (for example, "MCIMail"), and <mailbox> is the actual mailbox inside the system that <mailbox-type> describes. the <PrintableString> and <IA5String> rules are defined in Section 3.2. the <DOLLAR> rule is defined in [RFC4512].
the LDAP definition for the Other Mailbox syntax is:
( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )the ASN.1 type that matches the Other Mailbox syntax is defined like this, assuming EXPLICIT TAGS:
OtherMailbox ::= SEQUENCE {
mailboxType PrintableString,
mailbox IA5String
}3.3.28. Postal Address 🏡
a value of the Postal Address syntax is a sequence of strings of one or more arbitrary UCS characters, which together form an address in a physical mail system 📮 the LDAP-specific encoding is defined by this ABNF:
PostalAddress = line *( DOLLAR line )
line = 1*line-char
line-char = %x00-23
/ (%x5C "24") ; escaped "$"
/ %x25-5B
/ (%x5C "5C") ; escaped "\"
/ %x5D-7F
/ UTFMBeach character string (aka <line>) of a postal address value is encoded as a UTF-8 [RFC3629] string. the one exception is "" and "$" characters, which, if they show up, get escaped with a "" followed by the two hexadecimal digit code for the character 🫶 the <DOLLAR> and <UTFMB> rules are defined in [RFC4512].
ngl this is a real vibe check: many servers limit the postal address to no more than six lines of no more than thirty characters each 🙈
Example:
1234 Main St.$Anytown, CA 12345$USA
\241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USAthe LDAP definition for the Postal Address syntax is:
( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )this syntax corresponds to the PostalAddress ASN.1 type from [X.520]. that is:
PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF
DirectoryString { ub-postal-string }the values of ub-postal-line and ub-postal-string (both integers) are implementation defined. non-normative definitions show up in [X.520] 🌷
3.3.29. Printable String 🖨️
a value of the Printable String syntax is a string of one or more latin alphabetic, numeric, and selected punctuation characters, as spelled out by the <PrintableCharacter> rule in Section 3.2 💫 the LDAP-specific encoding is the unconverted string of characters, which matches the <PrintableString> rule in Section 3.2.
Example:
This is a PrintableString.the LDAP definition for the PrintableString syntax is:
( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )it corresponds to the PrintableString ASN.1 type from [ASN.1] 🧁
3.3.30. Substring Assertion 🔍
a value of the Substring Assertion syntax is a sequence of zero, one, or more character substrings. it's used as an argument for substring extensible matching of character string attribute values, which is to say it's the matchValue of a MatchingRuleAssertion [RFC4511] 🎯 each substring is a string of one or more arbitrary characters from the Universal Character Set (UCS) [UCS]. a zero-length substring is not permitted, so no empty ones, babe 🚫
the LDAP-specific encoding is defined by this ABNF:
SubstringAssertion = [ initial ] any [ final ]
initial = substring
any = ASTERISK *(substring ASTERISK)
final = substring
ASTERISK = %x2A ; asterisk ("*")
substring = 1*substring-character
substring-character = %x00-29
/ (%x5C "2A") ; escaped "*"
/ %x2B-5B
/ (%x5C "5C") ; escaped "\"
/ %x5D-7F
/ UTFMBeach <substring> of a Substring Assertion value is encoded as a UTF-8 [RFC3629] string. "" and "*" characters, if they're in the substring, get escaped with a "" followed by the two hexadecimal digit code for the character 🌸
the Substring Assertion syntax is only used as the syntax of assertion values in the extensible match. it is not used as an attribute syntax, and it isn't used in the SubstringFilter [RFC4511] ✋
the LDAP definition for the Substring Assertion syntax is:
( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )it corresponds to the SubstringAssertion ASN.1 type from [X.520] 💅
3.3.31. Telephone Number 📞
a value of the Telephone Number syntax is a string of printable characters that follows the internationally agreed format for international telephone numbers [E.123] 🌍 the LDAP-specific encoding is the unconverted string of characters, which matches the <PrintableString> rule in Section 3.2.
Examples:
+1 512 315 0280
+1-512-315-0280
+61 3 9896 7830the LDAP definition for the Telephone Number syntax is:
( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )the Telephone Number syntax corresponds to this ASN.1 type from [X.520]:
PrintableString (SIZE(1..ub-telephone-number))the value of ub-telephone-number (an integer) is implementation defined. a non-normative definition appears in [X.520] ✨
3.3.32. Teletex Terminal Identifier 🖥️
a value of this syntax specifies the identifier and, optionally, the parameters of a teletex terminal 💜 the LDAP-specific encoding is defined by this ABNF:
teletex-id = ttx-term *(DOLLAR ttx-param)
ttx-term = PrintableString ; terminal identifier
ttx-param = ttx-key COLON ttx-value ; parameter
ttx-key = "graphic" / "control" / "misc" / "page" / "private"
ttx-value = *ttx-value-octet
ttx-value-octet = %x00-23
/ (%x5C "24") ; escaped "$"
/ %x25-5B
/ (%x5C "5C") ; escaped "\"
/ %x5D-FFthe <PrintableString> and <COLON> rules are defined in Section 3.2. the <DOLLAR> rule is defined in [RFC4512].
the LDAP definition for the Teletex Terminal Identifier syntax is:
( 1.3.6.1.4.1.1466.115.121.1.51
DESC 'Teletex Terminal Identifier' )this syntax corresponds to the TeletexTerminalIdentifier ASN.1 type from [X.520] 🦋
3.3.33. Telex Number 📠
a value of the Telex Number syntax specifies the telex number, country code, and answerback code of a telex terminal 🌷 the LDAP-specific encoding is defined by this ABNF:
telex-number = actual-number DOLLAR country-code
DOLLAR answerback
actual-number = PrintableString
country-code = PrintableString
answerback = PrintableStringthe <PrintableString> rule is defined in Section 3.2. the <DOLLAR> rule is defined in [RFC4512].
the LDAP definition for the Telex Number syntax is:
( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )this syntax corresponds to the TelexNumber ASN.1 type from [X.520] 🎀
3.3.34. UTC Time ⏰
okay so UTC Time is a character string that holds a date and time, precise to either the minute or the second 🕐. The year is just two digits, which is very vintage of it 📼. LDAP encodes it the way ASN.1's UTCTime type does [ASN.1], and the ABNF looks like this:
UTCTime = year month day hour minute [ second ]
[ u-time-zone ]
u-time-zone = %x5A ; "Z"
/ u-differential
u-differential = ( MINUS / PLUS ) hour minuteThe year, month, day, hour, minute, second, and MINUS rules all come from Section 3.3.13 🎀. The PLUS rule comes from [RFC4512] 💜.
Heads up bestie, the ABNF will let through strings that aren't real dates or times in the Gregorian calendar 🙈. Those strings SHOULD be considered invalid for this syntax 🚫.
The time is coordinated universal time if you use the Z form of u-time-zone 🌍. If you don't, it's local time instead 🏠. In that case, if a u-differential is included, you can work out UTC by subtracting the differential from the local time 🧮. The u-time-zone SHOULD be present in time values ⭐, and the Z form SHOULD be used in preference to u-differential 💅.
The LDAP definition for the UTC Time syntax is:
( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )Note: This syntax is deprecated in favor of the Generalized Time syntax. 🥀
The UTC Time syntax corresponds to the UTCTime ASN.1 type from [ASN.1] 🔗.
4. Matching Rules 💅
Matching rules are how directory implementations compare attribute values against assertion values when they run Search and Compare operations [RFC4511] 🔍. They also come in clutch when comparing a purported distinguished name [RFC4512] with the name of an entry 🪪. And when you're modifying entries, they help figure out which values to delete and stop an attribute from holding two equal values 🙅♀️.
Matching rules that are required for directory operation, or that are in common use, are specified in this section ✨.
4.1. General Considerations 🧠
A matching rule gets applied to attribute values through an AttributeValueAssertion or MatchingRuleAssertion [RFC4511] 🎯. The conditions under which one of those evaluates to Undefined are specified elsewhere [RFC4511] 🫠. If an assertion isn't Undefined, the result is whatever you get from applying the selected matching rule 🧃. A matching rule evaluates to TRUE, and sometimes Undefined, as spelled out in its own description ✅. Otherwise it evaluates to FALSE ❌.
Each assertion has an assertion value 💌. Each matching rule's definition says what syntax that assertion value needs to be 📝. Usually the assertion value uses the same syntax as the attribute values the rule can be applied to, but not always 🤷♀️. Also, an AssertionValue inside a SubstringFilter [RFC4511] follows the assertion syntax of the equality matching rule for that attribute type, NOT the substrings matching rule 👀. Conceptually, the whole SubstringFilter gets turned into an assertion value of the substrings matching rule before the rule runs 🧩.
Each matching rule's definition says which attribute syntaxes it can be applied to, by listing conditions the ASN.1 type of a candidate attribute syntax has to satisfy 📋. Those conditions are also met if the ASN.1 type is a tagged or constrained derivative of the type named in the rule description (so ASN.1 tags and constraints get ignored when checking applicability) 🏷️, or if it's just an alternative reference notation for that type 🔁. Each rule description lists, as examples, the complete set of syntaxes defined in this document that the rule applies to 📚. A matching rule might also apply to extra syntaxes defined in other documents, as long as those syntaxes meet the ASN.1 type conditions 🌈.
Each matching rule description says whether the rule is good for use as the equality matching rule (EQUALITY), the ordering matching rule (ORDERING), or the substrings matching rule (SUBSTR) in an attribute type definition [RFC4512] 🧁.
Every matching rule is uniquely identified with an object identifier 🆔. A matching rule's definition should not subsequently be changed 🔒. If you really need a change, define a new matching rule with a different object identifier instead 🪄.
Servers MAY implement the wordMatch and keywordMatch matching rules 🌸, but they SHOULD implement the other matching rules in Section 4.2 💖. Servers MAY implement additional matching rules 🎁.
Servers that implement the extensibleMatch filter SHOULD allow the matching rules listed in Section 4.2 to be used in the extensibleMatch filter 🪄. They SHOULD also allow matching rules to be used with all attribute types known to the server, as long as the assertion syntax of the matching rule is the same as the value syntax of the attribute 💅.
Servers MUST publish, in the matchingRules attribute, the definitions of matching rules that are referenced by values of the attributeTypes and matchingRuleUse attributes in the same subschema entry 📣. Other unreferenced matching rules MAY be published in the matchingRules attribute 🫶.
If the server supports the extensibleMatch filter, then the server MAY use the matchingRuleUse attribute to indicate which matching rules apply (in an extensibleMatch filter) to nominated attribute types 🎀.
4.2. Matching Rule Definitions 🌷
Nominated character strings in assertion and attribute values are prepared according to the string preparation algorithms [RFC4518] for LDAP when evaluating the following matching rules 🧼:
numericStringMatch,
numericStringSubstringsMatch,
caseExactMatch,
caseExactOrderingMatch,
caseExactSubstringsMatch,
caseExactIA5Match,
caseIgnoreIA5Match,
caseIgnoreIA5SubstringsMatch,
caseIgnoreListMatch,
caseIgnoreListSubstringsMatch,
caseIgnoreMatch,
caseIgnoreOrderingMatch,
caseIgnoreSubstringsMatch,
directoryStringFirstComponentMatch,
telephoneNumberMatch,
telephoneNumberSubstringsMatch and
wordMatch.The Transcode, Normalize, Prohibit, and Check bidi steps are the same for each of the matching rules 🔁. The Map and Insignificant Character Handling steps, though, depend on the specific rule, as detailed in the descriptions of these matching rules in the sections that follow 🧭.
4.2.1. bitStringMatch 🔢
The bitStringMatch rule compares an assertion value of the Bit String syntax to an attribute value of a syntax (e.g., the Bit String syntax) whose corresponding ASN.1 type is BIT STRING 🧷.
If the corresponding ASN.1 type of the attribute syntax doesn't have a named bit list [ASN.1] (which is the case for the Bit String syntax), then the rule evaluates to TRUE if and only if the attribute value has the same number of bits as the assertion value and the bits match on a bitwise basis 🧮.
If the corresponding ASN.1 type does have a named bit list, then bitStringMatch works as above, except that trailing zero bits in the attribute and assertion values are treated as absent 🫥.
The LDAP definition for the bitStringMatch rule is:
( 2.5.13.16 NAME 'bitStringMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )The bitStringMatch rule is an equality matching rule 💜.
4.2.2. booleanMatch ✅
The booleanMatch rule compares an assertion value of the Boolean syntax to an attribute value of a syntax (e.g., the Boolean syntax) whose corresponding ASN.1 type is BOOLEAN 🔘.
The rule evaluates to TRUE if and only if the attribute value and the assertion value are both TRUE or both FALSE 👯♀️.
The LDAP definition for the booleanMatch rule is:
( 2.5.13.13 NAME 'booleanMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )The booleanMatch rule is an equality matching rule 🩷.
4.2.3. caseExactIA5Match 🔤
The caseExactIA5Match rule compares an assertion value of the IA5 String syntax to an attribute value of a syntax (e.g., the IA5 String syntax) whose corresponding ASN.1 type is IA5String 🇺🇸.
The rule evaluates to TRUE if and only if the prepared attribute value character string and the prepared assertion value character string have the same number of characters and corresponding characters have the same code point 🎯.
When preparing the attribute value and assertion value for comparison, characters are NOT case folded in the Map preparation step 🙅♀️, and only Insignificant Space Handling is applied in the Insignificant Character Handling step 🫧.
The LDAP definition for the caseExactIA5Match rule is:
( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )The caseExactIA5Match rule is an equality matching rule 💖.
4.2.4. caseExactMatch 🔠
The caseExactMatch rule compares an assertion value of the Directory String syntax to an attribute value of a syntax (e.g., the Directory String, Printable String, Country String, or Telephone Number syntax) whose corresponding ASN.1 type is DirectoryString, or one of the alternative string types of DirectoryString, such as PrintableString (the other alternatives don't correspond to any syntax defined in this document) 📜.
The rule evaluates to TRUE if and only if the prepared attribute value character string and the prepared assertion value character string have the same number of characters and corresponding characters have the same code point 🎯.
When preparing the attribute value and assertion value for comparison, characters are NOT case folded in the Map preparation step 🙅♀️, and only Insignificant Space Handling is applied in the Insignificant Character Handling step 🫧.
The LDAP definition for the caseExactMatch rule is:
( 2.5.13.5 NAME 'caseExactMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )The caseExactMatch rule is an equality matching rule 🌸.
4.2.5. caseExactOrderingMatch 📏
The caseExactOrderingMatch rule compares an assertion value of the Directory String syntax to an attribute value of a syntax (e.g., the Directory String, Printable String, Country String, or Telephone Number syntax) whose corresponding ASN.1 type is DirectoryString or one of its alternative string types 🧾.
The rule evaluates to TRUE if and only if, in the code point collation order, the prepared attribute value character string appears earlier than the prepared assertion value character string 🏃♀️. In other words, the attribute value is "less than" the assertion value 🫶.
When preparing the attribute value and assertion value for comparison, characters are NOT case folded in the Map preparation step 🙅♀️, and only Insignificant Space Handling is applied in the Insignificant Character Handling step 🫧.
The LDAP definition for the caseExactOrderingMatch rule is:
( 2.5.13.6 NAME 'caseExactOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )The caseExactOrderingMatch rule is an ordering matching rule 👑.
4.2.6. caseExactSubstringsMatch ✨
okay so the caseExactSubstringsMatch rule takes an assertion value written in the Substring Assertion syntax and checks it against an attribute value from a syntax like Directory String, Printable String, Country String, or Telephone Number. that attribute's ASN.1 type has to be DirectoryString or one of its alternative string types 💅
the rule evaluates to TRUE if and only if (1) the prepared substrings of the assertion value match disjoint portions of the prepared attribute value character string, in the same order the substrings show up in the assertion value, (2) an <initial> substring, if there is one, matches the beginning of the prepared attribute value character string, and (3) a <final> substring, if there is one, matches the end of the prepared attribute value character string. a prepared substring matches a portion when the corresponding characters have the same code point. every character has to line up, bestie 🎀
when we prep the attribute value and assertion value substrings, characters are not case folded in the Map preparation step. only Insignificant Space Handling gets applied in the Insignificant Character Handling step. the "Exact" in the name is literally doing its job 😭
The LDAP definition for the caseExactSubstringsMatch rule is:
( 2.5.13.7 NAME 'caseExactSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )the caseExactSubstringsMatch rule is a substrings matching rule 🦋
4.2.7. caseIgnoreIA5Match 🌸
the caseIgnoreIA5Match rule compares an assertion value of the IA5 String syntax to an attribute value from a syntax (like the IA5 String syntax itself) whose ASN.1 type is IA5String. so it's the IA5 squad going head to head 🍓
the rule evaluates to TRUE if and only if the prepared attribute value character string and the prepared assertion value character string have the same number of characters, and corresponding characters have the same code point. same length, same characters, periodt ✨
when preparing the attribute value and assertion value for comparison, characters are case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step. so "Ada" and "ADA" are besties here 💜
The LDAP definition for the caseIgnoreIA5Match rule is:
( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )the caseIgnoreIA5Match rule is an equality matching rule 🫶
4.2.8. caseIgnoreIA5SubstringsMatch 🌈
the caseIgnoreIA5SubstringsMatch rule compares an assertion value of the Substring Assertion syntax to an attribute value from a syntax (like the IA5 String syntax) whose ASN.1 type is IA5String. it's the substring version of the IA5 rule and it's giving full main character energy 👑
the rule evaluates to TRUE if and only if (1) the prepared substrings of the assertion value match disjoint portions of the prepared attribute value character string in the order of the substrings in the assertion value, (2) an <initial> substring, if present, matches the beginning of the prepared attribute value character string, and (3) a <final> substring, if present, matches the end of the prepared attribute value character string. a prepared substring matches a portion of the prepared attribute value character string if corresponding characters have the same code point. 🧚
when preparing the attribute value and assertion value substrings for comparison, characters are case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
The LDAP definition for the caseIgnoreIA5SubstringsMatch rule is:
( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )the caseIgnoreIA5SubstringsMatch rule is a substrings matching rule 💖
4.2.9. caseIgnoreListMatch 🎀
the caseIgnoreListMatch rule compares an assertion value that's a sequence of strings to an attribute value from a syntax (like the Postal Address syntax) whose ASN.1 type is a SEQUENCE OF the DirectoryString ASN.1 type. it's a list-to-list situation, so it's all about the pairs 🍓
the rule evaluates to TRUE if and only if the attribute value and the assertion value have the same number of strings, and the corresponding strings (matched by position) match according to the caseIgnoreMatch matching rule. same count, same spot, same match 💅
In [X.520], the assertion syntax for this matching rule is defined to be:
SEQUENCE OF DirectoryString {ub-match}so it's different from the corresponding type for the Postal Address syntax. the choice of the Postal Address syntax for the assertion syntax of the caseIgnoreListMatch in LDAP should not be seen as limiting the matching rule to apply only to attributes with the Postal Address syntax. it's not a Postal Address-only club, everyone's invited 🌸
The LDAP definition for the caseIgnoreListMatch rule is:
( 2.5.13.11 NAME 'caseIgnoreListMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )the caseIgnoreListMatch rule is an equality matching rule ✨
4.2.10. caseIgnoreListSubstringsMatch 🦋
the caseIgnoreListSubstringsMatch rule compares an assertion value of the Substring Assertion syntax to an attribute value from a syntax (like the Postal Address syntax) whose ASN.1 type is a SEQUENCE OF the DirectoryString ASN.1 type. it's the substring version of the list rule, and honestly it's iconic 👑
the rule evaluates to TRUE if and only if the assertion value matches, per the caseIgnoreSubstringsMatch rule, the character string formed by concatenating the strings of the attribute value. the one twist is that none of the <initial>, <any>, or <final> substrings of the assertion value are considered to match a substring of the concatenated string that spans more than one of the original strings of the attribute value. so no sneaking across the seams 🙈
Note that, in terms of the LDAP-specific encoding of the Postal Address syntax, the concatenated string omits the <DOLLAR> line separator and the escaping of \ and $ characters. the <DOLLAR> separator and the escape characters just get dropped from the string, so it's a clean join 🫶
The LDAP definition for the caseIgnoreListSubstringsMatch rule is:
( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )the caseIgnoreListSubstringsMatch rule is a substrings matching rule 💜
4.2.11. caseIgnoreMatch 🌈
the caseIgnoreMatch rule compares an assertion value of the Directory String syntax to an attribute value from a syntax (like Directory String, Printable String, Country String, or Telephone Number) whose ASN.1 type is DirectoryString or one of its alternative string types. this is the OG case-insensitive equality rule and it's a whole vibe 🍓
the rule evaluates to TRUE if and only if the prepared attribute value character string and the prepared assertion value character string have the same number of characters, and corresponding characters have the same code point. same length, same code points, slay ✨
when preparing the attribute value and assertion value for comparison, characters are case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step. case doesn't matter, but the spaces get the insignificant treatment 🎀
The LDAP definition for the caseIgnoreMatch rule is:
( 2.5.13.2 NAME 'caseIgnoreMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )the caseIgnoreMatch rule is an equality matching rule 🧚
4.2.12. caseIgnoreOrderingMatch 🔥
the caseIgnoreOrderingMatch rule compares an assertion value of the Directory String syntax to an attribute value from a syntax (like Directory String, Printable String, Country String, or Telephone Number) whose ASN.1 type is DirectoryString or one of its alternative string types. this one is about who comes first, like a sorting hat 👑
the rule evaluates to TRUE if and only if, in the code point collation order, the prepared attribute value character string appears earlier than the prepared assertion value character string. in other words, the attribute value is "less than" the assertion value. so it's basically a glow-up check, is this one before that one? 🌸
when preparing the attribute value and assertion value for comparison, characters are case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
The LDAP definition for the caseIgnoreOrderingMatch rule is:
( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )the caseIgnoreOrderingMatch rule is an ordering matching rule 💅
4.2.13. caseIgnoreSubstringsMatch 💖
the caseIgnoreSubstringsMatch rule compares an assertion value of the Substring Assertion syntax to an attribute value from a syntax (like Directory String, Printable String, Country String, or Telephone Number) whose ASN.1 type is DirectoryString or one of its alternative string types. it's the substring version of the case-ignore rule and it ate 🍓
the rule evaluates to TRUE if and only if (1) the prepared substrings of the assertion value match disjoint portions of the prepared attribute value character string in the order of the substrings in the assertion value, (2) an <initial> substring, if present, matches the beginning of the prepared attribute value character string, and (3) a <final> substring, if present, matches the end of the prepared attribute value character string. a prepared substring matches a portion of the prepared attribute value character string if corresponding characters have the same code point. 🦋
when preparing the attribute value and assertion value substrings for comparison, characters are case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
The LDAP definition for the caseIgnoreSubstringsMatch rule is:
( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )the caseIgnoreSubstringsMatch rule is a substrings matching rule 🫶
4.2.14. directoryStringFirstComponentMatch 👑
the directoryStringFirstComponentMatch rule compares an assertion value of the Directory String syntax to an attribute value from a syntax whose ASN.1 type is a SEQUENCE with a mandatory first component of the DirectoryString ASN.1 type. so the first component is the star of the show 🌟
Note that the assertion syntax of this matching rule differs from the attribute syntax of attributes for which this is the equality matching rule. so the assertion and attribute syntaxes are not the same, and that's on purpose 🙈
the rule evaluates to TRUE if and only if the assertion value matches the first component of the attribute value using the rules of caseIgnoreMatch. 💜
The LDAP definition for the directoryStringFirstComponentMatch matching rule is:
( 2.5.13.31 NAME 'directoryStringFirstComponentMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )the directoryStringFirstComponentMatch rule is an equality matching rule. when using directoryStringFirstComponentMatch to compare two attribute values (of an applicable syntax), an assertion value must first be derived from one of the attribute values. an assertion value can be derived from an attribute value by taking the first component of that attribute value. so you grab the first component, make it your assertion value, and then compare 🎀
4.2.15. distinguishedNameMatch
okay bestie, this is the rule for comparing whole DNs 💅🎀 so the assertion value is in the DN syntax, and the attribute value is any syntax whose ASN.1 type is DistinguishedName (like, the DN syntax itself) ✨
the vibe check is: it's TRUE if and only if both DNs have the same number of relative distinguished names AND the RDNs match up by position 🦋 and an RDN from the assertion value matches the RDN at the same spot if they have the same number of attribute value assertions, and every AVA in the first RDN matches the AVA in the second RDN with the same attribute type 🫶 the order of AVAs doesn't matter (no vibes-based sorting needed lol) 🙈 and heads up, a given attribute type can show up in at most one AVA in an RDN 💀 two AVAs with the same attribute type count as the same if their values are equal according to that attribute type's equality matching rule ✨
the plot twist: if one or more of the AVA comparisons come back Undefined and everything else comes back TRUE, then distinguishedNameMatch is Undefined too 😭 it's giving "not sure yet, check back later" energy 🌸
the LDAP definition is:
( 2.5.13.1 NAME 'distinguishedNameMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )distinguishedNameMatch is an equality matching rule 💜
4.2.16. generalizedTimeMatch
the generalizedTimeMatch rule compares an assertion value in the Generalized Time syntax to an attribute value of any syntax (like, Generalized Time again) whose ASN.1 type is GeneralizedTime ⏰🌈
it evaluates to TRUE if and only if both values represent the same universal coordinated time ✨ and here's the tea: if a time doesn't include minutes or seconds, the missing ones are just assumed to be zero 🍓 so no drama, the time is still the same 🧚
the LDAP definition is:
( 2.5.13.27 NAME 'generalizedTimeMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )generalizedTimeMatch is an equality matching rule 🦋
4.2.17. generalizedTimeOrderingMatch
the generalizedTimeOrderingMatch rule compares the time ordering of an assertion value in the Generalized Time syntax to an attribute value of a syntax (like Generalized Time) whose ASN.1 type is GeneralizedTime 🕰️💖
it evaluates to TRUE if and only if the attribute value represents a universal coordinated time that is earlier than the one in the assertion value 👑 so basically it's a "who came first" check 💅
the LDAP definition is:
( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )generalizedTimeOrderingMatch is an ordering matching rule 🔥
4.2.18. integerFirstComponentMatch
the integerFirstComponentMatch rule compares an assertion value in the Integer syntax to an attribute value of a syntax (like the DIT Structure Rule Description syntax) whose ASN.1 type is a SEQUENCE with a mandatory first component of the INTEGER ASN.1 type 🧩🌸
heads up, bestie 🚨 the assertion syntax here is different from the attribute syntax of the attributes that use this as their equality matching rule 🙈
it evaluates to TRUE if and only if the assertion value and the first component of the attribute value are the same integer value ✨
the LDAP definition is:
( 2.5.13.29 NAME 'integerFirstComponentMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )integerFirstComponentMatch is an equality matching rule 💜 and when you're comparing two attribute values (of an applicable syntax) with it, you have to derive an assertion value from one of them first 🫶 you do that by taking the first component of that attribute value, and yes, it's a whole process, but it's so worth it 🎀
4.2.19. integerMatch
the integerMatch rule compares an assertion value in the Integer syntax to an attribute value of a syntax (like Integer) whose ASN.1 type is INTEGER 🔢🦋
it evaluates to TRUE if and only if both values are the same integer value 💅
the LDAP definition is:
( 2.5.13.14 NAME 'integerMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )integerMatch is an equality matching rule 🌈
4.2.20. integerOrderingMatch
the integerOrderingMatch rule compares an assertion value in the Integer syntax to an attribute value of a syntax (like Integer) whose ASN.1 type is INTEGER 📊✨
it evaluates to TRUE if and only if the integer value of the attribute value is less than the integer value of the assertion value 👑 (so it's a strictly smaller check, no ties allowed lol) 💀
the LDAP definition is:
( 2.5.13.15 NAME 'integerOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )integerOrderingMatch is an ordering matching rule 🔥
4.2.21. keywordMatch
the keywordMatch rule compares an assertion value in the Directory String syntax to an attribute value of a syntax (like Directory String) whose ASN.1 type is DirectoryString 🔑💜
it evaluates to TRUE if and only if the assertion value character string matches any keyword in the attribute value 🫶 and here's the thing: how keywords get identified in the attribute value, and how exact the match has to be, are both implementation specific 🙈 so it's up to each implementation to vibe with that one 💅
the LDAP definition is:
( 2.5.13.33 NAME 'keywordMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )4.2.22. numericStringMatch
the numericStringMatch rule compares an assertion value in the Numeric String syntax to an attribute value of a syntax (like Numeric String) whose ASN.1 type is NumericString 🔢🌸
it evaluates to TRUE if and only if the prepared attribute value character string and the prepared assertion value character string have the same number of characters, and the corresponding characters have the same code point ✨
when you're preparing both values for comparison, characters are not case folded in the Map preparation step 🙅♀️ and only numericString Insignificant Character Handling gets applied in the Insignificant Character Handling step 🧼
the LDAP definition is:
( 2.5.13.8 NAME 'numericStringMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )numericStringMatch is an equality matching rule 💖
4.2.23. numericStringOrderingMatch
the numericStringOrderingMatch rule compares an assertion value in the Numeric String syntax to an attribute value of a syntax (like Numeric String) whose ASN.1 type is NumericString 📏💅
it evaluates to TRUE if and only if, in the code point collation order, the prepared attribute value character string shows up earlier than the prepared assertion value character string 🏃♀️ aka the attribute value is "less than" the assertion value 🦋
same prep as before, okay: no case folding in the Map preparation step, and only numericString Insignificant Character Handling in the Insignificant Character Handling step ✨
honestly this one is just caseIgnoreOrderingMatch with a twist 💁♀️ all space characters get skipped during the comparison, and case doesn't matter at all because numeric characters don't have case 🙃
the LDAP definition is:
( 2.5.13.9 NAME 'numericStringOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )numericStringOrderingMatch is an ordering matching rule 🔥
4.2.24. numericStringSubstringsMatch
the numericStringSubstringsMatch rule compares an assertion value in the Substring Assertion syntax to an attribute value of a syntax (like Numeric String) whose ASN.1 type is NumericString 🧵💜
it evaluates to TRUE if and only if all three of these are true 🫶:
- the prepared substrings of the assertion value match disjoint portions of the prepared attribute value character string, in the same order the substrings appear in the assertion value 🧩
- an
<initial>substring, if there is one, matches the beginning of the prepared attribute value character string 🌅 - a
<final>substring, if there is one, matches the end of the prepared attribute value character string 🌇
a prepared substring matches a portion of the prepared attribute value character string if the corresponding characters have the same code point ✨
same prep rules as the other numeric ones: no case folding in the Map preparation step, and only numericString Insignificant Character Handling in the Insignificant Character Handling step 🧼💅
the LDAP definition is:
( 2.5.13.10 NAME 'numericStringSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )numericStringSubstringsMatch is a substrings matching rule 🌈
4.2.25. objectIdentifierFirstComponentMatch
the objectIdentifierFirstComponentMatch rule compares an assertion value in the OID syntax to an attribute value of a syntax (like Attribute Type Description, DIT Content Rule Description, LDAP Syntax Description, Matching Rule Description, Matching Rule Use Description, Name Form Description, or Object Class Description) whose ASN.1 type is a SEQUENCE with a mandatory first component of the OBJECT IDENTIFIER ASN.1 type 🪄🎀
again, the assertion syntax here differs from the attribute syntax of the attributes that use this as their equality matching rule 🙈 be careful, bestie 🚨
it evaluates to TRUE if and only if the assertion value matches the first component of the attribute value, using the rules of objectIdentifierMatch 🦋
the LDAP definition is:
( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )objectIdentifierFirstComponentMatch is an equality matching rule 💜 and when you're comparing two attribute values (of an applicable syntax) with it, you first have to derive an assertion value from one of them 🫶 that's done by taking the first component of that attribute value, so no skipping this step 💅
4.2.26. objectIdentifierMatch
the objectIdentifierMatch rule compares an assertion value in the OID syntax to an attribute value of a syntax (like OID) whose ASN.1 type is OBJECT IDENTIFIER 🔢🌸
it evaluates to TRUE if and only if the assertion value and the attribute value represent the same object identifier, meaning the same sequence of integers 🧠✨ that can be written out explicitly in the <numericoid> form of <oid>, or implicitly in the <descr> form (see [RFC4512]) 🦋
if an LDAP client supplies an assertion value in the <descr> form and the descriptor they picked isn't recognized by the server, then objectIdentifierMatch evaluates to Undefined 😭 it's the "I don't know who you're talking about" moment 💀
the LDAP definition is:
( 2.5.13.0 NAME 'objectIdentifierMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )objectIdentifierMatch is an equality matching rule 👑
4.2.27. octetStringMatch ✨
okay so octetStringMatch 🫧 compares an assertion value of the Octet String syntax to an attribute value of a syntax (like Octet String or JPEG) whose ASN.1 type is OCTET STRING. it's giving raw bytes energy 💅
the rule evaluates to TRUE if and only if the attribute value and the assertion value are the same length and their corresponding octets (matched by position) are the same. no cap, it's a straight byte-for-byte glow-up 💖
the LDAP definition for the octetStringMatch matching rule is:
( 2.5.13.17 NAME 'octetStringMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )and octetStringMatch is an equality matching rule 🎀
4.2.28. octetStringOrderingMatch 🌊
octetStringOrderingMatch is the sorting cousin of the one above 🧚 it compares an assertion value of the Octet String syntax to an attribute value of a syntax (like Octet String or JPEG) whose ASN.1 type is the OCTET STRING ASN.1 type.
the rule evaluates to TRUE if and only if the attribute value appears earlier in the collation order than the assertion value. the comparison goes from the first octet to the last, and within each octet it goes from the most significant bit to the least significant bit. the first bit that differs decides the order, and a zero bit comes before a one bit 🍓 if the strings have different lengths but the longer one matches the shorter one all the way up to the shorter one's length, then the shorter string comes first. literally so organized 😭
the LDAP definition for the octetStringOrderingMatch matching rule is:
( 2.5.13.18 NAME 'octetStringOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )and octetStringOrderingMatch is an ordering matching rule 📚
4.2.29. telephoneNumberMatch 📞
telephoneNumberMatch compares an assertion value of the Telephone Number syntax to an attribute value of a syntax (like the Telephone Number syntax) whose ASN.1 type is a PrintableString representing a telephone number. it's giving phone-book precision 💜
the rule evaluates to TRUE if and only if the prepared attribute value character string and the prepared assertion value character string have the same number of characters, and the corresponding characters have the same code point.
when we prep both values for comparison, characters get case folded in the Map preparation step, and only telephoneNumber Insignificant Character Handling is applied in the Insignificant Character Handling step 🌸
the LDAP definition for the telephoneNumberMatch matching rule is:
( 2.5.13.20 NAME 'telephoneNumberMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )and telephoneNumberMatch is an equality matching rule ✨
4.2.30. telephoneNumberSubstringsMatch 🔍
telephoneNumberSubstringsMatch compares an assertion value of the Substring Assertion syntax to an attribute value of a syntax (like the Telephone Number syntax) whose ASN.1 type is a PrintableString representing a telephone number. this one is the "find the piece" queen 👑
the rule evaluates to TRUE if and only if all three of these are true:
- the prepared substrings of the assertion value match disjoint portions of the prepared attribute value character string, in the same order the substrings appear in the assertion value,
- an
<initial>substring, if present, matches the beginning of the prepared attribute value character string, and - a
<final>substring, if present, matches the end of the prepared attribute value character string.
a prepared substring matches a portion of the prepared attribute value character string if the corresponding characters have the same code point 🦋
when we prep the attribute value and the assertion value substrings for comparison, characters get case folded in the Map preparation step, and only telephoneNumber Insignificant Character Handling is applied in the Insignificant Character Handling step 🫶
the LDAP definition for the telephoneNumberSubstringsMatch matching rule is:
( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )and telephoneNumberSubstringsMatch is a substrings matching rule 🎀
4.2.31. uniqueMemberMatch 🧑🤝🧑
uniqueMemberMatch compares an assertion value of the Name And Optional UID syntax to an attribute value of a syntax (like the Name And Optional UID syntax) whose ASN.1 type is NameAndOptionalUID. it's a whole vibe check, but make it structured 💅
the rule evaluates to TRUE if and only if the <distinguishedName> components of the assertion value and attribute value match according to the distinguishedNameMatch rule, AND either:
- the
<BitString>component is absent from both the attribute value and the assertion value, or - the
<BitString>component is present in both, and the<BitString>component of the assertion value matches the<BitString>component of the attribute value according to the bitStringMatch rule.
heads up bestie 🙈 this matching rule was altered from how X.520 [X.520] describes it so that the matching is commutative. if you're a server implementor doing approximate matching of attributes with uniqueMemberMatch as the equality matching rule, you should think about using the original X.520 semantics (where the matching was less exact).
the LDAP definition for the uniqueMemberMatch matching rule is:
( 2.5.13.23 NAME 'uniqueMemberMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )and uniqueMemberMatch is an equality matching rule 💖
4.2.32. wordMatch 📝
wordMatch compares an assertion value of the Directory String syntax to an attribute value of a syntax (like the Directory String syntax) whose ASN.1 type is DirectoryString. it's word-search energy 🌈
the rule evaluates to TRUE if and only if the assertion value word matches any word in the attribute value, using the semantics of caseIgnoreMatch. the precise definition of a word is implementation specific 🧚
the LDAP definition for the wordMatch rule is:
( 2.5.13.32 NAME 'wordMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )5. Security Considerations 🔐
this part is serious, so I'm not gonna be all extra about it 😭 but we have to get it right!!
in general, the LDAP-specific encodings for the syntaxes defined in this document do not define canonical encodings. that means if you transform an LDAP-specific encoding into some other encoding (like BER) and then back again, you won't necessarily get the exact original octets. so an LDAP-specific encoding should not be used where a canonical encoding is required 🚫
also, the LDAP-specific encodings don't necessarily let you rebuild an alternative encoding of values from the Directory String and DN syntaxes. for example, going from a Distinguished Encoding Rules (DER) [BER] encoding to an LDAP-specific encoding and back to DER may not give you the original DER encoding. so LDAP-specific encodings should not be used where reversibility to DER is needed, like verifying digital signatures. use DER or a DER-reversible encoding instead 🫶
when you're interpreting security-sensitive fields (especially fields used to grant or deny access), implementations MUST ensure that any matching rule comparisons are done on the underlying abstract value, no matter which encoding was used. this is non-negotiable, babe 🚨👑
6. Acknowledgements 🌷
this document is mainly a revision of RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, and S. Kille. RFC 2252 came out of the IETF ASID Working Group, so big respect to them 🎀
this document is based on input from the IETF LDAPBIS working group. the author wants to thank Kathy Dally for editing the early drafts, and Jim Sermersheim and Kurt Zeilenga for their significant contributions to this revision 💜
7. IANA Considerations 🏛️
the Internet Assigned Numbers Authority (IANA) has updated the LDAP descriptors registry [BCP64] using the templates below 📋
Subject: Request for LDAP Descriptor Registration Update
Descriptor (short name): see comment
Object Identifier: see comment
Person & email address to contact for further information:
Steven Legg <steven.legg@eb2bcom.com>
Usage: see comment
Specification: RFC 4517
Author/Change Controller: IESG
NAME Type OID
------------------------------------------------------------------
bitStringMatch M 2.5.13.16
booleanMatch M 2.5.13.13
caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1
caseExactMatch M 2.5.13.5
caseExactOrderingMatch M 2.5.13.6
caseExactSubstringsMatch M 2.5.13.7
caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2
caseIgnoreListMatch M 2.5.13.11
caseIgnoreListSubstringsMatch M 2.5.13.12
caseIgnoreMatch M 2.5.13.2
caseIgnoreOrderingMatch M 2.5.13.3
caseIgnoreSubstringsMatch M 2.5.13.4
directoryStringFirstComponentMatch M 2.5.13.31
distinguishedNameMatch M 2.5.13.1
generalizedTimeMatch M 2.5.13.27
generalizedTimeOrderingMatch M 2.5.13.28
integerFirstComponentMatch M 2.5.13.29
integerMatch M 2.5.13.14
integerOrderingMatch M 2.5.13.15
keywordMatch M 2.5.13.33
numericStringMatch M 2.5.13.8
numericStringOrderingMatch M 2.5.13.9
numericStringSubstringsMatch M 2.5.13.10
objectIdentifierFirstComponentMatch M 2.5.13.30
octetStringMatch M 2.5.13.17
octetStringOrderingMatch M 2.5.13.18
telephoneNumberMatch M 2.5.13.20
telephoneNumberSubstringsMatch M 2.5.13.21
uniqueMemberMatch M 2.5.13.23
wordMatch M 2.5.13.32the descriptor for the object identifier 2.5.13.0 was incorrectly registered as objectIdentifiersMatch (with an extraneous `s') in BCP 64. it's been fixed to the following, with a reference to RFC 4517 ✅
NAME Type OID
------------------------------------------------------------------
objectIdentifierMatch M 2.5.13.0Subject: Request for LDAP Descriptor Registration
Descriptor (short name): caseIgnoreIA5SubstringsMatch
Object Identifier: 1.3.6.1.4.1.1466.109.114.3
Person & email address to contact for further information:
Steven Legg <steven.legg@eb2bcom.com>
Usage: other (M)
Specification: RFC 4517
Author/Change Controller: IESG8. References 📚
nothing is listed under this heading in the original text 💅
8.1. Normative References 📚✨
okay bestie, these are the docs the spec needs you to have read, no skipping 💅
[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑[RFC3629]Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. 🌍[RFC4234]Crocker, D., Ed. 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. 🗺️[RFC4511]Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006. 📨[RFC4512]Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006. 🏛️[RFC4514]Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006. 🏷️[RFC4518]Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation", RFC 4518, June 2006. 🌸[RFC4520]Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. 🗂️[E.123]Notation for national and international telephone numbers, ITU-T Recommendation E.123, 1988. ☎️[FAX]Standardization of Group 3 facsimile apparatus for document transmission - Terminal Equipment and Protocols for Telematic Services, ITU-T Recommendation T.4, 1993 📠[T.50]International Reference Alphabet (IRA) (Formerly International Alphabet No. 5 or IA5) Information Technology - 7-Bit Coded Character Set for Information Interchange, ITU-T Recommendation T.50, 1992 🔤[X.420]ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997, Information Technology - Message Handling Systems (MHS): Interpersonal messaging system 💌[X.501]ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994, Information Technology - Open Systems Interconnection - The Directory: Models 🧠[X.520]ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994, Information Technology - Open Systems Interconnection - The Directory: Selected attribute types 🎀[ASN.1]ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation 🔣[ISO3166]ISO 3166, "Codes for the representation of names of countries". 🌏[ISO8601]ISO 8601:2004, "Data elements and interchange formats -- Information interchange -- Representation of dates and times". 🗓️[UCS]Universal Multiple-Octet Coded Character Set (UCS) - Architecture and Basic Multilingual Plane, ISO/IEC 10646-1: 1993 (with amendments). 🦋[JPEG]JPEG File Interchange Format (Version 1.02). Eric Hamilton, C-Cube Microsystems, Milpitas, CA, September 1, 1992. 🖼️
8.2. Informative References 🌷
these ones are helpful background reading, not strictly required, but ngl they're worth a peek 🫶
[RFC4519]Sciberras, A., Ed., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006. 👩💻[RFC4523]Zeilenga, K., "Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates", RFC 4523, June 2006. 🔐[X.500]ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, Information Technology - Open Systems Interconnection - The Directory: Overview of concepts, models and services 🌐[BER]ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002, Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) 🧁
Appendix A. Summary of Syntax Object Identifiers 🦄✨
this little list is the cheat sheet of every syntax this document defines, plus its OBJECT IDENTIFIER. so cute, so organized 💖
Syntax OBJECT IDENTIFIER
==============================================================
Attribute Type Description 1.3.6.1.4.1.1466.115.121.1.3
Bit String 1.3.6.1.4.1.1466.115.121.1.6
Boolean 1.3.6.1.4.1.1466.115.121.1.7
Country String 1.3.6.1.4.1.1466.115.121.1.11
Delivery Method 1.3.6.1.4.1.1466.115.121.1.14
Directory String 1.3.6.1.4.1.1466.115.121.1.15
DIT Content Rule Description 1.3.6.1.4.1.1466.115.121.1.16
DIT Structure Rule Description 1.3.6.1.4.1.1466.115.121.1.17
DN 1.3.6.1.4.1.1466.115.121.1.12
Enhanced Guide 1.3.6.1.4.1.1466.115.121.1.21
Facsimile Telephone Number 1.3.6.1.4.1.1466.115.121.1.22
Fax 1.3.6.1.4.1.1466.115.121.1.23
Generalized Time 1.3.6.1.4.1.1466.115.121.1.24
Guide 1.3.6.1.4.1.1466.115.121.1.25
IA5 String 1.3.6.1.4.1.1466.115.121.1.26
Integer 1.3.6.1.4.1.1466.115.121.1.27
JPEG 1.3.6.1.4.1.1466.115.121.1.28
LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54
Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.30
Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31
Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34
Name Form Description 1.3.6.1.4.1.1466.115.121.1.35
Numeric String 1.3.6.1.4.1.1466.115.121.1.36
Object Class Description 1.3.6.1.4.1.1466.115.121.1.37
Octet String 1.3.6.1.4.1.1466.115.121.1.40
OID 1.3.6.1.4.1.1466.115.121.1.38
Other Mailbox 1.3.6.1.4.1.1466.115.121.1.39
Postal Address 1.3.6.1.4.1.1466.115.121.1.41
Printable String 1.3.6.1.4.1.1466.115.121.1.44
Substring Assertion 1.3.6.1.4.1.1466.115.121.1.58
Telephone Number 1.3.6.1.4.1.1466.115.121.1.50
Teletex Terminal Identifier 1.3.6.1.4.1.1466.115.121.1.51
Telex Number 1.3.6.1.4.1.1466.115.121.1.52
UTC Time 1.3.6.1.4.1.1466.115.121.1.53Appendix B. Changes from RFC 2252 ✨
okay bestie, this annex is the full tea on everything that changed since RFC 2252 ☕🫶 it's just for info, not a normative part of the spec, so it's giving "read for context" energy 💅
- The IESG Note has been removed. 🙈
- The major part of Sections 4, 5 and 7 has been moved to [RFC4512] and revised. Changes to the parts of these sections moved to [RFC4512] are detailed in [RFC4512]. 📦
- BNF descriptions of syntax formats have been replaced by ABNF [RFC4234] specifications. ✨
- The ambiguous statement in RFC 2252, Section 4.3 about using a backslash quoting mechanism to escape separator symbols has been removed. The escaping mechanism is now explicitly represented in the ABNF for the syntaxes where this provision applies. 🧵
- The description of each LDAP syntax has been expanded so they're less dependent on knowing X.500 to understand them 🌸
- The relationship between LDAP syntaxes and their corresponding ASN.1 type definitions has been made explicit. 💜
- The set of characters allowed in a
<PrintableString>(formerly<printablestring>) has been corrected to line up with the PrintableString ASN.1 type in [ASN.1]. Specifically, the double quote character has been removed, and the single quote character and equals sign have been added. 🎀 - Values of the Directory String, Printable String and Telephone Number syntaxes are now required to have at least one character. 🍓
- The
<DITContentRuleDescription>,<NameFormDescription>and<DITStructureRuleDescription>rules have been moved to [RFC4512]. 🦋 - The corresponding ASN.1 type for the Other Mailbox syntax has been incorporated from RFC 1274. 📬
- A corresponding ASN.1 type for the LDAP Syntax Description syntax has been invented. ✨
- The Binary syntax has been removed, because it was not adequately specified, implementations with different incompatible interpretations exist, and it was confused with the
;binarytransfer encoding. 💀 - All discussion of transfer options, including the
;binaryoption, has been removed. All imperatives regarding binary transfer of values have been removed too. 🙅♀️ - The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex Terminal Identifier and Telex Number syntaxes from RFC 2256 have been incorporated. 🌈
- The
<criteria>rule for the Enhanced Guide and Guide syntaxes has been extended to accommodate empty "and" and "or" expressions. 🧚 - An encoding for the
<ttx-value>rule in the Teletex Terminal Identifier syntax has been defined. 💅 - The PKI-related syntaxes (Certificate, Certificate List and Certificate Pair) have been removed. They're reintroduced in [RFC4523], and so is the Supported Algorithm syntax from RFC 2256. 🔐
- The MHS OR Address syntax has been removed, since its specification (in RFC 2156) is not at draft standard maturity. 📮
- The DL Submit Permission syntax has been removed, because it depends on the MHS OR Address syntax. 🙃
- The Presentation Address syntax has been removed, since its specification (in RFC 1278) is not at draft standard maturity. 🫠
- The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE Type, LDAP Schema Description, Master And Shadow Access Points, Modify Rights, Protocol Information, Subtree Specification, Supplier Information, Supplier Or Consumer and Supplier And Consumer syntaxes have been removed. These are referenced in RFC 2252 but never actually defined, so no cap 🧹
- The LDAP Schema Definition syntax (defined in RFC 2927) and the Mail Preference syntax have been removed, on the grounds that they're out of scope for the core specification. 🌷
- The description of each matching rule has been expanded so it's less dependent on knowing X.500 for interpretation. 🔍
- The
caseIgnoreIA5SubstringsMatchmatching rule from RFC 2798 has been added. ✨ - The
caseIgnoreListSubstringsMatch,caseIgnoreOrderingMatchandcaseIgnoreSubstringsMatchmatching rules have been added to the list of matching rules where the rules for handling leading, trailing and multiple adjoining whitespace characters apply (now through string preparation). This is consistent with how these matching rules are defined in X.500. ThecaseIgnoreIA5SubstringsMatchrule has also been added to that list. 🫧 - The specification of the
octetStringMatchmatching rule from RFC 2256 has been added to this document. 🧩 - The
presentationAddressMatchmatching rule has been removed, because it depends on an assertion syntax (Presentation Address) that isn't at draft standard maturity. 🚫 - The
protocolInformationMatchmatching rule has been removed, because it depends on an undefined assertion syntax (Protocol Information). 🚫 - The definitive reference for ASN.1 has been changed from X.208 to X.680, since X.680 is the version of ASN.1 that X.500 refers to. 📚
- The specification of the
caseIgnoreListSubstringsMatchmatching rule from RFC 2798 & X.520 has been added. 🌟 - String preparation algorithms have been applied to the character string matching rules. 🧼
- The specifications of the
booleanMatch,caseExactMatch,caseExactOrderingMatch,caseExactSubstringsMatch,directoryStringFirstComponentMatch,integerOrderingMatch,keywordMatch,numericStringOrderingMatch,octetStringOrderingMatchandwordMatchmatching rules from RFC 3698 & X.520 have been added. 👑
Author's Address
Steven Legg
eB2Bcom
Suite3, Woodhouse Corporate Centre
935 Station Street
Box Hill North, Victoria 3129
AUSTRALIA
Phone: +61 3 9896 7830
Fax: +61 3 9896 7801
EMail: steven.legg@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. It also doesn't 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, 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: rfc4517 2006-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms