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).




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)で使用される文字列表現を定義します。文字列表現は、任意の識別名を表現することができることながら、一般的に使用される識別名のきれいな表現を与えるように設計されています。

1. Background and Intended Usage

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).


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.


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].


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]に精通している前提としています。

1.1. Conventions
1.1. 表記

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]で見つけることができます。

2. Converting DistinguishedName from ASN.1 to a String
2. StringにASN.1から識別名を変換

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 ::= 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実装で製造されなければなりません。

2.1. Converting the RDNSequence
2.1. RDNSequenceの変換

If the RDNSequence is an empty sequence, the result is the empty or zero-length string.


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.


The encodings of adjoining RelativeDistinguishedNames are separated by a comma (',' U+002C) character.

隣接する相対識別名の符号化は、カンマ(「」U + 002C)文字で区切られます。

2.2. Converting RelativeDistinguishedName
2.2. 変換RelativeDistinguishedName

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.


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)文字で区切られます。

2.3. Converting AttributeTypeAndValue
2.3. 変換AttributeTypeAndValue

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.


2.4. Converting an AttributeValue from ASN.1 to a String
2.4. StringにASN.1からAttributeValueの変換

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.


- 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


' ', '"', '#', '+', ',', ';', '<', '=', '>', 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.


3. Parsing a String Back to a Distinguished Name

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:


      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.


There is zero or more relative distinguished names, separated by <COMMA>, for a distinguished name.


Implementations MUST recognize AttributeType name strings (descriptors) listed in the following table, but MAY recognize other name strings.


      String  X.500 AttributeType
      ------  --------------------------------------------
      CN      commonName (
      L       localityName (
      ST      stateOrProvinceName (
      O       organizationName (
      OU      organizationalUnitName (
      C       countryName (
      STREET  streetAddress (
      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].


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.


4. Examples

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):



UID = JSMITH、DC =例、DC =ネット

Here is an example of a name containing three RDNs, in which the first RDN is multi-valued:


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は\ 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.


Finally, this example shows an RDN whose commonName value consists of 5 letters:


      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:



CN =呂\ C4 \ 8DI \ C4 \ 87

5. Security Considerations

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]を構成する他の文書で説明されています。

5.1. Disclosure
5.1. 開示

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]は考慮されるべきです。

5.2. Use of Distinguished Names in Security Applications
5.2. セキュリティアプリケーションにおける識別名の使用

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.


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進形式を使用すべきです。

6. Acknowledgements

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ワーキンググループの製品です。

7. References
7.1. Normative References
7.1. 引用規格

[REGISTRY] IANA, Object Identifier Descriptors Registry, <>.

[REGISTRY] IANA、識別子ディスクリプタレジストリオブジェクト、<>。

[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" ( and by the "Unicode Standard Annex #28: Unicode 3.2" (

[UNICODE]ユニコードコンソーシアムは、 "Unicode標準、バージョン3.2.0" は、 "Unicode規格、バージョン3.0"(読書、MA、アディソン・ウェズリー、61633から5 2000. ISBN 0-201-)などによって定義されます改正 "Unicode標準の附属書#27:ユニコード3.1"(とで "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月。

7.2. Informative References
7.2. 参考文献

[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, <>, August 2000.

[CharModel]ウィスラー、K.とM.デイヴィス、 "Unicodeの技術レポート#17、文字エンコーディングモデル"、UTR17、<>、2000年8月。

[Glossary] The Unicode Consortium, "Unicode 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


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.


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.


Not all user interfaces are capable of displaying the full set of Unicode characters. Some Unicode characters are not displayable.


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).


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:


         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.


Another alternative is to use the LDAP Data Interchange Format (LDIF) [RFC2849]. For example:


         # 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


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財団



Full Copyright Statement


Copyright (C) The Internet Society (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に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。


この文書とここに含まれている情報は、基礎と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


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は、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。



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