使用EST简化证书配置
你将学到的
公钥基础设施（PKI）的概念已经存在了很长时间。 PKI通过数字证书形式的签名公钥认证用户和设备的身份。
最近，互联网工程任务组（IETF）引入了安全运输注册（EST）协议来提供这些证书。 在本白皮书中，我们讨论了EST的优点。 我们也和其他人比较证书配置标准，即：
- 简单证书注册协议（SCEP）
- 证书管理协议（CMP）
- 密码消息语法（CMC）的证书管理
目录
介绍
- EST
- SCEP
- CMC and CMP
比较
- EST Versus SCEP
- EST Versus CMC and CMP
采用
结论
参考文献
致谢
介绍
证书已被用于长时间验证设备和个人。 它们用于证明802.1AR standard of the Institute of Electrical and Electronics Engineers (IEEE)中设备的身份。 它们也广泛应用于传输层安全，VPN和许多需要认证的领域。 证书通常由可信实体或证书颁发机构（CA）生成，并且可以使用PKI根的信任证书和证书链来验证。
作为证书无处不在，PKI还需要一种可以安全地向实体提供证书的机制。 注册机构（RA）经常作为中介。 在从CA获取证书之前，它可以验证客户端（图1）。
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(错误！ 没有找到参考资料)显示了随着时间的推移制定了这些标准。
在下一节中，我们将介绍为什么我们认为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。
结论
证书配置和PKI的问题是普遍存在的。 即使其他协议正在考虑之中，我们认为，由于其简单，开放的开放性，可用的开源代码以及其对应的优势，EST是证书配置的最佳候选解决方案。
读者应该注意，开源的libEST库是便携式的，易于使用。 随着时间的推移，更多的客户和公共认证机构将采用EST。 开源代码将使得更快速地将EST带入越来越多的产品，因此供应商可以以现代和高效的方式使用这种通用协议。
参考文献
EST RFC 7030:https://tools.ietf.org/html/rfc7030
libEST: https://github.com/cisco/libest
SCEP: https://tools.ietf.org/id/draft-gutmann-scep
Cryptographic Message Syntax (CMS): https://tools.ietf.org/html/rfc5652
Certificate Management over CMS (CMC): https://tools.ietf.org/html/rfc5272
Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF):
https://tools.ietf.org/html/rfc4211
CMC Transport Protocols: https://tools.ietf.org/html/rfc5273
PKCS 10: https://tools.ietf.org/html/rfc2986
Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP):
https://tools.ietf.org/html/rfc4210
PKCS 7: https://tools.ietf.org/html/rfc2315
致谢
Panos Kampanakis (panosk[at]cisco[dot]com)
Technical Marketing Engineer
Max Pritikin (pritikin[at]cisco[dot]com)
Principal Engineer
Thanks to Pete Beal and Peter Panburana for their valuable feedback.
