Network Working Group S. Legg
Request for Comments: 4522 eB2Bcom
Category: Standards Track June 2006
Lightweight Directory Access Protocol (LDAP):
The Binary Encoding Option
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory has a defined syntax (i.e., data type). A syntax definition specifies how attribute values conforming to the syntax are normally represented when transferred in LDAP operations. This representation is referred to as the LDAP-specific encoding to distinguish it from other methods of encoding attribute values. This document defines an attribute option, the binary option, that can be used to specify that the associated attribute values are instead encoded according to the Basic Encoding Rules (BER) used by X.500 directories.
LDAP（Lightweight Directory Access Protocol）ディレクトリに保存されている各属性には、定義された構文（すなわち、データ型）を持っています。構文定義は、LDAP操作で転送する場合、通常は表現されている構文に準拠した属性値を指定する方法。この表現は、属性値を符号化する他の方法と区別するためにLDAP固有の符号化と呼ばれています。この文書は、関連属性値が代わりにX.500ディレクトリによって使用される基本符号化規則（BER）に従って符号化されることを指定するために使用することができる属性オプション、バイナリオプションを定義します。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions .....................................................2
3. The Binary Option ...............................................2
4. Syntaxes Requiring Binary Transfer ..............................3
5. Attributes Returned in a Search .................................4
6. All User Attributes .............................................4
7. Conflicting Requests ............................................5
8. Security Considerations .........................................5
9. IANA Considerations .............................................5
10. References .....................................................5
10.1. Normative References ......................................5
10.2. Informative References ....................................6
Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory [RFC4510] has a defined syntax (i.e., data type) which constrains the structure and format of its values.
LDAP（Lightweight Directory Access Protocol）ディレクトリ[RFC4510]に格納された各属性は、その値の構造およびフォーマットを制約定義された構文（すなわち、データ型）を有しています。
The description of each syntax [RFC4517] specifies how attribute or assertion values [RFC4512] conforming to the syntax are normally represented when transferred in LDAP operations [RFC4511]. This representation is referred to as the LDAP-specific encoding to distinguish it from other methods of encoding attribute values.
各構文[RFC4517]の説明は、LDAP操作[RFC4511]で転送する際の属性や構文に準拠したアサーション値[RFC4512]が正常に表現される方法を指定します。この表現は、属性値を符号化する他の方法と区別するためにLDAP固有の符号化と呼ばれています。
This document defines an attribute option, the binary option, which can be used in an attribute description [RFC4512] in an LDAP operation to specify that the associated attribute values or assertion values are, or are requested to be, encoded according to the Basic Encoding Rules (BER) [BER] as used by X.500 [X.500] directories, instead of the usual LDAP-specific encoding.
この文書では、基本的な符号化に従って符号化され、属性オプション、関連する属性値またはアサーションの値は、またはであることが要求されるように指定するLDAP操作で属性記述[RFC4512]で使用することができるバイナリオプションを定義します代わりに、通常のLDAP固有の符号化で、X.500 [X.500]ディレクトリによって使用されるルール（BER）[BER]。
The binary option was originally defined in RFC 2251 [RFC2251]. The LDAP technical specification [RFC4510] has obsoleted the previously defined LDAP technical specification [RFC3377], which included RFC 2251. The binary option was not included in the revised LDAP technical specification for a variety of reasons including implementation inconsistencies. No attempt is made here to resolve the known inconsistencies.
バイナリオプションは元々RFC 2251 [RFC2251]で定義されました。 LDAP技術仕様書[RFC4510]は、バイナリオプションは、実装の不整合を含む様々な理由のために改訂されたLDAP技術仕様に含まれていなかったRFC 2251に含ま以前に定義されたLDAP技術仕様書[RFC3377]を廃止しています。試みは知られている矛盾を解決するためにここで行われていません。
This document reintroduces the binary option for use with certain attribute syntaxes, such as certificate syntax [RFC4523], that specifically require it. No attempt has been made to address use of the binary option with attributes of syntaxes that do not require its use. Unless addressed in a future specification, this use is to be avoided.
この文書では、特に必要な証明書の構文などの特定の属性構文で使用するためのバイナリオプション、[RFC4523]を、再導入します。試みは、その使用を必要としないの構文の属性を持つバイナリオプションの使用に対処するためになされていません。将来の仕様で対処されない限り、この使用は避けるべきです。
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, RFC 2119 [BCP14].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [BCP14]で説明されるように解釈されます。
The binary option is indicated with the attribute option string "binary" in an attribute description. Note that, like all attribute options, the string representing the binary option is case insensitive.
バイナリーオプションは属性記述の属性オプション文字列「バイナリ」で示されています。すべての属性オプションのように、バイナリオプションを表す文字列は大文字小文字を区別しないで、ということに注意してください。
Where the binary option is present in an attribute description, the associated attribute values or assertion values MUST be BER encoded (otherwise the values are encoded according to the LDAP-specific encoding [RFC4517] for the attribute's syntax). Note that it is possible for a syntax to be defined such that its LDAP-specific encoding is exactly the same as its BER encoding.
バイナリオプションは、属性の記述中に存在する場合、関連する属性値またはアサーション値（属性の構文は、そうでなければ値は、LDAP固有の符号化に従って符号化される[RFC4517]）BER符号化されなければなりません。構文はそのLDAP固有のエンコードは、そのBERエンコーディングとまったく同じになるように定義することは可能であることに注意してください。
In terms of the protocol [RFC4511], the binary option specifies that the contents octets of the associated AttributeValue or AssertionValue OCTET STRING are a complete BER encoding of the relevant value.
プロトコル[RFC4511]の観点から、バイナリオプションは、関連するAttributeValueの又はAssertionValueのオクテット文字列の内容オクテットが関連値の完全なBER符号化であることを指定します。
The binary option is not a tagging option [RFC4512], so the presence of the binary option does not specify an attribute subtype. An attribute description containing the binary option references exactly the same attribute as the attribute description without the binary option. The supertype/subtype relationships of attributes with tagging options are not altered in any way by the presence or absence of the binary option.
バイナリーオプションは、タギングオプション[RFC4512]ではないので、バイナリオプションの存在は、属性のサブタイプを指定していません。バイナリーオプションなしの属性記述とまったく同じ属性のバイナリオプションの参照を含む属性記述。タグ付けオプションを持つ属性のスーパータイプ/サブタイプの関係は、バイナリオプションの存在または不在により、どのような方法で変更されません。
An attribute description SHALL be treated as unrecognized if it contains the binary option and the syntax of the attribute does not have an associated ASN.1 type [RFC4517], or the BER encoding of values of that type is not supported.
属性記述は、バイナリオプションが含まれている場合に認識されていないとして扱われるものとし、属性の構文は、関連するASN.1タイプ[RFC4517]を有していない、またはそのタイプの値のBER符号化がサポートされていません。
The presence or absence of the binary option only affects the transfer of attribute and assertion values in the protocol; servers store any particular attribute value in a format of their choosing.
バイナリオプションの有無のみプロトコルにおける属性アサーション値の転送に影響を与えます。サーバは、選択した形式で、任意の特定の属性値を格納します。
The attribute values of certain attribute syntaxes are defined without an LDAP-specific encoding and are required to be transferred in the BER-encoded form. For the purposes of this document, these syntaxes are said to have a binary transfer requirement. The certificate, certificate list, certificate pair, and supported algorithm syntaxes [RFC4523] are examples of syntaxes with a binary transfer requirement. These syntaxes also have an additional requirement that the exact BER encoding must be preserved. Note that this is a property of the syntaxes themselves, and not a property of the binary option. In the absence of this requirement, LDAP clients would need to re-encode values using the Distinguished Encoding Rules (DER).
特定の属性構文の属性値は、LDAP固有の符号化なしで定義され、BER符号化された形で転送する必要があります。このドキュメントの目的のために、これらの構文は、バイナリ転送要求を持っていると言われています。証明書、証明書のリスト、証明書のペア、およびサポートされているアルゴリズム構文[RFC4523]はバイナリ転送要求とシンタックスの一例です。これらの構文はまた、正確なBERエンコードが保存しなければならない追加の要件があります。これは、構文の性質そのものではなく、バイナリオプションのプロパティであることに注意してください。この要件の非存在下で、LDAPクライアントは、識別符号化規則（DER）を使用するために再エンコード値を必要とします。
An LDAP search request [RFC4511] contains a list of the attributes (the requested attributes list) to be returned from each entry matching the search filter. An attribute description in the requested attributes list also implicitly requests all subtypes of the attribute type in the attribute description, whether through attribute subtyping or attribute tagging option subtyping [RFC4512].
LDAP検索要求[RFC4511]は、検索フィルタに一致する各エントリから返される属性のリスト（要求された属性のリスト）を含みます。要求された属性リスト内の属性の記述は、暗黙的に属性サブタイプまたは属性を介しオプションのサブタイプ[RFC4512]をタグ付けするかどうか、属性記述の属性タイプのすべてのサブタイプを要求します。
The requested attributes list MAY contain attribute descriptions with the binary option, but MUST NOT contain two attribute descriptions with the same attribute type and the same tagging options (even if only one of them has the binary option). The binary option in an attribute description in the requested attributes list implicitly applies to all the subtypes of the attribute type in the attribute description (however, see Section 7).
要求された属性のリストは、バイナリオプションで属性の記述を含んでいてもよいが、（それらの一方のみがバイナリオプションを持っている場合でも）同じ属性タイプと同じタグ付けオプションを持つ2つの属性の説明を含めることはできません。要求された属性リスト内の属性の説明では、バイナリオプションは、暗黙のうちに、属性記述の属性タイプのすべてのサブタイプに適用されます（ただし、セクション7を参照してください）。
Attributes of a syntax with the binary transfer requirement, if returned, SHALL be returned in the binary form (i.e., with the binary option in the attribute description and the associated attribute values BER encoded) regardless of whether the binary option was present in the request (for the attribute or for one of its supertypes).
かかわらず、バイナリオプションは、リクエスト中に存在したかどうかのバイナリ転送要求と構文の属性は、返された場合、（属性の説明でバイナリオプションを使用して、IEと関連した属性は、BERは、符号化された値）をバイナリ形式で返されるものと（属性またはそのスーパータイプのいずれかの）。
Attributes of a syntax without the binary transfer requirement, if returned, SHOULD be returned in the form explicitly requested. That is, if the attribute description in the requested attributes list contains the binary option, then the corresponding attribute in the result SHOULD be in the binary form. If the attribute description in the request does not contain the binary option, then the corresponding attribute in the result SHOULD NOT be in the binary form. A server MAY omit an attribute from the result if it does not support the requested encoding.
バイナリ転送要求のない構文の属性は、返された場合、明示的に要求形式で返されるべきである（SHOULD）。これは、要求された属性リスト内の属性の記述がバイナリオプションが含まれている場合、結果の対応する属性がバイナリ形式でなければなりません、です。リクエストの属性記述がバイナリオプションが含まれていない場合、結果の対応する属性はバイナリ形式でするべきではありません。それは要求されたエンコーディングをサポートしていない場合、サーバーは、結果から属性を省略することができます。
Regardless of the encoding chosen, a particular attribute value is returned at most once.
かかわらず、選択したエンコーディングの、特定の属性値が最大で1回で返されます。
If the list of attributes in a search request is empty or contains the special attribute description string "*", then all user attributes are requested to be returned.
検索要求の属性のリストが空であるか、特別な属性の記述文字列「*」が含まれている場合は、すべてのユーザーの属性が返されるように要求されています。
Attributes of a syntax with the binary transfer requirement, if returned, SHALL be returned in the binary form.
バイナリ転送要求と構文の属性は、返された場合は、バイナリ形式で返却されます。
Attributes of a syntax without the binary transfer requirement and having a defined LDAP-specific encoding SHOULD NOT be returned in the binary form.
バイナリ転送要求と定義されたLDAP固有のエンコーディングを有することなく、構文の属性は、バイナリ形式で返されません。
Attributes of a syntax without the binary transfer requirement and without a defined LDAP-specific encoding may be returned in the binary form or omitted from the result.
バイナリ転送要求無しと定義LDAP固有の符号化せずに構文の属性は、バイナリ形式で返さまたは結果から省略されてもよいです。
A particular attribute could be explicitly requested by an attribute description and/or implicitly requested by the attribute descriptions of one or more of its supertypes, or by the special attribute description string "*". If the binary option is present in at least one, but not all, of these attribute descriptions then the effect of the request with respect to binary transfer is implementation defined.
特定の属性を明示的に、または「*」の特殊な属性記述文字列によって、そのスーパータイプのうちの1つまたは複数の属性の説明によって要求された属性の記述および/または暗黙によって要求される可能性があります。バイナリオプションは、少なくとも一つの中に存在する、すべてではないが、これらの属性の説明の場合、バイナリ転送に対する要求の効果は、実装定義です。
When interpreting security-sensitive fields, and 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.
セキュリティに敏感なフィールドを解釈する際に、アクセスを許可または拒否するために使用される特定のフィールドに、実装は、任意のマッチング規則の比較に関係なく使用される特定の符号化の基礎となる抽象値で行われていることを確認しなければなりません。
The Internet Assigned Numbers Authority (IANA) has updated the LDAP attribute description option registry [BCP64] as indicated by the following template:
IANA（Internet Assigned Numbers Authority）の次のテンプレートによって示されるように、[BCP64] LDAPの属性記述オプションのレジストリを更新しました：
Subject: Request for LDAP Attribute Description Option Registration Option Name: binary Family of Options: NO Person & email address to contact for further information: Steven Legg <steven.legg@eb2bcom.com> Specification: RFC 4522 Author/Change Controller: IESG
件名：LDAP属性説明オプション登録オプション名のための要求：オプションのバイナリ家族：NO人とEメールアドレスは、詳細についての問い合わせ先：スティーブン・レッグ<steven.legg@eb2bcom.com>仕様：RFC 4522著者/変更コントローラ：IESG
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP14]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[BCP64] Zeilenga、K.、 "IANA（Internet Assigned Numbers Authority）のライトウェイトディレクトリアクセスプロトコル（LDAP）に関する考慮事項"、BCP 64、RFC 4520、2006年6月。
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC RFC 4510, June 2006.
[RFC4510] Zeilenga、K.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：技術仕様ロードマップ"。、RFCのRFC 4510、2006年6月。
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim、J.、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：プロトコル"、RFC 4511、2006年6月。
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
[RFC4512] Zeilenga、K.、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：ディレクトリ情報モデル"、RFC 4512、2006年6月。
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
[RFC4517]レッグ、S.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：構文と一致規則"、RFC 4517、2006年6月。
[RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates", RFC 4523, June 2006.
[RFC4523] Zeilenga、K.、 "LDAP（Lightweight Directory Access Protocol）のX.509証明書のためのスキーマ定義"、RFC 4523、2006年6月。
[BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1, Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).
[BER] ITU-T勧告X.690（7月2日）| ISO / IEC 8825から1、情報技術 - ASN.1エンコーディング規則：基本符号化規則（BER）の仕様、Canonicalの符号化規則（CER）、および顕著な符号化規則（DER）。
[RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[RFC2251]ワール、M.、ハウズ、T.、およびS. Kille、 "軽量のディレクトリアクセスプロトコル（V3）"、RFC 2251、1997年12月。
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
[RFC3377]ホッジス、J.とR.モルガン、 "ライトウェイトディレクトリアクセスプロトコル（v3の）：技術仕様"、RFC 3377、2002年9月。
[X.500] ITU-T Recommendation X.500 (02/01) | ISO/IEC 9594-1:2001, Information technology - Open Systems Interconnection - The Directory: Overview of concepts, models and services
[X.500] ITU-T勧告X.500（02/01）| ISO / IEC 9594から1：2001、情報技術 - 開放型システム間相互接続 - ディレクトリ：概念、モデルとサービスの概要
Author's Address
著者のアドレス
Dr. Steven Legg eB2Bcom Suite 3, Woodhouse Corporate Centre 935 Station Street Box Hill North, Victoria 3129 AUSTRALIA
スティーブンレッグeB2Bcomスイート3、ウッドハウスコーポレートセンター935駅ストリートボックスヒルノース、ビクトリア3129オーストラリア
Phone: +61 3 9896 7830 Fax: +61 3 9896 7801 EMail: steven.legg@eb2bcom.com
電話：+61 3 9896 7830ファックス：+61 3 9896 7801 Eメール：steven.legg@eb2bcom.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。