さて今回は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の登場です。 [続きを読む]