可信時間：時間戳記如何證明「何時」

SpecSpec: RFC 3161RFC 3161SpecSpec: RFC 5816RFC 5816SpecSpec: ISO 32000-2, §12.8.5ISO 32000-2 §12.8.5

快速概覽

時間戳記回答的是一個單純、卻意外地滑溜的問題：這份資料當時已經存在了嗎？ 不是誰製作了它，也不是它是否正確——只是在某個指名的瞬間，這些確切的位元組就已經存在於這個世界上。本頁從最底層把這個概念建立起來：時間戳記憑證機構做什麼、一個權杖實際包含什麼，以及為什麼時鐘上的一個數字會成為證據。

它是聚焦於引擎的時間戳記與可信時間的第一原理夥伴篇。如果「可信時間」聽起來像行話，請先讀這一篇。

為什麼這很重要

你電腦上的時鐘是一份自白，而不是證明。你可以把它設成任何你想要的值，別人也可以。一旦某個日期對第二方變得重要——一份必須在期限前簽署的合約、一筆必須在爭議發生前就存在的紀錄——你自己的時鐘作為證據便毫無價值，因為它由你掌控。可信時間的整個問題，就在於找到一個你無法撥動的時鐘。

這並非小眾的顧慮。每一份長壽命的已簽署 PDF 都倚賴它。一張簽署憑證終究會過期；多年之後，驗證者需要知道這個簽章是在憑證仍然有效時做出的。少了一份關於「何時」的獨立紀錄，這個問題便沒有誠實的答案。可信時間，是整座持久簽章大廈所倚靠的、那道無聲的地基。

精簡版說明

• 時間戳記證明一段資料早於某個指名的瞬間就已存在。那是對年齡的一個上界，僅此而已。
• 它由第三方——時間戳記憑證機構（TSA）——產生，你信任它的時鐘，正是因為它不是你的。
• TSA 永遠看不到你的資料。它簽署的是資料的一個雜湊值，繫結到一個時間值，並回傳一個小小的、已簽署的權杖。
• 這個權杖一併證明三件事：資料就是那份資料（雜湊值相符）、時間就是 TSA 的時間（它的簽章），以及回覆對應到你送出的請求（它回應的 nonce，防範被重放的較舊回應）。
• 它不證明是誰寫了資料、資料是否屬實，或建立的確切時刻。只證明：不晚於此。
• 信任流向 TSA。一個公開受信任的 TSA 對多數紀錄已經夠用；一個符合 eIDAS 資格的 TSA 在歐盟帶有法律推定。

NextPDF 的處理方式

先從這一切核心的那個巧妙手法說起。你想要一個陌生人為你的資料在何時存在作證，但你無法把資料拿給他們看——它可能是機密的，而且無論如何它都可能極為龐大。所以你不這麼做。你計算一個雜湊值：一個簡短、定長的指紋，原始資料即使只改動一個位元組，它也會完全改變，而且無法從中還原出原始資料。你送出的是那枚指紋，而不是檔案。

TSA 接過那枚指紋，附上它自己當下的時間，用它的私鑰簽署這一對，然後交回一個時間戳記權杖（SpecSpec: RFC 3161, §2.1RFC 3161 §2.1）。這個權杖就是那道繫結被永久固定下來：這枚指紋，在這個時間，由我作證。 因為權杖經過簽署，任何人——連 TSA 事後也不行——都無法在不破壞簽章的情況下更改時間。因為它帶著你的指紋，它對任何其他檔案都毫無用處。又因為請求中包含一個 TSA 原封回應的全新隨機 nonce，你便能判斷這份回覆對應到這個特定請求、而非某個較舊回應的重放——nonce 證明的是新鮮度，而非是誰提出請求（SpecSpec: RFC 3161, §2.4.2RFC 3161 §2.4.2）。

想像一封折好的信件上壓著一枚火漆印。印章不會讀信；它只證明信件在蓋章那一刻是完整且在場的。時間戳記就是一枚由你並不擁有的時鐘所蓋下的印，蓋在你資料的指紋上。

