自堕落な技術者の日記

最近、ちらほらAdobe AIRを使ったプログラムが増えてきてますね。プログラムを配布する時はコードサイニングしないといけないという話はわかっていたんですが、まぁ、Adobe AIRの実行プログラム *.air は言っちゃえばjarファイルなもんでjarコマンドやZIP対応のアーカイバで解凍でき、Javaのjarに対する署名だとタカをくくっていたわけです。

久々にAdobe AIRの面白そうなプログラム「てれびなう」なんてものを見つけてしまったのでインストールしようとしたら、こんな画面が、、、

「発行者」とか「発行者ID：検証済み」とか出てますが、ボタンを押せば証明書やコード署名の内容が表示されるわけでもなく、どこから出た証明書でコード署名したもんか知る術がないので「こりゃ〜Adobe AIRは酷い作りだなぁ。何を信じていいのかわからないぢゃん」と思ったわけです。

折角なのでコード署名の中身を見てみるべ〜かなと"mv foo.air foo.zip"して解凍してみました。するとjarファイルよろしくMETA-INFがありまして

おお〜〜〜〜〜っ！！！ signatures.xml

XMLDSigなのか〜〜〜〜っ！！と鼻血が出そうになりながら中を覗いてみると

<Object xmlns:xades="http://uri.etsi.org/01903/v1.1.1#">

ずご〜〜〜〜っ！！！ETSI TS 101 903 XAdES 1.1.1ではないですか〜〜〜っ！！！ それも

<xades:SignatureTimeStamp>
 <xades:HashDataInfo uri="#PackageSignatureValue">
  <Transforms>
  <Transform
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
  </Transforms>
   <xades:EncapsulatedTimeStamp>

XML形式の長期署名フォーマットで署名タイムスタンプ付きXAdES-Tじゃないですか〜〜っ！！！うんうん、Microsoft Office 2010といい、これといい、ちゃんとこんなところでひっそり使われていたんだなぁ、、、(どんどん、仕様は改悪されていくような気はするけどね、、、)。こんなちゃんとした署名がついてるなら、署名者情報や認証された署名時刻を表示した方がいいんじゃないかなぁ、、、と強く思います。

XAdES-Tを検証してみたり、署名者証明書や署名タイムスタンプを取り出してエンジョイしました。見たコード署名はGeoTrust Timestamping Signer1のタイムスタンプがついてるんですが、このTSAポリシOIDが"1.1.2"って、TSAポリシが無いって事も同然の怪しさな気がします。

今晩はこんなとこで、、、

いつもXAdES関係でお世話になっているmiyachiさんのところでMicrosoft Office 2010でXAdES署名をするためのレジストリ設定ツールが公開されました。 そういえば、タイムスタンプの扱いについて「ある疑念」があったので、「そうそう試してみよう」とツールを使ってレジストリ設定をしてみたところちょっとうまくいかずに、報告したらソッコーで直して頂いちゃいました。すみませんでした。ありがとうございます。

で、「ある疑念」というのは

Office 2010では、タイムスタンプなんか検証してないし、解釈しようとすらしていないのでは？

ということなんです。今日は、これについて実際に試してみました。

検証内容

以下の内容で試してみました。

• テスト１：正常系：信頼するルートを辿って発行された署名タイムスタンプを付与した場合
• テスト２：異常系：信頼するルートを辿れないプライベートCAを辿って発行された署名タイムスタンプ
• テスト３：異常系：時刻が署名時刻と近くないgenTime=2001.01.01であるような署名タイムスタンプ

本当は他もやろうとおもったんですが、それについては後で、、、

テスト１、テスト２について

Office 2010の可視署名の機能をつかってパブリックルートの署名者証明書で、Officeに署名してみました。


署名してみると、タイムスタンプ局の証明書(TSA証明書)を発行するCAを信頼していようが、いまいが結果は同じで正しい署名であるかのように表示されます。ついでにタイムスタンプトークンの署名値を改ざんしたりもしてみましたが、やはり結果は同じです。

