RFC4515 日本語訳

Network Working Group                                      M. Smith, Ed.
Request for Comments: 4515                           Pearl Crescent, LLC
Obsoletes: 2254                                                 T. Howes
Category: Standards Track                                  Opsware, Inc.
                                                               June 2006

ワーキンググループのM.スミス、エドをネットワークでつないでください。コメントのために以下を要求してください。 4515年の真珠三日月、LLCは以下を時代遅れにします。 2254年のT.ハウズカテゴリ: 標準化過程Opsware Inc.2006年6月

             Lightweight Directory Access Protocol (LDAP):
                String Representation of Search Filters

ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP): 検索フィルタのストリング表現

Status of This Memo

このメモの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

Abstract

要約

   Lightweight Directory Access Protocol (LDAP) search filters are
   transmitted in the LDAP protocol using a binary representation that
   is appropriate for use on the network.  This document defines a
   human-readable string representation of LDAP search filters that is
   appropriate for use in LDAP URLs (RFC 4516) and in other
   applications.

ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)検索フィルタは、ネットワークにおける使用に、適切な2進法表示を使用しながら、LDAPプロトコルで送られます。 このドキュメントはLDAP検索フィルタのLDAP URL(RFC4516)と他のアプリケーションにおける使用に、適切な人間読み込み可能なストリング表現を定義します。

Table of Contents

目次

   1. Introduction ....................................................2
   2. LDAP Search Filter Definition ...................................2
   3. String Search Filter Definition .................................3
   4. Examples ........................................................5
   5. Security Considerations .........................................7
   6. Normative References ............................................7
   7. Informative References ..........................................8
   8. Acknowledgements ................................................8
   Appendix A: Changes Since RFC 2254 .................................9
      A.1. Technical Changes ..........................................9
      A.2. Editorial Changes ..........................................9

1. 序論…2 2. LDAPはフィルター定義を捜します…2 3. 検索フィルター定義を結んでください…3 4. 例…5 5. セキュリティ問題…7 6. 標準の参照…7 7. 有益な参照…8 8. 承認…8 付録A: RFC2254以来の変化…9 A.1。 技術的な変化…9 A.2。 社説は変化します…9

Smith and Howes             Standards Track                     [Page 1]

RFC 4515     LDAP: String Representation of Search Filters     June 2006

スミスとハウズStandardsはRFC4515LDAPを追跡します[1ページ]: 検索のストリング表現は2006年6月をフィルターにかけます。

1.  Introduction

1. 序論

   The Lightweight Directory Access Protocol (LDAP) [RFC4510] defines a
   network representation of a search filter transmitted to an LDAP
   server.  Some applications may find it useful to have a common way of
   representing these search filters in a human-readable form; LDAP URLs
   [RFC4516] are an example of one such application.  This document
   defines a human-readable string format for representing the full
   range of possible LDAP version 3 search filters, including extended
   match filters.

ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)[RFC4510]はLDAPサーバに送られた検索フィルタのネットワーク表現を定義します。いくつかのアプリケーションが、人間読み込み可能なフォームにこれらの検索フィルタを表す一般的な方法を持っているのが役に立つのがわかるかもしれません。 LDAP URL[RFC4516]はそのようなアプリケーションの1つに関する例です。 このドキュメントは最大限の範囲の可能なLDAPバージョン3検索フィルタを表すために人間読み込み可能な記号列の書式を定義します、拡張マッチフィルタを含んでいて。

   This document is a integral part of the LDAP technical specification
   [RFC4510], which obsoletes the previously defined LDAP technical
   specification, RFC 3377, in its entirety.

このドキュメントはLDAP技術仕様書[RFC4510]の不可欠の部分です。(それは、以前に定義されたLDAP技術仕様書、RFC3377を全体として時代遅れにします)。

   This document replaces RFC 2254.  Changes to RFC 2254 are summarized
   in Appendix A.

