PDF にデジタル署名を追加すると、署名画像自体のサイズのみが追加されるようです (通常の PNG ファイルの場合、おそらく 20 ～ 50 キロバイト)。実際のファイル サイズの増加は多くの場合さらに大きくなり、以前はファイル サイズが控えめだったドキュメントの場合、場合によっては数百キロバイト、場合によってはメガバイトに達することもあります。ファイル サイズが追加された署名データのサイズとほぼ同じだけ大きくなると予想しているユーザーは、この矛盾に困惑しています。その説明は、電子署名が PDF にどのように埋め込まれるか、デジタル署名に必要な暗号化インフラストラクチャ、および署名されていない文書から署名された文書に移行するときに PDF 形式が受ける構造的な変更にあります。
目に見える署名画像以外にデジタル署名が PDF に追加するもの
PDF のデジタル署名は、単にページに貼り付けられた画像ではありません。これは、目に見える署名の外観を超えたいくつかのコンポーネントを含む暗号構造です。署名の中核は、秘密キーを使用して作成され、対応する公開キー証明書を使用して検証できる文書コンテンツの署名付きハッシュです。この暗号化データ、ハッシュ、署名値、および証明書チェーンは、証明書の種類と使用される署名アルゴリズムに応じて、通常 2 ～ 10 キロバイトを占めます。可視署名画像が使用されている場合、暗号化データに画像ファイルのサイズが追加されます。
PDF 仕様では、署名データ自体のほかに、署名プロパティ (署名時間、署名の理由、場所、署名ハンドラーを識別するフィルターとサブフィルター、ファイル内の署名済みデータ範囲への参照) を記述する署名ディクショナリが必要です。この辞書と付随するメタデータにより、さらに数キロバイトが追加される可能性があります。ほとんどの署名では、署名に直接起因するデータの合計は 30 ～ 100 キロバイトの範囲内である必要があります。この範囲を超えるサイズの増加は、PDF が署名データをどのように吸収するかという構造的要因に起因します。以下の表は、ファイル サイズの増加に寄与するコンポーネントを分類したものです。
| 署名コンポーネント | 一般的なサイズ範囲 | 内容 |
|---|---|---|
| 暗号署名データ | 2～10KB | 署名付きハッシュ、署名値、タイムスタンプ トークン |
| 証明書チェーン | 3～15KB | 署名者証明書、中間CA証明書、ルート証明書 |
| 失効データ (CRL/OCSP) | 5～30KB | 署名時に証明書が有効であったことの証明 |
| 署名辞書とメタデータ | 2～5KB | 署名時刻、理由、場所、フィルター識別子 |
| 目に見える署名画像 | 10～100KB | 手書きの署名または印鑑のPNGまたはJPEG |
| 構造的なオーバーヘッド (増分保存) | 30～80KB | 更新された相互参照テーブル、追加されたオブジェクト、バイト範囲記述子 |
署名を追加すると PDF ファイルの構造がどのように変化するか
PDF ファイルは、オブジェクト番号をファイル内のバイト オフセットにマップする相互参照テーブルによってリンクされた、番号付きオブジェクトのコレクションとしてコンテンツを保存します。デジタル署名を追加する場合は、既存のコンテンツに対する署名が無効にならないように PDF を変更する必要があります。これは増分保存によって実現され、元のファイルの内容はそのまま残され、新しいオブジェクトがファイルの末尾に追加されます。新しいオブジェクトには、署名辞書、署名されたデータ、更新された相互参照テーブル、および署名プロセスの一部として変更されたオブジェクトが含まれます。
インクリメンタル保存メカニズムにより、署名されたバイト範囲を元のコンテンツと比較することで署名を検証できます。ただし、増分保存はファイル領域の使用効率が低くなります。完全な書き換えでコンパクトに参照できるオブジェクトは、追加セクションで完全に指定する必要があります。相互参照テーブルは、増分保存するたびに大きくなります。通常、最初の署名では、暗号データに 30 ～ 80 キロバイトの構造オーバーヘッドが追加されます。後続の署名でも同様の金額が追加されます。 4 者が署名した文書には、数百キロバイトの署名関連の構造データが含まれる場合があります。
証明書チェーンと失効チェックデータの役割
デジタル署名には、多くの場合、署名者の身元を検証するために必要な完全な証明書チェーン (署名者の証明書、発行元の中間認証局証明書、場合によってはルート証明書) が埋め込まれます。チェーン内の各証明書は 1 ～ 3 キロバイトにすることができます。 3 つの証明書のチェーンにより、3 ～ 9 キロバイトが追加されます。一部の署名ツールには、署名時に証明書が有効であったことを証明する証明書失効リスト (CRL) または OCSP 応答も埋め込まれています。これらの失効チェック データ構造は驚くほど大きくなる可能性があり、場合によっては証明書自体のサイズを超えます。複数のステータス エントリを含む完全な OCSP 応答では、10 ～ 20 キロバイト以上が追加される可能性があります。
失効データを含めるかどうかは署名ソフトウェアによって決定され、使用されている署名プロファイルの影響を受けます。長期検証 (LTV) 署名は、証明書の有効期限が切れてから何年も検証できるように設計されており、即時検証を目的として設計された基本署名よりも多くの失効データが含まれています。このオプションは多くの場合詳細設定に埋め込まれているか、デフォルトで有効になっているため、ユーザーは署名ツールに失効データが埋め込まれていることを認識していない可能性があります。ユーザーは小さな署名画像を見て、それに応じてファイル サイズが小さくなるだろうと期待するため、結果としてファイル サイズが増加すると混乱する可能性があります。
PDF ツールが異なるとファイル サイズが異なる理由で増加する
さまざまな PDF 署名ツールは、さまざまなレベルの構造効率で署名プロセスを実装します。 1 つのツールは、署名プロセスの一部として PDF の完全な書き換えを実行し、ファイル構造を圧縮し、以前の編集から孤立したデータを削除します。そのため、署名による正味のファイル サイズの増加は構造のクリーンアップによって相殺されます。別のツールでは、既存のすべてのコンテンツを変更せずに保存する増分保存が実行される場合があり、その結果、構造上のオーバーヘッド全体が既存のファイル サイズに追加されます。 2 つの異なるツールで同じ署名を同じ文書に適用すると、サイズが数百キロバイト異なる出力ファイルが生成される可能性があります。
WukongPDF の Sign PDF ツールは、ファイル構造を効率的に管理しながらデジタル署名を適用します。署名により、不必要な構造の重複を生じることなく、必要な暗号データが追加されます。署名前に大幅に編集された文書の場合は、署名する前に「名前を付けて保存」機能を使用して完全な書き換えを実行してクリーンなコピーを作成し、そのコピーに署名すると、累積ファイル サイズが最小限に抑えられます。クリーンなベース ファイルと効率的な署名ツールを組み合わせることで、可能な限り最小の署名付き PDF が生成されます。
複数の署名が必要な場合のファイル サイズの管理
複数の署名を必要とするドキュメントでは、各署名によって独自の暗号化データと増分保存による構造的オーバーヘッドが追加されるため、ファイル サイズが最大の課題となります。買い手、売り手、および 2 人の証人によって署名された契約書には、4 層の署名データが含まれます。各署名によって 50 ～ 100 キロバイトが追加される場合、署名関連の合計サイズ増加は 200 ～ 400 キロバイトになります。これは、提供される法的保証を考慮すると完全に妥当です。埋め込まれた失効データと冗長な証明書チェーンにより各署名のサイズが数百キロバイト増加し、合計の増加量がメガバイトの範囲に達すると、問題が発生します。
複数署名ドキュメントのファイル サイズを管理するには、構造的なオーバーヘッドを最小限に抑える署名ワークフローを使用します。コンパクトな署名を生成するツールを使用して文書に署名します。署名の間に、中間の増分保存レイヤーを追加するような不必要な編集や保存を避けてください。ファイル サイズが問題になる場合は、すべての署名が完了した後で PDF 最適化ツールを使用してファイル構造を圧縮します。署名されたバイト範囲が変更されない限り、署名は最適化によって有効なままになります。デジタル署名データは保存され、複数の増分保存による構造的なオーバーヘッドがクリーンアップされ、法的に有効で効率的なサイズの署名付きドキュメントが生成されます。
署名後のファイル サイズ増加の原因を理解すると、署名構成について情報に基づいた決定を下すのに役立ちます。電子メールで配布されるドキュメントや、サイズ制限のあるポータルにアップロードされるドキュメントなど、ファイル サイズが重要なドキュメントの場合は、不要な失効データを省略し、最小限の証明書チェーンを使用する署名プロファイルを選択すると、署名あたり数百キロバイトを節約できます。数年後に異議が申し立てられる可能性がある契約書など、ファイル サイズよりも長期的な検証が重要な文書の場合、失効データによる追加サイズは、文書の将来の法的防御力への価値ある投資となります。