1. Fingerprint the dataCompute a one-way hash of the file or the signature value. The data itself never leaves your hands.
2. Ask the authoritySend the hash and a fresh random nonce to the Time-Stamp Authority.
3. The TSA seals a timeIt signs the hash bound to its own clock and echoes your nonce, producing a small signed token.
4. Store the tokenFor a PDF, the token is placed inside the file so the proof travels with the document.
5. Verify laterAnyone who trusts the TSA can check the token: its signature against the TSA certificate, the matching hash, the echoed nonce, and the time — then concludes an upper bound on age.

一個受信任時間戳記如何取得、又證明了什麼：一個雜湊值加上一個全新的 nonce 送給 TSA，TSA 簽署那個繫結到自身時間的雜湊值並回應 nonce，驗證者在把該權杖當成「資料早於所載明時間就已存在」的證明之前，會先檢查每一道連結。

在 PDF 中，同樣這套機制身兼兩種角色。一個簽章時間戳記封存簽章是在何時施加的，做法是為簽章的值加上時間戳記。一個文件時間戳記封存整份檔案在何時存在，做法是把整份 PDF（排除權杖將佔用的占位欄位）雜湊化，並把回傳的權杖存回那個占位欄位（SpecSpec: ISO 32000-2, §12.8.5ISO 32000-2 §12.8.5）。第二種，正是一個長壽命的封存簽章在歲月中反覆更新、以維持其信任新鮮的那一種。

有一個值得知道的現代細節：較舊的時間戳記格式，曾把自己釘死在單一雜湊演算法上，用以為 TSA 自己的憑證命名。更新後的設定檔讓一個權杖改用一個目前的摘要來為其憑證命名（SpecSpec: RFC 5816, §2.1RFC 5816 §2.1），於是可信時間不會悄悄繼承昨日的密碼學。

實務範例

你不會親手組裝一個權杖，你也不該想這麼做。值得理解的，是那道信任邊界：你選擇相信的是哪一個時鐘。在 NextPDF 中，請求一個需要可信時間的簽章層級，會讓這個選擇變得明確，而非隱含。

<?php

declare(strict_types=1);

use NextPDF\Security\Signature\SignatureLevel;

// A baseline signature trusts only the signer's own clock.
$baseline = SignatureLevel::PAdES_B_B;
$baseline->requiresTimestamp(); // false → no third party vouches for "when"

// Stepping up to B-T means a Time-Stamp Authority must be supplied:
// from here on, "when" is attested by a clock you do not control.
$timestamped = SignatureLevel::PAdES_B_T;
$timestamped->requiresTimestamp(); // true → a TSA is now part of your trust model

// The decision is now visible at the call site, not buried in a default.
// Choosing the TSA is choosing whose time becomes your evidence.

這個範例的重點不在 API。重點是「我有可信時間嗎？」這件事，是關於你文件的一個是非分明的事實，由是否有一個 TSA 參與其中所決定——而引擎拒絕讓這個事實變得模稜兩可。

常見誤解

陷阱在於把時間戳記讀成*「這是在 14:32 建立的」。它沒這麼說。它說的是「這在不晚於 14:32 時就已存在」*。這個差別正是全部的重點。時間戳記是一個上界，從來不是下界，也從來不是一個確切時刻。你的資料可能在你終於著手加上時間戳記之前，就已經存在了好幾年；權杖對此保持沉默。它只畫出一條線並宣告：不晚於此處。

第二個、代價更高的誤解：以為時間戳記證明你的文件為真或正確。它兩者都不證明。它對意義漠不關心。一個被完美加上時間戳記的謊言依然是謊言——只不過如今可被證明很老。真確性來自那道說明是誰的簽章；真相來自這個世界。時間戳記只談何時。

Human-factors note:Human-factors note