このドキュメントはRFC2254を取り替えます。 RFC2254への変化はAppendix Aにまとめられます。

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14 [RFC2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14[RFC2119]で説明されるように本書では解釈されることであるべきですか?

2.  LDAP Search Filter Definition

2. LDAP検索フィルター定義

   An LDAP search filter is defined in Section 4.5.1 of [RFC4511] as
   follows:

LDAP検索フィルタは以下の.1セクション4.5[RFC4511]で定義されます:

        Filter ::= CHOICE {
            and                [0] SET SIZE (1..MAX) OF filter Filter,
            or                 [1] SET SIZE (1..MAX) OF filter 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 }

以下をフィルターにかけてください:= 選択そして、[2]フィルタ、AttributeValueAssertion(サブストリング[4]SubstringFilter、greaterOrEqual[5]AttributeValueAssertion、lessOrEqual[6]AttributeValueAssertion)が[7]AttributeDescription、approxMatch[8]AttributeValueAssertion、extensibleMatch[9]MatchingRuleAssertionを寄贈するequalityMatch[3]ではなく、[0]のSET SIZE(1..MAX)OFフィルタFilter、または[1]SET SIZE(1..MAX)OFフィルタFilter

        SubstringFilter ::= SEQUENCE {
            type    AttributeDescription,
            -- initial and final can occur at most once
            substrings    SEQUENCE SIZE (1..MAX) OF substring CHOICE {
             initial        [0] AssertionValue,
             any            [1] AssertionValue,
             final          [2] AssertionValue } }

SubstringFilter:、:= 系列AttributeDescriptionをタイプしてください--サブストリングSEQUENCE SIZE(1..MAX)OFサブストリングCHOICEがいったん[0]AssertionValue、どんな[1]AssertionValue、決勝[2]AssertionValueにも頭文字をつけると、初期的、そして、最終的な缶は高々現れます。

Smith and Howes             Standards Track                     [Page 2]

RFC 4515     LDAP: String Representation of Search Filters     June 2006

スミスとハウズStandardsはRFC4515LDAPを追跡します[2ページ]: 検索のストリング表現は2006年6月をフィルターにかけます。

        AttributeValueAssertion ::= SEQUENCE {
            attributeDesc   AttributeDescription,
            assertionValue  AssertionValue }

AttributeValueAssertion:、:= 系列attributeDesc AttributeDescription、assertionValue AssertionValue

        MatchingRuleAssertion ::= SEQUENCE {
            matchingRule    [1] MatchingRuleId OPTIONAL,
            type            [2] AttributeDescription OPTIONAL,
            matchValue      [3] AssertionValue,
            dnAttributes    [4] BOOLEAN DEFAULT FALSE }

MatchingRuleAssertion:、:= 系列matchingRule[1]MatchingRuleId OPTIONAL、タイプ[2]AttributeDescription OPTIONAL、matchValue[3]AssertionValue、dnAttributes[4]BOOLEAN DEFAULT FALSE

        AttributeDescription ::= LDAPString
                        -- Constrained to <attributedescription>
                        -- [RFC4512]

AttributeDescription:、:= LDAPString--<attributedescription>に抑制されます--[RFC4512]

        AttributeValue ::= OCTET STRING

AttributeValue:、:= 八重奏ストリング

        MatchingRuleId ::= LDAPString

MatchingRuleId:、:= LDAPString

        AssertionValue ::= OCTET STRING

AssertionValue:、:= 八重奏ストリング

        LDAPString ::= OCTET STRING -- UTF-8 encoded,
                                    -- [Unicode] characters

LDAPString:、:= OCTET STRING--コード化されたUTF-8--[ユニコード]キャラクタ

   The AttributeDescription, as defined in [RFC4511], is a string
   representation of the attribute description that is discussed in
   [RFC4512].  The AttributeValue and AssertionValue OCTET STRING have
   the form defined in [RFC4517].  The Filter is encoded for
   transmission over a network using the Basic Encoding Rules (BER)
   defined in [X.690], with simplifications described in [RFC4511].

[RFC4511]で定義されるAttributeDescriptionは[RFC4512]で議論する属性記述のストリング表現です。 AttributeValueとAssertionValue OCTET STRINGには、[RFC4517]で定義された書式があります。 Filterはネットワークの上のトランスミッションのために[X.690]で定義されたBasic Encoding Rules(BER)を使用することでコード化されます、簡素化が[RFC4511]で説明されている状態で。

3.  String Search Filter Definition

3. ストリング検索フィルター定義

   The string representation of an LDAP search filter is a string of
   UTF-8 [RFC3629] encoded Unicode characters [Unicode] that is defined
   by the following grammar, following the ABNF notation defined in
   [RFC4234].  The productions used that are not defined here are
   defined in Section 1.4 (Common ABNF Productions) of [RFC4512] unless
   otherwise noted.  The filter format uses a prefix notation.

LDAP検索フィルタのストリング表現は以下の文法によって定義される一連のUTF-8[RFC3629]のコード化されたユニコード文字[ユニコード]です、[RFC4234]で定義されたABNF記法に従って。 別の方法で注意されない場合、ここで定義されない使用される創作は[RFC4512]のセクション1.4(一般的なABNF Productions)で定義されます。 フィルタ形式は前置表記法を使用します。

      filter         = LPAREN filtercomp RPAREN
      filtercomp     = and / or / not / item
      and            = AMPERSAND filterlist
      or             = VERTBAR filterlist
      not            = EXCLAMATION filter
      filterlist     = 1*filter
      item           = simple / present / substring / extensible
      simple         = attr filtertype assertionvalue
      filtertype     = equal / approx / greaterorequal / lessorequal

どんなフィルタ=LPAREN filtercomp RPAREN filtercomp=と/か//項目と=AMPERSAND filterlistも=VERTBAR filterlistも1*フィルタのEXCLAMATIONフィルタfilterlist=品目=簡単であるか現在の/サブストリング/広げることができる簡単な=attr filtertype assertionvalue filtertype=同輩/と約等しくない、/ greaterorequal / lessorequal

Smith and Howes             Standards Track                     [Page 3]

RFC 4515     LDAP: String Representation of Search Filters     June 2006

スミスとハウズStandardsはRFC4515LDAPを追跡します[3ページ]: 検索のストリング表現は2006年6月をフィルターにかけます。

      equal          = EQUALS
      approx         = TILDE EQUALS
      greaterorequal = RANGLE EQUALS
      lessorequal    = LANGLE EQUALS
      extensible     = ( attr [dnattrs]
                           [matchingrule] COLON EQUALS assertionvalue )
                       / ( [dnattrs]
                            matchingrule COLON EQUALS assertionvalue )
      present        = attr EQUALS ASTERISK
      substring      = attr EQUALS [initial] any [final]
      initial        = assertionvalue
      any            = ASTERISK *(assertionvalue ASTERISK)
      final          = assertionvalue
      attr           = attributedescription
                         ; The attributedescription rule is defined in
                         ; Section 2.5 of [RFC4512].
      dnattrs        = COLON "dn"
      matchingrule   = COLON oid
      assertionvalue = valueencoding
      ; The <valueencoding> rule is used to encode an <AssertionValue>
      ; from Section 4.1.6 of [RFC4511].
      valueencoding  = 0*(normal / escaped)
      normal         = UTF1SUBSET / UTFMB
      escaped        = ESC HEX HEX
      UTF1SUBSET     = %x01-27 / %x2B-5B / %x5D-7F
                          ; UTF1SUBSET excludes 0x00 (NUL), LPAREN,
                          ; RPAREN, ASTERISK, and ESC.
      EXCLAMATION    = %x21 ; exclamation mark ("!")
      AMPERSAND      = %x26 ; ampersand (or AND symbol) ("&")
      ASTERISK       = %x2A ; asterisk ("*")
      COLON          = %x3A ; colon (":")
      VERTBAR        = %x7C ; vertical bar (or pipe) ("|")
      TILDE          = %x7E ; tilde ("~")

等しい=EQUALSはASTERISK*(assertionvalue ASTERISK)最終的な=assertionvalueいずれ[最終的な]も頭文字をつけるattr EQUALS ASTERISK(attr[dnattrs][matchingrule]コロンEQUALS assertionvalue)/([dnattrs]matchingruleコロンEQUALS assertionvalue)が提示するLANGLE EQUALSの広げることができるTILDE EQUALS greaterorequal=RANGLE EQUALS lessorequal===サブストリング=attr EQUALS[初期の]=いずれも=assertionvalue attr=attributedescriptionと約等しいです。 規則が定義されるattributedescription。 コロンコロン"dn"[RFC4512] dnattrsのセクション2.5=matchingrule=oid assertionvalueはvalueencodingと等しいです。 >規則をvalueencodingする<は<AssertionValue>をコード化するのに使用されます。 セクション4.1を.6 0*(正常であるか逃げられた)正常な=[RFC4511] valueencoding=UTF1SUBSET / UTFMBが=ESC HEX HEX UTF1SUBSET=%からx01-27/%x2B-5B/%x5D-7F逃げました。 UTF1SUBSETは0×00(NUL)、LPARENを除きます。 RPAREN、アスタリスク、およびESC。 感嘆=%x21。 感嘆符(“!")アンパーサンド=%x26。 アンパーサンド(または、ANDシンボル)(“&")アスタリスク=%x2A。 (「*」)コロン=%x3Aに星をつけてください。 コロン、(「:」、)、VERTBAR=%x7C。 縦棒(運ぶ)、(「|」、)、ティルド=%x7E。 ティルド("~")

   Note that although both the <substring> and <present> productions in
   the grammar above can produce the "attr=*" construct, this construct
   is used only to denote a presence filter.

<サブストリング>と上の文法の<の現在の>創作の両方が「attr=*」構造物を生産できますが、この構造物が使用されることに注意してください存在フィルタを指示する。

   The <valueencoding> rule ensures that the entire filter string is a
   valid UTF-8 string and provides that the octets that represent the
   ASCII characters "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII
   0x29), "\" (ASCII 0x5c), and NUL (ASCII 0x00) are represented as a
   backslash "\" (ASCII 0x5c) followed by the two hexadecimal digits
   representing the value of the encoded octet.

