Enterprise エディション

署名: PAdES B-LT / B-LTA、DSS、ドキュメントタイムスタンプ

概要

NextPDF Enterprise は、Core の Cryptographic Message Syntax (CMS) 署名の上に長期プロデューサーを追加します。すなわち、Document Security Store (DSS)、署名ごとの検証関連情報 (VRI)、そしてドキュメントタイムスタンプです。これらの構造は、PDF Advanced Electronic Signatures (PAdES) のベースライン署名を B-B から B-LT へ、さらに B-LTA へと引き上げます。このページは挙動を説明します。プロデューサーが何を書き込むか、何を決定しないか、そして Pro の境界がどこから始まるかを示します。

提供状況とライセンス

この機能は NextPDF Enterprise (nextpdf/enterprise) に同梱され、Enterprise ティアのライセンスエンベロープで有効化されます。そのエンタイトルメントを持たないデプロイメントは、この機能のクラスをロードしません。エディションを比較してライセンスを取得する。

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-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 適格を主張するものではありません。これは Pro セキュリティページに公開されているティア表と一致します。

インストール

composer require nextpdf/enterprise

nextpdf/enterprise は nextpdf/core と nextpdf/pro に依存します。Private Packagist 上で NextPDF ライセンス資格情報を使ってパッケージを解決してください。

概念的な概要

PAdES ベースライン署名には 4 つのレベルがあります。各レベルは前のレベルに情報を追加します。B-B は署名属性付きの CMS 署名です。B-T は署名値に信頼された RFC 3161 タイムスタンプを追加します。B-LT は、署名証明書が失効した後に検証者が必要とする証明書、Online Certificate Status Protocol (OCSP) レスポンス、証明書失効リスト (CRL) を保持する DSS を追加します。B-LTA は DSS を含むドキュメント全体の状態に対するドキュメントタイムスタンプを追加し、検証情報が時間的にアンカーされた状態を保ちます。

Core は CMS SignedData を構築し、それを DER エンコードして署名辞書の Contents エントリに格納します — ISO 32000-2 §12.8.1。長期検証は 2 種類の辞書を使用します。すなわち document security store と document timestamp dictionary です — 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 (TSA) との RFC 3161 交換です。リクエストは Time Stamp Information (TSTInfo) 値を返し — RFC 3161 §2.4.1 — その genTime はトークンが作成された協定世界時 (UTC) の瞬間です — RFC 3161 §2.4.2。トークンは、ファイル全体をカバーする /SubFilter /ETSI.RFC3161 を持つ /DocTimeStamp 辞書に埋め込まれます。

生成された署名が 検証される かどうかは、検証者が設定されたトラストアンカーと失効ポリシーを用いて決定します。プロデューサーは情報を埋め込みますが、信頼された結果を主張しません。この境界は、重要な箇所で以下に繰り返し述べられます。

順序は重要です。DSS は B-LTA のドキュメントタイムスタンプより前に書き込まれなければなりません。なぜなら、タイムスタンプは既に検証情報を含むドキュメント状態をカバーしなければならないからです。以下のフローはそのプロデューサーの順序を示します。

Diagram

なぜこの方式なのか

長期有効性には 1 つの厳格な順序規則があります。すなわち、ドキュメントタイムスタンプは検証情報をカバーしなければなりません。したがって DSS は常に最初に書き込まれ、B-LTA タイムスタンプは既に DSS を含むファイル状態に対して取得されます。この順序を逆にすると、タイムスタンプは検証者が何年も後に読む何もかもを保護しません — 証明書、OCSP、CRL がそのカバー範囲の外に置かれてしまうからです。したがってプロデューサーは情報を埋め込んで時間的にアンカーしますが、信頼された結果を主張する手前で止まります。その決定は検証者とそのトラストアンカーに属します。失効情報が不足しているときにフェイルクローズするということは、長期レベルを主張するドキュメントが、その主張を裏付ける証拠なしに出荷されることは決してないということです。その結果、署名証明書が失効した後も、元のレスポンダーに接続することなく、第三者が長期にわたって再検証できる署名が得られます。

設計背景: 長期検証。

API サーフェス

Enterprise の長期プロデューサーは Core のコントラクトを通じて利用します。プロダクションコードは具体的な Enterprise 実装型ではなく、コントラクトに依存します。

