さて昨日の続きです。おさらいをするとPKCS#7(CMS)を利用するPDF署名は素直に拡張するならPKCS#7の署名データをCAdESの長期署名データに変更すれば良いと思えます。しかしCAdESを全面採用できない事情が存在します。それはPDF署名が署名対象範囲を指定するのに使っているバイトレンジ指定の仕組みです。

PDF署名において署名データはPDFの中に埋め込まれます。しかし署名データは署名対象にはもちろん出来ません。つまり署名データの前と後ろの部分が署名対象になります。署名対象範囲はバイトレンジ（署名辞書内のByteRangeキー)で指定される４つの数字で示します。

　ByteRange [ 開始位置１　長さ１　開始位置２　長さ２ ]

開始位置と長さの２つの数値のペアになっています。これで署名データの上と下を指定できますね。めでたしめでたし… なのですが１つ問題があります。それは、

　「署名データのサイズは署名時（正確には署名前）に決定する必要があり後から変更やリサイズは出来ない」

と言うことです。バイトレンジの部分も署名対象の一部です。従って後から署名対象範囲の変更は出来ません。また開始位置とはファイル先頭からの指定です。従って前後２つの部分に挟まれた署名データ部分のサイズは署名後は変更できません。通常PDF署名ではある程度ゆとりを見て署名データ部のサイズを確保しておきます。署名データとせいぜいタイムスタンプくらいなら数キロバイト単位で確保しておけば充分です。

次に長期署名の仕組みを見てみましょう。JIS化されている仕様は大きく分けて以下の２種類です。

　１） ES-T： [ 署名 ＋ 署名タイムスタンプ ]
　２） ES-A： [ ES-T ＋ 証明書群 ＋ 検証情報 ＋ 保管タイムスタンプ ]

ES-Tの方は既存のPDF署名のPKCS#7でも細部は異なりますがほぼ同様に実現されています。問題はES-Aの方です。検証情報とはCRL（失効リスト）やOCSPレスポンスとなります。CRLの利用が一般的ですが、CRLの仕組みは失効したIDを全てリストアップしているので大量に証明書を発行されている認証局だと100キロバイト単位のサイズになることがあります。また検証情報は通常署名後に取得することになります。

またES-Aは有効期限が切れる前に繰り返し適用も可能になっています。つまり長期署名とは最新の情報を追加して行くことで長期間の有効性を担保していると言えます。動的な仕組みであり成長して行く署名データとも言えます。

バイトレンジの話に戻してみましょう。バイトレンジは通常はせいぜい数十キロバイト程度しか確保されていません。これを将来に渡ってES-Aを追加して行くつもりでメガバイト単位で最初から確保することは現実的でしょうか？ 答えはやはり「ノー」でしょう。どんなに小さなPDFファイルも最初から数メガバイトのサイズになるのは利用者から見て受け入れられませんし、そもそもどれだけ確保しても絶対に安全なサイズも分かりません。PDF署名は静的な安定した仕組みであり拡張性があまり無いと言えます。

以上から出てくる答えは、PDF署名の長期署名化に関して、ES-Tまでは現行の仕組みで対応が可能だが、ES-Aでは別途証明書や検証情報や保管タイムスタンプを保管する新しい場所をPDFファイル内に確保する必要がある。と言うことです。

証明書や検証情報をどこに保管するかで議論や検討があったようです。しかし最終的にはPDFのオブジェクト構造としてPDFの増分更新の仕組みで追加する仕様が支持されました。それが現在検討が進んでいるPAdESの仕様です。PAdESに関しては更に以下の仕様に分けられます（これ以外にもPAdES仕様は存在しますが今回はこの３つに絞ります）。

　PAdES Basic ： PKCS#7を使ったISO32000-1までのPDF署名
　PAdES Enhanced ： CAdES-Tを使ったPDF署名
　PAdES LTV (Long Term) ： PDFオブジェクトとしてES-Aを実現

PAdES Basicは従来からのPDF署名の仕様です。PKCS#7形式で署名＋タイムスタンプが利用可能です。PAdES EnhancedはPKCS#7部をCAdES-Tで置き換えた仕様です。CAdES-T形式で署名＋タイムスタンプが利用可能です。

