PKI: Simplify Certificate Provis

2017-04-23 本文已影响0人御浅永夜

使用EST简化证书配置

你将学到的

公钥基础设施（PKI）的概念已经存在了很长时间。 PKI通过数字证书形式的签名公钥认证用户和设备的身份。

最近，互联网工程任务组（IETF）引入了安全运输注册（EST）协议来提供这些证书。在本白皮书中，我们讨论了EST的优点。我们也和其他人比较证书配置标准，即：

简单证书注册协议（SCEP）
证书管理协议（CMP）
密码消息语法（CMC）的证书管理

介绍

证书已被用于长时间验证设备和个人。它们用于证明802.1AR standard of the Institute of Electrical and Electronics Engineers (IEEE)中设备的身份。它们也广泛应用于传输层安全，VPN和许多需要认证的领域。证书通常由可信实体或证书颁发机构（CA）生成，并且可以使用PKI根的信任证书和证书链来验证。

作为证书无处不在，PKI还需要一种可以安全地向实体提供证书的机制。注册机构（RA）经常作为中介。在从CA获取证书之前，它可以验证客户端（图1）。

图1 普通高级PKI架构

EST

提供证书配置的最近定义的协议是通过安全传输注册，IETF的RFC 7030. EST通过使用在密码消息语法（CMC）上的安全传输的证书管理来为客户端配置证书注册。根据IETF，EST“描述了一个简单但功能齐全的证书管理协议，针对需要获取客户端证书和相关证书颁发机构（CA）证书的公钥基础设施（PKI）客户端。它还支持客户端生成的公钥/私钥对以及CA生成的密钥对。”

EST是通过IETF进行了几次迭代的标准化工作。标准社区的多个供应商和独立方参与了这项工作。 EST分别使用公钥加密标准(PKCS)10和加密消息语法(CMS)作为证书请求和证书定义。思科本身也有开源的libEST，这是一个提供客户端和服务器功能的EST库，以促进供应商之间的采用和互操作性。

SCEP

EST是简单证书注册协议（SCEP）的继任者，最初由思科发起。由于其简单性，SCEP多年来一直是证书供应中的事实上的协议。但它从未超出IETF草案。最近，它被IETF再次采用（取代了以前的SCEP草案），但缺乏区域主管支持使得标准化变得不太可能。 SCEP有一些重要的缺点，我们稍后会介绍。

CMC and CMP

在2000年，在EST之前，IETF在RFC 2797中定义了“CMS上的证书管理”（CMC）。八年后，RFC 5272中的“使用加密消息语法的证书管理协议”（也称CMC）使RFC 2797过时。 CMC在架构上非常类似于SCEP，尽管它具有更多选项并提供更多的算法敏捷性。 RFC 5272定义了消息格式，消息控制和数据结构，可提供范围广泛的证书管理操作，超出SCEP和EST的证书配置。它使用证书请求消息格式(CRMF)或(PKCS)10用于证书请求。之后，RFC 6402更新了一些CMC消息和控件以及RFC 5273中定义的传输机制（HTTP，文件，电子邮件，TCP）。

在RFC 2797和RFC 5272之间，IETF在2005年提出了一个竞争协议：互联网X.509公钥基础设施证书管理协议或CMP。（CMP在RFC 4210中定义，它取代RFC 2510）。 CMP也超出了证书注册并定义了自己的消息格式。它由RFC 6712更新，它将HTTP描述为CMP传输机制。

总之，有两种证书配置和注册协议：EST和SCEP。有两种证书管理协议：CMC和CMP。证书管理涵盖证书注册，撤销，状态，批处理请求等。Error! Reference source not found(错误！没有找到参考资料)显示了随着时间的推移制定了这些标准。

图2 证书管理和证书注册标准

在下一节中，我们将介绍为什么我们认为EST是证书配置的最佳选择，我们将与SCEP进行比较。我们还将指出EST与CMC和CMP之间的差异。

比较

EST Versus SCEP

EST和SCEP协议解决证书配置。与CMC和CMP不同，它们并不旨在解决所有证书管理问题。他们的主要目标是从CA或通过RA给端点提供证书（图1）。EST是一个更新的协议，克服了SCEP的一些限制。我们建议在可能的情况下使用EST在SCEP上，原因如下：

