2010年6月にリリースが予定されているMicorosoft Office 2010で、XML形式の長期署名フォーマットXAdESがサポートされるという記事をUさんから紹介頂いた。

ブラジル政府はタイムスタンプ付き署名に熱心でECOMのサイトを見て、ブラジルの方が長期署名フォーマットについて問い合わせをしてきたりしてました。この記事を見るにブラジル政府の文書管理のためにXAdESに対応したような感じもしますね。

Microsoft Office 2010のRTM版(初期版)とベータ版のXAdESの各フォーマットの対応

現在、Microsoft Office 2010のベータ版が試せるようになっていますが、RTM版の機能はXAdES-X-Longまでに対応しているのに対し、ベータ版ではXAdES-Tまでしか対応していないんだそうです。


図2

Office 10ベータ版のXAdES機能を試す

誰でも登録すればダウンロードできるOffice 10のベータ版を使って、XAdES-EPES、XAdES-Tの機能を試してみた。本当はC、X、X-Longも見てみたかったんだけど、正式版を待つことにしましょう。

Office文書にXAdES-EPES、XAdES-Tで署名するにはレジストリの変更をするそうです。

XAdES-EPESにするには

HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\Signatures]
"XAdESLevel"=dword:00000001
"MinXAdESLevel"=dword:00000001
XAdES-Tにするには
HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\Signatures]
"XAdESLevel"=dword:00000002
"MinXAdESLevel"=dword:00000002
"TSALocation"="HTTPタイムスタンプサービスのURL"
のように設定すればよいようです。実際に
  • レジストリ設定なし (XML-Dsig署名)
  • レジストリ設定でLevel=1 (XAdES-EPES署名)
  • レジストリ設定でLevel=2 (XAdES-T署名)
のように設定して署名を行ってみました。

Office 10ベータ版のXAdES署名を見る

ご存じのとおりMicrosoft Office 2007以降の.docx、.xlsxなどのドキュメントフォーマットはいろんなファイルをZIPアーカイブで固めたもののになっていて "_xmlsignature" フォルダに署名データが入ります。

Office 2010の生成するXAdES署名データの特徴

実際にレジストリ設定をしてXAdES-TとXAdES-EPESで署名されたWordファイルを生成して、そのXAdES署名データを見てみました。以下のような特徴がありました。

  • XAdES v1.3.2 フォーマット
  • ハッシュアルゴリズムはSHA1を使用
  • 署名アルゴリズムはSHA1withRSAを使用
  • XAdES-Tは、XAdES-T over EPES
  • XAdES-EPES対応といってもSignaturePolicyImpliedがついているだけ
XAdES-EPESに対応しているというので、かなり期待していたんですが、実はSignaturePolicyImpliedがついているだけで、これは署名者と検証者で署名ポリシに対して暗黙の合意があることを意味しています。これって、Office文書の署名ポリシに対して何らかの暗黙の合意があるとはとても思えないのに勝手につけてしまうのはどうかと思うのと、SignaturePolicyImpliedをつけるぐらいなら、いっそ無くしてXAdES-BESでいいんじゃないかなぁと思いました。

生成されたXAdESフォーマットのプロファイル

XAdESのXML要素のプロファイルはこんな感じでした。


図3

あと、スキーマチェッカにはまだかけてないんですが、XAdES-EPESにした時に空要素のUnsignedSignaturePropertiesがあるのはスキーマ違反だと思います。

タイムスタンプサーバーについてはHTTPで認証無しのRFC 3161タイムスタンププロトコルに対応してないといけないので、国内の認証有のタイムスタンプサービスでは(仕掛けを入れないと)使えないこともあるかもしれません。

問題点は？

Microsoft Office 2010のXAdES署名の機能を見て、いくつか気になった点が他にもあります。

署名日時の表示
Offce 2010の署名の表示において署名を行った時刻は日単位で表示されています。国内のタイムスタンプサービスが500ミリ秒から1秒の精度を持っているのに日単位でしか表示されないのはもったいない話です。
猶予期間の問題
自分がICカードを落としたとき、その失効申請がCRLに反映されるまで数営業日かかるというのが普通だと思います。失効情報はリアルタイムに反映されるとは限らないので長期署名では署名してからある時間経過した後に取得した失効情報を用います。これを猶予期間(Grace Period)と呼んでいます。おそらくMicrosoft Office 2010のXAdES-C以降では失効情報として署名時刻に取得した失効情報を使うと思われますが、これは適切な失効情報ではありません。
XAdES-C、XAdES-X、XAdES-X-Longを流通させていいのか？
XAdES-CやXAdES-Xでは後になって必要となる当時の失効情報が取得できないかもしれませんし、XAdES-X-Longの中の検証情報へのタイムスタンプは機能として中途半端です。そこで、JIS X 5093:2008ではドキュメント交換にふさわしい署名はXAdES-TもしくはXAdES-Aだと位置づけました。XAdES-C、XAdES-X、XAdES-X-Longは不完全な中間データにすぎず、何らかの仕組みでこれを補ってやる必要があるのです。
タイムスタンプ検証してないんじゃ？
タイムスタンプ局の証明書(TSA証明書)をどうも検証していないっぽいんです。TSA証明書用のルート証明書を信頼していなくても、なんら警告やエラーが表示されませんし、ドキュメントで表示される(署名時刻でなく(T_T))署名日も署名タイムスタンプではなくSigningTimeプロパティの値を表示しているんじゃないかという気がしています。タイムスタンプの無効系のテストは時間があればやってみたいと思います。

おわりに

レジストリをいじらないとXAdESにならないというのは、ちょっとトホホな感じですが、ともあれMicrosoft Officeが標準でXAdESに対応してきたというのは、すごい事だなぁ、、、と思います。少しずつ普及が進むといいんですけどね。

今日はこの辺で、、、