時間戳記與可信時間

Spec Spec: RFC 3161 RFC 3161 Spec Spec: RFC 5816 RFC 5816 Spec Spec: ISO 32000-2, §12.8.5 ISO 32000-2 §12.8.5 Evidence § Standard-backed Evidence: Standard-backed

快速概覽

時間戳記並不是在記錄「這是在何時簽署的」。它證明的是更狹義、也更有力的一件事：某一份特定資料在某個特定時刻之前就已存在，且這件事由簽署者以外的第三方佐證。這個區別正是可信時間的全部價值所在，卻也經常被誤解。

為什麼這很重要

簽章內部的簽署時間，只是簽署者電腦所宣稱的任意值。時鐘可能因意外出錯，也可能被刻意調整。如果何時的唯一證據只是簽署者自己的主張，那麼簽署者就能任意把文件標成更早或更晚的日期。一張昨天才被撤銷的憑證，可以被偽裝成彷彿去年就已完成簽署。「何時」不是細枝末節；它決定了使用現已過期或現已撤銷憑證所做的簽章是否仍然有效。一旦可信時間有誤，建立在其上的每一項長期有效性論證都會隨之崩潰。

精簡版說明

• 簽署者自己的簽署時間是一項主張，而非證明。它很容易偽造。
• RFC 3161 時間戳記是來自時間戳記憑證機構（TSA）的已簽署權杖，將你資料的雜湊值繫結到 TSA 的時間。
• 它所證明的內容非常精確：該資料在 TSA 所載明的時間之前就已存在。這不是確切的建立時刻，而是一個上界。
• 該權杖會回應你的 nonce（隨機數）與你的訊息印記，所以它不可能是重放，也不可能對應到不同的資料。
• 文件時間戳記將同樣的機制套用到整份 PDF，把其下的所有內容——簽章及其內嵌的驗證證據——錨定到一個可信的時刻。

NextPDF 的處理方式

NextPDF 把時間戳記視為必須驗證的證據，而不只是要取得的資料。請求一個權杖，只完成工作中較小的一半。引擎採取的原則是：未經驗證的權杖不構成證據。

當引擎為一個簽章加上時間戳記時，它會把一份資料的雜湊值與一個全新的隨機 nonce 送給 TSA，絕不會送出資料本身。接著，回傳的權杖會被逐項核對其完整屬性，確認它足以作為證據：回應狀態為「granted」、權杖中的 nonce 與送出的相符、權杖中的訊息印記與送出的雜湊值相符、權杖本身的密碼學簽章通過驗證、權杖的內容類型確實是時間戳記類型，且所載明的時間落在可接受的容差範圍內。任何不符都會造成硬性失敗，並附帶分類原因。沒有「看起來夠接近」的通融路徑。文件時間戳記遵循同樣的規則，只是套用於整份檔案，而非單一簽章的值。

1. Hash the data Only a digest of the signature value (or the whole PDF, for a document timestamp) is computed — never the data itself.
2. Send hash + nonce The digest and a fresh random nonce go to the Time-Stamp Authority.
3. TSA returns a token A signed token binds the digest to the TSA’s genTime and echoes the nonce.
4. Verify the token Status granted, nonce matches, message imprint matches, token signature verifies, time within tolerance.
5. Conclude an upper bound The data provably existed before the TSA’s stated time — attested by a party that is not the signer.

可信時間戳記如何取得、又證明了什麼：將雜湊值加上一個 nonce 送給 TSA，TSA 回傳一個將該雜湊值繫結到其時間的已簽署權杖，驗證者在把它當成「資料在該時間之前已存在」的證明之前，會先確認此繫結。

證據怎麼說

Evidence § Standard-backed Evidence: Standard-backed 這個定義很精確。 Spec Spec: ISO/IEC 18014-2, §3 ISO/IEC 18014-2 §3 將時間戳記服務定義為一種提供*「某資料項在某個時間點之前就已存在」之證據*的服務——這是一個上界，而非建立時刻。 Spec Spec: ISO/IEC 18014-2, §7 ISO/IEC 18014-2 §7 定義了權杖的 TSTInfo 內容：一個訊息印記（你資料的雜湊值）、一個產生時間、 一個序號，以及一個選用的 nonce。 Spec Spec: ISO/IEC 18014-2, §6 ISO/IEC 18014-2 §6 載明驗證者在驗證成功時可以得出的結論：該資料項在權杖中的時間之前就已存在——不多也不少。

就 PDF 而言， Spec Spec: ISO 32000-2, §12.8.5 ISO 32000-2 §12.8.5 規定了文件時間戳記：位元組範圍涵蓋整份檔案，但排除 Contents 值；該雜湊值會送往時間戳記憑證機構，回傳的 RFC 3161 權杖——按 Spec Spec: RFC 5816 RFC 5816 所更新——會被放入 Contents。這與簽章採用同樣的位元組範圍規則，只是用於時間而非身分。而 Spec Spec: RFC 6960, §4.4.4 RFC 6960 §4.4.4 正說明了為什麼這對長期可驗證性如此重要：可信時間正是驗證器得以證明簽署時可靠性的依據——即使在憑證過期之後亦然。

