Let's Seal: 一種免費、自託管文件簽署的開放標準

Let's Seal 是一個免費、開放原始碼的專案，旨在使文件真實性基礎設施成為公共財。透過引入 SEAL (Sealed Evidence Anchored to a Ledger) 標準，該專案旨在透過提供一個系統來消除對付費文件印章的需求，在該系統中，任何檔案都可以被加密證明為真實、未變更且具時間戳，而無需依賴專有供應商。

SEAL 標準：核心保證

SEAL 為任何封印的檔案提供三項主要的加密保證：

• 完整性 (未變更): 檔案會被逐位元驗證。如果在封印後有一個位元被變更，簽名將會失效。
• 時間證明 (時間): 檔案透過 OpenTimestamps 錨定到 Bitcoin 區塊鏈，確保文件在特定日期存在，而無需信任 Let's Seal 運營者。
• 身份 (發證者): 簽章與特定憑證綁定。對於組織，系統會驗證域名控制權（透過 DNS 記錄或控制器地址），將全球唯一的域名綁定為憑證的 dNSName 欄位中的可機器檢查身份。

為防止冒充並確保可審計性，每個簽章都會記錄在一個公開的、僅追加的透明度日誌中（基於 RFC 6962）。此日誌的根會被簽名並錨定到 Bitcoin，使任何人都能驗證該簽章已被包含且日誌未被重寫。

多格式支援與互操作性

Let's Seal 避免專有格式，而是將證明直接嵌入原生檔案類型。這確保封印的文件仍與標準讀取器相容：

File Type	Seal Implementation	Verification Method
PDF	PAdES / X.509 簽章	標準 PAdES 驗證器
媒體 (圖像/影片/音訊)	C2PA (內容憑證)	C2PA 讀取器
XML	W3C XML-DSig	XML-DSig 驗證器
電子郵件	S/MIME multipart/signed (RFC 8551)	openssl smime -verify
一般檔案	分離的 CAdES / CMS .sig	openssl cms -verify
軟體/容器	簽章 + in-toto / DSSE 證明	標準工件簽署工具

部署與開發者工具

Let's Seal 設計為靈活，提供三種使用服務的方式：

1. 託管 Web 應用: 一個基於瀏覽器的介面，位於 app.letsseal.org，用於封印檔案和發放憑證。
2. CLI 和 API: sealbot 命令列工具以及一個帶有 Python 和 TypeScript SDK 的 REST API，用於將封印整合到自動化管線中。
3. 自託管: 整個引擎，包括憑證授權機構 (CA) 和簽名服務，可以在私人 CA 下本地運行。

對於開發者，REST API 提供了針對不同封印類型的特定端點（例如，/api/v1/seal/c2pa 用於媒體或 /api/v1/seal/detached 用於一般檔案）。僅摘要的端點確保在分離簽名的封印過程中，實際的檔案位元不會離開使用者的機器。

社區觀點與技術批評

儘管該專案開放基礎設施的目標受到讚揚，但 Hacker News 社區提出了幾項技術與法律上的疑慮：

法律效力與信任錨點

幾位使用者主張，加密證明對於法律用途而言是不足夠的。

"無論多少加密驗證都無法替代擁有法律人員在另一端，該人員可對實際驗證文件是否正確簽署/流程是否被遵循負責。"

批評者指出，像 DocuSign 這樣的既有服務充當 "信任錨點"，因為它們是可以被傳票或起訴的法律實體，而一個去中心化的開放標準難以輕易複製這一角色。

區塊鏈整合

使用 Bitcoin 進行時間戳記成為爭議點。一些使用者質疑 Proof-of-Work 的環境影響，或建議使用 RFC 3161（可信時間戳記的標準）或其他如 Ethereum 的賬本會更適當。

採用與市場適配

一些貢獻者指出，該項目目前缺少與企業電子簽署平台競爭所需的功能，例如預填模板和複雜的簽署工作流程。其他人則認為，由於該行業本質上保守，該項目需要重大的戰略合作夥伴關係才能達到與 Let's Encrypt 相同的信任水平。

與 'Let's Encrypt' 的比較

一些使用者質疑與 Let's Encrypt 的類比，指出 Let's Encrypt 的價值在於其作為一個受所有主要瀏覽器信任的中央ised、聲譽良好的 CA。他們主張，如果 Let's Seal 主要是自託管的，它將失去使 Let's Encrypt 成功的中央ised 信任錨點。