当对初始化了对tuf公证人的docker内容信任的初始信任时，我理解TUF，Notary和Content Trust是如何工作的。
但我不清楚的是，初始信任是如何设置的。
我怎么知道，第一次拉动不是受损的，初始的root.json值得信赖？
因此，例如，如果我启用了内容信任docker pull，我将只获得签名图像。但是，如何验证此图像是否由合适的人签名？
答案 0 :(得分：2)
这里是公证人和维护者。 Justin已经提供了一个很好的账户，但我会更广泛地相信TUF和Notary的初始化。
除非您通过某种带外方法传达信任根，否则您始终会隐藏信任的下载点以提供信任根。一些一般情况示例：我们在下载操作系统（即任何Linux发行版）或从公钥目录中获取某人的GPG公钥时执行此操作。假设资源是通过TLS连接传递的，并且我们认为发布者已经保护了他们的服务器，我们相信我们正在接收合法数据，并使用它来引导对未来所有交互的信任。这称为首次使用信任或TOFU。
这里的主张是人们做保证他们的服务器安全，并且很难执行中间人（MiTM）攻击，尤其是针对TLS安全连接。因此，我们可以信任此初始下载。
公证人有几种方法可以初始化信任。首先是这种TOFU机制。 TUF具有定义的更新流程，可确保在初始下载后对所有后续内容的信任。公证人实施此更新流程，并确保初始下载后发布者保持一致。
如果您想要另外确保发布者是特定实体，Notary提供了三种不同的方式来引导该信任。他们是：
有关信任固定的更多信息，请参阅我们的docs。请注意，所有3个选项都需要带外通信，您可以在其中获取root.json，根密钥的ID或用于颁发根密钥的CA证书。
在docker trust命令下实现信任固定在我们的TODO列表中，它还没有。但是，您仍然可以将选项1与docker trust一起使用。缓存位于~/.docker/trust/tuf/<GUN>/metadata/
选项3的附加上下文：公证人实现了一项功能，允许用户为GUN或GUN前缀配置CA.此实例中的要求是公共根密钥作为x509证书包含在root.json中，该证书链接到已配置的CA.虽然CA可能是一个有争议的话题，但没有人被迫使用此功能，而且在大多数攻击者模型中，它都严格优于TOFU。此外，TUF明确没有解决如何引导信任。
答案 1 :(得分：1)
您可以通过某些带外方式固定密钥，或者执行类似ssh的操作，这些操作会向您显示首次使用时检查的密钥。这些方法不是预定义的，但您可以根据自己使用公证的方式自行构建它们。对于LinuxKit，我们计划选择将密钥哈希放在您用于构建的配置文件中，该文件列出了要提取的图像。或者您可以在其他位置发布根密钥ID。