Network Working Group K. Zeilenga, Ed.
Request for Comments: 4514 OpenLDAP Foundation
Obsoletes: 2253 June 2006
Category: Standards Track
Lightweight Directory Access Protocol (LDAP):
String Representation of Distinguished Names
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
抽象
The X.500 Directory uses distinguished names (DNs) as primary keys to entries in the directory. This document defines the string representation used in the Lightweight Directory Access Protocol (LDAP) to transfer distinguished names. The string representation is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name.
X.500ディレクトリは、ディレクトリ内のエントリに主キーとして識別名（DN）を使用しています。この文書では、識別名を転送するためのLDAP（Lightweight Directory Access Protocol）で使用される文字列表現を定義します。文字列表現は、任意の識別名を表現することができることながら、一般的に使用される識別名のきれいな表現を与えるように設計されています。
In X.500-based directory systems [X.500], including those accessed using the Lightweight Directory Access Protocol (LDAP) [RFC4510], distinguished names (DNs) are used to unambiguously refer to directory entries [X.501][RFC4512].
ライトウェイトディレクトリアクセスプロトコル（LDAP）[RFC4510]を使用してアクセスされるものを含むX.500ベースのディレクトリシステム[X.500]において、識別名（DN）は、明確にディレクトリエントリ[X.501] [RFC4512を参照するために使用されています]。
The structure of a DN [X.501] is described in terms of ASN.1 [X.680]. In the X.500 Directory Access Protocol [X.511] (and other ITU-defined directory protocols), DNs are encoded using the Basic Encoding Rules (BER) [X.690]. In LDAP, DNs are represented in the string form described in this document.
DNの構造は、[X.501]はASN.1 [X.680]の観点から説明されています。 X.500ディレクトリアクセスプロトコル[X.511]（および他のITU-定義されたディレクトリ・プロトコル）において、DNSは基本符号化規則（BER）[X.690]を使用して符号化されます。 LDAPでは、DNSは、この文書で説明した文字列形式で表されます。
It is important to have a common format to be able to unambiguously represent a distinguished name. The primary goal of this specification is ease of encoding and decoding. A secondary goal is to have names that are human readable. It is not expected that LDAP implementations with a human user interface would display these strings directly to the user, but that they would most likely be performing translations (such as expressing attribute type names in the local national language).
明確に識別名を表現することができるようにする共通のフォーマットを有することが重要です。本明細書の主要な目標は、符号化および復号化の容易さです。二次の目標は、人間が読めるな名前を持つことです。人間のユーザー・インタフェースを持つLDAPの実装はユーザーに直接これらの文字列を表示することが期待されていないが、彼らは最も可能性が高い（ローカル国語で属性タイプの名前を表現するなど）の翻訳を実行するだろうと。
This document defines the string representation of Distinguished Names used in LDAP [RFC4511][RFC4517]. Section 2 details the RECOMMENDED algorithm for converting a DN from its ASN.1 structured representation to a string. Section 3 details how to convert a DN from a string to an ASN.1 structured representation.
この文書では、LDAP [RFC4511] [RFC4517]で使用される識別名の文字列表現を定義します。第2節では、文字列へのASN.1構造表現からDNを変換するための推奨アルゴリズムを詳述します。第3節では、ASN.1構造の表現に文字列からDNを変換する方法について説明します。
While other documents may define other algorithms for converting a DN from its ASN.1 structured representation to a string, all algorithms MUST produce strings that adhere to the requirements of Section 3.
他の文書は、文字列へのASN.1構造表現からDNを変換するための他のアルゴリズムを定義することができるが、すべてのアルゴリズムは、第3の要件に準拠した文字列を生成しなければなりません。
This document does not define a canonical string representation for DNs. Comparison of DNs for equality is to be performed in accordance with the distinguishedNameMatch matching rule [RFC4517].
この文書では、DNSのための標準的な文字列表現を定義していません。平等のDNSの比較はdistinguishedNameMatchマッチング規則[RFC4517]に従って実行されます。
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. This document obsoletes RFC 2253. Changes since RFC 2253 are summarized in Appendix B.
この文書は、その全体が、先に定義されたLDAP技術仕様、RFC 3377を時代遅れLDAP技術仕様書[RFC4510]の不可欠な部分です。 RFC 2253は、付録Bに要約されているので、この文書は、RFC 2253の変更を廃止します
This specification assumes familiarity with X.500 [X.500] and the concept of Distinguished Name [X.501][RFC4512].
この仕様はX.500 [X.500]および識別名の概念[X.501] [RFC4512]に精通している前提としています。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14 [RFC2119]に記載されているように解釈されます。
Character names in this document use the notation for code points and names from the Unicode Standard [Unicode]. For example, the letter "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
この文書における文字の名前は、Unicode標準[UNICODE]のコードポイントと名の表記を使用します。例えば、文字 "は" <LATIN SMALL LETTER A> <U + 0061>のいずれかとして表されてもよいです。
Note: a glossary of terms used in Unicode can be found in [Glossary]. Information on the Unicode character encoding model can be found in [CharModel].
注：Unicodeで使用される用語の用語集は、[用語]に見出すことができます。 Unicode文字エンコーディングモデルに関する情報は、[CharModel]で見つけることができます。
X.501 [X.501] defines the ASN.1 [X.680] structure of distinguished name. The following is a variant provided for discussion purposes.
X.501は、[X.501]識別名のASN.1 [X.680]の構造を定義します。以下は、説明の目的のために提供変種です。
DistinguishedName ::= RDNSequence
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType,
value AttributeValue }
This section defines the RECOMMENDED algorithm for converting a distinguished name from an ASN.1-structured representation to a UTF-8 [RFC3629] encoded Unicode [Unicode] character string representation. Other documents may describe other algorithms for converting a distinguished name to a string, but only strings that conform to the grammar defined in Section 3 SHALL be produced by LDAP implementations.
このセクションでは、UTF-8 [RFC3629]にASN.1構造表現から識別名を変換するための推奨アルゴリズムは、ユニコード[UNICODE]の文字列表現を符号化された定義します。他の文書は、文字列に識別名を変換するための他のアルゴリズムを記述してもよいが、セクション3で定義された文法に従うだけの文字列は、LDAP実装で製造されなければなりません。
If the RDNSequence is an empty sequence, the result is the empty or zero-length string.
RDNSequenceが空シーケンスの場合、結果は空またはゼロ長の文字列です。
Otherwise, the output consists of the string encodings of each RelativeDistinguishedName in the RDNSequence (according to Section 2.2), starting with the last element of the sequence and moving backwards toward the first.
そうでなければ、出力は、シーケンスの最後の要素で開始し、最初に向かって後方に移動し、（セクション2.2に従って）RDNSequence各RelativeDistinguishedNameの文字列エンコーディングから成ります。
The encodings of adjoining RelativeDistinguishedNames are separated by a comma (',' U+002C) character.
隣接する相対識別名の符号化は、カンマ（「」U + 002C）文字で区切られます。
When converting from an ASN.1 RelativeDistinguishedName to a string, the output consists of the string encodings of each AttributeTypeAndValue (according to Section 2.3), in any order.
文字列にASN.1のRelativeDistinguishedNameから変換するとき、出力は、任意の順序で、（セクション2.3に従って）各AttributeTypeAndValueの文字列エンコーディングから成ります。
Where there is a multi-valued RDN, the outputs from adjoining AttributeTypeAndValues are separated by a plus sign ('+' U+002B) character.
複数値のRDNがある場合、隣接しているAttributeTypeAndValuesからの出力は、プラス記号（「+」U + 002B）文字で区切られます。
The AttributeTypeAndValue is encoded as the string representation of the AttributeType, followed by an equals sign ('=' U+003D) character, followed by the string representation of the AttributeValue. The encoding of the AttributeValue is given in Section 2.4.
AttributeTypeAndValueはAttributeValueの文字列表現に続いて、（「=」U + 003D）文字等号、続いAttributeTypeでの文字列表現として符号化されます。 AttributeValueのの符号化は、セクション2.4で与えられています。
If the AttributeType is defined to have a short name (descriptor) [RFC4512] and that short name is known to be registered [REGISTRY] [RFC4520] as identifying the AttributeType, that short name, a <descr>, is used. Otherwise the AttributeType is encoded as the dotted-decimal encoding, a <numericoid>, of its OBJECT IDENTIFIER. The <descr> and <numericoid> are defined in [RFC4512].
AttributeTypeで、その短い名前を特定するようREGISTRY] [RFC4520]をAttributeTypeでは[RFC4512]のショートネーム（記述子）を有するように定義され、その短い名前が登録されることが知られている場合、<DESCR>、使用されています。さもなければAttributeTypeでは、物体識別子、<numericoid>、ドット付き十進符号化として符号化されます。 <DESCR>と<numericoid>は、[RFC4512]で定義されています。
Implementations are not expected to dynamically update their knowledge of registered short names. However, implementations SHOULD provide a mechanism to allow their knowledge of registered short names to be updated.
実装は動的に登録短い名前の知識を更新することが期待されていません。しかし、実装は登録短い名前の知識を更新することができるようにするメカニズムを提供する必要があります。
If the AttributeType is of the dotted-decimal form, the AttributeValue is represented by an number sign ('#' U+0023) character followed by the hexadecimal encoding of each of the octets of the BER encoding of the X.500 AttributeValue. This form is also used when the syntax of the AttributeValue does not have an LDAP-specific ([RFC4517], Section 3.1) string encoding defined for it, or the LDAP-specific string encoding is not restricted to UTF-8-encoded Unicode characters. This form may also be used in other cases, such as when a reversible string representation is desired (see Section 5.2).
AttributeTypeでは、ドット区切り形式である場合、AttributeValueのはX.500 AttributeValueのBERのエンコーディングのオクテットのそれぞれの進符号化が続く番号記号（「＃」U + 0023）の文字で表されます。 AttributeValueの構文は、LDAP固有（[RFC4517]、セクション3.1）、それに対して定義された文字列エンコーディング、またはLDAP固有の文字列のエンコーディングを持っていない場合、この形態はまた、UTF-8でエンコードされたUnicode文字に限定されず、使用されています。このフォームはまた、可逆的な文字列表現が望まれる場合のような他の場合、（セクション5.2を参照）で使用することができます。
Otherwise, if the AttributeValue is of a syntax that has a LDAP-specific string encoding, the value is converted first to a UTF-8- encoded Unicode string according to its syntax specification (see [RFC4517], Section 3.3, for examples). If that UTF-8-encoded Unicode string does not have any of the following characters that need escaping, then that string can be used as the string representation of the value.
AttributeValueのは、LDAP固有の文字列のエンコーディングを有する構文であればそれ以外の場合、値はその構文仕様に従って、UTF-8エンコードされたUnicode文字列に最初に変換される（例については、セクション3.3、[RFC4517]参照）。そのUTF-8でエンコードされたUnicode文字列をエスケープする必要がある、次のいずれかの文字を持っていない場合は、その文字列は、値の文字列表現として使用することができます。
- a space (' ' U+0020) or number sign ('#' U+0023) occurring at the beginning of the string;
- スペース（「『U + 0020）またはナンバー記号文字列の先頭に発生する（』＃」U + 0023）。
- a space (' ' U+0020) character occurring at the end of the string;
- スペース（」 'U + 0020）文字は、文字列の終わりに生じます。
- one of the characters '"', '+', ',', ';', '<', '>', or '\' (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C, respectively);
- 文字 '"'、 '+'、 '、'、のいずれか ';'、 '<'、 '>'、または '\'（U + 0022、U + 002B、U + 002C、U + 003B、 U + 003C、U + 003E、又はU + 005C、それぞれ）。
- the null (U+0000) character.
- ヌル（U + 0000）の文字。
Other characters may be escaped.
他の文字をエスケープすることができます。
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. Alternatively, if and only if the character to be escaped is one of
エスケープする文字の各オクテットは、バックスラッシュ文字のコードで単一オクテットを形成する2つの六角桁によって置き換えられます。また、文字をエスケープする場合にだけはの一つであります
' ', '"', '#', '+', ',', ';', '<', '=', '>', or '\' (U+0020, U+0022, U+0023, U+002B, U+002C, U+003B, U+003C, U+003D, U+003E, U+005C, respectively)
''、 '"'、 '＃'、 '+'、 '、'、 ';'、 '<'、 '='、 '>'、または '\'（U + 0020、U + 0022、U + 0023、U + 002B、U + 002C、U + 003B、それぞれU + 003C、U + 003D、003E U +、U + 005C）
it can be prefixed by a backslash ('\' U+005C).
それは、バックスラッシュ（「\」U + 005C）を前置することができます。
Examples of the escaping mechanism are shown in Section 4.
エスケープ機構の例は、セクション4に示されています。
The string representation of Distinguished Names is restricted to UTF-8 [RFC3629] encoded Unicode [Unicode] characters. The structure of this string representation is specified using the following Augmented BNF [RFC4234] grammar:
識別名の文字列表現は、UTF-8 [RFC3629]に制限されているユニコード[UNICODE]の文字をエンコードされました。この文字列表現の構造は、以下の増補BNF [RFC4234]文法を使用して指定されます。
distinguishedName = [ relativeDistinguishedName *( COMMA relativeDistinguishedName ) ] relativeDistinguishedName = attributeTypeAndValue *( PLUS attributeTypeAndValue ) attributeTypeAndValue = attributeType EQUALS attributeValue attributeType = descr / numericoid attributeValue = string / hexstring
distinguishedNameの= [relativeDistinguishedName *（COMMA relativeDistinguishedName）] relativeDistinguishedName = attributeTypeAndValue *（PLUS attributeTypeAndValue）attributeTypeAndValue =とattributeType属性値とattributeType = DESCR / numericoid属性値=文字列/ hexstringに等しいです
; The following characters are to be escaped when they appear ; in the value to be encoded: ESC, one of <escaped>, leading ; SHARP or SPACE, trailing SPACE, and NULL. string = [ ( leadchar / pair ) [ *( stringchar / pair ) ( trailchar / pair ) ] ]
;彼らが表示される場合は、次の文字がエスケープされるべきです。値には、符号化される：ESC、<エスケープ>のいずれかを、主要。シャープまたはSPACE、末尾のSPACE、およびNULL。ストリング= [（leadchar /ペア）*（stringchar /ペア）（trailchar /ペア）]
leadchar = LUTF1 / UTFMB LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A / %x3D / %x3F-5B / %x5D-7F
leadhar = LUTF1 / UTFMB LUTF1 h01-1F =％/％ks21 / ks24-2A％/％x2d OVER / S3D％/％kszF-5B /％H5D-7F
trailchar = TUTF1 / UTFMB TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A /
trailchar = TUTF1 / UTFMB TUTF1 h01-1F =％/％ks21 / h23-2A％/％x2d OVER /
%x3D / %x3F-5B / %x5D-7F
サードとして％/％Ksafajb /％Kskhaddhv
stringchar = SUTF1 / UTFMB SUTF1 = %x01-21 / %x23-2A / %x2D-3A / %x3D / %x3F-5B / %x5D-7F
stringchar = SUTF1 / UTFMB SUTF1 =％x01-21 /％x23-2A /％x2D-3A /％X3D /％からx3F-5B /％x5D-7F
pair = ESC ( ESC / special / hexpair ) special = escaped / SPACE / SHARP / EQUALS escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE hexstring = SHARP 1*hexpair hexpair = HEX HEX
一対= ESC（ESC /特殊/ hexpair）特殊=エスケープ/スペース/シャープ/に等しいが= DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE hexstring = SHARP 1 * hexpair hexpair = HEX HEXエスケープ
where the productions <descr>, <numericoid>, <COMMA>, <DQUOTE>, <EQUALS>, <ESC>, <HEX>, <LANGLE>, <NULL>, <PLUS>, <RANGLE>, <SEMI>, <SPACE>, <SHARP>, and <UTFMB> are defined in [RFC4512].
ここで制作<DESCR>、<numericoid>、<COMMA>、<DQUOTE>、<EQUALS>、<ESC>、<HEX>、<LANGLE>、<NULL>、<PLUS>、<RANGLE>、<SEMI> 、<SPACE>、<SHARP>、および<UTFMB> [RFC4512]で定義されています。
Each <attributeType>, either a <descr> or a <numericoid>, refers to an attribute type of an attribute value assertion (AVA). The <attributeType> is followed by an <EQUALS> and an <attributeValue>. The <attributeValue> is either in <string> or <hexstring> form.
各<とattributeType>いずれか<DESCR>または<numericoid>、属性値表明（AVA）の属性タイプを指します。 <とattributeType>は、<EQUALS>と<属性値>が続きます。 <属性値>は<文字列>または<hexstring>形式のいずれかです。
If in <string> form, a LDAP string representation asserted value can be obtained by replacing (left to right, non-recursively) each <pair> appearing in the <string> as follows:
<ストリング>の形式で、LDAP文字列表現は、値をアサートした場合に現れる<ペア>各（非再帰的に右、左）置き換えることによって得ることができる次の<string>として。
replace <ESC><ESC> with <ESC>;
replace <ESC><special> with <special>;
replace <ESC><hexpair> with the octet indicated by the <hexpair>.
If in <hexstring> form, a BER representation can be obtained from converting each <hexpair> of the <hexstring> to the octet indicated by the <hexpair>.
<hexstring>形式であれば、BER表現は<hexpair>によって示されるオクテットに<hexpair> <hexstring>の各変換から得ることができます。
There is one or more attribute value assertions, separated by <PLUS>, for a relative distinguished name.
<PLUS>、の相対識別名で区切られた1つ以上の属性値表明は、あります。
There is zero or more relative distinguished names, separated by <COMMA>, for a distinguished name.
識別名のために、<COMMA>で区切られたゼロ個以上の相対識別名は、あります。
Implementations MUST recognize AttributeType name strings (descriptors) listed in the following table, but MAY recognize other name strings.
実装は、次の表に記載されているAttributeTypeで名前文字列（記述子）を認識しなければならないが、他の名前の文字列を認識することができます。
String X.500 AttributeType
------ --------------------------------------------
CN commonName (2.5.4.3)
L localityName (2.5.4.7)
ST stateOrProvinceName (2.5.4.8)
O organizationName (2.5.4.10)
OU organizationalUnitName (2.5.4.11)
C countryName (2.5.4.6)
STREET streetAddress (2.5.4.9)
DC domainComponent (0.9.2342.19200300.100.1.25)
UID userId (0.9.2342.19200300.100.1.1)
These attribute types are described in [RFC4519].
これらの属性タイプは、[RFC4519]で説明されています。
Implementations MAY recognize other DN string representations. However, as there is no requirement that alternative DN string representations be recognized (and, if so, how), implementations SHOULD only generate DN strings in accordance with Section 2 of this document.
実装は、他のDN文字列表現を認識することができます。代替DN文字列表現が（そうであれば、どのように、など）を認識することが全く必要がないのでしかし、実装は、このドキュメントのセクション2に従ってDN文字列を生成する必要があります。
This notation is designed to be convenient for common forms of name. This section gives a few examples of distinguished names written using this notation. First is a name containing three relative distinguished names (RDNs):
この表記法は、名前を一般的な形式で利用できるように設計されています。このセクションでは、この表記を使用して書かれた識別名のいくつかの例を示します。最初の3相対識別名（RDNの）を含む名前は、次のとおりです。
UID=jsmith,DC=example,DC=net
UID = JSMITH、DC =例、DC =ネット
Here is an example of a name containing three RDNs, in which the first RDN is multi-valued:
ここで最初のRDNが多値された3つのRDNを含む名前の一例です。
OU=Sales+CN=J. Smith,DC=example,DC=net
OU =売上高+ CN = J。スミス、DC =例、DC =ネット
This example shows the method of escaping of a special characters appearing in a common name:
この例では、共通の名前で登場する特殊文字をエスケープする方法を示しています。
CN=James \"Jim\" Smith\, III,DC=example,DC=net
CN =ジェームズ\ "ジム\" スミス\、III、DC =例、DC =ネット
The following shows the method for encoding a value that contains a carriage return character:
以下は、復帰文字を含む値を符号化する方法を示しています。
CN=Before\0dAfter,DC=example,DC=net
CNは\ 0dAfter、DC =例、DC =ネットの前に=
In this RDN example, the type in the RDN is unrecognized, and the value is the BER encoding of an OCTET STRING containing two octets, 0x48 and 0x69.
このRDNの例では、RDNに型が認識され、その値は、二つのオクテットが0x48と0x69の含有オクテットストリングのBER符号化です。
Finally, this example shows an RDN whose commonName value consists of 5 letters:
最後に、この例では、そのcommonNameの値が5つの文字で構成されてRDNを示しています。
Unicode Character Code UTF-8 Escaped
------------------------------- ------ ------ --------
LATIN CAPITAL LETTER L U+004C 0x4C L
LATIN SMALL LETTER U U+0075 0x75 u
LATIN SMALL LETTER C WITH CARON U+010D 0xC48D \C4\8D
LATIN SMALL LETTER I U+0069 0x69 i
LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487 \C4\87
This could be encoded in printable ASCII [ASCII] (useful for debugging purposes) as:
これは、[ASCII]（デバッグ目的に有用）、印刷可能なASCIIで符号化することができます。
CN=Lu\C4\8Di\C4\87
CN =呂\ C4 \ 8DI \ C4 \ 87
The following security considerations are specific to the handling of distinguished names. LDAP security considerations are discussed in [RFC4511] and other documents comprising the LDAP Technical Specification [RFC4510].
次のセキュリティの考慮事項は、識別名の取り扱いに固有のものです。 LDAPセキュリティの考慮事項は、[RFC4511]とLDAP技術仕様[RFC4510]を構成する他の文書で説明されています。
Distinguished Names typically consist of descriptive information about the entries they name, which can be people, organizations, devices, or other real-world objects. This frequently includes some of the following kinds of information:
識別名は、一般的に人、組織、デバイス、または他の実世界のオブジェクトすることができ、彼らは名前を付けるエントリについての記述的な情報から構成されています。これは、しばしば次のような情報の一部が含まれています。
- the common name of the object (i.e., a person's full name) - an email or TCP/IP address - its physical location (country, locality, city, street address) - organizational attributes (such as department name or affiliation)
- オブジェクトの共通名（すなわち、人のフルネーム） - 電子メールまたはTCP / IPアドレス - その物理的な場所（国、地域、都市、住所） - （例えば部署名や所属など）組織の属性
In some cases, such information can be considered sensitive. In many countries, privacy laws exist that prohibit disclosure of certain kinds of descriptive information (e.g., email addresses). Hence, server implementers are encouraged to support Directory Information Tree (DIT) structural rules and name forms [RFC4512], as these provide a mechanism for administrators to select appropriate naming attributes for entries. Administrators are encouraged to use mechanisms, access controls, and other administrative controls that may be available to restrict use of attributes containing sensitive information in naming of entries. Additionally, use of authentication and data security services in LDAP [RFC4513][RFC4511] should be considered.
いくつかのケースでは、そのような情報は、機密とみなすことができます。多くの国では、個人情報保護法は、それが記述情報（例えば、電子メールアドレス）の特定の種類の開示を禁止して存在します。これらのエントリのための適切な命名属性を選択するには、管理者のためのメカニズムを提供するようしたがって、サーバーの実装は、ディレクトリ情報ツリー（DIT）構造規則や名前形式[RFC4512]をサポートすることをお勧めします。管理者は、エントリの命名に機密情報を含む属性の使用を制限するために利用できるかもしれメカニズム、アクセス制御、およびその他の管理コントロールを使用することをお勧めします。また、LDAPでの認証とデータのセキュリティ・サービスの使用[RFC4513] [RFC4511]は考慮されるべきです。
The transformations of an AttributeValue value from its X.501 form to an LDAP string representation are not always reversible back to the same BER (Basic Encoding Rules) or DER (Distinguished Encoding Rules) form. An example of a situation that requires the DER form of a distinguished name is the verification of an X.509 certificate.
LDAP文字列表現へのX.501フォームからAttributeValueの値の変換はバック同じBER（基本符号化規則）またはDER（識別符号化規則）を形成するために、常に可逆ではありません。識別名のDER形式を必要とする状況の例は、X.509証明書の検証です。
For example, a distinguished name consisting of one RDN with one AVA, in which the type is commonName and the value is of the TeletexString choice with the letters 'Sam', would be represented in LDAP as the string <CN=Sam>. Another distinguished name in which the value is still 'Sam', but is of the PrintableString choice, would have the same representation <CN=Sam>.
例えば、型がcommonNameのであり、値が文字「サム」とTeletexStringの一つのAVA、と、ワンRDNで構成される識別名は、文字列<CN =サム>としてLDAPで表現されることになります。値がまだ「サム」ですが、PrintableStringの選択のであるもう一つの識別名は、同じ表現<CN =サム>を持っているでしょう。
Applications that require the reconstruction of the DER form of the value SHOULD NOT use the string representation of attribute syntaxes when converting a distinguished name to the LDAP format. Instead, they SHOULD use the hexadecimal form prefixed by the number sign ('#' U+0023) as described in the first paragraph of Section 2.4.
LDAP形式に識別名を変換するときに値のDER形式の再構成を必要とするアプリケーションには、属性構文の文字列表現を使用しないでください。その代わりに、彼らは、セクション2.4の最初の段落に記載されているように番号記号（「＃」U + 0023）で始まる16進形式を使用すべきです。
This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and Steve Kille. RFC 2253 was a product of the IETF ASID Working Group.
この文書では、マーク・ワール、ティムハウズ、およびスティーブKilleによって、RFC 2253のアップデートです。 RFC 2253は、IETF ASID作業部会の製品でした。
This document is a product of the IETF LDAPBIS Working Group.
この文書は、IETF LDAPBISワーキンググループの製品です。
[REGISTRY] IANA, Object Identifier Descriptors Registry, <http://www.iana.org/assignments/ldap-parameters>.
[REGISTRY] IANA、識別子ディスクリプタレジストリオブジェクト、<http://www.iana.org/assignments/ldap-parameters>。
[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" (http://www.unicode.org/reports/tr28/).
[UNICODE]ユニコードコンソーシアムは、 "Unicode標準、バージョン3.2.0" は、 "Unicode規格、バージョン3.0"（読書、MA、アディソン・ウェズリー、61633から5 2000. ISBN 0-201-）などによって定義されます改正 "Unicode標準の附属書＃27：ユニコード3.1"（http://www.unicode.org/reports/tr27/）とで "Unicode標準の附属書＃28：Unicodeの3.2"（のhttp：//www.unicode .ORG /レポート/ TR28 /）。
[X.501] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory -- Models," X.501(1993) (also ISO/IEC 9594- 2:1994).
[X.501]国際電気通信連合 - 電気通信標準化部門、 "ディレクトリ - モデル、" X.501（1993）（2もISO / IEC 9594-：1994）。
[X.680] International Telecommunication Union - Telecommunication Standardization Sector, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
[X.680]国際電気通信連合 - 電気通信標準化部門、 "抽象構文記法1（ASN.1） - 基本的な記法の仕様"、X.680（1997）（また、ISO / IEC 8824から1：1998）。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[RFC4510] Zeilenga、K.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：技術仕様ロードマップ"。、RFC 4510、2006年6月。
[RFC4511] Sermersheim, J., Ed., "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月。
[RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
[RFC4513]ハリソン、R.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：認証方法とセキュリティメカニズム"。、RFC 4513、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月。
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006.
[RFC4519] Sciberras、A.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：ユーザー・アプリケーションのためのスキーマ"。、RFC 4519、2006年6月。
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[RFC4520] Zeilenga、K.、 "IANA（Internet Assigned Numbers Authority）のライトウェイトディレクトリアクセスプロトコル（LDAP）に関する考慮事項"、BCP 64、RFC 4520、2006年6月。
[ASCII] Coded Character Set--7-bit American Standard Code for Information Interchange, ANSI X3.4-1986.
情報交換、ANSI X3.4-1986のために7ビットの米国標準コード - [ASCII]文字セットをコード化されました。
[CharModel] Whistler, K. and M. Davis, "Unicode Technical Report #17, Character Encoding Model", UTR17, <http://www.unicode.org/unicode/reports/tr17/>, August 2000.
[CharModel]ウィスラー、K.とM.デイヴィス、 "Unicodeの技術レポート＃17、文字エンコーディングモデル"、UTR17、<http://www.unicode.org/unicode/reports/tr17/>、2000年8月。
[Glossary] The Unicode Consortium, "Unicode Glossary", <http://www.unicode.org/glossary/>.
[用語]ユニコードコンソーシアム、 "ユニコード用語"、<http://www.unicode.org/glossary/>。
[X.500] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory -- Overview of concepts, models and services," X.500(1993) (also ISO/IEC 9594-1:1994).
[X.500]国際電気通信連合 - 電気通信標準化部門、 "ディレクトリ - 概念、モデルとサービスの概要、" X.500（1993）（また、ISO / IEC 9594から1：1994）。
[X.511] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory: Abstract Service Definition", X.511(1993) (also ISO/IEC 9594-3:1993).
[X.511]国際電気通信連合 - 電気通信標準化部門、 "ディレクトリ：抽象サービス定義"、X.511（1993）（また、ISO / IEC 9594から3：1993）。
[X.690] International Telecommunication Union - Telecommunication Standardization Sector, "Specification of ASN.1 encoding rules: Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER)", X.690(1997) (also ISO/IEC 8825-1:1998).
[X.690]国際電気通信連合 - 電気通信標準化部門、 "ASN.1エンコーディング規則の仕様：基本符号化規則（BER）、Canonicalの符号化規則（CER）、および顕著な符号化規則（DER）"、X.690（1997 ）（また、ISO / IEC 8825から1：1998）。
[RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", RFC 2849, June 2000.
[RFC2849]グッド、G.、 "LDAPデータ交換フォーマット（LDIF） - 技術仕様"、RFC 2849、2000年6月。
Appendix A. Presentation Issues
付録A.プレゼンテーションの問題
This appendix is provided for informational purposes only; it is not a normative part of this specification.
この付録は、情報提供のみを目的として提供されます。それは、この仕様の標準的な部分ではありません。
The string representation described in this document is not intended to be presented to humans without translation. However, at times it may be desirable to present non-translated DN strings to users. This section discusses presentation issues associated with non-translated DN strings. Issues with presentation of translated DN strings are not discussed in this appendix. Transcoding issues are also not discussed in this appendix.
この文書で説明した文字列表現を翻訳なしで人間に提示されるものではありません。しかし、時にはユーザーに非翻訳DN文字列を提示することが望ましい場合があります。このセクションでは、非翻訳DN文字列に関連付けられているプレゼンテーションの問題について説明します。翻訳されたDN文字列のプレゼンテーションの問題は、この付録で説明されていません。トランスコーディングの問題も、この章で説明されていません。
This appendix provides guidance for applications presenting DN strings to users. This section is not comprehensive; it does not discuss all presentation issues that implementers may face.
この付録では、ユーザーにDN文字列を提示するアプリケーションのためのガイダンスを提供します。このセクションでは、包括的ではありません。それは、実装者が直面する可能性のあるすべてのプレゼンテーションの問題について議論しません。
Not all user interfaces are capable of displaying the full set of Unicode characters. Some Unicode characters are not displayable.
いないすべてのユーザーインタフェースは、Unicode文字のフルセットを表示することが可能です。いくつかのUnicode文字は表示されません。
It is recommended that human interfaces use the optional hex pair escaping mechanism (Section 2.3) to produce a string representation suitable for display to the user. For example, an application can generate a DN string for display that escapes all non-printable characters appearing in the AttributeValue's string representation (as demonstrated in the final example of Section 4).
人間のインタフェースはユーザへの表示に適した文字列表現を生成するために、オプションの六角対機構をエスケープ（セクション2.3）を使用することが推奨されます。例えば、アプリケーションは、（第4章の最後の例で示されるように）AttributeValueのの文字列表現に現れるすべての非印刷可能文字をエスケープ表示するためのDN文字列を生成することができます。
When a DN string is displayed in free-form text, it is often necessary to distinguish the DN string from surrounding text. While this is often done with whitespace (as demonstrated in Section 4), it is noted that DN strings may end with whitespace. Careful readers of Section 3 will note that the characters '<' (U+003C) and '>' (U+003E) may only appear in the DN string if escaped. These characters are intended to be used in free-form text to distinguish a DN string from surrounding text. For example, <CN=Sam\ > distinguishes the string representation of the DN composed of one RDN consisting of the AVA (the commonName (CN) value 'Sam ') from the surrounding text. It should be noted to the user that the wrapping '<' and '>' characters are not part of the DN string.
DN文字列は自由形式のテキストで表示されている場合は、テキストを囲むからDN文字列を区別する必要があることが多いです。これは、多くの場合（セクション4に示されているように）空白で行われるが、DNストリングが空白で終わってもよいことに留意されたいです。第3節の注意深い読者は、エスケープ場合、文字「<」（U + 003C）と「>」（U + 003E）は唯一のDN文字列に表示される可能性があることに注意します。これらの文字は、テキストの周囲からのDN文字列を区別するために、自由形式のテキストで使用されることを意図しています。例えば、<CN =サム\>周囲のテキストからAVA（commonNameの（CN）値「サム」）からなる1 RDNからなるDNの文字列表現を区別する。ラッピング「<」と「>」文字がDN文字列の一部ではないことをユーザに注意すべきです。
DN strings can be quite long. It is often desirable to line-wrap overly long DN strings in presentations. Line wrapping should be done by inserting whitespace after the RDN separator character or, if necessary, after the AVA separator character. It should be noted to the user that the inserted whitespace is not part of the DN string and is to be removed before use in LDAP. For example, the following DN string is long:
DN文字列はかなり長くなることができます。これは、プレゼンテーションで過度に長いDN文字列をラインラップすることが望ましい場合が多いです。行の折り返しは、AVAの区切り文字の後に、必要に応じて、RDN区切り文字の後に空白を挿入したりすることによって行われるべきです。これは、挿入された空白がDN文字列の一部ではなく、LDAPで使用する前に削除するユーザーに注意すべきです。たとえば、次のDN文字列は長いです。
CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
O=OpenLDAP Foundation,ST=California,C=US
So it has been line-wrapped for readability. The extra whitespace is to be removed before the DN string is used in LDAP.
だから、ライン・ラップ読みやすくするためになっています。 DN文字列をLDAPで使用される前に、余分な空白を削除します。
Inserting whitespace is not advised because it may not be obvious to the user which whitespace is part of the DN string and which whitespace was added for readability.
それは空白がDN文字列の一部であり、その空白文字が読みやすくするために追加されたユーザーには自明ではないかもしれないので、挿入する空白はお勧めできません。
Another alternative is to use the LDAP Data Interchange Format (LDIF) [RFC2849]. For example:
別の方法としては、LDAPデータ交換フォーマット（LDIF）[RFC2849]を使用することです。例えば：
# This entry has a long DN...
dn: CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
O=OpenLDAP Foundation,ST=California,C=US
CN: Kurt D. Zeilenga
SN: Zeilenga
objectClass: person
Appendix B. Changes Made since
付録B.変更は以降に行われました
This appendix is provided for informational purposes only, it is not a normative part of this specification.
この付録は、それがこの仕様の標準的な部分ではなく、情報提供のみを目的に提供されています。
The following substantive changes were made to RFC 2253:
以下の実質的な変更は、RFC 2253に行われました。
- Removed IESG Note. The IESG Note has been addressed. - Replaced all references to ISO 10646-1 with [Unicode]. - Clarified (in Section 1) that this document does not define a canonical string representation. - Clarified that Section 2 describes the RECOMMENDED encoding algorithm and that alternative algorithms are allowed. Some encoding options described in RFC 2253 are now treated as alternative algorithms in this specification. - Revised specification (in Section 2) to allow short names of any registered attribute type to appear in string representations of DNs instead of being restricted to a "published table". Removed "as an example" language. Added statement (in Section 3) allowing recognition of additional names but require recognition of those names in the published table. The table now appears in Section 3. - Removed specification of additional requirements for LDAPv2 implementations which also support LDAPv3 (RFC 2253, Section 4) as LDAPv2 is now Historic. - Allowed recognition of alternative string representations. - Updated Section 2.4 to allow hex pair escaping of all characters and clarified escaping for when multiple octet UTF-8 encodings are present. Indicated that null (U+0000) character is to be escaped. Indicated that equals sign ('=' U+003D) character may be escaped as '\='. - Rewrote Section 3 to use ABNF as defined in RFC 4234. - Updated the Section 3 ABNF. Changes include: + allowed AttributeType short names of length 1 (e.g., 'L'), + used more restrictive <oid> production in AttributeTypes, + did not require escaping of equals sign ('=' U+003D) characters, + did not require escaping of non-leading number sign ('#' U+0023) characters, + allowed space (' ' U+0020) to be escaped as '\ ', + required hex escaping of null (U+0000) characters, and + removed LDAPv2-only constructs. - Updated Section 3 to describe how to parse elements of the grammar. - Rewrote examples. - Added reference to documentations containing general LDAP security considerations. - Added discussion of presentation issues (Appendix A). - Added this appendix.
- IESG注意を削除しました。 IESG注意が対処されてきました。 - [ユニコード]でISO 10646-1へのすべての参照を置き換え。 - この文書は標準的な文字列表現を定義していないこと（セクション1）明らかにしました。 - 第2推奨符号化アルゴリズムを記述し、その代替アルゴリズムが許可されていることを明らかにしました。 RFC 2253に記載されるいくつかのエンコードオプションは、現在、本明細書において代替アルゴリズムとして扱われます。 - 登録されているすべての属性タイプの短い名前ではなく、「パブリッシュされたテーブル」に限定されるのDNの文字列表現に現れることを可能にする（第2節で）改訂仕様。言語「一例として、」削除しました。追加の名前の認識を可能にすること（セクション3）の文を追加しましたが、パブリッシュされたテーブルにそれらの名前を認識する必要があります。テーブルは、現在のセクション3に表示される - のLDAPv2は今歴史的であるとしてものLDAPv3をサポートするのLDAPv2実装の追加要件を除去仕様（RFC 2253、セクション4）。 - 代替文字列表現の認識可。 - 六角ペアは、すべての文字のエスケープを許可するセクション2.4を更新し、複数のオクテットUTF-8エンコーディングが存在するときのためにエスケープ明らかにしました。ヌル（U + 0000）文字をエスケープすることが示されました。等号ことが示された（「=」U + 003D）文字は「\ =」のようにエスケープすることができます。 - RFC 4234.で定義されたABNFを使用するために書き直し第3節 - 第3節ABNFを更新しました。変更点は以下のとおりです。長さ1（例えば、「L」）、+ attributeTypes属性で、より限定<OID>生産使用、+の等号エスケープする必要はありませんでした（「=」U + 003D）文字の+許可AttributeTypeで短い名前+でした、文字を非有数番号記号（「＃」U + 0023）文字のエスケープ、+スペース（」ヌルのエスケープ\ 『+必要な六角（U + 0000） 'U + 0020）のようにエスケープすることが』許さ必要はありませんそして+削除のLDAPv2のみの構築。 - 文法の要素を解析する方法を説明するために、セクション3を更新しました。 - 書き直しの例。 - 一般的なLDAPセキュリティの考慮事項を含むドキュメンテーションへの参照を追加。 - プレゼンテーションの問題（付録A）の議論を追加しました。 - この付録を追加しました。
In addition, numerous editorial changes were made.
さらに、多数の編集上の変更が行われました。
Editor's Address
編集者の住所
Kurt D. Zeilenga OpenLDAP Foundation
クルトD. ZeilengaのOpenLDAP財団
EMail: Kurt@OpenLDAP.org
メールアドレス：Kurt@OpenLDAP.org
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）によって提供されます。