Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 8649 Vigil Security
Category: Informational August 2019
ISSN: 2070-1721
Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 8649 Vigil Security
Category: Informational August 2019
ISSN: 2070-1721
Hash Of Root Key Certificate Extension
根密钥证书扩展的哈希
Abstract
摘要
This document specifies the Hash Of Root Key certificate extension. This certificate extension is carried in the self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate. This certificate extension unambiguously identifies the next public key that will be used at some point in the future as the next Root CA certificate, eventually replacing the current one.
此文档指定根密钥证书扩展的哈希。此证书扩展包含在信任锚的自签名证书中，该证书通常称为根证书颁发机构（CA）证书。此证书扩展明确地标识下一个公钥，该公钥将在将来某个时候用作下一个根CA证书，最终替换当前证书。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8649.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8649.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Terminology ................................................2
1.2. ASN.1 ......................................................3
2. Overview ........................................................3
3. Hash Of Root Key Certificate Extension ..........................4
4. IANA Considerations .............................................4
5. Operational Considerations ......................................4
6. Security Considerations .........................................6
7. References ......................................................7
7.1. Normative References .......................................7
7.2. Informative References .....................................8
Appendix A. ASN.1 Module ..........................................9
Acknowledgements ..................................................10
Author's Address ..................................................10
1. Introduction ....................................................2
1.1. Terminology ................................................2
1.2. ASN.1 ......................................................3
2. Overview ........................................................3
3. Hash Of Root Key Certificate Extension ..........................4
4. IANA Considerations .............................................4
5. Operational Considerations ......................................4
6. Security Considerations .........................................6
7. References ......................................................7
7.1. Normative References .......................................7
7.2. Informative References .....................................8
Appendix A. ASN.1 Module ..........................................9
Acknowledgements ..................................................10
Author's Address ..................................................10
This document specifies the Hash Of Root Key X.509 version 3 certificate extension. The extension is an optional addition to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile [RFC5280]. The certificate extension facilitates the orderly transition from one Root Certification Authority (CA) public key to the next. It does so by publishing the hash value of the next-generation public key in the current self-signed certificate. This hash value is a commitment to a particular public key in the next-generation self-signed certificate. This commitment allows a relying party to unambiguously recognize the next-generation self-signed certificate when it becomes available, install the new self-signed certificate in the trust anchor store, and eventually remove the previous one from the trust anchor store.
此文档指定根密钥X.509版本3证书扩展的哈希。该扩展是Internet X.509公钥基础结构证书和证书吊销列表（CRL）配置文件[RFC5280]的可选添加。证书扩展促进了从一个根证书颁发机构（CA）公钥到下一个公钥的有序转换。它通过在当前自签名证书中发布下一代公钥的哈希值来实现。此哈希值是对下一代自签名证书中特定公钥的承诺。此承诺允许依赖方在下一代自签名证书可用时明确识别该证书，在信任锚存储中安装新的自签名证书，并最终从信任锚存储中删除前一个自签名证书。
A Root CA certificate MAY include the Hash Of Root Key certificate extension to provide the hash value of the next public key that will be used by the Root CA.
根CA证书可以包括根密钥证书扩展的哈希，以提供根CA将使用的下一个公钥的哈希值。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Certificates [RFC5280] use ASN.1 [X680]; Distinguished Encoding Rules (DER) [X690] are REQUIRED for certificate signing and validation.
证书[RFC5280]使用ASN.1[X680]；证书签名和验证需要区分编码规则（DER）[X690]。
Before the initial deployment of the Root CA, the following are generated:
在初始部署根CA之前，将生成以下内容：
R1 = The initial Root key pair R2 = The second-generation Root key pair H2 = Thumbprint (hash) of the public key of R2 C1 = Self-signed certificate for R1, which also contains H2
R1=初始根密钥对R2=第二代根密钥对H2=R2的公钥指纹（散列）C1=R1的自签名证书，该证书也包含H2
C1 is a self-signed certificate, and it contains H2 within the HashOfRootKey extension. C1 is distributed as part of the initial system deployment. The HashOfRootKey certificate extension is described in Section 3.
C1是自签名证书，在HashOfRootKey扩展中包含H2。C1作为初始系统部署的一部分分发。第3节介绍了HashOfRootKey证书扩展。
When the time comes to replace the initial Root CA certificate, R1, the following are generated:
当替换初始根CA证书R1时，将生成以下内容：
R3 = The third-generation Root key pair H3 = Thumbprint (hash) the public key of R3 C2 = Self-signed certificate for R2, which contains H3
R3=第三代根密钥对H3=指纹（哈希）R3 C2=R2的自签名证书的公钥，其中包含H3
This is an iterative process. That is, R4 and H4 are generated when it is time for C3 to replace C2, and so on.
这是一个迭代过程。也就是说，R4和H4是在C3替换C2时生成的，依此类推。
The successor to the Root CA self-signed certificate can be delivered by any means. Whenever a new Root CA self-signed certificate is received, the recipient is able to verify that the potential Root CA certificate links back to a previously authenticated Root CA certificate with the HashOfRootKey certificate extension. That is, the recipient verifies the signature on the self-signed certificate and verifies that the hash of the DER-encoded SubjectPublicKeyInfo from the potential Root CA certificate matches the value from the HashOfRootKey certificate extension of the current Root CA certificate. Checking the self-signed certificate signature ensures that the certificate contains the subject name, public key algorithm identifier, and public key algorithm parameters intended by the key owner; these are important inputs to certification path validation as defined in Section 6 of [RFC5280]. Checking the hash of the SubjectPublicKeyInfo ensures that the certificate contains the intended public key. If either check fails, then the potential Root CA certificate is not a valid replacement, and the recipient continues to use the current Root CA certificate. If both checks
根CA自签名证书的后续证书可以通过任何方式交付。每当接收到新的根CA自签名证书时，接收方都能够验证潜在的根CA证书是否链接回具有HashOfRootKey证书扩展名的以前经过身份验证的根CA证书。也就是说，接收方验证自签名证书上的签名，并验证潜在根CA证书中DER编码的SubjectPublicKeyInfo的哈希值是否与当前根CA证书的HashOfRootKey证书扩展中的值匹配。检查自签名证书签名确保证书包含密钥所有者想要的使用者名称、公钥算法标识符和公钥算法参数；这些是[RFC5280]第6节中定义的认证路径验证的重要输入。检查SubjectPublicKeyInfo的哈希可确保证书包含预期的公钥。如果任一检查失败，则潜在的根CA证书不是有效的替换证书，并且收件人继续使用当前的根CA证书。如果两者都检查
succeed, then the recipient adds the potential Root CA certificate to the trust anchor store. As discussed in Section 5, the recipient can remove the current Root CA certificate immediately in some situations. In other situations, the recipient waits an appropriate amount of time to ensure that existing certification paths continue to validate.
成功，则收件人将潜在的根CA证书添加到信任锚存储区。如第5节所述，在某些情况下，收件人可以立即删除当前根CA证书。在其他情况下，收件人会等待适当的时间，以确保现有的证书路径继续验证。
The HashOfRootKey certificate extension MUST NOT be critical.
HashOfRootKey证书扩展不能是关键的。
The following ASN.1 [X680] [X690] syntax defines the HashOfRootKey certificate extension:
以下ASN.1[X680][X690]语法定义了HashOfRootKey证书扩展：
ext-HashOfRootKey EXTENSION ::= { -- Only in Root CA certificates
SYNTAX HashedRootKey
IDENTIFIED BY id-ce-hashOfRootKey
CRITICALITY {FALSE} }
ext-HashOfRootKey EXTENSION ::= { -- Only in Root CA certificates
SYNTAX HashedRootKey
IDENTIFIED BY id-ce-hashOfRootKey
CRITICALITY {FALSE} }
HashedRootKey ::= SEQUENCE {
hashAlg HashAlgorithm, -- Hash algorithm used
hashValue OCTET STRING } -- Hash of DER-encoded
-- SubjectPublicKeyInfo
HashedRootKey ::= SEQUENCE {
hashAlg HashAlgorithm, -- Hash algorithm used
hashValue OCTET STRING } -- Hash of DER-encoded
-- SubjectPublicKeyInfo
id-ce-hashOfRootKey ::= OBJECT IDENTIFIER { 1 3 6 1 4 1 51483 2 1 }
id-ce-hashOfRootKey ::= OBJECT IDENTIFIER { 1 3 6 1 4 1 51483 2 1 }
The definitions of EXTENSION and HashAlgorithm can be found in [RFC5912].
扩展和哈希算法的定义见[RFC5912]。
The hashAlg indicates the one-way hash algorithm that was used to compute the hash value.
hashAlg表示用于计算散列值的单向散列算法。
The hashValue contains the hash value computed from the next-generation public key. The public key is the DER-encoded SubjectPublicKeyInfo as defined in [RFC5280].
hashValue包含根据下一代公钥计算的哈希值。公钥是[RFC5280]中定义的DER编码的SubjectPublicKeyInfo。
This document has no IANA actions.
本文档没有IANA操作。
Guidance on the transition from one root key to another is available in Section 4.4 of [RFC4210]. Of course, a root key is also known as a trust anchor. In particular, the oldWithNew and newWithOld advice ensures that relying parties are able to validate certificates issued under the current Root CA certificate and the next-generation Root CA certificate throughout the transition. The notAfter field in the
[RFC4210]第4.4节提供了从一个根密钥到另一个根密钥的转换指南。当然，根密钥也称为信任锚。特别是，oldWithNew和newWithOld通知确保依赖方能够在整个转换过程中验证根据当前根CA证书和下一代根CA证书颁发的证书。中的notAfter字段
oldWithNew certificate MUST cover the validity period of all unexpired certificates issued under the old Root CA private key. Further, this advice SHOULD be followed by Root CAs to avoid the need for all relying parties to make the transition at the same time.
oldWithNew证书必须覆盖根据旧根CA私钥颁发的所有未过期证书的有效期。此外，根CA应遵循此建议，以避免所有依赖方同时进行过渡。
After issuing the newWithOld certificate, the Root CA MUST stop using the old private key to sign certificates.
颁发newWithOld证书后，根CA必须停止使用旧私钥对证书进行签名。
Some enterprise and application-specific environments offer a directory service or certificate repository to make certificate and CRLs available to relying parties. Section 3 in [RFC5280] describes a certificate repository. When a certificate repository is available, the oldWithNew and newWithOld certificates SHOULD be published before the successor to the current Root CA self-signed certificate is released. Recipients that are able to obtain the oldWithNew certificate SHOULD immediately remove the old Root CA self-signed certificate from the trust anchor store.
某些企业和特定于应用程序的环境提供目录服务或证书存储库，以使证书和CRL可供依赖方使用。[RFC5280]中的第3节描述了证书存储库。当证书存储库可用时，应在发布当前根CA自签名证书的后续证书之前发布oldWithNew和newWithOld证书。能够获得oldWithNew证书的收件人应立即从信任锚存储中删除旧的根CA自签名证书。
In environments without such a directory service or repository, like the Web PKI, recipients need a way to obtain the oldWithNew and newWithOld certificates. The Root CA SHOULD include the subject information access extension [RFC5280] with the accessMethod set to id-ad-caRepository and the assessLocation set to the HTTP URL that can be used to fetch a DER-encoded "certs-only" (simple PKI response) message as specified in [RFC5272] in all of their self-signed certificates. The Root CA SHOULD publish the "certs-only" message with the oldWithNew certificate and the newWithOld certificate before the subsequent Root CA self-signed certificate is released. The "certs-only" message format allows certificates to be added and removed from the bag of certificates over time, so the same HTTP URL can be used throughout the lifetime of the Root CA.
在没有此类目录服务或存储库（如Web PKI）的环境中，收件人需要一种获取oldWithNew和newWithOld证书的方法。根CA应包括主题信息访问扩展[RFC5280]，accessMethod设置为id ad caRepository，assessLocation设置为HTTP URL，可用于获取[RFC5272]中指定的DER编码的“仅证书”（简单PKI响应）消息，这些消息包含在其所有自签名证书中。在发布后续根CA自签名证书之前，根CA应使用oldWithNew证书和newWithOld证书发布“仅证书”消息。“certs only”消息格式允许随着时间的推移从证书包中添加和删除证书，因此可以在根CA的整个生命周期中使用相同的HTTP URL。
In environments without such a directory service or repository, recipients SHOULD keep both the old and replacement Root CA self-signed certificates in the trust anchor store for some amount of time to ensure that all end-entity certificates can be validated until they expire. The recipient MAY keep the old Root CA self-signed certificate until all of the certificates in the local cache that are subordinate to it have expired.
在没有此类目录服务或存储库的环境中，收件人应将旧的和替换的根CA自签名证书保留在信任锚点存储中一段时间，以确保所有最终实体证书在到期之前都可以进行验证。收件人可以保留旧的根CA自签名证书，直到本地缓存中从属于它的所有证书过期。
Certification path construction is more complex when the trust anchor store contains multiple self-signed certificates with the same distinguished name. For this reason, the replacement Root CA self-signed certificate SHOULD contain a different distinguished name than the one it is replacing. One approach is to include a number as part of the name that is incremented with each generation, such as "Example CA", "Example CA G2", "Example CA G3", and so on.
当信任锚点存储包含多个具有相同可分辨名称的自签名证书时，证书路径构造更为复杂。因此，替换根CA自签名证书应包含与其替换的可分辨名称不同的可分辨名称。一种方法是在名称中包含一个数字，该数字随着每一代的增加而增加，例如“示例CA”、“示例CA G2”、“示例CA G3”等等。
Changing names from one generation to another can lead to confusion when reviewing the history of a trust anchor store. To assist with such review, a recipient MAY create an audit entry to capture the old and replacement self-signed certificates.
在查看信任锚存储的历史记录时，将名称从一代更改到另一代可能会导致混淆。为了帮助进行此类审查，收件人可以创建一个审核条目来捕获旧的和替换的自签名证书。
The Root CA must securely back up the yet-to-be-deployed key pair. If the Root CA stores the key pair in a hardware security module and that module fails, the Root CA remains committed to the key pair that is no longer available. This leaves the Root CA with no alternative but to deploy a new self-signed certificate that contains a newly generated key pair in the same manner as the initial self-signed certificate, thus losing the benefits of the Hash Of Root Key certificate extension altogether.
根CA必须安全地备份尚未部署的密钥对。如果根CA将密钥对存储在硬件安全模块中，而该模块出现故障，则根CA仍将提交给不再可用的密钥对。这使得根CA别无选择，只能以与初始自签名证书相同的方式部署新的自签名证书，该证书包含新生成的密钥对，从而完全失去根密钥证书扩展哈希的好处。
The security considerations from [RFC5280] apply, especially the discussion of self-issued certificates.
[RFC5280]中的安全注意事项适用，尤其是对自颁发证书的讨论。
The Hash Of Root Key certificate extension facilitates the orderly transition from one Root CA public key to the next by publishing the hash value of the next-generation public key in the current certificate. This allows a relying party to unambiguously recognize the next-generation public key when it becomes available; however, the full public key is not disclosed until the Root CA releases the next-generation certificate. In this way, attackers cannot begin to analyze the public key before the next-generation Root CA self-signed certificate is released.
根密钥证书扩展散列通过在当前证书中发布下一代公钥的散列值，有助于从一个根CA公钥有序地转换到下一个根CA公钥。这允许依赖方在下一代公钥可用时明确地识别该公钥；但是，在根CA发布下一代证书之前，不会公开完整公钥。这样，攻击者就无法在下一代根CA自签名证书发布之前开始分析公钥。
The Root CA needs to ensure that the public key in the next-generation certificate is as strong or stronger than the key that it is replacing. Of course, a significant advance in cryptoanalytic capability can break the yet-to-be-deployed key pair. Such advances are rare and difficult to predict. If such an advance occurs, the Root CA remains committed to the now broken key. This leaves the Root CA with no alternative but to deploy a new self-signed certificate that contains a newly generated key pair, most likely using a different signature algorithm, in the same manner as the initial self-signed certificate, thus losing the benefits of the Hash Of Root Key certificate extension altogether.
根CA需要确保下一代证书中的公钥与它要替换的密钥一样强或更强。当然，密码分析能力的重大进步可以打破尚未部署的密钥对。这种进步是罕见的，也很难预测。如果发生这样的提前，根CA仍将致力于现在已断开的密钥。这使得根CA别无选择，只能部署一个新的自签名证书，该证书包含新生成的密钥对，很可能使用与初始自签名证书相同的方式使用不同的签名算法，从而完全失去根密钥证书扩展散列的好处。
The Root CA needs to employ a hash function that is resistant to preimage attacks [RFC4270]. A first-preimage attack against the hash function would allow an attacker to find another input that results in the hash value of the next-generation public key that was published in the current certificate. For the attack to be successful, the input would have to be a valid SubjectPublicKeyInfo that contains a public key that corresponds to a private key known to
根CA需要使用抗预映像攻击的哈希函数[RFC4270]。针对哈希函数的第一个前映像攻击将允许攻击者找到另一个输入，该输入会导致在当前证书中发布的下一代公钥的哈希值。要使攻击成功，输入必须是有效的SubjectPublicKeyInfo，该SubjectPublicKeyInfo包含一个公钥，该公钥对应于已知的私钥
the attacker. A second-preimage attack becomes possible once the Root CA releases the next-generation public key, which makes the input to the hash function available to the attacker and everyone else. Again, the attacker needs to find a valid SubjectPublicKeyInfo that contains the public key that corresponds to a private key known to the attacker. If the employed hash function is broken after the Root CA publishes the self-signed certificate with the HashOfRootKey certificate extension, an attacker would be able to trick the recipient into installing the incorrect next-generation certificate in the trust anchor store.
袭击者。一旦根CA释放下一代公钥，攻击者和其他所有人都可以使用哈希函数的输入，第二次预映像攻击就成为可能。同样，攻击者需要找到有效的SubjectPublicKeyInfo，该SubjectPublicKeyInfo包含与攻击者已知的私钥相对应的公钥。如果在根CA发布具有HashOfRootKey证书扩展名的自签名证书后，所使用的哈希函数被破坏，则攻击者将能够诱使收件人在信任锚存储中安装不正确的下一代证书。
If an early release of the next-generation public key occurs and the Root CA is concerned that attackers were given too much lead time to analyze that public key, then the Root CA can transition to a freshly generated key pair by rapidly performing two transitions. After the first transition, the Root CA is using the key pair that suffered the early release, and that transition causes the Root CA to generate the subsequent Root key pair. The second transition occurs when the Root CA is confident that the population of relying parties has completed the first transition, and it takes the Root CA to the freshly generated key pair. Of course, the second transition also causes the Root CA to generate another key pair that is reserved for future use. Queries for the CRLs associated with certificates that are subordinate to the self-signed certificate can give some indication of the number of relying parties that are still actively using the self-signed certificates.
如果下一代公钥提前发布，并且根CA担心攻击者被给予了太多的前置时间来分析该公钥，则根CA可以通过快速执行两次转换来转换为新生成的密钥对。在第一次转换之后，根CA正在使用遭受早期释放的密钥对，该转换导致根CA生成后续的根密钥对。当根CA确信依赖方的总体已完成第一次转换，并且它将根CA带到新生成的密钥对时，就会发生第二次转换。当然，第二个转换也会导致根CA生成另一个保留供将来使用的密钥对。查询与自签名证书从属的证书相关联的CRL，可以在某种程度上指示仍在积极使用自签名证书的依赖方的数量。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, DOI 10.17487/RFC4210, September 2005, <https://www.rfc-editor.org/info/rfc4210>.
[RFC4210]Adams，C.，Farrell，S.，Kause，T.，和T.Mononen，“互联网X.509公钥基础设施证书管理协议（CMP）”，RFC 4210，DOI 10.17487/RFC4210，2005年9月<https://www.rfc-editor.org/info/rfc4210>.
[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, DOI 10.17487/RFC4270, November 2005, <https://www.rfc-editor.org/info/rfc4270>.
[RFC4270]Hoffman，P.和B.Schneier，“对互联网协议中加密哈希的攻击”，RFC 4270，DOI 10.17487/RFC4270，2005年11月<https://www.rfc-editor.org/info/rfc4270>.
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, <https://www.rfc-editor.org/info/rfc5272>.
[RFC5272]Schaad，J.和M.Myers，“CMS的证书管理（CMC）”，RFC 5272，DOI 10.17487/RFC5272，2008年6月<https://www.rfc-editor.org/info/rfc5272>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<https://www.rfc-editor.org/info/rfc5280>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, <https://www.rfc-editor.org/info/rfc5912>.
[RFC5912]Hoffman，P.和J.Schaad，“使用X.509（PKIX）的公钥基础设施的新ASN.1模块”，RFC 5912，DOI 10.17487/RFC5912，2010年6月<https://www.rfc-editor.org/info/rfc5912>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[X680] ITU-T, "Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, August 2015.
[X680]ITU-T，“信息技术——抽象语法符号一（ASN.1）：基本符号规范”，ITU-T建议X.680，2015年8月。
[X690] ITU-T, "Information Technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, August 2015.
[X690]ITU-T，“信息技术——ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，ITU-T建议X.690，2015年8月。
[SET] MasterCard and VISA, "SET Secure Electronic Transaction Specification -- Book 2: Programmer's Guide, Version 1.0", May 1997.
[SET]万事达卡和VISA，“SET安全电子交易规范——第2册：程序员指南，1.0版”，1997年5月。
The following ASN.1 module provides the complete definition of the HashOfRootKey certificate extension.
下面的ASN.1模块提供了HashOfRootKey证书扩展的完整定义。
<CODE BEGINS>
<代码开始>
HashedRootKeyCertExtn { 1 3 6 1 4 1 51483 0 1 }
HashedRootKeyCertExtn{1 3 6 1 4 1 51483 0 1}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS All
--全部出口
IMPORTS
进口
HashAlgorithm
FROM PKIX1-PSS-OAEP-Algorithms-2009 -- RFC 5912
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-rsa-pkalgs-02(54) }
HashAlgorithm
FROM PKIX1-PSS-OAEP-Algorithms-2009 -- RFC 5912
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-rsa-pkalgs-02(54) }
EXTENSION
FROM PKIX-CommonTypes-2009 -- RFC 5912
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) } ;
EXTENSION
FROM PKIX-CommonTypes-2009 -- RFC 5912
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) } ;
-- -- Expand the certificate extensions list in RFC 5912 --
----展开RFC 5912中的证书扩展列表--
CertExtensions EXTENSION ::= {
ext-HashOfRootKey, ... }
CertExtensions EXTENSION ::= {
ext-HashOfRootKey, ... }
-- -- HashOfRootKey Certificate Extension --
----HashOfRootKey证书扩展--
ext-HashOfRootKey EXTENSION ::= { -- Only in Root CA certificates
SYNTAX HashedRootKey
IDENTIFIED BY id-ce-hashOfRootKey
CRITICALITY {FALSE} }
ext-HashOfRootKey EXTENSION ::= { -- Only in Root CA certificates
SYNTAX HashedRootKey
IDENTIFIED BY id-ce-hashOfRootKey
CRITICALITY {FALSE} }
HashedRootKey ::= SEQUENCE {
hashAlg HashAlgorithm, -- Hash algorithm used
hashValue OCTET STRING } -- Hash of DER-encoded
-- SubjectPublicKeyInfo
HashedRootKey ::= SEQUENCE {
hashAlg HashAlgorithm, -- Hash algorithm used
hashValue OCTET STRING } -- Hash of DER-encoded
-- SubjectPublicKeyInfo
id-ce-hashOfRootKey OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 51483 2 1 }
id-ce-hashOfRootKey OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 51483 2 1 }
END
终止
<CODE ENDS>
<代码结束>
Acknowledgements
致谢
The Secure Electronic Transaction (SET) [SET] specification published by MasterCard and VISA in 1997 includes a very similar certificate extension. The SET certificate extension has essentially the same semantics, but the syntax fairly different.
MasterCard和VISA在1997年发布的安全电子交易（SET）[SET]规范包括一个非常类似的证书扩展。SET证书扩展的语义基本相同，但语法却截然不同。
CTIA - The Wireless Association - is developing a public key infrastructure that will make use of the certificate extension described in this document; the object identifiers used in the ASN.1 module were assigned by CTIA.
CTIA——无线协会——正在开发一个公钥基础设施，该基础设施将利用本文档中描述的证书扩展；ASN.1模块中使用的对象标识符由CTIA分配。
Many thanks to Stefan Santesson, Jim Schaad, Daniel Kahn Gillmor, Joel Halpern, Paul Hoffman, Rich Salz, and Ben Kaduk. Their reviews and comments greatly improved the document, especially the "Operational Considerations" and "Security Considerations" sections.
非常感谢斯特凡·桑特森、吉姆·沙德、丹尼尔·卡恩·吉尔莫、乔尔·哈尔潘、保罗·霍夫曼、里奇·萨尔茨和本·卡杜克。他们的审查和评论大大改进了该文件，特别是“业务考虑”和“安全考虑”部分。
Author's Address
作者地址
Russ Housley Vigil Security 516 Dranesville Road Herndon, VA 20170 United States of America
美利坚合众国弗吉尼亚州赫恩登德兰斯维尔路516号Russ Housley Vigil Security，邮编：20170
Email: housley@vigilsec.com
Email: housley@vigilsec.com