最後のPAdES LTVは、PAdES Basic または PAdES Enhanced のPDF署名済みファイルを長期署名対応する為の仕様となり、証明書や検証情報を新しく設定されたPDFストリームオブジェクトとして増分更新を行い、PDF署名とほぼ同じ仕組みのこれも新しく設定されたドキュメントタイムスタンプを保管タイムスタンプとして利用する形式です。

ES-Aを実現しているのがPAdES-LTVですが、PAdES-Aとしなかったのはやはり既にPDF/Aと言う仕様が存在していた為でしょう。なおPAdES-LTVにより長期署名化することはPAdES-Basicつまり既存のPDF署名済みファイルに対しても有効と言うことになります。

また保管タイムスタンプでは無く、ドキュメントタイムスタンプと呼ぶことにも意味があります。ドキュメントタイムスタンプは署名無しでも利用が可能です。ドキュメントタイムスタンプだけ付与されたPDFファイルは「誰が」に関しては保障されませんが、「何時（いつ）」に関しては保障が可能ですので、特許対策の知財保護での利用等が考えられます。つまりドキュメントタイムスタンプは保管タイムスタンプ以外にも使い道があると言うことです。

CAdES/XAdESとは別の第3の長期署名フォーマットと言うことで何故増やす必要があるかと最初は思いましたが、既存のPDF署名からの連続性や拡張を考えると、PAdESは良く考えられた仕様だと思います。

さてお昼休みも終わりに近づいたし結構書いたと思うので今日はこのくらいにしたいと思います。なおPDF署名に関してはアンテナハウスにて色々な情報があります。PDF署名の仕組みに関して詳しく知りたい方は以下のリンクを辿ってみると良いでしょう。

　アンテナハウス「PDFと電子署名について」
　アンテナハウス「PDF電子署名入門」

また昨日話が出ましたPDF/Aに関する情報もあります。

　アンテナハウス「PDF/Aとはなにか」
　アンテナハウス「PDF/Aの概要」（PDFへのリンク）

どちらも大変勉強になります。

最近のPDFの状況を簡単にまとめてみましょう。現在ISO等で検討されているPDFの仕様としては、ISO32000-2と呼ばれるPDF2.0の仕様がまずあります。それとは別にPDF/A-2と呼ばれるPDF1.7（ISO32000-1）をベースとした仕様もあります。

PDF/AはPDFの長期保管の為の仕様です。既にAcrobat9.0ProではPDF/A-1の仕様に従っているかどうかをチェックするプリフライト機能とPDF/A-1bへの変換機能も付いています。PDF/Aはカプセル化して将来それだけで必要な情報は全て揃うようにPDFの仕様のうち使って良いものを指定したプロファイルとなります。例えばフォントに関しては全て埋め込みが必要ですし、カラースペースもデバイス独立か埋め込みが必要となります。更にPDF/A-1aと言う仕様がPDF/A-1のフル仕様対応版となりますが、タグ情報により文書の順番等も指定する必要があります。この辺りはちょうどPDF/A関連の仕事をしているので勉強しているところです。

PDF長期署名の仕様であるPAdESはISO3200-2にもPDF/A-2にも採用される方向だと理解しています。基本的には従来のPDF電子署名の拡張により長期署名を実現しています。

さてPDF署名では署名データとしてPKCS#7形式を利用しています。PKCS#7はバイナリ署名データCMS形式の元となった形式です。また既にJIS化されたCAdESはCMSを長期署名化した仕様となっています。ちょっと考えるとPKCS#7の部分をCAdESに置き換えるだけで長期署名化が出来そうに思えますが、PDF特有の問題がありそれが出来ないのでPAdESと言う仕様が生まれてきたと言うことになります。小出しにすることになりますが何故「PDF電子署名＋CAdES」でPDF長期署名が出来ないかはまた次回。

なおUさんのPAdES連載も既に第２回が出ています。こちらも是非ご覧になることをお勧めします。自堕落な技術者の日記 「連載:PAdES(PDF長期署名)について(第2回) PDF署名とは」。