[要約] RFC 2247は、LDAP/X.500の識別名でドメインを使用する方法について説明しています。このRFCの目的は、ドメインを識別名に組み込むための標準化と一貫性を提供することです。

Network Working Group                                           S. Kille
Request for Comments: 2247                                    Isode Ltd.
Category: Standards Track                                        M. Wahl
                                                     Critical Angle Inc.
                                                             A. Grimstad
                                                                    AT&T
                                                                R. Huber
                                                                    AT&T
                                                             S. Sataluri
                                                                    AT&T
                                                            January 1998
        

Using Domains in LDAP/X.500 Distinguished Names

LDAP / X.500識別名でのドメインの使用

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 (1998). All Rights Reserved.

Copyright(C)The Internet Society(1998)。全著作権所有。

1. Abstract
1. 概要

The Lightweight Directory Access Protocol (LDAP) uses X.500- compatible distinguished names [3] for providing unique identification of entries.

ライトウェイトディレクトリアクセスプロトコル(LDAP)は、X.500互換の識別名[3]を使用して、エントリを一意に識別します。

This document defines an algorithm by which a name registered with the Internet Domain Name Service [2] can be represented as an LDAP distinguished name.

このドキュメントでは、インターネットドメインネームサービス[2]に登録された名前をLDAP識別名として表現できるアルゴリズムを定義しています。

2. Background
2. バックグラウンド

The Domain (Nameserver) System (DNS) provides a hierarchical resource labeling system. A name is made up of an ordered set of components, each of which are short strings. An example domain name with two components would be "CRITICAL-ANGLE.COM".

ドメイン(ネームサーバー)システム(DNS)は、階層的なリソースラベル付けシステムを提供します。名前は、順序付けられたコンポーネントのセットで構成され、各コンポーネントは短い文字列です。 2つのコンポーネントを持つドメイン名の例は、 "CRITICAL-ANGLE.COM"です。

LDAP-based directories provide a more general hierarchical naming framework. A primary difference in specification of distinguished names from domain names is that each component of an distinguished name has an explicit attribute type indication.

LDAPベースのディレクトリは、より一般的な階層命名フレームワークを提供します。識別名とドメイン名の仕様の主な違いは、識別名の各コンポーネントに明示的な属性タイプの指示があることです。

X.500 does not mandate any particular naming structure. It does contain suggested naming structures which are based on geographic and national regions, however there is not currently an established registration infrastructure in many regions which would be able to assign or ensure uniqueness of names.

X.500は特定の命名構造を義務付けていません。これには、地理的および国の地域に基づく推奨される命名構造が含まれていますが、現在、多くの地域で、名前の割り当てまたは一意性を保証できる確立された登録インフラストラクチャはありません。

The mechanism described in this document automatically provides an enterprise a distinguished name for each domain name it has obtained for use in the Internet. These distinguished names may be used to identify objects in an LDAP directory.

このドキュメントで説明するメカニズムは、インターネットで使用するために取得した各ドメイン名の識別名を自動的に企業に提供します。これらの識別名は、LDAPディレクトリ内のオブジェクトを識別するために使用できます。

An example distinguished name represented in the LDAP string format [3] is "DC=CRITICAL-ANGLE,DC=COM". As with a domain name, the most significant component, closest to the root of the namespace, is written last.

LDAP文字列形式[3]で表される識別名の例は、「DC = CRITICAL-ANGLE、DC = COM」です。ドメイン名と同様に、名前空間のルートに最も近い最も重要なコンポーネントが最後に記述されます。

This document does not define how to represent objects which do not have domain names. Nor does this document define the procedure to locate an enterprise's LDAP directory server, given their domain name. Such procedures may be defined in future RFCs.

このドキュメントでは、ドメイン名を持たないオブジェクトの表現方法を定義していません。また、このドキュメントでは、ドメイン名を指定して、企業のLDAPディレクトリサーバーを見つける手順を定義していません。このような手順は、将来のRFCで定義される可能性があります。

3. Mapping Domain Names into Distinguished Names
3. ドメイン名を識別名にマッピングする

This section defines a subset of the possible distinguished name structures for use in representing names allocated in the Internet Domain Name System. It is possible to algorithmically transform any Internet domain name into a distinguished name, and to convert these distinguished names back into the original domain names.

このセクションでは、インターネットドメインネームシステムで割り当てられた名前を表すために使用できる識別名構造のサブセットを定義します。アルゴリズムによってインターネットドメイン名を識別名に変換し、これらの識別名を元のドメイン名に戻すことが可能です。

The algorithm for transforming a domain name is to begin with an empty distinguished name (DN) and then attach Relative Distinguished Names (RDNs) for each component of the domain, most significant (e.g. rightmost) first. Each of these RDNs is a single AttributeTypeAndValue, where the type is the attribute "DC" and the value is an IA5 string containing the domain name component.