型	種別	役割	安定性	Since
`SignerInterface`	インターフェース (`NextPDF\Contracts`)	呼び出し側向けの Core 署名コントラクト	stable	1.0.0
`SignatureLevel`	列挙型 (`NextPDF\Security\Signature`)	PAdES レベルセレクター: B-B、B-T、B-LT、B-LTA	stable	1.0.0
`LtvManagerInterface`	インターフェース (`NextPDF\Contracts`)	実行時に解決される長期検証プロデューサーのコントラクト	stable	1.0.0
`TsaClientInterface`	インターフェース	ドキュメントタイムスタンプのためにプロデューサーが呼び出す 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 と列挙型に依存してください。

コードサンプル — クイックスタート

<?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\Core\Document;
use NextPDF\Exception\NextPdfException;
use NextPDF\Security\Signature\CertificateInfo;
use NextPDF\Security\Signature\SignatureLevel;
use NextPDF\Security\Timestamp\TsaClient;
use Psr\Http\Client\ClientInterface;
use Psr\Log\LoggerInterface;

/**
 * Produce a PAdES B-LTA signature through the high-level Document seam, which
 * drives the Core PadesOrchestrator and the Enterprise long-term producer in the
 * load-bearing order: sign, write the DSS (LtvManager::enableLtv), then add the
 * /DocTimeStamp over the state that already includes it (::addDocumentTimestamp).
 */
