RFC 4517 - Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules
- ステータス: Proposed Standard
- 発行日: June 2006
- ストリーム: IETF
- 更新: RFC3698
- 廃止: RFC2252, RFC2256
- エラッタ: エラッタなし
概要
Lightweight Directory Access Protocol (LDAP) ディレクトリに格納され、その値が LDAP プロトコルで転送される可能性のある各属性には、その値の構造と形式を制約する定義された構文があります。構文の値の比較セマンティクスは構文定義の一部ではなく、個別に定義されたマッチング規則を通じて提供されます。マッチング規則は、定義された構文も持つ引数、アサーション値を指定します。本文書は、LDAP ディレクトリの属性を定義する際に使用するための基本的な構文とマッチング規則のセットを定義します。
目次
- はじめに
- 表記法
- 構文 3.1. 一般的な考慮事項 3.2. 共通定義 3.3. 構文定義 3.3.1. 属性タイプ記述 (Attribute Type Description) 3.3.2. ビット列 (Bit String) 3.3.3. ブール値 (Boolean) 3.3.4. 国コード文字列 (Country String) 3.3.5. 配信方法 (Delivery Method) 3.3.6. ディレクトリ文字列 (Directory String) 3.3.7. DIT コンテンツ規則記述 (DIT Content Rule Description) 3.3.8. DIT 構造規則記述 (DIT Structure Rule Description) 3.3.9. DN 3.3.10. 拡張ガイド (Enhanced Guide) 3.3.11. ファクシミリ電話番号 (Facsimile Telephone Number) 3.3.12. FAX (Fax) 3.3.13. 一般化時刻 (Generalized Time) 3.3.14. ガイド (Guide) 3.3.15. IA5 文字列 (IA5 String) 3.3.16. 整数 (Integer) 3.3.17. JPEG 3.3.18. LDAP 構文記述 (LDAP Syntax Description) 3.3.19. マッチング規則記述 (Matching Rule Description) 3.3.20. マッチング規則使用記述 (Matching Rule Use Description) 3.3.21. 名前とオプションの UID (Name and Optional UID) 3.3.22. 名前形式記述 (Name Form Description) 3.3.23. 数値文字列 (Numeric String) 3.3.24. オブジェクトクラス記述 (Object Class Description) 3.3.25. オクテット列 (Octet String) 3.3.26. OID 3.3.27. その他のメールボックス (Other Mailbox) 3.3.28. 郵便住所 (Postal Address) 3.3.29. 印刷可能文字列 (Printable String) 3.3.30. 部分文字列アサーション (Substring Assertion) 3.3.31. 電話番号 (Telephone Number) 3.3.32. テレテックス端末識別子 (Teletex Terminal Identifier) 3.3.33. テレックス番号 (Telex Number) 3.3.34. UTC 時刻 (UTC Time)
- マッチング規則 4.1. 一般的な考慮事項 4.2. マッチング規則定義
- セキュリティに関する考慮事項
- 謝辞
- IANA に関する考慮事項
- 参考文献 付録 A. 構文オブジェクト識別子の概要 付録 B. RFC 2252 からの変更点
1. はじめに
Lightweight Directory Access Protocol (LDAP) ディレクトリ [RFC4510] に格納され、その値が LDAP プロトコル [RFC4511] で転送される可能性のある各属性には、その値の構造と形式を制約する定義された構文(つまりデータ型)があります。構文の値の比較セマンティクスは構文定義の一部ではなく、個別に定義されたマッチング規則を通じて提供されます。マッチング規則は、定義された構文も持つ引数、アサーション値を指定します。本文書は、LDAP ディレクトリの属性を定義する際に使用するための基本的な構文とマッチング規則のセットを定義します。
読者は、本文書の残りの部分を読む前に、ディレクトリ情報モデル [RFC4512] に精通することをお勧めします。第 3 節では、LDAP 構文の基本セットの定義を提供します。第 4 節では、LDAP のマッチング規則の基本セットの定義を提供します。
本文書は、LDAP 技術仕様 [RFC4510] の不可欠な部分であり、以前に定義された LDAP 技術仕様である RFC 3377 を全体として廃止します。
RFC 2252 の第 4、5、7 節は [RFC4512] によって廃止されます。RFC 2252 の残りの部分は本文書によって廃止されます。RFC 2256 の第 6、8 節は本文書によって廃止されます。RFC 2256 の残りの部分は [RFC4519] および [RFC4512] によって廃止されます。RFC 3698 の第 2.11 節を除くすべてが本文書によって廃止されます。
LDAP 技術仕様の以前の改訂に含まれていたいくつかのスキーマ要素は、LDAP のこの改訂には含まれていません。公開鍵インフラストラクチャスキーマ要素は現在 [RFC4523] で指定されています。将来の技術仕様で再導入されない限り、残りの部分は歴史的なものと見なされます。
RFC 2252 に関する変更点は、本文書の付録 B に記載されています。
2. 表記法
本文書では、キーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は、BCP 14, RFC 2119 [RFC2119] で説明されているように解釈されます。
3. 構文
構文定義は、LDAP ディレクトリに格納される属性値の構造を制約し、LDAP プロトコルで転送される属性およびアサーション値の表現を決定します。
本節では、ディレクトリ操作に必要な、または一般的に使用される構文を指定します。サーバーは、本文書に記載されているすべての構文を認識すべきですが (SHOULD)、それらをサポートすることは必須ではなく、他の構文を認識またはサポートしてもかまいません (MAY)。ただし、相互運用性を妨げるため、追加の任意の構文の定義は推奨されません。クライアントおよびサーバーの実装は通常、新しい構文を動的に認識する機能を備えていません。
3.1. 一般的な考慮事項
各構文の説明では、構文に準拠する属性またはアサーション値が LDAP プロトコル [RFC4511] で転送されるときにどのように表現されるかを指定します。この表現は、属性値をエンコードする他の方法(たとえば、X.500 [X.500] ディレクトリで使用される基本エンコード規則 (BER) エンコード [BER])と区別するために、LDAP 固有のエンコードと呼ばれます。
3.2. 共通定義
以下の ABNF 規則は、第 3.3 節の多くの構文定義で使用されます。
PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
PLUS / COMMA / HYPHEN / DOT / EQUALS /
SLASH / COLON / QUESTION / SPACE
PrintableString = 1*PrintableCharacter
IA5String = *(%x00-7F)
SLASH = %x2F ; forward slash ("/")
COLON = %x3A ; colon (":")
QUESTION = %x3F ; question mark ("?")
3.3. 構文定義
(具体的な構文の詳細な定義はここでは省略します。原文を参照してください。)
4. マッチング規則
マッチング規則は、属性値とアサーション値を比較するためのアルゴリズムを定義します。
4.1. 一般的な考慮事項
各マッチング規則は、オブジェクト識別子 [ASN.1] によって一意に識別されます。本文書で定義されているマッチング規則には、短い名前(記述子)もあります。
マッチング規則の定義は、比較されるアサーション値の構文を指定します。属性値の構文は指定されていませんが、アサーション値の構文と互換性がなければなりません。
4.2. マッチング規則定義
(具体的なマッチング規則の詳細な定義はここでは省略します。原文を参照してください。)
5. セキュリティに関する考慮事項
本文書で定義されている多くの構文には、バイナリデータまたは特定の形式の文字列が含まれます。これらの値を誤って解析または処理すると、バッファオーバーフローなどのセキュリティ上の脆弱性につながる可能性があります。実装者は、すべての構文を堅牢に処理するように注意する必要があります。
マッチング規則の複雑さはさまざまです。一部(部分文字列マッチングなど)は計算コストが高い場合があります。サーバーは、検索の時間やリソースの使用を制限するなど、サービス拒否攻撃を防ぐための対策を講じるべきです。
6. 謝辞
(原文参照)
7. IANA に関する考慮事項
(原文参照)
8. 参考文献
(原文参照)