English

インターネットX.509 PKIおよびCRLプロファイルにおけるDirectoryString処理についての更新
(Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile)

このメモの位置づけ

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

著作権表記

Copyright (C) The Internet Society (2006).

要旨

本書は、 RFC 3280において発行されているインターネットX.509 PKIおよびCRLプロファイル中のDirectoryStringの扱いについて更新する。 UTF8StringおよびPrintableStringの利用は、 優先されるエンコーディングである。 2003年12月31日翌日以降のUTF8Stringの排他的な利用についての要件は、 削除される。

目次

1. 1. はじめに
2. 2. 用語法
3. 3. RFC 3280 4.1.2.4節 Issuerの更新
4. 4. RFC 3280 4.1.2.6節 Subjectの更新
5. 5. RFC 3280 4.2.1.7節 Subject Alternative Nameの更新
6. 6. セキュリティについての考慮事項
7. 7. 規範的参考文献

1. はじめに English

RFC 3280 [PKIX1] が発行された当時、 「どのように国際的なキャラクタセットがサポートされるべきか？」は、 とても不明確であった。 実装の試みや開発実践は、この構図の曖昧さを減らした。 このRFC 3280に対する更新は、この試みに基づく文書、 およびIETF PKIX WGの方向性に整合するものである。

UTF8StringおよびPrintableStringの利用は、 優先されるエンコーディングである。 UTF8Stringは、 国際的なキャラクタセットについてのサポートを提供し、 PrintableStringは、 既に配備された莫大な数の証明書についてのサポートを保持する。

2. 用語法 English

本書中のキーワード"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY"および"OPTIONAL"は、 RFC 2119 [STDWORDS] に規定されているように解釈されるべきものである。

3. RFC 3280 4.1.2.4節 Issuerの更新 English

RFC 3280の4.2.1.4節には下記のように書かれている。：

DirectoryString typeは、「PrintableString, TeletexString, BMPString, UTF8String, およびUniversalStringから選択」として規定されている。 UTF8Stringエンコーディング [RFC 2279] は、 選好されるエンコードであり、 2003年12月31日翌日以降に発行されるすべての証明書は、 (下記に示したことを除いて)DirectoryStringのUTF8Stringエンコーディングを使わなければならない(MUST)。 その日までに、準拠するCAは、 自身のDN (distinguished name)を含めてDNを作るとき、 下記の選択肢から選択しなければならない(MUST)。：

1. PrintableStringのキャラクタセットで十分な場合、 その文字列は、PrintableStringとして表現できる(MAY)。
2. a. で不足の場合、BMPStringキャラクタセットで十分な場合、 その文字列は、BMPStringとして表現できる(MAY)。
3. a. およびb. で不足の場合でも、その文字列は、 UTF8Stringとして表現されなければならない(MUST)。
   a. もしくはb. が満たされる場合でも、そのCAは、 その文字列をUTF8Stringとして表現することを選択できる(MAY)。

2003年12月31日翌日以降のUTF8エンコーディング要件についての例外は、 下記のとおり。：

1. CAは、 UTF8Stringエンコーディングへの秩序的な移行をサポートするために、 「名前ロールオーバー(name rollover)」証明書を発行できる(MAY)。
   このような証明書は、 そのCAのUTF8Stringでエンノードされた名前を発行者として、 名前の古いエンコーディングをサブジェクトとして含む。 あるいは、その逆となる。
2. 4.1.2.6節において述べたように、 サブジェクトのフィールドは、 エンコーディングに関わらず、 当該CAによって発行された、 すべての証明書中の発行者のフィールドの内容と一致する、 空でないDNで埋められなければならない(MUST)。

TeletexStringおよびUniversalStringは、 後方互換性のために含められており、 新しいサブジェクト用の証明書については、 使ってはいけない(SHOULD NOT)。 しかし、これらの種類は、 その名前が従前に確立していた証明書において使うことができる(MAY)。 証明書ユーザは、 これらの種類でエンコードされた証明書を受け取るために備える必要がある(SHOULD)。

さらに、多くの旧式(legacy)な実装は、 ISO 8859-1キャラクタセット(Latin1String) [ISO 8859-1] にエンコードさえれた名前をサポートしているが、 それらをTeletexStringとしてタグづけする。 TeletexStringは、 ISO 8859-1よりも大きいキャラクタセットをエンコードするが、 これは、いくつかのキャラクタを異なるようにエンコードする。 実装は、 両方のエンコードを扱うのに備える必要がある(SHOULD)。

この段落は、下記のものと置き換えられる。：