final readonly class LongTermSigner
{
    public function __construct(
        private TsaClient $tsa,         // RFC 3161 TSA client (required for B-T and above).
        private ClientInterface $http,  // PSR-18 client that fetches OCSP/CRL for the DSS.
        private LoggerInterface $logger,
    ) {}

    /**
     * Sign at B-LTA and return the long-term-signed PDF bytes; requesting B-LTA
     * without the nextpdf/enterprise producer fails closed rather than downgrading.
     *
     * @throws NextPdfException Fail-closed: enterprise producer absent
     *                          (SignatureLevelUnreachableException), no HTTP client
     *                          (SignatureException), or missing material (LtvException).
     */
    public function sign(CertificateInfo $certInfo): string
    {
        try {
            $document = Document::createStandalone();
            $document->addPage();
            $document->setSignature($certInfo, SignatureLevel::PAdES_B_LTA, $this->tsa, $this->http);

            return $document->getPdfData();
        } catch (NextPdfException $e) {
            $this->logger->error('long-term B-LTA 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 の脅威モデルのセクションおよびアーカイブ: DSS、VRI、LTV ヘルスを参照してください。

データレジデンシーと PII の緩和策

OCSP および CRL の取得は、各証明書に記載されたレスポンダーに接続します。それらのエンドポイントと TSA はリクエストのメタデータを見ます。データレジデンシーに制約のあるデプロイメントでは、失効情報を事前収集し、厳格オフラインポリシー下で実行することで、署名時にレスポンダーや TSA が接続されないようにしてください。証明書はサブジェクトの識別情報を保持します。プロデューサーは検証に必要な証明書を埋め込み、チェーンを超えて識別情報を追加しません。あなたが提供する証明書からサブジェクトフィールドを削除することもしません。

安全なテレメトリとログのスクラビング

プロデューサーの診断は、レベル、チェーン位置、および情報欠如の状態を報告します。秘密鍵や完全な証明書本体はログに記録しません。PSR-3 ロガーを接続する際は、署名フローの診断ログを非プロダクションの詳細度に保ち、レスポンダーの URL が内部インフラを明かす場合はスクラブしてください。埋め込まれた OCSP/CRL バイトは、ログの内容ではなくドキュメントの内容として扱ってください。

FIPS モードの挙動

Federal Information Processing Standards (FIPS) 140-3 暗号ポリシープロファイルは、セキュリティモジュールとともに文書化された Enterprise 機能です。長期プロデューサーは、ドキュメントタイムスタンプに使用される SHA-256 ダイジェストと RFC 3161 交換を超えて、独自の暗号プリミティブを追加しません。署名プリミティブは Core 署名者のものです。FIPS プロファイルが有効な場合、同じ DSS およびドキュメントタイムスタンプ構造が生成されます。制約は基盤となる署名およびダイジェストアルゴリズムに適用され、DSS のレイアウトには適用されません。

脅威モデル

資産	敵対者	リスク	緩和策
DSS 失効情報	古い情報の受容	検証者が失効した失効データを信頼する	OCSP/CRL の鮮度フィールドが有効性を区切る。アーカイブループが失効前に再スタンプする
B-LTA ドキュメントタイムスタンプ	TSA の侵害または到達不能な TSA	信頼できる時間アンカーが存在しない	呼び出し側が選ぶ TSA。TSA が構成されていない場合 B-LTA はフェイルクローズする
長期の主張	情報の暗黙の欠如	失効データのない「長期」PDF	フェイルクローズ施行のデフォルトが警告ではなくエラーを発生させる
署名検証	検証者の信頼の誤設定	検証者が主張すべきでない見かけ上の有効性	プロデューサーは情報を埋め込むだけであると明言する。信頼の決定は検証者のもの

適合性

主張	標準	条項
署名値 (またはタイムスタンプトークン) は `/Contents` に DER エンコードして格納される。	ISO 32000-2	§12.8.1
長期検証は DSS とドキュメントタイムスタンプ辞書を使用する。	ISO 32000-2	§12.8
DSS は証明書、OCSP レスポンス、CRL を保持する。	ISO 32000-2	§12.8.4.3
ドキュメントタイムスタンプはドキュメントタイムスタンプ辞書を使用する。	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 の署名リファレンスと同様に、長期およびタイムスタンプの主張を担います。

挙動コントラクト

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 に劣化するのではなくエラーを発生させます。

公開の境界

このページは、外部から観測可能な挙動とサポートされるパブリック API サーフェスのみを文書化します。内部の名前空間パス、ヘルパークラス、メカニズム表、ランブックのファイル名、チケットのプレフィックスは対象外です。

Core フォールバック

Core のみのデプロイメントでは、ソフトウェア署名者がローカルキーまたは Core の署名戦略コントラクトを通じて提供されたキーを使って PAdES B-B および B-T を生成します。Core は RFC 3161 タイムスタンプパスを同梱するため、B-T はいかなるプレミアムパッケージもなしで到達可能です。Core には DSS、VRI、ドキュメントタイムスタンプのプロデューサーがありません。B-LT または B-LTA を要求すると、名指しされたエラーとともにフェイルクローズします。セキュリティ / 署名 (Core) を参照してください。

Pro フォールバック

Pro のみのデプロイメントでは、サポートされる署名パスは Pro B-B ベースラインと Pro B-T レベル (Pro は Core の RFC 3161 スタックを組み合わせて signature-time-stamp 未署名属性を追加します)、およびそのリモートおよびクラウドの key management service (KMS) 署名戦略です。Pro は DSS、VRI、ドキュメントタイムスタンプを生成しません。Pro のみのデプロイメントで B-LT または B-LTA を要求する構成は、不足している Enterprise コンポーネントを名指しするメッセージとともにフェイルクローズします。Pro の署名サーフェスについては Pro セキュリティを参照してください。

Enterprise 境界に関する注記

DSS、VRI、ドキュメントタイムスタンプのプロデューサーは挙動レベルでのみ説明されています。内部の DSS 組み立て順序ロジック、署名ごとの VRI キーイングの内部、アーカイブループのスケジューリングの内部は、パブリックサーフェスの対象外であり、ここでは再現されません。

デプロイメントの境界

NextPDF Enterprise は検証情報を埋め込み、呼び出し側が提供する OCSP/CRL レスポンダーおよび RFC 3161 TSA と統合します。それ自体はそれらのレスポンダーや TSA を運用、ホスト、または可用性を保証することはありません。長期有効性は、レスポンダー、TSA、アーカイブループのスケジュール、および運用者に依存します — NextPDF Enterprise 単独に依存するものではありません。運用者は、TSA の選択と到達性、失効レスポンダーへのアクセスまたは事前収集された情報、ネットワークポリシー、そして各タイムスタンプ証明書が失効する前にアーカイブループを実行することについて責任を負います。

法的コンプライアンスの境界

これは暗号署名と長期検証に関するものです。ETSI EN 319 142 で定義された B-LT および B-LTA 構造との整合は構造的な陳述であり、法的意見でも認証でもありません。NextPDF は PAdES 認証の主張を一切行いません。 規制上の義務については、コンプライアンスおよび法務の助言者に相談してください。