つまりOffice 2010 betaでは、タイムスタンプトークンの検証は一切行っておらず、不正なタイムスタンプが付与されていたとしても、表示は変わらず有効であるかのように見えてしまうようです。

テスト３

次に、TSA証明書のルートCAを信頼しているテスト用タイムスタンプ局から、genTimeがUTC 2001年1月1日正午であるようなタイムスタンプを発行しこれを署名タイムスタンプとして付与してみました。 付与したタイムスタンプのgenTimeは確かに

GeneralizedTime 01/01/2001 12:00:00 GMT

と異常に古い時刻に署名したことになっているはずなのですが、ご覧のように表示上は以下のようになっています。


つまり、タイムスタンプ局の発行する第三者から信頼される署名時刻が署名時刻として表示されるのではなく、PCのローカルの時計を元にした署名時刻のみが表示されるという事になります。また、Officeではどのタイムスタンプ局から発行されたトークンであるのかを知る術がありません。

Office 2010のXAdES機能の問題点

以上の実験からMicrosoft Office 2010のXAdES機能は、以下のような問題があることがわかりました。

• 署名タイムスタンプにより示される信頼できる署名時刻があるにもかかわらず、これは決して表示されることはない。
• それにも関わらずMicrosoft Office 2010の正式版では、署名タイムスタンプが付与されている場合、XAdES-TかXAdES-XかXAdES-XLであると表示されてしまう。XAdESを理解してる利用者は、表示された時刻が信頼できる署名時刻であるかのように誤解してしまうだろう。

上記の2つ目は、容易に誤解されることによりタイムスタンプ局、長期署名、XAdESの信頼を大きく揺るがす問題だと思いますし、このような状況でMicrosoft Office 2010がXAdESに対応していると呼ぶのは問題だと思います。

関連記事

• 2010.04.01 Microsoft Office 2010 BetaのXAdES機能

関連リンク

• MS technet: Digital Signatures in Office 2010
• LangEdge Blog:MS-Office2010の長期署名仕様解析 2010-06-11

2010年6月にリリースが予定されているMicorosoft Office 2010で、XML形式の長期署名フォーマットXAdESがサポートされるという記事をUさんから紹介頂いた。

ブラジル政府はタイムスタンプ付き署名に熱心でECOMのサイトを見て、ブラジルの方が長期署名フォーマットについて問い合わせをしてきたりしてました。この記事を見るにブラジル政府の文書管理のためにXAdESに対応したような感じもしますね。

Microsoft Office 2010のRTM版(初期版)とベータ版のXAdESの各フォーマットの対応

現在、Microsoft Office 2010のベータ版が試せるようになっていますが、RTM版の機能はXAdES-X-Longまでに対応しているのに対し、ベータ版ではXAdES-Tまでしか対応していないんだそうです。

Office 10ベータ版のXAdES機能を試す

誰でも登録すればダウンロードできるOffice 10のベータ版を使って、XAdES-EPES、XAdES-Tの機能を試してみた。本当はC、X、X-Longも見てみたかったんだけど、正式版を待つことにしましょう。

Office文書にXAdES-EPES、XAdES-Tで署名するにはレジストリの変更をするそうです。

XAdES-EPESにするには

HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\Signatures]
"XAdESLevel"=dword:00000001
"MinXAdESLevel"=dword:00000001

XAdES-Tにするには

HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\Signatures]
"XAdESLevel"=dword:00000002
"MinXAdESLevel"=dword:00000002
"TSALocation"="HTTPタイムスタンプサービスのURL"

のように設定すればよいようです。実際に

• レジストリ設定なし (XML-Dsig署名)
• レジストリ設定でLevel=1 (XAdES-EPES署名)
• レジストリ設定でLevel=2 (XAdES-T署名)

のように設定して署名を行ってみました。

Office 10ベータ版のXAdES署名を見る

ご存じのとおりMicrosoft Office 2007以降の.docx、.xlsxなどのドキュメントフォーマットはいろんなファイルをZIPアーカイブで固めたもののになっていて "_xmlsignature" フォルダに署名データが入ります。

