Internet Engineering Task Force (IETF) G. Huston
Request for Comments: 8360 G. Michaelson
Category: Standards Track APNIC
ISSN: 2070-1721 C. Martinez
LACNIC
T. Bruijnzeels
RIPE NCC
A. Newton
ARIN
D. Shaw
AFRINIC
April 2018
Resource Public Key Infrastructure (RPKI) Validation Reconsidered
重新考虑资源公钥基础设施 (RPKI) 验证问题
Abstract
摘要
This document specifies an alternative to the certificate validation procedure specified in RFC 6487 that reduces aspects of operational fragility in the management of certificates in the Resource Public Key Infrastructure (RPKI), while retaining essential security features.
本文件规定了 RFC 6487 中指定的证书验证程序的替代方案，在保留基本安全功能的同时，减少了资源公钥基础架构 (RPKI) 中证书管理的操作脆弱性。
The procedure specified in RFC 6487 requires that Resource Certificates are rejected entirely if they are found to overclaim any resources not contained on the issuing certificate, whereas the validation process defined here allows an issuing Certification Authority (CA) to chose to communicate that such Resource Certificates should be accepted for the intersection of their resources and the issuing certificate.
RFC 6487 中规定的程序要求，如果发现资源证书多申请了签发证书中未包含的任何资源，则应完全拒绝这些证书，而此处定义的验证程序允许签发证书的证书颁发机构（CA）选择就其资源与签发证书的交叉点传达应接受此类资源证书的信息。
It should be noted that the validation process defined here considers validation under a single trust anchor (TA) only. In particular, concerns regarding overclaims where multiple configured TAs claim overlapping resources are considered out of scope for this document.
需要注意的是，此处定义的验证流程仅考虑在单个信任锚（TA）下进行验证。特别是，对于多个已配置的 TA 重叠申请资源的超额申请问题，不在本文件的讨论范围之内。
This choice is signaled by a set of alternative Object Identifiers (OIDs) per "X.509 Extensions for IP Addresses and AS Identifiers" (RFC 3779) and "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)" (RFC 6484). It should be noted that in case these OIDs are not used for any certificate under a trust anchor, the validation procedure defined here has the same outcome as the procedure defined in RFC 6487.
根据 "X.509 扩展 IP 地址和 AS 标识符"（RFC 3779）和 "资源公钥基础设施（RPKI）的证书策略（CP）"（RFC 6484），一组可选的对象标识符（OID）标志着这一选择。应注意的是，如果这些 OID 未用于信任锚下的任何证书，则此处定义的验证程序与 RFC 6487 中定义的程序结果相同。
Furthermore, this document provides an alternative to Route Origin Authorization (ROA) (RFC 6482) and BGPsec Router Certificate (BGPsec PKI Profiles -- publication requested) validation.
此外，本文件还提供了路由起源授权（ROA）（RFC 6482）和 BGPsec 路由器证书（BGPsec PKI 配置文件--请求发布）验证的替代方案。
Status of This Memo
本备忘录的地位
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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 Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组 (IETF) 的成果。它代表了 IETF 社区的共识。它已接受公众审查，并经互联网工程指导小组 (IESG) 批准发布。有关互联网标准的更多信息，请参见 RFC 7841 第 2 节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8360.
有关本文件的当前状态、任何勘误以及如何提供反馈的信息，请访问 https://www.rfc-editor.org/info/rfc8360。
Copyright Notice
版权声明
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2018 IETF Trust 和文件作者。保留所有权利。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文档受BCP 78以及本文档发布之日有效的IETF信托基金关于IETF文档的法律规定（https://trustee.ietf.org/license-info）的约束。 请仔细阅读这些文档，因为它们描述了您对本文档的权利和限制。 从本文档中提取的代码组件必须包含信托法律条款第 4.e 节中描述的简化 BSD 许可证文本，并且不提供简化 BSD 许可证中描述的担保。
Table of Contents
目录
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2. Certificate Validation in the RPKI . . . . . . . . . . . . . 4
3. Operational Considerations . . . . . . . . . . . . . . . . . 5
4. An Amended RPKI Certification Validation Process . . . . . . 7
4.1. Verified Resource Sets . . . . . . . . . . . . . . . . . 7
4.2. Differences with Existing Standards . . . . . . . . . . . 7
4.2.1. Certificate Policy (CP) for Use with Validation
Reconsidered in the RPKI . . . . . . . . . . . . . . 7
4.2.2. An Alternative to X.509 Extensions for IP Addresses
and AS Identifiers (RFC 3779) . . . . . . . . . . . . 8
4.2.3. Addendum to RFC 6268 . . . . . . . . . . . . . . . . 12
4.2.4. An Alternative to the Profile for X.509 PKIX Resource
Certificates . . . . . . . . . . . . . . . . . . . . 14
4.2.5. An Alternative ROA Validation . . . . . . . . . . . . 18
4.2.6. An Alternative to BGPsec Router Certificate
Validation . . . . . . . . . . . . . . . . . . . . . 18
5. Validation Examples . . . . . . . . . . . . . . . . . . . . . 19
5.1. Example 1 -- An RPKI Tree Using the Old OIDs Only . . . . 19
5.2. Example 2 -- An RPKI Tree Using the New OIDs Only . . . . 21
5.3. Example 3 -- An RPKI Tree Using a Mix of Old and New OIDs 23
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.1. Normative References . . . . . . . . . . . . . . . . . . 27
9.2. Informative References . . . . . . . . . . . . . . . . . 28
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
This document specifies an alternative to the certificate validation procedure specified in RFC 6487. Where the procedure specified in RFC 6487 will require that Resource Certificates be rejected entirely if they are found to overclaim any resources not contained on the issuing certificate, the procedure defined here dictates that these Resource Certificates be accepted for the intersection of their resources and the issuing certificate only.
本文件规定了 RFC 6487 中指定的证书验证程序的替代方案。RFC 6487 中规定的程序要求，如果发现资源证书多申请了签发证书中未包含的任何资源，则应完全拒绝接受资源证书。
The outcome of both procedures is the same as long as no overclaims occur. Furthermore, the new procedure can never lead to the acceptance of resources that are not validly held on the path of issuing certificates.
只要不出现超额申请，两种程序的结果是一样的。此外，新程序绝不会导致接受在签发证书过程中未有效持有的资源。
However, the procedure defined here will limit the impact in case resources are no longer validly held on the path of issuing certificates to attestations, such as Route Origin Authorizations [RFC6482] that refer to these resources only.
不过，这里定义的程序将限制在向证明（如仅引用这些资源的路由起源授权 [RFC6482]）颁发证书的路径上不再有效持有资源时产生的影响。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 以及 "OPTIONAL" 应按照BCP 14 [RFC2119] [RFC8174]中描述的一样，当且仅当它们以全大写形式出现时进行解释。
As currently defined in Section 7.2 of [RFC6487], validation of PKIX certificates that conform to the RPKI profile relies on the use of a path validation process where each certificate in the validation path is required to meet the certificate validation criteria.
根据 [RFC6487] 第 7.2 节目前的定义，符合 RPKI 配置文件的 PKIX 证书的验证依赖于路径验证过程的使用，验证路径中的每个证书都必须符合证书验证标准。
These criteria require, in particular, that the Internet Number Resources (INRs) of each certificate in the validation path are "encompassed" by INRs on the issuing certificate. The first certificate in the path is required to be a trust anchor, and its resources are considered valid by definition.
这些标准特别要求验证路径中每个证书的互联网号码资源（INR）都被签发证书上的 INR 所 "包含"。路径中的第一个证书必须是信任锚，其资源根据定义被视为有效。
For example, in the following sequence:
例如，按以下顺序
Certificate 1 (trust anchor): Issuer TA, Subject TA, Resources 192.0.2.0/24, 198.51.100.0/24, 2001:db8::/32, AS64496-AS64500
证书 1（信任锚）：Issuer TA, Subject TA, Resources 192.0.2.0/24, 198.51.100.0/24, 2001:db8::/32, AS64496-AS64500
Certificate 2: Issuer TA, Subject CA1, Resources 192.0.2.0/24, 198.51.100.0/24, 2001:db8::/32
证书 2：签发者 TA、主体 CA1、资源 192.0.2.0/24、198.51.100.0/24、2001:db8::/32
Certificate 3: Issuer CA1, Subject CA2, Resources 192.0.2.0/24, 198.51.100.0/24, 2001:db8::/32
证书 3：签发者 CA1、主体 CA2、资源 192.0.2.0/24、198.51.100.0/24、2001:db8::/32
ROA 1: Embedded Certificate 4 (EE certificate): Issuer CA2, Subject R1, Resources 192.0.2.0/24
ROA 1：嵌入式证书 4（EE 证书）：签发者 CA2、主体 R1、资源 192.0.2.0/24
Prefix 192.0.2.0/24, Max Length 24, ASN 64496
前缀 192.0.2.0/24，最大长度 24，ASN 64496
All certificates in this scenario are considered valid since the INRs of each certificate are encompassed by those of the issuing certificate. ROA1 is valid because the specified prefix is encompassed by the embedded end entity (EE) certificate, as required by [RFC6482].
这种情况下的所有证书都被视为有效，因为每个证书的 INR 都包含在签发证书的 INR 中。ROA1 是有效的，因为根据 [RFC6482] 的要求，指定的前缀被嵌入式终端实体 (EE) 证书所包含。
The allocations recorded in the RPKI change as a result of resource transfers. For example, the CAs involved in transfer might choose to modify CA certificates in an order that causes some of these certificates to "overclaim" temporarily. A certificate is said to "overclaim" if it includes INRs not contained in the INRs of the CA that issued the certificate in question.
RPKI 中记录的分配会因资源转移而改变。例如，参与转移的 CA 可能会选择按顺序修改 CA 证书，导致其中一些证书暂时 "超额申领"。如果证书包含的 INR 未包含在签发该证书的 CA 的 INR 中，则称该证书 "超额申领"。
It may also happen that a child CA does not voluntarily request a shrunk Resource Certificate when resources are being transferred or reclaimed by the parent. Furthermore, operational errors that may occur during management of RPKI databases also may create CA certificates that, temporarily, no longer encompass all of the INRs of subordinate certificates.
当父 CA 转移或回收资源时，子 CA 也可能不会主动要求缩减资源证书。此外，RPKI 数据库管理过程中可能出现的操作失误也可能导致 CA 证书暂时不再包含下属证书的所有 INR。
Consider the following sequence:
请看下面的序列：
Certificate 1 (trust anchor): Issuer TA, Subject TA, Resources 192.0.2.0/24, 198.51.100.0/24, 2001:db8::/32, AS64496-AS64500
证书 1（信任锚）：Issuer TA, Subject TA, Resources 192.0.2.0/24, 198.51.100.0/24, 2001:db8::/32, AS64496-AS64500
Certificate 2: Issuer TA, Subject CA1, Resources 192.0.2.0/24, 2001:db8::/32
证书 2：签发者 TA，主体 CA1，资源 192.0.2.0/24，2001:db8::/32
Certificate 3 (invalid): Issuer CA1, Subject CA2, Resources 192.0.2.0/24, 198.51.100.0/24, 2001:db8::/32
证书 3（无效）：签发者 CA1、主体 CA2、资源 192.0.2.0/24、198.51.100.0/24、2001:db8::/32
ROA 1 (invalid): Embedded Certificate 4 (EE certificate, invalid): Issuer CA2, Subject R1, Resources 192.0.2.0/24
ROA 1（无效）：嵌入式证书 4（EE 证书，无效）：签发者 CA2，主体 R1，资源 192.0.2.0/24
Prefix 192.0.2.0/24, Max Length 24, ASN 64496
前缀 192.0.2.0/24，最大长度 24，ASN 64496
Here, Certificate 2 from the previous example was reissued by TA to CA1, and the prefix 198.51.100.0/24 was removed. However, CA1 failed to reissue a new Certificate 3 to CA2. As a result, Certificate 3 is now overclaiming and considered invalid; by recursion, the embedded Certificate 4 used for ROA1 is also invalid. And ROA1 is invalid because the specified prefix contained in the ROA is no longer encompassed by a valid embedded EE certificate, as required by [RFC6482].
在此，TA 向 CA1 重新签发了上一示例中的证书 2，并删除了前缀 198.51.100.0/24。但是，CA1 未能向 CA2 重新签发新的证书 3。因此，证书 3 现在被过度声称并视为无效；通过递归，用于 ROA1 的嵌入式证书 4 也是无效的。ROA1 无效的原因是，ROA 中包含的指定前缀不再由有效的嵌入式 EE 证书涵盖，这也是 [RFC6482] 的要求。
However, it should be noted that ROA1 does not make use of any of the address resources that were removed from CA1's certificate; thus, it would be desirable if ROA1 could still be viewed as valid. Technically, CA1 should reissue a Certificate 3 to CA2 without 198.51.100.0/24, and then ROA1 would be considered valid according to [RFC6482]. But as long as CA1 does not take this action, ROA1 remains invalid. It would be preferable if ROA1 could be considered valid, since the assertion it makes was not affected by the reduced scope of CA1's certificate.
不过，应该注意的是，ROA1 并没有使用从 CA1 证书中删除的任何地址资源；因此，如果 ROA1 仍能被视为有效，那就更好了。从技术上讲，CA1 应在不包含 198.51.100.0/24 的情况下向 CA2 重新签发证书 3，这样 ROA1 就会根据 [RFC6482] 被视为有效。但只要 CA1 不这样做，ROA1 就仍然无效。如果 ROA1 能被视为有效就更好了，因为它所做的断言不受 CA1 证书范围缩小的影响。
The problem described above can be considered a low probability problem today. However, the potential impact on routing security would be high if an overclaiming occurred near the apex of the RPKI hierarchy, as this would invalidate the entirety of the subtree located below this point.
上述问题目前可被视为低概率问题。但是，如果在 RPKI 层次结构的顶点附近发生超额申领，对路由安全性的潜在影响就会很大，因为这会使位于该点以下的整个子树失效。
The changes specified here to the validation procedure in [RFC6487] do not change the probability of this problem, but they do limit the impact to just the overclaimed resources. This revised validation algorithm is intended to avoid causing CA certificates to be treated as completely invalid as a result of overclaims. However, these changes are designed to not degrade the security offered by the RPKI. Specifically, ROAs and router certificates will be treated as valid only if all of the resources contained in them are encompassed by all superior certificates along a path to a trust anchor.
此处对 [RFC6487] 中的验证程序所做的修改并不会改变这一问题的发生概率，但会将影响范围限制在超额申领的资源上。修订后的验证算法旨在避免 CA 证书因超额申领而被视为完全无效。不过，这些修改的目的是不降低 RPKI 提供的安全性。具体来说，只有当 ROA 和路由器证书中包含的所有资源都被通往信任锚的路径上的所有上级证书所覆盖时，它们才会被视为有效。
The way this is achieved conceptually is by maintaining a Verified Resource Set (VRS) for each certificate that is separate from the INRs found in the resource extension [RFC3779] in the certificate.
概念上实现这一目标的方法是为每张证书维护一个验证资源集（VRS），该资源集与证书中资源扩展[RFC3779]中的 INR 是分开的。
Note that Section 1.2 of [RFC6484] defines the "Certificate Policy (CP) for the Resource PKI (RPKI)" with the following OID:
请注意，[RFC6484] 第 1.2 节定义了 "资源 PKI (RPKI) 的证书策略 (CP)"，其 OID 如下：
id-cp-ipAddr-asNumber OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) cp(14) 2 }
Per this document, a new OID for an alternative "Certificate Policy (CP) for use with validation reconsidered in the Resource PKI (RPKI)" has been assigned as follows:
根据本文件，已为 "资源公钥基础设施（RPKI）中重新考虑验证的证书策略（CP）"分配了一个新的 OID：
id-cp-ipAddr-asNumber-v2 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) cp(14) 3 }
This alternative Certificate Policy is the same as the Certificate Policy described in [RFC6484], except that it is used to drive the decision in Step 8 of the validation procedure described in Section 4.2.4.4.
该替代证书策略与 [RFC6484] 中描述的证书策略相同，不同之处在于它用于驱动第 4.2.4.4 节所述验证程序步骤 8 中的决策。
This document defines an alternative to [RFC3779]. All specifications and procedures described in [RFC3779] apply, with the notable exceptions described in the following subsections.
本文件定义了 [RFC3779] 的替代方案。[RFC3779]中描述的所有规范和程序均适用，但以下小节中描述的明显例外除外。
Per this document, an OID has been assigned for the extension id-pe-ipAddrBlocks-v2 (id-pe 28). This OID MUST only be used in conjunction with the alternative Certificate Policy OID defined in Section 4.2.1.
根据本文件，为扩展名 id-pe-ipAddrBlocks-v2 分配了一个 OID（id-pe 28）。该 OID 必须与第 4.2.1 节中定义的替代证书策略 OID 结合使用。
The following is an amended specification to be used as an alternative to the specification in Section 2.2.1 of [RFC3779].
以下是修订后的规范，可用于替代 [RFC3779] 第 2.2.1 节中的规范。
The OID for this extension is id-pe-ipAddrBlocks-v2.
该扩展的 OID 是 id-pe-ipAddrBlocks-v2。
id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe 28 }
where [RFC5280] defines:
其中 [RFC5280] 定义：
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe 28 }
IPAddrBlocks ::= SEQUENCE OF IPAddressFamily
IPAddressFamily ::= SEQUENCE { -- AFI & optional SAFI --
addressFamily OCTET STRING (SIZE (2..3)),
ipAddressChoice IPAddressChoice }
IPAddressChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
addressesOrRanges SEQUENCE OF IPAddressOrRange }
IPAddressOrRange ::= CHOICE {
addressPrefix IPAddress,
addressRange IPAddressRange }
IPAddressRange ::= SEQUENCE {
min IPAddress,
max IPAddress }
IPAddress ::= BIT STRING
Note that the descriptions of objects referenced in the syntax above are defined in Sections 2.2.3.1 through 2.2.3.9 of [RFC3779].
请注意，[RFC3779]第 2.2.3.1 节至第 2.2.3.9 节定义了上述语法中引用的对象描述。
Per this document, an OID has been assigned for the extension id-pe-autonomousSysIds-v2 (id-pe 29). This OID MUST only be used in conjunction with the alternative Certificate Policy OID defined in Section 4.2.1.
根据本文件，为扩展名 id-pe-autonomousSysIds-v2 分配了一个 OID（id-pe 29）。该 OID 必须与第 4.2.1 节中定义的替代证书策略 OID 结合使用。
The following is an amended specification to be used as an alternative to the specification in Section 3.2.1 of [RFC3779].
以下是修订后的规范，可用于替代 [RFC3779] 第 3.2.1 节中的规范。
The OID for this extension is id-pe-autonomousSysIds-v2.
该扩展的 OID 是 id-pe-autonomousSysIds-v2。
id-pe-autonomousSysIds-v2 OBJECT IDENTIFIER ::= { id-pe 29 }
where [RFC5280] defines:
其中 [RFC5280] 定义：
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
id-pe-autonomousSysIds-v2 OBJECT IDENTIFIER ::= { id-pe 29 }
ASIdentifiers ::= SEQUENCE {
asnum [0] EXPLICIT ASIdentifierChoice OPTIONAL,
rdi [1] EXPLICIT ASIdentifierChoice OPTIONAL}
ASIdentifierChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
asIdsOrRanges SEQUENCE OF ASIdOrRange }
ASIdOrRange ::= CHOICE {
id ASId,
range ASRange }
ASRange ::= SEQUENCE {
min ASId,
max ASId }
ASId ::= INTEGER
Certificate path validation is performed as specified in Section 4.2.4.4.
证书路径验证按第 4.2.4.4 节规定执行。
Certificate path validation is performed as specified in Section 4.2.4.4.
证书路径验证按第 4.2.4.4 节规定执行。
Per this document, an OID has been assigned for id-mod-ip-addr-and-as-ident-v2, as follows:
根据本文件，id-mod-ip-addr-and-as-ident-v2 的 OID 已分配如下：
IPAddrAndASCertExtn-v2 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) mod(0)
id-mod-ip-addr-and-as-ident-v2(90) }
The following is an amended specification to be used as an alternative to the specification in Appendix A of [RFC3779].
以下是修订后的规范，可用于替代 [RFC3779] 附录 A 中的规范。
This normative appendix describes the extensions for IP address and AS identifier delegation used by conforming PKI components in ASN.1 syntax.
本规范性附录描述了符合规定的 PKI 组件使用 ASN.1 语法进行 IP 地址和 AS 标识符委托的扩展。
IPAddrAndASCertExtn-v2 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) mod(0)
id-mod-ip-addr-and-as-ident-v2(90) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
开始
-- EXPORTS ALL --
-- 全部出口
IMPORTS
进口
-- PKIX specific OIDs and arcs --
-- PKIX 专用 OID 和弧 --
id-pe FROM PKIX1Explicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) }
-- IP Address Block and AS Identifiers Syntax --
-- IP 地址块和 AS 标识符语法 --
IPAddrBlocks, ASIdentifiers FROM IPAddrAndASCertExtn { iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) mod(0) id-mod-ip-addr-and-as-ident(30) }
;
-- Validation Reconsidered IP Address Delegation Extension OID --
-- 重新考虑的验证 IP 地址授权扩展 OID --
id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe 28 }
-- Validation Reconsidered IP Address Delegation Extension Syntax --
-- Syntax is imported from RFC 3779 --
-- Validation Reconsidered Autonomous System Identifier --
-- Delegation Extension OID --
id-pe-autonomousSysIds-v2 OBJECT IDENTIFIER ::= { id-pe 29 }
-- Validation Reconsidered Autonomous System Identifier --
-- Delegation Extension Syntax --
-- Syntax is imported from RFC 3779 --
-- 语法源自 RFC 3779 --
END
结束
Per this document, an OID has been assigned for id-mod-ip-addr-and-as-ident-2v2 as follows:
根据本文件，id-mod-ip-addr-and-as-ident-2v2 的 OID 已分配如下：
IPAddrAndASCertExtn-2010v2 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) mod(0)
id-mod-ip-addr-and-as-ident-2v2(91) }
[RFC6268] is an informational RFC that updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 modules in Section 4.2.2.7 remain the normative version.
[RFC6268]是一个信息性 RFC，更新了一些辅助 ASN.1 模块，以符合 2008 版 ASN.1；第 4.2.2.7 节中的 1988 ASN.1 模块仍为规范版本。
The following is an additional module conforming to the 2008 version of ASN.1 to be used with the extensions defined in Sections 4.2.2.1 and 4.2.2.3.
以下是符合 2008 版 ASN.1 的附加模块，可与第 4.2.2.1 和 4.2.2.3 节中定义的扩展模块一起使用。
IPAddrAndASCertExtn-2010v2 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) mod(0)
id-mod-ip-addr-and-as-ident-2v2(91) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
开始
EXPORTS ALL; IMPORTS
全部出口；进口
-- PKIX specific OIDs and arcs --
-- PKIX 专用 OID 和弧 --
id-pe
FROM PKIX1Explicit-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51)}
EXTENSION
FROM PKIX-CommonTypes-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57)}
-- IP Address Block and AS Identifiers Syntax --
-- IP 地址块和 AS 标识符语法 --
IPAddrBlocks, ASIdentifiers
FROM IPAddrAndASCertExtn-2010
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) mod(0)
id-mod-ip-addr-and-as-ident-2(72) }
;
--
-- Extensions contain the set of extensions defined in this
-- module
--
-- These are intended to be placed in public key certificates
-- and thus should be added to the CertExtensions extension
-- set in PKIXImplicit-2009 defined for RFC 5280
--
Extensions EXTENSION ::= {
ext-pe-ipAddrBlocks-v2 | ext-pe-autonomousSysIds-v2
}
-- Validation Reconsidered IP Address Delegation Extension OID --
-- 重新考虑的验证 IP 地址授权扩展 OID --
ext-pe-ipAddrBlocks-v2 EXTENSION ::= {
SYNTAX IPAddrBlocks
IDENTIFIED BY id-pe-ipAddrBlocks-v2
}
id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe 28 }
-- Validation Reconsidered IP Address Delegation --
-- Extension Syntax --
-- Syntax is imported from RFC 6268 --
-- 语法源自 RFC 6268 --
-- Validation Reconsidered Autonomous System Identifier --
-- Delegation Extension OID --
ext-pe-autonomousSysIds-v2 EXTENSION ::= {
SYNTAX ASIdentifiers
IDENTIFIED BY id-pe-autonomousSysIds-v2
}
id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 29 }
-- Validation Reconsidered Autonomous System Identifier --
-- Delegation Extension Syntax --
-- Syntax is imported from RFC 6268 --
-- 语法源自 RFC 6268 --
END
结束
This document defines an alternative profile for X.509 PKIX Resource Certificates. This profile follows all definitions and procedures described in [RFC6487] with the following notable exceptions.
本文件定义了 X.509 PKIX 资源证书的替代配置文件。该配置文件遵循 [RFC6487] 中描述的所有定义和程序，但有以下明显例外。
The following is an amended specification to be used in this profile, in place of Section 4.8.9 of [RFC6487].
以下是本配置文件使用的修订规范，以取代 [RFC6487] 第 4.8.9 节。
This extension MUST be present and MUST be marked critical. It MUST include exactly one policy of type id-cp-ipAddr-asNumber-v2, as specified in the updated RPKI CP in Section 4.2.1.
该扩展必须存在，且必须标记为关键。它必须包含一个类型为 id-cp-ipAddr-asNumber-v2 的策略，如第 4.2.1 节中更新的 RPKI CP 所规定。
The following is an amended specification to be used in this profile, in place of Section 4.8.10 of [RFC6487].
以下是本配置文件中使用的修订规范，以取代 [RFC6487] 第 4.8.10 节。
Either the IP resources extension or the AS resources extension, or both, MUST be present in all RPKI certificates and MUST be marked critical.
所有 RPKI 证书中必须包含 IP 资源扩展名或 AS 资源扩展名，或同时包含这两种扩展名，并且必须标记为关键。
This extension contains the list of IP address resources as per Section 4.2.2.1. The value may specify the "inherit" element for a particular Address Family Identifier (AFI) value. In the context of Resource Certificates describing public number resources for use in the public Internet, the Subsequent AFI (SAFI) value MUST NOT be used.
该扩展包含第 4.2.2.1 节所述的 IP 地址资源列表。该值可指定特定地址族标识符 (AFI) 值的 "继承 "元素。在描述用于公共互联网的公共号码资源的资源证书中，不得使用后续 AFI (SAFI) 值。
This extension MUST either specify a non-empty set of IP address records or use the "inherit" setting to indicate that the IP address resource set of this certificate is inherited from that of the certificate's issuer.
该扩展必须指定一组非空的 IP 地址记录，或使用 "继承 "设置来表示该证书的 IP 地址资源集继承自证书签发者的资源集。
The following is an amended specification to be used in this profile, in place of Section 4.8.11 of [RFC6487].
以下是本配置文件中使用的修订规范，以取代 [RFC6487] 第 4.8.11 节。
Either the AS resources extension or the IP resources extension, or both, MUST be present in all RPKI certificates and MUST be marked critical.
在所有 RPKI 证书中，AS 资源扩展或 IP 资源扩展或两者都必须存在，并且必须标记为关键。
This extension contains the list of AS number resources as per Section 4.2.2.3, or it may specify the "inherit" element. Routing Domain Identifier (RDI) values are NOT supported in this profile and MUST NOT be used.
该扩展包含第 4.2.2.3 节所述的 AS 号码资源列表，也可指定 "继承 "元素。本配置文件不支持路由域标识符 (RDI) 值，也不得使用。
This extension MUST either specify a non-empty set of AS number records or use the "inherit" setting to indicate that the AS number resource set of this certificate is inherited from that of the certificate's issuer.
该扩展必须指定一组非空的 AS 号码记录，或使用 "继承 "设置表示该证书的 AS 号码资源集继承自证书签发者的 AS 号码资源集。
The following is an amended specification for path validation to be used in place of Section 7.2 of [RFC6487], which allows for the validation of both certificates following the profile defined in [RFC6487], as well as certificates following the profile described above.
以下是经修订的路径验证规范，可用于替代 [RFC6487] 第 7.2 节，该节允许对遵循 [RFC6487] 中定义的配置文件的证书和遵循上述配置文件的证书进行验证。
The following algorithm is employed to validate CA and EE resource certificates. It is modeled on the path validation algorithm from [RFC5280] but is modified to make use of the IP Address Delegation and AS Identifier Delegation extensions from [RFC3779].
以下算法用于验证 CA 和 EE 资源证书。该算法以 [RFC5280] 中的路径验证算法为模型，但进行了修改，以使用 [RFC3779] 中的 IP 地址授权和 AS 标识符授权扩展。
There are two inputs to the validation algorithm:
验证算法有两个输入：
1. a trust anchor
1. 信任之锚
2. a certificate to be validated
2. 验证证书
The algorithm is initialized with two new variables for use in the RPKI: Verified Resource Set-IP (VRS-IP) and Verified Resource Set-AS (VRS-AS). These sets are used to track the set of INRs (IP address space and AS numbers) that are considered valid for each CA certificate. The VRS-IP and VRS-AS sets are initially set to the IP Address Delegation and AS Identifier Delegation values, respectively, from the trust anchor used to perform validation.
算法初始化时有两个新变量用于 RPKI：已验证资源集-IP（VRS-IP）和已验证资源集-AS（VRS-AS）。这些集合用于跟踪被认为对每个 CA 证书有效的 INR（IP 地址空间和 AS 号码）集合。VRS-IP 和 VRS-AS 集最初分别设置为用于执行验证的信任锚的 IP 地址授权值和 AS 标识符授权值。
This path validation algorithm verifies, among other things, that a prospective certification path (a sequence of n certificates) satisfies the following conditions:
该路径验证算法主要验证预期认证路径（由 n 个证书组成的序列）是否满足以下条件：
a. for all 'x' in {1, ..., n-1}, the subject of certificate 'x' is
the issuer of certificate ('x' + 1);
b. certificate '1' is issued by a trust anchor;
b. 证书'1'由信任锚签发；
c. certificate 'n' is the certificate to be validated; and
c. 证书'n'是要验证的证书；以及
d. for all 'x' in {1, ..., n}, certificate 'x' is valid.
d. 对于{1，...，n}中的所有'x'，证书'x'有效。
Certificate validation requires verifying that all of the following conditions hold, in addition to the certification path validation criteria specified in Section 6 of [RFC5280].
除了 [RFC5280] 第 6 节规定的证书路径验证标准外，证书验证还要求验证以下所有条件是否成立。
1. The signature of certificate x (x>1) is verified using the public key of the issuer's certificate (x-1), using the signature algorithm specified for that public key (in certificate x-1).
1. 证书 x（x>1）的签名是使用签发人证书（x-1）的公开密钥，并使用为该公开密钥指定的签名算法（在证书 x-1 中）验证的。
2. The current time lies within the interval defined by the NotBefore and NotAfter values in the Validity field of certificate x.
2. 当前时间位于证书 x 有效期字段中的 NotBefore 和 NotAfter 值所定义的时间段内。
3. The Version, Issuer, and Subject fields of certificate x satisfy the constraints established in Sections 4.1 to 4.7 of RFC 6487.
3. 证书 x 的 "版本"、"签发者 "和 "主题 "字段符合 RFC 6487 第 4.1 至 4.7 节中规定的限制条件。
4. If certificate x uses the Certificate Policy defined in Section 4.8.9 of [RFC6487], then the certificate MUST contain all extensions defined in Section 4.8 of [RFC6487] that must be present. The value(s) for each of these extensions MUST satisfy the constraints established for each extension in the respective sections. Any extension not thus identified MUST NOT appear in certificate x.
4. 如果证书 x 使用[RFC6487]第 4.8.9 节定义的证书策略，则证书必须包含[RFC6487]第 4.8 节定义的所有扩展。每个扩展的值都必须满足相应章节中为每个扩展规定的限制条件。任何未确定的扩展都不得出现在证书 x 中。
5. If certificate x uses the Certificate Policy defined in Section 4.2.4.1, then all extensions defined in Section 4.8 of [RFC6487], except Sections 4.8.9, 4.8.10, and 4.8.11 MUST be present. The certificate MUST contain an extension as defined in Sections 4.2.4.2 or 4.2.4.3, or both. The value(s) for each of these extensions MUST satisfy the constraints established for each extension in the respective sections. Any extension not thus identified MUST NOT appear in certificate x.
5. 如果证书 x 使用第 4.2.4.1 节定义的证书策略，则除第 4.8.9、4.8.10 和 4.8.11 节外，[RFC6487]第 4.8 节定义的所有扩展名都必须存在。证书必须包含第 4.2.4.2 节或第 4.2.4.3 节定义的扩展名，或两者都包含。每项扩展的值必须满足各节中对每项扩展规定的限制条件。任何未以这种方式确定的扩展都不得出现在证书 x 中。
6. Certificate x MUST NOT have been revoked, i.e., it MUST NOT appear on a Certificate Revocation List (CRL) issued by the CA represented by certificate x-1.
6. 证书 x 必须未被吊销，即不得出现在证书 x-1 所代表的 CA 签发的证书吊销列表（CRL）中。
7. Compute the VRS-IP and VRS-AS set values as indicated below:
7. 计算 VRS-IP 和 VRS-AS 设置值，如下所示：
* If the IP Address Delegation extension is present in certificate x and x=1, set the VRS-IP to the resources found in this extension.
* 如果证书 x 中有 IP 地址授权扩展且 x=1，则将 VRS-IP 设置为该扩展中的资源。
* If the IP Address Delegation extension is present in certificate x and x>1, set the VRS-IP to the intersection of the resources between this extension and the value of the VRS-IP computed for certificate x-1.
* 如果证书 x 中存在 IP 地址授权扩展且 x>1 ，则将 VRS-IP 设置为该扩展与为证书 x-1 计算的 VRS-IP 值之间的资源交集。
* If the IP Address Delegation extension is absent in certificate x, set the VRS-IP to NULL.
* 如果 x 号证书中没有 IP 地址授权扩展名，则将 VRS-IP 设置为空。
* If the IP Address Delegation extension is present in certificate x and x=1, set the VRS-IP to the resources found in this extension.
* 如果证书 x 中有 IP 地址授权扩展且 x=1，则将 VRS-IP 设置为该扩展中的资源。
* If the AS Identifier Delegation extension is present in certificate x and x>1, set the VRS-AS to the intersection of the resources between this extension and the value of the VRS-AS computed for certificate x-1.
* 如果 AS Identifier Delegation 扩展名出现在证书 x 中且 x>1 ，则将 VRS-AS 设置为该扩展名与为证书 x-1 计算的 VRS-AS 值之间的资源交集。
* If the AS Identifier Delegation extension is absent in certificate x, set the VRS-AS to NULL.
* 如果 x 号证书中没有 AS 标识符委托扩展名，则将 VRS-AS 设为空。
8. If there is any difference in resources in the VRS-IP and the IP Address Delegation extension on certificate x, or the VRS-AS and the AS Identifier Delegation extension on certificate x, then:
8. 如果证书 x 上的 VRS-IP 和 IP 地址授权扩展名，或证书 x 上的 VRS-AS 和 AS 标识符授权扩展名的资源有任何差异，则：
* If certificate x uses the Certificate Policy defined in Section 4.2.4.1, a warning listing the overclaiming resources for certificate x SHOULD be issued.
* 如果证书 x 使用第 4.2.4.1 节定义的证书策略，则应发出警告，列出证书 x 的超额申领资源。
* If certificate x uses the Certificate Policy defined in Section 4.8.9 of [RFC6487], then certificate x MUST be rejected.
* 如果证书 x 使用了 [RFC6487] 第 4.8.9 节定义的证书策略，则必须拒绝证书 x。
These rules allow a CA certificate to contain resources that are not present in (all of) the certificates along the path from the trust anchor to the CA certificate. If none of the resources in the CA certificate are present in all certificates along the path, no subordinate certificates could be valid. However, the certificate is not immediately rejected as this may be a transient condition. Not immediately rejecting the certificate does not result in a security problem because the associated VRS sets accurately reflect the resources validly associated with the certificate in question.
这些规则允许 CA 证书包含从信任锚到 CA 证书的路径上（所有）证书中不存在的资源。如果 CA 证书中的资源都不存在于沿路径的所有证书中，则任何子证书都无效。不过，证书不会被立即拒绝，因为这可能是一个短暂的情况。不立即拒绝证书不会导致安全问题，因为相关的 VRS 集准确地反映了与有关证书相关的有效资源。
Section 4 of [RFC6482] currently has the following text on the validation of resources on a ROA:
目前，[RFC6482] 第 4 节有以下关于验证 ROA 上资源的文字：
The IP address delegation extension [RFC3779] is present in the end-entity (EE) certificate (contained within the ROA), and each IP address prefix(es) in the ROA is contained within the set of IP addresses specified by the EE certificate's IP address delegation extension.
IP 地址授权扩展[RFC3779]存在于最终实体（EE）证书中（包含在 ROA 中），ROA 中的每个 IP 地址前缀都包含在 EE 证书的 IP 地址授权扩展所指定的 IP 地址集合中。
If the end entity certificate uses the Certificate Policy defined in Section 4.2.4.1, then the following approach must be used instead.
如果最终实体证书使用第 4.2.4.1 节定义的证书策略，则必须使用以下方法。
The amended IP Address Delegation extension described in Section 4.2.4.2 is present in the end entity (EE) certificate (contained within the ROA), and each IP address prefix(es) in the ROA is contained within the VRS-IP set that is specified as an outcome of EE certificate validation described in Section 4.2.4.4.
第 4.2.4.2 节所述的经修订的 IP 地址授权扩展存在于终端实体（EE）证书中（包含在 ROA 中），ROA 中的每个 IP 地址前缀都包含在 VRS-IP 集中，而 VRS-IP 集是作为第 4.2.4.4 节所述的 EE 证书验证结果而指定的。
Note that this ensures that ROAs can be valid only if all IP address prefixes in the ROA are encompassed by the VRS-IP of all certificates along the path to the trust anchor used to verify it.
请注意，只有当 ROA 中的所有 IP 地址前缀都包含在所有证书的 VRS-IP 中时，ROA 才能有效。
Operators MAY issue separate ROAs for each IP address prefix, so that the loss of one or more IP address prefixes from the VRS-IP of any certificate along the path to the trust anchor would not invalidate authorizations for other IP address prefixes.
运营商可为每个 IP 地址前缀签发单独的 ROA，这样，在通往信任锚点的路径上，任何证书的 VRS-IP 丢失一个或多个 IP 地址前缀都不会导致其他 IP 地址前缀的授权失效。
If a BGPsec Router Certificate [RFC8209] uses the Certificate Policy defined in Section 4.2.4.1, then in addition to the BGPsec Router Certificate Validation defined in Section 3.3 of [RFC8209], the following constraint MUST be met:
如果 BGPsec 路由器证书 [RFC8209] 使用第 4.2.4.1 节中定义的证书策略，那么除了 [RFC8209] 第 3.3 节中定义的 BGPsec 路由器证书验证外，还必须满足以下约束条件：
o The VRS-AS of BGPsec Router Certificates MUST encompass all Autonomous System Numbers (ASNs) in the AS Resource Identifier Delegation extension.
o BGPsec 路由器证书的 VRS-AS 必须包含 AS 资源标识符授权扩展中的所有自治系统号 (ASN)。
Operators MAY issue separate BGPsec Router Certificates for different ASNs, so that the loss of an ASN from the VRS-AS of any certificate along the path to the trust anchor would not invalidate router keys for other ASNs.
操作员可为不同的 ASN 签发单独的 BGPsec 路由器证书，这样，在通往信任锚点的路径上，任何证书的 VRS-AS 的 ASN 丢失都不会使其他 ASN 的路由器密钥失效。
In this section, we will demonstrate the outcome of RPKI validation performed using the algorithm and procedures described in Sections 4.2.4.4, 4.2.5, and 4.2.6, under three deployment scenarios:
在本节中，我们将展示使用第 4.2.4.4、4.2.5 和 4.2.6 节中描述的算法和程序在三种部署场景下进行 RPKI 验证的结果：
o An RPKI tree consisting of certificates using the old OIDs only
o 由仅使用旧 OID 的证书组成的 RPKI 树
o An RPKI tree consisting of certificates using the new OIDs only
o 由仅使用新 OID 的证书组成的 RPKI 树
o An RPKI tree consisting of a mix of certificates using either the old or the new OIDs
o RPKI 树包括使用新旧 OID 的混合证书
In this context, we refer to a certificate as using the 'old' OIDs, if the certificate uses a combination of the OIDs defined in Section 1.2 of [RFC6484], Section 2.2.1 of [RFC3779], and/or Section 3.2.1 of [RFC3779]. We refer to a certificate as using the 'new' OIDS, if the certificate uses a combination of OIDs defined in Sections 4.2.4.1, 4.2.2.1, and/or Section 4.2.2.3.
在这种情况下，如果证书使用了 [RFC6484] 第 1.2 节、[RFC3779] 第 2.2.1 节和/或 [RFC3779] 第 3.2.1 节定义的 OID 组合，我们就称该证书使用了 "旧 "OID。如果证书使用了第 4.2.4.1 节、第 4.2.2.1 节及/或第 4.2.2.3 节定义的 OID 组合，我们就称该证书使用了 "新 "OIDS。
Consider the following example:
请看下面的例子：
Certificate 1 (trust anchor):
Issuer: TA,
Subject: TA,
OIDs: OLD,
Resources: 0/0, ::0, AS0-4294967295 (all resources)
Verified Resource Set: 0/0, ::0, AS0-4294967295 (all resources)
Warnings: none
Certificate 2:
Issuer: TA,
Subject: CA1,
OIDs: OLD,
Resources: 192.0.2.0/24, 2001:db8::/32, AS64496
Verified Resource Set: 192.0.2.0/24,
2001:db8::/32, AS64496
Warnings: none
Certificate 3 (invalid): Issuer: CA1, Subject: CA2, OIDs: OLD, Resources: 192.0.2.0/24, 198.51.100.0/24, AS64496
证书 3（无效）：签发者：CA1，主体：CA2CA2, OIDs：OLD, Resources：192.0.2.0/24, 198.51.100.0/24, as64496
Verified Resource Set: 192.0.2.0/24, AS64496
已验证资源集：192.0.2.0/24, as64496
Certificate 3 is considered invalid because resources contains 198.51.100.0/24, which is not found in the Verified Resource Set.
证书 3 被视为无效，因为资源包含 198.51.100.0/24，而验证资源集中没有该资源。
ROA 1 (invalid): Embedded Certificate 4 (EE certificate invalid): Issuer: CA2, Subject: R1, OIDs: OLD, Resources: 192.0.2.0/24 Prefix 192.0.2.0/24, Max Length 24, ASN 64496
ROA 1（无效）：嵌入式证书 4（EE 证书无效）：签发者：CA2, 主题：R1, OIDs: EER1, OIDs：OLD, Resources：192.0.2.0/24 前缀 192.0.2.0/24, 最大长度 24, ASN 64496
ROA1 is considered invalid because Certificate 3 is invalid.
ROA1 被视为无效，因为证书 3 无效。
ROA 2 (invalid): Embedded Certificate 5 (EE certificate invalid): Issuer: CA2, Subject: R2, OIDs: OLD, Resources: 198.51.100.0/24 Prefix 198.51.100.0/24, Max Length 24, ASN 64496
ROA 2（无效）：嵌入式证书 5（EE 证书无效）：签发者：CA2, 主题：R2, OIDs: EER2, OIDs：OLD, Resources：198.51.100.0/24 前缀 198.51.100.0/24, 最大长度 24, ASN 64496
ROA2 is considered invalid because Certificate 3 is invalid.
ROA2 被视为无效，因为证书 3 无效。
BGPsec Certificate 1 (invalid): Issuer: CA2, Subject: ROUTER-64496, OIDs: NEW, Resources: AS64496
BGPsec 证书 1（无效）：Issuer: CA2, Subject：ROUTER-64496, OIDs：NEW, Resources：AS64496
BGPsec Certificate 1 is invalid because Certificate 3 is invalid.
BGPsec 证书 1 无效，因为证书 3 无效。
BGPsec Certificate 2 (invalid): Issuer: CA2, Subject: ALL-ROUTERS, OIDs: NEW, Resources: AS64496-AS64497
BGPsec 证书 2（无效）：Issuer: CA2, Subject：ALL-ROUTERS, OIDs：NEW, Resources：AS64496-AS64497
BGPsec Certificate 2 is invalid because Certificate 3 is invalid.
BGPsec 证书 2 无效，因为证书 3 无效。
Consider the following example under the amended approach:
根据修正后的方法，请看下面的例子：
Certificate 1 (trust anchor):
Issuer: TA,
Subject: TA,
OIDs: NEW,
Resources: 0/0, ::0, AS0-4294967295 (all resources)
Verified Resource Set: 0/0, ::0, AS0-4294967295 (all resources)
Warnings: none
Certificate 2:
Issuer: TA,
Subject: CA1,
OIDs: NEW,
Resources: 192.0.2.0/24, 2001:db8::/32, AS64496
Verified Resource Set: 192.0.2.0/24,
2001:db8::/32, AS64496
Warnings: none
Certificate 3: Issuer: CA1, Subject: CA2, OIDs: NEW, Resources: 192.0.2.0/24, 198.51.100.0/24, AS64496
证书 3：签发者：CA1，主体：CA2，OID：CA1，OID：CA2：CA2, OIDs：NEW, Resources：192.0.2.0/24, 198.51.100.0/24, as64496
Verified Resource Set: 192.0.2.0/24, AS64496 Warnings: overclaim for 198.51.100.0/24
已验证资源集：192.0.2.0/24, AS64496 警告：超额申请 198.51.100.0/24
ROA 1 (valid): Embedded Certificate 4 (EE certificate): Issuer: CA2, Subject: R1, OIDs: NEW, Resources: 192.0.2.0/24 Prefix 192.0.2.0/24, Max Length 24, ASN 64496
ROA 1（有效）：嵌入式证书 4（EE 证书）：签发者：CA2, 主题：R1, OIDs: EER1, OIDs：NEW, Resources：192.0.2.0/24 前缀 192.0.2.0/24, 最大长度 24, ASN 64496
Verified Resource Set: 192.0.2.0/24 Warnings: none
已验证资源集：192.0.2.0/24 警告：无
ROA1 is considered valid because the prefix matches the Verified Resource Set on the embedded EE certificate.
ROA1 被认为是有效的，因为前缀与嵌入式 EE 证书上的验证资源集相匹配。
ROA 2 (invalid): Embedded Certificate 5 (EE certificate invalid): Issuer: CA2, Subject: R2, OIDs: NEW, Resources: 198.51.100.0/24 Prefix 198.51.100.0/24, Max Length 24, ASN 64496
ROA 2（无效）：嵌入式证书 5（EE 证书无效）：签发者：CA2, 主题：R2, OIDs: EER2, OIDs：NEW, Resources：198.51.100.0/24 前缀 198.51.100.0/24, 最大长度 24, ASN 64496
Verified Resource Set: none (empty set) Warnings: 198.51.100.0/24
已验证资源集：无（空集） 警告：198.51.100.0/24
ROA2 is considered invalid because the ROA prefix 198.51.100.0/24 is not contained in the Verified Resource Set.
ROA2 被视为无效，因为 ROA 前缀 198.51.100.0/24 未包含在已验证资源集中。
BGPsec Certificate 1 (valid): Issuer: CA2, Subject: ROUTER-64496, OIDs: NEW, Resources: AS64496
BGPsec 证书 1（有效）：Issuer: CA2, Subject：ROUTER-64496, OIDs：NEW, Resources：AS64496
Verified Resource Set: AS64496 Warnings: none
已验证资源集：AS64496 警告：无
BGPsec Certificate 2 (invalid): Issuer: CA2, Subject: ALL-ROUTERS, OIDs: NEW, Resources: AS64496-AS64497
BGPsec 证书 2（无效）：Issuer: CA2, Subject：ALL-ROUTERS, OIDs：NEW, Resources：AS64496-AS64497
Verified Resource Set: AS64496
验证资源集：AS64496
BGPsec Certificate 2 is invalid because not all of its resources are contained in the Verified Resource Set.
BGPsec 证书 2 无效，因为其资源未全部包含在已验证资源集中。
Note that this problem can be mitigated by issuing separate certificates for each AS number.
请注意，为每个 AS 号签发单独的证书可以缓解这一问题。
In the following example, new OIDs are used only for CA certificates where the issuing CA anticipates that an overclaim could occur and has a desire to limit the impact of this to just the overclaimed resources in question:
在下面的示例中，新的 OID 仅用于 CA 证书，在这种情况下，签发 CA 预计可能会发生超额申领，并希望将其影响限制在超额申领的资源范围内：
Certificate 1 (trust anchor):
Issuer: TA,
Subject: TA,
OIDs: OLD,
Resources: 0/0, ::0, AS0-4294967295 (all resources)
Verified Resource Set: 0/0, ::0, AS0-4294967295 (all resources)
Warnings: none
Note that a trust anchor certificate cannot be found to overclaim. So, using the new OIDs here would not change anything with regards to the validity of this certificate.
请注意，信任锚证书不能被认定为超额声明。因此，在这里使用新的 OID 不会改变该证书的有效性。
Certificate 2:
Issuer: TA,
Subject: CA1,
OIDs: OLD,
Resources: 192.0.2.0/24, 2001:db8::/32, AS64496
Verified Resource Set: 192.0.2.0/24,
2001:db8::/32, AS64496
Warnings: none
Note that since the TA certificate claims all resources, it is impossible to issue a certificate below it that could be found to be overclaiming. Therefore, there is no benefit in using the new OIDs for Certificate 2.
请注意，由于 TA 证书要求所有资源，因此不可能签发低于 TA 证书的证书，否则会被发现过度要求资源。因此，证书 2 使用新的 OID 没有任何好处。
Certificate 3: Issuer: CA1, Subject: CA2, OIDs: NEW, Resources: 192.0.2.0/24, 198.51.100.0/24, AS64496
证书 3：签发者：CA1，主体：CA2，OID：CA1，OID：CA2：CA2, OIDs：NEW, Resources：192.0.2.0/24, 198.51.100.0/24, as64496
Verified Resource Set: 192.0.2.0/24, AS64496 Warnings: overclaim for 198.51.100.0/24
已验证资源集：192.0.2.0/24, AS64496 警告：超额申请 198.51.100.0/24
Note that CA1 anticipated that it might invalid Certificate 3 issued to CA2, if its own resources on Certificate 2 were modified and old OIDs were used on Certificate 3.
请注意，CA1 预计，如果它自己在证书 2 上的资源被修改，而旧的 OID 被用于证书 3，它可能会使签发给 CA2 的证书 3 无效。
ROA 1 (valid): Embedded Certificate 4 (EE certificate): Issuer: CA2, Subject: R1, OIDs: OLD, Resources: 192.0.2.0/24 Prefix 192.0.2.0/24, Max Length 24, ASN 64496
ROA 1（有效）：嵌入式证书 4（EE 证书）：签发者：CA2, 主题：R1, OIDs: EER1, OIDs：OLD, Resources：192.0.2.0/24 前缀 192.0.2.0/24, 最大长度 24, ASN 64496
Verified Resource Set: 192.0.2.0/24 Warnings: none
已验证资源集：192.0.2.0/24 警告：无
ROA1 is considered valid because the prefix matches the Verified Resource Set on the embedded EE certificate.
ROA1 被认为是有效的，因为前缀与嵌入式 EE 证书上的验证资源集相匹配。
ROA 2 (invalid): Embedded Certificate 5 (EE certificate invalid): Issuer: CA2, Subject: R2, OIDs: OLD, Resources: 198.51.100.0/24 Prefix 198.51.100.0/24, Max Length 24, ASN 64496
ROA 2（无效）：嵌入式证书 5（EE 证书无效）：签发者：CA2, 主题：R2, OIDs: EER2, OIDs：OLD, Resources：198.51.100.0/24 前缀 198.51.100.0/24, 最大长度 24, ASN 64496
Verified Resource Set: none (empty set)
验证资源集：无（空集）
ROA2 is considered invalid because resources on its EE certificate contains 198.51.100.0/24, which is not contained in its Verified Resource Set.
ROA2 被视为无效，因为其 EE 证书上的资源包含 198.51.100.0/24，而该资源未包含在其验证资源集中。
Note that if new OIDs were used here (as in example 2), ROA 2 would be considered invalid because the prefix is not contained in the Verified Resource Set.
请注意，如果在此使用新的 OID（如例 2 所示），ROA 2 将被视为无效，因为该前缀不包含在已验证资源集中。
So, if there is no difference in the validity outcome, one could argue that using old OIDs here is clearest, because any overclaim of ROA prefixes MUST result in it being considered invalid (as described in Section 4.2.5).
因此，如果有效性结果没有区别，那么可以说在这里使用旧的 OID 是最明确的，因为任何对 ROA 前缀的过度声明都必须导致其被视为无效（如第 4.2.5 节所述）。
BGPsec Certificate 1 (valid): Issuer: CA2, Subject: ROUTER-64496, OIDs: OLD, Resources: AS64496
BGPsec 证书 1（有效）：Issuer: CA2, Subject：ROUTER-64496, OIDs：OLD, Resources：AS64496
Verified Resource Set: AS64496 Warnings: none
已验证资源集：AS64496 警告：无
BGPsec Certificate 2 (invalid): Issuer: CA2, Subject: ALL-ROUTERS, OIDs: OLD, Resources: AS64496-AS64497
BGPsec 证书 2（无效）：Issuer: CA2, Subject：ALL-ROUTERS, OIDs：OLD, Resources：AS64496-AS64497
Verified Resource Set: AS64496
验证资源集：AS64496
BGPsec Certificate 2 is considered invalid because resources contains AS64497, which is not contained in its Verified Resource Set.
BGPsec 证书 2 被视为无效，因为资源包含 AS64497，而 AS64497 未包含在其已验证资源集中。
Note that if new OIDs were used here (as in example 2), BGPsec Certificate 2 would be considered invalid because the prefix is not contained in the Verified Resource Set.
请注意，如果在此使用新的 OID（如例 2 所示），BGPsec 证书 2 将被视为无效，因为该前缀不包含在已验证资源集中。
So, if there is no difference in the validity outcome, one could argue that using old OIDs here is the clearest, because any overclaim on this certificate MUST result in it being considered invalid (as described in Section 4.2.6).
因此，如果有效性结果没有区别，可以说在这里使用旧的 OID 是最明确的，因为对该证书的任何超额申领都必须导致它被视为无效（如第 4.2.6 节所述）。
Also note that, as in example 2, this problem can be mitigated by issuing separate certificates for each AS number.
还要注意的是，如例 2 所示，可以通过为每个 AS 号签发单独的证书来缓解这一问题。
This document defines an alternative RPKI validation algorithm, but it does not dictate how this algorithm will be deployed. This should be discussed as a separate effort. That said, the following observations may help this discussion.
本文件定义了一种可供选择的 RPKI 验证算法，但并未规定如何部署该算法。这应该作为一项单独的工作来讨论。尽管如此，以下意见可能会对讨论有所帮助。
Because this document introduces new OIDs and an alternative to the profile for X.509 PKIX Resource Certificates described in [RFC6487], the use of such certificates in the global RPKI will lead to the rejection of such certificates by Relying Party tools that do not (yet) implement the alternative profile described in this document.
由于本文档引入了新的 OID 和 [RFC6487] 中描述的 X.509 PKIX 资源证书配置文件的替代方案，在全球 RPKI 中使用此类证书将导致未（尚未）实施本文档中描述的替代配置文件的依赖方工具拒绝接受此类证书。
For this reason, it is important that such tools are updated before Certification Authorities start to use this specification.
因此，在认证机构开始使用本规范之前，必须更新这些工具。
However, because the OIDs are defined in each RPKI certificate, there is no strict requirement for all Certification Authorities, or even for all the certificates they issue, to migrate to the new OIDs at the same time. The example in Section 5.3 illustrates a possible deployment where the new OIDs are used only in CA certificates where an accidental overclaim may occur.
然而，由于 OID 是在每个 RPKI 证书中定义的，因此并没有严格要求所有认证机构，甚至是它们签发的所有证书都必须同时迁移到新的 OID。第 5.3 节中的示例说明了一种可能的部署方式，即新的 OID 仅用于可能发生意外超额申领的 CA 证书。
The authors believe that the revised validation algorithm introduces no new security vulnerabilities into the RPKI, because it cannot lead to any ROA and/or router certificates to be accepted if they contain resources that are not held by the issuer.
作者认为，修订后的验证算法不会给 RPKI 带来新的安全漏洞，因为如果 ROA 和/或路由器证书包含非签发者持有的资源，就不会导致这些证书被接受。
IANA has added the following to the "SMI Security for PKIX Certificate Policies" registry:
IANA 在 "PKIX 证书策略的 SMI 安全性 "注册表中添加了以下内容：
Decimal Description References
十进制
3 id-cp-ipAddr-asNumber-v2 Section 4.2.1
3 id-cp-ipAddr-asNumber-v2 第 4.2.1 节
IANA has added the following to the "SMI Security for PKIX Certificate Extension" registry:
IANA 在 "PKIX 证书扩展的 SMI 安全性 "注册表中添加了以下内容：
Decimal Description References
十进制
28 id-pe-ipAddrBlocks-v2 Section 4.2.2.1 29 id-pe-autonomousSysIds-v2 Section 4.2.2.3
第 4.2.2.1 节 28 id-pe-ipAddrBlocks-v2
IANA has added the following to the "SMI Security for PKIX Module Identifier" registry:
IANA 在 "SMI Security for PKIX 模块标识符 "注册表中添加了以下内容：
Decimal Description References
十进制
90 id-mod-ip-addr-and-as-ident-v2 Section 4.2.2.7 91 id-mod-ip-addr-and-as-ident-2v2 Section 4.2.3
第 4.2.2.7 节 90 id-mod-ip-addr-and-as-ident-v2
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, DOI 10.17487/RFC3779, June 2004, <https://www.rfc-editor.org/info/rfc3779>.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, DOI 10.17487/RFC3779, June 2004, <https://www.rfc-editor.org/info/rfc3779>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, <https://www.rfc-editor.org/info/rfc6482>.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, <https://www.rfc-editor.org/info/rfc6482>。
[RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)", BCP 173, RFC 6484, DOI 10.17487/RFC6484, February 2012, <https://www.rfc-editor.org/info/rfc6484>.
[RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)", BCP 173, RFC 6484, DOI 10.17487/RFC6484, February 2012, <https://www.rfc-editor.org/info/rfc6484>。
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, <https://www.rfc-editor.org/info/rfc6487>.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, <https://www.rfc-editor.org/info/rfc6487>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>。
[RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests", RFC 8209, DOI 10.17487/RFC8209, September 2017, <https://www.rfc-editor.org/info/rfc8209>.
[RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests", RFC 8209, DOI 10.17487/RFC8209, September 2017, <https://www.rfc-editor.org/info/rfc8209>。
[RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)", RFC 6268, DOI 10.17487/RFC6268, July 2011, <https://www.rfc-editor.org/info/rfc6268>.
[RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)", RFC 6268, DOI 10.17487/RFC6268, July 2011, <https://www.rfc-editor.org/info/rfc6268>.
Acknowledgements
致谢
The authors would like to thank Stephen Kent for reviewing and contributing to this document. We would like to thank Rob Austein for suggesting that separate OIDs should be used to make the behavior of Relying Party tools deterministic, and we would like to thank Russ Housley, Sean Turner, and Tom Petch for their contributions on OID and ASN.1 updates. Finally, we would like to thank Tom Harrison for a general review of this document.
作者感谢 Stephen Kent 对本文档的审阅和贡献。我们还要感谢 Rob Austein 建议使用单独的 OID 来确定依赖方工具的行为，并感谢 Russ Housley、Sean Turner 和 Tom Petch 对 OID 和 ASN.1 更新所做的贡献。最后，我们还要感谢 Tom Harrison 对本文档的总体审阅。
Authors' Addresses
作者地址
Geoff Huston Asia Pacific Network Information Centre 6 Cordelia St South Brisbane, QLD 4101 Australia
Geoff Huston 亚太网络信息中心 6 Cordelia St South Brisbane, QLD 4101 Australia
Phone: +61 7 3858 3100 Email: [email protected]
George Michaelson Asia Pacific Network Information Centre 6 Cordelia St South Brisbane, QLD 4101 Australia
乔治-迈克尔逊亚太网络信息中心 6 Cordelia St South Brisbane, QLD 4101 Australia
Phone: +61 7 3858 3100 Email: [email protected]
Carlos M. Martinez Latin American and Caribbean Internet Address Registry Rambla Mexico 6125 Montevideo 11400 Uruguay
Carlos M. Martinez 拉丁美洲和加勒比互联网地址登记处 Rambla Mexico 6125 Montevideo 11400 Uruguay
Phone: +598 2604 2222 Email: [email protected] Tim Bruijnzeels RIPE Network Coordination Centre Singel 258 Amsterdam 1016 AB The Netherlands
电话：+598 2604 2222 电子邮件：+598 2604 2222 电子邮件：[email protected] Tim Bruijnzeels RIPE 网络协调中心 Singel 258 阿姆斯特丹 1016 AB 荷兰
Email: [email protected]
Andrew Lee Newton American Registry for Internet Numbers 3635 Concorde Parkway Chantilly, VA 20151 United States of America
安德鲁-李-牛顿 美国互联网号码注册处 3635 Concorde Parkway Chantilly, VA 20151 美利坚合众国
Email: [email protected]
Daniel Shaw African Network Information Centre (AFRINIC) 11th Floor, Standard Chartered Tower Cybercity, Ebene Mauritius
Daniel Shaw 非洲网络信息中心（AFRINIC） 毛里求斯埃贝内数码城渣打银行大厦 11 层
Phone: +230 403 51 00 Email: [email protected]