Internet Engineering Task Force (IETF) G. Huston
Request for Comments: 6487 G. Michaelson
Category: Standards Track R. Loomans
ISSN: 2070-1721 APNIC
February 2012
Internet Engineering Task Force (IETF) G. Huston
Request for Comments: 6487 G. Michaelson
Category: Standards Track R. Loomans
ISSN: 2070-1721 APNIC
February 2012
A Profile for X.509 PKIX Resource Certificates
X.509 PKIX资源证书的配置文件
Abstract
摘要
This document defines a standard profile for X.509 certificates for the purpose of supporting validation of assertions of "right-of-use" of Internet Number Resources (INRs). The certificates issued under this profile are used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI). This document also specifies profiles for the format of certificate requests and specifies the Relying Party RPKI certificate path validation procedure.
本文件定义了X.509证书的标准配置文件，以支持验证互联网号码资源（INRs）的“使用权”声明。根据本概要文件签发的证书用于传达发行人授权主体被视为证书中所述印度卢比“使用权”的当前持有人。本文档包含资源公钥基础结构（RPKI）中证书和证书撤销列表（CRL）语法的规范性规范。本文档还指定了证书请求格式的配置文件，并指定了依赖方RPKI证书路径验证过程。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6487.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6487.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Describing Resources in Certificates . . . . . . . . . . . . . 5
3. End-Entity (EE) Certificates and Signing Functions in the RPKI 5
4. Resource Certificates . . . . . . . . . . . . . . . . . . . . 6
4.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Serial Number . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Signature Algorithm . . . . . . . . . . . . . . . . . . . 6
4.4. Issuer . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.5. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.6. Validity . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.6.1. notBefore . . . . . . . . . . . . . . . . . . . . . . 8
4.6.2. notAfter . . . . . . . . . . . . . . . . . . . . . . . 8
4.7. Subject Public Key Info . . . . . . . . . . . . . . . . . 8
4.8. Resource Certificate Extensions . . . . . . . . . . . . . 8
4.8.1. Basic Constraints . . . . . . . . . . . . . . . . . . 8
4.8.2. Subject Key Identifier . . . . . . . . . . . . . . . . 9
4.8.3. Authority Key Identifier . . . . . . . . . . . . . . . 9
4.8.4. Key Usage . . . . . . . . . . . . . . . . . . . . . . 9
4.8.5. Extended Key Usage . . . . . . . . . . . . . . . . . . 9
4.8.6. CRL Distribution Points . . . . . . . . . . . . . . . 10
4.8.7. Authority Information Access . . . . . . . . . . . . . 10
4.8.8. Subject Information Access . . . . . . . . . . . . . . 11
4.8.9. Certificate Policies . . . . . . . . . . . . . . . . . 12
4.8.10. IP Resources . . . . . . . . . . . . . . . . . . . . . 12
4.8.11. AS Resources . . . . . . . . . . . . . . . . . . . . . 12
5. Resource Certificate Revocation Lists . . . . . . . . . . . . 13
6. Resource Certificate Requests . . . . . . . . . . . . . . . . 13
6.1. PCKS#10 Profile . . . . . . . . . . . . . . . . . . . . . 14
6.1.1. PKCS#10 Resource Certificate Request Template Fields . 14
6.2. CRMF Profile . . . . . . . . . . . . . . . . . . . . . . . 15
6.2.1. CRMF Resource Certificate Request Template Fields . . 15
6.2.2. Resource Certificate Request Control Fields . . . . . 16
6.3. Certificate Extension Attributes in Certificate Requests . 16
7. Resource Certificate Validation . . . . . . . . . . . . . . . 17
7.1. Resource Extension Validation . . . . . . . . . . . . . . 17
7.2. Resource Certification Path Validation . . . . . . . . . . 18
8. Design Notes . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. Operational Considerations for Profile Agility . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . . 25
12.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Example Resource Certificate . . . . . . . . . . . . 27
Appendix B. Example Certificate Revocation List . . . . . . . . . 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Describing Resources in Certificates . . . . . . . . . . . . . 5
3. End-Entity (EE) Certificates and Signing Functions in the RPKI 5
4. Resource Certificates . . . . . . . . . . . . . . . . . . . . 6
4.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Serial Number . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Signature Algorithm . . . . . . . . . . . . . . . . . . . 6
4.4. Issuer . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.5. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.6. Validity . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.6.1. notBefore . . . . . . . . . . . . . . . . . . . . . . 8
4.6.2. notAfter . . . . . . . . . . . . . . . . . . . . . . . 8
4.7. Subject Public Key Info . . . . . . . . . . . . . . . . . 8
4.8. Resource Certificate Extensions . . . . . . . . . . . . . 8
4.8.1. Basic Constraints . . . . . . . . . . . . . . . . . . 8
4.8.2. Subject Key Identifier . . . . . . . . . . . . . . . . 9
4.8.3. Authority Key Identifier . . . . . . . . . . . . . . . 9
4.8.4. Key Usage . . . . . . . . . . . . . . . . . . . . . . 9
4.8.5. Extended Key Usage . . . . . . . . . . . . . . . . . . 9
4.8.6. CRL Distribution Points . . . . . . . . . . . . . . . 10
4.8.7. Authority Information Access . . . . . . . . . . . . . 10
4.8.8. Subject Information Access . . . . . . . . . . . . . . 11
4.8.9. Certificate Policies . . . . . . . . . . . . . . . . . 12
4.8.10. IP Resources . . . . . . . . . . . . . . . . . . . . . 12
4.8.11. AS Resources . . . . . . . . . . . . . . . . . . . . . 12
5. Resource Certificate Revocation Lists . . . . . . . . . . . . 13
6. Resource Certificate Requests . . . . . . . . . . . . . . . . 13
6.1. PCKS#10 Profile . . . . . . . . . . . . . . . . . . . . . 14
6.1.1. PKCS#10 Resource Certificate Request Template Fields . 14
6.2. CRMF Profile . . . . . . . . . . . . . . . . . . . . . . . 15
6.2.1. CRMF Resource Certificate Request Template Fields . . 15
6.2.2. Resource Certificate Request Control Fields . . . . . 16
6.3. Certificate Extension Attributes in Certificate Requests . 16
7. Resource Certificate Validation . . . . . . . . . . . . . . . 17
7.1. Resource Extension Validation . . . . . . . . . . . . . . 17
7.2. Resource Certification Path Validation . . . . . . . . . . 18
8. Design Notes . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. Operational Considerations for Profile Agility . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . . 25
12.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Example Resource Certificate . . . . . . . . . . . . 27
Appendix B. Example Certificate Revocation List . . . . . . . . . 31
This document defines a standard profile for X.509 certificates [X.509] for use in the context of certification of Internet Number Resources (INRs), i.e., IP Addresses and Autonomous System (AS) numbers. Such certificates are termed "resource certificates". A resource certificate is a certificate that conforms to the PKIX profile [RFC5280], and that conforms to the constraints specified in this profile. A resource certificate attests that the issuer has granted the subject a "right-of-use" for a listed set of IP addresses and/or Autonomous System numbers.
本文件定义了X.509证书[X.509]的标准配置文件，用于互联网号码资源（INRs）的认证，即IP地址和自治系统（AS）号码。这种证书被称为“资源证书”。资源证书是符合PKIX配置文件[RFC5280]的证书，并且符合此配置文件中指定的约束。资源证书证明发卡机构已授予受试者一组列出的IP地址和/或自主系统号的“使用权”。
This document is referenced by Section 7 of the "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)" [RFC6484]. It is an integral part of that policy and the normative specification for certificate and Certificate Revocation List (CRL) syntax used in the RPKI. The document also specifies profiles for the format of certificate requests, and the relying party (RP) RPKI certificate path validation procedure.
“资源公钥基础设施（RPKI）的证书策略（CP）”第7节[RFC6484]引用了本文档。它是该策略以及RPKI中使用的证书和证书撤销列表（CRL）语法的规范性规范的一个组成部分。该文档还指定了证书请求格式的配置文件，以及依赖方（RP）RPKI证书路径验证过程。
Resource certificates are to be used in a manner that is consistent with the RPKI Certificate Policy (CP) [RFC6484]. They are issued by entities that assign and/or allocate public INRs, and thus the RPKI is aligned with the public INR distribution function. When an INR is allocated or assigned by a number registry to an entity, this allocation can be described by an associated resource certificate. This certificate is issued by the number registry, and it binds the certificate subject's key to the INRs enumerated in the certificate. One or two critical extensions, the IP Address Delegation or AS Identifier Delegation Extensions [RFC3779], enumerate the INRs that were allocated or assigned by the issuer to the subject.
资源证书的使用方式应与RPKI证书策略（CP）[RFC6484]一致。它们由分配和/或分配公共INR的实体发布，因此RPKI与公共INR分配功能一致。当INR由数字注册中心分配或分配给实体时，该分配可由关联的资源证书描述。此证书由数字注册中心颁发，它将证书主体的密钥绑定到证书中列举的INR。一个或两个关键扩展（IP地址委派或AS标识符委派扩展[RFC3779]）列举了发卡机构分配给主题的INR。
Relying party (RP) validation of a resource certificate is performed in the manner specified in Section 7.1. This validation procedure differs from that described in Section 6 of [RFC5280], such that:
资源证书的依赖方（RP）验证按照第7.1节规定的方式进行。该验证程序不同于[RFC5280]第6节中所述的验证程序，因此：
o additional validation processing imposed by the INR extensions is required,
o 需要INR扩展施加的额外验证处理，
o a confirmation of a public key match between the CRL issuer and the resource certificate issuer is required, and
o 需要确认CRL颁发者和资源证书颁发者之间的公钥匹配，以及
o the resource certificate is required to conform to this profile.
o 资源证书必须符合此配置文件。
This profile defines those fields that are used in a resource certificate that MUST be present for the certificate to be valid. Any extensions not explicitly mentioned MUST be absent. The same applies to the CRLs used in the RPKI, that are also profiled in this
此配置文件定义了资源证书中使用的字段，这些字段必须存在才能使证书有效。任何未明确提及的扩展都必须缺席。这同样适用于RPKI中使用的CRL，本文也对其进行了分析
document. A Certification Authority (CA) conforming to the RPKI CP MUST issue certificates and CRLs consistent with this profile.
文件符合RPKI CP的证书颁发机构（CA）必须颁发与此配置文件一致的证书和CRL。
It is assumed that the reader is familiar with the terms and concepts described in "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280], and "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779].
假定读者熟悉“Internet X.509公钥基础设施证书和证书吊销列表（CRL）配置文件”[RFC5280]和“IP地址和AS标识符的X.509扩展”[RFC3779]中描述的术语和概念。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The framework for describing an association between the subject of a certificate and the INRs currently under the subject's control is described in [RFC3779]. This profile further requires that:
[RFC3779]中描述了描述证书主体与主体当前控制的INR之间关联的框架。该概要文件还要求：
o Every resource certificate MUST contain either the IP Address Delegation or the Autonomous System Identifier Delegation extension, or both.
o 每个资源证书必须包含IP地址委派或自治系统标识符委派扩展，或两者都包含。
o These extensions MUST be marked as critical.
o 这些扩展必须标记为关键。
o The sorted canonical format describing INRs, with maximal spanning ranges and maximal spanning prefix masks, as defined in [RFC3779], MUST be used for the resource extension field, except where the "inherit" construct is used instead.
o 资源扩展字段必须使用[RFC3779]中定义的描述INR的排序规范格式，以及最大跨越范围和最大跨越前缀掩码，除非使用“继承”构造。
When validating a resource certificate, an RP MUST verify that the INRs described in the issuer's resource certificate encompass the INRs of the resource certificate being validated. In this context, "encompass" allows for the issuer's INRs to be the same as, or a strict superset of, the subject's INRs.
在验证资源证书时，RP必须验证发卡机构资源证书中描述的INR是否包含正在验证的资源证书的INR。在这种情况下，“包含”允许发行人的INR与主体的INR相同，或是一个严格的超集。
As noted in [RFC6480], the primary function of end-entity (EE) certificates in the RPKI is the verification of signed objects that relate to the usage of the INRs described in the certificate, e.g., Route Origin Authorizations (ROAs) and manifests.
如[RFC6480]所述，RPKI中终端实体（EE）证书的主要功能是验证与证书中所述INR使用相关的已签名对象，例如路由来源授权（ROA）和舱单。
The private key associated with an EE certificate is used to sign a single RPKI signed object, i.e., the EE certificate is used to validate only one object. The EE certificate is embedded in the object as part of a Cryptographic Message Syntax (CMS) signed-data
与EE证书关联的私钥用于对单个RPKI签名对象进行签名，即，EE证书仅用于验证一个对象。EE证书作为加密消息语法（CMS）签名数据的一部分嵌入到对象中
structure [RFC6488]. Because of the one-to-one relationship between the EE certificate and the signed object, revocation of the certificate effectively revokes the corresponding signed object.
结构[RFC6488]。由于EE证书与已签名对象之间存在一对一的关系，因此证书的撤销实际上会撤销相应的已签名对象。
An EE certificate may be used to validate a sequence of signed objects, where each signed object in the sequence overwrites the previous instance of the signed object in the repository publication point, such that only one instance of the signed object is published at any point in time (e.g., an EE certificate MAY be used to sign a sequence of manifests [RFC6486]). Such EE certificates are termed "sequential use" EE certificates.
EE证书可用于验证已签名对象序列，其中序列中的每个已签名对象将覆盖存储库发布点中已签名对象的前一个实例，以便在任何时间点仅发布已签名对象的一个实例（例如，EE证书可用于签署一系列清单[RFC6486]）。此类EE证书称为“顺序使用”EE证书。
EE certificates used to validate only one instance of a signed object, and are not used thereafter or in any other validation context, are termed "one-time-use" EE certificates.
EE证书被称为“一次性使用”EE证书，用于仅验证已签名对象的一个实例，并且此后或在任何其他验证上下文中不使用。
A resource certificate is a valid X.509 public key certificate, consistent with the PKIX profile [RFC5280], containing the fields listed in this section. Only the differences from [RFC5280] are noted below.
资源证书是有效的X.509公钥证书，与PKIX配置文件[RFC5280]一致，包含本节中列出的字段。以下仅说明与[RFC5280]的差异。
Unless specifically noted as being OPTIONAL, all the fields listed here MUST be present, and any other fields MUST NOT appear in a conforming resource certificate. Where a field value is specified here, this value MUST be used in conforming resource certificates.
除非特别注明为可选，否则此处列出的所有字段必须存在，且任何其他字段不得出现在合格资源证书中。如果此处指定了字段值，则必须在一致性资源证书中使用该值。
As resource certificates are X.509 version 3 certificates, the version MUST be 3 (i.e., the value of this field is 2).
由于资源证书是X.509版本3证书，因此版本必须为3（即，此字段的值为2）。
RPs need not process version 1 or version 2 certificates (in contrast to [RFC5280]).
RPs不需要处理版本1或版本2证书（与[RFC5280]相反）。
The serial number value is a positive integer that is unique for each certificate issued by a given CA.
序列号值是一个正整数，对于给定CA颁发的每个证书都是唯一的。
The algorithm used in this profile is specified in [RFC6485].
[RFC6485]中规定了此配置文件中使用的算法。
The value of this field is a valid X.501 distinguished name.
此字段的值是有效的X.501可分辨名称。
An issuer name MUST contain one instance of the CommonName attribute and MAY contain one instance of the serialNumber attribute. If both attributes are present, it is RECOMMENDED that they appear as a set. The CommonName attribute MUST be encoded using the ASN.1 type PrintableString [X.680]. Issuer names are not intended to be descriptive of the identity of issuer.
发卡机构名称必须包含CommonName属性的一个实例，并且可以包含serialNumber属性的一个实例。如果两个属性都存在，建议将它们显示为一组。CommonName属性必须使用ASN.1类型的PrintableString[X.680]进行编码。发行人名称不用于描述发行人的身份。
The RPKI does not rely on issuer names being globally unique, for reasons of security. However, it is RECOMMENDED that issuer names be generated in a fashion that minimizes the likelihood of collisions. See Section 8 for (non-normative) suggested name-generation mechanisms that fulfill this recommendation.
出于安全原因，RPKI不依赖于全球唯一的发行人名称。但是，建议以最小化冲突可能性的方式生成颁发者名称。有关实现本建议的建议名称生成机制（非规范性），请参见第8节。
The value of this field is a valid X.501 distinguished name [RFC4514], and is subject to the same constraints as the issuer name.
此字段的值是有效的X.501可分辨名称[RFC4514]，并且受与发卡机构名称相同的约束。
In the RPKI, the subject name is determined by the issuer, not proposed by the subject [RFC6481]. Each distinct subordinate CA and EE certified by the issuer MUST be identified using a subject name that is unique per issuer. In this context, "distinct" is defined as an entity and a given public key. An issuer SHOULD use a different subject name if the subject's key pair has changed (i.e., when the CA issues a certificate as part of re-keying the subject.) Subject names are not intended to be descriptive of the identity of subject.
在RPKI中，主体名称由发行人确定，而不是由主体提出[RFC6481]。必须使用每个发行人唯一的主题名称来标识发行人认证的每个不同的下属CA和EE。在此上下文中，“distinct”被定义为一个实体和一个给定的公钥。如果受试者的密钥对发生变化（即CA签发证书作为重新设置受试者密钥的一部分），则发卡机构应使用不同的受试者名称。受试者名称不用于描述受试者的身份。
The certificate validity period is represented as a SEQUENCE of two dates: the date on which the certificate validity period begins (notBefore) and the date on which the certificate validity period ends (notAfter).
证书有效期表示为两个日期的序列：证书有效期开始的日期（不在此之前）和证书有效期结束的日期（不在此之后）。
While a CA is typically advised against issuing a certificate with a validity period that spans a greater period of time than the validity period of the CA's certificate that will be used to validate the issued certificate, in the context of this profile, a CA MAY have valid grounds to issue a subordinate certificate with a validity period that exceeds the validity period of the CA's certificate.
虽然CA通常不建议颁发有效期大于CA证书有效期的证书，但在本概要文件中，CA可能有有效理由颁发有效期超过CA证书有效期的从属证书。
The "notBefore" time SHOULD be no earlier than the time of certificate generation.
“notBefore”时间不应早于证书生成时间。
In the RPKI, it is valid for a certificate to have a value for this field that pre-dates the same field value in any superior certificate. Relying Parties SHOULD NOT attempt to infer from this time information that a certificate was valid at a time in the past, or that it will be valid at a time in the future, as the scope of an RP's test of validity of a certificate refers specifically to validity at the current time.
在RPKI中，证书的此字段值在任何高级证书中的相同字段值之前是有效的。依赖方不应试图从该时间信息推断证书在过去某个时间有效，或在未来某个时间有效，因为RP对证书有效性的测试范围具体指当前时间的有效性。
The "notAfter" time represents the anticipated lifetime of the current resource allocation or assignment arrangement between the issuer and the subject.
“notAfter”时间表示发行人和主体之间当前资源分配或分配安排的预期寿命。
It is valid for a certificate to have a value for this field that post-dates the same field value in any superior certificate. The same caveats apply to RP's assumptions relating to the certificate's validity at any time other than the current time.
对于证书，此字段的值在任何高级证书中发布相同的字段值是有效的。同样的注意事项适用于RP在当前时间以外的任何时间对证书有效性的假设。
The algorithm used in this profile is specified in [RFC6485].
[RFC6485]中规定了此配置文件中使用的算法。
The following X.509 v3 extensions MUST be present in a conforming resource certificate, except where explicitly noted otherwise. Each extension in a resource certificate is designated as either critical or non-critical. A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize; however, a non-critical extension MAY be ignored if it is not recognized [RFC5280].
以下X.509 v3扩展必须存在于合格资源证书中，除非另有明确说明。资源证书中的每个扩展都被指定为关键或非关键。如果证书使用系统遇到无法识别的关键扩展，则必须拒绝该证书；但是，如果无法识别非关键扩展，则可以忽略该扩展[RFC5280]。
The Basic Constraints extension field is a critical extension in the resource certificate profile, and MUST be present when the subject is a CA, and MUST NOT be present otherwise.
基本约束扩展字段是资源证书配置文件中的关键扩展，当主题是CA时必须存在，否则不能存在。
The issuer determines whether the "cA" boolean is set.
发卡机构确定是否设置了“cA”布尔值。
The Path Length Constraint is not specified for RPKI certificates, and MUST NOT be present.
未为RPKI证书指定路径长度约束，且该约束不得存在。
This extension MUST appear in all resource certificates. This extension is non-critical.
此扩展必须出现在所有资源证书中。这个扩展是非关键的。
The Key Identifier used for resource certificates is the 160-bit SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the Subject Public Key, as described in Section 4.2.1.2 of [RFC5280].
用于资源证书的密钥标识符是主体公钥的DER编码ASN.1位字符串值的160位SHA-1散列，如[RFC5280]第4.2.1.2节所述。
This extension MUST appear in all resource certificates, with the exception of a CA who issues a "self-signed" certificate. In a self-signed certificate, a CA MAY include this extension, and set it equal to the Subject Key Identifier. The authorityCertIssuer and authorityCertSerialNumber fields MUST NOT be present. This extension is non-critical.
此扩展必须出现在所有资源证书中，但颁发“自签名”证书的CA除外。在自签名证书中，CA可以包括此扩展，并将其设置为等于使用者密钥标识符。authorityCertIssuer和authorityCertSerialNumber字段不得存在。这个扩展是非关键的。
The Key Identifier used for resource certificates is the 160-bit SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the issuer's public key, as described in Section 4.2.1.1 of [RFC5280].
用于资源证书的密钥标识符是颁发者公钥的DER编码ASN.1位字符串值的160位SHA-1散列，如[RFC5280]第4.2.1.1节所述。
This extension is a critical extension and MUST be present.
此扩展是一个关键扩展，必须存在。
In certificates issued to certification authorities only, the keyCertSign and CRLSign bits are set to TRUE, and these MUST be the only bits set to TRUE.
在仅颁发给证书颁发机构的证书中，keyCertSign和CRLSign位设置为TRUE，并且这些位必须是唯一设置为TRUE的位。
In EE certificates, the digitalSignature bit MUST be set to TRUE and MUST be the only bit set to TRUE.
在EE证书中，数字签名位必须设置为TRUE，并且必须是唯一设置为TRUE的位。
The Extended Key Usage (EKU) extension MUST NOT appear in any CA certificate in the RPKI. This extension also MUST NOT appear in EE certificates used to verify RPKI objects (e.g., ROAs or manifests. The extension MUST NOT be marked critical.
扩展密钥使用（EKU）扩展不能出现在RPKI中的任何CA证书中。此扩展也不得出现在用于验证RPKI对象（例如ROA或清单）的EE证书中。扩展不得标记为关键。
The EKU extension MAY appear in EE certificates issued to routers or other devices. Permitted values for the EKU OIDs will be specified in Standards Track RFCs issued by other IETF working groups that adopt the RPKI profile and that identify application-specific requirements that motivate the use of such EKUs.
EKU扩展可能出现在发给路由器或其他设备的EE证书中。EKU OID的允许值将在采用RPKI概要文件的其他IETF工作组发布的标准跟踪RFC中规定，并确定激励使用此类EKU的特定应用要求。
This extension MUST be present, except in "self-signed" certificates, and it is non-critical. In a self-signed certificate, this extension MUST be omitted.
除“自签名”证书外，此扩展必须存在，并且它不是关键的。在自签名证书中，必须省略此扩展。
In this profile, the scope of the CRL is specified to be all certificates issued by this CA issuer.
在此配置文件中，CRL的范围指定为该CA颁发者颁发的所有证书。
The CRL Distribution Points (CRLDP) extension identifies the location(s) of the CRL(s) associated with certificates issued by this issuer. The RPKI uses the URI [RFC3986] form of object identification. The preferred URI access mechanism is a single rsync URI ("rsync://") [RFC5781] that references a single inclusive CRL for each issuer.
CRL分发点（CRLDP）扩展标识与此颁发者颁发的证书相关联的CRL的位置。RPKI使用URI[RFC3986]形式的对象标识。首选的URI访问机制是单个rsync URI（“rsync:/”）[RFC5781]，它为每个发行者引用一个包含性CRL。
In this profile, the certificate issuer is also the CRL issuer, implying that the CRLIssuer field MUST be omitted, and the distributionPoint field MUST be present. The Reasons field MUST be omitted.
在此配置文件中，证书颁发者也是CRL颁发者，这意味着必须省略CRLIssuer字段，并且必须存在distributionPoint字段。必须省略“原因”字段。
The distributionPoint MUST contain the fullName field, and MUST NOT contain a nameRelativeToCRLIssuer. The form of the generalName MUST be of type URI.
distributionPoint必须包含fullName字段，并且不能包含nameRelativeToCRLIssuer。generalName的形式必须是URI类型。
The sequence of distributionPoint values MUST contain only a single DistributionPoint. The DistributionPoint MAY contain more than one URI value. An rsync URI [RFC5781] MUST be present in the DistributionPoint and MUST reference the most recent instance of this issuer's CRL. Other access form URIs MAY be used in addition to the rsync URI, representing alternate access mechanisms for this CRL.
distributionPoint值的序列只能包含一个distributionPoint。DistributionPoint可能包含多个URI值。DistributionPoint中必须存在rsync URI[RFC5781]，并且必须引用此颁发者的CRL的最新实例。除了rsync URI之外，还可以使用其他访问形式URI，表示此CRL的备用访问机制。
In the context of the RPKI, this extension identifies the publication point of the certificate of the issuer of the certificate in which the extension appears. In this profile, a single reference to the publication point of the immediate superior certificate MUST be present, except for a "self-signed" certificate, in which case the extension MUST be omitted. This extension is non-critical.
在RPKI上下文中，此扩展标识出现扩展的证书颁发者的证书的发布点。在此配置文件中，必须存在对直接上级证书发布点的单一引用，但“自签名”证书除外，在这种情况下，必须省略扩展名。这个扩展是非关键的。
This profile uses a URI form of object identification. The preferred URI access mechanisms is "rsync", and an rsync URI [RFC5781] MUST be specified with an accessMethod value of id-ad-caIssuers. The URI MUST reference the point of publication of the certificate where this Issuer is the subject (the issuer's immediate superior certificate). Other accessMethod URIs referencing the same object MAY also be included in the value sequence of this extension.
此概要文件使用对象标识的URI形式。首选的URI访问机制是“rsync”，必须使用id ad caIssuers的accessMethod值指定rsync URI[RFC5781]。URI必须引用该颁发者作为主体的证书的发布点（颁发者的直接上级证书）。引用同一对象的其他accessMethod URI也可能包含在此扩展的值序列中。
A CA MUST use a persistent URL name scheme for CA certificates that it issues [RFC6481]. This implies that a reissued certificate overwrites a previously issued certificate (to the same subject) in the publication repository. In this way, certificates subordinate to the reissued (CA) certificate can maintain a constant Authority Information Access (AIA) extension pointer and thus need not be reissued when the parent certificate is reissued.
CA必须为其颁发的CA证书使用持久URL名称方案[RFC6481]。这意味着重新颁发的证书将覆盖发布存储库中以前颁发的证书（针对同一主题）。这样，从属于重新颁发（CA）证书的证书可以保持一个恒定的授权信息访问（AIA）扩展指针，因此在重新颁发父证书时不需要重新颁发。
In the context of the RPKI, this Subject Information Access (SIA) extension identifies the publication point of products signed by the subject of the certificate.
在RPKI的上下文中，此主题信息访问（SIA）扩展标识由证书主题签名的产品的发布点。
This extension MUST be present and MUST be marked non-critical.
此扩展必须存在，并且必须标记为非关键。
This extension MUST have an instance of an accessMethod of id-ad-caRepository, with an accessLocation form of a URI that MUST specify an rsync URI [RFC5781]. This URI points to the directory containing all published material issued by this CA, i.e., all valid CA certificates, published EE certificates, the current CRL, manifest, and signed objects validated via EE certificates that have been issued by this CA [RFC6481]. Other accessDescription elements with an accessMethod of id-ad-caRepository MAY be present. In such cases, the accessLocation values describe alternate supported URI access mechanisms for the same directory. The ordering of URIs in this accessDescription sequence reflect the CA's relative preferences for access methods to be used by RPs, with the first element of the sequence being the most preferred by the CA.
此扩展必须具有id为ad caRepository的accessMethod的实例，并具有必须指定rsync URI[RFC5781]的URI的accessLocation形式。此URI指向包含此CA颁发的所有已发布资料的目录，即所有有效CA证书、已发布EE证书、当前CRL、清单和通过此CA颁发的EE证书验证的已签名对象[RFC6481]。可能存在id为ad caRepository的accessMethod的其他accessDescription元素。在这种情况下，accessLocation值描述了同一目录的备用受支持URI访问机制。此accessDescription序列中URI的顺序反映了CA对RPs使用的访问方法的相对偏好，序列的第一个元素是CA最喜欢的。
This extension MUST have an instance of an AccessDescription with an accessMethod of id-ad-rpkiManifest,
此扩展必须有一个AccessDescription实例，其accessMethod id为ad rpkiManifest，
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
id-ad-rpkiManifest OBJECT IDENTIFIER ::= { id-ad 10 }
id-ad-rpkiManifest OBJECT IDENTIFIER ::= { id-ad 10 }
with an rsync URI [RFC5781] form of accessLocation. The URI points to the CA's manifest of published objects [RFC6486] as an object URL. Other accessDescription elements MAY exist for the id-ad-rpkiManifest accessMethod, where the accessLocation value indicates alternate access mechanisms for the same manifest object.
使用accessLocation的rsync URI[RFC5781]形式。URI作为对象URL指向CA的已发布对象清单[RFC6486]。id ad rpkiManifest accessMethod可能存在其他accessDescription元素，其中accessLocation值表示同一清单对象的备用访问机制。
This extension MUST be present and MUST be marked non-critical.
此扩展必须存在，并且必须标记为非关键。
This extension MUST have an instance of an accessMethod of id-ad-signedObject,
此扩展必须具有id为ad signedObject的accessMethod的实例，
id-ad-signedObject OBJECT IDENTIFIER ::= { id-ad 11 }
id-ad-signedObject OBJECT IDENTIFIER ::= { id-ad 11 }
with an accessLocation form of a URI that MUST include an rsync URI [RFC5781]. This URI points to the signed object that is verified using this EE certificate [RFC6481]. Other accessDescription elements may exist for the id-ad-signedObject accessMethod, where the accessLocation value indicates alternate URI access mechanisms for the same object, ordered in terms of the EE's relative preference for supported access mechanisms.
必须包含rsync URI[RFC5781]的URI的accessLocation形式。此URI指向使用此EE证书[RFC6481]验证的已签名对象。id ad signedObject accessMethod可能存在其他accessDescription元素，其中accessLocation值表示同一对象的备用URI访问机制，按照EE对支持的访问机制的相对偏好排序。
Other AccessMethods MUST NOT be used for an EE certificates's SIA.
EE证书的SIA不得使用其他AccessMethods。
This extension MUST be present and MUST be marked critical. It MUST include exactly one policy, as specified in the RPKI CP [RFC6484]
此扩展必须存在并且必须标记为严重。按照RPKI CP[RFC6484]的规定，它必须只包含一个策略
Either the IP Resources extension, or the AS Resources extension, or both, MUST be present in all RPKI certificates, and if present, MUST be marked critical.
所有RPKI证书中都必须存在IP资源扩展或AS资源扩展，或者两者都存在，如果存在，则必须标记为关键。
This extension contains the list of IP address resources as per [RFC3779]. 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.
此扩展包含符合[RFC3779]的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地址资源集继承的。
Either the AS Resources extension, or the IP Resources extension, or both, MUST be present in all RPKI certificates, and if present, MUST be marked critical.
所有RPKI证书中都必须存在AS资源扩展或IP资源扩展，或者两者都存在，如果存在，则必须标记为关键。
This extension contains the list of AS number resources as per [RFC3779], or it may specify the "inherit" element. Routing Domain Identifier (RDI) values are NOT supported in this profile and MUST NOT be used.
此扩展包含符合[RFC3779]的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编号资源集继承的。
Each CA MUST issue a version 2 CRL that is consistent with [RFC5280]. RPs are NOT required to process version 1 CRLs (in contrast to [RFC5280]). The CRL issuer is the CA. CRLs conforming to this profile MUST NOT include Indirect or Delta CRLs. The scope of each CRL MUST be all certificates issued by this CA.
每个CA必须发布与[RFC5280]一致的版本2 CRL。RPs不需要处理版本1 CRL（与[RFC5280]相反）。CRL发行人是CA。符合此配置文件的CRL不得包括间接或增量CRL。每个CRL的范围必须是该CA颁发的所有证书。
The issuer name is as in Section 4.4 above.
发行人名称如上文第4.4节所述。
Where two or more CRLs are issued by the same CA, the CRL with the highest value of the "CRL Number" field supersedes all other CRLs issued by this CA.
如果两个或多个CRL由同一CA颁发，则“CRL编号”字段值最高的CRL将取代该CA颁发的所有其他CRL。
The algorithm used in CRLs issued under this profile is specified in [RFC6485].
[RFC6485]中规定了在此配置文件下发布的CRL中使用的算法。
The contents of the CRL are a list of all non-expired certificates that have been revoked by the CA.
CRL的内容是CA吊销的所有未过期证书的列表。
An RPKI CA MUST include the two extensions, Authority Key Identifier and CRL Number, in every CRL that it issues. RPs MUST be prepared to process CRLs with these extensions. No other CRL extensions are allowed.
RPKI CA必须在其发布的每个CRL中包含两个扩展，即权限密钥标识符和CRL编号。RPs必须准备好处理带有这些扩展的CRL。不允许其他CRL扩展。
For each revoked resource certificate, only the two fields, Serial Number and Revocation Date, MUST be present, and all other fields MUST NOT be present. No CRL entry extensions are supported in this profile, and CRL entry extensions MUST NOT be present in a CRL.
对于每个已吊销的资源证书，只有两个字段（序列号和吊销日期）必须存在，而所有其他字段不得存在。此配置文件中不支持CRL条目扩展，CRL中不得存在CRL条目扩展。
A resource certificate request MAY use either of PKCS#10 or Certificate Request Message Format (CRMF). A CA MUST support certificate issuance in PKCS#10 and a CA MAY support CRMF requests.
资源证书请求可以使用PKCS#10或证书请求消息格式（CRMF）。CA必须支持PKCS#10中的证书颁发，CA可以支持CRMF请求。
Note that there is no certificate response defined in this profile. For CA certificate requests, the CA places the resource certificate
请注意，此配置文件中没有定义证书响应。对于CA证书请求，CA放置资源证书
in the repository, as per [RFC6484]. No response is defined for EE certificate requests.
在存储库中，根据[RFC6484]。没有为EE证书请求定义响应。
This profile refines the specification in [RFC2986], as it relates to resource certificates. A Certificate Request Message object, formatted according to PKCS#10, is passed to a CA as the initial step in issuing a certificate.
此概要文件细化了[RFC2986]中与资源证书相关的规范。根据PKCS#10格式化的证书请求消息对象被传递给CA，作为颁发证书的初始步骤。
With the exception of the SubjectPublicKeyinfo and the SIA extension request, the CA is permitted to alter any field in the request when issuing a certificate.
除了SubjectPublicKeyinfo和SIA扩展请求外，CA可以在颁发证书时更改请求中的任何字段。
This profile applies the following additional requirements to fields that MAY appear in a CertificationRequestInfo:
此配置文件将以下附加要求应用于CertificationRequestInfo中可能出现的字段：
Version This field is mandatory and MUST have the value 0.
版本此字段是必填字段，必须具有值0。
Subject This field MAY be omitted. If present, the value of this field SHOULD be empty (i.e., NULL), in which case the CA MUST generate a subject name that is unique in the context of certificates issued by this CA. This field is allowed to be non-empty only for a re-key/reissuance request, and only if the CA has adopted a policy (in its Certificate Practice Statement (CPS)) that permits reuse of names in these circumstances.
主题此字段可以省略。如果存在，此字段的值应为空（即NULL），在这种情况下，CA必须生成一个在该CA颁发的证书上下文中唯一的使用者名称。仅当CA已采用策略（在其证书实践声明（CPS）中）且重新密钥/重新颁发请求时，此字段才允许为非空这允许在这些情况下重复使用名称。
SubjectPublicKeyInfo This field specifies the subject's public key and the algorithm with which the key is used. The algorithm used in this profile is specified in [RFC6485].
SubjectPublicKeyInfo此字段指定主题的公钥以及使用该密钥的算法。[RFC6485]中规定了此配置文件中使用的算法。
Attributes [RFC2986] defines the attributes field as key-value pairs where the key is an OID and the value's structure depends on the key.
属性[RFC2986]将属性字段定义为键-值对，其中键是OID，值的结构取决于键。
The only attribute used in this profile is the extensionRequest attribute as defined in [RFC2985]. This attribute contains certificate extensions. The profile for extensions in certificate requests is specified in Section 6.3.
此配置文件中使用的唯一属性是[RFC2985]中定义的extensionRequest属性。此属性包含证书扩展。第6.3节规定了证书请求中扩展的配置文件。
This profile applies the following additional constraint to fields that MAY appear in a CertificationRequest Object:
此配置文件将以下附加约束应用于可能出现在CertificationRequest对象中的字段：
signatureAlgorithm The signatureAlgorithm value is specified in [RFC6485].
signatureAlgorithm[RFC6485]中指定了signatureAlgorithm值。
This profile refines the Certificate Request Message Format (CRMF) specification in [RFC4211], as it relates to resource certificates. A Certificate Request Message object, formatted according to the CRMF, is passed to a CA as the initial step in certificate issuance.
此概要文件细化了[RFC4211]中的证书请求消息格式（CRMF）规范，因为它与资源证书相关。根据CRMF格式化的证书请求消息对象作为证书颁发的初始步骤传递给CA。
With the exception of the SubjectPublicKeyinfo and the SIA extension request, the CA is permitted to alter any requested field when issuing the certificate.
除了SubjectPublicKeyinfo和SIA扩展请求之外，CA可以在颁发证书时更改任何请求的字段。
This profile applies the following additional requirements to fields that may appear in a Certificate Request Template:
此配置文件将以下附加要求应用于证书请求模板中可能出现的字段：
version This field SHOULD be omitted. If present, it MUST specify a request for a version 3 Certificate.
版本此字段应省略。如果存在，则必须指定对版本3证书的请求。
serialNumber This field MUST be omitted.
serialNumber必须省略此字段。
signingAlgorithm This field MUST be omitted.
签名算法必须省略此字段。
issuer This MUST be omitted in this profile.
发卡机构此配置文件中必须省略此项。
Validity This field MAY be omitted. If omitted, the CA will issue a Certificate with Validity dates as determined by the CA. If specified, then the CA MAY override the requested values with dates as determined by the CA.
有效性此字段可以省略。如果省略，CA将颁发一份证书，证书的有效日期由CA确定。如果指定，CA可以使用CA确定的日期覆盖请求的值。
Subject This field MAY be omitted. If present, the value of this field SHOULD be empty (i.e., NULL), in which case the CA MUST generate a subject name that is unique in the context of certificates issued by this CA. This field is allowed to be non-empty only for a re-key/reissuance request, and only if the CA has adopted a policy (in its CPS) that permits the reuse of names in these circumstances.
主题此字段可以省略。如果存在，此字段的值应为空（即NULL），在这种情况下，CA必须生成一个在该CA颁发的证书上下文中唯一的使用者名称。仅当CA已采用策略（在其CPS中）时，此字段才允许为非空这允许在这些情况下重复使用名称。
PublicKey This field MUST be present.
公钥此字段必须存在。
extensions The profile for extensions in certificate requests is specified in Section 6.3.
扩展证书请求中扩展的配置文件在第6.3节中指定。
The following control fields are supported in this profile:
此配置文件中支持以下控制字段：
Authenticator Control The intended model of authentication of the subject is a "long term" model, and the guidance offered in [RFC4211] is that the Authenticator Control field be used.
认证者控制目标对象认证模型为“长期”模型，[RFC4211]中提供的指导是使用认证者控制字段。
The following extensions MAY appear in a PKCS#10 or CRMF Certificate Request. Any other extensions MUST NOT appear in a Certificate Request. This profile places the following additional constraints on these extensions:
以下扩展可能出现在PKCS#10或CRMF证书请求中。证书请求中不得出现任何其他扩展。此配置文件对这些扩展设置了以下附加约束：
BasicConstraints If this is omitted, then the CA will issue an EE certificate (hence no BasicConstraints extension will be included).
基本约束如果省略此项，则CA将颁发EE证书（因此不包括基本约束扩展）。
The pathLengthConstraint is not supported in this profile, and this field MUST be omitted.
此配置文件不支持pathLengthConstraint，必须忽略此字段。
The CA MAY honor the cA boolean if set to TRUE (CA Certificate Request). If this bit is set, then it indicates that the subject is requesting a CA certificate.
如果设置为TRUE（CA证书请求），CA可以接受CA布尔值。如果设置了此位，则表示主体正在请求CA证书。
The CA MUST honor the cA bit if set to FALSE (EE Certificate Request), in which case the corresponding EE certificate will not contain a Basic Constraints extension.
如果设置为FALSE（EE证书请求），CA必须接受CA位，在这种情况下，相应的EE证书将不包含基本约束扩展。
KeyUsage The CA MAY honor KeyUsage extensions of keyCertSign and cRLSign if present, as long as this is consistent with the BasicConstraints SubjectType sub-field, when specified.
KeyUsage CA可以接受keyCertSign和cRLSign的KeyUsage扩展（如果存在），只要在指定时与BasicConstraints SubjectType子字段一致。
ExtendedKeyUsage The CA MAY honor ExtendedKeyUsage extensions of keyCertSign and cRLSign if present, as long as this is consistent with the BasicConstraints SubjectType sub-field, when specified.
ExtendedKeyUsage CA可以接受keyCertSign和cRLSign的ExtendedKeyUsage扩展（如果存在），只要在指定时与BasicConstraints SubjectType子字段一致。
SubjectInformationAccess This field MUST be present, and the field value SHOULD be honored by the CA if it conforms to the requirements set forth in Section 4.8.8. If the CA is unable to honor the requested value for this field, then the CA MUST reject the Certificate Request.
主题信息访问此字段必须存在，并且如果字段值符合第4.8.8节中规定的要求，CA应遵守该字段值。如果CA无法接受此字段的请求值，则CA必须拒绝证书请求。
This section describes the resource certificate validation procedure. This refines the generic procedure described in Section 6 of [RFC5280].
本节介绍资源证书验证过程。这改进了[RFC5280]第6节中描述的通用程序。
The IP Resources and AS Resources extensions [RFC3779] define critical extensions for INRs. These are ASN.1 encoded representations of the IPv4 and IPv6 address range and an AS number set.
IP资源和AS资源扩展[RFC3779]定义了INR的关键扩展。这些是IPv4和IPv6地址范围以及AS编号集的ASN.1编码表示。
Valid resource certificates MUST have a valid IP address and/or AS number resource extension. In order to validate a resource certificate, the resource extension MUST also be validated. This validation process relies on definitions of comparison of resource sets:
有效的资源证书必须具有有效的IP地址和/或AS号资源扩展名。为了验证资源证书，还必须验证资源扩展。此验证过程依赖于资源集比较的定义：
more specific Given two contiguous IP address ranges or two contiguous AS number ranges, A and B, A is "more specific" than B if range B includes all IP addresses or AS numbers described by range A, and if range B is larger than range A.
更具体给定两个连续的IP地址范围或两个连续的AS数字范围A和B，如果范围B包括所有IP地址或范围A描述的AS数字，并且如果范围B大于范围A，则A比B“更具体”。
equal Given two contiguous IP address ranges or two contiguous AS number ranges, A and B, A is "equal" to B if range A describes precisely the same collection of IP addresses or AS numbers described by range B. The definition of "inheritance" in [RFC3779] is equivalent to this "equality" comparison.
相等给定两个连续的IP地址范围或两个连续的AS数字范围A和B，如果范围A描述的IP地址集合或范围B描述的数字完全相同，则A与B“相等”。[RFC3779]中“继承”的定义等同于此“相等”比较。
encompass Given two IP address and AS number sets, X and Y, X "encompasses" Y if, for every contiguous range of IP addresses or AS numbers elements in set Y, the range element is either "more specific" than or "equal" to a contiguous range element within the set X.
包含给定的两个IP地址和作为数字集的X和Y，如果对于IP地址的每个连续范围或作为集合Y中的数字元素，范围元素比集合X中的连续范围元素“更具体”或“等于”。
Validation of a certificate's resource extension in the context of a certification path (see Section 7.2 entails that for every adjacent
在证书路径的上下文中验证证书的资源扩展（参见第7.2节），需要对每个相邻的
pair of certificates in the certification path (certificates 'x' and 'x + 1'), the number resources described in certificate 'x' "encompass" the number resources described in certificate 'x + 1', and the resources described in the trust anchor information "encompass" the resources described in the first certificate in the certification path.
证书路径中的一对证书（证书“x”和“x+1”）、证书“x”中描述的数字资源“包含”证书“x+1”中描述的数字资源，以及信任锚信息中描述的资源“包含”证书路径中第一个证书中描述的资源。
Validation of signed resource data using a target resource certificate consists of verifying that the digital signature of the signed resource data is valid, using the public key of the target resource certificate, and also validating the resource certificate in the context of the RPKI, using the path validation process. This path validation process verifies, among other things, that a prospective certification path (a sequence of n certificates) satisfies the following conditions:
使用目标资源证书验证已签名资源数据包括使用目标资源证书的公钥验证已签名资源数据的数字签名是否有效，以及使用路径验证过程在RPKI上下文中验证资源证书。该路径验证过程验证预期认证路径（n个证书序列）是否满足以下条件：
1. for all 'x' in {1, ..., n-1}, the subject of certificate 'x' is the issuer of certificate ('x' + 1);
1. 对于{1，…，n-1}中的所有'x'，证书'x'的主体是证书的颁发者（'x'+1）；
2. certificate '1' is issued by a trust anchor;
2. 证书“1”由信托锚发行；
3. certificate 'n' is the certificate to be validated; and
3. 证书“n”是要验证的证书；和
4. for all 'x' in {1, ..., n}, certificate 'x' is valid.
4. 对于{1，…，n}中的所有“x”，证书“x”都有效。
Certificate validation entails 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 certificate can be verified using the issuer's public key and the signature algorithm
1. 可以使用颁发者的公钥和签名算法来验证证书
2. The current time lies within the certificate's Validity From and To values.
2. 当前时间在证书的有效期内，从和到值。
3. The certificate contains all fields that MUST be present, as defined by this specification, and contains values for selected fields that are defined as allowable values by this specification.
3. 证书包含本规范定义的所有必须存在的字段，并包含本规范定义为允许值的选定字段的值。
4. No field, or field value, that this specification defines as MUST NOT be present is used in the certificate.
4. 证书中未使用本规范定义为不存在的字段或字段值。
5. The issuer has not revoked the certificate. A revoked certificate is identified by the certificate's serial number being listed on the issuer's current CRL, as identified by the
5. 颁发者尚未吊销证书。吊销的证书由发卡机构当前CRL上列出的证书序列号标识，如
CRLDP of the certificate, the CRL is itself valid, and the public key used to verify the signature on the CRL is the same public key used to verify the certificate itself.
证书的CRLDP，CRL本身有效，用于验证CRL上签名的公钥与用于验证证书本身的公钥相同。
6. The resource extension data is "encompassed" by the resource extension data contained in a valid certificate where this issuer is the subject (the previous certificate in the context of the ordered sequence defined by the certification path).
6. 资源扩展数据被包含在有效证书中的资源扩展数据“包围”，其中该颁发者是主体（证书路径定义的有序序列上下文中的前一个证书）。
7. The certification path originates with a certificate issued by a trust anchor, and there exists a signing chain across the certification path where the subject of Certificate 'x' in the certification path matches the issuer in Certificate 'x + 1' in the certification path, and the public key in Certificate 'x' can verify the signature value in Certificate 'x+1'.
7. 证书路径由信任锚点颁发的证书发起，并且在证书路径上存在签名链，其中证书路径中证书“x”的主题与证书路径中证书“x+1”中的颁发者匹配，证书“x”中的公钥可以验证证书“x+1”中的签名值。
A certificate validation algorithm MAY perform these tests in any chosen order.
证书验证算法可以按任何选择的顺序执行这些测试。
Certificates and CRLs used in this process MAY be found in a locally maintained cache, maintained by a regular synchronization across the distributed publication repository structure [RFC6481].
此过程中使用的证书和CRL可以在本地维护的缓存中找到，该缓存由分布式发布存储库结构中的定期同步维护[RFC6481]。
There exists the possibility of encountering certificate paths that are arbitrarily long, or attempting to generate paths with loops as means of creating a potential denial-of-service (DOS) attack on an RP. An RP executing this procedure MAY apply further heuristics to guide the certification path validation process to a halt in order to avoid some of the issues associated with attempts to validate such malformed certification path structures. Implementations of resource certificate validation MAY halt with a validation failure if the certification path length exceeds a locally defined configuration parameter.
存在遇到任意长的证书路径的可能性，或者试图生成带有循环的路径，以此作为创建潜在拒绝服务（DOS）的手段对RP的攻击。执行此过程的RP可能会应用进一步的试探法来引导认证路径验证过程停止，以避免与验证此类格式错误的认证路径结构的尝试相关的一些问题。如果证书路径长度超过本地定义的配置参数，则资源证书验证的实现可能会因验证失败而停止。
The following notes provide some additional commentary on the considerations that lie behind some of the design choices that were made in the design of this certificate profile. These notes are non-normative, i.e., this section of the document does not constitute a formal part of the profile specification, and the interpretation of key words as defined in RFC 2119 are not applicable in this section of the document.
以下注释对本证书概要设计中的一些设计选择背后的考虑因素提供了一些补充说明。这些注释是非规范性的，即本文件的本节不构成概要规范的正式部分，RFC 2119中定义的关键词解释不适用于本节。
Certificate Extensions: This profile does not permit the use of any other critical or non-critical extensions. The rationale for this restriction is that the resource certificate profile is intended for a specific defined use. In this context, having certificates with additional non-critical extensions that RPs may see as valid certificates without understanding the extensions is inappropriate, because if the RP were in a position to understand the extensions, it would contradict or qualify this original judgment of validity in some way. This profile takes the position of minimalism over extensibility. The specific goal for the associated RPKI is to precisely match the INR allocation structure through an aligned certificate structure that describes the allocation and its context within the INR distribution hierarchy. The profile defines a resource certificate that is structured to meet these requirements.
证书扩展：此配置文件不允许使用任何其他关键或非关键扩展。此限制的基本原理是，资源证书配置文件用于特定的定义用途。在这种情况下，在不了解扩展的情况下，拥有RPs可能视为有效证书的附加非关键扩展的证书是不合适的，因为如果RP能够理解扩展，它将在某种程度上与此原始的有效性判断相矛盾或限定。此概要文件采取了极简主义而非可扩展性的立场。相关RPKI的具体目标是通过一个对齐的证书结构精确匹配INR分配结构，该结构描述INR分配层次结构中的分配及其上下文。配置文件定义了一个资源证书，该证书的结构满足这些要求。
Certification Authorities and Key Values: This profile uses a definition of an instance of a CA as a combination of a named entity and a key pair. Within this definition, a CA instance cannot rollover a key pair. However, the entity can generate a new instance of a CA with a new key pair and roll over all the signed subordinate products to the new CA [RFC6489].
证书颁发机构和键值：此配置文件使用CA实例的定义作为命名实体和密钥对的组合。在此定义中，CA实例不能滚动密钥对。但是，实体可以使用新密钥对生成CA的新实例，并将所有已签名的从属产品滚动到新CA[RFC6489]。
This has a number of implications in terms of subject name management, CRL Scope, and repository publication point management.
这在主题名称管理、CRL范围和存储库发布点管理方面有许多含义。
CRL Scope and Key Values: For CRL Scope, this profile specifies that a CA issues a single CRL at a time, and the scope of the CRL is all certificates issued by this CA. Because the CA instance is bound to a single key pair, this implies that the CA's public key, the key used to validate the CA's CRL, and the key used to validate the certificates revoked by that CRL are all the same key value.
CRL作用域和密钥值：对于CRL作用域，此配置文件指定CA一次颁发一个CRL，并且CRL的作用域是此CA颁发的所有证书。由于CA实例绑定到一个密钥对，这意味着CA的公钥，用于验证CA的CRL的密钥，用于验证该CRL吊销的证书的密钥都是相同的密钥值。
Repository Publication Point: The definition of a CA affects the design of the repository publication system. In order to minimize the amount of forced re-certification on key rollover events, a repository publication regime that uses the same repository publication point for all CA instances that refers to the same entity, but with different key values, will minimize the extent of re-generation of certificates to only immediate subordinate certificates. This is described in [RFC6489].
存储库发布点：CA的定义会影响存储库发布系统的设计。为了最大限度地减少密钥翻转事件中强制重新认证的数量，对于引用同一实体但具有不同键值的所有CA实例使用相同存储库发布点的存储库发布机制将最大限度地减少仅对直接下级证书重新生成证书的程度。这在[RFC6489]中有描述。
Subject Name: This profile specifies that subject names must be unique per issuer, and does not specify that subject names must be globally unique (in terms of assured uniqueness). This is due to the nature of the RPKI as a distributed PKI, implying that there is no ready ability for certification authorities to coordinate a simple RPKI-wide unique name space without resorting to additional critical external dependencies. CAs are advised to use subject name generation procedures that minimize the potential for name clashes.
主题名称：此配置文件指定每个发行人的主题名称必须是唯一的，但未指定主题名称必须是全局唯一的（就确保的唯一性而言）。这是由于RPKI作为分布式PKI的性质造成的，这意味着认证机构没有现成的能力来协调简单的RPKI范围的唯一名称空间，而不诉诸其他关键的外部依赖关系。建议CA使用主题名称生成程序，以尽量减少名称冲突的可能性。
One way to achieve this is for a CA to use a subject name practice that uses the CommonName component of the Distinguished Name as a constant value for any given entity that is the subject of CA-issued certificates, and set the serialNumber component of the Distinguished Name to a value that is derived from the hash of the subject public key value.
实现这一点的一种方法是CA使用主体名称实践，该实践使用可分辨名称的CommonName组件作为CA颁发的证书主体的任何给定实体的常量值，并将可分辨名称的serialNumber组件设置为从主题公钥值的哈希派生的值。
If the CA elects not to use the serialNumber component of the DistinguishedName, then it is considered beneficial that a CA generates CommonNames that have themselves a random component that includes significantly more than 40 bits of entropy in the name. Some non-normative recommendations to achieve this include:
如果CA选择不使用DifferentizedName的serialNumber组件，则CA生成具有随机组件的CommonName是有益的，该组件在名称中包含明显超过40位的熵。实现这一目标的一些非规范性建议包括：
1) Hash of the subject public key (encoded as ASCII HEX). example: cn="999d99d564de366a29cd8468c45ede1848e2cc14"
1) 主题公钥的散列（编码为ASCII十六进制）。示例：cn=“999d99d564de366a29cd8468c45ede1848e2cc14”
2) A Universally Unique IDentifier (UUID) [RFC4122] example: cn="6437d442-6fb5-49ba-bbdb-19c260652098"
2) 通用唯一标识符（UUID）[RFC4122]示例：cn=“6437d442-6fb5-49ba-bbdb-19c260652098”
3) A randomly generated ASCII HEX encoded string of length 20 or greater: example: cn="0f8fcc28e3be4869bc5f8fa114db05e1"> (A string of 20 ASCII HEX digits would have 80-bits of entropy)
3) 随机生成的长度为20或更大的ASCII十六进制编码字符串：例如：cn=“0f8fcc28e3be4869bc5f8fa114db05e1”>（由20个ASCII十六进制数字组成的字符串将具有80位熵）
4) An internal database key or subscriber ID combined with one of the above example: cn="<DBkey1> (6437d442-6fb5-49ba-bbdb-19c2606520980)" (The issuing CA may wish to be able to extract the database key or subscriber ID from the commonName. Since only the issuing CA would need to be able to parse the commonName, the database key and the source of entropy (e.g., a UUID) could be separated in any way that the CA wants, as long as it conforms to the rules for PrintableString. The separator
4) 与上述示例之一组合的内部数据库密钥或订户ID:cn=“<DBkey1>（6437d442-6fb5-49ba-bbdb-19c2606520980）”（签发CA可能希望能够从commonName中提取数据库密钥或订户ID。因为只有签发CA需要能够解析commonName、数据库密钥和熵源（例如UUID）可以用CA想要的任何方式进行分隔，只要它符合PrintableString的规则
could be a space character, parenthesis, hyphen, slash, question mark, etc.
可以是空格、括号、连字符、斜杠、问号等。
This profile requires that relying parties reject certificates or CRLs that do not conform to the profile. (Through the remainder of this section, the term "certificate" is used to refer to both certificates and CRLs.) This includes certificates that contain extensions that are prohibited, but that are otherwise valid as per [RFC5280]. This means that any change in the profile (e.g., extensions, permitted attributes or optional fields, or field encodings) for certificates used in the RPKI will not be backward compatible. In a general PKI context, this constraint probably would cause serious problems. In the RPKI, several factors minimize the difficulty of effecting changes of this sort.
此配置文件要求依赖方拒绝不符合配置文件的证书或CRL。（在本节剩余部分，术语“证书”用于指证书和CRL。）这包括包含禁止扩展的证书，但根据[RFC5280]的规定，这些证书在其他方面是有效的。这意味着RPKI中使用的证书的配置文件中的任何更改（例如，扩展、允许的属性或可选字段或字段编码）都将不向后兼容。在一般的PKI环境中，此约束可能会导致严重的问题。在RPKI中，有几个因素将影响此类变更的难度降至最低。
Note that the RPKI is unique in that every relying party (RP) requires access to every certificate issued by the CAs in this system. An important update of the certificates used in the RPKI must be supported by all CAs and RPs in the system, lest views of the RPKI data differ across RPs. Thus, incremental changes require very careful coordination. It would not be appropriate to introduce a new extension, or authorize use of an extant, standard extension, for a security-relevant purpose on a piecemeal basis.
请注意，RPKI是唯一的，因为每个依赖方（RP）都需要访问此系统中CAs颁发的每个证书。系统中的所有CA和RPs都必须支持RPKI中使用的证书的重要更新，以免RPKI数据的视图因RPs而异。因此，增量更改需要非常仔细的协调。为了与安全相关的目的，在零碎的基础上引入新的扩展或授权使用现有的标准扩展是不合适的。
One might imagine that the "critical" flag in X.509 certificate extensions could be used to ameliorate this problem. However, this solution is not comprehensive and does not address the problem of adding a new, security-critical extension. (This is because such an extension needs to be supported universally, by all CAs and RPs.) Also, while some standard extensions can be marked either critical or non-critical, at the discretion of the issuer, not all have this property, i.e., some standard extensions are always non-critical. Moreover, there is no notion of criticality for attributes within a name or optional fields within a field or an extension. Thus, the critical flag is not a solution to this problem.
可以想象，X.509证书扩展中的“critical”标志可以用来改善这个问题。但是，此解决方案并不全面，也不能解决添加新的安全关键扩展的问题。（这是因为此类扩展需要得到所有CA和RP的普遍支持。）此外，尽管一些标准扩展可以由发行人自行决定标记为关键或非关键，但并非所有扩展都具有此属性，即一些标准扩展始终是非关键的。此外，对于名称中的属性或字段或扩展中的可选字段，没有临界性的概念。因此，临界标志不是这个问题的解决方案。
In typical PKI deployments, there are few CAs and many RPs. However, in the RPKI, essentially every CA in the RPKI is also an RP. Thus the set of entities that will need to change in order to issue certificates under a new format is the same set of entities that will need to change to accept these new certificates. To the extent that this is literally true, it says that CA/RP coordination for a change is tightly linked anyway. In reality, there is an important exception to this general observation. Small ISPs and holders of provider-independent allocations are expected to use managed CA services, offered by Regional Internet Registries (RIRs) and
在典型的PKI部署中，CA很少，RPs很多。然而，在RPKI中，基本上RPKI中的每个CA也是一个RP。因此，为了以新格式颁发证书而需要更改的实体集与为了接受这些新证书而需要更改的实体集是相同的。从字面上讲，这是正确的，它说，CA/RP对变化的协调无论如何都是紧密相连的。事实上，这一普遍看法有一个重要的例外。小型ISP和独立于提供商分配的持有者预计将使用由区域互联网注册中心（RIR）和
potentially by wholesale Internet Service Providers (ISPs). This reduces the number of distinct CA implementations that are needed and makes it easier to effect changes for certificate issuance. It seems very likely that these entities also will make use of RP software provided by their managed CA service provider, which reduces the number of distinct RP software implementations. Also note that many small ISPs (and holders of provider-independent allocations) employ default routes, and thus need not perform RP validation of RPKI data, eliminating these entities as RPs.
可能由批发互联网服务提供商（ISP）提供。这减少了所需的不同CA实现的数量，并使更改证书颁发变得更容易。这些实体似乎也很可能会利用其托管CA服务提供商提供的RP软件，从而减少不同RP软件实现的数量。还要注意的是，许多小型ISP（以及独立于提供商的分配持有者）采用默认路由，因此不需要对RPKI数据执行RP验证，从而将这些实体作为RPs删除。
Widely available PKI RP software does not cache large numbers of certificates, an essential strategy for the RPKI. It does not process manifest or ROA data structures, essential elements of the RPKI repository system. Experience shows that such software deals poorly with revocation status data. Thus, extant RP software is not adequate for the RPKI, although some open source tools (e.g., OpenSSL and cryptlib) can be used as building blocks for an RPKI RP implementation. Thus, it is anticipated that RPs will make use of software that is designed specifically for the RPKI environment and is available from a limited number of open sources. Several RIRs and two companies are providing such software today. Thus it is feasible to coordinate change to this software among the small number of developers/maintainers.
广泛使用的PKI RP软件不会缓存大量证书，这是RPKI的一个基本策略。它不处理清单或ROA数据结构，这是RPKI存储库系统的基本元素。经验表明，这种软件处理撤销状态数据的能力很差。因此，现有的RP软件不适合RPKI，尽管一些开源工具（例如OpenSSL和cryptlib）可以用作RPKI RP实现的构建块。因此，预计RPs将使用专门为RPKI环境设计的软件，并可从数量有限的开放源代码中获得。如今，几家RIR和两家公司正在提供此类软件。因此，在少数开发人员/维护人员之间协调对该软件的更改是可行的。
If the resource certificate profile is changed in the future, e.g., by adding a new extension or changing the allowed set of name attributes or encoding of these attributes, the following procedure will be employed to effect deployment in the RPKI. The model is analogous to that described in [RPKI-ALG], but is simpler.
如果将来更改资源证书配置文件，例如，通过添加新扩展或更改允许的名称属性集或这些属性的编码，将采用以下过程来实现RPKI中的部署。该模型类似于[RPKI-ALG]中描述的模型，但更简单。
A new document will be issued as an update to this RFC. The CP for the RPKI [RFC6484] will be updated to reference the new certificate profile. The new CP will define a new policy OID for certificates issued under the new certificate profile. The updated CP also will define a timeline for transition to the new certificate (CRL) format. This timeline will define 3 phases and associated dates:
新文件将作为本RFC的更新发布。RPKI[RFC6484]的CP将更新以引用新的证书配置文件。新CP将为根据新证书配置文件颁发的证书定义新的策略OID。更新后的CP还将定义转换为新证书（CRL）格式的时间表。该时间线将定义3个阶段和相关日期：
1. At the end of phase 1, all RPKI CAs MUST be capable of issuing certificates under the new profile, if requested by a subject. Any certificate issued under the new format will contain the new policy OID.
1. 在第1阶段结束时，如果受试者要求，所有RPKI CA必须能够根据新配置文件颁发证书。以新格式颁发的任何证书都将包含新的策略OID。
2. During phase 2, CAs MUST issue certificates under the new profile, and these certificates MUST coexist with certificates issued under the old format. (CAs will continue to issue certificates under the old OID/format as well.) The old and new certificates MUST be identical, except for the policy OID and any new extensions, encodings, etc. The new certificates,
2. 在第2阶段，CA必须根据新配置文件颁发证书，并且这些证书必须与根据旧格式颁发的证书共存。（CAs也将继续以旧OID/格式颁发证书。）旧证书和新证书必须相同，但策略OID和任何新扩展、编码等除外。新证书，
and associated signed objects, will coexist in the RPKI repository system during this phase, analogous to what is required by an algorithm transition for the RPKI [RPKI-ALG]. Relying parties MAY make use of the old or the new certificate formats when processing signed objects retrieved from the RPKI repository system. During this phase, a relying party that elects to process both formats will acquire the same values for all certificate fields that overlap between the old and new formats. Thus if either certificate format is verifiable, the relying party accepts the data from that certificate. This allows CAs to issue certificates under the new format before all relying parties are prepared to process that format.
与RPKI[RPKI-ALG]的算法转换所需的内容类似，在该阶段，RPKI存储库系统中将共存相关的签名对象。在处理从RPKI存储库系统检索的签名对象时，依赖方可以使用旧的或新的证书格式。在此阶段，选择处理两种格式的依赖方将为新旧格式之间重叠的所有证书字段获取相同的值。因此，如果任一证书格式都是可验证的，则依赖方接受来自该证书的数据。这使得CAs可以在所有依赖方准备处理新格式之前，以新格式颁发证书。
3. At the beginning of phase 3, all relying parties MUST be capable of processing certificates under the new format. During this phase, CAs will issue new certificates ONLY under the new format. Certificates issued under the old OID will be replaced with certificates containing the new policy OID. The repository system will no longer require matching old and new certificates under the different formats.
3. 在第3阶段开始时，所有依赖方必须能够以新格式处理证书。在此阶段，CAs将仅以新格式颁发新证书。根据旧OID颁发的证书将替换为包含新策略OID的证书。存储库系统不再需要以不同格式匹配新旧证书。
At the end of phase 3, all certificates under the old OID will have been replaced. The resource certificate profile RFC will be replaced to remove support for the old certificate format, and the CP will be replaced to remove reference to the old policy OID and to the old resource certificate profile RFC. The system will have returned to a new, steady state.
在第3阶段结束时，旧OID下的所有证书都将被替换。将替换资源证书配置文件RFC以删除对旧证书格式的支持，并替换CP以删除对旧策略OID和旧资源证书配置文件RFC的引用。系统将恢复到新的稳定状态。
The Security Considerations of [RFC5280] and [RFC3779] apply to resource certificates. The Security Considerations of [RFC2986] and [RFC4211] apply to resource certificate certification requests.
[RFC5280]和[RFC3779]的安全注意事项适用于资源证书。[RFC2986]和[RFC4211]的安全注意事项适用于资源证书认证请求。
A resource certificate PKI cannot in and of itself resolve any forms of ambiguity relating to uniqueness of assertions of rights of use in the event that two or more valid certificates encompass the same resource. If the issuance of resource certificates is aligned to the status of resource allocations and assignments, then the information conveyed in a certificate is no better than the information in the allocation and assignment databases.
如果两个或多个有效证书包含同一资源，则资源证书PKI本身无法解决与使用权声明唯一性相关的任何形式的歧义。如果资源证书的颁发与资源分配和分配的状态一致，那么证书中传递的信息并不比分配和分配数据库中的信息好。
This profile requires that the key used to sign an issued certificate be the same key used to sign the CRL that can revoke the certificate, implying that the certification path used to validate the signature on a certificate is the same as that used to validate the signature of the CRL that can revoke the certificate. It is noted that this is
此配置文件要求用于签署已颁发证书的密钥与用于签署可撤销证书的CRL的密钥相同，这意味着用于验证证书上签名的证书路径与用于验证可撤销证书的CRL签名的证书路径相同。值得注意的是，这是
a tighter constraint than required in X.509 PKIs, and there may be a risk in using a path validation implementation that is capable of using separate validation paths for a certificate and the corresponding CRL. If there are subject name collisions in the RPKI as a result of CAs not following the guidelines provided here relating to ensuring sufficient entropy in constructing subject names, and this is combined with the situation that an RP uses an implementation of validation path construction that is not in conformance with this RPKI profile, then it is possible that the subject name collisions can cause an RP to conclude that an otherwise valid certificate has been revoked.
比X.509 PKI中要求的约束更严格，并且使用能够为证书和相应CRL使用单独验证路径的路径验证实现可能存在风险。如果由于CAs未遵循此处提供的关于确保构建主题名称时具有足够熵的指南，并且RP使用不符合此RPKI配置文件的验证路径构建实现，因此RPKI中存在主题名称冲突，然后，使用者名称冲突可能会导致RP得出本应有效的证书已被吊销的结论。
The authors would like to particularly acknowledge the valued contribution from Stephen Kent in reviewing this document and proposing numerous sections of text that have been incorporated into the document. The authors also acknowledge the contributions of Sandy Murphy, Robert Kisteleki, Randy Bush, Russ Housley, Ricardo Patara, and Rob Austein in the preparation and subsequent review of this document. The document also reflects review comments received from Roque Gagliano, Sean Turner, and David Cooper.
作者要特别感谢Stephen Kent在审查本文件和提出已纳入本文件的许多文本部分方面所作的宝贵贡献。作者还感谢Sandy Murphy、Robert Kisteleki、Randy Bush、Russ Housley、Ricardo Patara和Rob Austein在本文件编写和后续审查过程中所做的贡献。该文件还反映了从罗克·加利亚诺、肖恩·特纳和大卫·库珀收到的审查意见。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, November 2000.
[RFC2986]Nystrom，M.和B.Kaliski，“PKCS#10：认证请求语法规范版本1.7”，RFC 2986，2000年11月。
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC3779]Lynn，C.，Kent，S.，和K.Seo，“IP地址和AS标识符的X.509扩展”，RFC 3779，2004年6月。
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, September 2005.
[RFC4211]Schaad，J.“Internet X.509公钥基础设施证书请求消息格式（CRMF）”，RFC 42112005年9月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, February 2010.
[RFC5781]Weiler，S.，Ward，D.，和R.Housley，“rsync URI方案”，RFC 57812010年2月。
[RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)", BCP 173, RFC 6484, February 2012.
[RFC6484]Kent，S.，Kong，D.，Seo，K.，和R.Watro，“资源公钥基础设施（RPKI）的证书政策（CP）”，BCP 173，RFC 6484，2012年2月。
[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)", RFC 6485, February 2012.
[RFC6485]Huston，G.“用于资源公钥基础设施（RPKI）的算法和密钥大小的配置文件”，RFC 6485，2012年2月。
[X.509] ITU-T, "Recommendation X.509: The Directory - Authentication Framework", 2000.
[X.509]ITU-T，“建议X.509：目录认证框架”，2000年。
[X.680] ITU-T, "Recommendation X.680 (2002) | ISO/IEC 8824- 1:2002, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", 2002.
[X.680]ITU-T，“建议X.680（2002）| ISO/IEC 8824-1:2002，信息技术——抽象语法符号一（ASN.1）：基本符号规范”，2002年。
[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", RFC 2985, November 2000.
[RFC2985]Nystrom，M.和B.Kaliski，“PKCS#9：选定对象类和属性类型版本2.0”，RFC 29852000年11月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[RFC4122]Leach，P.，Mealling，M.和R.Salz，“通用唯一标识符（UUID）URN名称空间”，RFC 4122，2005年7月。
[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[RFC4514]Zeilenga，K.，“轻量级目录访问协议（LDAP）：可分辨名称的字符串表示”，RFC4514，2006年6月。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
[RFC6480]Lepinski，M.和S.Kent，“支持安全互联网路由的基础设施”，RFC 6480，2012年2月。
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012.
[RFC6481]Huston，G.，Loomans，R.，和G.Michaelson，“资源证书存储库结构的配置文件”，RFC 64812012年2月。
[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, February 2012.
[RFC6486]Austein，R.，Huston，G.，Kent，S.，和M.Lepinski，“资源公钥基础设施（RPKI）清单”，RFC 64862012年2月。
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, February 2012.
[RFC6488]Lepinski，M.，Chi，A.，和S.Kent，“资源公钥基础设施（RPKI）的签名对象模板”，RFC 6488，2012年2月。
[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", BCP 174, RFC 6489, February 2012.
[RFC6489]Huston，G.，Michaelson，G.，和S.Kent，“资源公钥基础设施（RPKI）中的证书颁发机构（CA）密钥滚动”，BCP 174，RFC 6489，2012年2月。
[RPKI-ALG] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility Procedure for RPKI", Work in Progress, November 2011.
[RPKI-ALG]Gagliano，R.，Kent，S.和S.Turner，“RPKI的算法敏捷程序”，正在进行的工作，2011年11月。
The following is an example resource certificate.
下面是一个资源证书示例。
Certificate Name: 9JfgAEcq7Q-47IwMC5CJIJr6EJs.cer
证书名称：9JfgAEcq7Q-47IwMC5CJIJr6EJs.cer
Data:
Version: 3 (0x2)
Serial: 1500 (0x5dc)
Signature Algorithm: SHA256WithRSAEncryption
Issuer: CN=APNIC Production-CVPQSgUkLy7pOXdNeVWGvnFX_0s
Validity
Not Before: Oct 25 12:50:00 2008 GMT
Not After : Jan 31 00:00:00 2010 GMT
Subject: CN=A91872ED
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:bb:fb:4a:af:a4:b9:dc:d0:fa:6f:67:cc:27:39:
34:d1:80:40:37:de:88:d1:64:a2:f1:b3:fa:c6:7f:
bb:51:df:e1:c7:13:92:c3:c8:a2:aa:8c:d1:11:b3:
aa:99:c0:ac:54:d3:65:83:c6:13:bf:0d:9f:33:2d:
39:9f:ab:5f:cd:a3:e9:a1:fb:80:7d:1d:d0:2b:48:
a5:55:e6:24:1f:06:41:35:1d:00:da:1f:99:85:13:
26:39:24:c5:9a:81:15:98:fb:5f:f9:84:38:e5:d6:
70:ce:5a:02:ca:dd:61:85:b3:43:2d:0b:35:d5:91:
98:9d:da:1e:0f:c2:f6:97:b7:97:3e:e6:fc:c1:c4:
3f:30:c4:81:03:25:99:09:4c:e2:4a:85:e7:46:4b:
60:63:02:43:46:51:4d:ed:fd:a1:06:84:f1:4e:98:
32:da:27:ee:80:82:d4:6b:cf:31:ea:21:af:6f:bd:
70:34:e9:3f:d7:e4:24:cd:b8:e0:0f:8e:80:eb:11:
1f:bc:c5:7e:05:8e:5c:7b:96:26:f8:2c:17:30:7d:
08:9e:a4:72:66:f5:ca:23:2b:f2:ce:54:ec:4d:d9:
d9:81:72:80:19:95:57:da:91:00:d9:b1:e8:8c:33:
4a:9d:3c:4a:94:bf:74:4c:30:72:9b:1e:f5:8b:00:
4d:e3
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
F4:97:E0:00:47:2A:ED:0F:B8:EC:8C:0C:0B:90:89:
20:9A:FA:10:9B
Data:
Version: 3 (0x2)
Serial: 1500 (0x5dc)
Signature Algorithm: SHA256WithRSAEncryption
Issuer: CN=APNIC Production-CVPQSgUkLy7pOXdNeVWGvnFX_0s
Validity
Not Before: Oct 25 12:50:00 2008 GMT
Not After : Jan 31 00:00:00 2010 GMT
Subject: CN=A91872ED
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:bb:fb:4a:af:a4:b9:dc:d0:fa:6f:67:cc:27:39:
34:d1:80:40:37:de:88:d1:64:a2:f1:b3:fa:c6:7f:
bb:51:df:e1:c7:13:92:c3:c8:a2:aa:8c:d1:11:b3:
aa:99:c0:ac:54:d3:65:83:c6:13:bf:0d:9f:33:2d:
39:9f:ab:5f:cd:a3:e9:a1:fb:80:7d:1d:d0:2b:48:
a5:55:e6:24:1f:06:41:35:1d:00:da:1f:99:85:13:
26:39:24:c5:9a:81:15:98:fb:5f:f9:84:38:e5:d6:
70:ce:5a:02:ca:dd:61:85:b3:43:2d:0b:35:d5:91:
98:9d:da:1e:0f:c2:f6:97:b7:97:3e:e6:fc:c1:c4:
3f:30:c4:81:03:25:99:09:4c:e2:4a:85:e7:46:4b:
60:63:02:43:46:51:4d:ed:fd:a1:06:84:f1:4e:98:
32:da:27:ee:80:82:d4:6b:cf:31:ea:21:af:6f:bd:
70:34:e9:3f:d7:e4:24:cd:b8:e0:0f:8e:80:eb:11:
1f:bc:c5:7e:05:8e:5c:7b:96:26:f8:2c:17:30:7d:
08:9e:a4:72:66:f5:ca:23:2b:f2:ce:54:ec:4d:d9:
d9:81:72:80:19:95:57:da:91:00:d9:b1:e8:8c:33:
4a:9d:3c:4a:94:bf:74:4c:30:72:9b:1e:f5:8b:00:
4d:e3
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
F4:97:E0:00:47:2A:ED:0F:B8:EC:8C:0C:0B:90:89:
20:9A:FA:10:9B
X509v3 Authority Key Identifier:
keyid:09:53:D0:4A:05:24:2F:2E:E9:39:77:4D:79:
55:86:BE:71:57:FF:4B
X509v3 Authority Key Identifier:
keyid:09:53:D0:4A:05:24:2F:2E:E9:39:77:4D:79:
55:86:BE:71:57:FF:4B
X509v3 Key Usage: critical Certificate Sign, CRL Sign
X509v3密钥用法：关键证书标志、CRL标志
X509v3 Basic Constraints: critical CA:TRUE
X509v3基本约束：关键CA:真
X509v3 CRL Distribution Points:
URI:rsync://rpki.apnic.net/repository/A3C38A24
D60311DCAB08F31979BDBE39/CVPQSgUkLy7pOXdNe
VWGvnFX_0s.crl
X509v3 CRL Distribution Points:
URI:rsync://rpki.apnic.net/repository/A3C38A24
D60311DCAB08F31979BDBE39/CVPQSgUkLy7pOXdNe
VWGvnFX_0s.crl
Authority Information Access:
CA Issuers - URI:rsync://rpki.apnic.net/repos
itory/8BDFC7DED5FD11DCB14CF4B1A703F9B7/CVP
QSgUkLy7pOXdNeVWGvnFX_0s.cer
Authority Information Access:
CA Issuers - URI:rsync://rpki.apnic.net/repos
itory/8BDFC7DED5FD11DCB14CF4B1A703F9B7/CVP
QSgUkLy7pOXdNeVWGvnFX_0s.cer
X509v3 Certificate Policies: critical Policy: 1.3.6.1.5.5.7.14.2
X509v3证书策略：关键策略：1.3.6.1.5.5.7.14.2
Subject Information Access:
CA Repository - URI:rsync://rpki.apnic.net/mem
ber_repository/A91872ED/06A83982887911DD81
3F432B2086D636/
Manifest - URI:rsync://rpki.apnic.net/member_r
epository/A91872ED/06A83982887911DD813F432
B2086D636/9JfgAEcq7Q-47IwMC5CJIJr6EJs.mft
Subject Information Access:
CA Repository - URI:rsync://rpki.apnic.net/mem
ber_repository/A91872ED/06A83982887911DD81
3F432B2086D636/
Manifest - URI:rsync://rpki.apnic.net/member_r
epository/A91872ED/06A83982887911DD813F432
B2086D636/9JfgAEcq7Q-47IwMC5CJIJr6EJs.mft
sbgp-autonomousSysNum: critical Autonomous System Numbers: 24021 38610 131072 131074
sbgp自治系统编号：关键自治系统编号：24021 38610 131072 131074
sbgp-ipAddrBlock: critical IPv4: 203.133.248.0/22 203.147.108.0/23
sbgp IPAddressBlock:关键IPv4:203.133.248.0/22 203.147.108.0/23
Signature Algorithm: sha256WithRSAEncryption
51:4c:77:e4:21:64:80:e9:35:30:20:9f:d8:4b:88:60:b8:1f:
73:24:9d:b5:17:60:65:6a:28:cc:43:4b:68:97:ca:76:07:eb:
dc:bd:a2:08:3c:8c:56:38:c6:0a:1e:a8:af:f5:b9:42:02:6b:
77:e0:b1:1c:4a:88:e6:6f:b6:17:d3:59:41:d7:a0:62:86:59:
29:79:26:76:34:d1:16:2d:75:05:cb:b2:99:bf:ca:c6:68:1b:
b6:a9:b0:f4:43:2e:df:e3:7f:3c:b3:72:1a:99:fa:5d:94:a1:
eb:57:9c:9a:2c:87:d6:40:32:c9:ff:a6:54:b8:91:87:fd:90:
55:ef:12:3e:1e:2e:cf:c5:ea:c3:4c:09:62:4f:88:00:a0:7f:
cd:67:83:bc:27:e1:74:2c:18:4e:3f:12:1d:ef:29:0f:e3:27:
00:ce:14:eb:f0:01:f0:36:25:a2:33:a8:c6:2f:31:18:22:30:
cf:ca:97:43:ed:84:75:53:ab:b7:6c:75:f7:2f:55:5c:2e:82:
0a:be:91:59:bf:c9:06:ef:bb:b4:a2:71:9e:03:b1:25:8e:29:
7a:30:88:66:b4:f2:16:6e:df:ad:78:ff:d3:b2:9c:29:48:e3:
be:87:5c:fc:20:2b:df:da:ca:30:58:c3:04:c9:63:72:48:8c:
0a:5f:97:71
Signature Algorithm: sha256WithRSAEncryption
51:4c:77:e4:21:64:80:e9:35:30:20:9f:d8:4b:88:60:b8:1f:
73:24:9d:b5:17:60:65:6a:28:cc:43:4b:68:97:ca:76:07:eb:
dc:bd:a2:08:3c:8c:56:38:c6:0a:1e:a8:af:f5:b9:42:02:6b:
77:e0:b1:1c:4a:88:e6:6f:b6:17:d3:59:41:d7:a0:62:86:59:
29:79:26:76:34:d1:16:2d:75:05:cb:b2:99:bf:ca:c6:68:1b:
b6:a9:b0:f4:43:2e:df:e3:7f:3c:b3:72:1a:99:fa:5d:94:a1:
eb:57:9c:9a:2c:87:d6:40:32:c9:ff:a6:54:b8:91:87:fd:90:
55:ef:12:3e:1e:2e:cf:c5:ea:c3:4c:09:62:4f:88:00:a0:7f:
cd:67:83:bc:27:e1:74:2c:18:4e:3f:12:1d:ef:29:0f:e3:27:
00:ce:14:eb:f0:01:f0:36:25:a2:33:a8:c6:2f:31:18:22:30:
cf:ca:97:43:ed:84:75:53:ab:b7:6c:75:f7:2f:55:5c:2e:82:
0a:be:91:59:bf:c9:06:ef:bb:b4:a2:71:9e:03:b1:25:8e:29:
7a:30:88:66:b4:f2:16:6e:df:ad:78:ff:d3:b2:9c:29:48:e3:
be:87:5c:fc:20:2b:df:da:ca:30:58:c3:04:c9:63:72:48:8c:
0a:5f:97:71
The following is an example Certificate Revocation List.
以下是证书吊销列表的示例。
CRL Name: q66IrWSGuBE7jqx8PAUHAlHCqRw.crl
Data:
Version: 2
Signature Algorithm:
Hash: SHA256, Encryption: RSA
Issuer: CN=Demo Production APNIC CA - Not for real use,
E=ca@apnic.net
This Update: Thu Jul 27 06:30:34 2006 GMT
Next Update: Fri Jul 28 06:30:34 2006 GMT
Authority Key Identifier: Key Identifier:
ab:ae:88:ad:64:86:b8:11:3b:8e:ac:7c:3c:05:
07:02:51:c2:a9:1c
CRLNumber: 4
Revoked Certificates: 1
Serial Number: 1
Revocation Date: Mon Jul 17 05:10:19 2006 GMT
Serial Number: 2
Revocation Date: Mon Jul 17 05:12:25 2006 GMT
Serial Number: 4
Revocation Date: Mon Jul 17 05:40:39 2006 GMT
Signature:
b2:5a:e8:7c:bd:a8:00:0f:03:1a:17:fd:40:2c:46:
0e:d5:64:87:e7:e7:bc:10:7d:b6:3e:39:21:a9:12:
f4:5a:d8:b8:d4:bd:57:1a:7d:2f:7c:0d:c6:4f:27:
17:c8:0e:ae:8c:89:ff:00:f7:81:97:c3:a1:6a:0a:
f7:d2:46:06:9a:d1:d5:4d:78:e1:b7:b0:58:4d:09:
d6:7c:1e:a0:40:af:86:5d:8c:c9:48:f6:e6:20:2e:
b9:b6:81:03:0b:51:ac:23:db:9f:c1:8e:d6:94:54:
66:a5:68:52:ee:dd:0f:10:5d:21:b8:b8:19:ff:29:
6f:51:2e:c8:74:5c:2a:d2:c5:fa:99:eb:c5:c2:a2:
d0:96:fc:54:b3:ba:80:4b:92:7f:85:54:76:c9:12:
cb:32:ea:1d:12:7b:f8:f9:a2:5c:a1:b1:06:8e:d8:
c5:42:61:00:8c:f6:33:11:29:df:6e:b2:cc:c3:7c:
d3:f3:0c:8d:5c:49:a5:fb:49:fd:e7:c4:73:68:0a:
09:0e:6d:68:a9:06:52:3a:36:4f:19:47:83:59:da:
02:5b:2a:d0:8a:7a:33:0a:d5:ce:be:b5:a2:7d:8d:
59:a1:9d:ee:60:ce:77:3d:e1:86:9a:84:93:90:9f:
34:a7:02:40:59:3a:a5:d1:18:fb:6f:fc:af:d4:02:
d9
CRL Name: q66IrWSGuBE7jqx8PAUHAlHCqRw.crl
Data:
Version: 2
Signature Algorithm:
Hash: SHA256, Encryption: RSA
Issuer: CN=Demo Production APNIC CA - Not for real use,
E=ca@apnic.net
This Update: Thu Jul 27 06:30:34 2006 GMT
Next Update: Fri Jul 28 06:30:34 2006 GMT
Authority Key Identifier: Key Identifier:
ab:ae:88:ad:64:86:b8:11:3b:8e:ac:7c:3c:05:
07:02:51:c2:a9:1c
CRLNumber: 4
Revoked Certificates: 1
Serial Number: 1
Revocation Date: Mon Jul 17 05:10:19 2006 GMT
Serial Number: 2
Revocation Date: Mon Jul 17 05:12:25 2006 GMT
Serial Number: 4
Revocation Date: Mon Jul 17 05:40:39 2006 GMT
Signature:
b2:5a:e8:7c:bd:a8:00:0f:03:1a:17:fd:40:2c:46:
0e:d5:64:87:e7:e7:bc:10:7d:b6:3e:39:21:a9:12:
f4:5a:d8:b8:d4:bd:57:1a:7d:2f:7c:0d:c6:4f:27:
17:c8:0e:ae:8c:89:ff:00:f7:81:97:c3:a1:6a:0a:
f7:d2:46:06:9a:d1:d5:4d:78:e1:b7:b0:58:4d:09:
d6:7c:1e:a0:40:af:86:5d:8c:c9:48:f6:e6:20:2e:
b9:b6:81:03:0b:51:ac:23:db:9f:c1:8e:d6:94:54:
66:a5:68:52:ee:dd:0f:10:5d:21:b8:b8:19:ff:29:
6f:51:2e:c8:74:5c:2a:d2:c5:fa:99:eb:c5:c2:a2:
d0:96:fc:54:b3:ba:80:4b:92:7f:85:54:76:c9:12:
cb:32:ea:1d:12:7b:f8:f9:a2:5c:a1:b1:06:8e:d8:
c5:42:61:00:8c:f6:33:11:29:df:6e:b2:cc:c3:7c:
d3:f3:0c:8d:5c:49:a5:fb:49:fd:e7:c4:73:68:0a:
09:0e:6d:68:a9:06:52:3a:36:4f:19:47:83:59:da:
02:5b:2a:d0:8a:7a:33:0a:d5:ce:be:b5:a2:7d:8d:
59:a1:9d:ee:60:ce:77:3d:e1:86:9a:84:93:90:9f:
34:a7:02:40:59:3a:a5:d1:18:fb:6f:fc:af:d4:02:
d9
Authors' Addresses
作者地址
Geoff Huston APNIC
杰夫·休斯顿呼吸暂停
EMail: gih@apnic.net
URI: http://www.apnic.net
EMail: gih@apnic.net
URI: http://www.apnic.net
George Michaelson APNIC
乔治·迈克尔森呼吸暂停综合征
EMail: ggm@apnic.net
URI: http://www.apnic.net
EMail: ggm@apnic.net
URI: http://www.apnic.net
Robert Loomans APNIC
罗伯特·卢曼斯呼吸暂停综合征
EMail: robertl@apnic.net
URI: http://www.apnic.net
EMail: robertl@apnic.net
URI: http://www.apnic.net