「PDF/Aへの長期署名の適用方法」の問題点
PDF/A仕様についての無理解
「PDF/Aへの長期署名の適用方法」の冒頭に「ISO / DIS 19005-1 において規定された、長期保存のための電子文書フォーマットであるPDF/A は、」とあります。ISO 19005-1は、DIS（仕様草案）ではなく2005年9月に標準として認められており、2005年10月1日付けで仕様書の初版が出版されています。DISは誤りです。
なお、このJIS原案は、経済産業省に提案後、差し戻しになり、改訂されているようです。
「電子署名長期保存ハンドブック」(平成19年3月)では
附属書E
（参考）
PDF/Aへの長期署名の適用方法
となっており、冒頭の問題の箇所もISO/19005-1に変更されています。
以下の項番号は付属書Bのままです。
次に本文に、PDF/Aの規定に違反する箇所があります。
B.1-d)この附属書では，PDF/A への長期署名適用のために，次の名前を定義する。
とあり、
「B.3 時刻付き署名データ及び長期保存署名データの格納方法」
時刻付き署名データをPDF コンテンツの署名タグ内に格納し，可変長の長期保存署名データは添付ファイルとして格納する（図B.1 参照）。
とあります。このような文脈から、この参考資料では、PDF/Aで添付ファイルを使おうと意図していることが明確です。
PDFにはFileAttachment注釈、EmbeddedFilesの2種類の添付ファイルがありますが、PDF/A-1では、いづれの添付ファイルも許されていません。
FileAttachement注釈は、PDF Reference 1.4 の注釈（Annotation）の一種として定義されています。ISO 19005-1（PDF/A-1）仕様書6.5.2注釈の種類の項でFileAttachementは禁止と規定されています。EmbeddedFilesについても、PDF/A仕様書6.1.11で禁止されています。
従いまして、この案は、ISO 19005-1（PDF/A-1）に対して不適合です。いくら参考資料とはいえ、なぜ、わざわざPDF/A-1に不適合な仕様を提案しているのでしょうか？
そこで、ECOMに問い合わせましたところ、次のような回答をいただきました。「電子署名に関し，昨年始めからISO/TC171国内委員会と連携してISO/TC171/SC2/WG5（PDF/Aの標準化WG）に対して，問題提起を行なってきました。この結果，今年１月の会議で各国の賛同を得て，電子署名部分がPDF/Aから切り離され別の仕様になることが決まりました。JISの附属書はこの経緯を踏まえたものとなっています。」
とのことです。もしかすると、PDF/A-2を想定しているのでしょうか。仮にそうだとして、将来、PDF/A-2で添付ファイルが許される可能性があるのでしょうか？
私の理解では、 ISO 19005-1は、PDFの長期保存性を実現するために、PDF/AはPDFファイルの外部環境に一切依存しないで自己完結型のPDFとする、という基本方針に基づいて仕様が作成されているように思います。それに対して、PDFの添付ファイルは、PDFとは異質の別形式のファイルを、PDFの後ろに取り外し可能なアタッチメントのように取り付けたものです。
このように考えますと、PDF/Aの設計思想と、添付ファイルは本質的に相容れないのではないかと思います。従って、将来、PDF/A-2になったとき、（すくなくとも無制限には）添付ファイルを許可する可能性はないように思います。
長期署名対象のPDFをPDF/Aに限定する必要があるのでしょうか？
PDF/Aの仕様の詳細を検討してみますと、PDF/Aファイルを作るのはかなり大変です。つまり、通常のPDFに比べて、PDF/Aは、PDFの内容（オブジェクト）に対して大きな制限があります。様々なコンテンツをPDF化することを考えたとき、コンテンツを変更することなくPDF/Aとして作成できるのは、恐らく極僅かではないかと思います。
Acrobat8 Professionalをお持ちのかたは、プリフライト機能で、あるPDFがPDF/Aに適合しているかどうかをチェックしてみたら良いと思います。現在、流通しているPDFの99%以上は、PDF/A不適合になるでしょう。いや、もしかすると、WebにあるようなPDFは、ほぼすべて（100%に限りなく近く）がPDF/A不適合となるかもしれません。
PDF/A仕様に適合するPDFを作ろうとしますと、オリジナルのコンテンツからそのことを配慮して作らねばなりませんし、世の中に広く流通しているプリンタ・ドライバ形式のPDF生成ソフトでPDF/Aを作るのは困難、もしくは不適切だろうと思います。
なぜ、そういう性格をもつPDF/Aを前提に長期署名を考えるのでしょうか？普通のPDFに長期署名をつけるのではだめなのでしょうか？
PDFの電子署名仕様との不整合
つぎにPDF Referenceに記述されている電子署名に関する規定への準拠という点でも問題があります。
PDF Referenceには、1.4以降1.7まで、一貫して次の規定があります。
Once a document has been signed (see Section 2.2.6, “Security”), all changes made to the document must be saved using incremental updates, since altering any existing bytes in the file will invalidate existing signatures.
(PDF Reference 1.4 p.69)
つまり、PDFに電子署名を施すと、その後、PDFは常に増分更新をしなければならなくなります。
電子署名を施したPDFに添付文書をつけると、その添付文書は、署名後のPDFファイルへの増分更新としてつけなければなりません。
ECOMのJIS原案には、次のような一文があります。
B.3 時刻付き署名データ及び長期保存署名データの格納方法
e)長期署名の延長（アーカイブタイムスタンプの再取得）は，添付ファイルに格納された長期保存署名データに対して行い，添付ファイルを差し替える。
しかし、増分更新である以上、添付ファイルの差し替えはできません。添付ファイルを差し替えるとは、もとの添付ファイルを削除し、新しい添付ファイルをその代わりに添付することを意味するはずです。しかし、増分更新では、このような回復不可能な処理を行うことができません。
ちなみに、Acrobat 8で、署名したPDFに添付ファイルをつけます。これは、PDF/Aとしては許されませんが、PDFとしては許可されます。
その添付ファイルを削除しようとしますと、次のような警告がでます。
つまり、PDFに電子署名を施したあと、添付ファイルをつけると、その添付ファイルを削除することは、PDF Reference1.4以降の電子署名の仕様上許されません。追加はできますが、差し替えはできないのです。差し替えするようなツールを作ったとしますと、そのツールはPDF電子署名の標準を無視していることになります。
仮に、PDF/AをPDFに変更したとしても、この部分がPDF Referenceで定めるPDF電子署名の規定に不適合となってしまいます。
ところで、ISO DIS 32000を見ますと次のようになっています。
Once a document has been signed (see 12.8, "Digital Signatures"), all changes made to the document may be saved using incremental updates, since altering any existing bytes in the file invalidates existing signatures.
must beがmay be に入れ替わっています。PDF Reference 1.7とISO DIS 32000は技術的に同等なはずですが、must beがmay beに変更された理由は不明です。
標準準拠とはどうあるべきか
「PDF/Aへの長期署名の適用方法」はPDF ReferenceとPDF/Aで決まっている項目について、それが、意図的か、あるいは、理解不足かはともかくとして、それを無視・違反した上で、自分達の都合の良い独自拡張をしています。この考え方では、標準である部分についても、互換性がなく、相互運用できない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になってしまいます。
ところで、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で、サードパーティが他の値を定義しても良くなり、独自拡張可能になりました。このように記述を追加して拡張可能にする、というのが正当な方法でしょう。