Internet Engineering Task Force (IETF) R. Gagliano
Request for Comments: 6916 Cisco Systems
BCP: 182 S. Kent
Category: Best Current Practice BBN Technologies
ISSN: 2070-1721 S. Turner
IECA, Inc.
April 2013
Internet Engineering Task Force (IETF) R. Gagliano
Request for Comments: 6916 Cisco Systems
BCP: 182 S. Kent
Category: Best Current Practice BBN Technologies
ISSN: 2070-1721 S. Turner
IECA, Inc.
April 2013
Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)
资源公钥基础设施（RPKI）的算法敏捷性程序
Abstract
摘要
This document specifies the process that Certification Authorities (CAs) and Relying Parties (RPs) participating in the Resource Public Key Infrastructure (RPKI) will need to follow to transition to a new (and probably cryptographically stronger) algorithm set. The process is expected to be completed over a timescale of several years. Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration (parent migrates before children).
本文档规定了认证机构（CA）和参与资源公钥基础设施（RPKI）的依赖方（RPs）需要遵循的流程，以过渡到新的（可能在加密方面更强）算法集。这一进程预计将在几年的时间内完成。因此，没有规定紧急过渡。本文档中定义的转换过程仅支持自上而下的迁移（父迁移先于子迁移）。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
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). Further information on BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6916.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6916.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Key Rollover Steps for Algorithm Migration . . . . . . . . . . 6
4.1. Milestones Definition . . . . . . . . . . . . . . . . . . 6
4.2. Process Overview . . . . . . . . . . . . . . . . . . . . . 7
4.3. Phase 0 . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3.1. Milestone 1 . . . . . . . . . . . . . . . . . . . . . 9
4.4. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.6. Phase 3 . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.7. Phase 4 . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.8. Return to Phase 0 . . . . . . . . . . . . . . . . . . . . 14
5. Support for Multiple Algorithms in the RPKI Provisioning
Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Validation of Multiple Instances of Signed Products . . . . . 15
7. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Key Rollover . . . . . . . . . . . . . . . . . . . . . . . . . 17
9. Repository Structure . . . . . . . . . . . . . . . . . . . . . 17
10. Deprecating an Algorithm Suite . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
13. Normative References . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Key Rollover Steps for Algorithm Migration . . . . . . . . . . 6
4.1. Milestones Definition . . . . . . . . . . . . . . . . . . 6
4.2. Process Overview . . . . . . . . . . . . . . . . . . . . . 7
4.3. Phase 0 . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3.1. Milestone 1 . . . . . . . . . . . . . . . . . . . . . 9
4.4. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.6. Phase 3 . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.7. Phase 4 . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.8. Return to Phase 0 . . . . . . . . . . . . . . . . . . . . 14
5. Support for Multiple Algorithms in the RPKI Provisioning
Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Validation of Multiple Instances of Signed Products . . . . . 15
7. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Key Rollover . . . . . . . . . . . . . . . . . . . . . . . . . 17
9. Repository Structure . . . . . . . . . . . . . . . . . . . . . 17
10. Deprecating an Algorithm Suite . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
13. Normative References . . . . . . . . . . . . . . . . . . . . . 19
The Resource Public Key Infrastructure (RPKI) must accommodate transitions between the public keys used by Certification Authorities (CAs). Transitions of this sort are usually termed "key rollover". Planned key rollover will occur regularly throughout the life of the RPKI, as each CA changes its public keys, in a non-coordinated fashion. (By non-coordinated we mean that the time at which each CA elects to change its keys is locally determined, not coordinated across the RPKI.) Moreover, because a key change might be necessitated by suspected private key compromise, one can never assume coordination of these events among all of the CAs in the RPKI. In an emergency key rollover, the old certificate is revoked and a new certificate with a new key is issued. The mechanisms to perform a key rollover in RPKI (either planned or in an emergency), while maintaining the same algorithm suite, are covered in [RFC6489].
资源公钥基础设施（RPKI）必须适应证书颁发机构（CA）使用的公钥之间的转换。这种类型的转换通常称为“键翻转”。在RPKI的整个生命周期内，随着每个CA以非协调方式更改其公钥，计划的密钥翻转将定期发生。（非协调我们的意思是，每个CA选择更改其密钥的时间是本地确定的，而不是在RPKI中进行协调。）此外，由于怀疑私钥泄露可能需要更改密钥，因此我们永远不能假设RPKI中的所有CA之间协调了这些事件。在紧急密钥翻转中，旧证书将被吊销，并颁发具有新密钥的新证书。[RFC6489]介绍了在维护相同算法套件的同时在RPKI中执行密钥翻转的机制（无论是计划中还是紧急情况下）。
This document describes the mechanism to perform a key rollover in the RPKI due to the migration to a new signature algorithm suite. It specifies the process that CAs and Relying Parties (RPs) participating in the RPKI will need to follow to transition to a new (and probably cryptographically stronger) algorithm set. The process is expected to be completed over a timescale of months or years. Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration (parent migrates before children).
本文档描述了由于迁移到新的签名算法套件而在RPKI中执行密钥翻转的机制。它指定了CA和参与RPKI的依赖方（RPs）需要遵循的过程，以过渡到新的（可能在加密方面更强）算法集。该过程预计将在数月或数年的时间内完成。因此，没有规定紧急过渡。本文档中定义的转换过程仅支持自上而下的迁移（父迁移先于子迁移）。
A signature-algorithm suite encompasses both a signature algorithm (with a specified key size range) and a one-way hash algorithm. It is anticipated that the RPKI will require the adoption of updated key sizes and/or different algorithm suites over time. This document treats the adoption of a new hash algorithm while retaining the current signature algorithm as equivalent to an algorithm migration, and requires the CA to change its key. Migration to a new algorithm suite will be required in order to maintain an acceptable level of cryptographic security and protect the integrity of certificates, Certificate Revocation Lists (CRLs), and signed objects in the RPKI. All of the data structures in the RPKI explicitly identify the signature and hash algorithms being used. However, experience has demonstrated that the ability to represent algorithm IDs is not sufficient to enable migration to new algorithm suites (algorithm agility). One also must ensure that protocols, infrastructure elements, and operational procedures also accommodate the migration from one algorithm suite to another. Algorithm migration is expected to be very infrequent, and it will require the support of a "current" and "next" suite for a prolonged interval, probably several years.
签名算法套件包括签名算法（具有指定的密钥大小范围）和单向散列算法。预计RPKI将需要随着时间的推移采用更新的密钥大小和/或不同的算法套件。本文档将采用新的哈希算法，同时保留当前签名算法视为等效于算法迁移，并要求CA更改其密钥。需要迁移到新的算法套件，以保持可接受的加密安全级别，并保护RPKI中证书、证书吊销列表（CRL）和签名对象的完整性。RPKI中的所有数据结构都明确标识所使用的签名和哈希算法。然而，经验表明，表示算法ID的能力不足以支持迁移到新的算法套件（算法敏捷性）。还必须确保协议、基础设施元素和操作过程也能适应从一个算法套件到另一个算法套件的迁移。算法迁移预计将非常罕见，并且需要“当前”和“下一个”套件的支持，时间间隔很长，可能需要几年。
This document defines how entities in the RPKI execute a planned CA key rollover when the algorithm suite changes. The description covers actions by CAs, repository operators, and RPs. It describes the behavior required of both CAs and RPs to make such key changes work in the RPKI context, including how the RPKI repository system is used to support key rollover.
本文档定义了当算法套件更改时，RPKI中的实体如何执行计划的CA密钥滚动。本说明涵盖CAs、存储库操作员和RPs的操作。它描述了CAs和RPs在RPKI上下文中进行此类密钥更改所需的行为，包括如何使用RPKI存储库系统来支持密钥滚动。
This document does not specify any algorithm suite per se. The RPKI Certificate Policy (CP) [RFC6484] mandates the use of the algorithms defined in [RFC6485] by CAs and RPs. When an algorithm transition is initiated, [RFC6485] MUST be updated (as defined in Section 4.1 of this document) to redefine the required algorithms for compliant RPKI CAs and RPs under the CP. The CP will not change as a side effect of algorithm transition, and thus the policy OID in RPKI certificates will not change.
本文档本身未指定任何算法套件。RPKI证书策略（CP）[RFC6484]要求CAs和RPs使用[RFC6485]中定义的算法。启动算法转换时，必须更新[RFC6485]（如本文件第4.1节所定义），以重新定义CP下符合RPKI CA和RPs要求的算法。CP不会作为算法转换的副作用而改变，因此RPKI证书中的策略OID不会改变。
For each algorithm transition, an additional document (the algorithm transition timetable) MUST be published (as a BCP) to define the dates for each milestone defined in this document. It will define dates for the phase transitions consistent with the descriptions provided in Section 4. It also will describe how the RPKI community will measure the readiness of CAs and RPs to transition to each phase. CAs publish certificates, CRLs, and other signed objects under the new algorithm suite as the transition progresses. This provides visibility into the deployment of the new algorithm suite, enabling the community to evaluate deployment progress. The transition procedure allows CAs to remove old certificates, CRLs, and signed products after the twilight date, which provides the ability to observe and measure the withdrawal of the old algorithm suite. Thus, the phases defined in this document enable the community to evaluate the progress of the transition. The timetable document will also describe procedures to amend the timetable if problems arise in implementing later phases of the transition. It is RECOMMENDED that the timetable document be developed by representatives of the RPKI community, e.g., IANA, Internet Registries, and network operators.
对于每个算法转换，必须发布一份附加文件（算法转换时间表）（作为BCP），以定义本文件中定义的每个里程碑的日期。它将根据第4节中提供的描述定义相变日期。它还将描述RPKI社区将如何衡量CAs和RPs向每个阶段过渡的准备情况。随着转换的进行，CAs将在新算法套件下发布证书、CRL和其他签名对象。这提供了新算法套件部署的可视性，使社区能够评估部署进度。过渡过程允许CAs在黄昏日期后删除旧证书、CRL和签名产品，从而提供观察和测量旧算法套件退出的能力。因此，本文件中定义的阶段使社区能够评估过渡的进展情况。时间表文件还将说明在过渡后期实施过程中出现问题时修改时间表的程序。建议RPKI社区代表（如IANA、互联网注册中心和网络运营商）编制时间表文件。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "NOT RECOMMENDED" and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”、“不建议”和“可选”应按照[RFC2119]中所述进行解释。
This document assumes that the reader is familiar with the terms and concepts described in "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280], "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779], and "A Profile for Resource Certificate Repository Structure" [RFC6481]. Additional terms and conventions used in examples are provided below.
本文档假设读者熟悉“Internet X.509公钥基础设施证书和证书吊销列表（CRL）配置文件”[RFC5280]、“IP地址和AS标识符的X.509扩展”[RFC3779]和“资源证书存储库结构配置文件”[RFC6481]中描述的术语和概念。下面提供了示例中使用的其他术语和约定。
Algorithm migration: A planned transition from one signature and hash algorithm to a new signature and hash algorithm.
算法迁移：从一个签名和哈希算法到一个新的签名和哈希算法的计划转换。
Algorithm Suite A: The "current" algorithm suite used for hashing and signing; used in examples in this document.
算法套件A：用于哈希和签名的“当前”算法套件；在本文档的示例中使用。
Algorithm Suite B: The "next" algorithm suite used for hashing and signing; used in examples in this document.
算法套件B：用于哈希和签名的“下一个”算法套件；在本文档的示例中使用。
CA X: The CA that issued CA Y's certificate (i.e., CA Y's parent); used in examples in this document.
CA X：颁发CA Y证书的CA（即CA Y的父母）；在本文档的示例中使用。
CA Y: The non-leaf CA; used in examples in this document.
cay：非叶CA；在本文档的示例中使用。
CA Z: A CA that is a "child" of CA Y; used in examples in this document.
CA Z：是CA Y的“子”的CA；在本文档的示例中使用。
Correspond: Two certificates issued under different algorithm suites correspond to one another if they are issued to the same entity by the same CA and bind identical Internet Number Resources (INRs) to that entity. Two CRLs correspond if they are issued by the same CA and enumerate corresponding certificates. Two signed objects (other than manifests) correspond if they are verified using corresponding end-entity (EE) certificates and they contain the same encapsulated Context Info field. Two manifests correspond if they encompass corresponding certificates, Route Origination Authorizations (ROAs), CRLs, and other signed objects. (The term "equivalent" is used synonymously when referring to such RPKI signed products.)
对应：如果两个在不同算法套件下颁发的证书由同一CA颁发给同一实体，并且将相同的Internet号码资源（INR）绑定到该实体，则它们彼此对应。如果两个CRL由同一CA颁发，则它们对应，并枚举相应的证书。如果使用相应的终端实体（EE）证书对两个签名对象（清单除外）进行验证，并且它们包含相同的封装上下文信息字段，则两个签名对象（清单除外）将对应。如果两个清单包含相应的证书、路由发起授权（ROA）、CRL和其他签名对象，则两个清单对应。（当提及此类RPKI签名产品时，术语“等效物”是同义词。）
Leaf CA: A CA that issues only EE certificates.
叶CA：仅颁发EE证书的CA。
Non-Leaf CA: A CA that issues certificates to other CAs.
非叶CA：向其他CA颁发证书的CA。
PoP (proof of possession): Execution of a protocol that demonstrates to an issuer that a subject requesting a certificate possesses the private key corresponding to the public key in the certificate request submitted by the subject.
PoP（持有证明）：执行协议，向颁发者证明申请证书的主体拥有与主体提交的证书请求中的公钥对应的私钥。
ROA: Route Origination Authorization, as defined in [RFC6482].
ROA：路由发起授权，定义见[RFC6482]。
Signed product set (also called set or product set): A collection of certificates, signed objects, a CRL and a manifest that are associated by virtue of being verifiable under the same parent CA certificate
已签名产品集（也称为集或产品集）：证书、已签名对象、CRL和清单的集合，它们通过在同一父CA证书下可验证而关联
The "current" RPKI algorithm suite (Suite A) is defined in the RPKI CP document, by reference to [RFC6485]. When a migration of the RPKI algorithm suite is needed, the first step MUST be an update of [RFC6485] to define the new algorithm suite. The algorithm transition timeline document MUST also be published (as a BCP) to inform the community of the dates selected for milestones in the transition process, as described in Section 4.1.
参考[RFC6485]，RPKI CP文件中定义了“当前”RPKI算法套件（套件A）。当需要迁移RPKI算法套件时，第一步必须是更新[RFC6485]以定义新的算法套件。如第4.1节所述，还必须发布算法过渡时间表文件（作为BCP），以通知社区过渡过程中里程碑的选定日期。
CA Ready Algorithm B Date: After this date, all non-leaf CAs MUST be ready to process a request from a child CA to issue a certificate under the Algorithm Suite B. All CAs publishing an [RFC6490] Trust Anchor Locator (TAL) for Algorithm Suite A MUST also publish the correspondent TAL for Algorithm Suite B.
CA就绪算法B日期：在此日期之后，所有非叶CA必须准备好处理来自子CA的请求，以在算法套件B下颁发证书。所有为算法套件a发布[RFC6490]信任锚定位器（TAL）的CA也必须为算法套件B发布相应的TAL。
CA Go Algorithm B Date: After this date, all CAs MUST have reissued all their signed product sets under Algorithm Suite B.
CA Go算法B日期：在此日期之后，所有CA必须重新发布算法套件B下的所有签名产品集。
RP Ready Algorithm B Date: After this date, all RPs MUST be prepared to process signed material issued under Algorithm Suite B.
RP就绪算法B日期：在此日期之后，所有RP必须准备好处理算法套件B下发布的签名材料。
Twilight Date: After this date, a CA MAY cease issuing signed products under Algorithm Suite A. Also, after this date, an RP MAY cease to validate signed materials issued under Algorithm Suite A.
黄昏日期：在此日期之后，CA可以停止发布算法套件a下的签名产品。此外，在此日期之后，RP可以停止验证算法套件a下发布的签名材料。
End-Of-Life (EOL) Date: After this date, Algorithm Suite A MUST be deprecated using the process in Section 10, and all Algorithm Suite A TALs MUST be removed from their publication points.
寿命终止（EOL）日期：在此日期之后，必须使用第10节中的流程弃用算法套件A，并且必须从其发布点删除所有算法套件A TAL。
The migration process described in this document involves a series of steps that MUST be executed in chronological order by CAs and RPs. The only milestone at which both CAs and RPs take action at the same time is the EOL Date. Due to the decentralized nature of the RPKI infrastructure, it is expected that an algorithm transition will span several years.
本文档中描述的迁移过程涉及一系列步骤，CAs和RPs必须按时间顺序执行这些步骤。CAs和RPs同时采取行动的唯一里程碑是下线日期。由于RPKI基础设施的分散性，预计算法转换将持续数年。
In order to facilitate the transition, CAs will start issuing certificates using Algorithm B in a hierarchical, top-down fashion. In our example, CA Y will issue certificates using Algorithm Suite B only after CA X has started to do so (CA Y Ready Algorithm B Date > CA X Ready Algorithm B Date). This ordered transition avoids the issuance of "mixed" suite CA certificates, e.g., a CA certificate signed using Suite A that contains a key from Suite B. In the RPKI, a CA MUST NOT sign a CA certificate carrying a subject key that corresponds to an algorithm suite that differs from the one used to sign the certificate. (X.509 accommodates such mixed algorithm certificates, but this process avoids using that capability.) A non-top-down transition approach would require the use of such mixed-mode certificates and would lead to exponential growth of the RPKI repository. Also, because the RPKI CP mandates PoP for certificate requests, it is not possible for a CA to request a certificate for Algorithm Suite B until its parent CA supports that suite. (See Section 5 for more details.)
为了便于转换，CAs将开始以分层、自上而下的方式使用算法B颁发证书。在我们的示例中，只有在cax开始使用算法套件B（cay就绪算法B日期>cax就绪算法B日期）之后，cay才会使用算法套件B颁发证书。这种有序转换避免了“混合”套件CA证书的颁发，例如，使用套件a签署的CA证书包含套件B中的密钥。在RPKI中，CA不得签署带有与用于签署证书的算法套件不同的主题密钥的CA证书。（X.509可容纳此类混合算法证书，但此过程避免使用该功能。）非自顶向下转换方法将需要使用此类混合模式证书，并将导致RPKI存储库的指数增长。此外，由于RPKI CP强制PoP用于证书请求，CA不可能为算法套件B请求证书，直到其父CA支持该套件。（详见第5节。）
The algorithm agility model described here does not prohibit a CA from issuing an EE certificate with a subject public key from a different algorithm suite, if that certificate is not used to verify repository objects. This exception to the mixed algorithm suite certificate rule is allowed because an EE certificate that is not used to verify repository objects does not interfere with the ability of RPs to download and verify repository content. As noted above, every CA in the RPKI is required to perform a PoP check for the subject public key when issuing a certificate. In general, a subject cannot assume that a CA is capable of supporting a different algorithm. However, if the subject is closely affiliated with the CA, it is reasonable to assume that there are ways for the subject to know whether the CA can support a request to issue an EE certificate containing a specific, different public key algorithm. This document does not specify how a subject can determine whether a CA is capable of issuing a mixed suite EE certificate, because it anticipates that such certificates will be issued only in contexts where the subject and CA are sufficiently closely affiliated (for example, an ISP issuing certificates to devices that it manages).
这里描述的算法敏捷性模型并不禁止CA使用来自不同算法套件的主题公钥颁发EE证书，前提是该证书未用于验证存储库对象。允许混合算法套件证书规则的此例外情况，因为不用于验证存储库对象的EE证书不会干扰RPs下载和验证存储库内容的能力。如上所述，在颁发证书时，RPKI中的每个CA都需要对主题公钥执行PoP检查。通常，受试者不能假设CA能够支持不同的算法。然而，如果主体与CA密切相关，则可以合理地假设主体可以通过各种方式知道CA是否能够支持发布包含特定、不同公钥算法的EE证书的请求。本文档未规定主体如何确定CA是否能够颁发混合套件EE证书，因为它预计此类证书将仅在主体与CA关系密切的上下文中颁发（例如，ISP向其管理的设备颁发证书）。
The following figure gives an overview of the process:
下图概述了该过程：
Process for RPKI CAs:
RPKI CAs的流程：
Phase 0 Phase 1 Phase 2 Phase 4 Phase 0
--x--------x---------x-------------------x--------x---------
^ ^ ^ ^ ^
| | | | |
(1) (2) (3) (5) (6)
Phase 0 Phase 1 Phase 2 Phase 4 Phase 0
--x--------x---------x-------------------x--------x---------
^ ^ ^ ^ ^
| | | | |
(1) (2) (3) (5) (6)
Process for RPKI RPs:
RPKI RPs的流程：
Phase 0 Phase 3 Phase 4 Phase 0
-------------------------------x---------x--------x---------
^ ^ ^ ^
| | | |
(1) (4) (5) (6)
Phase 0 Phase 3 Phase 4 Phase 0
-------------------------------x---------x--------x---------
^ ^ ^ ^
| | | |
(1) (4) (5) (6)
(1) RPKI algorithm document is updated, and the algorithm transition timeline document is issued (2) CA Ready Algorithm B Date (3) CA Go Algorithm B Date (4) RP Ready Algorithm B Date (5) Twilight Date (6) End-Of-Life (EOL) Date
(1) 更新RPKI算法文档，并发布算法过渡时间线文档（2）CA就绪算法B日期（3）CA Go算法B日期（4）RP就绪算法B日期（5）黄昏日期（6）寿命结束（EOL）日期
Each of these milestones is discussed in the next section when each phase of the transition process is described.
下一节将在描述过渡过程的每个阶段时讨论这些里程碑。
Two situations have been identified that motivate pausing or rolling back the transition process. The first situation arises if the RPKI community is not ready to make the transition. For example, many CAs might not be prepared to issue signed products under Suite B, or many RPs might not be ready to process Suite B products. Under these circumstances, the timetable MUST be reissued, postponing the date for the phase in question and pushing back the dates for later phases. The other situation arises if, during the transition, serious concerns arise about the security of the Suite B algorithms. Such concerns would motivate terminating the transition and rolling back signed products, i.e., reverting to Suite A. In this case, the timetable MUST be republished, and the RPKI algorithm document MUST be superseded. The phase descriptions below allude to these two situations, as appropriate.
已经确定了两种情况，它们会促使过渡过程暂停或回滚。第一种情况是，如果RPKI社区尚未准备好进行过渡。例如，许多CA可能不准备发布套件B下的签名产品，或者许多RP可能不准备处理套件B产品。在这种情况下，必须重新发布时间表，推迟有关阶段的日期，推迟以后阶段的日期。另一种情况是，如果在过渡期间，对套件B算法的安全性产生严重的担忧。这种担忧将促使终止过渡和回滚已签署的产品，即恢复到套件A。在这种情况下，必须重新发布时间表，并且必须取代RPKI算法文档。下面的阶段描述酌情提及这两种情况。
Phase 0 is the steady-state phase of the process; throughout this phase, Algorithm Suite A is the only supported algorithm suite in the RPKI. Phase 0 is also the steady state for the RPKI.
阶段0是过程的稳态阶段；在整个阶段，算法套件A是RPKI中唯一受支持的算法套件。相位0也是RPKI的稳态。
During Phase 0, CAs X, Y, and Z are required to generate signed product sets using only Algorithm Suite A. Also, RPs are required to validate signed product sets issued using only Algorithm Suite A.
在阶段0期间，CAs X、Y和Z需要仅使用算法套件A生成签名产品集。此外，RPs需要验证仅使用算法套件A发布的签名产品集。
The following figure shows an example of the structure of signed objects in the repository, indicating the algorithm suites in use and showing the relationships between three CAs (X, Y, and Z) that form a certification chain. Vertical alignment in the figure indicates objects signed by the same CA using the same private key. The differences in horizontal indentation also represent the use of different publication points for objects signed by different CAs. The characters "|->" are used for visualization purposes for both the signing relationship and the publication point change. For example, the objects CA-Y-Certificate-Algorithm-Suite-A, CA-X-CRL-Algorithm-Suite-A, and CA-X-Signed-Objects-Algorithm-Suite-A are all signed using the private key corresponding to CA-X-Certificate-Algorithm-Suite-A and published at CA X's corresponding publication point.
下图显示了存储库中已签名对象的结构示例，指出了正在使用的算法套件，并显示了构成证书链的三个CA（X、Y和Z）之间的关系。图中的垂直对齐表示由相同CA使用相同私钥签名的对象。水平缩进的差异还表示对由不同CA签名的对象使用不同的发布点。字符“|->”用于签名关系和发布点更改的可视化目的。例如，对象CA-Y-Certificate-Algorithm-Suite-A、CA-X-CRL-Algorithm-Suite-A和CA-X-Signed-objects-Algorithm-Suite-A都使用与CA-X-Certificate-Algorithm-Suite-A相对应的私钥进行签名，并在CA-X的相应发布点发布。
CA-X-Certificate-Algorithm-Suite-A (Cert-XA)
|-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
|-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA)
|-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
|-> CA-Z-Signed-Objects-Algorithm-Suite-A
|-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
|-> CA-Y-Signed-Objects-Algorithm-Suite-A
|-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
|-> CA-X-Signed-Objects-Algorithm-Suite-A
CA-X-Certificate-Algorithm-Suite-A (Cert-XA)
|-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
|-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA)
|-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
|-> CA-Z-Signed-Objects-Algorithm-Suite-A
|-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
|-> CA-Y-Signed-Objects-Algorithm-Suite-A
|-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
|-> CA-X-Signed-Objects-Algorithm-Suite-A
Note: Cert-XA represents the certificate for CA X, which is signed using Algorithm Suite A.
注意：Cert XA代表CA X的证书，该证书使用算法套件A签名。
The first milestone initiates the migration process. It updates [RFC6485] with the following definitions for the RPKI:
第一个里程碑启动迁移过程。它使用以下RPKI定义更新[RFC6485]：
o Algorithm Suite A
o 算法套件A
o Algorithm Suite B
o 算法套件B
Additionally, the new algorithm transition timeline document MUST be published with the following information:
此外，发布新算法转换时间表文档时必须包含以下信息：
o CA Ready Algorithm B Date
o CA就绪算法B日期
o CA Go Algorithm B Date
o CA Go算法B日期
o RP Ready Algorithm B Date
o RP就绪算法B日期
o Twilight Date
o 黄昏日期
o EOL Date
o 下线日期
o Readiness metrics for CAs and RPs in each phase
o 各阶段CAs和RPs的准备就绪指标
Each date specified here is assumed to be at one minute after midnight, UTC. No finer granularity time specification is required or supported.
此处指定的每个日期假定为UTC午夜后一分钟。不需要或不支持更细粒度的时间规范。
Phase 1 starts at the CA Ready Algorithm B Date. During Phase 1, all non-leaf CAs MUST be ready to process a request from a child CA to issue or revoke a certificate using Algorithm Suite B. If it is determined that a substantial number of CAs are not ready, the algorithm transition timeline document MUST be reissued, as noted in Section 4.2. However, CAs that are capable of issuing Suite B certificates may continue to do so, if requested by their child CAs. As this phase does not require any RPs to process signed objects under Suite B, and since Suite B product sets SHOULD be stored at independent publication points, there is no adverse impact on RPs. If the Suite B algorithm is deemed unsuitable, the algorithm transition timeline and the algorithm specification documents MUST be replaced, and Algorithm Suite B MUST be deprecated using the process described in Section 10.
阶段1从CA就绪算法B日期开始。在阶段1期间，所有非叶CA必须准备好处理子CA使用算法套件B发出或撤销证书的请求。如果确定大量CA未准备好，则必须重新发布算法转换时间表文档，如第4.2节所述。但是，如果子CA请求，能够颁发套件B证书的CA可以继续这样做。由于此阶段不需要任何RPs来处理套件B下的签名对象，而且套件B产品集应存储在独立的发布点，因此对RPs没有不利影响。如果认为套件B算法不合适，则必须更换算法过渡时间线和算法规范文件，并且必须使用第10节中描述的流程弃用算法套件B。
Because the transition will happen using a hierarchical, top-down model, a child CA will be able to issue certificates using Algorithm Suite B only after its parent CA has issued its own. The RPKI provisioning protocol can identify if a parent CA is capable of issuing certificates using Algorithm Suite B and can identify the corresponding algorithm suite in each Certificate Signing Request (CSR; see Section 5). During much of this phase, the Suite B product tree will be incomplete, i.e., not all CAs will have issued products under Suite B. Thus, for production purposes, RPs MUST fetch and validate only Suite A products. Suite B products should be fetched and processed only for testing purposes.
由于转换将使用分层、自上而下的模型进行，因此子CA只有在其父CA发出自己的证书后，才能使用算法套件B发出证书。RPKI配置协议可以识别父CA是否能够使用算法套件B颁发证书，并且可以在每个证书签名请求中识别相应的算法套件（CSR；参见第5节）。在此阶段的大部分时间内，套件B产品树将不完整，即并非所有CA都已发布套件B下的产品。因此，出于生产目的，RPs必须仅获取和验证套件A产品。套件B产品的获取和处理应仅用于测试目的。
The following figure shows the status of repository entries for the three example CAs during this phase. Two distinct certificate chains are maintained, and CA Z has not yet requested any material using Algorithm Suite B.
下图显示了此阶段中三个示例CA的存储库条目的状态。维护两个不同的证书链，CA Z尚未使用算法套件B请求任何材料。
CA-X-Certificate-Algorithm-Suite-A (Cert-XA)
|-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
|-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA)
|-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
|-> CA-Z-Signed-Objects-Algorithm-Suite-A
|-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
|-> CA-Y-Signed-Objects-Algorithm-Suite-A
|-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
|-> CA-X-Signed-Objects-Algorithm-Suite-A
CA-X-Certificate-Algorithm-Suite-A (Cert-XA)
|-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
|-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA)
|-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
|-> CA-Z-Signed-Objects-Algorithm-Suite-A
|-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
|-> CA-Y-Signed-Objects-Algorithm-Suite-A
|-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
|-> CA-X-Signed-Objects-Algorithm-Suite-A
CA-X-Certificate-Algorithm-Suite-B (Cert-XB)
|-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB)
|-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB)
|-> CA-Y-Signed-Objects-Algorithm-Suite-B
|-> CA-X-CRL-Algorithm-Suite-B (CRL-XB)
|-> CA-X-Signed-Objects-Algorithm-Suite-B
CA-X-Certificate-Algorithm-Suite-B (Cert-XB)
|-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB)
|-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB)
|-> CA-Y-Signed-Objects-Algorithm-Suite-B
|-> CA-X-CRL-Algorithm-Suite-B (CRL-XB)
|-> CA-X-Signed-Objects-Algorithm-Suite-B
Phase 2 starts at the CA Go Algorithm B Date. At the start of this phase, each signed product set MUST be available using both Algorithm Suite A and Algorithm Suite B. Thus, prior to the start of this phase, every CA MUST ensure that there is a Suite B product corresponding to each Suite A product that the CA has issued. Throughout this phase, each CA MUST maintain this correspondence. During this phase, RPs MUST be prepared to validate sets issued using Algorithm Suite A and MAY be prepared to validate sets issued using the Algorithm Suite B.
阶段2从CA Go算法B日期开始。在本阶段开始时，必须使用算法套件A和算法套件B提供每个签名产品集。因此，在本阶段开始之前，每个CA必须确保有一个套件B产品对应于CA发布的每个套件A产品。在整个阶段中，每个CA必须保持这种对应关系。在此阶段，RPs必须准备好验证使用算法套件A发布的集合，并且可能准备好验证使用算法套件B发布的集合。
If it is determined that a substantial number of CAs are not ready, the algorithm transition timeline document MUST be reissued, as noted in Section 4.2. (Since the processing requirement for RPs here is a MAY, if RPs have problems with Suite B products, this does not require pushing back the Phase 2 milestone, but it does motivate delaying the start of Phase 3.) CAs that are capable of publishing products under Suite B MAY continue to do so. Phase 2, like Phase 1, does not require any RPs to process signed objects under Suite B. Also, Suite B products SHOULD be stored at independent publication points so that there is no adverse impact on RPs that are not prepared to process Suite B products. (See Section 9 for additional details.) If the Suite B algorithm is deemed unsuitable, the
如第4.2节所述，如果确定大量CA未准备就绪，则必须重新发布算法转换时间表文件。（由于此处RPs的处理要求是a，因此，如果RPs与套件B产品存在问题，则不需要推迟阶段2里程碑，但这确实会促使延迟阶段3的开始。）能够发布套件B下产品的CA可以继续这样做。第2阶段与第1阶段一样，不需要任何RPs来处理套件B下的签名对象。此外，套件B产品应存储在独立的发布点，以便不会对未准备好处理套件B产品的RPs产生不利影响。（更多详细信息，请参见第9节。）如果认为套件B算法不合适，则
algorithm transition timeline and the algorithm specification documents MUST be replaced, and Algorithm Suite B MUST be deprecated using the process described in Section 10.
必须更换算法转换时间表和算法规范文档，并且必须使用第10节中描述的流程弃用算法套件B。
It is RECOMMENDED that RPs that can process Algorithm Suite B fetch and validate Suite B products. RPs that are not ready to process Suite B products MUST continue to make use of Suite A products. An RP that elects to validate signed product sets using both Algorithm Suite A and Algorithm Suite B should expect the same results. If there are discrepancies when evaluating corresponding signed product sets, successful validation of either product set is acceptable. A detailed analysis of the validation of multiple instances of signed objects is included in Section 6.
建议能够处理算法套件B的RPs获取并验证套件B产品。尚未准备好处理套件B产品的RPs必须继续使用套件A产品。选择使用算法套件A和算法套件B验证签名产品集的RP应期望相同的结果。如果在评估相应的签名产品集时存在差异，则可接受成功验证任一产品集。第6节详细分析了签名对象的多个实例的验证。
The following figure shows the status of the repository entries for the three example CAs throughout this phase, where all signed objects are available using both algorithm suites.
下图显示了此阶段中三个示例CA的存储库条目的状态，其中所有已签名对象都可以使用这两个算法套件使用。
CA-X-Certificate-Algorithm-Suite-A (Cert-XA)
|-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
|-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA)
|-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
|-> CA-Z-Signed-Objects-Algorithm-Suite-A
|-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
|-> CA-Y-Signed-Objects-Algorithm-Suite-A
|-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
|-> CA-X-Signed-Objects-Algorithm-Suite-A
CA-X-Certificate-Algorithm-Suite-A (Cert-XA)
|-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
|-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA)
|-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
|-> CA-Z-Signed-Objects-Algorithm-Suite-A
|-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
|-> CA-Y-Signed-Objects-Algorithm-Suite-A
|-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
|-> CA-X-Signed-Objects-Algorithm-Suite-A
CA-X-Certificate-Algorithm-Suite-B (Cert-XB)
|-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB)
|-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZB)
|-> CA-Z-CRL-Algorithm-Suite-B (CRL-ZB)
|-> CA-Z-Signed-Objects-Algorithm-Suite-B
|-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB)
|-> CA-Y-Signed-Objects-Algorithm-Suite-B
|-> CA-X-CRL-Algorithm-Suite-B (CRL-XB)
|-> CA-X-Signed-Objects-Algorithm-Suite-B
CA-X-Certificate-Algorithm-Suite-B (Cert-XB)
|-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB)
|-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZB)
|-> CA-Z-CRL-Algorithm-Suite-B (CRL-ZB)
|-> CA-Z-Signed-Objects-Algorithm-Suite-B
|-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB)
|-> CA-Y-Signed-Objects-Algorithm-Suite-B
|-> CA-X-CRL-Algorithm-Suite-B (CRL-XB)
|-> CA-X-Signed-Objects-Algorithm-Suite-B
Phase 3 starts at the RP Ready Algorithm B Date. During this phase, all signed product sets are available using both algorithm suites, and all RPs MUST be able to validate them. (The correspondence between Suite A and Suite B products was required for Phase 2 and was maintained throughout that phase. The same requirements apply throughout this phase.) It is RECOMMENDED that, in preparation for Phase 4, RPs retrieve and process Suite B product sets first and
第3阶段从RP就绪算法B日期开始。在此阶段，所有已签名的产品集都可以使用这两个算法套件，并且所有RPs都必须能够验证它们。（第2阶段需要套件A和套件B产品之间的对应关系，并在该阶段中保持一致。相同的要求适用于整个阶段。）建议在准备第4阶段时，RPs首先检索和处理套件B产品集，然后
treat them as the preferred product sets for validation throughout this phase. Thus, an RP SHOULD try to validate the sets of signed products retrieved from the Algorithm Suite B repository first.
将其视为整个阶段验证的首选产品集。因此，RP应该首先尝试验证从算法套件B存储库检索的签名产品集。
If a substantial number of RPs are unable to process product sets signed with Suite B, the algorithm transition timeline document MUST be reissued, pushing back the date for this and later milestones, as discussed in Section 4.2. Since the Suite B products SHOULD be published at distinct publication points, RPs that cannot process Suite B products can be expected to revert to the Suite A products that still exist. If the Suite B algorithm is deemed unsuitable, the algorithm transition timeline and the algorithm specification documents MUST be replaced and Algorithm Suite B MUST be deprecated using the process described in Section 10.
如果大量RPs无法处理与套件B签署的产品集，则必须重新发布算法转换时间线文档，将此里程碑和以后里程碑的日期往后推，如第4.2节所述。由于套件B产品应在不同的发布点发布，因此无法处理套件B产品的RPs可能会恢复为仍然存在的套件A产品。如果认为套件B算法不合适，则必须更换算法过渡时间线和算法规范文件，并且必须使用第10节中描述的流程弃用算法套件B。
There are no changes to the CA behavior throughout this phase.
在整个阶段中，CA行为没有变化。
Phase 4 starts at the Twilight Date. At that date, Algorithm A is labeled as "old" and the Algorithm B is labeled as "current".
第四阶段从黄昏之日开始。在该日期，算法A标记为“旧”，算法B标记为“当前”。
During this phase, all signed product sets MUST be issued using Algorithm Suite B and MAY be issued using Algorithm Suite A. All signed products sets issued using Suite B MUST be published at their corresponding publication points. Signed products sets issued using Suite A might not be available at their corresponding publication points. Every RP MUST validate signed product sets using Suite B. RPs MAY validate signed product sets using Suite A. However, RPs SHOULD NOT assume that the collection of Suite A product sets is complete. Thus, RPs SHOULD make use of only Suite B products sets. (See Section 6 for further details.)
在此阶段，所有签名产品集必须使用算法套件B发布，也可以使用算法套件A发布。使用套件B发布的所有签名产品集必须在其相应的发布点发布。使用套件A发布的签名产品集在其相应的发布点可能不可用。每个RP必须使用套件B验证已签名的产品集。RPs可以使用套件A验证已签名的产品集。但是，RPs不应假设套件A产品集的集合已完成。因此，RPs应仅使用套件B产品集。（详见第6节。）
If it is determined that many RPs are not capable of processing the new algorithm suite, the algorithm transition timeline document MUST be reissued, pushing back the date for this and the next milestone. The document MUST require the CA not to remove Suite A product sets if this phase is delayed. If Algorithm Suite B is deemed unsuitable, the algorithm transition timeline and the algorithm specification documents MUST be replaced, Algorithm Suite B MUST be deprecated using the process described in Section 10, and CAs MUST NOT remove Suite A product sets. At this stage, RPs are still capable of processing Suite A signed products, so the RPKI is still viable.
如果确定许多RPs无法处理新的算法套件，则必须重新发布算法转换时间线文档，将此里程碑和下一里程碑的日期往后推。如果此阶段延迟，文档必须要求CA不要删除套件A产品集。如果认为算法套件B不合适，则必须更换算法转换时间表和算法规范文件，必须使用第10节中描述的流程弃用算法套件B，并且CAs不得删除套件A产品集。在这个阶段，RPs仍然能够处理套件A签名的产品，因此RPKI仍然是可行的。
The following figure describes a possible status for the repositories of the example CAs.
下图描述了示例CA存储库的可能状态。
CA-X-Certificate-Algorithm-Suite-A (Cert-XA)
|-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
|-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
|-> CA-Y-Signed-Objects-Algorithm-Suite-A
|-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
|-> CA-X-Signed-Objects-Algorithm-Suite-A
CA-X-Certificate-Algorithm-Suite-A (Cert-XA)
|-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
|-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
|-> CA-Y-Signed-Objects-Algorithm-Suite-A
|-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
|-> CA-X-Signed-Objects-Algorithm-Suite-A
CA-X-Certificate-Algorithm-Suite-B (Cert-XB)
|-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB)
|-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZB)
|-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZB)
|-> CA-Z-Signed-Objects-Algorithm-Suite-B
|-> CA-Y-CRL-Algorithm-Suite-A (CRL-YB)
|-> CA-Y-Signed-Objects-Algorithm-Suite-B
|-> CA-X-CRL-Algorithm-Suite-A (CRL-XB)
|-> CA-X-Signed-Objects-Algorithm-Suite-B
CA-X-Certificate-Algorithm-Suite-B (Cert-XB)
|-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB)
|-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZB)
|-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZB)
|-> CA-Z-Signed-Objects-Algorithm-Suite-B
|-> CA-Y-CRL-Algorithm-Suite-A (CRL-YB)
|-> CA-Y-Signed-Objects-Algorithm-Suite-B
|-> CA-X-CRL-Algorithm-Suite-A (CRL-XB)
|-> CA-X-Signed-Objects-Algorithm-Suite-B
The EOL Date triggers the return to Phase 0 (steady state). At this point, the old algorithm suite, Algorithm Suite A, MUST be deprecated using the process described in Section 10.
下线日期触发返回阶段0（稳定状态）。此时，必须使用第10节中描述的过程弃用旧的算法套件，即算法套件A。
This phase closes the loop, as the new algorithm suite (Algorithm Suite B) is now the only required algorithm suite in RPKI. From this point forward, this suite is referred to as Algorithm Suite A.
这个阶段结束了循环，因为新的算法套件（算法套件B）现在是RPKI中唯一需要的算法套件。从这一点开始，这个套件被称为算法套件A。
If it is determined that many RPs are not capable of processing the new algorithm suite, the algorithm transition timeline document MUST be reissued, pushing back the date for this milestone.
如果确定许多RP无法处理新的算法套件，则必须重新发布算法转换时间线文档，将此里程碑的日期往后推。
The migration described in this document is a top-down process where two synchronization issues need to be solved between child and parent CAs:
本文档中描述的迁移是一个自上而下的过程，其中需要解决子CA和父CA之间的两个同步问题：
o A child CA needs to identify which algorithm suites are supported by its parent CA.
o 子CA需要确定其父CA支持哪些算法套件。
o A child CA needs to signal which algorithm suite should be used by its parent CA to sign a CSR.
o 子CA需要通知其父CA应该使用哪个算法套件来签署CSR。
The RPKI provisioning protocol [RFC6492] supports multiple algorithms suites by implementing different resource classes for each suite. Several different resource classes also may use the same algorithm suite for different resource sets.
RPKI配置协议[RFC6492]通过为每个套件实现不同的资源类，支持多个算法套件。几个不同的资源类也可以对不同的资源集使用相同的算法套件。
A child CA that wants to identify which algorithm suites are supported by its parent CA MUST perform the following tasks:
要确定其父CA支持哪些算法套件的子CA必须执行以下任务：
1. Establish a provisioning protocol session with its parent CA.
1. 与其父CA建立配置协议会话。
2. Perform a "list" command as described in Section 3.3.1 of [RFC6492].
2. 执行[RFC6492]第3.3.1节所述的“列表”命令。
3. From the Payload in the "list response" resource class, extract the "issuer's certificate" for each class. The algorithm suite for each class will match the algorithm suite used to issue the corresponding "issuer's certificate" (as specified in the SubjectPublicKeyInfo field of that certificate).
3. 从“列表响应”资源类中的有效负载中，提取每个类的“颁发者证书”。每个类的算法套件将与用于颁发相应“颁发者证书”的算法套件相匹配（如该证书的SubjectPublicKeyInfo字段中所指定）。
A child CA that wants to specify an algorithm suite to its parent CA (e.g., in a certificate request) MUST perform the following tasks:
希望为其父CA指定算法套件的子CA（例如，在证书请求中）必须执行以下任务：
1. Perform the tasks described above to identify the algorithm suites supported by its parent CA and the resource class corresponding to each suite.
1. 执行上述任务，以确定其父CA支持的算法套件以及对应于每个套件的资源类。
2. Identify the corresponding resource class in the appropriate provisioning protocol command (e.g., "issue" or "revoke").
2. 在适当的配置协议命令中标识相应的资源类（例如，“发布”或“撤销”）。
Upon receipt of a certificate request from a child CA, a parent CA will verify the PoP of the private key. If a child CA requests the issuing of a certificate using an algorithm suite that does not match a resource class, the PoP validation will fail and the request will not be performed.
在收到来自子CA的证书请求后，父CA将验证私钥的PoP。如果子CA使用与资源类不匹配的算法套件请求颁发证书，PoP验证将失败，请求将不会执行。
During Phases 1, 2, 3, and 4, two algorithm suites will be valid simultaneously in RPKI. In this section, we describe the RP behavior when validating corresponding signed products using different algorithm suites.
在阶段1、2、3和4期间，两个算法套件将在RPKI中同时有效。在本节中，我们将描述使用不同算法套件验证相应签名产品时的RP行为。
During Phase 1, two corresponding instances MAY be available for each signed product, one signed under Algorithm Suite A and one under Algorithm Suite B. As noted in Section 4.4, in this phase there is a preference for Suite A product sets. All products are available under Suite A, while only some products may be available under Suite B. For production purposes, an RP MAY fetch and validate only Suite A products. Suite B products SHOULD be fetched and validated only for test purposes. When product sets exist under both suites, they should yield equivalent results, to facilitate testing. (It is not possible to directly compare Suite A and Suite B product sets, because certificates, CRLs, and manifests will appear syntactically
在第1阶段，每个签名产品可能有两个对应的实例，一个在算法套件A下签名，另一个在算法套件B下签名。如第4.4节所述，在该阶段，首选套件A产品集。所有产品都在套件A下可用，而套件B下可能只有部分产品可用。出于生产目的，RP可能只获取和验证套件A产品。套件B产品的获取和验证应仅用于测试目的。当两个套件下都存在产品集时，它们应产生相同的结果，以便于测试。（无法直接比较套件A和套件B产品集，因为证书、CRL和清单将按语法显示。）
different. However, the output of the process, i.e., the ROA payloads -- Autonomous System number and address prefix data -- SHOULD match, modulo timing issues.)
不同的然而，进程的输出，即ROA有效负载（自治系统号和地址前缀数据）应该匹配，模定时问题。）
During Phases 2 and 3 of this process, two corresponding instances of all signed products MUST be available to RPs. As noted in Section 4.5, it is RECOMMENDED that Suite B capable RPs fetch and validate Suite B products sets during Phase 2. If an RP encounters validation problems with the Suite B products, it SHOULD revert to using Suite A products. RPs that are Suite B capable MAY fetch both product sets and compare the results (e.g., ROA outputs) for testing.
在此过程的第2和第3阶段中，RPs必须可以使用所有已签名产品的两个对应实例。如第4.5节所述，建议支持套件B的RPs在第2阶段获取并验证套件B产品集。如果RP在套件B产品中遇到验证问题，则应恢复使用套件A产品。支持套件B的RPs可以获取两个产品集，并比较测试结果（例如ROA输出）。
In Phase 3, all RPs MUST be Suite B capable and MUST fetch Suite B product sets. If an RP encounters problems with Suite B product sets, it can revert to Suite A products. RPs encountering such problems SHOULD contact the relevant repository maintainers (e.g., using the mechanism defined in [RFC6493] to report problems.)
在第3阶段，所有RPs必须具有套件B功能，并且必须获取套件B产品集。如果RP在套件B产品集中遇到问题，它可以恢复为套件A产品。遇到此类问题的RPs应联系相关的存储库维护人员（例如，使用[RFC6493]中定义的机制来报告问题。）
During Phase 4, only Suite B product sets are required to be present for all RPKI entities, as per Section 4.7. Thus, RPs SHOULD retrieve and validate only these product sets. Retrieval of Suite A products sets may yield an incomplete set of signed products and is NOT RECOMMENDED.
在第4阶段，根据第4.7节，所有RPKI实体只需提供套件B产品集。因此，RPs应该只检索和验证这些产品集。检索套件A产品集可能会产生一组不完整的签名产品，因此不建议这样做。
The algorithm migration process mandates the maintenance of two parallel but equivalent certification hierarchies during Phases 2 and 3 of the process. During these phases, a CA MUST revoke and request revocation of certificates consistently under both algorithm suites. When not performing a key rollover operation (as described in Section 8), a CA requesting the revocation of its certificate during these two phases MUST perform that request for both algorithm suites (A and B). A non-leaf CA SHOULD NOT verify that its child CAs comply with this requirement. Note that a CA MUST request revocation of its certificate relative to a specific algorithm suite using the mechanism described in Section 5
算法迁移过程要求在过程的第2和第3阶段维护两个并行但等效的证书层次结构。在这些阶段中，CA必须在两个算法套件下一致地撤销和请求撤销证书。当不执行密钥翻转操作（如第8节所述）时，在这两个阶段请求撤销其证书的CA必须对两个算法套件（a和B）执行该请求。非叶CA不应验证其子CA是否符合此要求。请注意，CA必须使用第5节中描述的机制请求撤销其相对于特定算法套件的证书
During Phase 1, a CA that revokes a certificate under Suite A SHOULD revoke the corresponding certificate under Suite B if that certificate exists. During Phase 4, a CA that revokes a certificate under Suite B SHOULD revoke the corresponding certificate under Suite A if that certificate exists.
在阶段1期间，撤销套件a下的证书的CA应撤销套件B下的相应证书（如果该证书存在）。在阶段4期间，撤销套件B下的证书的CA应撤销套件a下的相应证书（如果该证书存在）。
During Phase 1, a CA may revoke certificates under Suite B without revoking them under Suite A, since the Suite B products are for test purposes. During Phase 4, a CA may revoke certificates issued under Suite A without revoking them under Suite B, since Suite A products are being deprecated.
在阶段1期间，CA可以撤销套件B下的证书，而不撤销套件a下的证书，因为套件B产品用于测试目的。在第4阶段，CA可以撤销在套件a下颁发的证书，而不撤销在套件B下颁发的证书，因为套件a产品已被弃用。
Key rollover (without algorithm changes) is effected independently for each algorithm suite and MUST follow the process described in [RFC6489].
密钥翻转（无算法更改）对每个算法套件都独立生效，并且必须遵循[RFC6489]中描述的过程。
The two parallel hierarchies that will exist during the transition process SHOULD have independent publications points. The repository structures for each algorithm suite are described in [RFC6481].
过渡过程中存在的两个并行层次结构应该具有独立的发布点。[RFC6481]中描述了每个算法套件的存储库结构。
To deprecate an algorithm suite, the following process MUST be executed by every CA in the RPKI:
要弃用算法套件，RPKI中的每个CA都必须执行以下过程：
1. Each CA MUST cease issuing certificates under the suite. This means that any request for a CA certificate from a child will be rejected, e.g., sending an "error_response" message with error code "request - no such resource class", as defined in [RFC6492].
1. 每个CA必须停止颁发套件下的证书。这意味着任何来自子级的CA证书请求都将被拒绝，例如，按照[RFC6492]中的定义，发送错误代码为“请求-无此类资源类”的“错误\u响应”消息。
2. Each CA MUST cease generating signed products, except the CRL and manifest, under the deprecated algorithm suite.
2. 每个CA必须停止在不推荐的算法套件下生成已签名的产品（CRL和清单除外）。
3. Each CA MUST revoke the EE certificates for all signed products that it has issued under the deprecated algorithm suite. The CA SHOULD delete these products from its publication point to avoid burdening RPs with the need to download and process these products.
3. 每个CA必须撤销其在不推荐的算法套件下发布的所有已签名产品的EE证书。CA应从其发布点删除这些产品，以避免RPs因需要下载和处理这些产品而负担沉重。
4. Each CA MUST revoke all CA certificates that it has issued under the deprecated algorithm suite.
4. 每个CA必须吊销它在不推荐的算法套件下颁发的所有CA证书。
5. Each CA SHOULD remove all CA certificates that it has issued under the deprecated algorithm suite.
5. 每个CA都应该删除它在不推荐的算法套件下颁发的所有CA证书。
6. Each CA that publishes a TAL under the deprecated algorithm suite MUST removed it from the TAL's publication point.
6. 在不推荐的算法套件下发布TAL的每个CA必须将其从TAL的发布点删除。
7. Each CA SHOULD continue to maintain the publication point for the deprecated algorithm suite at least until the CRL nextUpdate. This publication point MUST contain only the CRL and a manifest for that publication point. This behavior provides a window in which RPs may be able to become aware of the revoked status of the signed products that have been deleted.
7. 每个CA应至少在CRL nextUpdate之前继续维护不推荐的算法套件的发布点。此发布点必须仅包含该发布点的CRL和清单。此行为提供了一个窗口，在该窗口中，RPs可以了解已删除的已签名产品的吊销状态。
8. Each RP MUST remove any TALs that is has published under the deprecated algorithm suite.
8. 每个RP必须删除在不推荐的算法套件下发布的任何TAL。
CAs in the RPKI hierarchy may become aware of the deprecation of the algorithm suite at different times and may execute the procedure above asynchronously relative to one another. Thus, for example, a CA may request revocation of its CA certificate, only to learn that the certificate has already been revoked by the issuing CA. The revocation of a CA certificate makes the CRL and manifest issued under it incapable of validation. The asynchronous execution of this procedure likely will result in transient "inconsistencies" among the publication points associated with the deprecated algorithm suite. However, these inconsistencies should yield "fail-safe" results, i.e., the objects signed under the deprecated suite should be rejected by RPs.
RPKI层次结构中的CA可能会在不同时间意识到算法套件的弃用，并且可能会相对彼此异步执行上述过程。因此，例如，CA可能会请求撤销其CA证书，但却发现证书已被颁发CA撤销。CA证书的撤销会使根据其颁发的CRL和清单无法验证。此过程的异步执行可能会导致与不推荐的算法套件相关联的发布点之间出现短暂的“不一致”。但是，这些不一致应该会产生“故障安全”结果，即RPs应该拒绝在不推荐的套件下签名的对象。
An algorithm transition in RPKI should be a very infrequent event, and it requires wide community consensus. The events that may lead to an algorithm transition may be related to a weakness of the cryptographic strength of the algorithm suite in use by RPKI, which is normal to happen over time. The procedures described in this document mean that it will take years to complete an algorithm transition. During that time, the RPKI system will be vulnerable to any cryptographic weakness that may have triggered this procedure (e.g., a downgrade attack).
RPKI中的算法转换应该是非常罕见的事件，并且需要广泛的社区共识。可能导致算法转换的事件可能与RPKI使用的算法套件的加密强度不足有关，这是随时间推移而发生的正常现象。本文件中描述的程序意味着完成算法转换需要几年时间。在此期间，RPKI系统将容易受到触发此过程的任何加密漏洞的攻击（例如降级攻击）。
This document does not describe an emergency mechanism for algorithm migration. Due to the distributed nature of RPKI and the very large number of CAs and RPs, the authors do not believe it is feasible to effect an emergency algorithm migration procedure.
本文档不描述算法迁移的紧急机制。由于RPKI的分布性质以及CA和RPs的数量非常大，作者认为实施紧急算法迁移过程是不可行的。
If a CA does not complete its migration to the new algorithm suite as described in this document (after the EOL of the "old" algorithm suite), its signed product set will no longer be valid. Consequently, the RPKI may, at the end of Phase 4, have a smaller number of valid signed products than before starting the process. Conversely, an RP that does not follow this process will lose the ability to validate signed products issued under the new algorithm
如果CA没有按照本文档所述完成到新算法套件的迁移（在“旧”算法套件的下线之后），其签名产品集将不再有效。因此，在第4阶段结束时，RPKI的有效签名产品数量可能比流程开始前少。相反，不遵循此流程的RP将失去验证根据新算法发布的签名产品的能力
suite. The resulting incomplete view of routing information from the RPKI (as a result of a failure by CAs or RPs to complete the transition) could degrade routing in the public Internet.
一套由此产生的来自RPKI的路由信息的不完整视图（由于CAs或RPs未能完成转换）可能会降低公共Internet中的路由。
The authors would like to acknowledge the work of the SIDR working group co-chairs (Sandra Murphy, Chris Morrow, and Alexey Melnikov) as well as the contributions given by Geoff Huston, Arturo Servin, Brian Weis, Terry Manderson, Brian Dickson, David Black, and Danny McPherson.
作者要感谢SIDR工作组联合主席（桑德拉·墨菲、克里斯·莫罗和阿列克谢·梅尔尼科夫）的工作以及杰夫·休斯顿、阿图罗·塞文、布赖恩·维斯、特里·曼德森、布赖恩·迪克森、大卫·布莱克和丹尼·麦克弗森所作的贡献。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC3779]Lynn，C.，Kent，S.，和K.Seo，“IP地址和AS标识符的X.509扩展”，RFC 3779，2004年6月。
[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, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012.
[RFC6481]Huston，G.，Loomans，R.，和G.Michaelson，“资源证书存储库结构的配置文件”，RFC 64812012年2月。
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.
[RFC6482]Lepinski，M.，Kent，S.，和D.Kong，“路线原产地授权（ROA）的配置文件”，RFC 64822012年2月。
[RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)", BCP 173, RFC 6484, February 2012.
[RFC6484]Kent，S.，Kong，D.，Seo，K.，和R.Watro，“资源公钥基础设施（RPKI）的证书政策（CP）”，BCP 173，RFC 6484，2012年2月。
[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)", RFC 6485, February 2012.
[RFC6485]Huston，G.“用于资源公钥基础设施（RPKI）的算法和密钥大小的配置文件”，RFC 6485，2012年2月。
[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", BCP 174, RFC 6489, February 2012.
[RFC6489]Huston，G.，Michaelson，G.，和S.Kent，“资源公钥基础设施（RPKI）中的证书颁发机构（CA）密钥滚动”，BCP 174，RFC 6489，2012年2月。
[RFC6490] Huston, G., Weiler, S., Michaelson, G., and S. Kent, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", RFC 6490, February 2012.
[RFC6490]Huston，G.，Weiler，S.，Michaelson，G.，和S.Kent，“资源公钥基础设施（RPKI）信任锚定位器”，RFC 64902012年2月。
[RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A Protocol for Provisioning Resource Certificates", RFC 6492, February 2012.
[RFC6492]Huston，G.，Loomans，R.，Ellacott，B.，和R.Austein，“资源证书配置协议”，RFC 64922012年2月。
[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, February 2012.
[RFC6493]布什，R.，“资源公钥基础设施（RPKI）捉鬼记录”，RFC6493，2012年2月。
Authors' Addresses
作者地址
Roque Gagliano Cisco Systems Avenue des Uttins 5 Rolle 1180 Switzerland
Roque Gagliano Cisco Systems Avenue des Uttins 5 Rolle 1180瑞士
EMail: rogaglia@cisco.com
EMail: rogaglia@cisco.com
Stephen Kent BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA
Stephen Kent BBN Technologies美国马萨诸塞州剑桥莫尔顿街10号，邮编02138
EMail: kent@bbn.com
EMail: kent@bbn.com
Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA
Sean Turner IECA，Inc.美国弗吉尼亚州费尔法克斯市努特利街3057号106室，邮编22031
EMail: turners@ieca.com
EMail: turners@ieca.com