署名: PAdES B-LT / B-LTA、DSS、ドキュメントタイムスタンプ
NextPDF Enterprise は、Core の CMS 署名を基盤として、長期プロデューサーを追加します。具体的には Document Security Store (DSS)、署名ごとの検証関連情報 (VRI)、およびドキュメントタイムスタンプです。これらの構造は、PAdES ベースライン署名を B-B から B-LT へ、さらに B-LTA へと引き上げます。このページでは、挙動レベルの内容を扱います。プロデューサーが何を書き込み、何を決定しないか、そして Pro の境界がどこにあるかを記載します。
インストール
「インストール」という見出しのセクションcomposer require nextpdf/enterprisenextpdf/enterprise は nextpdf/core と nextpdf/pro に依存します。パッケージは、NextPDF ライセンス資格情報を使って Private Packagist 上で解決されます。
概念の概要
「概念の概要」という見出しのセクションPAdES ベースライン署名には 4 つのレベルがあります。各レベルでは、前のレベルにマテリアルを追加します。B-B は、署名付き属性を持つ CMS 署名です。B-T は、署名値に対して信頼できる RFC 3161 タイムスタンプを追加します。B-LT は、署名証明書の失効後に検証者が必要とする証明書、OCSP レスポンス、および CRL を保持する DSS を追加します。B-LTA は、DSS を含むドキュメント状態全体に対するドキュメントタイムスタンプを追加し、検証マテリアル自体にも時刻アンカーが付いた状態を維持します。
Core は CMS SignedData を構築し、それを署名ディクショナリの Contents エントリに DER エンコードして格納します — ISO 32000-2 §12.8.1。長期検証は、document security store と document timestamp dictionary という 2 つのディクショナリタイプによって実現されます — ISO 32000-2 §12.8。Enterprise プロデューサーは、証明書、OCSP、CRL のマテリアルを保持する DSS を書き込み — ISO 32000-2 §12.8.4.3 — さらに B-LTA の場合は document timestamp dictionary を書き込みます — ISO 32000-2 §12.8.5。ETSI EN 319 142-2 も同じ長期形式を記述しています。長期署名のための DSS エントリとドキュメントタイムスタンプ — §5.5 — であり、署名ハンドラーによってサポートされます — §6.3.3.3。
プロデューサーは、チェーン内の証明書ごとに失効情報を収集します。まず OCSP レスポンダーに問い合わせます。OCSP レスポンスは good、revoked、または unknown を報告し — RFC 6960 §2.2 — thisUpdate および nextUpdate フィールドが、そのステータスの鮮度の範囲を定めます — RFC 6960 §4.2。OCSP が利用できない場合は、CRL にフォールバックします。チェーンは、パス検証の入力に従って、署名者からトラストアンカーへ向かって辿られます — RFC 5280 §6.1。
B-LTA のドキュメントタイムスタンプは、Time-Stamping Authority との RFC 3161 交換です。リクエストは TSTInfo を返し — RFC 3161 §2.4.1 — その genTime は、トークンが作成された UTC 時刻です — RFC 3161 §2.4.2。トークンは /DocTimeStamp ディクショナリに、ファイル全体をカバーする /SubFilter /ETSI.RFC3161 とともに埋め込まれます。
生成された署名が 検証される かどうかは、検証者、および検証者に設定されたトラストアンカーと失効ポリシーによって決定されます。プロデューサーはマテリアルを埋め込みますが、信頼済みの結果を主張するものではありません。この境界は、以下の関連箇所で繰り返し記載します。
順序は重要です。DSS は B-LTA のドキュメントタイムスタンプより前に書き込まれなければなりません。タイムスタンプは、検証マテリアルをすでに含むドキュメント状態をカバーする必要があるためです。プロデューサーのフローを以下に示します。
API サーフェス
「API サーフェス」という見出しのセクションEnterprise の長期プロデューサーは、Core のコントラクトを通じて利用されます。本番コードは、具体的な Enterprise の実装型にではなく、コントラクトに依存させます。
| 型 | 種別 | 役割 | 安定性 | 導入バージョン |
|---|---|---|---|---|
SignerInterface | interface (NextPDF\Contracts) | 呼び出し元が依存する Core の署名コントラクト | stable | 1.0.0 |
SignatureLevel | enum (NextPDF\Security\Signature) | PAdES レベルセレクター: B-B、B-T、B-LT、B-LTA | stable | 1.0.0 |
LtvManagerInterface | interface (NextPDF\Contracts) | 実行時に解決される長期検証プロデューサーのコントラクト | stable | 1.0.0 |
TsaClientInterface | interface | プロデューサーがドキュメントタイムスタンプで呼び出す RFC 3161 TSA クライアント | stable | 1.0.0 |
SignatureLevel::requiresDss() は B-LT と B-LTA で true になります。SignatureLevel::requiresDocumentTimestamp() は B-LTA でのみ true になります。Core の SignatureLevel::isAvailableInEnvironment() は、Enterprise の長期プロデューサーがインストールされていない場合、B-LT と B-LTA に対して false を返します。その場合、Core のオーケストレーターはフェイルクローズします。具体的な Enterprise プロデューサークラスは内部実装であり、パブリック API の一部ではありません。LtvManagerInterface と enum に依存してください。
コードサンプル — クイックスタート
「コードサンプル — クイックスタート」という見出しのセクション<?php
declare(strict_types=1);
require_once __DIR__ . '/../../vendor/autoload.php';
use NextPDF\Security\Signature\SignatureLevel;
/** * Select the PAdES level for a long-term signature. * * B-LT embeds a DSS. B-LTA also adds a document timestamp. * Both require the nextpdf/enterprise long-term producer at runtime. * * @return SignatureLevel The requested PAdES baseline level. */function longTermLevel(): SignatureLevel{ return SignatureLevel::PAdES_B_LTA;}レベルは、署名構成内に保持されます。Core のオーケストレーターは、実行時に LtvManagerInterface を通じて長期プロデューサーを解決するため、アプリケーションコードは Enterprise の型を参照しません。
コードサンプル — 本番
「コードサンプル — 本番」という見出しのセクション<?php
declare(strict_types=1);
require_once __DIR__ . '/../../vendor/autoload.php';
use NextPDF\Contracts\LtvManagerInterface;use NextPDF\Contracts\SignerInterface;use NextPDF\Exception\NextPdfException;use Psr\Log\LoggerInterface;
final readonly class LongTermSigner{ public function __construct( private SignerInterface $signer, private LtvManagerInterface $ltv, private LoggerInterface $logger, ) {}
/** * Sign, then embed the DSS and the B-LTA document timestamp. * * The order matters: the DSS is written first, then the document * timestamp is taken over the document state that already includes it. * * @param string $byteRange The PDF byte range to sign. * * @throws NextPdfException When revocation material is missing under the * fail-closed enforcement default, or when no TSA * is configured for B-LTA. */ public function sign(string $byteRange): string { try { $contents = $this->signer->sign($byteRange)->toHex(); // The orchestrator drives DSS collection and the document // timestamp through the resolved LtvManagerInterface; revocation // freshness and TSA reachability are operational inputs. return $contents; } catch (NextPdfException $e) { $this->logger->error('long-term signing failed', ['reason' => $e->getMessage()]); throw $e; } }}DSS は、ドキュメントタイムスタンプより前に書き込まれなければなりません。B-LTA タイムスタンプは、DSS を含むファイル全体をカバーします。これにより、検証マテリアル自体が時刻アンカーされます。
エッジケースと注意点
「エッジケースと注意点」という見出しのセクション- 失効情報がない場合はデフォルトでフェイルクローズします。 強制モードが設定されていない場合、プロデューサーは、ルート以外のすべての証明書について、OCSP レスポンスの欠落と CRL の欠落を警告ではなくエラーとして扱います。これにより、長期レベルを主張するドキュメントが、DSS 内に失効情報を持たないまま書き込まれることを防ぎます。許容的（警告のみ）なワークフローはオプトインです。
- B-LTA には TSA が必要です。 ドキュメントタイムスタンプは RFC 3161 のラウンドトリップです。TSA クライアントが構成されていない場合、B-LTA ステップは、暗黙的に B-LT を生成するのではなく、エラーを発生させます。
- 順序は重要です。 ドキュメントタイムスタンプは、DSS が書き込まれた後にのみ追加してください。DSS より前に取得されたタイムスタンプは、検証マテリアルをカバーしません。
- エアギャップ実行。 厳格オフラインのネットワークポリシーでは、OCSP/CRL の取得も TSA リクエストも行われず、DSS にすでに埋め込まれているマテリアルのみが使用されます。新しい TSA トークンを必要とする B-LTA は、厳格オフラインでは実現できません。
- VRI はオプトインです。 署名ごとの VRI は、デフォルトでは書き込まれません。一部のバリデーターは、VRI が存在すると長期ステータスをより適切に表示します。対象の検証者が必要とする場合に有効にしてください。
パフォーマンス
「パフォーマンス」という見出しのセクションDSS アセンブリのコストは、チェーン長と取得される失効レスポンスの数に応じて増減します。各 OCSP または CRL の取得は、1 回のネットワークラウンドトリップです。事前収集またはキャッシュされたマテリアルは、それらのラウンドトリップを不要にします。B-LTA の実行では、ドキュメントタイムスタンプのために 1 回の TSA ラウンドトリップが追加されます。1500 ms のウォール予算は、ウォーム状態の OCSP/CRL および TSA 接続による単一の長期署名をカバーします。コールド状態または低速なレスポンダーがウォールタイムを支配します。再現性プロファイルは structural です。タイムスタンプは署名時刻とタイムスタンプ時刻を埋め込むため、2 回の実行はそれらのバイトで異なりますが、ドキュメント構造は同一です。
セキュリティに関する注意
「セキュリティに関する注意」という見出しのセクション- 信頼は検証者の決定です。 プロデューサーは、証明書、OCSP、および CRL を埋め込みます。署名が検証されるかどうかは、検証者、そのトラストアンカー、および失効情報の鮮度ポリシーに依存します。NextPDF は、組み込みのトラストリストを提供しません。
- 失効の鮮度には時間的な制限があります。 OCSP の
thisUpdate/nextUpdateおよび CRL の有効期間ウィンドウは、埋め込まれたマテリアルが有用であり続ける期間を定めます。アーカイブループは、タイムスタンプ証明書が失効する前に再押印します。スケジュールどおりに運用する責任は、呼び出し元にあります。 - フェイルクローズのデフォルト。 厳格な失効強制のデフォルトは、それを裏付けるマテリアルなしに長期の主張がなされないように設けられています。
- 詳細は Enterprise の脅威モデルセクション および Archive: DSS, VRI, LTV health を参照してください。
データレジデンシーと PII の緩和策
「データレジデンシーと PII の緩和策」という見出しのセクションOCSP と CRL の取得では、各証明書に記載されたレスポンダーに接続します。それらのエンドポイントと TSA は、リクエストのメタデータを参照します。データレジデンシーが制約されたデプロイでは、失効情報を事前収集し、署名時にレスポンダーや TSA に接続しないよう、厳格オフラインポリシーの下で実行してください。証明書はサブジェクトの識別情報を保持します。プロデューサーは、検証に必要な証明書を埋め込み、チェーンを超えた識別情報を追加しません。呼び出し元が提供した証明書からサブジェクトフィールドを除去することもありません。
安全なテレメトリとログのスクラブ
「安全なテレメトリとログのスクラブ」という見出しのセクションプロデューサーの診断情報は、レベル、チェーン位置、およびマテリアル欠落の状態を報告します。秘密鍵や証明書本体全体をログに記録することはありません。PSR-3 ロガーを配線する際は、署名フローの診断ログを本番向けの冗長度に抑え、レスポンダー URL が内部インフラを明らかにする場合はスクラブしてください。埋め込まれた OCSP/CRL バイトは、ログの内容としてではなく、ドキュメントの内容として扱ってください。
FIPS モードの挙動
「FIPS モードの挙動」という見出しのセクションFIPS 140-3 暗号ポリシープロファイルは、セキュリティモジュールとあわせて文書化されている Enterprise の機能です。長期プロデューサーは、ドキュメントタイムスタンプと RFC 3161 交換に使用される SHA-256 ダイジェスト以外に、独自の暗号プリミティブを追加しません。署名プリミティブは Core 署名者のものです。FIPS プロファイルが有効な場合も、同じ DSS およびドキュメントタイムスタンプ構造が生成されます。この制約は、基盤となる署名およびダイジェストのアルゴリズムに適用され、DSS のレイアウトには適用されません。
脅威モデル
「脅威モデル」という見出しのセクション| 資産 | 敵対者 | リスク | 緩和策 |
|---|---|---|---|
| DSS 失効情報 | 古いマテリアルの受け入れ | 検証者が期限切れの失効データを信頼すること | OCSP/CRL の鮮度フィールドによる有効性範囲の定義；アーカイブループによる失効前の再押印 |
| B-LTA ドキュメントタイムスタンプ | TSA の侵害または到達不能な TSA | 信頼できる時刻アンカーの欠如 | 呼び出し元による TSA の選択。B-LTA は TSA が構成されていない場合にフェイルクローズする |
| 長期の主張 | マテリアルの暗黙的な欠落 | 失効データを持たない「長期」PDF | フェイルクローズ強制のデフォルトによる、警告ではなくエラーの発生 |
| 署名検証 | 設定ミスのある検証者による信頼 | 検証者が主張すべきではない見かけ上の有効性 | プロデューサーはマテリアルの埋め込みのみを明記。信頼の決定は検証者のもの |
| 主張 | 標準 | 条項 | reference_id |
|---|---|---|---|
署名値 (またはタイムスタンプトークン) は、/Contents に DER エンコードされて格納されます。 | ISO 32000-2 | §12.8.1 | |
| 長期検証は、DSS と document timestamp dictionary を使用します。 | ISO 32000-2 | §12.8 | |
| DSS は、証明書、OCSP レスポンス、および CRL を保持します。 | ISO 32000-2 | §12.8.4.3 | |
| ドキュメントタイムスタンプは、document timestamp dictionary を使用します。 | ISO 32000-2 | §12.8.5 | |
| DSS エントリとドキュメントタイムスタンプは、長期署名をサポートします。 | ETSI EN 319 142-2 | §5.5 | |
| 署名ハンドラーは、DSS エントリとドキュメントタイムスタンプをサポートします。 | ETSI EN 319 142-2 | §6.3.3.3 | |
| タイムスタンプトークンは、作成された時刻である UTC の genTime を保持します。 | RFC 3161 | §2.4.2 | |
| OCSP は good、revoked、または unknown を報告し、thisUpdate/nextUpdate によって範囲が定められます。 | RFC 6960 | §2.2, §4.2 | , |
すべての条項はパラフレーズです。NextPDF は規範的なテキストを複製しません。正規の文言については、公開された標準を参照してください。NextPDF は PAdES 認証の主張を行いません。 ここで説明する構造は、ETSI EN 319 142 で定義された B-LT および B-LTA レベルに整合していますが、適合性テスト結果や第三者による証明は主張しません。ETSI EN 319 142-1 のベースラインレベルに関するパートは、引用された証拠セットの範囲外です。そのため、このページでは、認証された適合性レベルではなく、生成される構造と Pro/Enterprise の境界を記載します。引用された ETSI の証拠は EN 319 142-2 です。ISO および RFC のアンカーが、Core 署名リファレンスと同様に、長期およびタイムスタンプの主張を担います。
エディションゲート
「エディションゲート」という見出しのセクションNextPDF Core は B-B および B-T の PAdES ベースラインレベルを生成します。Core はソフトウェア CMS 署名者と RFC 3161 タイムスタンプパスを同梱しているため、B-T (タイムスタンプ付き) 署名は Core の機能であり、Enterprise を必要としません。NextPDF Pro も B-B および B-T を生成します。Pro は Core の RFC 3161 スタックを組み合わせて、署名値に signature-time-stamp 未署名属性を追加します (PadesBtTimestamper、フィクスチャ検証済み)。B-LT および B-LTA レベル — DSS、VRI、およびドキュメントタイムスタンプのプロデューサー — は Enterprise の機能であり、Core や Pro では 生成されません。これは、Pro セキュリティページ に公開されているティアテーブルと一致します。つまり、B-B と B-T は Core と Pro が生成し、B-LT と B-LTA は Enterprise のみが生成します。B-T プロデューサーは構造的なものです — 引用された RFC 3161 / RFC 5652 / ETSI EN 319 122-1 の証拠に従って RFC 3161 signature-time-stamp を組み合わせます。これは認証された ETSI EN 319 142-1 適合性や eIDAS 適格の主張ではありません。Pro のみのデプロイでは、B-LT または B-LTA を要求すると、欠落している Enterprise コンポーネントを名指しするメッセージとともにフェイルクローズします。これは、Enterprise の長期プロデューサーが存在しない場合に SignatureLevel::isAvailableInEnvironment() が false を返すためです。
| PAdES レベル | 追加内容 | プロデューサーのエディション |
|---|---|---|
| B-B | 署名付き属性を持つ CMS 署名 | Core、Pro、Enterprise |
| B-T | 署名値に対する RFC 3161 signature-time-stamp (構造的。eIDAS 適格ではない) | Core、Pro、Enterprise |
| B-LT | 検証マテリアルを伴う Document Security Store | Enterprise (nextpdf/enterprise) のみ |
| B-LTA | アーカイブ有効性のためのドキュメントタイムスタンプ | Enterprise (nextpdf/enterprise) のみ |
これが正規のレベル→ティアマトリクスです。B-B はすべてのエディションが生成するベースラインです。B-T (タイムスタンプ付き) も Core と Pro が生成します (Pro は Core の RFC 3161 スタックを組み合わせます)。B-LT と B-LTA は Enterprise 専用です。B-T プロデューサーは構造的なものです — これは認証された ETSI EN 319 142-1 適合性や eIDAS 適格の主張ではありません。
ライセンス機能フラグ
「ライセンス機能フラグ」という見出しのセクション長期プロデューサーは Enterprise エディションの一部です (license_feature_flag: enterprise)。これは実行時に Core のコントラクトを通じて解決されます。Pro から Enterprise へアップグレードしても、パブリック API は変更されません。
挙動コントラクト
「挙動コントラクト」という見出しのセクション- Core と Pro はどちらも B-B と B-T を生成します (B-T は RFC 3161 signature-time-stamp を追加します。Pro は Core の RFC 3161 スタックを組み合わせます)。B-LT と B-LTA は Enterprise の境界です。
nextpdf/enterpriseなしでこれらを要求すると、名前付きエラーとともにフェイルクローズします。 - プロデューサーは DSS (B-LT) と、DSS に対するドキュメントタイムスタンプ (B-LTA) を書き込みます。これにより検証マテリアルを埋め込みますが、信頼された検証結果を主張するものではありません。
- フェイルクローズの失効強制デフォルトは、ルート以外の証明書について失効情報が欠落している場合、呼び出し元が許容的ワークフローをオプトインしない限り、エラーを発生させます。
- B-LTA には構成された TSA が必要です。TSA がない場合、B-LTA ステップは B-LT に降格するのではなく、エラーを発生させます。
NDA スキャンステータス
「NDA スキャンステータス」という見出しのセクションこの公開ページでは、外部から観測できるプロデューサーの挙動のみを説明します。内部の名前空間パス、内部のクラス名やトレイト名、ランブックのファイル名、内部のチケットプレフィックスは一切含まれていません。具体的な Enterprise の長期プロデューサー型は、パブリックな Core のコントラクト (LtvManagerInterface、SignatureLevel) を通じてのみ参照されます。詳細な DSS アセンブリおよびアーカイブループの内部は、NDA の対象であるゲートされた詳細リファレンスに記載されています。
Core フォールバック
「Core フォールバック」という見出しのセクションCore のみのデプロイでは、ソフトウェア署名者が、ローカル鍵または Core の署名ストラテジーコントラクトを通じて提供される鍵を用いて、PAdES B-B と B-T を生成します。Core は RFC 3161 タイムスタンプパスを同梱しているため、B-T はどのプレミアムパッケージがなくても利用できます。Core には DSS、VRI、ドキュメントタイムスタンプのプロデューサーがありません。B-LT または B-LTA を要求すると、名前付きエラーとともにフェイルクローズします。Security / Signing (Core) を参照してください。
Pro フォールバック
「Pro フォールバック」という見出しのセクションPro のみのデプロイでサポートされる署名パスは、Pro の B-B ベースラインと Pro の B-T レベル (Pro は Core の RFC 3161 スタックを組み合わせて signature-time-stamp 未署名属性を追加します)、およびリモート署名ストラテジーとクラウド KMS 署名ストラテジーです。Pro は DSS、VRI、ドキュメントタイムスタンプを生成しません。Pro のみのデプロイで B-LT または B-LTA を要求する構成は、欠落している Enterprise コンポーネントを名指しするメッセージとともにフェイルクローズします。Pro の署名サーフェスについては Pro セキュリティ を参照してください。
Enterprise の境界に関する注記
「Enterprise の境界に関する注記」という見出しのセクションDSS、VRI、ドキュメントタイムスタンプのプロデューサーは、挙動レベルでのみ説明しています。内部の DSS アセンブリの順序付けロジック、署名ごとの VRI キーイングの内部、およびアーカイブループのスケジューリングの内部は、パブリックサーフェスの範囲外であり、ここでは複製していません。
デプロイの境界
「デプロイの境界」という見出しのセクションNextPDF Enterprise は検証マテリアルを埋め込みます。その際、呼び出し元が提供する OCSP/CRL レスポンダーおよび RFC 3161 TSA と統合されます。NextPDF Enterprise 自体は、それらのレスポンダーや TSA を運用、ホスト、または可用性を保証するものではありません。長期有効性は、レスポンダー、TSA、アーカイブループのスケジュール、およびオペレーターに依存し、NextPDF Enterprise 単独には依存しません。 オペレーターは、TSA の選択と到達性、失効レスポンダーへのアクセスまたは事前収集したマテリアル、ネットワークポリシー、および各タイムスタンプ証明書が失効する前にアーカイブループを実行する責任を負います。
法令遵守の境界
「法令遵守の境界」という見出しのセクションこのページは export_control_class: legal-review-required とマークされています。対象は暗号署名と長期検証です。publish フラグを設定する前に、法務承認が必要です。ETSI EN 319 142 で定義された B-LT および B-LTA 構造との整合は構造的な記述であり、法的見解でも認証でもありません。NextPDF は PAdES 認証の主張を行いません。 ご自身の規制上の義務については、ご自身のコンプライアンスおよび法務の助言者にご相談ください。
- Security / Signing (Core) — CMS、RFC 3161、RFC 5280 パス検証、OCSP/CRL。
- Pro セキュリティ — B-B ベースラインと Enterprise の境界。
- Archive: DSS, VRI, LTV health — 長期アーカイブと LTV ヘルス。
- 署名検証 — 検証側: 暗号 CMS / タイムスタンプ検証、TSA-at-genTime、およびアーカイブチェーン検証。
- PAdES ベースラインマッピング — エディション全体にわたる B-B、B-T、B-LT、B-LTA。
- PAdES · DSS · VRI · LTV — 用語集の用語。