また、前回から随分時間が空いてしまいました。
XAdES v1.4.1改訂の問題点の続きです。
前回は、以下のXAdESタイムスタンププロパティに含まれるRFC 3161タイムスタンプトークンのTSA証明書の検証情報(認証パスと失効情報)を格納するために、タイムスタンプトークン自体に追加しなくていいようにv1.4.1ではTimeStampValidationDataという新しいプロパティが導入されたという話をしました。
・AllDataObjectsTimeStamp
・IndividualDataObjectsTimeStamp
・SignatureTimeStamp
・SigAndRefsTimeStamp
・RefsOnlyTimeStamp
XAdES 1.3.2(もしくは名前空間の異なるそれ以前のバージョン)のArchiveTimeStampは、同じ名前空間の明示的に指定されたXAdESプロパティしかアーカイビングの対象になっていませんでした。
それは XAdES v1.3.2 を含むそれ以前のバージョンでは、どの(同一名前空間の)XAdESプロパティを保護するかということが明示的に規定されていたからです。
CAdESのバージョンの差異をご存知の人はCAdES v1.4.3とv1.5.1のArchiveTimeStampの違いに似ているといえば理解できるかもしれません。(計算方法が違うのに同じOIDにしたため相互運用性の問題が生じたため日本から根気強く提言したことで別のOID ArcvhiveTimeStampV2 が付与されるようになりました。)
ところが、XAdES v1.4.1 では、殆どのXAdESプロパティが前のバージョンと同じ v1.3.2の名前空間のプロパティに加え、先の名前空間がv1.4.1用で異なるTSA証明書検証情報のTimeStampValidationDataプロパティが加えられたので、v1.3.2のArchiveTimeStampではこれを保護することができません。
そこで、新しいxades141:ArchiveTimeStampV2では、UnsignedSignatureProperties要素の子要素であるプロパティ全てに対して(名前空間の別に関係なく)、自身とそれ以降のアーカイブタイムスタンプを除きアーカイブタイムスタンプの対象とします。
これで、新しいxades141:TimeStampValidationDataプロパティもちゃんとアーカイブタイムスタンプで保護されるようになったわけです。
xades141:ArchiveTimeStampV2とxades132:ArchiveTimeStampプロパティの違いをまとめてみると
結局、現状ではTimeStampValidationDataを保護できるか程度の違いしかありません。
タイムスタンプトークン自体に検証情報を含める方式を採用したとすれば、TimeStampValidationDataを使用しないためxades132:ArchiveTimeStampとxades141:ArchiveTimeStampV2とで、新しい方式に移行するメリットは全くありません。
それにもかかわらず、XAdES v1.4.1 では古いxades132:ArchiveTimeStampの利用を非推奨(deprecated)としているのです。
つまり新しい仕様では古いバージョンのアーカイブタイムスタンプは非推奨としているため、古いバージョンのXAdESから新しいXAdES 1.4.1への移行パスが絶たれています。
長期署名フォーマットは数十年といった長期スパンで電子文書を保存できる技術なわけですが、これだけ頻繁にフォーマットが改訂され、後方互換性を欠いたものになっていると、将来的に過去のXAdESフォーマットを正しく検証できる実装は少なくなってきます。
ちなみに、バイナリ形式のCAdESでは名前空間の概念が無いので、属性の検証方法が同じならば実装を作り直す必要もありませんし、基本的には高い後方互換性を持っています。
今後のXAdESのバージョン改訂について、私個人の主張は以下の通りです：
XAdESの厄介だと思うのはXMLDsig(XML署名)の仕様に強く依存しており、XMLDSig自体の後方互換性にも配慮しなければならない点です
XAdES v1.4.1では要素のスキーマ定義は後方互換性のため v1.3.2の定義をそのまま利用し、v1.4.1で新設された要素だけを追加定義しています。
・xades141:TimeStampValidationData
・xades141:ArchiveTimeStampV2
ここで2つの仕様上の誤りがあります。
今回の XAdES v1.4.1 の改訂をまとめてみると
・XAdES v1.3.2 の名前空間はそのまま利用し後方互換性に配慮したが、
・xades141:ArchiveTimeStampV2の導入により結局は後方互換性を欠いており、
・アーカイブタイムスタンプの検証は入れる場所も無い
・スキーマ定義も間違っている
という、何ともトホホな改訂になっているわけです。
長くなったので、今日はここまでにしたいと思います。
次回以降、二回ぐらいに分けて
・XAdESなどに適した後方互換性に配慮したXMLスキーマの改訂のガイドライン
・本当はXAdES v1.4.1は、どのように改訂すればよかったのか
について書く予定でいます。
XAdES v1.4.1改訂の問題点の続きです。
前回は、以下のXAdESタイムスタンププロパティに含まれるRFC 3161タイムスタンプトークンのTSA証明書の検証情報(認証パスと失効情報)を格納するために、タイムスタンプトークン自体に追加しなくていいようにv1.4.1ではTimeStampValidationDataという新しいプロパティが導入されたという話をしました。
・AllDataObjectsTimeStamp
・IndividualDataObjectsTimeStamp
・SignatureTimeStamp
・SigAndRefsTimeStamp
・RefsOnlyTimeStamp
旧XAdES 1.3.2のArchiveTimeStamp
XAdES 1.3.2(もしくは名前空間の異なるそれ以前のバージョン)のArchiveTimeStampは、同じ名前空間の明示的に指定されたXAdESプロパティしかアーカイビングの対象になっていませんでした。
それは XAdES v1.3.2 を含むそれ以前のバージョンでは、どの(同一名前空間の)XAdESプロパティを保護するかということが明示的に規定されていたからです。
CAdESのバージョンの差異をご存知の人はCAdES v1.4.3とv1.5.1のArchiveTimeStampの違いに似ているといえば理解できるかもしれません。(計算方法が違うのに同じOIDにしたため相互運用性の問題が生じたため日本から根気強く提言したことで別のOID ArcvhiveTimeStampV2 が付与されるようになりました。)
ところが、XAdES v1.4.1 では、殆どのXAdESプロパティが前のバージョンと同じ v1.3.2の名前空間のプロパティに加え、先の名前空間がv1.4.1用で異なるTSA証明書検証情報のTimeStampValidationDataプロパティが加えられたので、v1.3.2のArchiveTimeStampではこれを保護することができません。
新XAdES v1.4.1のArchiveTimeStampV2
そこで、新しいxades141:ArchiveTimeStampV2では、UnsignedSignatureProperties要素の子要素であるプロパティ全てに対して(名前空間の別に関係なく)、自身とそれ以降のアーカイブタイムスタンプを除きアーカイブタイムスタンプの対象とします。
これで、新しいxades141:TimeStampValidationDataプロパティもちゃんとアーカイブタイムスタンプで保護されるようになったわけです。
xades141:ArchiveTimeStampV2とxades132:ArchiveTimeStampプロパティの違いをまとめてみると
結局、現状ではTimeStampValidationDataを保護できるか程度の違いしかありません。
xades141:ArchiveTimeStampの問題点
タイムスタンプトークン自体に検証情報を含める方式を採用したとすれば、TimeStampValidationDataを使用しないためxades132:ArchiveTimeStampとxades141:ArchiveTimeStampV2とで、新しい方式に移行するメリットは全くありません。
それにもかかわらず、XAdES v1.4.1 では古いxades132:ArchiveTimeStampの利用を非推奨(deprecated)としているのです。
つまり新しい仕様では古いバージョンのアーカイブタイムスタンプは非推奨としているため、古いバージョンのXAdESから新しいXAdES 1.4.1への移行パスが絶たれています。
長期署名フォーマットは数十年といった長期スパンで電子文書を保存できる技術なわけですが、これだけ頻繁にフォーマットが改訂され、後方互換性を欠いたものになっていると、将来的に過去のXAdESフォーマットを正しく検証できる実装は少なくなってきます。
「XMLは可読性が高いためXAdESは将来的に長期に渡り改竄されていないことを証明できる」という人がいますが、本当にそうなのかな、、と思うわけです。10年先、当時のバージョンのXAdESを正しく検証できる実装なんて残っていないのではないかと、、、現行のv1.3.2の実装だって、XAdESの1.3.2より前の署名も合わせて検証できるような実装なんて一つも無いはずです。
ちなみに、バイナリ形式のCAdESでは名前空間の概念が無いので、属性の検証方法が同じならば実装を作り直す必要もありませんし、基本的には高い後方互換性を持っています。
XAdESの改訂の方針に対する主張
今後のXAdESのバージョン改訂について、私個人の主張は以下の通りです：
- 大して良くなりもしないなら改訂などする必要は全くない。
- 署名が長期にわたり検証できるように必ず後方互換性を持つ改訂とする。
- 古いバージョンから新しいものへ移行するためのパスを必ず提供する。
- バージョンの異なるアーカイブタイムスタンプのの混在を許す設計が必須。
XAdESの厄介だと思うのはXMLDsig(XML署名)の仕様に強く依存しており、XMLDSig自体の後方互換性にも配慮しなければならない点です
XAdES v1.4.1のスキーマ定義の誤り
XAdES v1.4.1では要素のスキーマ定義は後方互換性のため v1.3.2の定義をそのまま利用し、v1.4.1で新設された要素だけを追加定義しています。
・xades141:TimeStampValidationData
・xades141:ArchiveTimeStampV2
ここで2つの仕様上の誤りがあります。
- 誤り１：ArchiveTimeStampV2かArchiveTimeStampか
- ETSI TS 101 903 XAdES v1.4.1では、新設されたアーカイブタイムスタンプ要素の名前をxades141:ArchiveTimeStampとしていますが、スキーマ定義ではxades141:ArchiveTimeStampV2となっています。名前空間だけで区別するというXML流のやり方はXAdESの長期保存にはそぐわないなめ、V2とする方を選ぶべきだと思います。仕様のエディタに確認します。
- 誤り２：TimeStampValidationDataの参照属性
- どのタイムスタンプの検証情報か、その参照を表すため要素には"UR"属性が使えるとスキーマ定義にありますが、これは他の要素を見てみれば"URI"属性の誤りであると思われます。これもエディタに確認します。
XAdES v1.4.1の改訂の問題点のまとめ
今回の XAdES v1.4.1 の改訂をまとめてみると
・XAdES v1.3.2 の名前空間はそのまま利用し後方互換性に配慮したが、
・xades141:ArchiveTimeStampV2の導入により結局は後方互換性を欠いており、
・アーカイブタイムスタンプの検証は入れる場所も無い
・スキーマ定義も間違っている
という、何ともトホホな改訂になっているわけです。
長くなったので、今日はここまでにしたいと思います。
次回以降、二回ぐらいに分けて
・XAdESなどに適した後方互換性に配慮したXMLスキーマの改訂のガイドライン
・本当はXAdES v1.4.1は、どのように改訂すればよかったのか
について書く予定でいます。
