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
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.
根据“IP地址和AS标识符的X.509扩展”（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.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. 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
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照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.
这些标准特别要求验证路径中每个证书的Internet号码资源（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
Certificate 1 (trust anchor):
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
Certificate 2:
Issuer TA,
Subject CA1,
Resources 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
Certificate 3:
Issuer CA1,
Subject CA2,
Resources 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证书，从而导致其中一些证书暂时“过度使用”。如果证书中包含的印度卢比不包含在颁发该证书的CA的印度卢比中，则该证书被称为“超额索赔”。
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
Certificate 1 (trust anchor):
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
Certificate 2:
Issuer TA,
Subject CA1,
Resources 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
Certificate 3 (invalid):
Issuer CA1,
Subject CA2,
Resources 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无效，因为按照[RFC6482]的要求，ROA中包含的指定前缀不再包含在有效的嵌入式EE证书中。
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，然后根据[RFC6482]将ROA1视为有效。但只要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分开。
4.2.1. Certificate Policy (CP) for Use with Validation Reconsidered in the RPKI
4.2.1. 与RPKI中重新考虑的验证一起使用的证书策略（CP）
Note that Section 1.2 of [RFC6484] defines the "Certificate Policy (CP) for the Resource PKI (RPKI)" with the following OID:
请注意，[RFC6484]的第1.2节使用以下OID定义了“资源PKI（RPKI）的证书策略（CP）”：
id-cp-ipAddr-asNumber OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) cp(14) 2 }
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:
根据本文件，已为备选“用于资源PKI（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 }
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中的决策。
4.2.2. An Alternative to X.509 Extensions for IP Addresses and AS Identifiers (RFC 3779)
4.2.2. IP地址和AS标识符的X.509扩展的替代方案（RFC 3779）
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-IPADRBLOCKS-v2（id pe 28）分配了一个OID。此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 }
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-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 OBJECT IDENTIFIER ::= { id-pkix 1 }
id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe 28 }
id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe 28 }
IPAddrBlocks ::= SEQUENCE OF IPAddressFamily
IPAddrBlocks ::= SEQUENCE OF IPAddressFamily
IPAddressFamily ::= SEQUENCE { -- AFI & optional SAFI --
addressFamily OCTET STRING (SIZE (2..3)),
ipAddressChoice IPAddressChoice }
IPAddressFamily ::= SEQUENCE { -- AFI & optional SAFI --
addressFamily OCTET STRING (SIZE (2..3)),
ipAddressChoice IPAddressChoice }
IPAddressChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
addressesOrRanges SEQUENCE OF IPAddressOrRange }
IPAddressChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
addressesOrRanges SEQUENCE OF IPAddressOrRange }
IPAddressOrRange ::= CHOICE {
addressPrefix IPAddress,
addressRange IPAddressRange }
IPAddressOrRange ::= CHOICE {
addressPrefix IPAddress,
addressRange IPAddressRange }
IPAddressRange ::= SEQUENCE {
min IPAddress,
max IPAddress }
IPAddressRange ::= SEQUENCE {
min IPAddress,
max IPAddress }
IPAddress ::= BIT STRING
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（id pe 29）分配了一个OID。此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 }
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-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 OBJECT IDENTIFIER ::= { id-pkix 1 }
id-pe-autonomousSysIds-v2 OBJECT IDENTIFIER ::= { id-pe 29 }
id-pe-autonomousSysIds-v2 OBJECT IDENTIFIER ::= { id-pe 29 }
ASIdentifiers ::= SEQUENCE {
asnum [0] EXPLICIT ASIdentifierChoice OPTIONAL,
rdi [1] EXPLICIT ASIdentifierChoice OPTIONAL}
ASIdentifiers ::= SEQUENCE {
asnum [0] EXPLICIT ASIdentifierChoice OPTIONAL,
rdi [1] EXPLICIT ASIdentifierChoice OPTIONAL}
ASIdentifierChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
asIdsOrRanges SEQUENCE OF ASIdOrRange }
ASIdentifierChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
asIdsOrRanges SEQUENCE OF ASIdOrRange }
ASIdOrRange ::= CHOICE {
id ASId,
range ASRange }
ASIdOrRange ::= CHOICE {
id ASId,
range ASRange }
ASRange ::= SEQUENCE {
min ASId,
max ASId }
ASRange ::= SEQUENCE {
min ASId,
max ASId }
ASId ::= INTEGER
ASId ::= INTEGER
4.2.2.5. Amended IP Address Delegation Extension Certification Path Validation
4.2.2.5. 修改的IP地址委派扩展证书路径验证
Certificate path validation is performed as specified in Section 4.2.4.4.
按照第4.2.4.4节的规定执行证书路径验证。
4.2.2.6. Amended Autonomous System Identifier Delegation Extension Certification Path Validation
4.2.2.6. 修改的自治系统标识符委派扩展证书路径验证
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) }
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
本规范性附录描述了ASN.1中一致性PKI组件使用的IP地址和AS标识符授权的扩展
syntax.
语法。
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) }
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 ::=
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
开始
-- EXPORTS ALL --
--全部出口--
IMPORTS
进口
-- PKIX specific OIDs and arcs --
--特定于PKIX的OID和ARC--
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) }
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) }
;
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 }
id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe 28 }
-- Validation Reconsidered IP Address Delegation Extension Syntax --
-- Syntax is imported from RFC 3779 --
-- Validation Reconsidered IP Address Delegation Extension Syntax --
-- Syntax is imported from RFC 3779 --
-- Validation Reconsidered Autonomous System Identifier --
-- Delegation Extension OID --
-- Validation Reconsidered Autonomous System Identifier --
-- Delegation Extension OID --
id-pe-autonomousSysIds-v2 OBJECT IDENTIFIER ::= { id-pe 29 }
id-pe-autonomousSysIds-v2 OBJECT IDENTIFIER ::= { id-pe 29 }
-- Validation Reconsidered Autonomous System Identifier --
-- Delegation Extension Syntax --
-- Validation Reconsidered Autonomous System Identifier --
-- Delegation Extension Syntax --
-- Syntax is imported from RFC 3779 --
--语法是从RFC3779导入的--
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) }
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模块，以符合ASN.1的2008版本；第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) }
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 ::=
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
开始
EXPORTS ALL; IMPORTS
全部出口；进口
-- PKIX specific OIDs and arcs --
--特定于PKIX的OID和ARC--
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)}
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)}
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) }
;
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 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
}
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
}
ext-pe-ipAddrBlocks-v2 EXTENSION ::= {
SYNTAX IPAddrBlocks
IDENTIFIED BY id-pe-ipAddrBlocks-v2
}
id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe 28 }
id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe 28 }
-- Validation Reconsidered IP Address Delegation --
-- Extension Syntax --
-- Validation Reconsidered IP Address Delegation --
-- Extension Syntax --
-- Syntax is imported from RFC 6268 --
--语法是从RFC6268导入的--
-- Validation Reconsidered Autonomous System Identifier --
-- Delegation Extension OID --
-- Validation Reconsidered Autonomous System Identifier --
-- Delegation Extension OID --
ext-pe-autonomousSysIds-v2 EXTENSION ::= {
SYNTAX ASIdentifiers
IDENTIFIED BY id-pe-autonomousSysIds-v2
}
ext-pe-autonomousSysIds-v2 EXTENSION ::= {
SYNTAX ASIdentifiers
IDENTIFIED BY id-pe-autonomousSysIds-v2
}
id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 29 }
id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 29 }
-- Validation Reconsidered Autonomous System Identifier --
-- Delegation Extension Syntax --
-- Validation Reconsidered Autonomous System Identifier --
-- Delegation Extension Syntax --
-- Syntax is imported from RFC 6268 --
--语法是从RFC6268导入的--
END
终止
4.2.4. An Alternative to the Profile for X.509 PKIX Resource Certificates
4.2.4. X.509 PKIX资源证书配置文件的替代方案
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.
IP资源扩展或AS资源扩展或两者都必须出现在所有RPKI证书中，并且必须标记为关键。
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）值的“继承”元素。在描述公共Internet中使用的公共编号资源的资源证书上下文中，不得使用后续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地址资源集继承自证书颁发者的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.
AS资源扩展或IP资源扩展或两者都必须出现在所有RPKI证书中，并且必须标记为关键。
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地址委派和标识符委派扩展。
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);
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-1）的公钥，使用为该公钥（在证书x-1中）指定的签名算法，验证证书x（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设置为NULL。
* 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标识符委派扩展存在于证书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设置为NULL。
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集合中，该集合被指定为第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或新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组合，我们将其称为使用“新”OID的证书。
Consider the following example:
考虑下面的例子：
Certificate 1 (trust anchor):
Issuer: TA,
Subject: TA,
OIDs: OLD,
Resources: 0/0, ::0, AS0-4294967295 (all resources)
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
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
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
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
Certificate 3 (invalid):
Issuer: CA1,
Subject: CA2,
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，OID:旧，资源：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，OID:旧，资源：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（无效）：颁发者：CA2，主题：路由器-64496，OID:新，资源：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（无效）：颁发者：CA2，主题：ALL-ROUTERS，OID:NEW，资源：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)
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
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
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
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
Certificate 3:
Issuer: CA1,
Subject: 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
Verified Resource Set: 192.0.2.0/24, AS64496
Warnings: overclaim for 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，OID:新，资源：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，OID：新，资源：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（有效）：颁发者：CA2，主题：路由器-64496，OID:新，资源：AS64496
Verified Resource Set: AS64496 Warnings: none
已验证的资源集：AS64496警告：无
BGPsec Certificate 2 (invalid): Issuer: CA2, Subject: ALL-ROUTERS, OIDs: NEW, Resources: AS64496-AS64497
BGPsec证书2（无效）：颁发者：CA2，主题：ALL-ROUTERS，OID:NEW，资源：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)
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
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
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
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证书声明了所有资源，因此不可能在其下颁发一个可能被发现过度声明的证书。因此，对证书2使用新的OID没有任何好处。
Certificate 3:
Issuer: CA1,
Subject: CA2,
OIDs: NEW,
Resources: 192.0.2.0/24, 198.51.100.0/24, AS64496
Certificate 3:
Issuer: CA1,
Subject: 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
Verified Resource Set: 192.0.2.0/24, AS64496
Warnings: overclaim for 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上自己的资源，并且在证书3上使用了旧的OID，则CA1预计它可能会使颁发给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，OID:旧，资源：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，OID:旧，资源：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（有效）：颁发者：CA2，主题：路由器-64496，OID:旧，资源：AS64496
Verified Resource Set: AS64496 Warnings: none
已验证的资源集：AS64496警告：无
BGPsec Certificate 2 (invalid): Issuer: CA2, Subject: ALL-ROUTERS, OIDs: OLD, Resources: AS64496-AS64497
BGPsec证书2（无效）：颁发者：CA2，主题：ALL-ROUTERS，OID:OLD，资源：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
28 id-pe-IPADDROCKS-v2第4.2.2.1节29 id-pe-autonomousSysIds-v2第4.2.2.3节
IANA has added the following to the "SMI Security for PKIX Module Identifier" registry:
IANA已将以下内容添加到“PKIX模块标识符的SMI安全性”注册表中：
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
90 id-mod-ip-addr-and-as-ident-v2第4.2.2.7节91 id-mod-ip-addr-and-as-ident-2v2第4.2.3节
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[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.，和K.Seo，“IP地址和AS标识符的X.509扩展”，RFC 3779，DOI 10.17487/RFC3779，2004年6月<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.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<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.，和D.Kong，“路线原产地授权（ROA）的概要”，RFC 6482，DOI 10.17487/RFC6482，2012年2月<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.，和R.Watro，“资源公钥基础设施（RPKI）的证书政策（CP）”，BCP 173，RFC 6484，DOI 10.17487/RFC64842012年2月<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.，和R.Loomans，“X.509 PKIX资源证书的配置文件”，RFC 6487，DOI 10.17487/RFC6487，2012年2月<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.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<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.和S.Kent，“BGPsec路由器证书、证书撤销列表和证书请求的配置文件”，RFC 8209，DOI 10.17487/RFC8209，2017年9月<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.和S.Turner，“加密消息语法（CMS）和使用X.509（PKIX）的公钥基础设施的额外新ASN.1模块”，RFC 6268，DOI 10.17487/RFC6268，2011年7月<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更新的贡献。最后，我们要感谢汤姆·哈里森对本文件的全面审查。
Authors' Addresses
作者地址
Geoff Huston Asia Pacific Network Information Centre 6 Cordelia St South Brisbane, QLD 4101 Australia
澳大利亚昆士兰州南布里斯班科迪利亚街6号杰夫休斯顿亚太网络信息中心4101
Phone: +61 7 3858 3100
Email: gih@apnic.net
Phone: +61 7 3858 3100
Email: gih@apnic.net
George Michaelson Asia Pacific Network Information Centre 6 Cordelia St South Brisbane, QLD 4101 Australia
澳大利亚昆士兰州南布里斯班科迪利亚街6号乔治·迈克尔森亚太网络信息中心4101
Phone: +61 7 3858 3100
Email: ggm@apnic.net
Phone: +61 7 3858 3100
Email: ggm@apnic.net
Carlos M. Martinez Latin American and Caribbean Internet Address Registry Rambla Mexico 6125 Montevideo 11400 Uruguay
Carlos M.Martinez拉丁美洲和加勒比互联网地址注册处Rambla Mexico 6125蒙得维的亚11400乌拉圭
Phone: +598 2604 2222
Email: carlos@lacnic.net
Phone: +598 2604 2222
Email: carlos@lacnic.net
Tim Bruijnzeels RIPE Network Coordination Centre Singel 258 Amsterdam 1016 AB The Netherlands
Tim Bruijnzeels成熟网络协调中心Singel 258阿姆斯特丹1016 AB荷兰
Email: tim@ripe.net
Email: tim@ripe.net
Andrew Lee Newton American Registry for Internet Numbers 3635 Concorde Parkway Chantilly, VA 20151 United States of America
Andrew Lee Newton美国互联网注册号3635 Concorde Parkway Chantilly，弗吉尼亚州，美国20151
Email: andy@arin.net
Email: andy@arin.net
Daniel Shaw African Network Information Centre (AFRINIC) 11th Floor, Standard Chartered Tower Cybercity, Ebene Mauritius
丹尼尔·肖非洲网络信息中心（AFRINIC）毛里求斯埃本赛博城渣打大厦11楼
Phone: +230 403 51 00
Email: daniel@afrinic.net
Phone: +230 403 51 00
Email: daniel@afrinic.net