<、規則が確実にする全体のフィルタが結ぶ>をvalueencodingして、有効なUTF-8がそれを結んで、提供するaがASCII文字「*」を表す八重奏である、(ASCII0x2a)、「(「(ASCII0x28)、」、)、」 「\」(ASCII0x5c)というバックスラッシュがコード化された八重奏の値を表す2つの16進数字で従ったので、(ASCII0x29)、「\」(ASCII0x5c)、およびNUL(ASCII0x00)は表されます。

Smith and Howes             Standards Track                     [Page 4]

RFC 4515     LDAP: String Representation of Search Filters     June 2006

スミスとハウズStandardsはRFC4515LDAPを追跡します[4ページ]: 検索のストリング表現は2006年6月をフィルターにかけます。

   This simple escaping mechanism eliminates filter-parsing ambiguities
   and allows any filter that can be represented in LDAP to be
   represented as a NUL-terminated string.  Other octets that are part
   of the <normal> set may be escaped using this mechanism, for example,
   non-printing ASCII characters.

この簡単なエスケープメカニズムは、フィルタを分析するあいまいさを排除して、LDAPに表すことができるどんなフィルタもNULによって終えられたストリングとして表されるのを許容します。 <の正常な>セットの一部である他の八重奏、このメカニズム、例えば非印刷ASCII文字を使用することで逃げられるかもしれません。

   For AssertionValues that contain UTF-8 character data, each octet of
   the character to be escaped is replaced by a backslash and two hex
   digits, which form a single octet in the code of the character.  For
   example, the filter checking whether the "cn" attribute contained a
   value with the character "*" anywhere in it would be represented as
   "(cn=*\2a*)".

