メンバー以外の方のコメントが受け付けられない設定になっていました… kjurさんご指摘ありがとうございました。変更しましたのでこれでメンバー以外の方でもコメント追加が可能になっています。すみませんでしたm(_ _)m

これってスパムコメント対応の為に自分で設定してしまったんだろうなぁ… 元に戻したつもりが設定を１つ戻し忘れていたようです。やっぱりちゃんと確認しなきゃ駄目ですね。反省反省… kjurさん以外にもコメント投稿しようとして弾かれていた方がいらっしゃいましたら申し訳ありませんでした！

さて技術的な説明は前回と前々回で終わったと考えています。最終回の今回はまず実際のサンプルファイルを見てみましょう。早速ですが以下はXAdES 1.3.2とXAdES 1.4.1/1.4.2でそれぞれ署名したES-A（保管タイムスタンプ付）のサンプルファイルです。弊社のLe-XAdESのVer1.5ベータ版で作成してあります。 [続きを読む]

さて1日間が空きましたが第３回は前回説明したXAdESv141:TimeStampValidationDataと同じくXAdES 1.4.1/1.4.2で新しく追加されたXAdESv141:ArchiveTimeStampについての説明です。名前の通り保管タイムスタンプなのですがXAdES 1.3.2とは互換性がありませんので名前空間で区別して利用する必要があります。

では今回もそもそもなぜ新しい保管タイムスタンプであるXAdESv141:ArchiveTimeStampが必要になるのかと言う話からしましょう。前回XAdESの非署名領域であるUnsignedSignatureProperties要素の下にタイムスタンプ用の検証情報格納場所であるXAdESv141:TimeStampValidationDataが追加された事を説明しました。UnsignedSignatureProperties要素の下にはSchema的には任意の要素の追加が可能なので問題ありません。

一方XAdESv132:ArchiveTimeStampの計算時にはUnsignedSignatureProperties要素の下の決められた要素を順番に取得して連結して行く仕様となっています。この決められた要素とは全てXAdES 1.3.2で定義されたSignatureTimeStamp要素やCertificateValues要素等でありXAdESv141:TimeStampValidationData要素が含まれていません。これではせっかくXAdES 1.4.1/1.4.2で追加したXAdESv141:TimeStampValidationData要素の下が保護出来ない事になってしまいます。そこでArchiveTimeStampの計算方法として「UnsignedSignatureProperties要素の下を全て対象とする」XAdESv141:ArchiveTimeStamp要素を追加して解決したと言う事です。

ただそれだけでは無くもう１点ds:Objectの扱いについても変更がありました。XAdES 1.3.2では「Reference要素で参照されていないds:Object」が対象でしたが、XAdES 1.4.1/1.4.2では「全てのds:Object」が対象となりました。なお正確には「XAdESの要素であるQualifyingPropertiesを持つds:Objectは除外する」と言うルールもありますがこれはXAdES 1.3.2とXAdES 1.4.1/1.4.2の両方に共通しています。

以上をまとめると以下のようになります。

　１）XAdES 1.3.2における保管タイムスタンプ仕様（一部）
　　１：UnsignedSignatureProperties要素の下の決められた要素を連結
　　２：Reference参照されていない全てのds:Objecctを連結 ※

　２）XAdES 1.4.1/1.4.2における保管タイムスタンプ（一部）
　　１：UnsignedSignatureProperties要素の下の全ての要素を連結
　　２：Reference参照有無に関係無く全てのds:Objecctを連結 ※

　※ ただしXAdESのQualifyingPropertiesを持つds:Objectは除外する。

計算方法が2箇所異なるので、当然計算結果のハッシュ値もXAdES 1.3.2とAdES 1.4.1/1.4.2では異なり一致しません。XAdESv141:TimeStampValidationData要素への対応の為に異なる保管タイムスタンプが生まれてしまいました。

なおXAdES 1.4.1のSchemaではXAdESv141:ArchiveTimeStampV2と書かれていましたがこれは誤りで、V2が無いXAdESv141:ArchiveTimeStampが正しい要素名となります。これはXAdES 1.4.2で訂正されています。 [続きを読む]

さて今回はXAdES 1.4.1/1.4.2で新しく追加された要素のうちタイムスタンプの検証情報を保管するXAdESv141:TimeStampValidationDataについて私の理解の範囲で説明しましょう。

そもそも何故XAdESv141:TimeStampValidationDataが必要になるのかと言う話からする必要がありますね。XAdESをはじめとする長期署名は基本的には「署名」＋「タイムスタンプ」（これがES-T形式）となります。PDF長期署名のPAdESでは「(文書)タイムスタンプ」だけで「署名」無しの仕様も可能ですが、XAdES/CAdESでは署名抜きでタイムスタンプだけの仕様はありません。

タイムスタンプのRFC3161仕様とは乱暴に言えばサーバによる「署名」と言えます。つまり「署名」＋「タイムスタンプ」では2つの「署名」がある事になります。それぞれの「署名」についてEE(署名者)証明書が存在しており、かつトラストアンカーとなるルート証明書までの証明書パス（チェーン）が存在する事になります。

