DigiCert:为文档签名创建专用的扩展密钥用法(EKU)

一个互联网草案已经提出了互联网工程任务组(IETF),以创建专用于文件签署的扩展密钥用法(EKU) 。如果被接受,第一次将有一个特定的EKU,用于数字签名的重要用例。

公共信任PKI有一个加速的趋势,即通过它们创建的数字证书类型来分离颁发的证书颁发机构 (CA)。这通常由终端实体证书中包含的EKU扩展完成。

为什么要为文档签名创建专用的扩展密钥用法?

重点始于CA/浏览器 (CA/B) 论坛的工作,其TLS/SSL和代码签名证书的标准规定了 CA 对这些用例的分离。随着 Mozilla 最近要求 CA 计划用反映当前社区标准的新版本替换其现有的根 CA 证书,这一趋势得到了额外的重视。作为回应,许多CA正在摆脱过去的“通用”层次结构,并根据其用例将 CA 分开。

虽然从合规性和标准的角度来看,这种内务管理被广泛认为是有益的,但它突出了一个问题。x.509 证书的通用 EKU 由 IETF 在 RFC 5280 中定义,包括通用 EKU,例如用于 TLS 的 id-kp-serverAuth 和 id-kp-clientAuth,以及用于代码签名的 id-kp-codeSigning。但是,从来没有定义过用于文档签名的 EKU。

因此,大多数文档签名证书都采用了通用 id-kp-emailProtection EKU,它适用于S/MIME 证书,即使证书不包含电子邮件地址。或者,CA 可以使用私有 EKU,例如由个人签名平台提供的。

由于两股力量,这个问题正在变得尖锐起来。首先,AdobeSign、DocuSign 和 DigiCert 的文档签名管理器等平台的迅速普及正在推动文档签名的大众市场采用。其次,行业标准化 CA 实践和证书配置文件的努力可能会为跨越用例(及其不同的标准要求)的“多用途”证书带来合规性问题。

一个具体的例子是CA/B 论坛的 S/MIME 证书工作组,它正在制定一项新的 S/MIME 基线要求,重点是包含 id-kp-emailProtection EKU 的证书。虽然该组织正在尽一切努力避免对其他领域产生意外的不利影响,例如利用 EKU 的文件签名,但这些证书拥有“属于自己的 EKU 之家”显然是有益的。

同样,在签名领域,通过 Adob​​e 批准的信任列表和欧洲 eIDAS 的合格制度等努力,签名证书的标准和证书配置文件不断发展,有朝一日可能会与 S/MIME 用例发生冲突。

因此,SECOM 的 Tadahiko ITO 和 DigiCert 的 Tomofumi Okubo 向 IETF 提出了一份名为通用扩展密钥使用 (EKU) 的互联网草案,用于文档签名 X.509 证书。该文件明确指出需要专用的 id-kp-documentSigning EKU 成为 x.509 数字证书核心标准的一部分。

草案一旦通过 EKU将会被使用

如果该草案被 IETF 通过,互联网编号分配机构 (IANA) 将为 EKU 分配一个对象标识符 (OID),然后可以在证书中使用该标识符。现有和未来的文档签名标准、根程序和产品将能够使用 EKU 来确定特定证书是否旨在用于文档签名。

DigiCert 非常注意确保拥有文档签名证书的客户不会受到这种标准演变的过度影响。DigiCert 支持 Internet-Draft,并鼓励 CA、文档签名和数字转换领域的其他相关方同样表达他们对创建用于文档签名和数字签名的专用通用 EKU 的支持。文档签名 EKU 的采用符合证书用例分离的行业趋势,并将促进文档签名和 S/MIME 行业标准的持续发展。

免责声明:文章内容不代表DigiCert证书评测网的立场,本站不对其内容的真实性、完整性、准确性给予任何担保、暗示和承诺,仅供读者参考,文章版权归原作者所有。如本文内容影响到您的合法权益(内容、图片等),请及时联系本站,我们会及时删除处理。

为您推荐