UTF-8キャラクタデータを含むAssertionValuesに関しては、逃げられるべきキャラクタの各八重奏をバックスラッシュと2十六進法ケタに取り替えます。(ケタはキャラクタのコードにおけるただ一つの八重奏を形成します)。 例えば、"cn"属性がそれでどこでもキャラクタ「*」がある値を含んだか否かに関係なく、フィルタの照合は「(cn=*\2a*)」として表されるでしょう。

   As indicated by the <valueencoding> rule, implementations MUST escape
   all octets greater than 0x7F that are not part of a valid UTF-8
   encoding sequence when they generate a string representation of a
   search filter.  Implementations SHOULD accept as input strings that
   are not valid UTF-8 strings.  This is necessary because RFC 2254 did
   not clearly define the term "string representation" (and in
   particular did not mention that the string representation of an LDAP
   search filter is a string of UTF-8-encoded Unicode characters).

>規則をvalueencodingする<によって示されるように、実装はストリングが検索フィルタの表現であると生成すると系列をコード化する有効なUTF-8の一部でない0x7Fより大きいすべての八重奏から逃げなければなりません。 実装SHOULDは有効なUTF-8ストリングでない入力ストリングとして受け入れます。 RFC2254が明確に「ストリング表現」(そして、LDAP検索フィルタのストリング表現が一連のコード化されたUTF8ユニコード文字であると特に言及しなかった)という用語を定義しなかったので、これが必要です。

4.  Examples

4. 例

   This section gives a few examples of search filters written using
   this notation.

