報告書 - IPA 独立行政法人 情報処理推進機構

2004 情財第 845 号
PKI における UTF8String 問題に関する調査 報告書
Part1: UTF8String 問題の解説と提言
2005 年 3 月
登録商標等について
•
•
•
•
Microsoft、MS、Windows、Windows 2000、Windows NT、Windows
XP、Windows ロゴ、Internet Explorer、Outlook、Outlook Express
などは、米国 Microsoft Corporation の米国およびその他の国におけ
る登録商標または商標である。
Sun Microsystems、Sun ロゴ、Java コーヒーカップロゴ、Solaris、
Java、JDK などは、米国 Sun Microsystems の米国およびその他の
国における登録商標または商標である。
その他、本文小児記載されている会社名、商品名、製品名などは、一
般に各社の商標または登録商標である。
本書では、™、Ⓒ、Ⓡなどを記載しない
目次
1
2
3
語句の定義と解説............................................................................................................... - 1 1.1
語句の定義 .................................................................................................................. - 1 -
1.2
UTF8String とは ........................................................................................................ - 2 -
1.3
ASCII 共通部分........................................................................................................... - 2 -
1.4
PrintableString と UTF8String................................................................................. - 3 -
UTF8String 問題の概要 .................................................................................................... - 4 2.1
RFC 3280 における移行要件の記述 ........................................................................... - 4 -
2.2
UTF8String 問題への対応.......................................................................................... - 5 -
基礎知識編(文字コード・PKI) ........................................................................................... - 6 3.1
3.1.1
文字列処理概要 .................................................................................................... - 6 -
3.1.2
文字列の正規化 .................................................................................................... - 7 -
3.1.3
Stringprep ........................................................................................................... - 8 -
3.1.4
文字列比較 ........................................................................................................... - 9 -
3.2
4
5
PKI 基礎知識 .............................................................................................................- 11 -
3.2.1
PKI の信用モデルと識別名比較..........................................................................- 11 -
3.2.2
ASN.1 におけるエンコード ............................................................................... - 12 -
3.2.3
識別名の複雑なエンコード ................................................................................ - 15 -
UTF8String 問題 ............................................................................................................. - 16 4.1
曖昧な文字列比較要件 .............................................................................................. - 16 -
4.2
UTF8String 環境への移行........................................................................................ - 17 -
UTF8String 問題の影響 .................................................................................................. - 19 5.1
UTF8String 問題の影響 実装編............................................................................... - 20 -
5.1.1
異なるエンコード方式同士の文字列比較........................................................... - 20 -
5.1.2
証明書の検索と認証パスの検証 ......................................................................... - 21 -
5.1.3
外部アプリケーションとの文字列の受け渡し.................................................... - 23 -
5.2
6
文字コード基礎知識 .................................................................................................... - 6 -
UTF8String 問題の影響 運用編............................................................................... - 24 -
5.2.1
証明書発行要求のエンコード方式 ..................................................................... - 24 -
5.2.2
CA 証明書の移行(更新と再発行)........................................................................ - 26 -
5.2.3
CA 証明書の移行と失効検証.............................................................................. - 29 -
UTF8String 問題に関する提言........................................................................................ - 30 6.1
UTF8String 問題解決のための要件 ......................................................................... - 30 -
6.2
各組織に対する提言 .................................................................................................. - 31 -
6.3
PKIX WG への提言................................................................................................... - 32 -
6.3.1
文字列比較要件の追加定義 ................................................................................ - 32 -
6.3.2
3280bis で触れられていない問題 ...................................................................... - 32 i
参考文献 .................................................................................................................................. - 34 規範的参考文献.................................................................................................................... - 34 参考資料............................................................................................................................... - 34 -
ii
図表番号
表 1-1 ASCII...................................................................................................................... - 3 表 3-1 正規化すべき文字（列）........................................................................................ - 7 表 3-2 比較規則と比較対象の組み合わせ ....................................................................... - 10 表 5-1 異なるエンコード方式の比較............................................................................... - 20 図 3-1 文字列処理の一例 .................................................................................................. - 7 図 3-2 比較規則、正規化による処理方法の違い............................................................... - 8 図 3-3 Unicode における文字列表現 ................................................................................. - 9 図 3-4 文字列比較の対象 ................................................................................................ - 10 図 3-5 PKI の信用モデルと DN....................................................................................... - 12 図 3-6 証明書における文字列表現 .................................................................................. - 13 図 3-7 ASN.1(DER)におけるエンコード......................................................................... - 14 図 3-8 バイト列比較における比較対象 ........................................................................... - 15 図 3-9 RDN 毎に異なるエンコード方式.......................................................................... - 15 図 5-1 異なるエンコード方式の文字列をコードポイント比較 ....................................... - 21 図 5-2 外部アプリケーションとの文字列の受け渡し...................................................... - 23 図 5-3 CSR と証明書のエンコード方式が異なる場合 ..................................................... - 25 図 5-4 自己署名証明書を更新する場合 ........................................................................... - 27 図 5-5 下位 CA 証明書を更新する場合 ........................................................................... - 27 図 5-6 自己署名証明書を再発行する場合 ....................................................................... - 28 図 5-7 下位 CA 証明書を再発行する場合........................................................................ - 28 -
iii
1 語句の定義と解説
UTF8String 問題を議論するには、文字コードに対する理解が不可欠である。本
報告書では、文字コードの専門家でなくても理解できるよう平易な解説を心がけ
るが、理解を助けるために必要最小限の語句について定義を示すとともに簡単な
解説を以下に記す。
1.1 語句の定義
① 文字
英数字や各言語文字の他、制御記号なども含まれる。
A ,
u , <DEL>など
② 文字列
文字の並び。
③ 文字セット、文字コード
ある規則に従って定義された文字の集合。
多くの場合、それぞれの文字に対応するコードポイントも同時に定義する
ため、ここでは[文字コード]と[文字セット]はほぼ同義に扱う。
ASCII、JIS X2013、Unicode(ISO 10646 など)
④ コードポイント
文字(列)をコンピュータが処理するために、文字に一意な(マッピングされ
た)数値。文字コード毎に定められる。
Unicode の場合、 A なら U+0041、 <DEL> なら U+007F など
⑤ コードポイント列
コードポイントの並び。
ほとんどの場合「列」をつけずに混用することが多い。
⑥ 正規化
論理的に同等の文字列を、コードポイントレベルで完全に一致させるため
の作業。具体的には、文字列をあるテーブルに沿って合成し文字に変換する
こと。または文字をあるテーブルに沿って分解し、文字列に変換すること。
u¨ → u など。
⑦ エンコード
-1-
コードポイント(列)からバイト列へ、ある(エンコード)方式に沿って変換す
ること。
⑧ デコード
バイト列からコードポイント(列)へ、ある(エンコード)方式に沿って変換す
ること。
⑨ エンコード方式
コードポイント(列)からバイト列へ変換する規則。文字コードや文字セット
に依存している場合が多い。
PrintableString、UTF8String など。
⑩ バイト列
コードポイント(列)を出力する際の値。
異なる処理との間でデータを入出力するために用いる。コードポイント(列)
が同じでもバイト列へのエンコード方式が異なれば、バイト列は異なる値に
なる。
1.2 UTF8String とは
'UTF8String'とは、X.509[1] のデータ構造を定義する言語 ASN.11[2] で定義さ
れる文字列型であり、Unicode コンソーシアム2が定義した文字セット UCS3[3] を
UTF-84というエンコード方式に従ってエンコードして格納するものである。
UCS は、Unicode コンソーシアムが世界中の文字を一意に示すことを目的とし
て開発した文字コードであり、ISO/IEC 10646-1[3] として標準化されている。
UTF-8 は、この ISO/IEC 10646-1 に対するエンコード方式の一つであり、
ISO/IEC 646[4] と完全互換性を持つ。
IETF5においても UTF-8 は RFC 3629[5] によって、今後の文字コード標準の一
つとして採用されており、証明書に限らず様々な分野で適用されていくものと考
えられる。
1.3 ASCII 共通部分
ASCII6は、ISO/IEC 646[4] として定められた文字コードである。
1
2
3
4
5
6
Abstract Syntax Notation One
http://www.unicode.org/
Unicode Character Set
UCS Transformation 8
Internet Engineering Task Force, http://www.ietf.org/
American Standard Code for Information Interchange
-2-
ASCII は、いわゆる半角英数記号や制御文字等が定義されており、これらを全
て 7bit で表現できることが大きな特徴である。
表 1-1 ASCII
上位3bit
下位4bit
0
1
2
3
4
5
6
7
8
9
A
B
C
D
E
F
0
NUL
SOH
STX
ETX
EOT
ENQ
ACK
BEL
BS
HT
LF
VT
FF
CR
SO
SI
1
2
DLE SPC
DC1
!
DC2
"
DC3 #
DC4 $
NAK %
SYN &
ETB
'
CAN
(
EM
)
SUB
*
ESC +
FS
,
GS
RS
.
US
/
3
4
5
6
7
0
1
2
3
4
5
6
7
8
9
:
;
<
=
>
?
@
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
X
Y
Z
[
\
]
^
_
`
a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
p
q
r
s
t
u
v
w
x
y
z
{
|
}
~
DEL
制御文字
非互換文字
その後 ASCII を拡張する形で様々な文字コードが存在しており、現在 ASCII の
文字セットの中で確実に互換性が保証されているのは表 1-1 のうち無色のセルの
みである。これを本文では便宜上''ASCII 共通部分''と呼ぶことにする。
UTF-8 は、既に広く互換性のある ASCII 共通部分に着目し、これらについて互
換性を維持できるよう設計されたエンコード方式である。
このため、UTF-8 でも他の ASCII をベースとしたエンコード方式でも同等に扱
うことができるのが、ASCII 共通部分の大きな特徴である。
1.4 PrintableString と UTF8String
RFC 3280[6] では、ASCII に相当する領域の互換性を意識したエンコード方式
として PrintableString が定義されている。類似するエンコード方式として
IA5String があるが、これは URI を表記することを目的としたものであり、その
ために一部 ASCII 共通部分以外の文字(‘@’や’$’など)を取り込んでいる。このため
-3-
IA5String は URI を表記するフィールドに限定的に使用され、一般的な
directoryName には PrintableString が用いられることが多かった。
PrintableString は、UTF8String に比べて利用できる文字種が半角英数字と一
部の記号のみに限定されるため、利便性は低くなるものの互換性に優れており、
多くの証明書で利用されている。
一方で、UTF-8 が ASCII 共通部分について互換性を持っていることにより
UTF8String も PrintableString に対して互換性を持っている。
このため将来 UTF8String への移行を見据えた CA などでは、PrintableString
を採用しているものが多く、一方で既に UTF8String を用いている CA であって
も相互運用性のために、実際に利用している文字セットを ASCII 共通部分のみに
限定している例も多く見られる。
2 UTF8String 問題の概要
この章では、本調査研究の対象となっている UTF8String 問題について概要を
述べる。
2.1 RFC 3280 における移行要件の記述
PKI の公開鍵証明書 X.509[1] に関してインターネットにおける標準文書である
RFC 3280[6] には、以下のような記述が存在する。
4.1.2.4
Issuer
(中略)
The DirectoryString type is defined as a choice of PrintableString,
TeletexString, BMPString, UTF8String, and UniversalString. The
UTF8String encoding [RFC 2279] is the preferred encoding, and all
certificates issued after December 31, 2003 MUST use the UTF8String
encoding of DirectoryString (except as noted below). Until that
date, conforming CAs MUST choose from the following options when
creating a distinguished name, including their own:
(a) if the character set is sufficient, the string MAY be
represented as a PrintableString;
(b) failing (a), if the BMPString character set is sufficient the
string MAY be represented as a BMPString; and
-4-
(c) failing (a) and (b), the string MUST be represented as a
UTF8String. If (a) or (b) is satisfied, the CA MAY still choose
to represent the string as a UTF8String.
現在発行されている証明書において、DirectoryString として UTF8String を選
択している例は一部を除いてそれほど多くなく、大半は PrintableString や
TeletexString、BMPString などを用いてきた。一方、IETF では 1.2 節で述べた
ように UTF-8 を文字コード標準の一つとして挙げており、UTF-8 への移行を推進
するよう働きかけている。このため、RFC 3280 においても期限を切って
UTF8String への移行を促している。
上記の移行要件は、RFC 3280 の前身である RFC 2459 から既に記述されていた
もので、移行期限間近(平成 14 年 4 月)に公開された RFC 3280 では、移行期限に
ついて再検討される可能性も予想されていた。しかし、IETF として UTF-8 への
移行を推進するモチベーションが高かったことと、RFC 2459 から RFC 3280 への
修正箇所が多岐にわたっていたなどの理由から、移行期限について再検討される
ことなく、そのまま転記されることとなった。
これにより、RFC 3280 公開時には、UTF8String への移行期限が既に残り 1 年
8 ヶ月という状態になってしまった。
UTF8String 問題は移行期限だけにあるのではなく、移行時の仕様の曖昧さにも
起因している。具体的な内容については 4 章にて後述するが、移行手順や証明書
識別名(DN)の比較方法、アプリケーションの実装状況とのギャップなどである。
実際、多くのベンダは移行期限の問題よりも、移行時の仕様の曖昧さによる移
行や移行後の混乱を避けるために、移行をためらっていたのではないかと考えら
れる。
2.2 UTF8String 問題への対応
(a) IPA セキュリティセンタの対応
RFC 3280 で設定された移行期限である平成 15 年 12 月 31 日を前に控えた
12 月 3 日に、IPA7から注意喚起「RFC 3280 の UTF8String 問題について」
[7] が発表された。
これによると、移行期限を間近に控えての混乱を避けるために、RFC 3280
への準拠性よりも以下について優先すべき、との見解を示した。
− 当面は従来のエンコード方式を使い続けるべき
− アプリケーションの対応状況を把握すべき
独立行政法人 情報処理推進機構(Information-Technology Promotion Agency, Japan),
http://www.ipa.go.jp/
7
-5-
(b) PKIX WG の対応
IETF の PKIX WG8では移行期限である平成 15 年末が近づくに連れて、い
くつか UTF8String 問題についての話題が上がった。以下にそのポイントを
示す。
•
UTF-8 への移行は大きな問題であり、真剣に取り組む必要がある。
•
UTF-8 への移行期限として平成 15 年末というのは難しいだろう。
•
移行期限は別として、UTF-8 へ移行することは間違いない。
•
理想としてはバイナリ比較である。
そしてこれらの議論を受けて、移行期限直前の 2003 年 11 月に開催された
第 58 回 IETF 会合では、以下のような声明が発表された。
(イ) LDAP に関する仕様の改訂
(ロ) 名前比較規則に関する仕様の提案
(ハ) 3280bis への着手
このうち、(ロ)については現在 Internet-Draft が公開されているものの、
最終的には(ハ)に内容を統合することが決まったようである。ちなみに(ハ)は
2004 年 12 月下旬に公開される予定であったが 2005 年 1 月末現在まだ公開
されていない。9
3 基礎知識編(文字コード・PKI)
この章では、UTF8String 問題を議論していく上で必要となる基礎知識として、
文字コードと PKI それぞれに関して個別に解説を行う。本書では、必ずしもこの
章を読まなくても問題の概要については理解できるよう努めているが、PKI ベン
ダ、アプリケーションベンダにおいては精読願いたい。
3.1 文字コード基礎知識
本節では、文字列がどのようにシステム内部で処理されるのか文字コードとの
関係を含めて簡単に説明する。
3.1.1 文字列処理概要
ここでは典型的な例として、人間が入力した文字が、システムの中でどのよう
に表現され、どのように処理されていくのか観察してみる。
Public Key Infrastructure X.509 Working Group,
http://www.ietf.org/html.charters/pkix-charter.html
9 その後 2005 年 2 月 17 日に、
以下の URL で限定的にドラフト 3280bis[10] が公開されている。
http://csrc.nist.gov/pki/documents/PKIX/draft-ietf-pkix-rfc3280bis-00.txt
8
-6-
これは’A’だね。
(human readable)
文字
‘A’
Character
これは’A’だね。
(processable)
入力
コードポイント
Code point
これは’A’だね。
(machine readable)
‘0x41’
他のシステムとデータ交換する
にはバイト列へエンコードする
必要がある。
エンコード
バイト列
Byte sequences
‘???’
‘???’
図 3-1 文字列処理の一例
人間が扱うものは可読性のある文字列であり、これはシステムへ入力される過
程でコードポイントにマッピングされる。システムでは文字列をコードポイント
(列)として扱い、処理が終わるとバイト列という形式にエンコードして出力・管理
する。
エンコードされたバイト列は、他のシステムや処理へ文字列を受け渡しするた
めに用いられる。
このため、エンコード方式が異なる場合は、例え文字列が一緒でもバイト列は
異なるものになるので注意が必要である。
3.1.2 文字列の正規化
文字列は、システムへ入力される過程でコードポイントにマッピングされるが、
コードポイントと文字は必ずしも 1 対 1 であるとは限らない。
例えば人間にとっては区別する必要のない情報(全角・半角、空白文字の連続、
濁音の合成・分解、英文字の大小など)も、コードポイントレベルでは区別して扱
われる。
表 3-1 正規化すべき文字（列）
旧字体と新字体 半角と全角 分解濁点と合成濁点
“神” と ”神” “A” と “Ａ”
“は゜” と “ぱ”
このため、意味論的に同等な文字列をコードポイントレベルで一致させる作業
が必要となる。これを文字列の正規化(Normalization)という。
-7-
UTF8String で使われている ISO/IEC 10646-1 では、文字列を正規化した形と
して 4 種類の正規形を定義している。
•
•
•
•
NFC: 正規合成 Normalization form C(Composition)
NFD: 正規分解 Normalization form D(Decomposition)
NFKC: 正規互換合成 Normalization form KC
NFKD: 正規互換分解 Normalization form KD
3.1.3 Stringprep
ISO/IEC 10646-1 が定義しているのは正規形までだが、実際の様々な文字列処
理を行う上では正規化だけでは不十分であり、IETF では Unicode 文字列に対する
前処理として、stringprep(RFC 3454)[8] を策定している。
stringprep では、文字列の入力や比較といった処理のために以下の 4 工程を定
義している。
(イ)
(ロ)
(ハ)
(ニ)
マッピング
正規化
出力禁止文字の処理
bidi10の処理
(イ)では、stringprep 後に適用する比較規則や(ロ)で適用する正規形によって、
異なるマッピングが行われる。
stringprep がサポートする比較規則と正規形はそれぞれ以下の通りである。
•
•
比較規則: case-sensitive または case-insensitive
正規形: NFKC または 正規形なし
このため、(イ)、(ロ)の工程に対して計 4 種類の異なる処理方法がある。
比較規則
正規化
Case-sensitive
NFKC
正規化しない
Case-insensitive
NFKC
正規化しない
図 3-2 比較規則、正規化による処理方法の違い
bi-directional string: アラビア文字やヘブライ文字など右から左へ読むこともある文字のこ
と。
10
-8-
これに対して(ハ)、(ニ)はどのような比較規則・正規形に対しても同様の処理を
行うものである。
3.1.4 文字列比較
stringprep を用いる場合、文字列比較処理は図 3-3 のように 3 つの対象に分け
て考えることができる。このうち文字列そのものの比較は人間によって行われる
ものなので、ここではコードポイント比較とバイト列比較に注目して考えてみる。
文字
Character
‘A’
入力
未処理
コードポイント
‘0x41’
stringprep
処理済
コードポイント
‘0x41’
エンコード
バイト列
Byte sequences
‘???’
図 3-3 Unicode における文字列表現
-9-
•マッピング
•正規化
•出力禁止文字
•bidi
文字
文字比較
‘A’
Character
‘a’
入力
未処理
コードポイント
‘0x41’
‘0x61’
stringprep
処理済
コードポイント
‘0x41’
コードポイント比較
‘0x41’
エンコード
バイト列
Byte sequences
‘???’
バイト列比較
‘???’
図 3-4 文字列比較の対象
コードポイント比較について考える場合、前述の stringprep によってサポート
される比較規則は case-sensitive と case-insensitive の 2 種類である。
また、本調査研究のように異なる文字コードの文字列同士を比較することを考
えた場合、文字コードによらず比較可能な ASCII 共通部分とそれ以外を分けて考
えることは意味があると思われる。
そこで、case-sensitive/case-insensitive という 2 種類の比較規則と、ASCII 共
通部分・ASCII 共通部分以外という 2 種類の比較対象によって組み合わせを考え
てみる。
表 3-2 比較規則と比較対象の組み合わせ
比較対象
ASCII共通部分
Case-sensitive
比較規則
(英大小文字区別あり)
Case-insensitive
(英大小文字区別なし)
- 10 -
ASCII共通部分以外
Case-sensitive
(1)
Case-insensitive
Case-sensitive
Case-insensitive
(2)
(3)
(4)
stringprep では、ASCII 共通部分以外の文字列に対して
case-sensitive/case-insensitive といった比較規則の適用を想定していない。この
ため一般には(1)または(3)のような文字列比較を行うことになる。
もし非 ASCII 文字に対して case-sensitive/case-insensitive といった比較規則を
適用する場合には、stringprep のさらに事前に以下のような処理が必要になると
考えられる。
−
−
ASCII 共通部分以外における大文字小文字のマッピング
ASCII 共通部分以外から ASCII 共通部分へのマッピング
(2)を実現したい場合には前者を、(4)を実現したい場合には後者を適用すること
が想定される。
3.2 PKI 基礎知識
ここでは UTF8String 問題を扱う上で最低限必要な PKI の知識について解説す
る。
一つは証明書チェーンにおいて DN11を比較することの重要性であり、もう一つ
はその DN を比較する際に必要となる、DN の構造と ASN.1 によるエンコードの
詳細である。
3.2.1 PKI の信用モデルと識別名比較
PKI では、証明書の連鎖(証明書チェーン)によって信用関係を示しており、証明
書チェーンを確認することで、信用関係を確認することができる。
この証明書チェーンを辿る時に用いる識別情報が、公開鍵による証明書検証と
DN である。
一般に公開鍵を使った署名検証には計算コストがかかることと、人間にとって
の見読性が低いことから、文字列として扱うことが可能な DN も証明書チェーン
を確認する貴重な情報である。
証明書には、その証明書の公開鍵に対応した秘密鍵を持つエンティティ名を表
す主体者 DN と、証明書を発行したエンティティ名を表す発行者 DN という 2 つ
の DN がある。証明書チェーンでは、一方の証明書の発行者 DN が他方の証明書
の主体者 DN と一致していることを確認することになる。
11
Distinguished Name, 識別名
- 11 -
発行者: ルートCA
ルートCA
主体者: ルートCA
発行者: ルートCA
下位CA
主体者:下位CA
Alice
発行者: 下位CA
それぞれ一致して
それぞれ一致して
いなければならない。
いなければならない。
主体者: Alice
図 3-5 PKI の信用モデルと DN
3.2.2 ASN.1 におけるエンコード
文字列処理における証明書の位置づけは、処理から出力されたバイト列を格納
するものである。つまり証明書へバイト列として出力する際にコードポイントか
らのエンコードという操作が発生し、また証明書から DN を取り出してコードポ
イントとして処理する際に、証明書からバイト列を取り出してデコードするとい
う操作が発生する。
- 12 -
文字
‘A’
Character
入力
未処理
コードポイント
‘0x41’
stringprep
処理済
コードポイント
‘0x41’
•マッピング
•正規化
•出力禁止文字
•bidi
オプショナル
エンコード
バイト列
Byte sequences
‘???’
図 3-6 証明書における文字列表現
実際にコードポイントを PrintableString へエンコードしてみると、図 3-7 にあ
るように、エンコード方式を示す Tag と、コードポイントを PrintableString とい
うエンコード方式に従ってエンコードした Value がある。Length は Value の長さ
を示したものである。
- 13 -
‘Alice’
文字
Character
入力
stringprep
処理済
コードポイント
‘0x41 0x6C 0x69 0x63 0x65’
Length: Valueの長さ
証明書上の
バイト列
PrintableString
エンコード
‘0x13 0x05 0x41 0x6C 0x69 0x63 0x65’
Value: コードポイントを
エンコードしたもの
Tag: エンコード方式が
PrintableStringであることを示す。
図 3-7 ASN.1(DER)におけるエンコード
ここで注意しなければならないのは、コードポイントと Value が必ずしも一致
するとは限らない点である。
例えば PrintableString はコードポイントと Value が一致するが、BMPString
では両者が一致しないため、コードポイントが同じでもエンコード方式が異なれ
ば Value は異なる、という場合があるので注意が必要である。
- 14 -
比較対象 Tag,Length,Value全て
OctetStringMatch
比較規則
Valueのみ
OctetStringMatch
エンコード方式なども
比較対象
特徴
エンコード方式は
区別しない
Alice
Alice
Alice
PrintableString
UTF8String
BMPString
‘13 05 41 6C 69 63 65’
‘0C 05 41 6C 69 63 65’
‘1E 0A 00 41 00 6C 00
69 00 63 00 65’
ASCII文字なので
Tag以外は一致する。
PrintableString以外では
Valueも一致しない。
比較対象をどちらにしても、比較結果が
比較対象をどちらにしても、比較結果が
エンコード方式に依存してしまう。
エンコード方式に依存してしまう。
図 3-8 バイト列比較における比較対象
3.2.3 識別名の複雑なエンコード
DN を比較する際に厄介なのは、DN を構成する個々の RDN12によってエンコ
ード方式が異なる(かも知れない)点である。
DN は、複数の RDN の並びによって構成されており、それぞれの RDN は(X.500
や LDAP などの)ディレクトリの属性として定義されている。
cn=foo, o=bar, c=JP
PrintableString
UTF8String
図 3-9 RDN 毎に異なるエンコード方式
ディレクトリの属性値として格納できる文字列のエンコード方式は、属性毎に
定義されており、必ずしも共通ではない。
例えば、Name 属性の多くはエンコード方式として UTF8String を用いるが、
country 属性は UTF8String ではなく、例外的に PrintableString でエンコードさ
れなければならないし、他にも serialNumber 属性などいくつか例外が存在する。
12
Relative Distinguished Name, 相対識別名
- 15 -
UTF8String 問題が解決した後も、このように DN 中に複数のエンコード方式が
混在する可能性は高いので注意が必要である。
RDN に用いるディレクトリの属性値の詳細については UTF8String 問題を広く
理解するために必要な情報ではないため、本文書では割愛する。ただしこれらデ
ィレクトリの属性値に対して具体的な処理を記述することになる開発者は、十分
に理解を深めることが必要であり、本報告書 Part2 「PKI 利用製品の UTF8String
項目実装の現状」でディレクトリの属性値と実装の関係について解説しているの
で参照されたい。
4 UTF8String 問題
UTF8String 問題の概要については既に 2 章で述べたが、ここでは 3 章の基礎
知識をもとに UTF8String 問題について掘り下げて考察し、より具体的に問題分
析を行うこととする。
4.1 曖昧な文字列比較要件
RFC 3280 では、証明書の正しい検証のための要件として、DN の文字列比較規
則についても定義している。これらの要件は単一のエンコード方式を用いて運用
する場合にはそれほど複雑なものではなかったが、UTF8String へ移行するなど異
なるエンコード方式が混在するケースについては、RFC 3280 の求める要件は複雑
であり、かつ実際に評価してみると曖昧な部分が残っている。本節では、その曖
昧な要件について詳しく述べる。
① 認証局側(証明書発行時)の要件
4.1.2.4 Issuer
(中略)
(b) As stated in section 4.1.2.6, the subject field MUST be
populated with a non-empty distinguished name matching the
contents of the issuer field in all certificates issued by the
subject CA regardless of encoding.
② 証明書ユーザ側の要件
4.1.2.4 Issuer
(中略)
(a) attribute values encoded in different types (e.g.,
PrintableString and BMPString) MAY be assumed to represent
- 16 -
different strings;
③ X.500 の比較要件
4.1.2.4 Issuer
(中略)
Note that the comparison rules defined in the X.500 series of
specifications indicate that the character sets used to encode data
in distinguished names are irrelevant. The characters themselves are
compared without regard to encoding. Implementations of this profile
are permitted to use the comparison algorithm defined in the X.500
series. Such an implementation will recognize a superset of name
matches recognized by the algorithm specified above.
①では UTF8String へ移行する際の要件として、以下のようにエンコード方式
に関わらずに証明書チェーンにおける DN が一致することを要件としている。こ
れは、3.2.2 節で言うところの value 比較か、3.1.4 節で言うところのコードポイン
ト比較のいずれかが該当する。
一方②では、異なるエンコード方式の属性値(文字列)は、異なる文字列として比
較されるかも知れない(MAY)とも記述されている。これは明らかにコードポイント
比較ではない、と言っている。これまでの記述を読む限りでは、value 比較という
のが RFC 3280 の求める要件と読み取れるのだが、しかし③ではさらに、移行に
関わらず一般的な文字列比較要件として以下のように、X.500 の比較規則(エンコ
ード方式に関わらず)を用いてもよい、と述べており、これは明らかにコードポイ
ント比較を指している。これらの矛盾は多くの読者に混乱を与える原因であると
考えられる。
4.2 UTF8String 環境への移行
RFC 3280 では、UTF8String 以外のエンコード方式を用いて証明書発行を行っ
てきた既存の認証局が、UTF8String へエンコード方式を移行するためにどのよう
な方法を用いることかできるのか、という点についてあまり触れられていない。
2.1 節で述べたように、あくまで移行期限を設け、以降に CA が発行する証明書の
エンコード方式を定めただけである。しかし 4.1 節で述べたように、単にエンコー
ド方式を変更すれば済む問題ではなく、エンコード方式を変更することによって
生じる様々な懸案について明確な対応策がなければいけないし、対応策を明確に
できない限りは既存の認証局はなかなか移行を推進できない。
- 17 -
•
Name rollover 証明書を用いた移行
RFC 3280 では移行時の対応策として挙げられている一例として、name
rollover 証明書というものが記述されている。
4.1.2.4 Issuer
(中略)
(a) CAs MAY issue "name rollover" certificates to support an
orderly migration to UTF8String encoding. Such certificates would
include the CA's UTF8String encoded name as issuer and and the old
name encoding as subject, or vice-versa.
しかし、この name rollover 証明書については、上記引用以外の記述は何らなく、
具体的にどのような証明書が発行されるのかきわめて曖昧なままである。このた
め UTF8String への移行を行おうとする CA にとって、果たしてどのような対策
をとるべきか悩ませる記述となってしまっている。
name rollover 証明書によってエンコード方式が変更になったことを証明書チ
ェーン中で表現できるので、あたかもバイト列比較を想定した移行策のようにも
解釈できるが、実際には自己署名証明書を UTF8String でエンコードされたもの
に更新すれば自然とこのような方式で移行することになるだけの話である。つま
り name rollover 証明書とは、必ずしも移行策として示されたものではなく、自己
署名証明書を UTF8String へ更新する際に発行する証明書のことを、名前付けた
だけと考えてよいだろう。
また、これはあくまで CA が自己署名証明書を発行しているケースに限られた話
であり、自己署名証明書を持たない下位 CA などの場合にどのような移行になり、
また name rollover 証明書が発行されるとしたらどのように発行されるべきなの
か、といった点については触れられていない。
なお、name rollover 証明書を発行する際には、いくつか注意しなければならな
い点があるので、以下に記述する。
•
•
•
•
認証局は RFC 2510[9] に示される CA 鍵の更新と自己発行証明書の
発行ができなければならない。
認証局は、自己発行証明書の issuer/subject において異なるエンコー
ド方式を利用できなければならない。
検証者は、RFC 2510 に示される自己発行証明書を辿った認証パスの
構築・検証ができなければならない。
検証者は、issuer/subject のエンコード方式が異なる自己発行証明書
を、明確に自己署名証明書と区別して扱うことができなければならな
い。
- 18 -
4 点目は、かなりの混乱を招くかも知れない。というのも、これまで述べてきた
ように文字列比較に対してはコードポイント比較を求めつつ、ここではエンコー
ドの違いについても認識できなければならない、と解釈できるからである。しか
し実際には、name rollover 証明書に限らず自己発行証明書はそもそも同じ DN を
持つ証明書である。したがって、4 点目の注意点に対しては DN のエンコード方式
を見て識別できる必要はなく、一般的な自己発行証明書と自己署名証明書の識別
と同様主体者公開鍵と発行者公開鍵を見て識別できればよいはずである。
このように RFC 3280 では、移行の手法として name rollover 証明書について
触れてはいるものの、例えば下位 CA などはどうすればよいのか、などの記述も不
足している。このため既存の認証局は安心して移行に踏み切ることができない状
態にあり、具体的な移行例を示す必要があるなど移行手段についての検討が必要
とされている。
5 UTF8String 問題の影響
本章では、4 章までで述べた各問題が、実際にどのような影響を及ぼす可能性が
あるかについて考察する。各節では詳細にわたる問題点が記述してあるためやや
難易な記述も含まれるが、重要な部分であるために本章でとりあげた。
問題は、大きくアプリケーション実装における影響と、認証局運用における影
響とに分けることができる。
アプリケーション実装する上で、文字列比較要件が大きな問題となることは既
に述べた。5.1 節では、この問題をさらに深く掘り下げて、実装上どのような点で
注意すればよいのか、説明する。
一方認証局運用においては、移行にあたって注意すべき問題と、文字列比較要
件の二つの問題がかかってくる。移行にあたっては、証明書が数年∼十数年とい
う有効期間を持つ以上は一定の移行期間を持つ必要があるだろう。その期間中に、
どのような手順で移行していくべきか、という解決策については本報告書 Part6
「公開鍵証明書発行に関する移行ガイド」の中で述べるが、5.2 節では、そのよう
な移行手順を実施する上で理解しておくべき問題について掘り下げて説明する。
5.1 UTF8String 問題の影響 実装編
5.1.1 異なるエンコード方式同士の文字列比較
4.1 節で述べたように、異なるエンコード方式同士の文字列比較の要件は曖昧な
ままであり、実装によって文字列比較の結果が異なるという事態が生じる可能性
が大きい。
- 19 -
具体的に、文字列'Alice'を BMPString、PrintableString、UTF8String でエン
コードしている場合について考えてみる。
文字列'Alice'のコードポイント列は'41 6C 69 63 65'であるが、実際にそれぞれの
エンコード方式でエンコードしたバイト列は以下のような値になる。
表 5-1 異なるエンコード方式の比較
バイト列
Encoding
Tag Length
BMPString
1E
0A
00 41 00 6C 00 69 00 63 00 65
UTF8String
0C
05
41 6C 69 63 65
PrintableString
13
05
41 6C 69 63 65
Value
これらはエンコード方式(Tag)が異なるため、TLV 比較を行うと一致しないこと
は自明である。PrintableString と UTF8String では ASCII 共通部分について互
換性があるため、どちらも Value の値は同一であるが、BMPString では ASCII
共通部分であっても互換性がないため、Value の値が異なってしまう。
このため、
「異なるエンコード方式であっても文字列が一緒であれば同じ識別名
とみなす」のであれば、TLV 比較・Value 比較いずれもバイト列比較では要件を
満たせず、コードポイント比較を行うしかない、ということになる。
証明書の
DN
バイト列
Byte sequences
‘Alice’
‘Alice’
‘Alice’
BMPString
UTF8String
PrintableString
‘1E 0A 00 41 00 6C
‘0C 05 41 6C 69 63 65’ ‘13 05 41 6C 69 63 65’
00 69 00 63 00 65’
デコード
処理済
コードポイント
‘41 6C 69 63 65’
‘41 6C 69 63 65’
‘41 6C 69 63 65’
処理済コードポイントで比較するべき!!
処理済コードポイントで比較するべき!!
図 5-1 異なるエンコード方式の文字列をコードポイント比較
- 20 -
ここで重要なのは、要件として挙げた「異なるエンコード方式であっても文字
列が一緒であれば同じ識別名とみなす」が果たして適切かどうかである。先述の
通り RFC 3280 では要件そのものが曖昧であるので、比較方法としてどちらが正
しいのかを論じる前に要件を明確に定めなければならない。
5.1.2 証明書の検索と認証パスの検証
証明書の検索と認証パスの検証では、それぞれ必要とされる文字列処理につい
ての要求精度が異なる。ここでは、それらの違いについて説明する。
一般に証明書の検索は、クライアントからリポジトリに対して証明書の DN を
問い合わせる形で行われ、リポジトリからは検索条件に該当する証明書が応答と
して返されることになる。なお、ここではリポジトリとは広義のものであり、ネ
ットワーク上のディレクトリサーバだけでなく、ローカル環境で管理される証明
書ストアなども含めて考えるものとする。
検索処理そのものはこれで終了だが、多くの場合クライアントは認証パスの構
築・検証の中の一処理として証明書の検索を行う。このような場合クライアント
は、続く認証パスの検証の一処理として、返された証明書が自身の必要とするも
のかどうか選別する必要がある。この選別手段の一つとして、検索に用いた DN
と証明書の DN を比較する処理がある。
例えば、図 3-5 で証明書チェーンを確認する場合には、Alice の証明書の発行者
DN である「下位 CA」という DN を用いてリポジトリに検索を行い、得られた証
明書の主体者 DN が「下位 CA」と一致する証明書を選出する。同様にその証明書
の発行者 DN である「ルート CA」という DN を用いて検索を行い…、という処理
を繰り返すことで証明書チェーンを確認する。
(a) 証明書の検索
クライアントからの問い合わせを受けたリポジトリでは検索条件に該当す
る証明書を抽出するわけだが、最終的に必要な証明書か否かの判断を下すの
がクライアント側である以上、リポジトリはあくまで候補となりうる証明書
を一通りクライアントへ返せるべきであると考えられる。
Unicode では、正規化をはじめとする stringprep 処理を施さないコードポ
イントは、異なる文字列として判断される可能性があるため、リポジトリで
はこれらの誤判定を防ぐため、検索要求の DN および検索対象となる証明書
の DN それぞれについて stringprep を処理した上で検索要求との比較処理を
行うべきである。
これによって、検索要求の DN が曖昧であっても適切な証明書を検索する
ことができ、余分な証明書が一緒に返されたとしても、クライアントはその
- 21 -
後の認証パスの検証の中で除外することができるため、検証の信頼性に何ら
悪影響を与えることはない。
例えば、Bob が Alice の証明書を探そうとしていても、実際の Alice の証明
書に Alice'と記されていた場合、stringprep せずに比較すればマッチしない
し、その逆もまた然りである。ここで仮に Alice’の証明書が検索条件にマッチ
しても、Bob が Alice'の証明書を選別できれば問題はない。
(b) 認証パスの検証
認証パスの検証では、検証対象証明書の発行者 DN と、発行者証明書の主
体者 DN を比較することで証明書チェーンを確認する。この発行者証明書を
取得するために証明書の検索を行い、得られた(複数の)証明書のうち DN が一
致するものを選別することになる。厳密には、証明書チェーンの確認には DN
の比較だけでなく発行者公開鍵による証明書の署名検証も必要となるが、こ
こでは DN 比較について考察する。
証明書の検索時には、比較する DN をどちらも stringprep 処理した上で比
較していたが、認証パスの検証ではどちらの DN も証明書に記載されたもの
であるので、これを stringprep 処理すると、場合によっては異なる DN がマ
ッチしてしまうことになる。
このため、認証パス検証時にはバイト列をデコードしたままのコードポイ
ント同士を比較するべきであり、一方証明書を発行する時点で認証局は、正
規化されてない正規化可能文字列を DN に用いるべきではない。
5.1.3 外部アプリケーションとの文字列の受け渡し
Web ブラウザやメーラ等多国語対応が早期から必要とされていた一部のクライ
アントアプリケーションでは、UTF-8 への対応も進んでいたが、OS や一般的なア
プリケーション、サーバソフトウェアが UTF-8 対応したのはごく最近の話である。
例えば、Microsoft 社の Windows シリーズが本格的に UTF-8 に対応したのは
Windows 2000 以降であり、従って OS 機能の一部である CryptoAPI を利用して
いる Windows 上の PKI アプリケーションの多くは、Windows 2000 以降でしか
UTF-8 を正しくサポートすることができない。このような場合、文字列がいった
んアプリケーションから OS を経由して他のアプリケーションへ渡る時に、エンコ
ード方式に関する情報が失われる可能性がある。同様に、一つのアプリケーショ
ンの内部でも、各ライブラリ間で同様の問題が考えられる。
- 22 -
一見UTF-8に対応
していても・・・
ユーザ
単なる文字列と
して入出力
単なる文字列と
して入出力
アプリケーション
ユーザインタフェース
エンコード方式
が欠落
PKIライブラリ
エンコード方式
が不足
証明書
業務モジュール
認証パスの検証
証明書の検証
図 5-2 外部アプリケーションとの文字列の受け渡し
これを防ぐには、PKI ライブラリと他のライブラリとの間で、エンコード方式
に関する情報を必要とする入出力をなるべく避けるよう設計することである。そ
のためには PKI ライブラリと他のライブラリとの間の DN に関する情報の入出力
は、コードポイントで行うべきと考えられる。
これまで UTF8String 問題を考えていく上で、DN などの比較をバイト列比較と
するかコードポイント比較とするか、という曖昧な要素が残っていた。しかし明
確にコードポイント比較にすることによって、エンコード/デコードなどエンコー
ド方式に関する情報を必要とする処理はごく一部に限定される。これらの処理を
PKI ライブラリ内部に実装してしまうことで、他のライブラリとの間にエンコー
ド方式に関する情報を入出力することは抑制できるのではないかと考えられる。
PKI ライブラリは、DN に関する他のライブラリとの入出力にはコードポイント
だけで済むように設計すべきであり、アプリケーション内の他のライブラリも、
コードポイントのみを入出力するだけで済むように設計すべきである。また、や
むを得ずエンコード方式も含めて他のアプリケーションと入出力する必要があっ
たとしても、一方が正しくエンコード方式を保持することを期待すべきではない
し、保持されずとも正しく処理できるよう設計する必要があるだろう。
- 23 -
5.2 UTF8String 問題の影響 運用編
5.2.1 証明書発行要求のエンコード方式
EE が認証局から証明書の発行を受けるにはいくつかの方法があるが、その一つ
として PKCS#10 形式の証明書発行要求(以下 CSR)を用いる方法がある。この方法
では、EE が自身で鍵ペアを生成し、EE を示す主体者 DN とその公開鍵などに対
して秘密鍵で署名した CSR を CA に送る。CA は、CSR の署名を、CSR に含まれ
る公開鍵で検証した上で主体者 DN に対して証明書を発行し、EE に返す。このよ
うな方法は、Web サーバや VPN 機器等に対して多く用いられている。この方法で
は、EE 自身が CSR の中で主体者 DN をバイト列へエンコードしており、CA は、
そのバイト列をそのまま証明書の主体者 DN として利用することが可能である。
しかしこの方法は、UTF8String 問題を考える上でいくつかの課題を抱えている。
1 点目は、もし移行期限以後に例えば PrintableString でエンコードされた CSR
を受け取った場合 CA はどのような対応をするべきか、という点であり、2 点目は、
EE が生成した CSR の主体者 DN のエンコード方式と CA から返された証明書の
主体者 DN のエンコード方式が異なっている場合の影響である。
① 移行期限以降に UTF8String 以外でエンコードされた CSR を受け取った場合
これは CA のポリシによって決められるべき問題であるが、大きく 2 つの
選択肢が考えられる。
1 点目は CSR に記載された主体者 DN を忠実に証明書に反映せず、エンコ
ード方式を UTF8String に変更してしまう、という選択肢である。一般に CA
は、その CP/CPS において主体者 DN の決め方について規定することができ
る。例えば、既に Alice に対して証明書を発行してしまった CA は、他の同名
の Alice から証明書発行を依頼されても、先の Alice と同じ主体者 DN の証明
書を発行してはならない。例えば"Alice Riddell"など先の Alice とは識別可能
な名前を付ける必要がある。
このため CA は主体者 DN の決め方について一定の裁量権を持つべき、と
いうのが一般的な考え方である。エンコード方式の変更も、この裁量権の範
囲と考えるのはごく自然な発想と言ってよいだろう。
2 点目は CSR の主体者 DN が UTF8String でエンコードされてないという
理由で証明書発行を拒否する、もしくは主体者 DN が UTF8String でエンコ
ードされた CSR を要求するという選択肢である。
② CSR と証明書のエンコード方式が異なる場合の影響
- 24 -
①の 1 点目とも関係するが、CSR と証明書でエンコード方式が異なってい
た場合どうなるのか、整理してみることにする。
EE が鍵ペアおよび CSR を生成し、発行された証明書を受け取る場合、生
成した鍵ペアと後から発行された証明書を関連づける処理が必要となる。こ
こで、もし関連づけるための識別子として主体者 DN を用いているようなら
厄介である。もし生成した CSR の主体者 DN と、発行された証明書の主体者
DN でエンコード方式が異なっていれば、両者の比較方法によっては関連づ
けに失敗する可能性があるからである。
例えば、鍵ペア生成後に'Alice'を BMPString でエンコードして CSR の主
体者 DN として記載した場合、生成した鍵ペアの識別子は、BMPString の
'Alice'となる。一方、発行された証明書の主体者 DN は UTF8String でエン
コードされた'Alice'であり、両者をもしバイト列比較してしまうと一致しなく
なってしまい、証明書を利用できなくなる可能性がある。
‘Alice’
’00 41 00 6C 00
69 00 63 00 65’
BMPString
証明書発行要求
(CSR)
UTF8Stringでしか
発行しないよ!!
’13 05 41 6C 69 63 65’
UTF8String
で再エンコード
証明書
’0C 05 41 6C 69 63 65’
あれっ? CSRは
BMPStringだった
のに!?
‘41 6C 69 63 65’
図 5-3 CSR と証明書のエンコード方式が異なる場合
このような挙動は鍵ペアを管理するアプリケーションの実装に依存するも
のだが、実際のアプリケーションの中にはいくつかこのような挙動を示すも
のが存在する。そのため CSR を用いて証明書を発行してもらうアプリケーシ
ョンを使う場合には、このような点についての注意が必要となる。
5.2.2 CA 証明書の移行(更新と再発行)
CA 証明書は、一般的に 5∼20 年といった長い有効期間を持つ証明書として発行
される。CA 鍵ペアについても同様で、多くの CA は特定の鍵ペアを長期間使い続
- 25 -
けている状態にある。公開鍵証明書は、その性質上公開鍵が公開されている期間
が長いほど鍵強度は下がるため、CA 鍵ペアはなるべく新しく生成されたものを利
用することが望ましい。鍵ペアの更新に伴って発生する CA 証明書の更新は運用コ
ストへの影響が大きく、CA にとってなかなか実施しづらいものであるが、今回の
ように CA 証明書の切り換えが不可避な状態においては、むしろ積極的に CA 鍵ペ
アを更新するよい機会である。
そこで本節では CA 鍵ペアも更新することを想定して解説を進めるものとし、本
報告書 Part6 「公開鍵証明書発行に関する移行ガイド」においても同様に CA 鍵
ペアを更新することを前提とした移行手順の説明を行うものとする。
実際に CA が自身の CA 証明書を UTF8String へ切り換えるためにはいくつか
の方法があるが、大きく分けると以下の 2 種類に分けて考えられる。
•
•
更新: CA の DN を保持(エンコード方式は除く)したまま CA 証明書を
更新する。
再発行: CA の DN を保持しない。新たに異なる CA を構築する。
なお、これら更新や再発行を行った場合、新 CA から発行された新 EE 証明書や、
旧 CA から発行された旧 EE 証明書を失効検証するにあたって、いくつか注意すべ
き点がある。これらについては次の 5.2.3 節にて解説する。
(a) CA 証明書を更新する場合
更新の場合には、既存の旧 CA の識別名からエンコード方式のみ
UTF8String に変更しコードポイントについては同一な新 CA 証明書を発行
する。なお、新 CA 証明書の発行形態は基本的に旧 CA 証明書と同じである
べきである。
例えば、旧 CA 証明書が自己署名証明書であれば新 CA 証明書を自己署名
証明書として発行し、新旧の自己署名証明書の関連を示すために自己発行証
明書を発行しなければならならいだろう。なお、ここで言う自己発行証明書
は、4.2 節の Name Rollover 証明書そのものである。
- 26 -
同じDN
異なる鍵ペア
旧CA
cn=same CA
旧来エンコード
新CA
自己発行証明書の
発行
Issuer: 旧来エンコード
Subject: UTF8String
cn=same CA
UTF8String
Issuer: UTF8String
Subject: 旧来エンコード
図 5-4 自己署名証明書を更新する場合
一方旧 CA 証明書が下位 CA 証明書であれば、新 CA 証明書はやはり下位
CA 証明書として発行されるべきであり、その発行者は旧 CA 証明書の発行者
と同一であるべきである。下位 CA 証明書として発行される場合は、新旧 CA
証明書の関連を上位 CA によって示されているので、自己発行証明書などの
発行は特に必要ない。
旧RPの
トラストポイント
旧CAの
リライングパーティ
共通の
トラストポイント
新RPの
トラストポイント
新CAの
リライングパーティ
同じDN
異なる鍵ペア
旧CA
新CA
cn=same CA
旧来エンコード
cn=same CA
UTF8String
図 5-5 下位 CA 証明書を更新する場合
(b) CA 証明書を再発行する場合
再発行では、旧 CA とは異なる DN を用いて UTF8String でエンコードさ
れた新たな CA(新 CA)を構築する。この時 CA は、更新と異なり DN を変え
る以上は CA 鍵ペアも変えなければならない。また、旧 CA とは DN が異な
- 27 -
っているため、両者の関係を示すために相互認証証明書を発行するなどの措
置が必要となる。
なお、再発行においても新 CA 証明書の発行形態は基本的に旧 CA 証明書
と同じであるべきである。
例えば、旧 CA 証明書が自己署名証明書であれば新 CA 証明書を自己署名
証明書として発行し、新旧の自己署名証明書の関連を示すために相互認証証
明書を発行しなければならならいだろう。更新と異なり新旧の CA 証明書で
は DN が異なるので、自己発行証明書ではない点に注意する必要がある。
異なるDN
同じDN
異なる鍵ペア
旧CA
cn=old CA
旧来エンコード
新CA
相互認証証明書
の発行
cn=new CA
UTF8String
図 5-6 自己署名証明書を再発行する場合
一方旧 CA 証明書が下位 CA 証明書であれば、新 CA 証明書はやはり下位
CA 証明書として発行されるべきであり、その発行者は旧 CA 証明書の発行者
と同一であるべきである。下位 CA 証明書として発行される場合は、新旧 CA
証明書の関連を上位 CA によって示されているので、相互認証証明書などの
発行は特に必要ない。
旧RPの
トラストポイント
共通の
トラストポイント
新RPの
トラストポイント
新CAの
リライングパーティ
異なるDN
同じDN
異なる鍵ペア
旧CAの
リライングパーティ
旧CA
新CA
cn=old CA
旧来エンコード
cn=new CA
UTF8String
図 5-7 下位 CA 証明書を再発行する場合
- 28 -
5.2.3 CA 証明書の移行と失効検証
証明書の失効を検証する際には、証明書を特定するための情報として当該証明
書の発行者 DN と当該証明書のシリアルナンバを用いる。これは、証明書のシリ
アルナンバが、発行する CA に対して一意でなければならない、という考え方にも
とづくものである。従って失効リストは、証明書発行者と失効リスト発行者は同
一であるという前提のもと、失効した証明書のシリアルナンバが列挙されている
構造を持っている。
このため 5.2.2 節で述べた CA 証明書を更新するような場合においては、以下の
ような要件を満たさなければならない。
① 旧 CA 証明書で発行した証明書のシリアル番号は、新 CA 証明書から発行する
いかなる証明書においても再利用してはならない(MUST)
② 旧 CA 証明書で発行した証明書の失効情報は、新 CA 証明書の発行する CRL
にも記載されなければならない(MUST)
これらの要件は、失効リスト上での証明書の識別が、発行者識別名と対象とな
る証明書のシリアル番号によって行われているためであり、CA がたとえ CA 証明
書を更新したとしても、証明書のシリアル番号は CA 毎に一意でなければならない。
ただし、これらはアプリケーションがコードポイント比較に対応している場合
の話である。アプリケーションがコードポイント比較に対応してないなど実装が
十分でない場合には、旧式証明書の失効検証に新 CRL を用いることができないの
で、CA 証明書更新後も旧 CA 鍵で旧 CRL を発行(更新)し続ける必要がある。
一方、CA 証明書更新後に旧 CRL を発行(更新)する場合の注意点として、以下が
挙げられる。
① 旧 CA 鍵を用いて旧 CRL を発行し続けなければならない。
② 旧 CRL の issuer は、旧 CA 証明書の subject とエンコード方式まで含めて一
緒でなければならない。
③ 旧 CA 証明書の発行する CRL にも、新 CA で発行した証明書の失効情報が反
映されなければならない。
④ 旧式証明書に cRLDistributionPoints 拡張で CRL 配布点が明記されている場
合、旧 CRL はその配布点に配布し続ける必要がある。
⑤ 新 CA 証明書から発行する証明書には、cRLDistributionPoints 拡張を用いて
旧 CRL とは異なる CRL 配布点を明示し、新 CRL はそちらへ配布する必要が
ある。
⑥ 新旧 CRL には、issuingDistributionPoint 拡張を用いてそれぞれの配布点を
明記する必要がある。
- 29 -
①はコードポイント比較に対応してないアプリケーションに対する要件であり、
③はコードポイント比較に対応したアプリケーションが新旧 CRL を混同したと
しても同様の失効検証ができるようにするための要件である。
④⑤⑥は同じ DN を持つ CA が複数の CRL を配布する際に注意すべき置換攻撃
への対策である。
トラストアンカとなる CA が、コードポイント比較に対応できてないアプリーシ
ョンに配慮しながら自身の CA 証明書を更新する場合、以上のような要件を満たす
必要があると考えられる。しかしこの方法では CRL の issuingDistributionPoint
拡張を使用する必要があり、これに対応したアプリケーションもまた少ないのが
実情である。このためコードポイント比較に対応してないアプリケーションに配
慮しつつ CA 証明書を更新する、という作業は非常に敷居の高いものと考えてよい
だろう。
6 UTF8String 問題に関する提言
ここまで UTF8String 問題について様々な面から解説を行ってきた。これらを
解決していくには CA ベンダ、CA 事業者、アプリケーションベンダに加えて、標
準の曖昧さを改善すべく PKIX WG においても解決へ向けての努力が必要となる
だろう。本章では、UTF8String 問題解決へ向けてまず必要な技術要件について定
義した後、この定義を有効とするために各機関が解決へ向けて努めるべき要件を
まとめ、提言とする。
6.1 UTF8String 問題解決のための要件
(a) 文字列比較要件
比較対象: 文字列はコードポイント比較とすべきである。
比較要件: ASCII 共通部分について case-insensitive で比較すべきである。
ASCII 共通部分以外は case-sensitive で比較すべきである。
(b) 移行要件
アプリケーションベンダは文字列比較要件が定められ次第、速やかに実装
対応すべきである。CA は、アプリケーションの対応が完了してから CA 証明
書の切り換えを行うべきである。
アプリケーションがコードポイント比較に対応してない限り、CA は同一
DN を保持したまま証明書更新をすべきではない。
- 30 -
(c) 証明書発行要件
証明書・CRL ともに issuer は、発行者証明書の subject と同じエンコード
方式でなければならない。これは、場合によっては証明書の中の issuer と
subject でエンコード方式が異なることになるかも知れないので、実装が対応
していなければならない。
PKIX WG が移行期限を定める場合、移行期限以降に発行する証明書の
subject のエンコード方式は、name rollover 証明書を除いて UTF8String と
すべきである。
なお、CSR の subjectDN が UTF8String 以外でエンコードされていた場
合についても、原則として発行する証明書の subject は UTF8String でエン
コードすべきだが、相互認証証明書に関しては発行先の状況を鑑みて判断す
るなどの配慮が必要となるかも知れない。
証明書の DN は正規化されているべきである。一つの CA が発行する証明
書の subject を正規化した際、その CA が発行した他の証明書の DN と一致
すべきではない。
(d) アプリケーション要件
PKI ライブラリ外との DN の受け渡しにはコードポイントを用いるべきで
あり、Unicode 以外のいかなる文字コードも仮定してはならない。他の文字
コードである可能性があれば、適切に Unicode にマッピングするなどしなけ
ればならない。
CSR を生成する場合、必要に応じて UTF8Sting でエンコードされた CSR
を生成できるべきである。あるいは鍵ペアを識別子としてハンドリングする
べきである。
6.2 各組織に対する提言
(a) CA ベンダ
CA ベンダは、6.1 節の(a)文字列比較要件、(c)証明書発行要件について注意
して実装対応しておく必要がある。特に(c)証明書発行要件は CA ベンダが対
応しない限りどうにもならないものであり、移行期限までに対応しておく必
要がある。一番初めに対応が済んでいなければならない点であり、CA ベンダ
の責任は大きい。
(b) CA 事業者
CA 事業者は、利用する製品が 6.1 節の(a)文字列比較要件、(c)証明書発行
要件を満たしていることを確認し、(b)移行要件についてはアプリケーション
ベンダと調整して無理のない移行計画を立てる必要がある。特に(c)証明書発
- 31 -
行要件は TTP(Trusted Third Party:信用できる第三者機関)としての信用問
題にも関わってくるものであり、十分な評価はもちろんのこと、運用してい
く上でも最新の注意を払わなければならない。
(c) アプリケーションベンダ
アプリケーションベンダは、利用する PKI ライブラリとアプリケーション
自身の両者についてそれぞれ 6.1 節の(d)アプリケーション要件を満たしてい
ることを確認する必要がある。
また、アプリケーションを扱っている CA 事業者との間で(b)移行要件につ
いて調整し、無理のない移行計画を立てる必要がある。CA 事業者によっては、
早期の対応を求める場合があるかも知れないが、アプリケーションの対応に
ついて目処が立たなければ CA 事業者も具体的な移行を計画できない。この
ためスケジュール上の最大のネックとなるのは、アプリケーションの対応時
期であることをアプリケーションベンダは十分に認識しておく必要がある。
6.3 PKIX WG への提言
6.3.1 文字列比較要件の追加定義
これまで再三に渡って述べてきたように、PKIX WG ではまず文字列比較要件に
ついて明確にすべきである。スケジュール上のネックがアプリケーションの対応
時期である以上、文字列比較要件を明確にできない限りは何も先へ進まないこと
になる。現在 3280bis[10] において、文字列比較に関する記述がかなり見直され
ており、これらが早急に確定されることが望まれる。
6.3.2 3280bis で触れられていない問題
6.1 節で述べた要件のうち、いくつか従来の RFC 3280 では触れられていない点
もいくつか存在しており、これらは現在改訂作業中の 3280bis へ反映されていく
必要がある。特に標準として求められるべきことは、CA に求められる 6.1 節の(c)
証明書発行要件である。これらは実装上の問題ではなく運用上の問題であるため、
標準という仕様の中で示すことによって執行力を保つ必要があるだろう。
また、現在公開されている 3280bis では、UTF8String と PrintableString の併
用を認めている状態だが、移行期間として両者を共存させる時期を見込んでの一
時的な仕様なのか、あるいはそのまま UTF8String と PrintableString については
無期限に共存を認めるつもりなのか、方針を明らかにしなければならない。
その上で、既存の CA が実際に UTF8String へ証明書のエンコード方式を移行
するために、どのような手順でどのような点に注意して実施すべきであるのかモ
- 32 -
デルケースなどを用いて啓蒙し、UTF8String への推進のきっかけを与える情報を
提供していくべきである。
- 33 -
参考文献
規範的参考文献
[1] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2000,
"Information Technology - Open Systems Interconnection: The Directory:
Authentication Framework", 2001
[2] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998,
"Information technology - Abstract Syntax Notation One (ASN.1):
Specification of basic notation", 1997
[3] ISO/IEC 10646, "Information technology -- Universal Multiple-Octet
Coded Character Set (UCS)", 2003
[4] ISO/IEC 646, "Information technology -- ISO 7-bit coded character set for
information interchange", 1991
[5] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 3629,
2003
[6] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key
Infrastructure Certificate and CRL Profile", RFC 3280, April 2002
[7] 情報処理振興事業協会セキュリティセンター, 日本ネットワークセキュリ
ティ協会, "注意喚起: RFC 3280 の UTF8String 問題について",
http://www.ipa.go.jp/security/pki/utf8string/utf8string.html , December,
2003
[8] P. Hoffman, M. Blanchet, "Preparation of Internationalized Strings",
RFC 3454, 2002
[9] C. Adams, S. Farrell, "Internet X.509 Public Key Infrastructure
Certificate Management Protocols", RFC 2510, 1999
[10]
D. Cooper, S. Santesson, S. Farrell, S. Boeyen, W. Ford, "Internet
X.509 Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", <draft-ietf-pkix-rfc3280bis-00.txt>, work in progress,
2005
参考資料
[11] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP
18, RFC 2277, January 1998
[12] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP
19, RFC 2278, January 1998
- 34 -
[13] P. Faltstrom, P. Hoffman, A. Costello, "Internationalizing Domain
Names in Applications (IDNA)", March 2003
[14] P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile for
Internationalized Domain Names (IDN)", March 2003
[15] P. Hoffman, "Terminology Used in Internationalization in the IETF",
May 2003
- 35 -