前回からさらに時間があいてしまいごめんなさい。
前回はXAdES v1.3.2までのタイムスタンプトークンの検証情報を格納する場所について紹介し、それぞれどんな問題があるのかって話をしました。
今回は新しいXAdES v1.4.1でタイムスタンプトークンの検証情報の格納するために新たに設けられたxades141:TimeStampValidationDataプロパティについて紹介していこうと思います。
名前空間の話は別の機会に詳しくしようと思いますが、XAdES v1.3.2以降は、使われている基本的なXML要素の名前空間は1.3.2のまま変えず、新しく定義された要素についてのみ新しい名前空間を使用するような方針となりました。
これまでXAdESの各バージョンにおいて要素の処理方法が全く同じにもかかわらず名前空間が違ってしまい、互換性を欠く、処理方法は同じなのに違うバージョンのXAdESを処理できないといった問題がありました。これは、日本からずっと申し入れてきたXAdESの後方互換性を高く保てるようにするため
です。(ちょっと誤解されていて面倒臭いことになっちゃったんですが、それはまた別の機会にします。)
新しく作られた名前空間の異なるTimeStampValidationData要素なんですが、UnsignedSignatureProperties要素の中に入れることができます。
UnsignedSignaturePropertiesのXMLスキーマ定義なんですが、こんな感じになっていて
UnsignedSignaturePropertiesにはXAdESの要素については上に書いてあるものをいくつでも順不問で入れることができて、名前空間が違うなら何でも入れてよいと
書いてあります。この定義を使って、XAdES v1.4.1より導入された名前空間の違うxades141:TimeStampValidationDataやxades141:ArchiveTimeStampV2が入れられるわけです。
では、最初に TimeStampValidationData を使って署名タイムスタンプ(SignatureTimeStamp)の検証情報を入れてみましょう。

これがAllDataObjectsTimeStampの場合にはこんな感じで参照するタイムスタンププロパティのIDを明示的に指定することができます。

xades141のスキーマ定義ではIDの参照は"UR"になっていますが、"URI"の誤りだと思います。
v1.4.1の仕様から、このTimeStampValidationDataの入れ物の特徴を取り出してみると:
・一つの入れ物を共用して複数のトークンのTSA証明書検証情報を入れることもできる
・TimeStampValidationDataを複数持たせトークン毎に検証情報をわけることもできる
・分ける場合には、参照先のIDを指定することができる
・AllDataObjectsTimeStampとIndividualDataObjectsTimeStampの場合には
参照先のIDを明示したほうがよい
てな感じになっています。
さて、新たにXAdES v1.4.1ではTimeStampValidationDataという専用の検証情報格納場所が提供されるようになったわけですが、これと、これまでに可能であった格納場所とを比較してみましょう。
ざっくり表にまとめてみました。

