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).
本文件规定了参与资源公钥基础设施（RPKI）的认证机构（CA）和依赖方（RP）在过渡到新的（可能在密码学上更强大的）算法集时需要遵循的流程。这一过程预计将在数年内完成。因此，没有规定紧急过渡。本文件中定义的过渡程序仅支持自上而下的迁移（父节点先于子节点迁移）。
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
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 之间会对这些事件进行协调。在紧急金钥滚转中，旧证书会被废止，并签发带有新金钥的新证书。在 RPKI 中执行密钥翻转（计划中或紧急情况下），同时保持相同算法套件的机制见 [RFC6489]。
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 中执行密钥展期的机制。它规定了参与 RPKI 的 CA 和依赖方 (RP) 在过渡到新算法集（可能在密码学上更强）时需要遵循的流程。该过程预计在数月或数年内完成。因此，没有规定紧急过渡。本文件中定义的过渡程序仅支持自上而下的迁移（父节点先于子节点迁移）。
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 密钥展期。描述包括 CA、存储库操作员和 RP 的操作。它描述了 CA 和 RP 在 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] 规定 CA 和 RP 必须使用 [RFC6485] 中定义的算法。当算法过渡开始时，[RFC6485] 必须更新（如本文档第 4.1 节所定义），以重新定义符合 CP 的 RPKI CA 和 RP 所需的算法。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 社区将如何衡量 CA 和 RP 过渡到每个阶段的准备情况。随着过渡的进行，CA 会根据新算法套件发布证书、CRL 和其他签名对象。这为新算法套件的部署提供了可见性，使社区能够评估部署进度。过渡程序允许 CA 在黄昏日后删除旧证书、证书废止列表和签名产品，这就提供了观察和衡量旧算法套件退出情况的能力。因此，本文件中定义的阶段使社区能够评估过渡的进展情况。时间表文件还将描述在实施过渡的后期阶段出现问题时修改时间表的程序。建议时间表文件由 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].
本文档中的关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、"NOT RECOMMENDED "和 "OPTIONAL "应按照 [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.
本文档假定读者已熟悉 "互联网 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）；在本文档的示例中使用。
CA Y: The non-leaf CA; used in examples in this document.
CA Y：非叶 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 向同一实体签发，并与该实体绑定相同的互联网号码资源 (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：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 和清单的集合，这些证书、已签名对象、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.
当前 "RPKI 算法套件（套件 A）在 RPKI CP 文档中参照 [RFC6485] 进行定义。当需要迁移 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 Ready Algorithm B Date（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 Algorithm 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.
黄昏日期：此外，在此日期之后，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) 日期：在此日期之后，算法套件 A 必须按照第 10 节中的流程报废，所有算法套件 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.
本文档中描述的迁移过程涉及一系列步骤，必须由 CA 和 RP 按时间顺序执行。CA 和 RP 同时采取行动的唯一里程碑是 EOL 日期。由于 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.)
为便于过渡，CA 将以分层、自上而下的方式开始使用算法 B 签发证书。在我们的例子中，CA Y 将在 CA X 开始使用算法套件 B 签发证书后才使用算法套件 B 签发证书（CA Y 准备好算法 B 日期 > CA X 准备好算法 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 证书，如果该证书不用于验证版本库对象的话。混合算法套件证书规则的这一例外是允许的，因为不用于验证版本库对象的电子环境证书不会干扰注册中心下载和验证版本库内容的能力。如上所述，RPKI 要求每个 CA 在签发证书时对主体公开密钥进行 PoP 检查。一般来说，主体不能假定 CA 能够支持不同的算法。然而，如果主体与 CA 关系密切，则有理由假定主体有办法知道 CA 是否能支持签发包含特定、不同公开密钥算法的电子环境证书的请求。本文件没有说明主体如何确定 CA 是否有能力签发混合套件电子环境证书，因为本文件预计只有在主体和 CA 有足够密切联系的情况下（例如，ISP 向其管理的设备签发证书）才会签发此类证书。
The following figure gives an overview of the process:
下图为流程概览：
Process for RPKI CAs:
RPKI CA 的流程：
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 RP 的流程：
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 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
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 组算法的安全性产生了严重的担忧。在这种情况下，时间表必须重新发布，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 阶段，CA X、Y 和 Z 必须仅使用算法套件 A 生成签名产品集，RP 也必须验证仅使用算法套件 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
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 Additionally, the new algorithm transition timeline document MUST be published with the following information:
o 算法套件 B 此外，新算法过渡时间表文件必须包含以下信息：
o CA Ready Algorithm B Date
o CA 就绪算法 B 日期
o CA Go Algorithm B Date
o CA 围棋算法 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 各阶段 CA 和 RP 的准备度量标准
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 Ready Algorithm B Date 开始。在第一阶段期间，所有非叶子 CA 必须准备就绪，以处理子 CA 使用算法套件 B 签发或撤销证书的请求。如果确定有相当数量的 CA 尚未准备就绪，则必须重新发布算法过渡时间表文件，如第 4.2 节所述。但是，如果子 CA 提出要求，有能力签发 B 组证书的 CA 可以继续签发。由于本阶段不要求任何 RP 处理 B 组套下的签名对象，而且 B 组套产品集应存储在独立的发布点，因此不会对 RP 产生不利影响。如果组套B算法被认为不合适，算法过渡时间表和算法规范文档必须被替换，并且算法组套B必须使用第10节中描述的流程被废弃。
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 下的产品。套件 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-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.
第二阶段从 CA Go Algorithm B Date 开始。因此，在此阶段开始之前，每个 CA 必须确保有一个套件 B 产品与该 CA 发行的每个套件 A 产品相对应。在整个阶段中，每个 CA 必须保持这种对应关系。在此阶段，RP 必须准备好验证使用算法套件 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 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.
如果确定有相当数量的 CA 还没有准备好，则必须重新发布算法过渡时间表文件，如第 4.2 节所述（由于这里对 RP 的处理要求是 MAY，如果 RP 在套件 B 产品上有问题，这并不要求推后第二阶段的里程碑，但这确实会促使推迟第三阶段的开始）。有能力发布 B 套件产品的 CA 可以继续这样做。第二阶段与第一阶段一样，不要求任何 RP 处理 B 组套下的签名对象。此外，B 组套产品应存储在独立的发布点，这样就不会对不准备处理 B 组套产品的 RP 造成不利影响。(如果组套 B 算法被认为不合适，则必须更换算法过渡时间表和算法规范文档，并且必须使用第 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 的 RP 获取并验证套件 B 产品。尚未准备好处理套件 B 产品的 RP 必须继续使用套件 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-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 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.
第 3 阶段从 RP 准备就绪算法 B 日期开始。在此阶段，所有签名产品集都可使用两种算法套件，所有 RP 必须能够验证这些产品。(套件 A 和套件 B 产品之间的对应关系是第 2 阶段的要求，并在整个阶段保持不变。同样的要求也适用于本阶段）。建议在为第 4 阶段做准备时，RP 首先检索和处理套件 B 产品集，并在整个阶段将其作为首选产品集进行验证。因此，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.
如果大量的 RP 无法处理用套件 B 签名的产品集，则必须重新发布算法过渡时间表文件，推后此里程碑和以后里程碑的日期，详见第 4.2 节。由于 B 套件产品应在不同的发布点发布，因此无法处理 B 套件产品的 RP 可能会重新使用仍然存在的 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".
第 4 阶段从黄昏日开始。在这一天，算法 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 发布。使用套件 A 签发的签名产品集可能无法在相应的发布点发布。每个 RP 必须使用套件 B 验证签名产品集。RP 可以使用套件 A 验证签名产品集。因此，RP 只应使用套件 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.
如果确定许多 RP 没有能力处理新的算法套件，则必须重新发布算法过渡时间表文件，推后本阶段和下一个里程碑的日期。该文件必须要求 CA 在这一阶段被推迟的情况下不删除套件 A 产品集。如果算法套件 B 被认为不合适，算法过渡时间表和算法规范文件必须被替换，算法套件 B 必须使用第 10 节中描述的流程被废弃，并且 CA 不得删除套件 A 产品集。在此阶段，RP 仍能处理套件 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-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.
EOL 日期触发返回第 0 阶段（稳定状态）。此时，旧算法套件（算法套件 A）必须使用第 10 节中描述的流程报废。
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 different. However, the output of the process, i.e., the ROA payloads -- Autonomous System number and address prefix data -- SHOULD match, modulo timing issues.)
如第 4.4 节所述，在此阶段，优先选择套件 A 产品集。出于生产目的，RP 可以只获取和验证 A 组产品。套件 B 产品应仅用于测试目的。当两个套件下都有产品集时，它们应产生相同的结果，以方便测试。(不可能直接比较套件 A 和套件 B 产品集，因为证书、CRL 和清单在语法上有所不同。不过，该过程的输出，即 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 阶段，必须向 RP 提供所有已签名产品的两个相应实例。如第 4.5 节所述，建议有套件 B 能力的 RP 在第 2 阶段获取和验证套件 B 产品集。如果 RP 遇到套件 B 产品的验证问题，它应该恢复使用套件 A 产品。有套件 B 能力的 RP 可以获取两个产品集，并比较结果（如 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 阶段，所有 RP 必须具备套件 B 功能，并且必须获取套件 B 产品集。如果 RP 在使用 B 套件产品集时遇到问题，它可以恢复使用 A 套件产品。遇到此类问题的 RP 应联系相关的资源库维护者（例如，使用 [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 产品集。因此，RP 只应检索和验证这些产品集。检索套件 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 中存在相应的证书套件 B，则吊销该证书套件 B 中相应证书的 CA 应吊销该证书套件 A 中的相应证书。在第 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 階段，核證機關可撤銷組合 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 对 CA 证书的任何请求都将被拒绝，例如，根据 [RFC6492] 中的定义，发送错误代码为 "request - no such resource class "的 "error_response "消息。
2. Each CA MUST cease generating signed products, except the CRL and manifest, under the deprecated algorithm suite.
2. 除 CRL 和清单外，每个 CA 必须停止在废弃算法套件下生成签名产品。
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 应从其发布点删除这些产品，以避免给 RP 带来下载和处理这些产品的负担。
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 和该公布点的清单。此行为提供了一个窗口，RP 可以在此窗口中了解已被删除的签名产品的废止状态。
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 和清单就无法验证了。该程序的异步执行可能会导致与废弃算法套件相关的发布点之间出现短暂的 "不一致"。不过，这些不一致性应该会产生 "故障安全 "结果，即根据废弃算法套件签署的对象应被注册表拒绝。
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 和 RP 数量庞大，作者认为实施紧急算法迁移程序并不可行。
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 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.
如果 CA 没有按照本文所述完成向新算法套件的迁移（在 "旧 "算法套件到期后），其签名产品集将不再有效。因此，在第 4 阶段结束时，RPKI 的有效签名产品数量可能少于启动该流程之前的数量。相反，不遵循此流程的 RP 将失去验证根据新算法套件发布的签名产品的能力。由此造成的 RPKI 路由信息不完整（由于 CA 或 RP 未完成过渡）可能会降低公共互联网的路由性能。
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 工作组联合主席（Sandra Murphy、Chris Morrow 和 Alexey Melnikov）的工作，以及 Geoff Huston、Arturo Servin、Brian Weis、Terry Manderson、Brian Dickson、David Black 和 Danny McPherson 的贡献。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[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., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
[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., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012.
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.
[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., and R. Watro, "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)", BCP 173, RFC 6484, February 2012.
[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., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)", RFC 6485, February 2012.
[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., and S. Kent, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", BCP 174, RFC 6489, February 2012.
[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., and S. Kent, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", RFC 6490, February 2012.
[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., and R. Austein, "A Protocol for Provisioning Resource Certificates", RFC 6492, February 2012.
[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, February 2012.
[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, February 2012.
Authors' Addresses
作者地址
Roque Gagliano Cisco Systems Avenue des Uttins 5 Rolle 1180 Switzerland
Roque Gagliano 思科系统公司 乌坦大道 5 号 Rolle 1180 瑞士
EMail: [email protected]
Stephen Kent BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA
Stephen Kent BBN Technologies 10 Moulton St.
EMail: [email protected]
Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA
Sean Turner IECA, Inc.3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA
EMail: [email protected]