| Network Working Group | T. Howes |
| Request for Comments: 2254 | Netscape Communications Corp. |
| Category: Standards Track | December 1997 |
The String Representation of LDAP Search Filters
本文書は、インターネットコミュニティのための標準化プロトコルを規定するとともに、それを改良するための議論や提言を求めるものである。本プロトコルの標準化状態、および、ステータスについては「Internet Official Protocol Standards」(STD 1)の最新版を参照してほしい。このメモの配布に制限は無い。
著作権について
Copyright (C) The Internet Society (1997). All Rights Reserved.
IESGノート
本文書では、読み出しおよび更新アクセスを提供するディレクトリアクセスプロトコルについて述べる。更新アクセスには安全な認証が必要であるが、本文書は十分な認証機構の実装についてはなにも指示しない。
このような制限は存在するが、本仕様書は、RFC 2026のセクション4.4.1に従って、Proposed StandardとしてIESGに認可されている。その理由は次の通りである：
必須の認証機構が標準化されるまで、本仕様に従って書かれた更新機能を利用するクライアントとサーバは相互運用できない、あるいは、認証レベルが受け入れ難いレベルにまで下げられる場合に限り相互運用できる、という可能性があることを読者にあらかじめ警告する。
実装者は、LDAPv3で必須となる認証のためのProposed Standardが認められ、RFCとして発行されるまで、更新機能を実装するLDAPv3クライアント、およびサーバの配備を行わないことが望ましい。
Lightweight Directory Access Protocol(LDAP)[1]は、LDAPサーバに転送される検索フィルタのネットワーク表記を定義している。アプリケーションから見たとき、これらの検索フィルタを人が読み易い形式で表記する共通の方法があれば便利であることがある。本書はLDAP検索フィルタを表す、人が読み易い文字列フォーマットを定義するものである。 本書は、RFC 1960の書き換えであり、バージョン3拡張適合フィルタをサポートする文字列LDAPフィルタ定義を拡張し、使用できるすべての型のLDAP検索フィルタの表記をサポートする。LDAPv3検索フィルタは、[1]のセクション4.5.1で以下のように定義されている ：
Filter ::= CHOICE {
and [0] SET OF Filter,
or [1] SET OF Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeDescription,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion
}
SubstringFilter ::= SEQUENCE {
type AttributeDescription,
SEQUENCE OF CHOICE {
initial [0] LDAPString,
any [1] LDAPString,
final [2] LDAPString
}
}
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
attributeValue AttributeValue
}
MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleID OPTIONAL,
type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE
}
AttributeDescription ::= LDAPString
AttributeValue ::= OCTET STRING
MatchingRuleID ::= LDAPString
AssertionValue ::= OCTET STRING
LDAPString ::= OCTET STRING
上記のLDAPStringはISO 10646文字集合[4]のUTF-8符号化に限定されている。 AttributeDescriptionは属性記述の文字列表記であり、[1]で定義されている。 AttributeValueとAssertionValueのOCTET STRINGは、[2]で定義されている形式をとる。このフィルタは、[1]に記述されている簡略化が行われ、[3]で定義されている基本符号化規則(Basic Encoding Rules)に従って符号化されて、ネットワーク上で送信される。
LDAP検索フィルタの文字列表記は、[5]で定義されるABNF記法に従って、以下の文法で定義される。フィルタフォーマットはプレフィックス記法を用いる。
filter =
"(" filtercomp ")"
filtercomp = and / or / not / item
and =
"&" filterlist
or
= "|" filterlist
not =
"!" filter
filterlist = 1*filter
item =
simple / present / substring / extensible
simple = attr
filtertype value
filtertype = equal / approx / greater / less
equal =
"="
approx = "~="
greater = ">="
less =
"<="
extensible = attr [":dn"]
[":" matchingrule] ":=" value
/ [":dn"] ":" matchingrule ":=" value
present = attr "=*"
substring = attr "=" [initial]
any [final]
initial = value
any =
"*" *(value "*")
final = value
attr =
AttributeDescription from Section 4.1.5 of [1]
matchingrule = MatchingRuleId from Section
4.1.9 of [1]
value =
AttributeValue from Section 4.1.6 of [1]
attr、matchingruleおよびvalueの構造子は、上記の[1]の該当するセクションで記述されている。
valueが以下のいずれかの文字を含む場合には、その文字は、バックスラッシュ文字'\'(ASCII 0x5c)と、その後に続く符号化された文字のASCII値を表す二桁の16進数字、として符号化されなければならない。2つの16進数字の大・小文字の表記上の違いは重要ではない。
Character
ASCII value
---------------------------
*
0x2a
(
0x28
)
0x29
\
0x5c
NUL
0x00
この単純なエスケープ機構が、フィルタ解析の際の曖昧さを排除し、LDAPで表記されるどんなフィルタもNUL文字で終了する文字列として表現されることを許容する。上にリストアップされた文字以外の文字でもこの構造を使ってエスケープできる。例えば、印字されない文字である。
例えば、「cn」属性がその値の中のどこかに「*」文字を含んでいるかどうかを調べるフィルタは「(cn=*\2a*)」として表記される。
上の文法で、substringとpresentの両方の生成子とも、「attr=*」という構造子を作れるが、この構造子は、presence filterを表すためだけに使用されることに注意。
このセクションでは、この記号法を使って書かれたいくつかの検索フィルタの例を述べる。
(cn=Babs Jensen)
(!(cn=Tim Howes))
(&(objectClass=Person)(|(sn=Jensen)(cn=Babs
J*)))
(o=univ*of*mich*)
次の例は、拡張可能適合の使用例である。
(cn:1.2.3.4.5:=Fred Flintstone)
(sn:dn:2.4.6.8.10:=Barney Rubble)
(o:dn:=Ace Industry)
(:dn:2.4.6.8.10:=Dino)
2番目の例は、比較の際に適合規則「2.4.6.8.10」を使用されるべきであることを示す「:dn」記法の使用例であり、適合の評価中は、エントリの識別名の属性は、エントリの一部であると考えられるべきであることを示している。
3番目の例は、適合の際に、DNの要素がエントリの一部と考えられるべきであるもの以外の等価適合の例である。
４番目の例は与えられた適合規則をサポートしている属性のどれにでも（attrが指定されないままになっているため）適用されるフィルタである。DNに含まれているその適合規則をサポートしている属性も、同じく考慮されるべきである。
次の例はエスケープ機構の使用例を示す。
(o=Parens R Us \28for all your
parenthetical needs\29)
(cn=*\2A*)
(filename=C:\5cMyFile)
(bin=\00\00\00\04)
(sn=Lu\c4\8di\c4\87)
最初の例は「（ ）」文字を表記するためのエスケープ機構の例である。2番目は、それがsubstringとして解釈されないための、値中にある「*」文字の表現方法を示す。3番目はバックスラッシュ文字のエスケープ例である。
4番目の例は、4バイトの値0x00000004を検索しているフィルタであり、NUL文字を含む、任意のデータを表記するためのエスケープ機構の使用例を示している。
最後の例は様々な非ASCII UTF-8文字を表記するためのエスケープ機構の使用例を示す。
このメモはLDAP検索フィルタの文字列表記を記述する。この表現自体には、知られたセキュリティ関連の話はないが、LDAP検索フィルタにはある。それらは検索されるデータからエントリを選ぶためにLDAPサーバによって解釈される。LDAPサーバはそれらが保持しているデータを無許可のアクセスから保護することに注意するべきである。
[1] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [2] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [3] Specification of ASN.1 encoding rules: Basic, Canonical, and Distinguished Encoding Rules, ITU-T Recommendation X.690, 1994. [4] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996. [5] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
Tim Howes Netscape Communications Corp. 501 E. Middlefield Road Mountain View, CA 94043 USA Phone: +1 415 937-3419 EMail: howes@netscape.com
Copyright (C) The Internet Society (1997). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.