PAdES 基準設定檔

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

概覽

PAdES 定義了四個基準層級——B-B、B-T、B-LT、B-LTA——彼此層層堆疊，並建立於前一層之上。每一層都新增一種特定形式的證據。本頁說明這段遞進過程，協助你挑選仍能滿足該義務的最低層級，而不是你恰好聽過名字的最高層級。

為何重要

有人選用「B-LTA」，是因為它聽起來最周全；也有人選用「B-B」，是因為它最省事。兩者都只是猜測。決定你所需層級的是一個問題，而非偏好：這份簽章必須維持可驗證多久，又必須由誰來驗證？ 選得太低，原本在簽署當天有效的簽章，會在憑證到期時變得無法驗證。選得太高，你便會承擔並不需要的時戳機構與驗證材料基礎設施，外加一項必須持續維護的封存義務。若層級日後無法變更，就會為錯誤的層級付出代價。

精簡版說明

• 這四個層級是累積的。每一層都是在前一層之上再新增一項內容。
• B-B——附帶必要簽署屬性的簽章。證明是誰以及簽了什麼。
• B-T——B-B 再加上一個對該簽章的受信任時戳。不依賴簽署者的時鐘，證明何時簽署。
• B-LT——B-T 再加上內嵌的驗證材料（憑證與撤銷資料）。文件自行攜帶證據，證明憑證在簽署當時是有效的。
• B-LTA——B-LT 再加上一個文件時戳，並隨時間反覆施加。讓整份內容跨越數十年與演算法變遷仍維持可驗證。
• 依義務的存續期間來挑選層級，而不是依看起來最安全的那個選項。

NextPDF 的處理方式

NextPDF 將層級建模為一個明確且有序的選擇，並且不假裝成功。你要求一個層級。引擎會產生恰好那個層級，否則就以可採取行動的錯誤失敗。它不會悄悄以較低層級簽署，卻讓合規紀錄宣稱是較高的層級。這套設計的目的，正是為了防止在基礎設施缺失時，把一個 B-LTA 的請求悄悄降級為 B-T。每個層級的需求都會被編碼為述詞：是否需要時戳、是否需要內嵌的驗證材料、是否需要文件時戳。引擎會逐一走訪這些述詞，不是全部滿足，就是停下。

下方的遞進過程，正是引擎所強制執行、也是標準所定義的那一套。

層級	相對前一層所新增的內容	它所回答的問題	對你的部署有何需求
B-B	簽署屬性：content-type、message-digest、signing-time、signing-certificate-v2	是誰簽署的，以及確切是哪些位元組？	一把簽署金鑰與一張憑證
B-T	一個涵蓋簽章值的受信任時戳	它是何時簽署的，可被證明嗎？	一個時戳機構（TSA）
B-LT	內嵌的憑證與撤銷資料（一個 DSS）	憑證在簽署當時是否有效——日後能否證明？	TSA，以及可在簽署當時存取撤銷資料的管道
B-LTA	一個可隨時間更新的文件時戳	這份內容在數十年後是否仍可驗證？	TSA，以及一套會重新施加時戳的封存流程

最關鍵的躍進是從 B-T 到 B-LT。B-T 證明何時。B-LT 讓文件在信任方面自給自足：它不再仰賴某個憑證機構在多年之後仍可連線並回應查詢。

1. Step 1 of 4: ISO 32000-2 §12.8 — signatures, LTV, document timestamp ISO 32000-2 §12.8 — signatures, LTV, document timestamp
2. Step 2 of 4: ETSI EN 319 142-1 PAdES baseline levels B-B…B-LTA ETSI EN 319 142-1 PAdES baseline levels B-B…B-LTA
3. Step 3 of 4: RFC 3161 Timestamp token (introduced at B-T) RFC 3161 Timestamp token (introduced at B-T)
4. Step 4 of 4: RFC 6960 OCSP revocation evidence (embedded at B-LT) RFC 6960 OCSP revocation evidence (embedded at B-LT)