XAdESを生成する環境条件によって、どの格納方法が使えるのか変わってくるので、この表を見て選んでもらえればと思います。
個人的な評価から言えば(OCSPを使わず、署名タイムスタンプとアーカイブタイムスタンプしかないという前提で)、タイムスタンプトークンのcertificates、crlsフィールドに格納するのが一番良いんじゃないかと思っています。
新しく導入されたTimeStampValidationDataのダメなのは:
・ArchiveTimeStampやxades141:ArchiveTimeStampV2では使えない
・全ての検証情報を一緒くたに入れられてしまう可能性がある
・検証情報とタイムスタンプが近くにないと整理し辛い
と、あまり良いところがありません。
それなのに、このTimeStampValidationDataを保護するために、xades141:ArchiveTimeStampV2を導入し、古いArchiveTimeStampを非推奨(deprecated)としてしまったのです。
昔のXAdES署名文書のマイグレーションを無視した残念な改訂であると言わざるを得ません。
次回は、v1.3.2とv1.4.1のアーカイブスタンプの説明とTimeStampValidationDataとの関係を説明したいと思います。
それでは。
前回はXAdES v1.3.2までのタイムスタンプトークンの検証情報を格納する場所について紹介し、それぞれどんな問題があるのかって話をしました。
今回は新しいXAdES v1.4.1でタイムスタンプトークンの検証情報の格納するために新たに設けられたxades141:TimeStampValidationDataプロパティについて紹介していこうと思います。
xades141:TimeStampValidationDataプロパティの格納場所
名前空間の話は別の機会に詳しくしようと思いますが、XAdES v1.3.2以降は、使われている基本的なXML要素の名前空間は1.3.2のまま変えず、新しく定義された要素についてのみ新しい名前空間を使用するような方針となりました。
これまでXAdESの各バージョンにおいて要素の処理方法が全く同じにもかかわらず名前空間が違ってしまい、互換性を欠く、処理方法は同じなのに違うバージョンのXAdESを処理できないといった問題がありました。これは、日本からずっと申し入れてきたXAdESの後方互換性を高く保てるようにするため
です。(ちょっと誤解されていて面倒臭いことになっちゃったんですが、それはまた別の機会にします。)
新しく作られた名前空間の異なるTimeStampValidationData要素なんですが、UnsignedSignatureProperties要素の中に入れることができます。
UnsignedSignaturePropertiesのXMLスキーマ定義なんですが、こんな感じになっていて
出典:ETSI TS 101 903 v1.4.1 (or v1.3.2)
<xsd:element name="UnsignedSignatureProperties" type="UnsignedSignaturePropertiesType"/>
<xsd:complexType name="UnsignedSignaturePropertiesType">
<xsd:choice maxOccurs="unbounded">
<xsd:element name="CounterSignature" type="CounterSignatureType"/>
<xsd:element name="SignatureTimeStamp" type="XAdESTimeStampType"/>
<xsd:element name="CompleteCertificateRefs" type="CompleteCertificateRefsType"/>
<xsd:element name="CompleteRevocationRefs" type="CompleteRevocationRefsType"/>
<xsd:element name="AttributeCertificateRefs" type="CompleteCertificateRefsType"/>
<xsd:element name="AttributeRevocationRefs" type="CompleteRevocationRefsType"/>
<xsd:element name="SigAndRefsTimeStamp" type="XAdESTimeStampType"/>
<xsd:element name="RefsOnlyTimeStamp" type="XAdESTimeStampType"/>
<xsd:element name="CertificateValues" type="CertificateValuesType"/>
<xsd:element name="RevocationValues" type="RevocationValuesType"/>
<xsd:element name="AttrAuthoritiesCertValues" type="CertificateValuesType"/>
<xsd:element name="AttributeRevocationValues" type="RevocationValuesType"/>
<xsd:element name="ArchiveTimeStamp" type="XAdESTimeStampType"/>
<xsd:any namespace="##other"/>
</xsd:choice>
<xsd:attribute name="Id" type="xsd:ID" use="optional"/>
</xsd:complexType>
UnsignedSignaturePropertiesにはXAdESの要素については上に書いてあるものをいくつでも順不問で入れることができて、名前空間が違うなら何でも入れてよいと
<xsd:any namespace="##other"/>
書いてあります。この定義を使って、XAdES v1.4.1より導入された名前空間の違うxades141:TimeStampValidationDataやxades141:ArchiveTimeStampV2が入れられるわけです。
xades141:TimeStampValidationDataを実際に使う
では、最初に TimeStampValidationData を使って署名タイムスタンプ(SignatureTimeStamp)の検証情報を入れてみましょう。

これがAllDataObjectsTimeStampの場合にはこんな感じで参照するタイムスタンププロパティのIDを明示的に指定することができます。

xades141のスキーマ定義ではIDの参照は"UR"になっていますが、"URI"の誤りだと思います。
v1.4.1の仕様から、このTimeStampValidationDataの入れ物の特徴を取り出してみると:
・一つの入れ物を共用して複数のトークンのTSA証明書検証情報を入れることもできる
・TimeStampValidationDataを複数持たせトークン毎に検証情報をわけることもできる
・分ける場合には、参照先のIDを指定することができる
・AllDataObjectsTimeStampとIndividualDataObjectsTimeStampの場合には
参照先のIDを明示したほうがよい
てな感じになっています。
タイムスタンプ検証場所の比較
さて、新たにXAdES v1.4.1ではTimeStampValidationDataという専用の検証情報格納場所が提供されるようになったわけですが、これと、これまでに可能であった格納場所とを比較してみましょう。
ざっくり表にまとめてみました。

XAdESを生成する環境条件によって、どの格納方法が使えるのか変わってくるので、この表を見て選んでもらえればと思います。
個人的な評価から言えば(OCSPを使わず、署名タイムスタンプとアーカイブタイムスタンプしかないという前提で)、タイムスタンプトークンのcertificates、crlsフィールドに格納するのが一番良いんじゃないかと思っています。
新しく導入されたTimeStampValidationDataのダメなのは:
・ArchiveTimeStampやxades141:ArchiveTimeStampV2では使えない
・全ての検証情報を一緒くたに入れられてしまう可能性がある
・検証情報とタイムスタンプが近くにないと整理し辛い
と、あまり良いところがありません。
それなのに、このTimeStampValidationDataを保護するために、xades141:ArchiveTimeStampV2を導入し、古いArchiveTimeStampを非推奨(deprecated)としてしまったのです。
昔のXAdES署名文書のマイグレーションを無視した残念な改訂であると言わざるを得ません。
次回は、v1.3.2とv1.4.1のアーカイブスタンプの説明とTimeStampValidationDataとの関係を説明したいと思います。
それでは。