EST使用TLS来安全传输消息和证书，而不需要进一步封装消息。 SCEP通过HTTP运行，并使用pkcsPKIEnvelope信封中的pkiMessage消息进行保护。
在EST中，证书签名请求（CSR）可以绑定到已经被TLS信任和认证的请求者。在SCEP中，CSR使用客户端和CA之间的共享密钥进行身份验证，这引入了安全性问题，如下所述。
EST提供加密敏捷性。它支持椭圆曲线加密（ECC）和安全密码算法。 ECC用于世界各地的政府任务。它在计算上更有效率，这有利于资源受限的设备。 SCEP不支持ECC，因为它用于保护数据的PKCS 7方法取决于RSA加密。如最近提交的SCEP草案所述：“基于CMS和PKCS＃10的消息类型完全支持算法敏捷性，但请求者必须使用服务器支持的密钥类型。具体来说，他们必须使用能够进行加密和签名的PKC算法。 RSA是唯一广泛使用的具有这些属性的算法。“将算法更新为CMS并与CMC进行充分的对齐以利用此领域的新工作将需要尽可能多的努力，只需移动到EST并且不会跟踪任何标准工作。
自动证书重新注册或更新很重要。 EST被建立以支持自动重新注册。即使最近提交的SCEP草案包括续订消息，但在以前的提交中并非如此，SCEP实施中也不常常部署此类消息。
EST可以通过注册请求来支持服务器端密钥生成。 SCEP仅支持在客户端生成的私钥。资源PKI（RPKI）环境中的服务器端密钥生成可能很重要，或者没有足够的功率和熵源的约束设备来生成随机私钥。
EST是联合标准的努力，包括供应商和标准社区。它在IETF的开发阶段受到广泛的社区监督。供应商和私人方采用EST进行EST的开源实施。 SCEP是在20世纪90年代开发的，尽管它被广泛使用，但是IETF的审查过程没有得到EST的贯彻。
EST提供CA滚动功能，通过在过渡期使用三个证书来刷新信任锚点。过渡期提供了一种路径，其中所有PKI实体可以逐渐滚动到新的CA信任增量而不影响实体之间的通信。 SCEP需要CA证书更新的“标志日”。由于没有过渡期，经营者无法确定事情是否能够在旗帜日内起作用。另外，使用GetNextCACert消息完成CA证书更新。没有请求数据与此消息相关联，因此更新由CA触发，使CA滚动更少灵活性和更少的自动化。
EST不提供检索证书撤销状态的机制。 SCEP定义了证书吊销列表（CRL）检索消息，以便端点可以接收到特定证书的撤销状态。也可以从证书本身检索CRL分发点（CDP）。但是，即使CRL检索在某些情况下可能有用，证书撤销超出了证书配置或检索CRL。撤销的其他选项是在线证书状态协议（OCSP）和OCSP装订。 Firefox最近不赞成CRL支持OCSP。此外，如果CA不使用OCSP，则需要将CRL分解成多个单独的文件。请求的SCEP方法CRL不包括此信息，因此SCEP服务器需要PKI CRL结构的重要详细信息，或需要CA为单个CRL使用不可扩展的平面文件。这是一个重要的限制。

就安全风险而言，值得指出的是：

在EST中，证书签名请求（CSR the certificate signing requset）可以绑定到已经被TLS信任和认证的请求者。证书仅提供给请求它的实体，该实体拥有私钥或用户名和密码（proof of possesion拥有证明或PoP）。换句话说，当PoP被强制执行时，客户端不能为任何人自己获得证书。在SCEP中，CSR使用客户端和CA之间的共享密钥进行身份验证。缺少用户名会使共享密钥的分发变得复杂，因此在大多数现实世界的部署中，共享密钥对于每个客户端来说都不是一次性的秘密。这引入了一个漏洞。访问共享密钥的人可以为自己以外的实体生成证书。当使用PoP时，在EST中永远都不会发生。
TLS的经过验证的安全性和持续改进有助于确保EST交易在加密保护方面是安全的。随着技术进步（例如处理速度或量子计算），SCEP与RSA紧密集成以保护数据引入了安全性问题。

EST Versus CMC and CMP

EST不解决与CMC和CMP相同的问题。 EST处理证书配置，但CMC和CMP地址证书管理，包括注册，撤销，状态，批处理请求等。 EST是一个安全传输的CMC配置文件，专注于密钥注册和更新（将所有其他选项留给完整的CMC消息）。 EST还遵循CA证书翻转的CMP范例。 CMC成功了CMP定义。令人困惑的是，IETF在这么短的时间内定义了两个具有相同目标的标准。他们缺乏主流接受度，部分原因是它们实施的复杂程度。

EST在其他方式上与CMC和CMP不同：

EST是更轻量级的，其消息很简单。由于CMS消息的多次包装以及定义如何处理控制数据的各种抽象语法符号一（ASN.1）结构，CMC是复杂的。类似地，CMP使用包络消息数据。
EST定义了一个安全的运输机制，并不允许其解释或其他标准。
EST使用注册请求定义服务器大小的密钥生成选项。通过运行TLS，它使私钥的传输更简单，无需额外的加密即可发送。 CMC没有解决这个问题。有一个关于CMC服务器端密钥生成的草案，但它从未被批准。 CMP具有超出范围的服务器端密钥生成。服务器端密钥生成在RPKI或者没有足够的功率和熵源的受限设备中可能很重要，以生成随机私钥。
CMC不涉及CA证书的更新。 EST将CMP定义的CA证书更新结合到CMC规范中。该模型已被业界证实，现在由注册协议支持。

采用

我们在本文档中介绍的协议用于各种设置。读者对于协议在行业中的应用方式有一个了解是非常重要的。

SCEP已经存在了15年以上，在许多厂商的产品中。几乎所有的CA都支持它，它已被包含在许多标准中。然而，SCEP的限制（如上所述）使其不适合现代环境。

另一方面，第三代合作伙伴计划(3GPP)标准委员会要求CMP作为其TS 33.310标准的一部分。 TS 33.310中CMP的实际使用限于如EST所述的配置功能（尽管在IETF for CMP中没有实际定义该配置文件）。 CMP也被纳入国家标准与技术研究所（NIST）特刊800-57。此外，一些CA供应商和PKI产品支持CMP。有些也支持CMC。

对于EST，即使它比SCEP，CMP和CMC更年轻，它被用于IETF ANIMA工作组的引导草案。在Wi-Fi联盟定义的Hotspot 2.0（也称为HS2）中也需要EST。此外，国际电工委员会（IEC）制定了IEC 62351，其中涉及电力系统的安全性，EST是选择的证书提供协议。最后，CA供应商正在增加对EST的支持。思科的IOS和IOS-XE产品已经支持EST。