前回から随分間があいてすみません。

今回は、XAdES v1.4.1 から新設されたタイムスタンプトークンの検証情報の格納場所の話をする前に、v1.3.2 以前ではどうだったのかってことをおさらいしたいと思います。

XAdES 1.3.2までのタイムスタンプの検証情報の格納場所



CAdESやXAdESの長期署名フォーマットでは一般的なCMS署名(バイナリ形式)やXML署名で、署名者証明書の検証情報である証明書チェーンやCRLやOCSPレスポンスなどの失効情報も含めて保存しておけるようにCertificateValuesおよびRevocationValuesといった格納場所を設けています。

長期署名ではRFC 3161タイムスタンプトークンを利用するため、同様にタイムスタンプ局のTSA証明書の検証情報を格納しておいた方がおススメです。後になって必要なCRLやOCSPレスポンスを得ようとしても得られない事もありますから。

XAdESには以下のタイムスタンププロパティがあります。(概ね付与する時系列順)


AllDataObjectsTimeStamp (略記DataTS)
署名する文書やデータを含む全てのds:Objectに対する署名前のタイムスタンプ (全文書があった時刻を特定)
IndividualDataObjectsTimeStamp (略記DataTS)
署名する文書やデータを含む個々のds:Objectに対する署名前のタイムスタンプ (一部の文書があった時刻を特定)
SignatureTimeStamp (略記SigTS)
署名値に対するタイムスタンプ (署名時刻を特定)
SigAndRefsTimeStamp (略記RefTS)
署名値と署名者証明書の検証情報の参照情報に対するタイムスタンプ
RefsOnlyTimeStamp (略記RefTS)
署名者証明書の検証情報の参照情報に対するタイムスタンプ
ArchiveTimeStamp (略記ArcTS)
アーカイブタイムスタンプ (略記Arc2TS)
xades141:ArchiveTimeStampV2
XAdES v1.4.1のアーカイブタイムスタンプ


JIS X 5093 XAdESプロファイルでは以下の4つの場所に格納できるという例を示しています。

XAdESのTS検証情報格納場所




方法１
XAdESのXML署名のKeyInfo要素に格納
方法２
XAdESの非署名プロパティCertificateValues、RevocationValues要素に格納する
方法３
タイムスタンプトークンのCMS構造のcertificates, crlsフィールドに格納する
方法４
タイムスタンプトークンのCMS構造の非署名属性CertificateValues、RevocationValuesに格納する


それぞれ格納できるものの制限や長所、短所があって、どれを使うかは難しいです。

方法1(KeyInfo格納)の長所



・XMLDSigで署名されていなければDataTS,SigTS,RefTS,ArcTSの検証情報は格納できる
・XMLDSigの知識で格納できるので、扱いやすい(かも)

方法1(KeyInfo格納)の短所



・XMLDSigで署名されている場合、DataTSしか入れられない
・ArcTSの検証情報は入れられない
・OCSPレスポンスは入らない
・署名者証明書や幾つかのタイムスタンプトークンのTSA証明書の検証情報が
　　混在するので、特に失効情報でどれを使うかの区別が難しい。
・基本的には署名者証明書の格納場所とすべき
・総合的に見てあまりおススメしない

方法2(署名者のCertVals,RevVals格納)の長所



・証明書、CRL、OCSPレスポンス全て格納できる
・仕様をそのまま解釈すると、ここに入れるのもそれほど悪くない。
・DataTS、SigTSの検証情報は入れられる
・OCSPレスポンスも入れられる

方法2(署名者のCertVals,RevVals格納)の短所



・ETSI TC ESIでは、ここにタイムスタンプの検証情報を入れるのは
　　「仕様の拡大解釈である！」とコメントした人もおり
　　ETSI ESIではこれを認めないという見解
・RefTS、ArcTSについては入れられない

方法3(トークンのcerts,crlsフィールド格納)の長所



・CAdESの知識は無くともCMS SignedDataの知識で証明書、CRLは格納可
・何より検証したいトークンの中に検証情報を含められ情報を整理しやすいし、
　　わかりやすい
・DataTS以外のSigTS、RefTS、最新を除く全世代のArcTSについて
　　検証情報を格納できる

方法3(トークンのcerts,crlsフィールド格納)の短所



・(新しい標準が無いと)OCSPレスポンスの格納ができない
・DataTSの検証情報は格納できない
・certificates, crls フィールドはBER SET OFなのでBER/DER問題が起きることも
・XAdESの実装者はTimeStampTokenのCMS署名構造を変更したくない
・TSA事業者はTimeStampTokenに変更を加えることを良く思っていない。
　　TSAではトークンの変更は非サポートと言われることもある。

方法4(トークンのCertVals,RevVals属性への格納)の長所



・証明書、CRL、OCSPレスポンス全て格納できる
・何より検証したいトークンの中に検証情報を含められ情報を整理しやすいし、
　　わかりやすい
・DataTS以外のSigTS、RefTS、最新を除く全世代のArcTSについて
　　検証情報を格納できる

方法4(トークンのCertVals,RevVals属性への格納)の短所



・DataTSの検証情報は格納できない
・XAdESの実装なのにCAdESの属性の処理まで必要になる。
・XAdESの実装者はTimeStampTokenのCMS署名構造を変更したくない
・ここに格納された検証情報を見ないXAdES実装はかなり多い。
・TSA事業者はTimeStampTokenに変更を加えることを良く思っていない。
　　TSAではトークンの変更は非サポートと言われることもある。

とまぁ、こんな感じです。

どれが良いかは迷うところですが、XAdES v1.3.2の時点では、方法3が割とマシではと考えており、これをサポートする国内実装も割と多いようです。その理由はこんなとこかなと思います。

・JISプロファイルの要件であるSigTS、ArcTSについてきちんと検証情報を格納できる
・DataTSはあまり使われないので気にする必要がない
・タイムスタンプトークンの検証情報はその近くに置いた方が情報整理がしやすい

国内XAdES実装ではCMS署名を変更を含めちゃんと扱えるので、方法3が流行っているのかなぁ、、、と思います。

ただ、海外XAdES実装ではCMS署名構造であるTimeStampTokenを変更することへの技術的な敷居の高さから、別に格納方法を設けて欲しいという要望があり、また、日本のタイムスタンプ事業者のタイムスタンプトークンの検証情報を何か別に設けて欲しいという要望もETSI ESIのXAdESのエディタに伝えました。

その結果できたのが、XAdES v1.4.1 のタイムスタンプトークン用の検証情報の新しい格納場所です。これが、嵐を呼ぶわけですが次回以降解説していこうと思います。