Office 2010の生成するXAdES署名データの特徴

実際にレジストリ設定をしてXAdES-TとXAdES-EPESで署名されたWordファイルを生成して、そのXAdES署名データを見てみました。以下のような特徴がありました。

• XAdES v1.3.2 フォーマット
• ハッシュアルゴリズムはSHA1を使用
• 署名アルゴリズムはSHA1withRSAを使用
• XAdES-Tは、XAdES-T over EPES
• XAdES-EPES対応といってもSignaturePolicyImpliedがついているだけ

XAdES-EPESに対応しているというので、かなり期待していたんですが、実はSignaturePolicyImpliedがついているだけで、これは署名者と検証者で署名ポリシに対して暗黙の合意があることを意味しています。これって、Office文書の署名ポリシに対して何らかの暗黙の合意があるとはとても思えないのに勝手につけてしまうのはどうかと思うのと、SignaturePolicyImpliedをつけるぐらいなら、いっそ無くしてXAdES-BESでいいんじゃないかなぁと思いました。

生成されたXAdESフォーマットのプロファイル

XAdESのXML要素のプロファイルはこんな感じでした。

あと、スキーマチェッカにはまだかけてないんですが、XAdES-EPESにした時に空要素のUnsignedSignaturePropertiesがあるのはスキーマ違反だと思います。

タイムスタンプサーバーについてはHTTPで認証無しのRFC 3161タイムスタンププロトコルに対応してないといけないので、国内の認証有のタイムスタンプサービスでは(仕掛けを入れないと)使えないこともあるかもしれません。

問題点は？

Microsoft Office 2010のXAdES署名の機能を見て、いくつか気になった点が他にもあります。

署名日時の表示

Offce 2010の署名の表示において署名を行った時刻は日単位で表示されています。国内のタイムスタンプサービスが500ミリ秒から1秒の精度を持っているのに日単位でしか表示されないのはもったいない話です。

猶予期間の問題

自分がICカードを落としたとき、その失効申請がCRLに反映されるまで数営業日かかるというのが普通だと思います。失効情報はリアルタイムに反映されるとは限らないので長期署名では署名してからある時間経過した後に取得した失効情報を用います。これを猶予期間(Grace Period)と呼んでいます。おそらくMicrosoft Office 2010のXAdES-C以降では失効情報として署名時刻に取得した失効情報を使うと思われますが、これは適切な失効情報ではありません。

XAdES-C、XAdES-X、XAdES-X-Longを流通させていいのか？

XAdES-CやXAdES-Xでは後になって必要となる当時の失効情報が取得できないかもしれませんし、XAdES-X-Longの中の検証情報へのタイムスタンプは機能として中途半端です。そこで、JIS X 5093:2008ではドキュメント交換にふさわしい署名はXAdES-TもしくはXAdES-Aだと位置づけました。XAdES-C、XAdES-X、XAdES-X-Longは不完全な中間データにすぎず、何らかの仕組みでこれを補ってやる必要があるのです。

タイムスタンプ検証してないんじゃ？

タイムスタンプ局の証明書(TSA証明書)をどうも検証していないっぽいんです。TSA証明書用のルート証明書を信頼していなくても、なんら警告やエラーが表示されませんし、ドキュメントで表示される(署名時刻でなく(T_T))署名日も署名タイムスタンプではなくSigningTimeプロパティの値を表示しているんじゃないかという気がしています。タイムスタンプの無効系のテストは時間があればやってみたいと思います。

おわりに

レジストリをいじらないとXAdESにならないというのは、ちょっとトホホな感じですが、ともあれMicrosoft Officeが標準でXAdESに対応してきたというのは、すごい事だなぁ、、、と思います。少しずつ普及が進むといいんですけどね。

今日はこの辺で、、、

また、前回から随分時間が空いてしまいました。

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は、どのように改訂すればよかったのか

について書く予定でいます。

前回からさらに時間があいてしまいごめんなさい。