もし「署名」と「タイムスタンプ」で同じトラストアンカーのルート証明書を使うのであれば同じ証明書とCRL等の検証情報で良いので証明書パスは1つだけですみます。過去にXAdESの国際プラグテストを行った時には署名証明書とタイムスタンプは同じトラストアンカーを利用していました。欧州等ではどうもこのような運用が一般的だったようです。

一方日本では主に「署名」に関しては経済産業省の管轄であり「タイムスタンプ」は時刻に関係があるので総務省の管轄で認証局とタイムスタンプ局が別々に認定されてきました。このために「署名」と「タイムスタンプ」ではトラストアンカーとなるルート証明書が異なります。そうすると証明書パスは「署名」と「タイムスタンプ」の2つが必要となります。

少なくとも日本では証明書パス（と正確にはそれらに必要な検証情報群）は2つ格納する必要があります。ところがXAdES 1.3.2の仕様では証明書はCertificateValues要素下に格納し検証情報はRevocationValues要素下に格納できるだけです。かつCertificateValues要素とRevocationValues要素は1つだけしか認められません。つまり証明書パスの情報を格納するのは1ヶ所しか無いのです。本来CertificateValues要素とRevocationValues要素には「署名」に関する証明書パスと検証情報を格納する事になっています。

このままでは「タイムスタンプ」の証明書パスと検証情報をXML要素として格納する事ができません。そこでJIS化する際に以下のルールが定義されました。

　署名タイムスタンプ(SigTS)の証明書と検証情報：
　　１）タイムスタンプトークン自身に埋め込む
　　２）CertificateValues要素とRevocationValues要素に入れる

　保管タイムスタンプ(ArcTS)の証明書と検証情報：
　　１）タイムスタンプトークン自身に埋め込む

正確にはタイムスタンプトークンのどこに埋め込むかによって更に種類は分かれますがここの本題では無いので省略します。CertificateValues要素とRevocationValues要素に関しては意味を広義にとって署名タイムスタンプについては利用しても良いとしました。保管タイムスタンプはその時刻が常にRevocationValues要素に埋め込まれたCRL発行日よりも後になるので利用できません。

これでめでたしめでたし…なのですが証明書や検証情報を「タイムスタンプトークン自身に埋め込む」には以下の意見がありました。

　１）XMLだけでなくASN.1/DER(BER)の操作が必要になり難しい
　２）取得したタイムスタンプトークンはそのまま利用すべき
　３）XMLの利点である可読性の面から望ましくない
　４）CertificateValues/RevocationValuesは署名証明書のみにすべき

どれも問題点と言うレベルでは無いのですが、特に１）のASN.1/DER(BER)の操作については技術的なハードルが高くなるので実装者が苦労すると嫌がられています。ちなみに日本ではどのベンダーもタイムスタンプトークン自身に埋め込む方式に対応しています。JIS対応するには必須ですから当然ですね。しかし欧州では…げふんげふんw ここでXAdESv141:TimeStampValidationDataの登場です。 [続きを読む]

XMLの長期署名フォーマットであるXAdESの最新仕様はETSI（欧州電気通信標準化機構）が中心となって決定しています。日本では旧ECOM及び現在はeRAP（電子記録応用基盤フォーラム）が中心となってJISプロファイルを策定してきました。現在のJISプロファイル（JIS X 5093:2008）はXAdES 1.3.2をベースにしています。しかし実は新しいXAdES 1.4.1が既にリリースされており、更に1.4.1を更新したXAdES 1.4.2も2010年12月にリリースされています。ETSIのベースラインプロファイルも昨年リリースされ欧州では標準化作業が進展しています。ここまでのXAdES仕様の流れを以下にリストアップします。

　(2005) ETSI XAdES 1.3.1 Draft
　(2006-03) ETSI XAdES 1.3.2 [PDF]
　(2008-05) JIS X 5093:2008 [案：PDF]
　(2009-06) ETSI XAdES 1.4.1 [PDF]
　(2010-12) ETSI XAdES 1.4.2 [PDF]
　(2011-09) ETSI XAdES Baseline Profile [PDF]

XAdES 1.3.1の前にももちろん仕様が存在しますが今回の話には必要が無いのでここでは説明しません。またXAdESはベース仕様として XmlDsig（XML署名）[PDF] を使っています。しかしながらXAdES 1.4.1/1.4.2に関して言えば変更はありませんのでこれもここでは説明しません。

JISプロファイルもそろそろXAdES 1.4.1/1.4.2ベースに移行する必要があると思いますが色々な事情もあり（聞かないでw）まだ更新されていません。しかしながらそろそろ弊社のLe-XAdESライブラリもXAdES 1.4.1/1.4.2へ対応しようと作業を開始しました。その必要もあってXAdES 1.4.1/1.4.2仕様をまずは簡単にまとめたいと思います。 [続きを読む]