NextPDF 的引擎會送出雜湊值與一個 nonce，絕不送出資料；在把回傳的權杖視為證據之前，它會逐項核對狀態、nonce、訊息印記、權杖簽章、內容類型與時間容差。

Human-factors note: Human-factors note

本頁一開始就給出精確主張——時間戳記證明資料由第三方佐證，且在某時間之前已存在——因為此處最常見、 代價也最高的錯誤，就是把它過度誇大成「確切簽署時刻的證明」。先陳述真實而較狹義的主張，是為了防止誤用，並把這項提醒放在機制說明之前。

實務範例

你不會親手組裝一個時間戳記權杖。真正重要的是信任邊界。TSA 是你需要設定並保護的對象，因為它的時間會成為你的證據。

<?php

declare(strict_types=1);

use NextPDF\Security\Signature\SignatureLevel;

// Asking for any level at or above B-T requires a TSA.
$level = SignatureLevel::PAdES_B_T;
$level->requiresTimestamp(); // true → a Time-Stamp Authority must be supplied

// The TSA endpoint, its transport security, and its trust anchor are
// deployment-supplied. The engine sends a hash plus a fresh nonce — never the
// document — and verifies the returned token before the signature is accepted.
// A token that fails any check (status, nonce, imprint, signature, time)
// is a hard error, not a warning.

值得留意的邊界在於：引擎送出的是雜湊值，而非文件，因此 TSA 永遠看不到你的內容。而且引擎會驗證回應。一個你無法驗證身分的 TSA，並不是可信時間；它只不過是另一個時鐘。

常見誤解

陷阱在於把時間戳記解讀成「這份文件正是在這一天的 14:32 簽署的」。它不是用來為簽署事件計時的碼錶。它證明的是資料不晚於 TSA 的時間就已存在，而這是由第三方設定的上界。建立時間可能是那之前的任何時刻。第二個陷阱是假設任何時間戳記伺服器都能給你可信時間。一個你無法驗證其簽章、或其憑證機構不受你信任的權杖，什麼都證明不了。它只是一個你沒有理由相信的時鐘。可信時間來自一個你能驗證身分的 TSA，以及一個你已驗證過的權杖，而不是來自向伺服器索取一個數字這個動作本身。

限制與邊界

NextPDF 會建構請求、只送出雜湊值，並驗證回傳的權杖。它並不為其背後的憑證機構背書。TSA 的準確度、它本身憑證的有效性，以及它的可信度，都是該服務與你部署設定的屬性，而非引擎的屬性。時間戳記將一個雜湊值繫結到一個時間。它不會判斷資料的意義、簽署者的身分，或簽署者的憑證是否有效。那些屬於另外的檢查，涵蓋於 正確驗證簽章。引擎無法把一個不可信的 TSA 變得可信。本頁也未主張時間戳記具有任何特定的法律效力；那取決於 TSA 的狀態與司法管轄區。可信時間如何被反覆運用，以在數十年間保持簽章可驗證，這在 長期驗證 中有說明。

時間戳記功能在各版本層級的供應情形：

RFC 3161 timestamping (signature timestamp and document timestamp) — edition availability

Edition	Availability
Core	○ Not in this edition
Pro	○ PAdES B-T — 針對簽章值、以部署所提供的 TSA 驗證過的 RFC 3161 時間戳記。
Enterprise	○ 新增 B-LT 與 B-LTA 所使用的文件時間戳記，用以錨定內嵌的驗證證據，並驅動歸檔更新迴圈。

相關文件

• 長期驗證 — 文件時間戳記如何封存內嵌證據，並隨時間持續更新。
• PAdES 基準設定檔 — 簽章時間戳記（B-T）與文件時間戳記（B-LTA）在等級遞進中各居何處。
• 合格簽章解說 — 合格時間戳記在 eIDAS 信任全貌中的定位。

詞彙表

• 時間戳記（RFC 3161） — 來自 TSA 的已簽署權杖，將一份資料的雜湊值繫結到 TSA 的時間，證明該資料在該時間之前就已存在。
• 時間戳記憑證機構（TSA） — 簽發時間戳記權杖的可信服務。
• TSTInfo — 權杖的內容結構：訊息印記、產生時間、序號，以及選用的 nonce。
• 訊息印記 — 被加上時間戳記之資料的雜湊值，會由權杖回應。
• Nonce — 隨請求一同送出、並由權杖回應的全新隨機值，使回應不可能是重放。
• 文件時間戳記 — 涵蓋整份 PDF 的 RFC 3161 時間戳記（按 RFC 5816 所更新），把簽章及其證據錨定到一個可信的時刻。