假设以下公钥基础设施:
|根 CA (RSA)
|-子 CA (RSA)
|-子 CA (ECC)
是否有任何理由可以解释为什么这不是可接受的实现?
首选的实现是 RSA 的 PKI 和 ECC 的单独 PKI?
假设以下公钥基础设施:
|根 CA (RSA)
|-子 CA (RSA)
|-子 CA (ECC)
是否有任何理由可以解释为什么这不是可接受的实现?
首选的实现是 RSA 的 PKI 和 ECC 的单独 PKI?
根据X.509,没问题。你可以随意混合算法。每个签名都是独立的。
(X.509 包含一个特殊规定,即当 CA 使用 DSS 并颁发证书时也使用具有相同组参数的DSS ,在这种情况下颁发的证书可以省略组参数。这称为“参数继承”。这是从未在实践中使用过,也没有移植到 ECDSA,尽管这是一种可能性,并且显然是在某个时候设想的。据我所知,这是唯一一种情况,链中各个级别的签名算法在一起有任何关系.)
但是,您必须了解,通过使用几种不同的算法,您会强制“依赖方”(必须验证这些链的系统)来实现所有这些算法。虽然这对于桌面系统、服务器和智能手机通常不是问题,但对于希望节省代码大小并且不希望包含 RSA和ECDSA代码的小型嵌入式设备来说,这可能是一个问题。
这种问题体现在SSL 中,客户端和服务器互相告诉对方他们支持哪种算法来验证证书上的签名(例如,参见Certificate Request消息)。这是为了更好地支持代码空间很小的小型设备。在您的证书链中混合使用 RSA 和 ECDSA 会使您与该原则有些不一致。根据您的上下文,这可能重要也可能不重要(可能不重要)。
无论如何,这种混合链是预期的过渡。假设您从一个完整的 RSA 世界开始;根 CA 已分发到所有客户端系统(可能成本很高)。现在,您决定切换到 ECDSA,因为客户端软件由它决定(例如,它带有正常的操作系统/浏览器更新),但是创建一个新的 ECDSA 根并将其推送到所有客户端将花费大量时间。因此,要开始使用 ECDSA 而不会破坏已安装的基础,您需要制作交叉证书:
此交叉证书允许知道 newRoot 作为受信任根的系统使用路径“newRoot->cert”验证证书,并且只知道 oldRoot 的系统将使用“oldRoot->newRoot->cert”(在后一种情况下,通过交叉证书)。换句话说,newRoot 有两个证书,一个是自签名的(使用 ECDSA),另一个是由 oldRoot 签名的(使 newRoot 成为中间CA)。
这是处理密钥更改更新的相当标准的方法,但在 RSA 到 ECDSA 转换的情况下,它必然意味着混合算法链。因此,您描述的情况不仅得到支持,而且得到预期。
总结一下:使用完全独立的 PKI 允许使用单一算法的 PKI,这可能有助于嵌入式设备(仅实现一种算法)。但是,混合算法 PKI 是正常的事情,得到很好的支持,并且在 PKI 范围内转换到新算法的情况下是预期的。
据我所知,除了根 CA 想要强制执行的算法之外,对从属 CA 的算法没有任何要求。
事实上,与其寻找为什么它不可接受的理由,我会研究为什么它可以接受的理由。任何从属 CA 证书必须由根 CA 签名。而根 CA 代表了最终的信任。如果根 CA 使用 ECC/RSA/任何算法证书信任从属 CA,那么就可以了。根 CA 签署证书并扩展其信任。
但是,您可能应该提供 CA 策略,在其中声明您作为 CA 授权的内容,以便您的客户可以评估他们是否想要信任您的根 CA。查看已弃用或损坏的算法,并且永远不要在您的证书中接受它们。