一份签名回执能够证明什么，而又不能证明什么

密码学证据总是很容易引得人们夸大其词。“已签名”听起来像是“真实的”，“可发现篡改”听起来又像是“已认证的”。然而这两种理解都是不对的。如果您要在一次审计、一份合同或者一场争议中使用 Trustvice 回执，那么您所能做的最有价值的一件事，就是准确无误地描述它们：既不超出它们实际所能证明的范围，也不低于这个范围。

本文就是这样一份尽可能准确的描述。这是我们希望一位审慎的律师、审计师或者交易对手，在决定依赖一份回执之前能够认真读到的页面，其中也有意重复了我们的文档中早已说明过的一些内容。

一份有效的回执能够证明什么#

一份能够通过某一把已经公开发布的 Trustvice 密钥验证的回执，可以确切地证明以下三件事情。

来源。 这个信封是由与 signatureKeyId 相匹配的那一把私钥的持有者进行签名的，而这把私钥是一把 Trustvice 签名密钥。除此之外的任何人，包括您自己在内，都不可能制作出一份能够通过这把密钥验证的回执。

完整性。 除了 signature 之外，信封中的每一个成员都与签名时完全一致：类型、回执正文、issuedAt 时间以及密钥 ID。哪怕只修改了其中的一个字符，验证也都会立即失败。

一个经过签名的时间。 Trustvice 声明这份回执是在 issuedAt 这一时间创建的。这个时间来自签发方自己的时钟，而不是来自任何外部来源。

任何人都可以离线检查这三项内容，既不需要注册账户，也不需要事先询问我们。而且这项检查是完全确定性的：给定同一份回执和同一把密钥，两个相互独立的实现会得出完全相同的答案。这正是一份回执真正的力量所在，而且这种力量是实实在在、真实存在的。

报告的事实与观察到的事实#

在逐一列出各项局限之前，有一个重要的区别，决定了任何一份具体的回执究竟具有多大的分量。

一份回执所陈述的，可以是某一方提供给 Trustvice 的事实（经签名以表明这些事实曾被出示），也可以是关于 Trustvice 自己执行过或看到过的事情的事实。关于报告事实的回执，证明这些事实在 issuedAt 之前已被出示；关于观察事实的回执，证明 Trustvice 所看到的内容。两种情况下回执看起来完全一样，因此请查看回执类型，以了解您手中的是哪一种。

一份回执不能证明什么#

以下这些并不是产品的缺陷。它们是这项声明本身所固有的边界。

一项报告的事实是真实的#

一份针对哈希的回执所涵盖的是一个哈希值。一份虚假文档的哈希，与一份真实文档的哈希，在验证时的表现完全一样。一份针对所报告的交互（例如一个提示词和一个响应）的回执，证明的是这次交互在某一时间被出示过，而不是它确实按照所描述的方式发生过。

不过，一份报告事实类的回执所能给您的东西，依然非常值得拥有：它把这项声明牢牢地固定在了某一个时间点上，因此无法被人悄悄地倒填日期，而之后对它所做的任何修改，也都必然能够被发现。

是谁撰写、批准或者拥有了任何东西#

信封之中并不包含任何工作区或者账户的标识符，也不包含任何个人的签名。任何一个持有这份 JSON 的人，都可以随时出示它。一个哈希所标识的是字节，而不是所有者：它并不能表明其他人没有持有完全相同的内容。如果作者身份很重要，请把您自己的签名放进内容之中。

您的内容本身#

回执中保存的是一个哈希值。要证明某一份文档与之相符，请对这份文档计算哈希，并将结果与回执正文进行比较。只有当您把内容保存在了某个能够随时拿出来的地方时，这份回执才能真正地派上用场；否则它几乎无法帮到您。

某个事件发生的真实时间#