可信時間是一項披著技術外衣的信任決定。在你接受一個時間戳記的那一刻，你已經決定相信一個陌生人的時鐘。那不是瑕疵——它正是整套機制。誠實的問題從來不是「這個時間戳記有效嗎」，而是「就我使用它的目的而言，我信任簽發它的那個憑證機構嗎」。一個公開受信任的 TSA，對多數營運紀錄已綽綽有餘。一個合格的 TSA 則帶有法律分量。把那個選擇明白說出口，而不是繼承恰好離得最近的那個時鐘，正是證據與裝飾之間的差別。

限制與邊界

一個時間戳記的觸及範圍，恰恰止於它的信任模型所止之處。它證明對年齡的一個上界，僅此而已，且僅當你信任那個封存它的憑證機構時才成立。

有兩個層級的憑證機構值得區分。一個公開受信任的 TSA鏈結到一張你的軟體已經接受的憑證；它的權杖可被廣泛驗證，對多數紀錄都很合適。一個符合 eIDAS 資格的 TSA是 EU 信任清單上一個受監管的提供者，而一個合格的電子時間戳記，對其日期的準確性與資料的完整性帶有一項法律推定——這是普通時間戳記所不具備的推定（SpecSpec: eIDAS, Art. 41eIDAS Art. 41）。在兩者之間做選擇，是一個關於你所需證據分量的問題，而非關於這些位元組如何運作的問題；密碼學是一樣的。

時間戳記也繼承了它自己信任錨點的存續期間。TSA 的憑證可能過期或被撤銷，而它所用的雜湊演算法也可能老化淘汰。這正是為什麼長壽命的文件不會只蓋一次時間戳記就一走了之——它們會更新，在舊證據變弱之前，在舊證據之上層疊一個全新的文件時間戳記。那道更新迴圈自成一個主題；參見長期驗證。

RFC 3161 trusted timestamping (signature and document timestamps) — edition availability

Edition	Availability
Core	○ 支援 PAdES B-B 與 B-T。B-B 是沒有時間戳記的基準簽章；B-T 針對一個由部署所提供、其時鐘由你選擇的 TSA，請求並內嵌一個經驗證的 RFC 3161 簽章時間戳記。
Pro	○ 新增 B-LT 所需的內嵌長期驗證資料（憑證、OCSP、CRL），用以在簽章的憑證過期後仍維持其可驗證性。
Enterprise	○ 新增 B-LTA 更新迴圈，把驗證資料封存於一個全新的文件時間戳記之下，並在保護變弱之前重新蓋上時間戳記。

相關文件

• 時間戳記與可信時間——同一套機制在引擎與 PAdES 層級的樣貌，並把驗證規則逐項說清楚。
• 長期驗證——更新文件時間戳記如何讓一個簽章維持多年可驗證。
• 簽章如何證明是誰簽署——本頁擱在一旁的那「是誰」的另一半故事。
• 合格簽章解說——「合格」是什麼意思，以及為什麼一個合格的 TSA 帶有法律分量。

詞彙表

• 時間戳記憑證機構（TSA）——一個簽發已簽署時間戳記權杖的獨立服務。你信任它的時鐘，正是因為它不是你的。
• 時間戳記權杖——TSA 回傳的那個小小的已簽署物件，把你資料的一個雜湊值繫結到一個時間值（SpecSpec: RFC 3161, §2.1RFC 3161 §2.1）。
• 雜湊值（訊息印記）——資料的一枚簡短的單向指紋。TSA 簽署的是它，從不是資料本身，因此你的內容維持私密。
• Nonce——隨請求一同送出、並在回覆中被原封回應的一個全新隨機值，表明該權杖對應到那個特定請求、而非某個被重放的舊回應（它證明的是新鮮度，而非請求者的身分）。
• 上界——時間戳記所確立的事：資料在所載明瞬間之前不晚於該時刻就已存在。從來不是一個確切的建立時刻。
• 符合 eIDAS 資格的時間戳記——來自一個受監管 EU 提供者的時間戳記，對日期準確性與資料完整性帶有一項法律推定。
• 文件時間戳記——涵蓋整份 PDF 檔案的一個時間戳記，用以錨定並更新長期驗證證據（SpecSpec: ISO 32000-2, §12.8.5ISO 32000-2 §12.8.5）。