Let's Seal
Seal anything.
The open standard for proving any file is real: unaltered, sealed by a known certificate, and in existence by a certain date.
网站 ·
SEAL 标准 ·
免费 Web 应用 ·
快速开始 ·
封存内容 ·
工作原理 ·
用例 ·
开发者 ·
自托管 ·
验证文档
**SEAL 是用于证明任何文件真实性的开放标准。** 一个已封存的工件，一种验证方式，任何人都可以永久验证。使用任何合规的工具进行封存，任何人都可以使用其他工具进行验证。
Let's Seal 创建了该标准——**SEAL**（Sealed Evidence Anchored to a Ledger，锚定到账本的封存证据），并运行负责颁发和验证该标准的免费网络及参考实现。该标准是核心基石。本仓库中的所有内容均构建于其上，并完全免费开放。
它是文档证明领域的 Let's Encrypt。Let's Encrypt 让付费的 TLS 证书成为了历史，Let's Seal 也将为付费的文档封存做同样的事。与 Let's Encrypt 一样，它是免费、开源的，并作为基金会的公益项目而非初创公司来运营。
**真实性是基础设施，不应被用来租售。**
## 免费使用
三种封存方式，均免费：
- **托管 Web 应用**，[app.letsseal.org](https://app.letsseal.org)。对任何人免费，在浏览器中运行，无需安装任何东西。封存文件、发送文档以供签名（远程、当面或完全不使用电子邮件），并颁发带有品牌的证书和凭证。
- **命令行和 API。** 用于终端的 `sealbot`，以及可让您将封存功能集成到自有系统中的 REST API 和 SDK。
- **自托管。** 在您自己的证书颁发机构下自行运行整个引擎。
在 [verify.letsseal.org](https://verify.letsseal.org) 或您自己的机器上离线验证，验证始终免费且无需账户。
- **永久免费。** 没有单文档费用，没有付费封存。
- **开源 (Apache-2.0)。** 引擎、SDK 和标准本身均开放。
## 封存的证明力
SEAL 证明通过加密技术确立了三点，并清晰地界定了其适用范围：
- **未更改。** 自封存以来，该文件连一个字节都没有改变。哪怕改变一个字节，签名也会失效。
- **时间。** 通过 [OpenTimestamps](https://opentimestamps.org) 锚定到比特币，证明其在特定日期已存在，无需信任我们。
- **颁发者。** 它由特定的证书进行封存。当组织证明了对某个域名的控制权时，该封存会将该域名作为可由机器验证的身份。
每个封存也会被写入到公开的、仅追加的透明日志（RFC 6962）中，该日志具有锚定到比特币的根节点，因此关于封存内容的记录本身也是防篡改的，任何人都可以对其进行审计。
这就是全部的保证，完整且永久。封存证明了完整性、时间和颁发证书。它不是公证，也不断言个人的现实世界身份。身份功能绑定了由提供商在封存时验证过的电子邮件，其最诚实的称呼是“提供商验证的电子邮件”，这也正是它所传递的内容。
## 封存的内容
一个标准，涵盖所有类型的文件，每种文件均采用其原生格式，因此任何标准验证器都可以对其进行检查。读者无需专门的工具，验证时也不依赖 Let's Seal。
| 文件 | 封存形式 | 验证方式 |
|---|---|---|
| **PDF** | 嵌入文件的 PAdES / X.509 签名 | 任何标准 PAdES 验证器，或此处的参考验证器 |
| **图像、视频、音频** | 嵌入媒体的 C2PA（内容来源信息）清单 | 任何 C2PA 读取器 |
| **XML** | 封闭式 W3C XML-DSig 签名 | 任何 XML-DSig 验证器 |
| **电子邮件** | S/MIME `multipart/signed` (RFC 8551) | `openssl smime -verify` |
| **任何其他文件** | 基于文件 SHA-256 的分离式 CAdES / CMS `.sig` | `openssl cms -verify`；文件的字节永远不会离开您的机器 |
| **软件工件、容器镜像** | 签名以及 in-toto / DSSE 证明（SBOM、SLSA 来源） | 您的流水线已在运行的标准开源工件签名工具 |
封存是针对每种格式原生的，因此封存后的 PDF 依然是可以在任何地方打开的普通 PDF，封存后的图像依然能在各处显示，签名后的工件也能像往常一样安装。证明随文件一同携带。
## 实际运行效果
从命令行进行封存和验证：
免费的公共验证门户 [verify.letsseal.org](https://verify.letsseal.org)：
公开证明页面：任何人都可以打开的通俗易懂的验证结论，以及其背后的证据。在您上传文件之前，主题和签名者的详细信息将保持私密：
位于 [app.letsseal.org](https://app.letsseal.org) 的托管应用可完成其余工作：封存文件、发送文档以供签名（远程、当面或完全不使用电子邮件），并颁发带有品牌的证书和凭证。
## 快速开始
在 **[verify.letsseal.org](https://verify.letsseal.org)** 上公开且免费地验证任何已封存的文档，或者自行运行参考验证器：
```
python spec/verify.py sealed.pdf sealed.pdf.ots
```
通过托管 API 使用组织密钥封存文件：
```
curl -X POST https://app.letsseal.org/api/v1/seal \
-H "Authorization: Bearer $LETSSEAL_KEY" \
-F file=@contract.pdf
```
或者从命令行进行：
```
sealbot seal contract.pdf # seal a PDF or any file
sealbot verify contract.sealed.pdf # verify a seal, offline
```
适用于 Python 和 TypeScript 的 SDK 以及 OpenAPI schema 位于 [`sdk/`](sdk/) 中。
## 证明的形式
打开已封存文件的证明页面，或运行验证器，您将获得一个有证据支持的、任何人都可以复现的直观结论：
```
Authentic and unaltered
Document contract.pdf
SHA-256 9f2c1a…e7b4 (matches the sealed bytes, exactly)
Issuer Acme Solicitors LLP
Issuer verified, controls acme.example (dNSName in the cert)
Sealed 2026-07-14 11:42 UTC
Time anchor Bitcoin block #812,043 (via OpenTimestamps)
Transparency Entry #48,120 in the public log, inclusion proof checks out
Verdict rule: Authentic = valid and intact and trusted.
A valid signature that does not chain to the published root is
reported as unrecognised, never as authentic.
```
该结论是刻意严格的。如果使用一个未链接到受信任根节点的证书进行加密签名，将被视为伪造途径，并会被报告为“未识别”，绝不会显示为通过。
## 封存的生成与检查方式
一个封存的生命周期：生成一次，提供证据并锚定到公共账本，提供服务返回，并且任何人都可以永久检查。
## 自行免费验证
两项检查，均独立于我们。一个封存包含了验证它所需的一切，因此只需固定一次已发布的根证书，之后就可以在任何地方永久离线验证。
- **根证书指纹 (SHA-256)：** `02:68:6D:EE:20:67:31:C4:59:C1:7A:9F:58:36:7B:0B:0B:BA:5D:24:C6:85:D8:6D:1F:74:49:86:2D:C0:FE:BE`，主题为 `CN=Let's Seal Root CA, O=Let's Seal, C=GB`。可在 [letsseal.org/api/root-ca](https://letsseal.org/api/root-ca) 下载。
- **PDF：** 任何固定了根节点的标准 PAdES 验证器，或使用 `python spec/verify.py sealed.pdf sealed.pdf.ots`。
- **电子邮件和分离式文件：** `openssl smime -verify -in message.eml -CAfile letsseal-root.crt` · `openssl cms -verify -inform DER -in file.sig -content file -binary -CAfile letsseal-root.crt`。
- **软件和 SBOM：** 标准开源工件签名工具会根据已发布的根证书验证签名和证明，可在任何机器上重现。
- **时间：** 针对比特币运行 `ots verify sealed.pdf.ots`。
- **透明日志：** 获取 `/api/log/proof?sha256=
` 处的包含证明，并将其与 `/api/log/sth`（RFC 6962）处的已签名树头进行核对。`/api/log/consistency` 处的一致性证明可以证明日志仅追加。
## 公共透明日志
每个封存都会写入一个仅追加的 Merkle 日志（RFC 6962），这与浏览器在证书透明度中依赖的结构相同。该日志的根节点已签名并且本身锚定到比特币，因此：
- 任何人都可以证明给定的封存已包含在日志中（包含证明），
- 任何人都可以证明日志从未被重写（一致性证明），
- 并且整个过程无需信任运营方即可进行审计。
它是防范冒用的审计追踪：如果某个证书曾以不应使用的名称对某项内容进行了封存，证据将是公开且永久的。
## 颁发者身份
封存始终会证明是哪个证书签署了它。在此之上，组织可以证明对域名的控制权（DNS 记录或发送到控制器地址的消息），然后该域名将作为 `dNSName` 绑定到签名证书本身中，因此平台外的验证器可以直接从证书中读取身份。
- 未验证域名的组织将被显示为“自我声明”，绝不会显示为“已验证”。
- 已验证颁发者的徽章是其控制的域名，该域名是全球唯一的，不会发生冲突。
- 滥用行为可以公开举报，冒充的颁发者可能会被暂停，这将冻结其密钥并撤销其已验证的徽章。
这是作为身份的域名控制权，与网络在 TLS 中采用的模型相同。它证明了谁控制着该封存，而不是个人的法律身份，并且对此予以坦率声明。
## SEAL 标准
**开放验证。开放实现。无法被垄断。**
SEAL 是一个任何人都可以在此基础上进行构建的已发布规范，请参阅 [SPEC.md](SPEC.md) 和 [letsseal.org/standard](https://letsseal.org/standard)。其目标是提供一种可互操作的方式来封存和验证任何文件，而不是一个要被绑定的产品。SEAL 证明是包含完整性、时间、透明度和可选的已验证电子邮件归属的单一自包含工件。
本仓库中的签名服务、SDK 和参考验证器是参考实现。任何其他方都可以自由编写自己的实现，并且由一种实现生成的证明可以在任何其他实现下进行验证。
## 用例
该标准适用于任何文件和任何领域。针对常见领域的实用指南，每个都包含分步说明和在线证明：
- **文档与法律：** [法律与法制](https://letsseal.org/use-cases/law) · [财产与产权转让](https://letsseal.org/use-cases/property-conveyancing) · [合规与审计](https://letsseal.org/use-cases/compliance) · [人力资源与企业](https://letsseal.org/use-cases/hr-corporate) · [政府与公共部门](https://letsseal.org/use-cases/government-public-sector)
- **金融与专业服务：** [银行与贷款](https://letsseal.org/use-cases/banking-lending) · [保险](https://letsseal.org/use-cases/insurance) · [会计与审计](https://letsseal.org/use-cases/accounting-audit) · [投资与资产管理](https://letsseal.org/use-cases/investment-asset-management) · [测量与房产报告](https://letsseal.org/use-cases/surveying-property-reports)
- **软件与供应链：** [软件供应链](https://letsseal.org/use-cases/software-supply-chain) · [采购与供应链](https://letsseal.org/use-cases/procurement-supply-chain) · [制造与贸易](https://letsseal.org/use-cases/manufacturing-trade)
- **受监管与专业领域：** [医疗保健](https://letsseal.org/use-cases/healthcare) · [制药与生命科学](https://letsseal.org/use-cases/pharma-life-sciences) · [建筑与工程](https://letsseal.org/use-cases/construction-engineering) · [知识产权](https://letsseal.org/use-cases/intellectual-property) · [教育与凭证](https://letsseal.org/use-cases/education-credentials)
- **媒体与个人：** [媒体、新闻与创意](https://letsseal.org/use-cases/media-journalism) · [个人与自由职业者](https://letsseal.org/use-cases/individuals-freelancers)
请在 [letsseal.org/use-cases](https://letsseal.org/use-cases) 查看全部内容。
## 架构
该引擎完全支持自托管，不包含任何仅在托管环境中运行的代码路径。单用户安装运行的代码与托管服务运行的代码完全相同。
## 自托管
在您自己的证书颁发机构下自行运行整个项目。
```
git clone https://github.com/letsseal/letsseal.git && cd letsseal
# 1. 证书颁发机构 (参见 ca/)
./ca/setup-ca.sh init
# 2. 签名服务 (持有 intermediate key；绑定到 localhost)
cd signing-service && python -m venv .venv && . .venv/bin/activate
pip install -r requirements.txt && uvicorn main:app --port 8081
# 3. Web app：dashboard、hosted API、verification portal、site
cd ../web && npm install && cp .env.example .env # fill in the values
npx prisma migrate deploy && npm run dev # http://localhost:3000
```
如果您希望您自己的门户之外的验证器也能显示自动的绿色勾选，您稍后可以零代码修改地替换为付费的 AATL 或 eIDAS `.p12` 证书。无论哪种方式，加密保证都是相同的。您的验证门户就是信任锚。
## 面向开发者
**REST API**（托管或自托管），使用组织 API 密钥进行身份验证：
```
POST /api/v1/seal seal a PDF (PAdES)
POST /api/v1/seal/c2pa seal an image, video, or audio file (C2PA)
POST /api/v1/seal/xml seal XML (XML-DSig)
POST /api/v1/seal/smime seal an email message (S/MIME)
POST /api/v1/seal/detached seal any file by digest (detached CAdES)
POST /api/v1/seal/blob seal a software artifact
POST /api/v1/seal/identity seal with a provider-verified email
POST /api/v1/attest attach an SBOM / SLSA attestation
POST /api/v1/anchor anchor a hash to Bitcoin
POST /api/v1/verify verify a seal (public, no key)
GET /api/v1/whoami check a key's organisation
```
仅摘要端点（`/seal/detached`、`/seal/blob`）绝不会接收文件的字节，仅接收其 SHA-256。
**CLI：** `sealbot seal`、`sealbot verify`、`sealbot issue`、`sealbot anchor`、`sealbot watch`。使用 `npm -g sealbot` 安装（或运行 `npx sealbot`）；一个独立的 Rust 构建版本位于 `cli-rs/` 中。
**SDK：** 为 Python（`sdk/python`）和 TypeScript（`sdk/ts`）手工编写的客户端，以及 OpenAPI schema（`sdk/openapi.json`）。使用 `sdk/generate.sh` 为任何其他语言生成客户端。
**CI：** 使用 `ci/` 中的 GitHub Action 在流水线中封存构建工件。
## 仓库布局
| 路径 | 说明 |
|---|---|
| `ca/` | 代码化证书颁发机构（根证书和中间证书颁发） |
| `signing-service/` | FastAPI 签名服务（持有中间证书密钥） |
| `web/` | Next.js 应用：仪表板、托管 API、验证门户、网站 |
| `spec/` | SEAL 规范和参考验证器 |
| `sdk/` | Python 和 TypeScript SDK、OpenAPI schema 以及 `generate.sh` |
| `cli/`、`cli-rs/` | `sealbot` 命令行工具（Node 和 Rust） |
| `ci/` | 用于在 CI 中封存工件的 GitHub Action |
## 使命
真实性是基础设施。它不应该被用来租售。证明文件的真实性是一项公共利益，就像浏览器地址栏中的挂锁图标一样，它应该是免费、开源的，由所有依赖它的人共同拥有。Let's Seal 作为基金会的公益项目而非初创公司运营，因此该标准永远不会被拉回到付费墙之后。
## 许可证
Apache-2.0，请参阅 [LICENSE](LICENSE) 和 [NOTICE](NOTICE)。SEAL 规范可免费实现。
由 [**nsokin**](https://github.com/nsokin) 创建和维护。Let's Seal 是 [Experimental Open Works](https://xowx.org) 的一个项目。