RFC2253 日本語訳
2253 Lightweight Directory Access Protocol (v3): UTF-8 StringRepresentation of Distinguished Names. M. Wahl, S. Kille, T. Howes. December 1997. (Format: TXT=18226 bytes) (Obsoletes RFC1779) (Obsoleted by RFC4510, RFC4514) (Updated by RFC3377) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Wahl
Request for Comments: 2253 Critical Angle Inc.
Obsoletes: 1779 S. Kille
Category: Standards Track Isode Ltd.
T. Howes
Netscape Communications Corp.
December 1997
コメントを求めるワーキンググループM.ウォール要求をネットワークでつないでください: 株式会社が時代遅れにする2253臨界角: 1779秒間Killeカテゴリ: 標準化過程Isode株式会社T.ハウズネットスケープ・コミュニケーションズ1997年12月
Lightweight Directory Access Protocol (v3):
UTF-8 String Representation of Distinguished Names
ライトウェイト・ディレクトリ・アクセス・プロトコル(v3): 分類名のUTF-8ストリング表現
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright(C)インターネット協会(1997)。 All rights reserved。
IESG Note
IESG注意
This document describes a directory access protocol that provides both read and update access. Update access requires secure authentication, but this document does not mandate implementation of any satisfactory authentication mechanisms.
このドキュメントは読まれた両方を提供するディレクトリアクセス・プロトコルとアップデートアクセサリーについて説明します。 アップデートアクセスは安全な認証を必要としますが、このドキュメントはどんな満足できる認証機構の実装も強制しません。
In accordance with RFC 2026, section 4.4.1, this specification is being approved by IESG as a Proposed Standard despite this limitation, for the following reasons:
RFC2026、セクション4.4.1に従って、この制限にもかかわらず、この仕様はProposed StandardとしてIESGによって承認されます、以下の理由で:
a. to encourage implementation and interoperability testing of
these protocols (with or without update access) before they
are deployed, and
そしてa. 以前これらのプロトコル(アップデートアクセスのあるなしにかかわらず)の実装と相互運用性テストを奨励するために、それらが配布される。
b. to encourage deployment and use of these protocols in read-only
applications. (e.g. applications where LDAPv3 is used as
a query language for directories which are updated by some
secure mechanism other than LDAP), and
b. 書き込み禁止アプリケーションにおけるこれらのプロトコルの展開と使用を奨励するために。 (例えば、LDAPv3がLDAP以外の何らかの安全なメカニズムによってアップデートされるディレクトリに照会言語として使用されるアプリケーション), そして
c. to avoid delaying the advancement and deployment of other Internet
standards-track protocols which require the ability to query, but
not update, LDAPv3 directory servers.
c. LDAPv3ディレクトリサーバを質問しますが、アップデートしない能力を必要とする他のインターネット標準化過程プロトコルの前進と展開を遅らせるのを避けるために。
Wahl, et. al. Proposed Standard [Page 1] RFC 2253 LADPv3 Distinguished Names December 1997
etウォール、アル。 提案された標準[1ページ]RFC2253LADPv3分類名1997年12月
Readers are hereby warned that until mandatory authentication mechanisms are standardized, clients and servers written according to this specification which make use of update functionality are UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
Readers are hereby warned that until mandatory authentication mechanisms are standardized, clients and servers written according to this specification which make use of update functionality are UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
Implementors are hereby discouraged from deploying LDAPv3 clients or servers which implement the update functionality, until a Proposed Standard for mandatory authentication in LDAPv3 has been approved and published as an RFC.
作成者はアップデートの機能性を実装するLDAPv3クライアントかサーバを配布して、これによりがっかりしています、LDAPv3での義務的な認証のためのProposed StandardがRFCとして承認されて、発行されるまで。
Abstract
要約
The X.500 Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1 in the X.500 Directory protocols. In the Lightweight Directory Access Protocol, a string representation of distinguished names is transferred. This specification defines the string format for representing names, which is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name.
X.500ディレクトリは主キーとしてディレクトリでエントリーに分類名を使用します。 顕著なNamesはASN.1でX.500ディレクトリプロトコルでコード化されます。 ライトウェイト・ディレクトリ・アクセス・プロトコルでは、分類名のストリング表現はわたっています。 この仕様は名前を表すための記号列の書式を定義します。(それは、一般的に使用された分類名の清潔な表現を与えるようにどんな分類名も表すことができる間、設計されています)。
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 RFC 2119 [6].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[6]で説明されるように本書では解釈されることであるべきですか?
1. Background
1. バックグラウンド
This specification assumes familiarity with X.500 [1], and the concept of Distinguished Name. 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 clients with a human user interface would display these strings directly to the user, but would most likely be performing translations (such as expressing attribute type names in one of the local national languages).
この仕様は、X.500への親しみが[1]と、Distinguished Nameの概念であると仮定します。 明白に分類名を表すことができるように一般的な形式を持っているのは重要です。 この仕様のプライマリ目標はコード化と解読の容易さです。 セカンダリ目標は読み込み可能な状態で人間である名前を持つことです。 人間のユーザーインタフェースをもっているLDAPクライアントが直接ユーザにこれらのストリングを表示しないと予想されます、たぶん、翻訳(現地雇用人言語の1つによる属性型名を表すことなどの)を実行していて。
2. Converting DistinguishedName from ASN.1 to a String
2. ASN.1からストリングまでDistinguishedNameを変換します。
In X.501 [2] the ASN.1 structure of distinguished name is defined as:
X.501[2]では、分類名のASN.1構造は以下と定義されます。
DistinguishedName ::= RDNSequence
DistinguishedName:、:= RDNSequence
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
RDNSequence:、:= RelativeDistinguishedNameの系列
Wahl, et. al. Proposed Standard [Page 2] RFC 2253 LADPv3 Distinguished Names December 1997
etウォール、アル。 提案された標準[2ページ]RFC2253LADPv3分類名1997年12月
RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
AttributeTypeAndValue
RelativeDistinguishedName:、:= AttributeTypeAndValueのサイズ(1..MAX)を設定してください。
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType,
value AttributeValue }
AttributeTypeAndValue:、:= 系列AttributeType、値のAttributeValueをタイプしてください。
The following sections define the algorithm for converting from an ASN.1 structured representation to a UTF-8 string representation.
以下のセクションはASN.1の構造化された表現からUTF-8ストリング表現まで変換するためのアルゴリズムを定義します。
2.1. Converting the RDNSequence
2.1. RDNSequenceを変換します。
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 2.2), starting with the last element of the sequence and moving backwards toward the first.
さもなければ、出力はRDNSequence(2.2に従って)のそれぞれのRelativeDistinguishedNameのストリングencodingsから成ります、系列の最後の原理から始まって、後方に1番目に近づいて。
The encodings of adjoining RelativeDistinguishedNames are separated
by a comma character (',' ASCII 44).
RelativeDistinguishedNamesに隣接するencodingsがコンマキャラクタによって切り離される、('、'、ASCII44)。
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 2.3), in any order.
ASN.1RelativeDistinguishedNameからストリングまで変換するとき、出力はそれぞれのAttributeTypeAndValue(2.3に従って)のストリングencodingsから成ります、順不同に。
Where there is a multi-valued RDN, the outputs from adjoining
AttributeTypeAndValues are separated by a plus ('+' ASCII 43)
character.
マルチ評価されたRDNがあるところに、AttributeTypeAndValuesに隣接するのからの出力はプラス('+'ASCII43)キャラクタによって切り離されます。
2.3. Converting AttributeTypeAndValue
2.3. AttributeTypeAndValueを変換します。
The AttributeTypeAndValue is encoded as the string representation of
the AttributeType, followed by an equals character ('=' ASCII 61),
followed by the string representation of the AttributeValue. The
encoding of the AttributeValue is given in section 2.4.
AttributeValueのストリング表現で同輩キャラクタ(ASCII61と'等しい')によって後をつけられたAttributeTypeのストリング表現が続いて、AttributeTypeAndValueはコード化されます。 セクション2.4でAttributeValueのコード化を与えます。
If the AttributeType is in a published table of attribute types associated with LDAP [4], then the type name string from that table is used, otherwise it is encoded as the dotted-decimal encoding of the AttributeType's OBJECT IDENTIFIER. The dotted-decimal notation is described in [3]. As an example, strings for a few of the attribute types frequently seen in RDNs include:
AttributeTypeがLDAP[4]に関連している属性タイプの発行されたテーブルにあるならそのテーブルからの型名ストリングが使用されている、さもなければ、それはAttributeTypeのOBJECT IDENTIFIERのドット付き10進法コード化としてコード化されます。 ドット付き10進法は[3]で説明されます。 例としての、RDNsの頻繁に見られる属性タイプのいくつかのストリングは:
Wahl, et. al. Proposed Standard [Page 3] RFC 2253 LADPv3 Distinguished Names December 1997
etウォール、アル。 提案された標準[3ページ]RFC2253LADPv3分類名1997年12月
String X.500 AttributeType
------------------------------
CN commonName
L localityName
ST stateOrProvinceName
O organizationName
OU organizationalUnitName
C countryName
STREET streetAddress
DC domainComponent
UID userid
ストリングX.500 AttributeType------------------------------ CN commonName L localityName ST stateOrProvinceName O organizationName OU organizationalUnitName C countryName通りstreetAddress DC domainComponent UIDユーザID
2.4. Converting an AttributeValue from ASN.1 to a String
2.4. ASN.1からストリングまでAttributeValueを変換します。
If the AttributeValue is of a type which does not have a string
representation defined for it, then it is simply encoded as an
octothorpe character ('#' ASCII 35) followed by the hexadecimal
representation of each of the bytes of the BER encoding of the X.500
AttributeValue. This form SHOULD be used if the AttributeType is of
the dotted-decimal form.
それのために定義されたストリング表現を持っていないタイプにAttributeValueがあるなら、シャープ記号キャラクタ('#'ASCII35)がそれぞれのX.500 AttributeValueのBERコード化のバイトの16進表現で後をつけて、それは単にコード化されます。 これはSHOULDを形成します。AttributeTypeが使用されるなら、ドット付き10進法フォームについて使用されてください。
Otherwise, if the AttributeValue is of a type which has a string representation, the value is converted first to a UTF-8 string according to its syntax specification (see for example section 6 of [4]).
さもなければ、値はストリング表現を持っているタイプにAttributeValueがあるなら構文仕様通りに最初に、UTF-8ストリングに変換されます。(例えば、セクション6の[4])を見てください。
If the UTF-8 string does not have any of the following characters which need escaping, then that string can be used as the string representation of the value.
UTF-8ストリングに逃げる必要がある以下のキャラクタのいずれもないなら、価値のストリング表現としてそのストリングを使用できます。
o a space or "#" character occurring at the beginning of the
string
o ストリングの始めに起こるスペースか「#」キャラクタ
o a space character occurring at the end of the string
o ストリングの端に起こる間隔文字
o one of the characters ",", "+", """, "\", "<", ">" or ";"
o または、「キャラクタのひとり」、」、「+」、「「「「\」、"<"">"、」、」、;、」
Implementations MAY escape other characters.
実装は他のキャラクタから逃げるかもしれません。
If a character to be escaped is one of the list shown above, then it
is prefixed by a backslash ('\' ASCII 92).
逃げられるべきキャラクタが上で見せられたリストの1つであるなら、バックスラッシュ('\'ASCII92)によってそれは前に置かれています。
Otherwise the character to be escaped is replaced by a backslash and two hex digits, which form a single byte in the code of the character.
さもなければ、逃げられるべきキャラクタをバックスラッシュと2十六進法ケタに取り替えます。(ケタはキャラクタのコードの1バイトを形成します)。
Examples of the escaping mechanism are shown in section 5.
エスケープメカニズムに関する例はセクション5で示されます。
Wahl, et. al. Proposed Standard [Page 4] RFC 2253 LADPv3 Distinguished Names December 1997
etウォール、アル。 提案された標準[4ページ]RFC2253LADPv3分類名1997年12月
3. Parsing a String back to a Distinguished Name
3. Distinguished NameにStringを分析して戻します。
The structure of the string is specified in a BNF grammar, based on the grammar defined in RFC 822 [5]. Server implementations parsing a DN string generated by an LDAPv2 client MUST also accept (and ignore) the variants given in section 4 of this document.
RFC822[5]で定義された文法に基づいてストリングの構造はBNF文法で指定されます。 また、DNストリングがLDAPv2クライアントで生成したサーバ実装構文解析が受け入れなければならない、(無視、)、このドキュメントのセクション4で与えられた異形。
distinguishedName = [name] ; may be empty string
distinguishedNameは[名前]と等しいです。 空のストリングであるかもしれません。
name = name-component *("," name-component)
名前=名前コンポーネント*(「」、名前コンポーネント)
name-component = attributeTypeAndValue *("+" attributeTypeAndValue)
名前コンポーネント=attributeTypeAndValue*(「+」 attributeTypeAndValue)
attributeTypeAndValue = attributeType "=" attributeValue
attributeTypeAndValue=attributeTypeはattributeValueと「等しいです」。
attributeType = (ALPHA 1*keychar) / oid keychar = ALPHA / DIGIT / "-"
attributeType=(アルファー1*keychar)/oid keycharはアルファー/ DIGIT /「-」と等しいです。
oid = 1*DIGIT *("." 1*DIGIT)
oidは1*DIGIT*と等しいです。(「. 」 1*ケタ、)
attributeValue = string
attributeValue=ストリング
string = *( stringchar / pair )
/ "#" hexstring
/ QUOTATION *( quotechar / pair ) QUOTATION ; only from v2
=*(stringchar/組)/「#」hexstring/引用*(quotechar/組)引用を結んでください。 単にv2から
quotechar = <any character except "\" or QUOTATION >
quotechar=<は「\」か引用>以外のあらゆるキャラクタです。
special = "," / "=" / "+" / "<" / ">" / "#" / ";"
」 「特別番組=」、/は「」 /「+」/"<"/">"/「#」/と等しい」;、」
pair = "\" ( special / "\" / QUOTATION / hexpair ) stringchar = <any character except one of special, "\" or QUOTATION >
組=「\」(特別番組/「\」/引用/hexpair)stringchar=<は特別番組、「\」または引用>の1つ以外のあらゆるキャラクタです。
hexstring = 1*hexpair hexpair = hexchar hexchar
hexstringは1*hexpair hexpair=hexchar hexcharと等しいです。
hexchar = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
/ "a" / "b" / "c" / "d" / "e" / "f"
DIGIT//「B」/「C」/「D」/「E」/「F」hexchar=/“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>
アルファーが<と等しい、どんなASCII英字>も。 (小数65-90と97-122) DIGITが<と等しい、どんなASCII10進数字>も。 (小数48-57) QUOTATIONが<と等しい、ASCIIは引用符キャラクタ'「'10進34>'」を倍にします。
Wahl, et. al. Proposed Standard [Page 5] RFC 2253 LADPv3 Distinguished Names December 1997
etウォール、アル。 提案された標準[5ページ]RFC2253LADPv3分類名1997年12月
4. Relationship with RFC 1779 and LDAPv2
4. RFC1779とLDAPv2との関係
The syntax given in this document is more restrictive than the syntax in RFC 1779. Implementations parsing a string generated by an LDAPv2 client MUST accept the syntax of RFC 1779. Implementations MUST NOT, however, generate any of the RFC 1779 encodings which are not described above in section 2.
本書では与えられた構文はRFC1779の構文より制限しています。 ストリングがLDAPv2クライアントで生成した実装構文解析はRFC1779の構文を受け入れなければなりません。 しかしながら、実装は上でセクション2で説明されないRFC1779encodingsのいずれも生成してはいけません。
Implementations MUST allow a semicolon character to be used instead of a comma to separate RDNs in a distinguished name, and MUST also allow whitespace characters to be present on either side of the comma or semicolon. The whitespace characters are ignored, and the semicolon replaced with a comma.
実装は、セミコロンキャラクタがコンマの代わりに分類名でRDNsを切り離すのに使用されるのを許容しなければならなくて、また、コンマかセミコロンのどちらの側にも空白キャラクタに出席しているのを許容しなければなりません。 空白キャラクタは、無視されていてコンマに取り替えられたセミコロンです。
Implementations MUST allow an oid in the attribute type to be prefixed by one of the character strings "oid." or "OID.".
実装は、属性タイプのoidが"oid" 文字列の1つ"OID"によって前に置かれるのを許容しなければなりません。
Implementations MUST allow for space (' ' ASCII 32) characters to be
present between name-component and ',', between attributeTypeAndValue
and '+', between attributeType and '=', and between '=' and
attributeValue. These space characters are ignored when parsing.
そして、実装が存在している宇宙(''ASCII32)キャラクタのために名前コンポーネントを許容しなければならない、'、'、attributeTypeAndValueと'+'の間でattributeTypeと'='と、'='とattributeValueの間で。 分析するとき、これらの間隔文字は無視されます。
Implementations MUST allow a value to be surrounded by quote ('"'
ASCII 34) characters, which are not part of the value. Inside the
quoted value, the following characters can occur without any
escaping:
実装が、値が引用文によって囲まれるのを許容しなければならない、('「'ASCII34) キャラクタ。'。」(キャラクタは価値の一部ではありません)。 引用された値の中では、以下のキャラクタは少しもエスケープなしで起こることができます:
",", "=", "+", "<", ">", "#" and ";"
そして、「「」、「=」、「+」、"<"">"「#」、」、;、」
5. Examples
5. 例
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つの相対的な分類名(RDNs)を含む名前があります:
CN=Steve Kille,O=Isode Limited,C=GB
CNはスティーブKille、O=Isode株式会社と等しく、CはGBと等しいです。
Here is an example name containing three RDNs, in which the first RDN is multi-valued:
ここに、最初のRDNがマルチ評価されている3RDNsを含んでいて、例の名があります:
OU=Sales+CN=J. Smith,O=Widget Inc.,C=US
OUは販売+CN=Jと等しいです。 スミス、Oはウィジェット株式会社と等しく、Cは米国と等しいです。
This example shows the method of quoting of a comma in an organization name:
この例は組織名のコンマについて以下を引用するメソッドを示しています。
CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB
CN=L。 ワシとスー\とGrabbitとRunn、C=O=GB
Wahl, et. al. Proposed Standard [Page 6] RFC 2253 LADPv3 Distinguished Names December 1997
etウォール、アル。 提案された標準[6ページ]RFC2253LADPv3分類名1997年12月
An example name in which a value contains a carriage return character:
値が復帰文字を含む例の名:
CN=Before%%BODY%%DAfter,O=Test,C=GB
テスト、%%BODY%%DAfter、Oの前のCN==CはGBと等しいです。
An example name in which an RDN was of an unrecognized type. The value is the BER encoding of an OCTET STRING containing two bytes 0x48 and 0x69.
認識されていないタイプにはRDNがあった例の名。 値は2バイト0×48と0x69を含むOCTET STRINGのBERコード化です。
1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB
○ = 1.3.6.1.4.1.1466.0は#04024869、と等しく、テスト、CはGBと等しいです。
Finally, an example of an RDN surname value consisting of 5 letters:
最終的に5個の手紙から成るRDN姓の価値に関する例:
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
ユニコードLetter記述10646コードUTF-8 Quoted=============================== ========== ====== ======= LATIN CAPITAL LETTER L U0000004C 0x4C L LATIN SMALL LETTER U U00000075 0×75u LATIN SMALL LETTER C WITH CARON U0000010D 0xC48D\C4円の8D LATIN SMALL LETTER I U00000069 0×69i LATIN SMALL LETTER C WITH ACUTE U00000107 0xC487円C4 87円
Could be written in printable ASCII (useful for debugging purposes):
印刷可能なASCII(デバッグ目的の役に立つ)に書くことができました:
SN=Lu\C4\8Di\C4\87
SNはLu\C4\8Di\C4と87円等しいです。
6. References
6. 参照
[1] The Directory -- overview of concepts, models and services.
ITU-T Rec. X.500(1993).
[1]、ディレクトリ--概念の、そして、モデルの、そして、サービスの概要。 ITU-T Rec。 X.500(1993)。
[2] The Directory -- Models. ITU-T Rec. X.501(1993).
[2]、ディレクトリ--モデル。 ITU-T Rec。 X.501(1993)。
[3] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[3] ウォール、M.、ハウズ、T.、およびS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル(v3)」、RFC2251 1997年12月。
[4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions",
RFC 2252, December 1997.
[4] ウォール、M.、Coulbeck、A.、ハウズ、T.、およびS.Kille、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「属性構文定義」、RFC2252、1997年12月。
[5] Crocker, D., "Standard of the Format of ARPA-Internet Text
Messages", STD 11, RFC 822, August 1982.
[5] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119.
[6] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119。
Wahl, et. al. Proposed Standard [Page 7] RFC 2253 LADPv3 Distinguished Names December 1997
etウォール、アル。 提案された標準[7ページ]RFC2253LADPv3分類名1997年12月
7. Security Considerations
7. セキュリティ問題
7.1. Disclosure
7.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:
顕著なNamesは彼らが命名するエントリーの描写的である情報から通常成ります。(人々、組織、デバイスまたはエントリーは他の本当の世界オブジェクトであるかもしれません)。 これは頻繁に情報の以下の数種類を含んでいます:
- 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アドレス--物理的な位置(国、場所、都市、住所)--組織的な属性(部の名か提携などの)
Most countries have privacy laws regarding the publication of information about people.
ほとんどの国には、人々の情報の公表に関するプライバシー法があります。
7.2. Use of Distinguished Names in Security Applications
7.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 or DER form. An example of a situation which requires the DER form of a distinguished name is the verification of an X.509 certificate.
X.501フォームからLDAPストリング表現までの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 of the PrintableString choice would have the same representation CN=Sam.
例えば、分類名が1AVAと共に1RDNから成って、'サム'という手紙がどれがあるタイプがcommonNameであり、値がTeletexString選択のものであるかで表されるだろうかはストリングCNとしてのLDAPでサムと等しいです。 値がそれでも、'サム'ですが、PrintableString選択について同じ表現CNを持っている別の分類名はサムと等しいです。
Applications which 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 octothorpe ('#')
as described in the first paragraph of section 2.4.
LDAP形式に分類名を変換するとき、値のSHOULD NOTのDER形式の再構成を必要とするアプリケーションが属性構文のストリング表現を使用します。 代わりにそれら、SHOULDはシャープ記号('#')によってセクション2.4の第一節で説明されるように前に置かれた16進フォームを使用します。
8. Authors' Addresses
8. 作者のアドレス
Mark Wahl Critical Angle Inc. 4815 W. Braker Lane #502-385 Austin, TX 78759 USA
マークウォール臨界角株式会社4815W.Braker Laneテキサス78759#502-385オースチン(米国)
EMail: M.Wahl@critical-angle.com
メール: M.Wahl@critical-angle.com
Wahl, et. al. Proposed Standard [Page 8] RFC 2253 LADPv3 Distinguished Names December 1997
etウォール、アル。 提案された標準[8ページ]RFC2253LADPv3分類名1997年12月
Steve Kille Isode Ltd. The Dome The Square Richmond, Surrey TW9 1DT England
スティーブ・Kille Isode株式会社ドームの正方形のリッチモンド、サリーTW9 1DTイギリス
Phone: +44-181-332-9091 EMail: S.Kille@ISODE.COM
以下に電話をしてください。 +44-181-332-9091 メールしてください: S.Kille@ISODE.COM
Tim Howes Netscape Communications Corp. 501 E. Middlefield Rd, MS MV068 Mountain View, CA 94043 USA
ティムハウズネットスケープ・コミュニケーションズ501E.Middlefield、MS MV068カリフォルニア94043第マウンテンビュー(米国)
Phone: +1 650 937-3419 EMail: howes@netscape.com
以下に電話をしてください。 +1 650 937-3419 メールしてください: howes@netscape.com
Wahl, et. al. Proposed Standard [Page 9] RFC 2253 LADPv3 Distinguished Names December 1997
etウォール、アル。 提案された標準[9ページ]RFC2253LADPv3分類名1997年12月
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Wahl, et. al. Proposed Standard [Page 10]
etウォール、アル。 提案された標準[10ページ]
一覧
スポンサーリンク
