Lightweight Directory Access Protocol (v3):
UTF-8 String Representation of Distinguished Names

このメモの位置付け

本文書は、 インターネットコミュニティのための標準化プロトコルを規定するとともに、 それを改良するための議論や提言を求めるものである。 本プロトコルの標準化状態、および、ステータスについては「Internet Official Protocol Standards」(STD 1)の最新版を参照してほしい。 このメモの配布に制限は無い。

著作権について

Copyright (C) The Internet Society (1997).  All Rights Reserved.

IESGノート

本文書では、 読み出しおよび更新アクセスを提供するディレクトリアクセスプロトコルについて述べる。 更新アクセスには安全な認証が必要であるが、 本文書は十分な認証機構の実装についてはなにも指示しない。

このような制限は存在するが、本仕様書は、 RFC 2026のセクション4.4.1に従って、Proposed StandardとしてIESGに認可されている。 その理由は次の通りである：

1. 配備される前に、(更新アクセスの有無に関わらず)本プロトコルの実装と相互運用性の試験を奨励するため。
2. 読み出し専用のアプリケーション中で、これらのプロトコルの配備と利用を奨励するため。(例えば、LDAP以外の安全な方法で更新されるディレクトリに対して、LDAPv3が問い合わせ言語として使用されているアプリケーション）
3. LDAPv3ディレクトリサーバへの問い合わせ機能が必要であるが、更新を必要としない他の標準化過程にあるプロトコルの配備、あるいは進歩を遅らせないため。

必須の認証機構が標準化されるまで、 本仕様に従って書かれた更新機能を利用するクライアントとサーバは相互運用できない、あるいは、 認証レベルが受け入れ難いレベルにまで下げられる場合に限り相互運用できる、 という可能性があることを読者にあらかじめ警告する。

実装者は、LDAPv3で必須となる認証のためのProposed Standardが認められ、 RFCとして発行されるまで、更新機能を実装するLDAPv3クライアント、 およびサーバの配備を行わないことが望ましい。

要約

X.500ディレクトリは、ディレクトリ内のエントリに対する主要なキーとして、 識別名を使用する。 また、X.500ディレクトリプロトコル中では、識別名はASN.1で符号化されている。 Lightweight Directory Access Protocolでは、 識別名の文字列表現が転送される。 本仕様は、名前を表記するための文字列フォーマットを定義するものあり、 一般的に使用される名前をすっきりと表記することができ、一方で、 どのような識別名も表記することができるように設計されている。

この文書中のキーワード、"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL"は、 RFC 2119[6]に記述されているように解釈されるべき用語である。

本仕様書では、X.500[1]、 および識別名の概念に関して、熟知しているものと仮定する。 識別名を明確に表現することができる共通フォーマットを持つことは重要である。 この仕様の第一の目標は、符号化と復号化の簡素化である。 第二の目標は人が読める名前を持つことである。 人に対するユーザインタフェースを持つLDAPクライアントがユーザに直接これらの文字列を見せることは想定されていないが、 ほとんどの場合、変換が行われる。 (例えば、属性型名を母国語で表現するように)。

X.501[2]において、 識別名のASN.1構造は次のように定義されている：

       DistinguishedName ::= RDNSequence

       RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

       RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
        AttributeTypeAndValue

       AttributeTypeAndValue ::= SEQUENCE {
        type  AttributeType,
        value AttributeValue }
    

次のセクションではASN.1の構造化された表現からUTF-8による文字列表現に変換するためのアルゴリズムを定義する。

RDNSequenceが空シーケンスの場合、結果は空か長さゼロの文字列である。

それ以外の場合、 出力はRDNSequence(セクション2.2に従う)中の各相対識別名の文字列符号化から成る。 それはシーケンスの最後の要素から始まり、後ろ向きに先頭へ移動する。

隣接する相対識別名の符号化はコンマ(','ASCII 44)によって区切られている。

ASN.1による相対識別名を文字列へ変換する場合、出力は、順序に関係なく、 各AttributeTypeAndValue(セクション2.3)の文字列符号化から成り立つ。

複数の値を持つRDNの部分では、 それらの隣接しているAttributeTypeAndValuesからの出力はプラス('+' ASCII 43)によって区切られている。

AttributeTypeAndValueは、AttributeTypeの文字列表現、 イコール('='ASCII 61)、AttributeValueの文字列表現、 と続く文字列表現として符号化される。 AttributeValueの符号化はセクション2.4に説明されている。

AttributeTypeは、 LDAP[4]に関連する属性型の表に公開されていれば、 その表中の型の名前を表す文字列が使用され、そうでない場合、 AttributeTypeのオブジェクトIDのドットで区切られた10進数表記として符号化される。 ドットで区切られた10進数表記は[3]で述べられる。 RDNでよくある属性型に対する文字列の例を次にあげる。

String  X.500 AttributeType
------------------------------
CN      commonName
L       localityName
ST      stateOrProvinceName
O       organizationName
OU      organizationalUnitName
C       countryName
STREET  streetAddress
DC      domainComponent
UID     userid
    

AttributeValueがそのための文字列表現を定義されていない型であるなら、 それは単に、シャープ文字('#' ASCII 35)を先頭としたＸ.500 AttributeValueのBER符号化を16進表現したバイト列として符号化される。 AttributeTypeがドットで区切られた10進数形式の場合は、 その形式が使用されるべき(SHOULD)である。

それ以外に、AttributeValueが文字列表現を持っている型なら、 値はその構文仕様([4]のセクション6を参照)に従って、 まずUTF-8文字列に変換される。

UTF-8文字列がエスケープを必要とする次のいずれの文字も持っていないなら、 その文字列は値の文字列表現として使われ得る。

• 文字列の初めに空白あるいは、「#」文字がある場合
• 文字列の終わりに空白文字がある場合
• ",","+",""","\","<",">"あるいは";"の文字がある場合

実装によっては、他の文字もエスケープしてもよい。(MAY)。

エスケープされる文字が上のリストに示された文字のいずれかであるなら、 その文字の前にバックスラシュ('\' ASCII 92)を接頭辞として付ける。

そうでなければ、 エスケープ文字はバックスラシュと二桁の16進数で置き換えられる。 これらは文字コード中で1バイトを形成する。

エスケープメカニズムの例はセクション5で示される。

文字列の構造は、 RFC 822[5]で定義された文法に基づいて、 BNF記法で指定される。 LDAPv2クライアントによって生成されたDN文字列を解析するサーバの実装は、 本文書のセクション4で述べられる多様性を許容(そして無視)しなければならない(MUST)。

  distinguishedName = [name]
  ; may be empty string

  name       = name-component *("," name-component)

  name-component = attributeTypeAndValue *("+" attributeTypeAndValue)

  attributeTypeAndValue = attributeType "=" attributeValue

  attributeType = (ALPHA 1*keychar) / oid
  keychar    = ALPHA / DIGIT / "-"

  oid        = 1*DIGIT *("." 1*DIGIT)

  attributeValue = string

  string     = *( stringchar / pair )
               / "#"
  hexstring
               / QUOTATION *(
  quotechar / pair ) QUOTATION ; only from v2

  quotechar     = <any character except "\" or
  QUOTATION>

  special    = "," / "=" / "+" /
  "<" /  ">" / "#" / ";"

  pair       = "\" ( special / "\" /
  QUOTATION / hexpair )
  stringchar = <any character except one of special, "\" or QUOTATION>

  hexstring  = 1*hexpair
  hexpair    = hexchar hexchar

  hexchar    = DIGIT / "A" / "B" / "C" /
  "D" / "E" / "F"
               / "a" /
  "b" / "c" / "d" / "e" / "f"

  ALPHA      =  <any ASCII alphabetic character>

  ; (decimal 65-90 and 97-122)
  DIGIT      =  <any ASCII decimal digit>  ;
  (decimal 48-57)
  QUOTATION  =  <the ASCII double quotation mark character '"'
  decimal 34>
    

本文書で述べられている構文は、 RFC 1779で述べられた構文よりもさらに制限が設けられている。 LDAPv2のクライアントによって生成された文字列を解析する実装はRFC 1779の構文を受け入れなければならない(MUST)。 しかしながら、実装は、 上のセクション2で記述していないいずれのRFC 1779符号化も行ってはならない(MUST NOT)。

実装は、識別名においてRDNを区切るためのコンマの代わりに、 セミコロンが使用されることを認めなければならない(MUST)。 また、コンマやセミコロンの両側に空白文字があることを許さなければならない(MUST)。 空白文字は無視され、セミコロンはコンマに置き換えられる。

実装は、 属性型oidが文字列"oid."または"OID"のどちらか一つをその前に付けることを容認しなければならない(MUST)。

実装は、名前の要素と','の間、attributeTypeAndValueと'+'の間、 attributeTypeと'='の間、および、'='とattributeValueの間に、 空白(' ' ASCII 32)文字があることを許容しなければならない(MUST)。 これらの空白文字は解析時には無視される。

実装は、 値がクオート("" ASCII 34)文字で囲まれることを許容しなければならない(MUST)。 このクオート("" ASCII 34)文字は値の部分ではない。 クオート中では、次の文字はエスケープの必要はない。

    ",", "=", "+", "<", ">", "#" and ";"
    

本表記法は、名前を一般的な形式で利用できるように設計されている。 このセクションでは本表記法を使って書かれた識別名の例をいくつか示している。 最初は三つの相対識別名（RDN)を含んでいる名前である：

   CN=Steve Kille,O=Isode Limited,C=GB

次に示すのは、最初のRDNが複数の値を持つ、 三つのRDNを含んでいる名前の例である。：

   OU=Sales+CN=J. Smith,O=Widget Inc.,C=US

以下の例は組織名中にコンマを引用する方法を示している。

   CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB

改行文字を含んでいる値の例：

   CN=Before\0DAfter,O=Test,C=GB

認識されなかった型のRDNがある名前の例。 値が0x48と0x69の二つのバイトを含むOCTET STRINGをBER符号化する。

   1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB

最後に五つの文字で成り立っている RDNsurnameの例を示す：

    Unicode Letter Description       10646 code UTF-8  Quoted
    =============================== ========== ====== =======
    LATIN CAPITAL LETTER L          U0000004C  0x4C   L
    LATIN SMALL LETTER U            U00000075  0x75   u
    LATIN SMALL LETTER C WITH CARON U0000010D  0xC48D \C4\8D
    LATIN SMALL LETTER I            U00000069  0x69   i
    LATIN SMALL LETTER C WITH ACUTE U00000107  0xC487 \C4\87
    

印刷可能なASCII文字で書かれ得る（デバッグするために役立つ）：

   SN=Lu\C4\8Di\C4\87

[1] The Directory -- overview of concepts, models and services. ITU-T Rec.X.500(1993).

[2] The Directory -- Models. ITU-T Rec. X.501(1993).

[3] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access  Protocol (v3)",RFC 2251, December 1997.

[4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.

[5] Crocker, D., "Standard of the Format of ARPA-Internet Text Messages", STD 11, RFC 822, August 1982.

[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119.

識別名は、普通、名付けたエントリについての記述的な情報から成り立つ。 この情報は人々、組織、装置あるいは他の実世界のものであり得る。 これはしばしば、以下のような情報を含む :

• オブジェクトの一般名（つまり、人の名前）
• emailあるいは TCP/IPのアドレス
• その物理的な場所（国、地域、都市、道路住所）
• 組織的な属性（例えば、部課名、所属)

ほとんどの国に、 個人情報の公開に関してプライバシー保護のための法律がある。

AttributeValue値のX.501形式からLDAP文字列表現ヘの変換はBERあるいはDER形式に逆変換できない場合もある。 識別名のDER形式を要求する場合の例はX.509証明書の照合である。

例えば、 型がcommonNameで値が‘Sam'というTeletexStringの一つのAVAから成る一つのRDNで構成される識別名は、 LDAPでは文字列CN=Samと表される。 値が'Sam'で、PrintableStringである他の識別名の場合にも、 LDAPでは同じ文字列CN=Samと示される。

値のDER形式の再構成を要求するアプリケーションは、 識別名をLDAPフォーマットに変換する時、 属性構文の文字列表現を使うべきではない(SHOULD NOT)。 その代わりに、セクション2.4の最初の節で記述したように、 シャープ（"#"）を前につけた16進数形式を使うべきである(SHOULD)。

   Mark Wahl
   Critical Angle Inc.
   4815 W. Braker Lane #502-385
   Austin, TX 78759
   USA

   EMail:  M.Wahl@critical-angle.com
    

   Steve Kille
   Isode Ltd.
   The Dome
   The Square
   Richmond, Surrey
   TW9 1DT
   England

   Phone:  +44-181-332-9091
   EMail:  S.Kille@ISODE.COM
    

   Tim Howes
   Netscape Communications Corp.
   501 E. Middlefield Rd, MS MV068
   Mountain View, CA 94043
   USA

   Phone:  +1 650 937-3419
   EMail:   howes@netscape.com
    

Copyright (C) The Internet Society (1997).  All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works.  However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.