PDF　千夜一夜

なぜ、こんな発想が出てくるのか疑問に思い、ECOMの前年度の報告書を見ましたところ、彼らの誤れる発想の原点が少し見えました。

前年度の「長期署名フォーマット相互運用実験報告書」（平成18年3月）次世代電子商取引推進協議会発行資料のPP.45～49まで、PDF/A文書に対する長期署名の標準化という項があり、そこで予備的な検討が行われています。その中に次のような部分があります。

PDF/AのベースになっているPDF Reference1.4では電子署名についての仕様は簡単な記述になっています。

ちなみに、その時点では、PDFの電子署名は別文書「PDF Public-Key Digital Signature and Encryption Specification Version 3.2（Jim Pravetz 著）」で記述されていました。その後、この別文書の内容がPDF Reference本体に吸収されたようです。
※上記の文書は、どうも既にWebからなくなってしまっているようで、内容は私には確認できていませんので推測です。

その結果、ECOM的PDF長期署名にとっては都合の悪い記述がPDF Reference1.6に盛り込まれてしまいました。

すなわち、PDF 1.4では、署名辞書の署名ハンドラの名前（Filterキーの値）、署名の符号化方法を示す名前（SubFilterキーの値）、署名値（Contentsキーの値）について、簡単な記述しかなかったので、長期署名の形式をPDFの署名辞書に定義可能でした。

ところが、PDF 1.6でこれらの記述が詳しくなりました。具体的には、
(1) SubFilterキーの値の部分に次のパラグラフが追加されました。
Defined values for public-key cryptographic signatures are adbe.x509.rsa_sha1, adbe.pkcs7.detached, and adbe.pkcs7.sha1 (see Section 8.7.2, “Signature Interoperability”).

(2) Contentsキーの値の部分に次のパラグラフが追加されました。
For public-key signatures, Contents is commonly either a DER-encoded PKCS#1 binary data object or a DER-encoded PKCS#7 binary data object.

このふたつのパラグラフが追加されたために、長期署名の形式を表すキーの値を定義できなくなってしまったのです。「長期署名フォーマット相互運用実験報告書」の筆者は、この対策として、このインターフェイスの阻害要因である、上の二つの段落を削除する、ということを提案しています。

Adobeが作った標準仕様であるPDF Referenceを利用しておきながら、自分達に都合の悪い段落を削除し、都合の良い項目を追加する、という発想方法は、標準を認めない、ということに繋がります。その結果できるものは標準とは名ばかりで、実態は非互換の独自PDFです。

ところで、PDF 1.7で、SubFilterの項にはさらに次の一文が追加になりました。
Other values can be defined by third party developers, subject to the restriction that all names beginning with the adbe. prefix be reserved for future versions of PDF. All third party names must be registered with Adobe Systems.

これで、サードパーティが他の値を定義しても良くなり、独自拡張可能になりましたので、削除しなくても問題なくなりました。PDF 1.7のように記述を追加して拡張可能にする、というのが正当な方法でしょう。

さて、3回にわたり、ECOMのJIS原案に掲載されている「PDF/Aへの長期署名の適用方法」について検討しましたが、その目的のひとつは、アンテナハウスPDFでこれを採用するかどうかを判断することがあります。結論は、既に明らかなように、アンテナハウスPDFにはこの仕様案は採用できないです。