前回は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との関係を説明したいと思います。

それでは。

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

今回は、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の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 のタイムスタンプトークン用の検証情報の新しい格納場所です。これが、嵐を呼ぶわけですが次回以降解説していこうと思います。

はじめに

先日、XML署名を拡張した長期署名フォーマット ETSI TS 101 903 XAdES の改訂版 v1.4.1 が2009年6月25日頃公開されたとブログに書きました。今回の改訂はこれまでETSI TC ESI(電子署名基盤技術委員会)に送られたコメントや昨年度3回(も)実施したETSI Remote XAdES Plugtestsでのコメントを反映させたものになっているんですが、個人的な感想を言わせてもらうと

本当にXMLで長期保存する気あります？！ちゃんと検討しました？！

と言いたくなるような改訂なんです。

何回かの連載でETSI TS 101 903 XAdES v1.4.1 の改訂のポイントと問題点を説明したいと思います。

XAdESの説明をするときに「XMLは可読性が高いので長期保存に向いている」とか簡単に言っちゃう人がいますが、CAdESとXAdESの双方の実装をしてみて本当にそうなのかなぁ、、、と私は前から疑問に思ってました。今回の改訂で「ちょっとXAdESはダメかも、、、」と悲しくなった次第、、、、
＃もちろん問題の指摘は２年ぐらいかけて苦手な英語で今後もしていきますよ〜〜〜(でも心が折れそう、、、)

問題のポイントっていうのは、

• 長期の保管が目的なので、フォーマットには後方互換性があり長期に渡り検証ができるようになっていなければならない。複数バージョンのXAdESの混在が可能な設計でなければならない。


• XML(メッセージング)はトランザクション用途の方が重要で(スキーマとか)バージョンを厳密に区別するので、後方互換性を持ち長期に検証させるのは難しい


• 上記の問題は標準の設計を工夫すれば解決できたはずだが、設計者にその意識がないか希薄


• 実際、複数のバージョンのXMLのデータを扱うのはXMLの世界ではやや難しい


• XML署名の処理は基本的に複雑で、XAdESはさらに輪をかけて複雑

っていうとこにあるのかな、、、と、、、、こんなんじゃ、複数バージョンのXAdESを跨いで生成・検証できるのはそう多くは出てこないっすよ。

XAdES 1.3.2から1.4.1の改訂の概要

1.4.1への改訂内容は、77ページ Annex E (informative) "Main changes to XAdES v1.3.2" にまとめられています。細かい話が多いので要約するとざっくりこんなとこだと思います。

• xades141:ArchiveTimeStampの新設


• 古いxades132:ArchiveTimeStampは非推奨(deprecated)に。もっと古いのは言及すら無し。


• タイムスタンプトークンのTSA証明書のパス検証用情報格納のためにxades141:TimeStampValidationDataを新設


• 名前空間の扱いについての方針の記述


• 検証情報にOCSPレスポンスを含める場合、参照情報としてそのハッシュを含めることを強く推奨


• SigningTimeプロパティとタイムスタンプとの時間比較は署名ポリシーに委ねることとした


• スキーマ定義中の要素数の制約の数々の誤りの修正(minOccurs等)

そうなんです、ArchiveTimeStamp変わっちゃったんですよ〜〜〜。それも大きく（Ｔ＿Ｔ）変更の仕方はCAdES v1.4.0 から v1.5.1で大幅に変わって泣きをみましたが、その時と事情もかなり似ています（−−；(嵐を呼ぶぜぇ〜〜ぃっ！)

次回以降、改訂箇所を掘り下げていきましょう。

ではでは、、、

W3C XML署名を拡張した長期署名フォーマットXAdESの最新バージョン 1.4.1 がこの何日かでリリースされました。(先週末にはリリースされてなかったと思う)

http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=28064

メールアドレスさえ登録してあれば、無償でダウンロードできますので関心のある方はご覧ください。

この改訂版は昨年度 ETSI で行われた3回のプラグテストの結果やコメントを反映させ改訂させたものなんですが、個人的には改悪だなぁ、、と思っているものです。

