Enterprise 版本
封存：DSS、VRI、LTV 健康、文件時間戳記
NextPDF Enterprise 會隨時間維持一份長期簽章的有效性。它會寫入文件安全儲存區（DSS）與每個簽章的 VRI，以 LTV 健康檢查檢視封存完整性，並在時間戳記憑證過期前以文件時間戳記重新蓋章。本頁屬於行為層級。它說明封存介面做了什麼、檢視了什麼，以及驗證器仍然要決定什麼。
可用性與授權
標題為「可用性與授權」的區段此能力隨 NextPDF Enterprise（nextpdf/enterprise）出貨，並以 Enterprise 級授權封套啟用。不具備該權利的部署不會載入此能力的類別。比較各版本並取得授權。
DSS、VRI、LTV 健康與封存迴圈介面僅限 Enterprise。NextPDF Core 產生 B-B 與 B-T 基準層級（Core 隨附 RFC 3161 時間戳記路徑，因此 B-T 不需要進階套件）。NextPDF Pro 產生 B-B 與 B-T 基準層級，但不產生 DSS 或文件時間戳記。B-LT 與 B-LTA 層級僅由 Enterprise 產生，這與 Pro 安全頁面上已發布的層級表相符。在僅有 Pro 的部署中，請求長期層級會 fail closed，並附上指名缺少之 Enterprise 元件的訊息。
| PAdES 層級 | 加入 | 產生器版本 |
|---|---|---|
| B-B | 帶有已簽署屬性的 CMS 簽章 | Core、Pro、Enterprise |
| B-T | 簽章值上受信任的 RFC 3161 時間戳記 | Core、Pro、Enterprise |
| B-LT | 帶有驗證資料的文件安全儲存區 | 僅 Enterprise（nextpdf/enterprise） |
| B-LTA | 用於封存有效性的文件時間戳記（封存迴圈） | 僅 Enterprise（nextpdf/enterprise） |
這是規範的「層級→級別」矩陣：B-B 是每個版本都會產生的基準；B-T（加時間戳記）由 Core、Pro 與 Enterprise 產生；B-LT 與 B-LTA 僅限 Enterprise。
composer require nextpdf/enterprisenextpdf/enterprise 依賴 nextpdf/core 與 nextpdf/pro。封存介面是 Enterprise 版本的一部分。
概念總覽
標題為「概念總覽」的區段長期驗證建立在兩種結構之上：DSS 與文件時間戳記字典——ISO 32000-2 §12.8。DSS 存放在簽署憑證過期後驗證簽章所需的憑證、OCSP 回應與 CRL——ISO 32000-2 §12.8.4.3。VRI 是針對該資料、以簽章內容雜湊鍵控的每個簽章索引。文件時間戳記字典將整個文件狀態錨定於時間之中——ISO 32000-2 §12.8.5。ETSI EN 319 142-2 描述相同的長期形態——§5.5——以及對它的處理器支援——§6.3.3.3。
時間戳記憑證有有限的存活期。在它過期前，封存迴圈會為時間戳記憑證鏈收集新鮮的撤銷資料、重寫 DSS，並在更新後的狀態之上加入一個新的文件時間戳記。每一個新的時間戳記都會涵蓋先前的那些，因此只要迴圈依排程執行，信任鏈就能無限延伸。該時間戳記是一次 RFC 3161 交換——§2.4.1——帶有一個 UTC genTime（§2.4.2）。
LTV 健康檢查會檢視一份既有文件的封存完整性：DSS 是否存在、是否嵌入了 OCSP 回應或 CRL、憑證儲存區與每個簽章的 VRI 是否存在。它檢查的是結構性存在；它不會以密碼學方式重新驗證嵌入的 OCSP 或 CRL 資料。撤銷資料有一個新鮮度窗：一份 OCSP 回應會回報 good、revoked 或 unknown——RFC 6960 §2.2——並受 thisUpdate/nextUpdate 界定——RFC 6960 §4.2。
已封存的簽章是否能驗證通過，仍是驗證器依其信任錨點與新鮮度政策所做的決定。封存介面讓資料維持完整且時間錨定；它不主張任何受信任的結果。
它為何這樣運作
標題為「它為何這樣運作」的區段封存介面只能透過 Core 合約——LtvManagerInterface 與 SignatureLevel enum——觸及，絕不透過具體的 Enterprise 類別。那道邊界是承重的。呼叫端程式碼從 Core 到 Enterprise 保持一致，因此升級是加入能力而不需重寫。enum 會將請求的層級解析到已安裝的環境。沒有 Enterprise 產生器的長期請求會 fail closed，而非悄悄降級成一份未封存的簽章。這之所以重要，是因為一份看似長期、卻不帶 DSS 或文件時間戳記的簽章，會在數年後——當無人留意時——驗證失敗。
設計背景：長期驗證。
API 介面
標題為「API 介面」的區段封存介面透過 Core 長期合約與 Enterprise 合規原則介面使用。正式環境程式碼應依賴合約。
| 型別 | 種類 | 角色 | 穩定度 | 自 |
|---|---|---|---|---|
LtvManagerInterface | interface（NextPDF\Contracts） | 長期驗證產生器與封存迴圈合約 | stable | 1.0.0 |
TsaClientInterface | interface | 封存迴圈所使用的 RFC 3161 TSA 用戶端 | stable | 1.0.0 |
SignatureLevel | enum（NextPDF\Security\Signature） | PAdES 層級：B-LTA 是封存層級 | stable | 1.0.0 |
LTV 健康檢查以一條 Enterprise 合規原則的形式執行。它會發出結構化的 findings——某結構存在時為資訊性，而某封存結構缺少時為警告或錯誤——每一項都帶有 ISO 32000-2 §12.8.4.3 參考。具體的封存類別屬於內部實作，不是公開 API 的一部分。
程式碼範例——快速上手
標題為「程式碼範例——快速上手」的區段<?php
declare(strict_types=1);
require_once __DIR__ . '/../../vendor/autoload.php';
use NextPDF\Security\Signature\SignatureLevel;
/** * B-LTA is the archival level: DSS plus a document timestamp, * maintained by the archival loop. Requires nextpdf/enterprise. * * @return bool True when this level needs a document timestamp. */function isArchivalLevel(SignatureLevel $level): bool{ return $level->requiresDocumentTimestamp();}程式碼範例——正式環境
標題為「程式碼範例——正式環境」的區段<?php
declare(strict_types=1);
require_once __DIR__ . '/../../vendor/autoload.php';
use NextPDF\Contracts\LtvManagerInterface;use NextPDF\Exception\NextPdfException;use Psr\Log\LoggerInterface;
final readonly class ArchivalMaintenance{ public function __construct( private LtvManagerInterface $ltv, private LoggerInterface $logger, ) {}
/** * Run the archival loop before the timestamp certificate expires. * * The loop collects fresh revocation material for the timestamp * certificate chain, rewrites the DSS, and adds a new document * timestamp over the updated state. * * @throws NextPdfException When no TSA is configured, or under a * strict-offline network policy. */ public function maintain(): void { try { // The orchestrator drives DSS rewrite + document timestamp via // the resolved LtvManagerInterface. Schedule this before the // timestamp certificate's notAfter. $this->logger->info('archival loop completed'); } catch (NextPdfException $e) { $this->logger->error('archival loop failed', ['reason' => $e->getMessage()]); throw $e; } }}請在時間戳記憑證過期之前排程封存迴圈。在過期後才執行的迴圈無法延伸信任鏈。
邊界案例與陷阱
標題為「邊界案例與陷阱」的區段- 迴圈是一個排程，不是一次性動作。 唯有在每個時間戳記憑證過期前迴圈持續執行的期間，B-LTA 有效性才會是無限的。請將它視為一項維運義務。
- 健康檢查屬於結構性。 LTV 健康檢查會回報 DSS、OCSP/CRL、憑證儲存區與 VRI 是否存在。它不會以密碼學方式重新驗證嵌入的撤銷資料；一份存在但已過時的 OCSP 回應，仍會回報為存在。
- 缺少 VRI 是警告，不是錯誤。 沒有 VRI 的 DSS 仍然有效；健康檢查會將其標記為警告，因為某些驗證器在有 VRI 時能更好地顯示每個簽章的狀態。
- 嚴格離線會阻斷迴圈。 封存迴圈需要新鮮的 TSA 符記與新鮮的撤銷資料；在嚴格離線網路政策下，它會引發錯誤。
- 沒有 TSA 就沒有封存迴圈。 與 B-LTA 本身一樣，未設定 TSA 用戶端時，迴圈會引發錯誤。
健康檢查是對文件的一次結構性掃描，成本不高。一次封存迴圈迭代的成本為一次 TSA 來回，加上為時間戳記憑證鏈進行的 OCSP/CRL 擷取；預先收集的資料可省去這些擷取來回。1500 ms 的牆鐘預算涵蓋暖機連線下的一次迴圈迭代。可重現性設定檔為 structural：每一個文件時間戳記都會嵌入它的 genTime，因此重新蓋章的執行在那些位元組上會不同，但結構相同。
安全注意事項
標題為「安全注意事項」的區段- 有效性由驗證器決定。 封存介面讓資料維持完整且時間錨定。驗證器是否接受它，取決於它的信任錨點與撤銷新鮮度政策。
- 新鮮度有時鐘。 嵌入的 OCSP/CRL 資料受其更新欄位界定。封存迴圈正是讓信任鏈在多年間維持於可信任窗口內的關鍵。
- 結構性健康不等於密碼學驗證。 一次通過的 LTV 健康檢查只代表那些結構存在，而非每一個嵌入的回應目前都值得信任。
- 請參閱 簽章：PAdES B-LT / B-LTA 與威脅模型一節。
資料落地與 PII 緩解措施
標題為「資料落地與 PII 緩解措施」的區段封存迴圈會聯絡 OCSP/CRL 回應器與 TSA。在受資料落地限制的部署中，請預先收集撤銷資料，並在不需要迴圈之處使用嚴格離線政策，或將 TSA 與回應器置於區域內。DSS 會嵌入帶有主體身分的憑證；封存介面只加入驗證所需的資料，不會在它所處理的憑證鏈之外另加身分。
安全遙測與日誌清洗
標題為「安全遙測與日誌清洗」的區段健康檢查 findings 指名的是缺少的結構與 ISO 條款，而非文件內容。封存迴圈診斷會回報迴圈結果與缺少資料的情況。兩者皆不記錄私鑰或完整憑證內容。當回應器與 TSA 的 URL 可能揭露內部基礎設施時，請從日誌中清洗它們。
FIPS 模式行為
標題為「FIPS 模式行為」的區段FIPS 140-3 加密政策設定檔是隨安全模組一併記載的 Enterprise 功能。封存介面僅為文件時間戳記加入 SHA-256 摘要與 RFC 3161 交換；它不引入任何其他原語。在 FIPS 設定檔下，會產生相同的 DSS、VRI 與文件時間戳記結構；該約束適用於摘要與簽署演算法，而非封存配置。
威脅模型
標題為「威脅模型」的區段| 資產 | 對手 | 風險 | 緩解措施 |
|---|---|---|---|
| 時間戳記鏈連續性 | 錯過迴圈排程 | 在某時間戳記憑證過期後信任鏈中斷 | 在每個時間戳記憑證過期前執行封存迴圈 |
| 嵌入的撤銷資料 | 接受過時資料 | 驗證器信任了過期的 OCSP/CRL 資料 | 新鮮度窗界定有效性；迴圈在過期前重新收集 |
| LTV 健康訊號 | 對結構性通過的過度信任 | 一份看似完整、卻帶有過時資料的封存 | 健康檢查聲明它屬於結構性，而非密碼學重新驗證 |
| 文件時間戳記 | TSA 無法連線或遭入侵 | 沒有新的時間錨點 | 呼叫端選定的 TSA；未設定 TSA 時迴圈 fail closed |
一致性
標題為「一致性」的區段| 聲明 | 標準 | 條款 |
|---|---|---|
| 長期驗證使用一個 DSS 與一個文件時間戳記字典。 | ISO 32000-2 | §12.8 |
| DSS 存放憑證、OCSP 回應與 CRL；VRI 為每個簽章。 | 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 的長期層級對齊；不主張任何一致性測試結果或第三方認證。ETSI EN 319 142-1 基準層級部分不在所引用的證據集合之內；所引用的 ETSI 證據是 EN 319 142-2，而 ISO 與 RFC 錨點承載長期、時間戳記與撤銷聲明。
行為合約
標題為「行為合約」的區段- DSS、VRI、LTV 健康與封存迴圈介面僅限 Enterprise。Core 產生 B-B 與 B-T（加時間戳記）；僅有 Pro 的部署產生 B-B 與 B-T，但無法產生或維持長期（B-LT/B-LTA）簽章。
- LTV 健康檢查回報 DSS、OCSP/CRL、憑證儲存區與 VRI 的結構性存在；它不會以密碼學方式重新驗證嵌入的撤銷資料。
- 封存迴圈會重寫 DSS，並在更新後的狀態之上加入一個新的文件時間戳記。它必須在時間戳記憑證過期前執行。
- 未設定 TSA 或在嚴格離線網路政策下時，迴圈會 fail closed。
發布邊界
標題為「發布邊界」的區段本頁僅記載外部可觀察的行為與受支援的公開 API 介面。內部命名空間路徑、輔助類別、機制表格、runbook 檔名，以及工單前綴皆不在範圍內。
Core 回退
標題為「Core 回退」的區段在僅有 Core 的部署中，軟體簽署器會產生 PAdES B-B 與 B-T（Core 隨附 RFC 3161 時間戳記路徑）。Core 沒有 DSS、VRI、LTV 健康或封存迴圈介面；長期層級會 fail closed，並附上具名錯誤。本頁所述的封存介面需要 nextpdf/enterprise。請參閱 安全 / 簽署（Core）。
Pro 回退
標題為「Pro 回退」的區段在僅有 Pro 的部署中，受支援的簽署路徑是 Core 的 B-B/B-T 基準，加上 Pro 的遠端與雲端 KMS 簽署工作流程。Pro 不產生任何 DSS、任何 VRI，以及任何文件時間戳記，也不執行任何封存迴圈。在僅有 Pro 的部署中，請求長期層級的設定會 fail closed，並附上指名缺少之 Enterprise 元件的訊息。請參閱 Pro 安全。
Enterprise 邊界註記
標題為「Enterprise 邊界註記」的區段DSS/VRI 組裝、LTV 健康檢查，以及封存迴圈僅以行為層級描述。內部的 DSS 重寫排序、每個簽章的 VRI 鍵控內部實作、健康 finding 分類內部實作，以及迴圈排程內部實作，皆不在公開介面範圍內，此處不予重現。
部署邊界
標題為「部署邊界」的區段NextPDF Enterprise 會維護驗證資料；它整合呼叫端提供的 OCSP/CRL 回應器與一個 RFC 3161 TSA。它本身不會營運、託管或保證那些回應器或 TSA 的可用性。無限有效性取決於那些回應器、TSA、封存迴圈排程，以及操作者——而非單靠 NextPDF Enterprise。 操作者負責 TSA 的選擇與可連線性、撤銷回應器的存取或預先收集資料、網路政策，以及在每個時間戳記憑證的 notAfter 之前執行封存迴圈。
法律合規邊界
標題為「法律合規邊界」的區段它涉及加密簽章的長期驗證與封存。與定義於 ETSI EN 319 142 的長期結構對齊是結構性陳述，並非法律意見，也不是認證。NextPDF 不做任何 PAdES 認證聲明。 關於你的法規義務，請諮詢你自己的合規與法律顧問。
另請參閱
標題為「另請參閱」的區段- 簽章：PAdES B-LT / B-LTA — 長期產生器。
- 安全 / 簽署（Core） — CMS、RFC 3161、RFC 5280、OCSP/CRL。
- Pro 安全 — B-B 基準與 Enterprise 邊界。
- PAdES 基準對應 — 跨版本的 B-B、B-T、B-LT、B-LTA。
- DSS · VRI · LTV · PAdES — 詞彙表條目。