長期検証

Spec: ETSI EN 319 142-1 Spec: RFC 6960 Spec: ISO 32000-2, §12.8.4 Evidence: Standard-backed

概要

現在検証できる署名は、長くは保たない事実の上に成り立っています。期限切れになる証明書、オフラインになる失効サーバー、安全性が弱まるハッシュアルゴリズムなどです。長期検証は、証拠がまだ取得できるうちにそれをドキュメント内へ記録します。これにより、署名は何年も後になっても、外部へ問い合わせることなく確認できます。

なぜこれが重要か

デジタル署名の厄介な性質は、見た目は変わらないまま静かに検証不能になりうる点です。ファイル内では何も変わりません。認証局は、とうの昔に期限切れになった証明書についての問い合わせに応答しなくなります。その回答を必要としていた検証側は、もはやそれを得られません。署名された当日は疑いなく有効だった契約が、10 年後には「判定不能」になってしまいます。10 年後というのは、まさに紛争が最も起こりやすく、利害が最も大きくなる時期です。保管義務が年単位で定められている場合、長期検証のない署名は、後になって初めて表面化するリスクとなります。

要点

署名の有効性は、時間の影響を受ける外部の事実に依存します。証明書の有効期間や、サーバーから取得する失効ステータスなどです。
これらの事実は、証明書が期限切れになると取得不能になります。認証局には永久に応答し続ける義務はありません。
長期検証は、署名時に証拠を取得し（証明書、OCSP レスポンス、CRL）、それをドキュメントの**ドキュメントセキュリティストア（DSS）**に埋め込みます。
次にドキュメントタイムスタンプが、証拠そのものがその時点で存在し有効だったことを証明します。このタイムスタンプは、それ自体の保護が弱まる前に更新できます。
その結果、ドキュメント自身が証拠を保持します。検証は、サーバーがまだ存在していることに依存しなくなります。

NextPDF のアプローチ

原則は「まだ可能なうちに証拠を集め、それを封印する」ことです。NextPDF は長期署名を生成する際、署名証明書が署名の時点で有効だったことを証明する証明書チェーンと失効レスポンスを収集します。そしてそれらを、リンクではなく埋め込み値として DSS に書き込みます。次に、その全体にドキュメントタイムスタンプを付与します。埋め込み値であることが重要です。失効サーバーへのリンクは、まさに長期検証が取り除くために存在する依存関係そのものです。

長期検証のレイヤーは個別のドキュメントリビジョンとして書き込まれ、元の署名のバイト範囲を乱すことなく追記されます。最初の署名は検証可能なまま保たれます。長期検証の素材は、署名の中にではなく、その周りに追加されます。ドキュメントタイムスタンプ自体の保護が古くなると、アーカイブレベルではその上に別のタイムスタンプを重ねられます。その結果、各タイムスタンプがその下にあるすべてを保証する連鎖ができあがります。

Sign The signature and its signed attributes are written (B-B).
Capture evidence Certificate chain, OCSP responses, and CRLs proving the certificate was valid at signing time are gathered.
Embed in the DSS The evidence is written into the document as embedded values, not links (B-LT).
Seal with a document timestamp A timestamp proves the embedded evidence existed and was valid at that moment (B-LTA).
Renew before it weakens Another timestamp is layered before the previous one’s protection ages, extending verifiability.

長期検証が時間の経過とともに署名を検証可能に保つ仕組み。署名が作成され、証拠がまだ取得できるうちに取得され、証拠がドキュメントタイムスタンプによって封印され、封印が弱まる前に更新されます。

根拠が示すこと

Evidence: Standard-backed この必要性は、次の規格で明確に示されています。 Spec: RFC 6960, §4.4.4 。OCSP レスポンダーは、証明書の期限切れ後も失効情報を保持することがあり、アーカイブのカットオフ日付によって、アプリケーションは署名が作成された日に信頼できたか、できなかったかを証明できます。 それを検証するために必要な証明書がとうに期限切れになっていたとしてもです。この趣旨こそが、長期検証が存在する理由のすべてです。失効に関する回答は限られた期間しか得られないため、その期間が終わる前にそれらを取得しておかなければなりません。

この仕組みは ETSI が定めています。 Spec: ETSI EN 319 142-2, §5.5 は、長期的な運用には検証データを値として保持するドキュメントセキュリティストアと、それに続くドキュメントタイムスタンプが必要であると定めています。 Spec: ISO 32000-2, §12.8.3.3 がこれらを結びつけます。 PAdESは、CAdES CMS に長期検証（§12.8.4）とドキュメントタイムスタンプ辞書（§12.8.5）を組み合わせたものです。そして Spec: ETSI EN 319 142-2, §6.3.2.2 は、タイムスタンプを早期に付与すべき根拠を示しています。記録される時刻が実際の時刻にできるだけ近くなるよう、署名直後にタイムスタンプを付与すべきです。

NextPDF のエンジンは、これをB-LTおよびB-LTAレベルとして実装しています。DSS 内に埋め込まれた失効値、それらを封印するドキュメントタイムスタンプ、そして封印を更新するアーカイブループとして構成され、元の署名のバイト範囲をそのまま残す追記リビジョンとして書き込まれます。