詳しい話はまた後日、、、、

先月27日頃、ETSI TS 101 903 XAdESの改訂ドラフトが内々に回ってきましたが、レビューとコメント受付の期間が殆ど無いので多分このまま通っちゃうんでしょう、、、、、トホホ、

今回の改訂は仕様を深く理解していない人の意見をそのままあまり考えずに取り入れた改悪なような気が少ししています。正式に公開されたら、このブログで問題点を述べたいと思います。

STF351の実験の対応に忙殺されて、標準改訂に対して忙しすぎて全くコメントできなくて、後になってコメントすればいいやと考えていたのは間違いでした。残念、、、、、

自堕落な技術者の日記 : ETSI 3rd Remote XAdES/CAdES Plugtestが始まってます - livedoor Blog（ブログ）

2月16日に始まったETSI 3rd Remote XAdES/CAdES Plugtestsですが、3月4日に最終の検証結果の提出期限を終え、無事終了しました。参加された皆様、ご苦労さまでした。




今回は13ヶ国17組織が参加しました。全体が減っているおかげで日本からの参加の比率が「しっかりある」といった感じがしますね。珍しいところではトルコ政府機関の方が参加されたのは良かったかなと思っています。




参加総数は前回よりも徐々に減っていますが、実験の回数が無駄に多いから何回も参加する必要ないっていうのと、景気の影響もあるんですかね。




長期署名フォーマットにはXML署名の拡張であるXAdESと、CMS(PKCS#7)署名の拡張であるCAdESがあって、今回ETSIでは初めてのCAdESのテストで欧州でまともに参加実装が集まるんかいなと心配していたんですが、傾向的に長期署名に関心のある企業はCAdESもXAdESの双方に対応する企業が多いんだなぁ、、、という感じでした。
面倒だけど理屈さえわかっちゃえば、XMLだろうがCMSだろうが実装の手間は大差ないみたいなところはあるんでしょうかね、、、、

各実装でのありがちな誤りはこんなところ、、、

【CAdESでありがちな誤り】
・タイムスタンプ対象のMessageImprintの計算間違い
・BasicOCSPResponseでなくOCSPResponseを使っている
・署名ポリシIdのハッシュ計算や構造の誤り

【XAdESでありがちな誤り】
・DataObjectFormatの一致確認の誤り
・CertifiedRoleの属性証明書の誤り
・スキーマエラー
・入っている証明書・CRL・OCSPが間違っていたり

ECOMのテストデータを公開しているせいか、CAdESの誤りっていうのは初のETSIテストにもかかわらずあまりなくて驚きました。まぁ、ひどいところはひどいし、「前も指摘しましたよねぇ、、、直ってないじゃん、、、」みたいなのはあります。

ASN.1 BER・DERの議論も、もっと出てくるかなと思ったんですが、指摘すると「あ、そうですね」みたいな感じで素直に直ってくるので揉め事も少ないような気もしました。

自分の実装は、検証部分を大きく作り直したりしたんですが、テスト参加回数も大小あわせて７回ぐらいになるので実装的には枯れてきていてテストでバグが見つかったりとかも無く、単に設定上の誤りがあった程度でした。




ETSIのテストケースは標準で定義された全て要素を扱っていてテストケースへの対応状況表はこんな感じ、、、、うちのは無駄に100%フル実装してますな。（＾＾；

個人的には、イベントを主催している側の意識が仕様の改訂のネタ出しが主目的になっていてお金を払っている参加企業への配慮を非常に欠いているのと、お金を払ってまでヒトのバグを直しているような気分になるのがちょっとなぁ、、、という気がしました。eEuropeがスポンサーになっているそうなんですけど、参加費まで取ってるし、日本からの実験準備・技術提供とかも全てボランティアなのに、スポンサー費用って一体何に使われてるんでしょうねぇ、、、、

随分前にコトリグラフという3Dグラフ作成ソフトを買ってから何でもとりあえずグラフにしたくなってます（＾＾；