ネットワーク WG
Request for Comments: 4630
更新: 3280
分類: Standards Track

 R. Housley
Vigil Security
S. Santesson
Microsoft
2006年 8月

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. はじめに
2. 用語法
3. RFC 3280 4.1.2.4 節 Issuer の更新
4. RFC 3280 4.1.2.6 節 Subject の更新
5. RFC 3280 4.2.1.7 節 Subject Alternative Name の更新
6. セキュリティについての考慮事項
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)。:

(a)  PrintableString のキャラクタセットで十分な場合、その文字列は、PrintableString として表現できる(MAY)
(b)  (a) で不足の場合、BMPStringキャラクタセットで十分な場合、その文字列は、BMPString として表現できる(MAY)
(c) 

(a) および (b) で不足の場合でも、その文字列は、UTF8String として表現されなければならない(MUST)

(a) もしくは (b) が満たされる場合でも、その CA は、その文字列を UTF8String として表現することを選択できる(MAY)


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

(a) 

CA は、UTF8String エンコーディングへの秩序的な移行をサポートするために、「名前ロールオーバー(name rollover)」証明書を 発行できる(MAY)

このような証明書は、その CA の UTF8String でエンノードされた名前を発行者として、名前の古いエンコーディングをサブジェクトとして含む。あるいは、その逆となる。

(b) 

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.  規範的参考文献

 [PKIX1]     Housley, R., Polk, W., Ford, W., and D. Solo,
"Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile",
RFC 3280, 2002 4月.
 
 [STDWORDS] Bradner, S.,
"Key words for use in RFCs to Indicate Requirement Levels",
BCP 14, RFC 2119, 1997年 3月.


著者のアドレス

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).