当对 tuf 上的公证人对 docker 内容信任的初始信任初始化时，我了解了 TUF、公证人和内容信任的工作原理。
但我不清楚的是，最初的信任是如何建立的。
我怎么知道第一次拉取没有受到损害并且初始 root.json 是值得信赖的？
例如，如果我这样做docker pull启用内容信任后，我只会获得签名图像。但我如何验证该图像是否由正确的人签名？
这里是公证创建者和维护者。 Justin 已经给出了很好的说明，但我将更广泛地讨论 TUF 和 Notary 中的信任初始化。
除非您通过某种带外方法传达信任根，否则总会有一个您隐式信任的下载点来传递信任根。一些一般案例：当我们下载操作系统（即任何 Linux 发行版）或从公钥目录获取某人的 GPG 公钥时，我们会执行此操作。假设资源是通过 TLS 连接交付的，并且我们相信发布者已保护其服务器的安全，我们相信我们正在接收合法数据，并使用它来引导对所有未来交互的信任。这称为“首次使用信任”或“TOFU”。
这里的主张是人们do确保服务器安全，并且很难执行中间人 (MiTM) 攻击，尤其是针对 TLS 安全连接。因此我们can相信这个初始下载。
公证人有几种初始化信任的方法。首先是这个TOFU机制。 TUF 具有定义的更新流程，可确保初始下载后对所有后续内容的信任。 Notary 实现此更新流程并确保发布者在初始下载后保持一致。
如果您还想确保发布者是特定实体，Notary 提供了三种不同的方式来引导这种信任。他们是：
- 手动将带外获取的 root.json 放置在公证缓存中的正确位置。
- 配置信任固定以信任公证全局唯一名称 (GUN) 的特定根密钥 ID。
- 配置信任固定以信任特定公证 GUN 或 GUN 前缀的 CA。
有关信任固定的更多信息可以在我们的docs https://github.com/theupdateframework/notary/blob/master/docs/reference/client-config.md#trust_pinning-section-optional。请注意，所有 3 个选项都需要带外通信，您可以在带外通信中获取 root.json、根密钥的 ID 或用于颁发根密钥的 CA 证书。
实施信任固定docker trust命令在我们的 TODO 列表中，但它还不存在。但是您仍然可以使用选项 1docker trust。缓存位于~/.docker/trust/tuf/<GUN>/metadata/
关于选项 3 的其他上下文：Notary 实现了一项功能，允许为 GUN 或 GUN 前缀配置 CA。此实例中的要求是公共根密钥作为链接到配置的 CA 的 x509 证书包含在 root.json 中。虽然 CA 可能是一个有争议的话题，但没有人被迫使用此功能，并且在大多数攻击者模型中，它绝对比 TOFU 更好。此外，TUF 明确没有解决如何引导信任的问题。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