ドメイン名を変換するためのアルゴリズムは、空の識別名(DN)から始めて、ドメインの各コンポーネントに相対識別名(RDN)を、最も重要な(右端など)から最初に付加することです。これらの各RDNは単一のAttributeTypeAndValueで、タイプは属性「DC」で、値はドメイン名コンポーネントを含むIA5文字列です。

Thus the domain name "CS.UCL.AC.UK" can be transformed into

したがって、ドメイン名「CS.UCL.AC.UK」は次のように変換できます。

        DC=CS,DC=UCL,DC=AC,DC=UK
        

Distinguished names in which there are one or more RDNs, all containing only the attribute type DC, can be mapped back into domain names. Note that this document does not define a domain name equivalence for any other distinguished names.

1つ以上のRDNがあり、すべてが属性タイプDCのみを含む識別名は、ドメイン名にマップして戻すことができます。このドキュメントでは、他の識別名と同等のドメイン名は定義していません。

4. Attribute Type Definition
4. 属性タイプの定義

The DC (short for domainComponent) attribute type is defined as follows:

DC(domainComponentの略)属性タイプは、次のように定義されます。

( 0.9.2342.19200300.100.1.25 NAME 'dc' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

(0.9.2342.19200300.100.1.25 NAME 'dc' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE)

The value of this attribute is a string holding one component of a domain name. The encoding of IA5String for use in LDAP is simply the characters of the string itself. The equality matching rule is case insensitive, as is today's DNS.

この属性の値は、ドメイン名の1つのコンポーネントを保持する文字列です。 LDAPで使用するIA5Stringのエンコーディングは、単に文字列自体の文字です。等価一致ルールは、今日のDNSと同様に、大文字と小文字を区別しません。

5. Object Class Definitions
5. オブジェクトクラスの定義

An object with a name derived from its domain name using the algorithm of section 3 is represented as an entry in the directory. The "DC" attribute is present in the entry and used as the RDN.

セクション3のアルゴリズムを使用してドメイン名から派生した名前を持つオブジェクトは、ディレクトリ内のエントリとして表されます。 「DC」属性はエントリに存在し、RDNとして使用されます。

An attribute can only be present in an entry held by an LDAP server when that attribute is permitted by the entry's object class.

属性は、その属性がエントリのオブジェクトクラスによって許可されている場合にのみ、LDAPサーバーが保持するエントリに存在できます。

This section defines two object classes. The first, dcObject, is intended to be used in entries for which there is an appropriate structural object class. For example, if the domain represents a particular organization, the entry would have as its structural object class 'organization', and the 'dcObject' class would be an auxiliary class. The second, domain, is a structural object class used for entries in which no other information is being stored. The domain object class is typically used for entries that are placeholders or whose domains do not correspond to real-world entities.

このセクションでは、2つのオブジェクトクラスを定義します。最初のdcObjectは、適切な構造オブジェクトクラスがあるエントリで使用するためのものです。たとえば、ドメインが特定の組織を表す場合、エントリはその構造オブジェクトクラスとして「organization」を持ち、「dcObject」クラスは補助クラスになります。 2番目のドメインは、他の情報が格納されていないエントリに使用される構造オブジェクトクラスです。ドメインオブジェクトクラスは通常、プレースホルダーであるエントリ、またはドメインが実際のエンティティに対応しないエントリに使用されます。

5.1. The dcObject object class
5.1. dcObjectオブジェクトクラス

The dcObject object class permits the dc attribute to be present in an entry. This object class is defined as auxiliary, as it would typically be used in conjunction with an existing structural object class, such as organization, organizationalUnit or locality.

dcObjectオブジェクトクラスでは、dc属性をエントリに含めることができます。このオブジェクトクラスは、通常、organization、organizationalUnit、localityなどの既存の構造オブジェクトクラスと組み合わせて使用​​されるため、補助として定義されます。

The following object class, along with the dc attribute, can be added to any entry.

次のオブジェクトクラスは、dc属性とともに、任意のエントリに追加できます。

( 1.3.6.1.4.1.1466.344 NAME 'dcObject' SUP top AUXILIARY MUST dc )

(1.3.6.1.4.1.1466.344 NAME 'dcObject' SUP top AUXILIARY MUST dc)

An example entry would be:

エントリの例は次のとおりです。

dn: dc=critical-angle,dc=com objectClass: top objectClass: organization objectClass: dcObject dc: critical-angle o: Critical Angle Inc.

dn:dc = critical-angle、dc = com objectClass:top objectClass:organization objectClass:dcObject dc:critical-angle o:Critical Angle Inc.

5.2. The domain object class
5.2. ドメインオブジェクトクラス

If the entry does not correspond to an organization, organizational unit or other type of object for which an object class has been defined, then the "domain" object class can be used. The "domain" object class requires that the "DC" attribute be present, and permits several other attributes to be present in the entry.

エントリが、オブジェクトクラスが定義されている組織、組織単位、またはその他のタイプのオブジェクトに対応していない場合は、「ドメイン」オブジェクトクラスを使用できます。 「ドメイン」オブジェクトクラスは、「DC」属性が存在することを必要とし、他のいくつかの属性がエントリに存在することを許可します。

The entry will have as its structural object class the "domain" object class.

エントリは、その構造オブジェクトクラスとして「ドメイン」オブジェクトクラスを持ちます。

( 0.9.2342.19200300.100.4.13 NAME 'domain' SUP top STRUCTURAL MUST dc MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description $ o $ associatedName ) )

