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 通过将证明直接嵌入原生文件类型来避免使用专有格式。这确保了密封的文档与标准阅读器保持兼容：

文件类型	印章实现	验证方法
PDF	PAdES / X.509 signature	标准 PAdES 验证器
媒体 (图像/视频/音频)	C2PA (Content Credentials)	C2PA 阅读器
XML	W3C XML-DSig	XML-DSig 验证器
电子邮件	S/MIME multipart/signed (RFC 8551)	openssl smime -verify
通用文件	Detached CAdES / CMS .sig	openssl cms -verify
软件/容器	Signature + in-toto / DSSE attestation	标准制品签名工具

部署与开发者工具

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）。对于分离式签名，仅摘要 (Digest-only) 端点确保在密封过程中，实际的文件字节永远不会离开用户的机器。

社区观点与技术评议

虽然该项目的开放基础设施目标受到了赞赏，但 Hacker News 社区提出了若干技术和法律方面的疑虑：

法律效力与信任锚点

一些用户认为，密码学证明在法律用途上是不充分的。

“再多的密码学验证也无法替代在另一端拥有一个可以被追究责任的法律主体，以确保其确实准确地验证了文档已被签署/遵循了流程。”

批评者指出，像 DocuSign 这样成熟的服务充当了“信任锚点”，因为它们是可以通过传票或起诉的法律实体，而这种角色是去中心化开放标准难以轻易复制的。

区块链集成

使用 Bitcoin 进行时间戳处理是一个争议点。一些用户质疑工作量证明 (Proof-of-Work) 的环境影响，或者建议 RFC 3161（可信时间戳标准）或其他账本（如 Ethereum）会更合适。

采用与市场契合度

一些贡献者指出，该项目目前缺乏与企业级电子签名平台竞争所需的功能，例如预填模板和复杂的签名工作流。其他人认为，由于行业本质上是保守的，该项目需要重大的战略合作伙伴关系才能达到与 Let's Encrypt 相同的信任水平。

与 “Let's Encrypt” 的比较

一些用户对与 Let's Encrypt 的类比提出了质疑，指出 Let's Encrypt 的价值在于其作为被所有主流浏览器信任的集中式、信誉良好的 CA 的角色。他们认为，如果 Let's Seal 主要采用自托管模式，它就会失去使 Let's Encrypt 取得成功的集中式信任锚点。