はじめに
先日、XML署名を拡張した長期署名フォーマット ETSI TS 101 903 XAdES の改訂版 v1.4.1 が2009年6月25日頃公開されたとブログに書きました。今回の改訂はこれまでETSI TC ESI(電子署名基盤技術委員会)に送られたコメントや昨年度3回(も)実施したETSI Remote XAdES Plugtestsでのコメントを反映させたものになっているんですが、個人的な感想を言わせてもらうと
本当にXMLで長期保存する気あります？！ちゃんと検討しました？！
と言いたくなるような改訂なんです。
何回かの連載でETSI TS 101 903 XAdES v1.4.1 の改訂のポイントと問題点を説明したいと思います。
XAdESの説明をするときに「XMLは可読性が高いので長期保存に向いている」とか簡単に言っちゃう人がいますが、CAdESとXAdESの双方の実装をしてみて本当にそうなのかなぁ、、、と私は前から疑問に思ってました。今回の改訂で「ちょっとXAdESはダメかも、、、」と悲しくなった次第、、、、
＃もちろん問題の指摘は２年ぐらいかけて苦手な英語で今後もしていきますよ〜〜〜(でも心が折れそう、、、)
問題のポイントっていうのは、
- 長期の保管が目的なので、フォーマットには後方互換性があり長期に渡り検証ができるようになっていなければならない。複数バージョンのXAdESの混在が可能な設計でなければならない。
- XML(メッセージング)はトランザクション用途の方が重要で(スキーマとか)バージョンを厳密に区別するので、後方互換性を持ち長期に検証させるのは難しい
- 上記の問題は標準の設計を工夫すれば解決できたはずだが、設計者にその意識がないか希薄
- 実際、複数のバージョンのXMLのデータを扱うのはXMLの世界ではやや難しい
- XML署名の処理は基本的に複雑で、XAdESはさらに輪をかけて複雑
っていうとこにあるのかな、、、と、、、、こんなんじゃ、複数バージョンのXAdESを跨いで生成・検証できるのはそう多くは出てこないっすよ。
XAdES 1.3.2から1.4.1の改訂の概要
1.4.1への改訂内容は、77ページ Annex E (informative) "Main changes to XAdES v1.3.2" にまとめられています。細かい話が多いので要約するとざっくりこんなとこだと思います。
- xades141:ArchiveTimeStampの新設
- 古いxades132:ArchiveTimeStampは非推奨(deprecated)に。もっと古いのは言及すら無し。
- タイムスタンプトークンのTSA証明書のパス検証用情報格納のためにxades141:TimeStampValidationDataを新設
- 名前空間の扱いについての方針の記述
- 検証情報にOCSPレスポンスを含める場合、参照情報としてそのハッシュを含めることを強く推奨
- SigningTimeプロパティとタイムスタンプとの時間比較は署名ポリシーに委ねることとした
- スキーマ定義中の要素数の制約の数々の誤りの修正(minOccurs等)
そうなんです、ArchiveTimeStamp変わっちゃったんですよ〜〜〜。それも大きく（Ｔ＿Ｔ）変更の仕方はCAdES v1.4.0 から v1.5.1で大幅に変わって泣きをみましたが、その時と事情もかなり似ています（−−；(嵐を呼ぶぜぇ〜〜ぃっ！)
次回以降、改訂箇所を掘り下げていきましょう。
ではでは、、、
