SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
The integerMatch rule is an equality matching rule.
4.2.20. integerOrderingMatch
The integerOrderingMatch rule compares an assertion value of the
Integer syntax to an attribute value of a syntax (e.g., the Integer
syntax) whose corresponding ASN.1 type is INTEGER.
The rule evaluates to TRUE if and only if the integer value of the
attribute value is less than the integer value of the assertion
value.
The LDAP definition for the integerOrderingMatch matching rule is:
( 2.5.13.15 NAME ’integerOrderingMatch’
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
The integerOrderingMatch rule is an ordering matching rule.
4.2.21. keywordMatch
The keywordMatch rule compares an assertion value of the Directory
String syntax to an attribute value of a syntax (e.g., the Directory
String syntax) whose corresponding ASN.1 type is DirectoryString.
The rule evaluates to TRUE if and only if the assertion value
character string matches any keyword in the attribute value. The
identification of keywords in the attribute value and the exactness
of the match are both implementation specific.
The LDAP definition for the keywordMatch rule 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 of the
Numeric String syntax to an attribute value of a syntax (e.g., the
Numeric String syntax) whose corresponding ASN.1 type is
NumericString.
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.
In preparing the attribute value and assertion value for comparison,
characters are not case folded in the Map preparation step, and only
numericString Insignificant Character Handling is applied in the
Insignificant Character Handling step.
The LDAP definition for the numericStringMatch matching rule is:
( 2.5.13.8 NAME ’numericStringMatch’
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
The numericStringMatch rule is an equality matching rule.
4.2.23. numericStringOrderingMatch
The numericStringOrderingMatch rule compares an assertion value of
the Numeric String syntax to an attribute value of a syntax (e.g.,
the Numeric String syntax) whose corresponding ASN.1 type is
NumericString.
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;
i.e., the attribute value is "less than" the assertion value.
In preparing the attribute value and assertion value for comparison,
characters are not case folded in the Map preparation step, and only
numericString Insignificant Character Handling is applied in the
Insignificant Character Handling step.
The rule is identical to the caseIgnoreOrderingMatch rule except that
all space characters are skipped during comparison (case is
irrelevant as the characters are numeric).
The LDAP definition for the numericStringOrderingMatch matching rule
is:
( 2.5.13.9 NAME ’numericStringOrderingMatch’
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
The numericStringOrderingMatch rule is an ordering matching rule.
4.2.24. numericStringSubstringsMatch
The numericStringSubstringsMatch rule compares an assertion value of
the Substring Assertion syntax to an attribute value of a syntax
(e.g., the Numeric String syntax) whose corresponding ASN.1 type is
NumericString.
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.
In preparing the attribute value and assertion value for comparison,
characters are not case folded in the Map preparation step, and only
numericString Insignificant Character Handling is applied in the
Insignificant Character Handling step.
The LDAP definition for the numericStringSubstringsMatch matching
rule is:
( 2.5.13.10 NAME ’numericStringSubstringsMatch’
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The numericStringSubstringsMatch rule is a substrings matching rule.
4.2.25. objectIdentifierFirstComponentMatch
The objectIdentifierFirstComponentMatch rule compares an assertion
value of the OID syntax to an attribute value of a syntax (e.g., the
Attribute Type Description, DIT Content Rule Description, LDAP Syntax
Description, Matching Rule Description, Matching Rule Use
Description, Name Form Description, or Object Class Description
syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory
first component of the OBJECT IDENTIFIER ASN.1 type.
Note that the assertion syntax of this matching rule differs from the
attribute syntax of attributes for which this is the equality
matching rule.
The rule 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 for the objectIdentifierFirstComponentMatch
matching rule is:
( 2.5.13.30 NAME ’objectIdentifierFirstComponentMatch’
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
The objectIdentifierFirstComponentMatch rule is an equality matching
rule. When using objectIdentifierFirstComponentMatch 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.
4.2.26. objectIdentifierMatch
The objectIdentifierMatch rule compares an assertion value of the OID
syntax to an attribute value of a syntax (e.g., the OID syntax) whose
corresponding ASN.1 type is OBJECT IDENTIFIER.
The rule evaluates to TRUE if and only if the assertion value and the
attribute value represent the same object identifier; that is, the
same sequence of integers, whether represented 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 chosen descriptor is not recognized by the server, then the
objectIdentifierMatch rule evaluates to Undefined.
The LDAP definition for the objectIdentifierMatch matching rule is:
( 2.5.13.0 NAME ’objectIdentifierMatch’
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
The objectIdentifierMatch rule is an equality matching rule.
4.2.27. octetStringMatch
The octetStringMatch rule compares an assertion value of the Octet
String syntax to an attribute value of a syntax (e.g., the Octet
String or JPEG syntax) whose corresponding ASN.1 type is the OCTET
STRING ASN.1 type.
The rule evaluates to TRUE if and only if the attribute value and the
assertion value are the same length and corresponding octets (by
position) are the same.
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 )
The octetStringMatch rule is an equality matching rule.
4.2.28. octetStringOrderingMatch
The octetStringOrderingMatch rule compares an assertion value of the
Octet String syntax to an attribute value of a syntax (e.g., the
Octet String or JPEG syntax) whose corresponding 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 rule
compares octet strings from the first octet to the last octet, and
from the most significant bit to the least significant bit within the
octet. The first occurrence of a different bit determines the
ordering of the strings. A zero bit precedes a one bit. If the
strings contain different numbers of octets but the longer string is
identical to the shorter string up to the length of the shorter
string, then the shorter string precedes the longer string.
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 )
The octetStringOrderingMatch rule is an ordering matching rule.
4.2.29. telephoneNumberMatch
The telephoneNumberMatch rule compares an assertion value of the
Telephone Number syntax to an attribute value of a syntax (e.g., the
Telephone Number syntax) whose corresponding ASN.1 type is a
PrintableString representing a telephone number.
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.
In preparing the attribute value and assertion value for comparison,
characters are 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 )
The telephoneNumberMatch rule is an equality matching rule.
4.2.30. telephoneNumberSubstringsMatch
The telephoneNumberSubstringsMatch rule compares an assertion value
of the Substring Assertion syntax to an attribute value of a syntax
(e.g., the Telephone Number syntax) whose corresponding ASN.1 type is
a PrintableString representing a telephone number.
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.
In preparing the attribute value and assertion value substrings for
comparison, characters are 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 )
The telephoneNumberSubstringsMatch rule is a substrings matching
rule.
4.2.31. uniqueMemberMatch
The uniqueMemberMatch rule compares an assertion value of the Name
And Optional UID syntax to an attribute value of a syntax (e.g., the
Name And Optional UID syntax) whose corresponding ASN.1 type is
NameAndOptionalUID.
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, (1) the <BitString>
component is absent from both the attribute value and assertion
value, or (2) the <BitString> component is present in both the
attribute value and the assertion value and the <BitString> component
of the assertion value matches the <BitString> component of the
attribute value according to the bitStringMatch rule.
Note that this matching rule has been altered from its description in
X.520 [X.520] in order to make the matching rule commutative. Server
implementors should consider using the original X.520 semantics
(where the matching was less exact) for approximate matching of
attributes with uniqueMemberMatch as the equality matching rule.
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 )
The uniqueMemberMatch rule is an equality matching rule.
4.2.32. wordMatch
The wordMatch rule compares an assertion value of the Directory
String syntax to an attribute value of a syntax (e.g., the Directory
String syntax) whose corresponding ASN.1 type is DirectoryString.
The rule evaluates to TRUE if and only if the assertion value word
matches, according to the semantics of caseIgnoreMatch, any word in
the attribute value. 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
In general, the LDAP-specific encodings for syntaxes defined in this
document do not define canonical encodings. That is, a
transformation from an LDAP-specific encoding into some other
encoding (e.g., BER) and back into the LDAP-specific encoding will
not necessarily reproduce exactly the original octets of the LDAP-
specific encoding. Therefore, an LDAP-specific encoding should not
be used where a canonical encoding is required.
Furthermore, the LDAP-specific encodings do not necessarily enable an
alternative encoding of values of the Directory String and DN
syntaxes to be reconstructed; e.g., a transformation from a
Distinguished Encoding Rules (DER) [BER] encoding to an LDAP-specific
encoding and back to a DER encoding may not reproduce the original
DER encoding. Therefore, LDAP-specific encodings should not be used
where reversibility to DER is needed; e.g., for the verification of
digital signatures. Instead, DER or a DER-reversible encoding should
be used.
When interpreting security-sensitive fields (in particular, fields
used to grant or deny access), implementations MUST ensure that any
matching rule comparisons are done on the underlying abstract value,
regardless of the particular encoding used.
6. Acknowledgements
This document is primarily a revision of RFC 2252 by M. Wahl, A.
Coulbeck, T. Howes, and S. Kille. RFC 2252 was a product of the IETF
ASID Working Group.
This document is based on input from the IETF LDAPBIS working group.
The author would like to thank Kathy Dally for editing the early
drafts of this document, 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] as indicated by the following templates:
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.32
The descriptor for the object identifier 2.5.13.0 was incorrectly
registered as objectIdentifiersMatch (extraneous \`s’) in BCP 64.
It has been changed to the following, with a reference to
RFC 4517.
NAME Type OID
------------------------------------------------------------------
objectIdentifierMatch M 2.5.13.0
Subject: 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: IESG
8. References
8.1. Normative References
[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
[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
The following list summarizes the object identifiers assigned to the
syntaxes defined in this document.
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