3.2 調査結果
3.2.2 動作検証
3.2.2.1
解析結果から予想される動作結果3.2.1
の結果から、テストパターンに含まれる名前がどのような結果になるか予想する。予想結果は表
3-8
のようになる。結果の根拠は次のとおり。始めに、テスト自体の名前の特性について、標準実装の動作を踏まえて分析し た。まず、
EE
証明書の署名者名と中間CA
証明書のサブジェクトに関して、標準 実装では、表3-10/
表3-11
のように解釈される。さらに、これらを分類した結果、表
3-12
のようになる。表3-12
は次のような方法で分類を行った。1.
属性の有無で分類した場合、email属性の有無でグループ分けする。2.
属性O
に関して、標準実装の動作特性に従って分類する。この結果、壊れている文字列を持つものと”
cpki2004”を持つものに分類できる。
3. RFC2253
指定属性に関して、CNの値を文字列として取り扱い可能な物と
16
進表記になるものに分類する。4.
前述したグループ間において、もともと16
進表記になりえる属性と 値の型の組み合わせで分類する。これらの結果、テストケースは
5
つのテストへ収束することが明らかとなった。これを踏まえて、テストの結果を予想したものが表
3-8
となる。なお、
1.2
テストケースで示されているテスト番号と証明書の組み合わせは表3-7
のようになる。表 3-7 テスト番号と証明書の組み合わせ
2910002 2910003 2910004 2910005 2910006 2910007 2910008 2900002 1 2 3 4 5 6 7
2900003 8 9 10 11 12 13 14
2900004 15 16 17 18 19 20 21
2900005 22 23 24 25 26 27 28
2900006 29 30 31 32 33 34 35
2900007 36 37 38 39 40 41 42
2900008 43 44 45 46 47 48 49
表
3-8
予想される動作結果2910002 2910003 2910004 2910005 2910006 2910007 2910008 2900002
2900003 2900004
SUCCESS FAILURE FAILURE FAILURE FAILURE
2900005 FAILURE SUCCESS FAILURE FAILURE FAILURE
2900006 FAILURE FAILURE SUCCESS FAILURE FAILURE
2900007 FAILURE FAILURE FAILURE SUCCESS FAILURE
2900008 FAILURE FAILURE FAILURE FAILURE SUCCESS
表
3-9
標準実装のテスト結果2910002 2910003 2910004 2910005 2910006 2910007 2910008 2900002 SUCCESS SUCCESS SUCCESS FAILURE FAILURE FAILURE FAILURE 2900003 SUCCESS SUCCESS SUCCESS FAILURE FAILURE FAILURE FAILURE 2900004 SUCCESS SUCCESS SUCCESS FAILURE FAILURE FAILURE FAILURE 2900005 FAILURE FAILURE FAILURE SUCCESS FAILURE FAILURE FAILURE 2900006 FAILURE FAILURE FAILURE FAILURE SUCCESS FAILURE FAILURE 2900007 FAILURE FAILURE FAILURE FAILURE FAILURE SUCCESS FAILURE 2900008 FAILURE FAILURE FAILURE FAILURE FAILURE FAILURE SUCCESS
実際に標準実装を動作させた結果を表
3-9
に示す。この結果を表3-8
と比較し た場合、まったく差異が無い。よって、分析したソースから得られる以外の動作 をしていないことが判った。表
3-10
中間CA
証明書のサブジェクトSubject Names 2900002
2900003 2900004
C=JP O=cpki2004 OU=jnsa 2.5.4.46=#13026471 ST=tokyo CN=middle 2.5.4.5=#13023130
2900005
C=JP O=cpki2004 OU=jnsa 2.5.4.46=#13026471 ST=tokyo CN=middle 2.5.4.5=#13023130 1.2.840.113549.1.9.1=#161175746638 ・
・・
2900006 C=JP O=cpki2004 OU=jnsa 2.5.4.46=#13026471 ST=tokyo CN=#1e0c006d0069・・・2.5.4.5=#13023130
2900007 C=JP O=cpki2004 OU=jnsa 2.5.4.46=#0c026471 ST=tokyo CN=middle 2.5.4.5=#0c023130 2900008 C=JP O=?? OU=jnsa 2.5.4.46=#13026471 ST=tokyo CN=middle 2.5.4.5=#13023130
表
3-11
エンドエンティティ証明書の署名者Issuer Names 2910002
2910003 2910004
C=JP O=cpki2004 OU=jnsa 2.5.4.46=#13026471 ST=tokyo CN=middle 2.5.4.5=#13023130
2910005
C=JP O=cpki2004 OU=jnsa 2.5.4.46=#13026471 ST=tokyo CN=middle 2.5.4.5=#13023130 1.2.840.113549.1.9.1=#161175746638 ・
・・
2910006 C=JP O=cpki2004 OU=jnsa 2.5.4.46=#13026471 ST=tokyo CN=#1e0c006d0069・・・2.5.4.5=#13023130
2910007 C=JP O=cpki2004 OU=jnsa 2.5.4.46=#0c026471 ST=tokyo CN=middle 2.5.4.5=#0c023130 2910008 C=JP O=?? OU=jnsa 2.5.4.46=#13026471 ST=tokyo CN=middle 2.5.4.5=#13023130
表
3-12
標準実装におけるテストケースの分類1.2.840.113549.1.9.1=#161175746638・・・ 0005
O=?? 0008
C=JP, OU=jnsa, ST=tokyo, CN=#1e0c006d0069・・・ 0006 2.5.4.46=#13026471, 2.5.4.5=#13023130 0002 0003 0004 O=cpki2004
C=JP, OU=jnsa, ST=tokyo, CN=middle
2.5.4.46=#0c026471, 2.5.4.5=#0c023130 0007
3.2.2.2
期待との差異テストケースの期待値と標準実装の動作結果を比較すると、10個所に違いが現 れた。表 3-13に比較結果を示す。
表 3-13は期待値をベースに標準実装の結果と相違した部分を強調したものであ る。
表
3-13
期待値と実行結果の比較2910002 2910003 2910004 2910005 2910006 2910007 2910008 2900002 SUCCESS FAILURE
① FAILURE② FAILURE FAILURE FAILURE FAILURE 2900003 FAILURE
③ SUCCESS SUCCESS FAILURE SUCCESS
④ FAILURE FAILURE 2900004 FAILURE
⑤ SUCCESS SUCCESS FAILURE SUCCESS
⑥ FAILURE FAILURE 2900005 FAILURE FAILURE FAILURE SUCCESS FAILURE FAILURE FAILURE 2900006 FAILURE SUCCESS
⑦
SUCCESS
⑧ FAILURE SUCCESS FAILURE FAILURE 2900007 FAILURE FAILURE FAILURE FAILURE FAILURE FAILURE
⑨ FAILURE 2900008 FAILURE FAILURE FAILURE FAILURE FAILURE FAILURE FAILURE
⑩
まず、①②③⑤に関して、期待値では多バイト系の文字と
1
バイト系の文字は 区別することを前提にしている。しかし、この前提は標準実装の動作と異なって いる。標準実装では多バイト系の文字は出来うる限り1
バイト系文字へ置換され た後、比較が行われる。それ故、一バイト・多バイト文字の差が失われた結果、パスの構築に成功した。
次に、④⑥⑦⑧に関して、期待値ではパス構築が成功すると定義している。こ れの根拠はユニコードから派生している文字列型同士は、エンコードが異なって もコードポイント比較が行われると期待しているからである。
しかし、標準実装では
BMPString
を理解できず、コードポイント比較できない事 から期待値と異なった結果となった。⑨に関して、期待値自体の議論として、
PrintableString
しか入れられない属性に
UTF8String
を入れた場合の挙動が議論された。その結果、エラーを検出してパス構築自体が失敗するべきである、と結論付けられた。
しかし、異なる型同士の比較機能という意味においては、成功することも期待出 来るので、この領域自体がグレーゾーンであるとも言える。
標準実装では、ここの動作がパス構築成功であり期待値とは相違しているが、一 概に間違った動作とは分類しないほうがよいと考える。
⑩に関して、エンコーディングが不正な文字列同士はマッチングの処理まで到 達できないはずであると考えられるので、パス構築としては失敗すると定義して いるが、標準実装では壊れているにもかかわらず強引にマッチングを行い、成功 してしまっている。この動作も一概に間違った動作とは言えないが、いくつか追 加のテストを行った結果によって判断すべきであろうと思われる。