issuedAt 是我们在签名时的时钟时间。对于一项报告的事实，事件本身发生在回执生成之前的某一个时间。在任何法律制度下，一份回执都不是一个合格的时间戳。因此，请不要声称任何比事件与回执之间的时间间隔更为精细的精度。如果您确实需要一个外部的时间锚点，请把这份回执的签名发布到某个拥有自己可信时钟的地方。

没有回执的地方就什么都没有发生#

一份回执证明的是它所说的内容，而不是它没有说出的内容。回执中的空缺并不能证明什么都没有发生，无论这对您有利还是不利。

一份回执已被撤销，或者某把密钥从未泄露#

目前并不存在任何撤销机制。一份在签发时能够通过验证的回执，只要它的签名密钥还保持着发布状态，就会一直能够通过验证。同样，目前也不存在任何密钥撤销列表。一把泄露的签名密钥，会让它的持有者能够制作出可以通过验证的回执，而仅仅凭借签名检查本身，是完全无法把它们与真正的回执区分开来的。

您仍然需要在哪些方面信任我们#

验证让您在很多方面都不再需要去信任我们：您不需要由我们来告诉您一份回执是否被篡改过、是哪把密钥签的名，或者其中的密钥是否被调换过。剩下需要信任的，只是一小组被明确列出的事项：

• 您用来验证的那把公钥确实属于我们。 请从一个您所信任的网络之中固定下密钥 ID 和 x 值，然后始终使用这份副本来进行验证。
• 我们的签名密钥只被回执服务所使用。 Trustvice 将这些密钥保存在 AWS KMS 的硬件安全模块之中，它们从不会离开那里，这可以防止它们被复制。但这并不能阻止那些能够部署回执服务、或者持有其仅限签名凭据的人，让它去进行签名。
• 当我们说观察到了某件事时，我们确实观察到了。 这一点适用于那些关于 Trustvice 执行过或看到过的事情的回执。
• 我们自己的时钟。

若要在争议中处于最有利的位置，请将回执与您自己掌控的记录结合起来使用。

如何出示一份回执#

当一份回执离开您的手中、交给他人时，附上一段简短的说明，就可以避免绝大多数的误解。一段好的说明，通常会做到以下这五件事：

1. 用回执本身的措辞，说明这份回执显示了什么。 “10 月 14 日 UTC 时间 09:41:07，我们密钥的一位持有者以标签 proof v3 delivered 向 Trustvice 出示了 SHA-256 4d9a…7d62。”
2. 说明这是谁的事实。 是由我们报告的，还是由 Trustvice 观察到的。
3. 把证据一起提供。 回执本身、它通过验证时所用的密钥集合，以及原始内容。
4. 邀请对方进行独立验证。 指向 /verify 以及离线验证流程，并请对方自己从 trustvice.com 获取密钥，这样他们就不必依赖您所提供的密钥文件。
5. 说明各项局限。 尤其是时间、观测点以及其中存在的任何空缺。

我们的指南用于争议的证据详细展示了完整的做法：在争议发生之前就确定您将需要哪些声明，在事情发生的那一刻就获取回执，并整理出一份对方无需信任您、即可自行验证的证据包。

回执与法律#

一份回执在某个特定的法庭、监管或合同场景中是否可以被采纳，或者是否足够充分，取决于所在的司法管辖区以及具体的案件。一份回执是一条技术记录，记录了向某个签名服务出示了什么，或者某个签名服务观察到了什么。它不是法律建议，不是一项认证，也不是任何形式的合规性证明。请咨询您自己的法律顾问的意见，并且可以考虑在您的合同中写明：双方都接受经已公开发布的密钥验证过的回执，作为其所陈述事实的证据。

我们为什么要把这些写下来#

一项被坦率说明的局限，往往比一项宣传声明更能建立起真正的信任，因为一份回执的用处，取决于人们描述它时的精确程度。如果您发现我们自己的页面有夸大回执证明内容的地方，请通过 /contact 告诉我们，我们会加以修正。