PAdES 遞進過程背後的標準：ISO 32000-2 定義了簽章與驗證材料如何置於 PDF 之中；ETSI EN 319 142-1 定義了各個基準層級；RFC 3161 定義了 B-T 所引入的時戳；RFC 6960 定義了 B-LT 所內嵌的撤銷證據。

證據怎麼說

Evidence § Standard-backed Evidence: Standard-backed 層級定義出自 ETSI。 Spec Spec: ETSI EN 319 142-1 ETSI EN 319 142-1 定義了 PAdES 基準層級； Spec Spec: ETSI EN 319 142-2, §5.3 ETSI EN 319 142-2 §5.3 將 signature-time-stamp 屬性標示為一個可選元素，而其是否存在，正是區分帶時戳層級與 B-B 的關鍵；以及 Spec Spec: ETSI EN 319 142-2, §6.3.2.2 ETSI EN 319 142-2 §6.3.2.2 指出受信任的時戳應在簽章建立後立即施加，讓所記錄的時間盡可能接近真實的簽署時間。 Spec Spec: ETSI EN 319 142-2, §5.5 ETSI EN 319 142-2 §5.5 指出長期行為同時需要一個文件安全儲存區與文件時戳—— 也就是 B-LT 與 B-LTA 新增的內容。

容器層則由 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），正如 ETSI EN 319 142-1 所描述。B-LT 之所以重要，其緣由由 Spec Spec: RFC 6960, §4.4.4 RFC 6960 §4.4.4 所闡明：已封存的撤銷證據有助於證明該簽章在產生當天是可信的，即使該憑證早已過期。這正是將它內嵌的用意。

NextPDF 的引擎將每個層級編碼為一個需求述詞，並產生所請求的層級，否則就失敗——它絕不會宣稱一個它並未建立的層級。

Human-factors note: Human-factors note

本頁以決策規則開場——依義務的存續期間來挑選—— 並把它放在任何層級細節之前，因為這才是多數讀者真正需要的訊息。只讀過「精簡版說明」的讀者，理當已經能夠做出正確選擇。各層級的運作機制是給那些需要為其選擇辯護的讀者，而不是用來把關選擇本身。

實務範例

API 反映了這段遞進過程：你指名一個層級，引擎便把它視為一份契約。

<?php

declare(strict_types=1);

use NextPDF\Security\Signature\SignatureLevel;

// The level is an explicit, ordered choice — not a flag you hope is honoured.
$level = SignatureLevel::PAdES_B_T;

// The level itself tells you what it requires, before you sign:
$level->requiresTimestamp();          // B-T and above → true
$level->requiresDss();                // B-LT and above → true
$level->requiresDocumentTimestamp();  // B-LTA only     → true

// Ask for B-LTA only if the deployment can actually fulfil it.
// The engine produces exactly the requested level or fails with an
// actionable error — it never silently signs lower and reports higher.

如果你請求 B-LTA，而部署無法提供 B-LTA 所需的內容，預設會失敗，並告訴你它本來能達到的最高層級——而不是悄悄回傳一份標示為 B-LTA 的 B-T 檔案。

常見誤解

常見陷阱是「B-LTA 就是最好的那一個，永遠選它就對了。」B-LTA 並不是抽象意義上的更好；它是更多，而更多會帶來義務。它需要一個時戳機構、在簽署當時蒐集的撤銷材料，以及一套持續運作的封存流程，在文件的保護演算法或時戳憑證變弱之前，重新為文件施加時戳。一份沒有人為其重新施加時戳的 B-LTA 檔案並不能面向未來——它只是一份多了一套形式流程的 B-LT 檔案。反過來說，為一份必須存續十年的合約選用 B-B 並不「輕量」；它是一份在憑證到期當天就會驗證失敗的簽章。正確的層級就是該義務所要求的那一個，不高也不低。

限制與邊界