DirectoryStringの種類は、「PrintableString, TeletexString, BMPString, UTF8String, and UniversalStringから選択」として規定されている。 このプロファイルに適合するCAは、ひとつの例外はあるが、 DirectoryStringのPrintableStringか、 あるいはUTF8String encodingのいずれかを使わなければならない(MUST)。 CAが以前に、発行者のフィールドがTeletexString, BMPStringもしくはUniversalStringを使ってエンコードされた属性をもつ証明書を発行したことがあるとき、 そのCAは、後方互換性を確保するために、 DirectoryStringのこれらのエンコーディングを使い続けることができる(MAY)。

4. RFC 3280 4.1.2.6節 Subjectの更新 English

RFC 3280 の 4.2.1.6 節には下記のように書かれている。：

サブジェクト名のフィールドは、X.501 type Nameとして規定されている。 このフィールドについての実装要件は、 発行者のフィールド(4.1.2.4 節)について規定されているものである。 DirectoryString型の値をエンコードするとき、 発行者フィールドについてのエンコーディングルールが、 実装されなければならない(MUST)。

この段落は、下記のものと置き換えられる。：

サブジェクト名のフィールドは、X.501型のNameとして規定される。 このフィールドについての実装要件は、 発行者のフィールド(4.1.2.4節)について規定されているものである。 このプロファイルに準拠するCAは、ひとつの例外はあるが、 DirectoryStringのPrintableStringか、 あるいはUTF8Stringのいずれかのエンコーディングを使わなければならない(MUST)。 CAが以前にサブジェクトのフィールドがTeletexString, BMPStringもしくはUniversalStringを使ってエンコードされた属性をもつ証明書を発行していたとき、 そのCAは、後方互換性を確保するために、 DirectoryStringのこれらのエンコーディングを、 その同じサブジェクト用の新しい証明書中に使い続けることができる(MAY)。

名前の比較は、 「異なる型(例：PrintableStringおよびUTF8String)でエンコードがなされた属性の値は、 異なる文字列を表現する」と想定しているので、 サブジェクトのフィールドおよび発行者のフィールドの両方にある、 あらゆる名前コンポーネントは、 認証パスを通じて同一のエンコーディングを使う必要がある(SHOULD)。

5. RFC 3280 4.2.1.7節 Subject Alternative Nameの更新 English

RFC 3280の4.2.1.7節には下記のように書かれている。：

subjectAltName拡張がDNをdirectoryName中にを含むとき、 そのDNは、発行者名前フィールドによって定義されるように、 ひとつのCAによって認定された各サブジェクトのエントリについて、 一意でなければならない(MUST)。 CAは、同一のサブジェクト主体宛てに、 同一のDNをもつ複数の証明書を発行できる(MAY)。

この段落は、下記のものと置き換えられる。：

subjectAltName extensionがDNをdirectoryName中に含むとき、 そのエンコーディングの優先度については、 4.1.2.4節に規定されている。 そのDNは、発行者名前フィールドによって定義されるように、 ひとつのCAによって認定された各サブジェクトのエントリについて、 一意でなければならない(MUST)。 CAは、同一のサブジェクト主体宛てに、 同一のDNをもつ複数の証明書を発行できる(MAY)。

6. セキュリティについての考慮事項 English

名前コンポーネントについて、 整合性あるエンコーディングの利用によって、 「[PKIX1] に規定された名前制約が期待されるように機能すること」が確保される。

文字列が国際的な表現(internal representation)から可視表現(visual representation)にマップされるとき、しばしば、 2つの異なる文字列は、 同一もしくは同様の可視表現(visual representation)をもつ。 これは、同様の象形文字(glyph)の利用や、 合成されたキャラクタの利用を含む多くの原因によって起こる可能性がある。 (例：e +'(U+00E9)や韓国語の合成文字、 特定の言語における子音群の上の母音が挙げられる。) この状況の結果として、 異なる名前間の可視的な比較を行っている人々は、「それらは、 実際には異なるときに同一となる」と考える可能性がある。 また、人々は、ある文字列を別のものと間違える可能性がある。 証明書の発行者と利用者(relying party)の両方は、この状況を認識しておく必要がある。

7. 規範的参考文献

著者のアドレス

Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
USA

EMail： housley＠vigilsec.com

Stefan Santesson
Microsoft
Tuborg Boulevard 12
2900 Hellerup
Denmark

EMail： stefans＠microsoft.com

翻訳者のアドレス

宮川 寧夫
独立行政法人 情報処理推進機構
セキュリティセンター

EMail： miyakawa＠ipa.go.jp

著作権表記全文

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.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

知的財産権

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.

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 http://www.ietf.org/ipr.

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-ipr@ietf.org.

謝辞

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