为什么RFC 4158 (路径建设)将信任锚限制在自签名证书上？

Question

我在使用Wget从ftp.gnu.org上使用X3根目录加密一个文件时遇到了问题。让我们加密X3是交叉认证，这意味着它有一个发行人和它的非自签名。当使用“让我们加密”X3时，Wget失败了，它找不到颁发者证书，即使我试图在“让我们加密证书”中建立信任。

我访问了RFC 4158，因特网X.509公钥基础设施:认证路径构建，看看行为应该是什么。本文档详细讨论了从终端实体证书或订阅服务器证书到CA根和信任锚点的构建路径。这是人们所期望的。

然而，第1.3款提供了术语，它定义了信任锚：

• 信任列表:信任锚列表。
• 信任锚:可信公钥和相应私钥所属实体的名称的组合。
• 信任锚证书:用于证书路径处理的信任锚的自签名证书。
• “信任锚证书”和要求“自签名”的定义意味着我们不能在从属证书中建立信任，就像让我们加密交叉认证的X3根一样。

我的问题是，RFC为什么要这么做？为什么我们被迫使用一个自签名证书作为锚，并且包含PKI中不需要的部分，这些部分只会使路径构建复杂化并增加攻击面？

Answer 1

这是一个棘手的微妙的措辞。RFC的全部含义在一读时可能并不明显。根据你的问题(强调我的问题)：

信任锚:可信公钥和相应私钥所属实体的名称的组合。信任锚证书:用于证书路径处理的信任锚的自签名证书。

信托商店有两个目的：

1. 确定由此公钥生成的所有签名都应该是可信的，并且
2. 将公钥绑定到名称(通常在RFC2253中定义LDAP区分名称(DN) )

其中的一些推论是：

• 由该密钥执行的所有签名都将被信任，包括证书颁发。
• 因为您正在显式地将其标记为可信的，所以不能通过常规方法撤销此密钥--唯一的方法是手动从信任存储中删除它。

这里的微妙之处在于，RFC允许您直接将证书或公钥引脚，但是如果您将证书引脚，则它需要是根证书。RFC在此给出了一些理由：

1.5.1.分层结构图1中描述的分层PKI是指所有终端实体和依赖方都使用单一的“根CA”作为其信任锚。

从CA的角度来看，他们可能不希望您将中间CA固定在一起，因为如果中间CA被破坏，他们就会取消撤销它的能力:即使他们为它发布了吊销，您的客户端也会忽略它。

在CA确实希望您能够使用中间CA作为信任锚点的情况下，我看到他们为同一个公钥和DN提供了一个已颁发的证书和一个自签名证书。我假设，让我们加密它的中间CA不会这样做。

至于您关于wget、ftp.gnu.org和Let's Encrypt X3中间CA的实际问题，我认为您有两个选择：

• 找到发出Let's Encrypt X3的自签名根证书，并将其添加到信任存储中。
• 想办法直接把公钥钉起来。这将取决于您正在使用的软件/ OS堆栈，以及它是否支持RFC中允许信任锚成为密钥而不是证书的陈旧和不寻常的部分。

Answer 2

作为一个普遍的假设:如果它不是自签名的，那么您就依赖于其他实体来灌输信任；根据定义，另一个实体将成为锚。

虽然许多实现可能会信任更深层次的东西，但这并不是PKI/x 509的功能--这是一种带外信任；因此，RFC超出了范围。

这引发了一个问题:你为什么要在锚上灌输隐含的信任，因为它本身没有发行人的隐含信任(它可能被撤销)。