このセクションはこの記法を使用することで書かれた検索フィルタに関するいくつかの例を出します。

        (cn=Babs Jensen)
        (!(cn=Tim Howes))
        (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
        (o=univ*of*mich*)
        (seeAlso=)

(cnはBabsジェンセンと等しいです) ((ティム・cn=ハウズ))((objectClassは人と等しいです)(| (snはジェンセンと等しいです)(バブスcn=J*)))(*mich*のo=univ*)(seeAlso=)

   The following examples illustrate the use of extensible matching.

以下の例は広げることができるマッチングの使用を例証します。

        (cn:caseExactMatch:=Fred Flintstone)
        (cn:=Betty Rubble)
        (sn:dn:2.4.6.8.10:=Barney Rubble)
        (o:dn:=Ace Industry)
        (:1.2.3:=Wilma Flintstone)
        (:DN:2.4.6.8.10:=Dino)

(cn:caseExactMatch:=フレッドFlintstone) (cn: =ベティRubble) (sn: dn:、2.4、.6、.8、.10、: =バニー瓦礫) (o:dn:=エース産業)、(: 1.2、.3:、=ウィルマFlintstone)(: DN: 2.4、.6、.8、.10:、=ディーノ)

   The first example shows use of the matching rule "caseExactMatch."

最初の例は合っている規則"caseExactMatch"の使用を示しています。

   The second example demonstrates use of a MatchingRuleAssertion form
   without a matchingRule.

2番目の例はmatchingRuleなしでMatchingRuleAssertionフォームの使用を示します。

Smith and Howes             Standards Track                     [Page 5]

RFC 4515     LDAP: String Representation of Search Filters     June 2006

スミスとハウズStandardsはRFC4515LDAPを追跡します[5ページ]: 検索のストリング表現は2006年6月をフィルターにかけます。

   The third example illustrates the use of the ":oid" notation to
   indicate that the matching rule identified by the OID "2.4.6.8.10"
   should be used when making comparisons, and that the attributes of an
   entry's distinguished name should be considered part of the entry
   when evaluating the match (indicated by the use of ":dn").

「3番目の例が使用を例証する、」、:、」 示す合っている規則がOIDで特定した記法をoidする、「2.4、.6、マッチを評価するとき、比較、およびそれを属性にすると0.1インチが使用されているべきである.8がエントリーを離れさせる、エントリーの分類名が考えられるべきである(」 : dnの使用で示される、」、)

   The fourth example denotes an equality match, except that DN
   components should be considered part of the entry when doing the
   match.

4番目の例は平等マッチを指示します、マッチをするとき、DNの部品がエントリーの一部であると考えられるべきであるのを除いて。

   The fifth example is a filter that should be applied to any attribute
   supporting the matching rule given (since the <attr> has been
   omitted).

5番目の例は与えられた合っている規則をサポートするどんな属性にも適用されるべきであるフィルタ(<attr>が省略されたので)です。

   The sixth and final example is also a filter that should be applied
   to any attribute supporting the matching rule given.  Attributes
   supporting the matching rule contained in the DN should also be
   considered.

また、6番目の、そして、最終的な例は与えられた合っている規則をサポートするどんな属性にも適用されるべきであるフィルタです。 また、DNに含まれた合っている規則をサポートする属性は考えられるべきです。

   The following examples illustrate the use of the escaping mechanism.

以下の例はエスケープメカニズムの使用を例証します。

        (o=Parens R Us \28for all your parenthetical needs\29)
        (cn=*\2A*)
        (filename=C:\5cMyFile)
        (bin=%%BODY%%0%%BODY%%0%%BODY%%0%%BODY%%4)
        (sn=Lu\c4\8di\c4\87)
        (1.3.6.1.4.1.1466.0=%%BODY%%4%%BODY%%2\48\69)

(あなたのすべての挿入語句が29円必要とするo=Parens R Us\28for)(cn=*\2A*)(ファイル名=C: \5cMyFile)(容器00=円00円00円04円)(snはLu\c4\8di\c4と87円等しいです)(1.3.6.1.4.1.1466.0=%%BODY%%4%%BODY%%2\48\69)

   The first example shows the use of the escaping mechanism to
   represent parenthesis characters.  The second shows how to represent
   a "*" in an assertion value, preventing it from being interpreted as
   a substring indicator.  The third illustrates the escaping of the
   backslash character.

最初の例は、挿入句キャラクタの代理をするためにエスケープメカニズムの使用を示しています。 秒は、どのように主張値における「*」を表すかを示します、それがサブストリングインディケータとして解釈されるのを防いで。 3番目はバックスラッシュキャラクタのエスケープを例証します。

   The fourth example shows a filter searching for the four-octet value
   00 00 00 04 (hex), illustrating the use of the escaping mechanism to
   represent arbitrary data, including NUL characters.

4番目の例は、フィルタが4八重奏の値00 00 00 04(魔法をかけます)を捜し求めるのを示します、任意のデータを表すためにエスケープメカニズムの使用を例証して、NULキャラクタを含んでいて。

   The fifth example illustrates the use of the escaping mechanism to
   represent various non-ASCII UTF-8 characters.  Specifically, there
   are 5 characters in the <assertionvalue> portion of this example:
   LATIN CAPITAL LETTER L (U+004C), LATIN SMALL LETTER U (U+0075), LATIN
   SMALL LETTER C WITH CARON (U+010D), LATIN SMALL LETTER I (U+0069),
   and LATIN SMALL LETTER C WITH ACUTE (U+0107).

5番目の例は、様々な非ASCII UTF-8キャラクタの代理をするためにエスケープメカニズムの使用を例証します。 明確に、5つのキャラクタがこの例の<assertionvalue>部分にあります: ラテン語の大文字L(U+004C)、ラテン語の小文字U(U+0075)、キャロンとのラテン語の小文字C(U+010D)、ラテン語の小文字I(U+0069)、および鋭いのがあるラテン語の小文字C(U+0107)。

   The sixth and final example demonstrates assertion of a BER-encoded
   value.

6番目の、そして、最終的な例はBERによってコード化された価値の主張を示します。

Smith and Howes             Standards Track                     [Page 6]

RFC 4515     LDAP: String Representation of Search Filters     June 2006

スミスとハウズStandardsはRFC4515LDAPを追跡します[6ページ]: 検索のストリング表現は2006年6月をフィルターにかけます。

5.  Security Considerations

5. セキュリティ問題

   This memo describes a string representation of LDAP search filters.
   While the representation itself has no known security implications,
   LDAP search filters do.  They are interpreted by LDAP servers to
   select entries from which data is retrieved.  LDAP servers should
   take care to protect the data they maintain from unauthorized access.

このメモはLDAP検索フィルタのストリング表現について説明します。 表現自体には知られているセキュリティ意味が全くない間、LDAP検索フィルタは持っています。 それらはLDAPサーバによって解釈されて、データが検索されるエントリーを選択します。 LDAPサーバは、それらが不正アクセスから保守するデータを保護するために注意されるべきです。

   Please refer to the Security Considerations sections of [RFC4511] and
   [RFC4513] for more information.

詳しい情報について[RFC4511]と[RFC4513]のSecurity Considerations部を参照してください。

6.  Normative References

6. 引用規格

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC3629]   Yergeau, F., "UTF-8, a transformation format of ISO
               10646", STD 63, RFC 3629, November 2003.

