Network Working Group S. Legg
Request for Comments: 4522 eB2Bcom
Category: Standards Track June 2006
Network Working Group S. Legg
Request for Comments: 4522 eB2Bcom
Category: Standards Track June 2006
Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option
轻量级目录访问协议（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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（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）目录中存储的每个属性都有一个定义的语法（即数据类型）。语法定义指定在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
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）目录[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]中使用该选项，以指定相关属性值或断言值根据X.500[X.500]目录使用的基本编码规则（BER）[BER]进行编码，或请求进行编码，而不是通常的LDAP特定编码。
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技术规范[RFC3377]，其中包括RFC 2251。由于各种原因（包括实现不一致），二进制选项未包含在修订的LDAP技术规范中。此处未尝试解决已知的不一致性。
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].
“本文件”中的“必须”和“不应”应解释为“BCP”，不得解释为“BCP”。
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.
二进制选项在属性描述中用属性选项字符串“binary”表示。请注意，与所有属性选项一样，表示二进制选项的字符串不区分大小写。
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.
如果属性描述中存在二进制选项，则必须对关联的属性值或断言值进行BER编码（否则，将根据属性语法的LDAP特定编码[RFC4517]对值进行编码）。请注意，可以定义语法，使其特定于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).
请求的属性列表可以包含具有二进制选项的属性描述，但不能包含具有相同属性类型和相同标记选项的两个属性描述（即使其中只有一个具有二进制选项）。请求属性列表中属性描述中的二进制选项隐式应用于属性描述中属性类型的所有子类型（但是，请参见第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).
具有二进制传输要求的语法的属性（如果返回）应以二进制形式返回（即，属性描述中的二进制选项和相关的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.
如果返回没有二进制传输要求的语法的属性，则应以显式请求的形式返回。也就是说，如果请求的属性列表中的属性描述包含binary选项，则结果中相应的属性应为二进制形式。如果请求中的属性描述不包含binary选项，则结果中相应的属性不应为二进制形式。如果服务器不支持请求的编码，则可能会从结果中忽略属性。
Regardless of the encoding chosen, a particular attribute value is returned at most once.
无论选择何种编码，特定属性值最多返回一次。
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.
一个或多个属性的描述可以由“*”的一个或多个属性的描述隐式请求。如果这些属性描述中至少有一个（而不是全部）存在二进制选项，则请求对二进制传输的影响由实现定义。
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:
Internet Assigned Numbers Authority（IANA）已更新LDAP属性描述选项注册表[BCP64]，如以下模板所示：
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
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
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP14]Bradner，S.，“RFC中用于表示需求水平的关键词”，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.，“轻量级目录访问协议（LDAP）的互联网分配号码管理局（IANA）注意事项”，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.，Ed.“轻量级目录访问协议（LDAP）：技术规范路线图”，RFC RFC 4510，2006年6月。
[RFC4511] Sermersheim, J., "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月。
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
[RFC4517]Legg，S.，Ed.，“轻量级目录访问协议（LDAP）：语法和匹配规则”，RFC4517，2006年6月。
[RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates", RFC 4523, June 2006.
[RFC4523]Zeilenga，K.，“X.509证书的轻型目录访问协议（LDAP）模式定义”，RFC4523，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（07/02）| ISO/IEC 8825-1，信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范。
[RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[RFC2251]Wahl，M.，Howes，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]Hodges，J.和R.Morgan，“轻量级目录访问协议（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 Recommendation X.500 (02/01) | ISO/IEC 9594-1:2001,
Information technology - Open Systems Interconnection -
The Directory: Overview of concepts, models and services
Author's Address
作者地址
Dr. Steven Legg eB2Bcom Suite 3, Woodhouse Corporate Centre 935 Station Street Box Hill North, Victoria 3129 AUSTRALIA
Steven Legg博士eB2Bcom澳大利亚维多利亚州博克斯山北站街935号伍德豪斯企业中心3号套房，邮编：3129
Phone: +61 3 9896 7830
Fax: +61 3 9896 7801
EMail: steven.legg@eb2bcom.com
Phone: +61 3 9896 7830
Fax: +61 3 9896 7801
EMail: 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。