自堕落な技術者の日記 : XAdESにおける発行者名前比較の問題(第7回)

≪第6回へ

前回は証明書識別名のRFC 2253文字列が得られる入手しやすそうな5つの実装を紹介しました。

・Sun Java SE 6 Update 3 (build 1.6.0_03-b05)
・BouncyCastle Java Crypto Library 1.3.8
・IAIK JCE Toolkit 3.142
・Microsoft .NET Framework 3.5
・OpenSSL 0.9.8i (cygwin)

今回はこれらの実装を使った場合、生成されるRFC 2253文字列にそれぞれどのような違いがあるのかテストしてみたいと思います。

テスト1: 属性タイプ名に関するテスト

テスト対象の実装を用いてテスト用に生成された証明書の発行者名よりRFC 2253文字列を生成し、属性タイプ名(例: C, OU)がRFC 2253で規定に従っているかをテストします。

テストを行う属性タイプ名は
(1) RFC 2253で例として挙げられている属性タイプ名
(2) RFC 3280で扱うと規定されている属性タイプ名
計18をテストします。

属性タイプ名として期待される値は以下とします。
(1) RFC 2253で例として挙げられていればこれを用いる
(2) 上記(1)以外でRFC 2256で属性タイプ名が規定されていればこれを用いる
(3) 上記(1)、(2)以外ならばOID表記(例 1.2.3=#1F3D...)

テストの結果は以下の表のようになりました。

結果の表から以下の事が言えるかと思います。

.NETの実装ではIsserやSubjectのプロパティはRFC 2253というよりもむしろ
古いRFC 1779に準拠しており、RDNのカンマ区切りの後ろに空白文字が含まれたり
古いOID表記(例 "OID1.2.3=Test")が使われる場合、値が16進形式(例 "#1F3D..")
になっていないなどRFC 2253の生成要件を満たしているとは言えない。

良く使われているC,O,OU,CN,L,DCについては、ほぼ問題が無い。

良く使われる"ST(stateOrProvince)"で.NETの実装は"S="と表記するので
注意が必要

良く使われるEmailAddressについては、そもそもRFC 2253、RFC 2256で
属性タイプ名が規定されておらず、そのために相互運用性に問題がある。
EmailAddressはRFC 3280では後方互換性のため主体者名にのみ使えるとしている
ので発行者名しか使わないXAdESでは問題なさそうだが、Thawteなど
一部のパブリックな証明書発行サービスでも主体者名にEmailAddressを
含めているものはある。

一般にOpenSSLは証明書に関して標準に忠実であると考えられていたが、
RFC 2253の属性タイプ名に関してはむしろSun Java JCEの方が非常に厳格で
RFC 2253の例で示されたもののみを属性名文字列として表記しており、
未知のものはOID表記にしてしまう。

テスト2: DirectoryString Typeに関するテスト

証明書の識別名に使用されるPrintableStringやUTF8StringなどのDirectoryString Typeは、ITU-T X.680で規定されていて、RFC 3280では利用できる範囲を限定(プロファイリング)しています。

DirectoryString TypeがRFC 2253識別名文字列に影響を受けるのか調べるためにテストを行いました。UTF8StringやTeletexStringなど国際化対応の文字列についてはASCII文字以外の日本語などの文字列でもテストを行いました。

各実装でのDirectoryString Type対応テストの結果は以下の通りです。

表中、緑色で示されるDirectoryString Type(UTF8String, PrintableString等)はRFC 3280で利用可能なDirectoryString Typeです。

結果の表より以下のことが言えると思います。

よく使用されるUTF8String, PrintableString, IA5Stringについては問題ない

RFC 3280で使用できるとされているTeletexString, BMPString, UniversalStringについては一部の実装において使用している文字エンコーディングISO 2022, USC2, USC4から正しくUTF-8に変換されずに文字化けとなっているケースがあった

OpenSSLとIAIKにおいて処理中エラーとなるケースがあった。16進数形式で表示するならまだしもエラーとなり処理を継続できないのは実装の重大な欠陥であると考えられる。(OpenSSLはSSLが扱えることが目的なのでRFC 3280で扱えるTypeだけを処理できれば十分なのかもしれない)

Microsoft .NETの実装はどのようなTypeでも最も正しく表示させることができる

Sun Java JCEの実装は対応するDirectoryString Typeの範囲が最も狭い

テスト3: エスケープに関するテスト

識別名の属性値の部分をRFC 2253で文字列にする場合、一部の文字、例えばカンマ","やセミコロン";"などバックスラッシュ"\"でエスケープしなければならない文字があります。エスケープのルールについては"RFC 2253 2.4. Converting an AttributeValue from ASN.1 to a String"で規定されています。

ここでは実装が正しく属性値のエスケープ処理を行っているかテストします。

各実装でのエスケープ処理のテスト結果は以下の通りです。

結果の表より以下のことが言えると思います。

Microsoft .NET の実装はエスケープが必要なケースでは属性値をダブルクォート'"'で括るというRFC 2253の旧版であるRFC 1779に基づいた実装である

シャープ'#'や空白文字では一部RFC 2253従わない実装があった

OpenSSLとIAIKはエスケープ処理に関してはRFC 2253に完全に準拠している

RFC 2253生成要件準拠性の採点

3つのテストの結果を受け各テストにおいてどれくらいRFC 2253の生成要件を満足しているかを(主観的に（＾＾；)5点で採点し、15点満点で各実装の準拠性を比較したのが以下です。

正直な話、どれも「帯に短し襷に長し」といった感じでピリッとしませんね。RFC 2253の生成ルーチンについては自前できちんとしたものを持っておいた方がいいんじゃないかという気さえします。

各実装におけるRFC 2253文字列生成の特徴をまとめます。

実装	生成の特徴
Sun Java JCE	RFC 2253の例のレベルで局所的に完璧に実装しているが、属性タイプなど扱えない範囲が多すぎる
Bouncy	TeletexStringを使わない限り概ね良いが、エスケープの実装には注意が必要
IAIK	属性タイプの実装はほぼ合格だが、エスケープも満点だが対応してないDirectoryString Typeがあるのが欠点か？
Microsoft .NET	基本は旧版のRFC 1779なのでXAdESで利用するのに問題がある。DirectoryString Typeの対応は素晴らしい
OpenSSL	RFC 3280の証明書を使う限りはほぼ問題無いが、扱えないDirectoryString Typeの際にエラーとなり16進数形式ですら値を返せないのは大きな欠点

以上、比較的普及していると思われる実装のRFC 2253生成機能の標準準拠性をテストした結果を報告しました。

次回についてですが、実は今回紹介しているRFC 2253は古くて新しいXML署名の標準でRFC 2253の改訂版である"RFC 4514 Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names"が参照され使用されています。

XAdESで引用されているのはRFC 2253ですが、近い将来新しいXML署名の標準であったりRFC 4514を引用されるようになると思います。次回はこのRFC 4514について紹介しようと思っています。

今回も長くなっちゃいましたね。

ではでは