自堕落な技術者の日記

PDFやPDF署名については全く素人なんですが、ちょっとずつ勉強しながらPAdES(PDF長期署名)を何回かに分けて紹介してみたいと思います。（＾＾；

PAdESとは

【PAdESとは】
PDF署名の拡張です。署名をする人の情報を後で書き換えられないように詳しく記述でき、数十年といった長い期間、元の文書が書き換えられていないことを保証できます。

PDFファイルは、標準でデジタル署名をつけることができます。デジタルタイムスタンプもつけることができます。

・誰がいつ署名したか
・どんな目的で署名したか
・署名した場所、連絡先情報
・デジタル署名されて以降、(署名された部分の)文章が変更されていない事の証明

欧州ではデジタル署名が手書きの署名と同じぐらい(法的に)信用できるようにするには「デジタル署名が適格電子署名(Qualified Electronic Signature)でなければならない」としています。デジタル署名が適格電子署名であるための条件は次の3つとなっています。

(1)本人性を厳密に確認する適格証明書(Qualified Certificate)を用いて署名すること。
(2)署名者が特定できる高度電子署名(Advanced Electronic Signature)を用いること。
(3)スマートカード、(ハード/ソフト)トークンなどセキュアな署名デバイスを用いること。

上記(2)の署名者本人が本当に行ったと特定できるようにするためには

(2-1)証明書が失効していた場合、署名が失効の前に行われたか後ろかを判断できる。
(2-2)もし証明書の有効期間後も検証できる必要がある場合
　(2-2-1)証明書の有効期間後も、証明書が有効な時刻に署名が行われた事を判断できる。
　(2-2-2)将来、コンピュータの処理能力や解析技術が向上して暗号アルゴリズムが
　　　　　破られたとしても、当時署名が有効であったかどうかを判断できる。
(2-3)署名に用いた証明書や認証パス、失効情報が不正に置き換えられてないか判断できる。
(2-4)本人を特定するために必要な属性情報
　　　(署名者の所属,職位,資格,署名場所,署名目的など)

ETSI TC ESI(欧州通信規格協会 電子署名基盤技術委員会)は、欧州電子署名指令に対応できるよう、従来型のCMS(PKCS#7)、XML署名に対して以下のような拡張を行い、これを標準としました。これが、CAdES、XAdESと呼ばれる長期署名フォーマットです。
・署名者や署名そのものの追加情報
・デジタルタイムスタンプ等の技術を用い証明書の期限切れ、
　暗号アルゴリズムの危殆化に対して署名を長期的に保護する。

PDF署名においても同様の拡張ができるようにAdobeのPDF署名の専門家がETSI TC ESIに加わって共同で策定したのがPAdES(PDF長期署名フォーマット ETSI TS 102 778-1〜5)です。

次回はPDF署名の仕組みについて紹介できたらと思っています。

ではでは。

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

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

それでは。

sourceforge.com: AS2 e-commerce RFC-4130
This piece of code uses Perl and qx// calls to OpenSSL and to other small Perl scripts, to follow the RFC-4130. At the time this project was opened, the product works ok when receiving messages. Read the README file inside the tar.gz for details

電子商取引っていう言葉はなんか古臭くてアレですが、いろんな仕組みができては消えたりしています。現在のところメジャーに見えるのは、

・ウェブEDI - ウェブアプリケーションとして実装されたEDI(セキュリティが弱い？)
・AS2 (RFC 4130) - IETFで定められ米国ではメジャーになりつつあるEDI
・OASIS ebXML - XMLベースのEDI (欧州の中堅の国で頑張っているが、、、)
・UN/EDIFACT - この中では割と歴史も実装もあるEDI (仕組みが古いかも)

そんな中、sourceforge上で、OpenSSLとPerlベースのRFC 4130 AS2のオープンソース実装のプロジェクトas2openssl(AS2 e-commerce RFC 4130が行われて、OpenSSLのMLでテスター/評価をしてくれる人を募集しているようです。

ISO TC154総会に行った際、CAdES/XAdESはOASIS ebXML、UN/EDIFACTには適用できそうだという話は日本(JISC)からしてきたんですが、AS2についてもメッセージのやりとりはMIMEベースらしいので、S/MIMEにしてしまえばCAdESで対応できるのかなぁ、、、と思っており、TC154議長にも、そう説明しました。

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

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

5月にも一度投票があり結局、積極参加が1ヶ国足らずにダメだったんですが、各方面のアドバイス通り、議長など粘り強くいろいろして下さった結果、追加の積極参加が1ヶ国あって、New Work Itemとして7月14日に ISO/TC154/SCで承認されたとTC154の議長さんから連絡が来ました。

そ〜〜です、CAdESとXAdESのJISプロファイルが3年後にはISOになるっつ〜〜〜〜ことなんですよ、おと〜〜〜さん。(トホホ)・・・・（Ｔ＿Ｔ）

■タイトル
Long Term Signature Profiles for EDI Data and Electronic Documents

■投票結果
Pメンバー19 / 賛成10 / 反対1 / 棄権8

■積極参加(エキスパートを出してくれる国)
・中国(SAC)
・チェコ(UNMZ)
・ドイツ(DIN)
・日本(JISC)
・ベトナム(STAMEQ)

2010年1月15日までに最初のドラフトを出さないといけないんだそう、、、、

いつのまにかexpertに入れられちゃってるし、、、(＞＞自分)、、、、日本提案だからワーキングのリーダーっつ〜〜ことになるんだよなぁ、、、、（はぁ)

そんなにワークが割けるんかいな、、、と、とて〜〜〜〜〜も不安、、、、、New Work Itemが承認されて、とて〜〜〜も複雑、、、、、

Twitterでも書きましたが、この前、ETSIから突然郵便が来て(前回はUPSだったのに今回はクロネコだったのも謎なんですが、、、)このような立派な紙で金のロゴなどついたカードが送られてきました。

なんかNDAに違反するようなことをしでかしたのか、、、とか、、、ヒヤヒヤしました。

"This is to certify that ..."

「STF 351 で貢献したことを証明します」みたいなカードのようです。「誰にもいいません(よ)」カードみたいなもんですな。「お持ちになってて下さい。」みたいな、、、、

はじめに

先日、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回のプラグテストの結果やコメントを反映させ改訂させたものなんですが、個人的には改悪だなぁ、、と思っているものです。

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

Since cryptographic algorithms can become weak over the years, it is necessary to evaluate their security suitability. When signing or verifying data, or when encrypting or decrypting data, these evaluations must be considered. This document specifies a data structure that enables an automated analysis of the security suitability of a given cryptographic algorithm at a given point of time which may be in the past, at the present time or in the future.

IETF LTANS WGから「Data Structure for the Security Suitability of　Cryptographic Algorithms (DSSC)」というインターネットドラフトのアップデートが出ております。もう8版になるに全く知りませんでした。

http://www.ietf.org/internet-drafts/draft-ietf-ltans-dssc-08.txt

主にドイツで使われている電子文書の長期アーカイビングの仕組みであるLTANSのための、使われる暗号アルゴリズムのポリシーを記述できるデータフォーマットのようです。これ記述して将来のアルゴリズム危殆化に備えましょうみたいな、、、、

う〜む、これって暗号アルゴリズムに特化したIETFやETSIの署名ポリシのサブセットみたいに見えますね。署名ポリシはトラストアンカなんかも書けるんですけどね、、、、