実践例

どのレベルを選択するかこそが長期的な意思決定です。API は、確定する前に要件を明示します。

<?php

declare(strict_types=1);

use NextPDF\Security\Signature\SignatureLevel;

// B-LT embeds validation material; B-LTA adds the renewable seal.
$level = SignatureLevel::PAdES_B_LTA;

$level->requiresDss();                // true  → certificates + revocation embedded
$level->requiresDocumentTimestamp();  // true  → a document timestamp seals the DSS

// The high-level seam produces the level end to end: it embeds the DSS
// dictionary and appends the DocTimeStamp revision in one call.
$document
    ->setSignature($cert, SignatureLevel::PAdES_B_LTA, $tsaClient)
    ->save();

// The engine produces this only if the deployment can supply what it needs
// (a TSA, and revocation data reachable at signing time). It fails with an
// actionable error rather than embedding nothing and reporting success.

上に示した高レベルの接合点（setSignature($cert, SignatureLevel::PAdES_B_LTA, $tsaClient)->save()）は、現在エンドツーエンドで接続されています。以前のリリースではレベルの列挙型は公開されていましたが、それを生成する接合点は公開されていませんでした。これが書き込むのは構造です。すなわち DSS 辞書と、 Spec: ISO 32000-2, §12.8 で記述されたDocTimeStampリビジョンです。この構造についてはプロファイル適合性のテストが行われておらず、接合点はETSI適合性や法的有効性について一切保証しません。B-LTおよびB-LTAレベルには Pro と Enterprise の両方が必要です。それ以外のティアでは、接合点は部分的な結果を生成するのではなくフェイルクローズ（安全側に失敗）します。暗号化されたドキュメントも、B-LTおよびB-LTAではフェイルクローズします。DSS とドキュメントタイムスタンプは、暗号化されたコンテンツに対して誤って書き込まれるのではなく、まったく書き込まれません。

この選択を後から安価に追加することはできません。失効の証拠は、回答がまだ存在するうちに署名時に取得しなければなりません。「長期検証は後で追加しよう」と決めることは、たいてい「必要なときに証拠を持っていないだろう」と決めることを意味します。

よくある誤解

よくある誤解は「長期検証は署名を永久に有効にする」というものです。長期検証は、何かを有効にするものではありません。署名時に確立された有効性を確認する能力を保持するものです。ドキュメントが署名された時点で証明書がすでに失効していた場合、その事実を埋め込んでも署名は救済されません。むしろ、その失敗を永久に記録します。長期検証は証拠を保存する仕組みであって、証拠を作り出す仕組みではありません。2 つ目の誤解は、B-LTAを「設定したら放置でよい」と考えることです。アーカイブタイムスタンプ自体も、やがて古くなるアルゴリズムで保護されています。更新しなければ、B-LTAファイルはやがて、本来回避するはずだった脆弱性を再び抱え込んでしまいます。

制限と境界

NextPDF は証拠を集めて埋め込み、タイムスタンプを書き込みます。証拠の真正性を保証したり、更新スケジュールを決めたりするものではありません。失効レスポンスの信頼性は、それを発行した認証局と、それが取得された時点の信頼性に左右されます。署名時にその認証局へ接続できるかどうかは、デプロイ側の責任です。エンジンは、取得できなかった失効の回答を作り出すことはできません。アーカイブの更新は運用上のプロセスです。エンジンは別のタイムスタンプを追加できますが、保管ポリシーがいつそれを必要とするかを判断することはできません。埋め込まれたデータが後に十分と判断されるかどうかは、検証側とポリシーの問題であり、署名を正しく検証するで扱います。このページは法的な証拠能力を保証するものではありません。それは管轄、署名者、証明書に依存します。

長期検証のティア別提供状況。

Long-term validation (DSS embedding and the archival timestamp loop) — edition availability
Edition	Availability
Core	Not in this edition
Pro	PAdES B-T（署名値への信頼できるタイムスタンプ）は利用できますが、埋め込み検証素材（DSS）はB-Tには含まれません。
Enterprise	PAdES B-LTおよびB-LTA。すなわち、 DSS 内の埋め込み証明書と失効値、それらを封印するドキュメントタイムスタンプ、そして更新可能なアーカイブループです。

用語集

長期検証（LTV） — 署名の検証に必要な証拠を埋め込み、後日の検証が外部サービスに依存しないようにすること。
ドキュメントセキュリティストア（DSS） — 長期検証のための埋め込み証明書と失効データを保持する PDF 構造。
OCSP レスポンス — ある時点における証明書の失効ステータスを示す署名付きの宣言（Online Certificate Status Protocol、RFC 6960）。
CRL — 証明書失効リスト（Certificate Revocation List）。失効した証明書の署名付きリスト。
ドキュメントタイムスタンプ — ドキュメント全体に適用されるRFC 3161タイムスタンプ。埋め込まれた証拠がその時点で存在し、有効だったことを証明する。
アーカイブループ — 前のタイムスタンプの保護が弱まる前に新しいドキュメントタイムスタンプを繰り返し追加し、検証可能性を延長すること。