[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日

   [RFC4234]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
               Specifications: ABNF", RFC 4234, October 2005.

[RFC4234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。

   [RFC4510]   Zeilenga, K., Ed., "Lightweight Directory Access Protocol
               (LDAP): Technical Specification Road Map", RFC 4510, June
               2006.

[RFC4510] Zeilenga、K.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「仕様書ロードマップ」、RFC4510、2006年6月。

   [RFC4511]   Sermersheim, J., Ed., "Lightweight Directory Access
               Protocol (LDAP): The Protocol", RFC 4511, June 2006.

[RFC4511] Sermersheim、J.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「プロトコル」、RFC4511、2006年6月。

   [RFC4512]   Zeilenga, K., "Lightweight Directory Access Protocol
               (LDAP): Directory Information Models", RFC 4512, June
               2006.

[RFC4512] Zeilenga、K.、「軽量のディレクトリアクセスは以下について議定書の中で述べ(LDAP)」。 「ディレクトリ情報モデル」、RFC4512、2006年6月。

   [RFC4513]   Harrison, R., Ed., "Lightweight Directory Access Protocol
               (LDAP): Authentication Methods and Security Mechanisms",
               RFC 4513, June 2006.

[RFC4513] ハリソン、R.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「認証方法とセキュリティー対策」、RFC4513、6月2006日

   [RFC4517]   Legg, S., Ed., "Lightweight Directory Access Protocol
               (LDAP): Syntaxes and Matching Rules", RFC 4517, June
               2006.

[RFC4517] Legg、S.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「構文とマッチングは統治する」RFC4517、2006年6月。

   [Unicode]   The Unicode Consortium, "The Unicode Standard, Version
               3.2.0" is defined by "The Unicode Standard, Version 3.0"
               (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
               as amended by the "Unicode Standard Annex #27: Unicode
               3.1" (http://www.unicode.org/reports/tr27/) and by the
               "Unicode Standard Annex #28: Unicode 3.2."

[ユニコード] ユニコードConsortium、「ユニコード規格、バージョン、3.2、0インチ、定義される、「ユニコード規格、修正されるバージョン3インチ(読書、MA、アディソン-ウエスリー、2000ISBN0-201-61633-5)、「ユニコード規格別館#27:」 「ユニコード規格別館#28:」 「ユニコード3.2。」

Smith and Howes             Standards Track                     [Page 7]

RFC 4515     LDAP: String Representation of Search Filters     June 2006

スミスとハウズStandardsはRFC4515LDAPを追跡します[7ページ]: 検索のストリング表現は2006年6月をフィルターにかけます。

7.  Informative References

7. 有益な参照

   [RFC4516]   Smith, M., Ed. and T. Howes, "Lightweight Directory
               Access Protocol (LDAP): Uniform Resource Locator", RFC
               4516, June 2006.

[RFC4516] エドスミス、M.、T.ハウズ、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「Uniform Resource Locator」、RFC4516、2006年6月。

   [X.690]     Specification of ASN.1 encoding rules: Basic, Canonical,
               and Distinguished Encoding Rules, ITU-T Recommendation
               X.690, 1994.

ASN.1符号化規則の[X.690]仕様: 基本的で、正準で、顕著なコード化はITU-T推薦X.690、1994に統治されます。

8.  Acknowledgements

8. 承認

   This document replaces RFC 2254 by Tim Howes.  RFC 2254 was a product
   of the IETF ASID Working Group.

このドキュメントはRFC2254をティム・ハウズに取り替えます。 RFC2254はIETF ASID作業部会の製品でした。

   Changes included in this revised specification are based upon
   discussions among the authors, discussions within the LDAP (v3)
   Revision Working Group (ldapbis), and discussions within other IETF
   Working Groups.  The contributions of individuals in these working
   groups is gratefully acknowledged.

この訂正明細書に含まれていた変化は作者の中の議論、LDAP(v3)改正作業部会(ldapbis)の中の議論、および他のIETF Working Groupsの中の議論に基づいています。 これらのワーキンググループにおける、個人の貢献は感謝して承諾されます。

Smith and Howes             Standards Track                     [Page 8]

RFC 4515     LDAP: String Representation of Search Filters     June 2006

スミスとハウズStandardsはRFC4515LDAPを追跡します[8ページ]: 検索のストリング表現は2006年6月をフィルターにかけます。

Appendix A: Changes Since RFC 2254

付録A: RFC2254以来の変化

A.1.  Technical Changes

A.1。 技術変化

   Replaced [ISO 10646] reference with [Unicode].

[ユニコード]に参照を置き換えました[ISO10646]。

   The following technical changes were made to the contents of the
   "String Search Filter Definition" section:

以下の技術変化を「ストリング検索フィルター定義」セクションのコンテンツにしました:

   Added statement that the string representation is a string of UTF-8-
   encoded Unicode characters.

ストリング表現が一連のUTF-8でコード化されたユニコード文字であるという声明を加えました。

   Revised all of the ABNF to use common productions from [RFC4512].

[RFC4512]からの一般的な創作を使用するためにABNFのすべてを改訂しました。

   Replaced the "value" rule with a new "assertionvalue" rule within the
   "simple", "extensible", and "substring" ("initial", "any", and
   "final") rules.  This matches a change made in [RFC4517].

「値」規則を「簡単」の中の「広げることができる」新しい"assertionvalue"規則、および「サブストリング」(「いずれと、決勝」に「頭文字をつける」)規則に取り替えました。 これは[RFC4517]で行われた変更に合っています。

   Added "(" and ")" around the components of the <extensible>
   subproductions for clarity.

そして、付加、「(「」、)、」 明快のための<の広げることができる>「副-創作」の部品の周りで。

   Revised the "attr", "matchingrule", and "assertionvalue" ABNF to more
   precisely reference productions from the [RFC4512] and [RFC4511]
   documents.

[RFC4512]と[RFC4511]ドキュメントからの、より正確に参照創作への改訂された"attr"、"matchingrule"、および"assertionvalue"ABNF。

   "String Search Filter Definition" section: replaced "greater" and
   "less" with "greaterorequal" and "lessorequal" to avoid confusion.

「ストリング検索Filter Definition」セクション: "greaterorequal"と混乱を避ける"lessorequal"で「よりすばらしく」「より少ない」状態で、取り替えます。

   Introduced the "valueencoding" and associated "normal" and "escaped"
   rules to reduce the dependence on descriptive text.  The "normal"
   production restricts filter strings to valid UTF-8 sequences.

「valueencoding」と関連「標準」を導入して、説明文への依存を減少させるために規則から「逃げました」。 「正常な」生産はフィルタストリングを有効なUTF-8系列に制限します。

   Added a statement about expected behavior in light of RFC 2254's lack
   of a clear definition of "string representation."

RFC2254の「ストリング表現」の明確な定義の不足の観点から予想された振舞いに関する声明を加えました。

A.2.  Editorial Changes

A.2。 編集の変化

   Changed document title to include "LDAP:" prefix.

含んでいるドキュメントタイトルを変える、「LDAP:」 前に置きます。

   IESG Note: removed note about lack of satisfactory mandatory
   authentication mechanisms.

IESGは以下に注意します。 満足できる義務的な認証機構の不足に関する注を取り除きました。

   Header and "Authors' Addresses" sections: added Mark Smith as the
   document editor and updated affiliation and contact information.

ヘッダーと「は作者」 セクションに演説します: ドキュメントエディタとしてマーク・スミスを加えて、提携と問い合わせ先をアップデートしました。

   "Table of Contents" and "Intellectual Property" sections: added.

「目次」と「知的所有権」セクション: 加えられる。

   Copyright: updated per latest IETF guidelines.

著作権: 最新のIETFガイドライン単位でアップデートします。

Smith and Howes             Standards Track                     [Page 9]

RFC 4515     LDAP: String Representation of Search Filters     June 2006

スミスとハウズStandardsはRFC4515LDAPを追跡します[9ページ]: 検索のストリング表現は2006年6月をフィルターにかけます。

   "Abstract" section: separated from introductory material.

「抽象的な」セクション: 紹介している材料と、切り離されます。

   "Introduction" section: new section; separated from the Abstract.
   Updated second paragraph to indicate that RFC 2254 is replaced by
   this document (instead of RFC 1960).  Added reference to the
   [RFC4510] document.

「序論」セクション: 新しいセクション。 要約と、切り離されます。 RFC2254がこのドキュメント(RFC1960の代わりに)に取り替えられるのを示すために第2パラグラフをアップデートしました。 [RFC4510]ドキュメントの参照を加えました。

   "LDAP Search Filter Definition" section: made corrections to the LDAP
   search filter ABNF so it matches that used in [RFC4511].

「LDAP検索Filter Definition」セクション: LDAPへの人工の修正がフィルタABNFを捜すので、それは[RFC4511]で使用されるそれに合っています。

   Clarified the definition of 'value' (now 'assertionvalue') to take
   into account the fact that it is not precisely an AttributeAssertion
   from [RFC4511] Section 4.1.6 (special handling is required for some
   characters).  Added a note that each octet of a character to be
   escaped is replaced by a backslash and two hex digits, which
   represent a single octet.

それが正確に[RFC4511]セクション4.1.6からのAttributeAssertion(特別な取り扱いが何人かのキャラクタに必要である)でないという事実を考慮に入れるために'値'(現在の'assertionvalue')の定義をはっきりさせました。 逃げられるべきキャラクタの各八重奏をバックスラッシュに取り替えるというメモと2十六進法ケタを加えました。(ケタはただ一つの八重奏を表します)。

   "Examples" section: added four additional examples: (seeAlso=),
   (cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone), and
   (1.3.6.1.4.1.1466.0=%%BODY%%4%%BODY%%2\48\69).  Replaced one occurrence of "a
   value" with "an assertion value".  Corrected the description of this
   example: (sn:dn:2.4.6.8.10:=Barney Rubble).  Replaced the numeric OID
   in the first extensible match example with "caseExactMatch" to
   demonstrate use of the descriptive form.  Used "DN" (uppercase) in
   the last extensible match example to remind the reader to treat the
   <dnattrs> production as case insensitive.  Reworded the description
   of the fourth escaping mechanism example to avoid making assumptions
   about byte order.  Added text to the fifth escaping mechanism example
   to spell out what the non-ASCII characters are in Unicode terms.

「例」セクション: 4つの付記された追加例: (seeAlso=), (cn: =ベティRubble), (: 1.2、.3:、=ウィルマFlintstone), そして、(04 1.3.6.1.4.1.1466.0=円02円48円69円。) 「値」の1回の発生に「主張値」に取って代わりました。 直る、この例の記述: (: .6.8.10=バーニーが瓦礫にするsn:dn:2.4。) 描写的であるフォームの使用を示すために最初の広げることができるマッチの例で数値OIDを"caseExactMatch"に取り替えました。 広げることができる最終の中古の"DN"(大文字)は、大文字と小文字を区別しないとして<dnattrs>生産を扱うように読者に思い出させるために例に合っています。 バイトオーダーに関する仮定をするのを避けるために4番目に逃げているメカニズムの例の記述を言い換えました。 ユニコード用語で非ASCII文字が者であると詳しく説明するために5番目に逃げているメカニズムの例にテキストを追加しました。

   "Security Considerations" section: added references to [RFC4511] and
   [RFC4513].

「セキュリティConsiderations」セクション: [RFC4511]と[RFC4513]の参照を加えました。

   "Normative References" section: renamed from "References" per new RFC
   guidelines.  Changed from [1] style to [RFC4511] style throughout the
   document.  Added entries for [Unicode], [RFC2119], [RFC4513],
   [RFC4512], and [RFC4510] and updated the UTF-8 reference.  Replaced
   RFC 822 reference with a reference to RFC 4234.

「標準のReferences」セクション: 新しいRFCガイドラインあたりの「参照」から、改名されます。 ドキュメント中で[1] スタイルから[RFC4511]スタイルに変えます。 [ユニコード]、[RFC2119]、[RFC4513]、[RFC4512]、および[RFC4510]のためにエントリーを加えて、UTF-8参照をアップデートしました。 RFC822参照をRFC4234の参照に取り替えました。

   "Informative References" section: (new section) moved [X.690] to this
   section.  Added a reference to [RFC4516].

「有益なReferences」セクション: (新しいセクション) [X.690]をこのセクションに動かしました。 [RFC4516]の参照を加えました。

   "Acknowledgements" section: added.

「承認」セクション: 加えられる。

   "Appendix A: Changes Since RFC 2254" section: added.

「付録A:」 「変化Since RFC2254」セクション: 加えられる。

   Surrounded the names of all ABNF productions with "<" and ">" where
   they are used in descriptive text.

それらが説明文で使用される"<"と">"にすべてのABNF創作の名前を取り巻きました。

Smith and Howes             Standards Track                    [Page 10]

RFC 4515     LDAP: String Representation of Search Filters     June 2006

スミスとハウズStandardsはRFC4515LDAPを追跡します[10ページ]: 検索のストリング表現は2006年6月をフィルターにかけます。

   Replaced all occurrences of "LDAPv3" with "LDAP."

「"LDAP"があるLDAPv3"」のすべての発生に取って代わります。

Authors' Addresses

作者のアドレス

   Mark Smith, Editor
   Pearl Crescent, LLC
   447 Marlpool Dr.
   Saline, MI 48176
   USA

エディタ真珠三日月、LLC447Marlpool Saline博士、MI48176米国のマーク・スミス

   Phone: +1 734 944-2856
   EMail: mcs@pearlcrescent.com

以下に電話をしてください。 +1 734 944-2856 メールしてください: mcs@pearlcrescent.com

   Tim Howes
   Opsware, Inc.
   599 N. Mathilda Ave.
   Sunnyvale, CA 94085
   USA

ティムハウズOpsware Inc.599N.マチルダAve。 サニーベル、カリフォルニア94085米国

   Phone: +1 408 744-7509
   EMail: howes@opsware.com

以下に電話をしてください。 +1 408 744-7509 メールしてください: howes@opsware.com

Smith and Howes             Standards Track                    [Page 11]

RFC 4515     LDAP: String Representation of Search Filters     June 2006

スミスとハウズStandardsはRFC4515LDAPを追跡します[11ページ]: 検索のストリング表現は2006年6月をフィルターにかけます。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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.

IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。

Acknowledgement

承認

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Smith and Howes             Standards Track                    [Page 12]

スミスとハウズ標準化過程[12ページ]