(0.9.2342.19200300.100.4.13 NAME 'domain' SUP top STRUCTURAL MUST dc MAY(userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ phoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description $ o $ associatedName))

The optional attributes of the domain class are used for describing the object represented by this domain, and may also be useful when searching. These attributes are already defined for use with LDAP [4].

ドメインクラスのオプションの属性は、このドメインによって表されるオブジェクトを説明するために使用され、検索時にも役立つ場合があります。これらの属性は、LDAP [4]で使用するためにすでに定義されています。

An example entry would be:

エントリの例は次のとおりです。

   dn: dc=tcp,dc=critical-angle,dc=com
   objectClass: top
   objectClass: domain
   dc: tcp
   description: a placeholder entry used with SRV records
        

The DC attribute is used for naming entries of the domain class, and this can be represented in X.500 servers by the following name form rule.

DC属性は、ドメインクラスのエントリに名前を付けるために使用されます。これは、X.500サーバーでは次の名前形式規則によって表すことができます。

( 1.3.6.1.4.1.1466.345 NAME 'domainNameForm' OC domain MUST ( dc ) )

(1.3.6.1.4.1.1466.345 NAME 'domainNameForm' OC domainは必須(dc))

6. References
6. 参考文献

[1] The Directory: Selected Attribute Types. ITU-T Recommendation X.520, 1993.

[1] ディレクトリ:選択された属性タイプ。 ITU-T勧告X.520、1993。

[2] Mockapetris, P., " Domain Names - Concepts and Facilities," STD 13, RFC 1034, November 1987.

[2] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。

[3] Kille, S., and M. Wahl, " Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997.

[3] Kille、S。、およびM. Wahl、「Lightweight Directory Access Protocol(v3):UTF-8 String Representation of Distinguished Names」、RFC 2253、1997年12月。

[4] Wahl, M., "A Summary of the X.500(96) User Schema for use with LDAP", RFC 2256, December 1997.

[4] Wahl、M。、「LDAPで使用するX.500(96)ユーザースキーマの概要」、RFC 2256、1997年12月。

7. Security Considerations
7. セキュリティに関する考慮事項

This memo describes how attributes of objects may be discovered and retrieved. Servers should ensure that an appropriate security policy is maintained.

このメモは、オブジェクトの属性がどのように発見および取得されるかを説明しています。サーバーは、適切なセキュリティポリシーが維持されていることを確認する必要があります。

An enterprise is not restricted in the information which it may store in DNS or LDAP servers. A client which contacts an untrusted server may have incorrect or misleading information returned (e.g. an organization's server may claim to hold naming contexts representing domain names which have not been delegated to that organization).

企業は、DNSサーバーまたはLDAPサーバーに格納される情報に制限はありません。信頼されていないサーバーにアクセスするクライアントは、誤った情報または誤解を招く情報を返すことがあります(たとえば、組織のサーバーは、その組織に委任されていないドメイン名を表す名前付けコンテキストを保持していると主張する場合があります)。

8. Authors' Addresses
8. 著者のアドレス

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

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

Phone: +44-181-332-9091 EMail: S.Kille@ISODE.COM Mark Wahl Critical Angle Inc. 4815 W. Braker Lane #502-385 Austin, TX 78759 USA

電話:+ 44-181-332-9091メール:S.Kille@ISODE.COM Mark Wahl Critical Angle Inc. 4815 W. Braker Lane#502-385 Austin、TX 78759 USA

Phone: (1) 512 372 3160 EMail: M.Wahl@critical-angle.com

電話:(1)512 372 3160メール:M.Wahl@critical-angle.com

Al Grimstad AT&T Room 1C-429, 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA

Al Nimstad AT&T Room 1C-429、101 Crawfords Corner Road Holmdel、NJ 07733-3030 USA

   EMail: alg@att.com
        

Rick Huber AT&T Room 1B-433, 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA

Rick Huber AT&T Room 1B-433、101 Crawfords Corner Road Holmdel、NJ 07733-3030 USA

   EMail: rvh@att.com
        

Sri Sataluri AT&T Room 4G-202, 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA

Sri Sataluri AT&T Room 4G-202、101 Crawfords Corner Road Holmdel、NJ 07733-3030 USA

   EMail: sri@att.com
        
9. 完全な著作権表示

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

Copyright(C)The Internet Society(1998)。全著作権所有。

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.

このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。