長期驗證

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

概覽

你今天驗證的簽章，建立在無法長久保存的事實之上：會過期的憑證、可能下線的撤銷伺服器，以及會逐漸變弱的雜湊演算法。長期驗證會趁證據仍可取得時，把它寫入文件。如此一來，多年後仍可檢驗該簽章，而不必再向任何人查詢資料。

為什麼這很重要

數位簽章的危險特性在於，它可能悄悄變得無法驗證，外觀卻毫無改變。檔案內容沒有任何變動。憑證授權單位不再回覆某張早已過期憑證的查詢；需要該答覆的驗證器，也就再也拿不到它。一份在簽署當天毫無疑問有效的合約，十年後卻成了「無法判定」。而十年後，往往正是爭議最可能發生、利害關係也最重大的時刻。如果你的保存義務是以年為單位計算，缺少長期驗證的簽章就是一項日後才會浮現的風險。

簡短版本

• 簽章的有效性取決於具有時效性的外部事實：憑證有效期間，以及伺服器提供的撤銷狀態。
• 憑證過期之後，這些事實便會變得無法取得——授權單位沒有永遠回應的義務。
• 長期驗證會在簽署當下擷取證據——憑證、OCSP 回應、CRL——並將它們嵌入文件的**文件安全儲存區（DSS）**之中。
• 接著由一個文件時間戳記證明證據本身在那一刻確實存在且有效；這個時間戳記也可在自身保護變弱前更新。
• 其結果是：文件本身就帶有證明。驗證不再取決於某個伺服器是否仍然存在。

NextPDF 的處理方式

其原則是「趁還能蒐集時就蒐集證明，然後封存」。當 NextPDF 產生長期簽章時，會蒐集憑證鏈以及撤銷回應，藉以證明簽署憑證在簽署當下狀態良好。它會將這些內容以嵌入值（而非連結）的形式寫入 DSS，接著在整體之上加上一個文件時間戳記。嵌入值正是關鍵所在。指向撤銷伺服器的連結，正是長期驗證要消除的那種相依性。

這些長期層會寫成個別的文件修訂版本，以附加方式加入，而不擾動原始簽章的位元組範圍。第一個簽章仍然可驗證。長期資料是加在它周圍，而不是加進它之中。當文件時間戳記本身的保護隨時間衰退時，封存等級允許在其之上再疊加另一個時間戳記。其結果會形成一條鏈：每個時間戳記都為它之下的所有內容背書。

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

長期驗證如何讓簽章在時間推移中維持可驗證：先建立簽章，趁證據還能取得時加以擷取，再以文件時間戳記將證據封存，並在封存變弱之前加以更新。

證據說明了什麼

Evidence § Standard-backed Evidence: Standard-backed 這項需求已由 Spec Spec: RFC 6960, §4.4.4 RFC 6960 §4.4.4 明確說明：OCSP 回應方可在憑證過期後仍保留撤銷資訊，而封存截止日期讓應用程式得以證明某個簽章在其產生當天是否可靠——即使用來驗證它所需的憑證早已過期亦然。這正是長期驗證存在的全部理由。撤銷回應只會在有限期間內保持可用，因此你必須在那段期間結束前擷取它。

這套機制源自 ETSI。 Spec Spec: ETSI EN 319 142-2, §5.5 ETSI EN 319 142-2 §5.5 指出，長期行為要求一個文件安全儲存區，以值的形式承載驗證資料，接著再加上一個文件時間戳記。 Spec Spec: ISO 32000-2, §12.8.3.3 ISO 32000-2 §12.8.3.3 將這些要求串連在一起： PAdES 即 CAdES CMS 結合長期驗證（§12.8.4）以及文件時間戳記字典（§12.8.5）。而且 Spec Spec: ETSI EN 319 142-2, §6.3.2.2 ETSI EN 319 142-2 §6.3.2.2 正說明了為什麼時間戳記應及早加上：它應在簽署後立即套用，讓所記錄的時間盡可能貼近真實時間。

NextPDF 的引擎將其實作為 B-LT 與 B-LTA 等級：嵌入 DSS 中的撤銷值、用來封存這些值的文件時間戳記，以及更新該封存的封存迴圈——全部以附加修訂版本寫入，使原始簽章的位元組範圍保持完整不變。

Human-factors note: Human-factors note

最重要的訊息——趁證據還能取得時就加以擷取，因為日後就無法取得——會先於任何 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 Spec: ISO 32000-2, §12.8 ISO 32000-2 §12.8 所描述的 DocTimeStamp 修訂版本。該結構尚未經過設定檔符合性測試，且該接合點不對 ETSI 符合性或法律有效性作任何斷言。B-LT 與 B-LTA 等級需要 Pro 與 Enterprise 兩者；在任何其他方案上，該接合點會以失敗封閉（fail closed）方式處理，而不是產生部分結果。加密文件對於 B-LT 與 B-LTA 同樣採失敗封閉方式處理——寧可不在加密內容之上寫入 DSS 與文件時間戳記，也不會錯誤寫入。

這項選擇無法事後低成本補做。撤銷證據必須在簽署當下、趁回應仍然存在時加以擷取。決定「我們日後再加上長期驗證」，通常等同於決定「等到我們需要時，手上不會有證據。」

常見的誤解

那項誤解是「長期驗證會讓簽章永遠有效」。它並不會讓任何東西變得有效；它保留的是檢驗能力，用以檢驗在簽署當下就已確立的有效性。如果文件簽署時憑證就已遭撤銷，嵌入這項事實也救不了該簽章，反而會把這項失效永久記錄下來。長期驗證是一種保存證明的機制，而非建立證明的機制。第二項誤解是認為 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 中的憑證與撤銷值、用於封存的文件時間戳記，以及可更新的封存迴圈。

相關文件

• PAdES 基準設定檔——說明 B-LT 與 B-LTA 在等級進程中的位置，以及各自增加了什麼。
• 時間戳記與受信任時間——封存嵌入證據所用的文件時間戳記。
• 正確驗證簽章——驗證器如何使用嵌入的資料，以及為什麼單憑「有效」並不完整。
• 已簽署協議工作流程——在實務中套用長期驗證資料的端到端工作流程。

詞彙表

• 長期驗證（LTV）——嵌入驗證簽章所需的證據，讓日後驗證不再依賴外部服務。
• 文件安全儲存區（DSS）——用以承載長期驗證所需的嵌入式憑證與撤銷資料的 PDF 結構。
• OCSP 回應——針對某張憑證在特定時間點的撤銷狀態所做的已簽署聲明（線上憑證狀態協定，RFC 6960）。
• CRL——憑證撤銷清單；一份列出已撤銷憑證的已簽署清單。
• 文件時間戳記——套用於整份文件的 RFC 3161 時間戳記，用以證明嵌入的證據在當時確實存在且有效。
• 封存迴圈——在前一個文件時間戳記的保護變弱之前，反覆加上新的文件時間戳記，以延長可驗證性。