NextPDF 會產生所請求的 PAdES 層級；但它不提供該層級所仰賴的外部條件。時戳機構、憑證鏈、信任錨點，以及在簽署當時取得撤銷資料的連線能力，都屬於部署方的職責。引擎實作了相關結構並強制執行層級契約；它無法讓一個 TSA 變得值得信任，也無法讓一張憑證變得有效。所產生的結構承載了該層級所要求的各項元素，並已對照引擎本身的測試與所引用的條款加以驗證。這並非第三方的一致性認證，本頁也不主張 eIDAS 的法律效力；後者取決於憑證、簽署者以及管轄區。簽署時間是否獲得獨立信任，相關說明請見 時戳與受信任時間；至於長期證據如何讓一份簽章維持可用，相關說明請見 長期驗證。

以下邊界用來精確設定預期：

• B-LT 與 B-LTA 產生的是長期驗證的結構，而非一致性裁定。 引擎所寫入的是一個文件安全儲存區字典，外加一筆文件時戳修訂——一個 Type = DocTimeStamp 的簽章字典，依 Spec Spec: ISO 32000-2, §12.8 ISO 32000-2 §12.8 而定。此處並未將該結構標榜為已通過設定檔一致性測試；ETSI EN 319 142-1 設定檔檢查在 Pro 與 Enterprise 的 CI 通道上以發行版本作為門檻，因此本頁並未就所產生的檔案主張 ETSI EN 319 142-1 一致性。
• 加密文件對於 B-LT 與 B-LTA 採取失敗即關閉。 對一份加密文件請求長期層級時，會以可採取行動的錯誤停止，而不會寫入一筆不完整的長期修訂。

各層級在方案中的可用性——四者全都透過同一個高階接縫達成，即 setSignature($cert, SignatureLevel::PAdES_B_LTA, $tsaClient)->save()：

PAdES baseline level — edition availability

Edition	Availability
Core	○ PAdES B-B——簽署屬性基準；也就是 Core 接縫。
Pro	○ 新增 PAdES B-T——一個涵蓋簽章值的受信任時戳，由 TsaClient 驅動。
Enterprise	○ 新增 PAdES B-LT 與 B-LTA——內嵌的驗證材料（DSS），以及可更新的文件時戳封存迴圈。這些都透過同一個高階接縫運作，但僅在 Pro 與 Enterprise 套件兩者 皆已安裝時才可用；只要任一者缺少，該呼叫便會失敗即關閉，而不會寫入一筆不完整的長期修訂。

相關文件

• 簽章在 PDF 中的存放方式——每個層級所建立在其上的位元組範圍與字典基礎。
• 長期驗證——B-LT 與 B-LTA 實際內嵌了什麼，以及為何一份有效簽章若缺了它，日後可能會驗證失敗。
• 時戳與受信任時間——RFC 3161 所引入、且由 B-LTA 更新的 B-T 時戳。
• 簽署協議工作流程——讓你選定的 PAdES 基準層級實際發揮作用的具體工作流程。

詞彙表

• PAdES——PDF Advanced Electronic Signatures（PDF 進階電子簽章）；也就是用於在 PDF 中規範 CMS 簽章設定檔的 ETSI EN 319 142 系列標準。
• 基準層級——B-B、B-T、B-LT、B-LTA 之一；一組已定義且累積的必要簽章元素。
• B-B——附帶必要簽署屬性的基準簽章。
• B-T——B-B 再加上一個涵蓋簽章值的受信任時戳。
• B-LT——B-T 再加上內嵌的長期驗證材料（一個 DSS）。
• B-LTA——B-LT 再加上一個可更新的文件時戳，以維持封存有效性。
• DSS——Document Security Store（文件安全儲存區）；用於存放內嵌憑證與撤銷資料的 PDF 結構。
• TSA——Time-Stamp Authority（時戳機構）；一個發行 RFC 3161 時戳憑記的受信任服務。