Network Working Group C. Lynn
Request for Comments: 3779 S. Kent
Category: Standards Track K. Seo
BBN Technologies
June 2004
Network Working Group C. Lynn
Request for Comments: 3779 S. Kent
Category: Standards Track K. Seo
BBN Technologies
June 2004
X.509 Extensions for IP Addresses and AS Identifiers
X.509 IP地址和AS标识符的扩展
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document defines two X.509 v3 certificate extensions. The first binds a list of IP address blocks, or prefixes, to the subject of a certificate. The second binds a list of autonomous system identifiers to the subject of a certificate. These extensions may be used to convey the authorization of the subject to use the IP addresses and autonomous system identifiers contained in the extensions.
本文档定义了两个X.509 v3证书扩展。第一种方法将IP地址块或前缀列表绑定到证书的主题。第二种方法将自治系统标识符列表绑定到证书的主题。这些扩展可用于传达主体使用扩展中包含的IP地址和自主系统标识符的授权。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3
2. IP Address Delegation Extension. . . . . . . . . . . . . . . . 5
2.1. Context. . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Encoding of an IP Address or Prefix. . . . . . . 5
2.1.2. Encoding of a Range of IP Addresses. . . . . . . 7
2.2. Specification. . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. OID. . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2. Criticality. . . . . . . . . . . . . . . . . . . 9
2.2.3. Syntax . . . . . . . . . . . . . . . . . . . . . 9
2.2.3.1. Type IPAddrBlocks. . . . . . . . . . . 9
2.2.3.2. Type IPAddressFamily . . . . . . . . . 9
2.2.3.3. Element addressFamily. . . . . . . . . 10
2.2.3.4. Element ipAddressChoice and Type
IPAddressChoice. . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3
2. IP Address Delegation Extension. . . . . . . . . . . . . . . . 5
2.1. Context. . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Encoding of an IP Address or Prefix. . . . . . . 5
2.1.2. Encoding of a Range of IP Addresses. . . . . . . 7
2.2. Specification. . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. OID. . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2. Criticality. . . . . . . . . . . . . . . . . . . 9
2.2.3. Syntax . . . . . . . . . . . . . . . . . . . . . 9
2.2.3.1. Type IPAddrBlocks. . . . . . . . . . . 9
2.2.3.2. Type IPAddressFamily . . . . . . . . . 9
2.2.3.3. Element addressFamily. . . . . . . . . 10
2.2.3.4. Element ipAddressChoice and Type
IPAddressChoice. . . . . . . . . . . . 10
2.2.3.5. Element inherit. . . . . . . . . . . . 10
2.2.3.6. Element addressesOrRanges. . . . . . . 10
2.2.3.7. Type IPAddressOrRange. . . . . . . . . 11
2.2.3.8. Element addressPrefix and Type
IPAddress. . . . . . . . . . . . . . . 11
2.2.3.9. Element addressRange and Type
IPAddressRange . . . . . . . . . . . . 12
2.3. IP Address Delegation Extension Certification Path
Validation . . . . . . . . . . . . . . . . . . . . . . . 12
3. Autonomous System Identifier Delegation Extension. . . . . . . 13
3.1. Context . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Specification. . . . . . . . . . . . . . . . . . . . . . 13
3.2.1. OID. . . . . . . . . . . . . . . . . . . . . . . 13
3.2.2. Criticality. . . . . . . . . . . . . . . . . . . 14
3.2.3. Syntax . . . . . . . . . . . . . . . . . . . . . 14
3.2.3.1. Type ASIdentifiers . . . . . . . . . . 14
3.2.3.2. Elements asnum, rdi, and Type
ASIdentifierChoice . . . . . . . . . . 14
3.2.3.3. Element inherit. . . . . . . . . . . . 15
3.2.3.4. Element asIdsOrRanges. . . . . . . . . 15
3.2.3.5. Type ASIdOrRange . . . . . . . . . . . 15
3.2.3.6. Element id . . . . . . . . . . . . . . 15
3.2.3.7. Element range. . . . . . . . . . . . . 15
3.2.3.8. Type ASRange . . . . . . . . . . . . . 15
3.2.3.9. Elements min and max . . . . . . . . . 15
3.2.3.10. Type ASId. . . . . . . . . . . . . . . 15
3.3. Autonomous System Identifier Delegation Extension
Certification Path Validation. . . . . . . . . . . . . . . . 16
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 16
5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 16
Appendix A -- ASN.1 Module . . . . . . . . . . . . . . . . . . . . 17
Appendix B -- Examples of IP Address Delegation Extensions . . . . 18
Appendix C -- Example of an AS Identifier Delegation Extension . . 21
Appendix D -- Use of X.509 Attribute Certificates. . . . . . . . . 21
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Normative References . . . . . . . . . . . . . . . . . . . . . . . 24
Informative References . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 27
2.2.3.5. Element inherit. . . . . . . . . . . . 10
2.2.3.6. Element addressesOrRanges. . . . . . . 10
2.2.3.7. Type IPAddressOrRange. . . . . . . . . 11
2.2.3.8. Element addressPrefix and Type
IPAddress. . . . . . . . . . . . . . . 11
2.2.3.9. Element addressRange and Type
IPAddressRange . . . . . . . . . . . . 12
2.3. IP Address Delegation Extension Certification Path
Validation . . . . . . . . . . . . . . . . . . . . . . . 12
3. Autonomous System Identifier Delegation Extension. . . . . . . 13
3.1. Context . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Specification. . . . . . . . . . . . . . . . . . . . . . 13
3.2.1. OID. . . . . . . . . . . . . . . . . . . . . . . 13
3.2.2. Criticality. . . . . . . . . . . . . . . . . . . 14
3.2.3. Syntax . . . . . . . . . . . . . . . . . . . . . 14
3.2.3.1. Type ASIdentifiers . . . . . . . . . . 14
3.2.3.2. Elements asnum, rdi, and Type
ASIdentifierChoice . . . . . . . . . . 14
3.2.3.3. Element inherit. . . . . . . . . . . . 15
3.2.3.4. Element asIdsOrRanges. . . . . . . . . 15
3.2.3.5. Type ASIdOrRange . . . . . . . . . . . 15
3.2.3.6. Element id . . . . . . . . . . . . . . 15
3.2.3.7. Element range. . . . . . . . . . . . . 15
3.2.3.8. Type ASRange . . . . . . . . . . . . . 15
3.2.3.9. Elements min and max . . . . . . . . . 15
3.2.3.10. Type ASId. . . . . . . . . . . . . . . 15
3.3. Autonomous System Identifier Delegation Extension
Certification Path Validation. . . . . . . . . . . . . . . . 16
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 16
5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 16
Appendix A -- ASN.1 Module . . . . . . . . . . . . . . . . . . . . 17
Appendix B -- Examples of IP Address Delegation Extensions . . . . 18
Appendix C -- Example of an AS Identifier Delegation Extension . . 21
Appendix D -- Use of X.509 Attribute Certificates. . . . . . . . . 21
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Normative References . . . . . . . . . . . . . . . . . . . . . . . 24
Informative References . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 27
This document defines two X.509 v3 certificate extensions that authorize the transfer of the right-to-use for a set of IP addresses and autonomous system identifiers from IANA through the regional Internet registries (RIRs) to Internet service providers (ISPs) and user organizations. The first binds a list of IP address blocks, often represented as IP address prefixes, to the subject (private key holder) of a certificate. The second binds a list of autonomous system (AS) identifiers to the subject (private key holder) of a certificate. The issuer of the certificate is an entity (e.g., the IANA, a regional Internet registry, or an ISP) that has the authority to transfer custodianship of ("allocate") the set of IP address blocks and AS identifiers to the subject of the certificate. These certificates provide a scalable means of verifying the right-to-use for a set of IP address prefixes and AS identifiers. They may be used by routing protocols, such as Secure BGP [S-BGP], to verify legitimacy and correctness of routing information, or by Internet routing registries to verify data that they receive.
本文件定义了两个X.509 v3证书扩展，授权将IP地址和自治系统标识符的使用权通过区域互联网注册中心（RIR）从IANA转移到互联网服务提供商（ISP）和用户组织。第一种方法将IP地址块列表（通常表示为IP地址前缀）绑定到证书的主题（私钥持有者）。第二种方法将自治系统（AS）标识符列表绑定到证书的主体（私钥持有者）。证书的颁发者是一个实体（如IANA、区域互联网注册中心或ISP），该实体有权将IP地址块集的保管权（“分配”）以及作为标识符转移给证书的主体。这些证书提供了一种可扩展的方法来验证一组IP地址前缀和作为标识符的使用权。它们可以被路由协议（如安全BGP[S-BGP]）用来验证路由信息的合法性和正确性，或者被互联网路由注册中心用来验证它们接收到的数据。
Sections 2 and 3 specify several rules about the encoding of the extensions defined in this specification that MUST be followed. These encoding rules serve the following purposes. First, they result in a unique encoding of the extension's value; two instances of an extension can be compared for equality octet-by-octet. Second, they achieve the minimal size encoding of the information. Third, they allow relying parties to use one-pass algorithms when performing certification path validation; in particular, the relying parties do not need to sort the information, or to implement extra code in the subset checking algorithms to handle several boundary cases (adjacent, overlapping, or subsumed ranges).
第2节和第3节规定了关于本规范中定义的扩展的编码必须遵循的若干规则。这些编码规则用于以下目的。首先，它们导致扩展值的唯一编码；一个扩展的两个实例可以逐个八位字节进行比较。其次，它们实现了信息的最小大小编码。第三，它们允许依赖方在执行认证路径验证时使用一次性算法；特别是，依赖方不需要对信息进行排序，也不需要在子集检查算法中实现额外的代码来处理多个边界情况（相邻、重叠或包含的范围）。
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" [RFC3280], "INTERNET PROTOCOL" [RFC791], "Internet Protocol Version 6 (IPv6) Addressing Architecture" [RFC3513], "INTERNET REGISTRY IP ALLOCATION GUIDELINES" [RFC2050], and related regional Internet registry address management policy documents. Some relevant terms include:
假定读者熟悉“Internet X.509公钥基础设施证书和证书吊销列表（CRL）配置文件”[RFC3280]、“Internet协议”[RFC791]、“Internet协议版本6（IPv6）寻址体系结构”[RFC3513]、“Internet注册表IP分配指南”中描述的术语和概念[RFC2050]和相关的区域Internet注册表地址管理策略文件。一些相关术语包括：
allocate - the transfer of custodianship of a resource to an intermediate organization (see [RFC2050]).
分配-将资源的保管权转移给中间组织（参见[RFC2050]）。
assign - the transfer of custodianship of a resource to an end organization (see [RFC2050]).
分配-将资源的保管权转移给最终组织（参见[RFC2050]）。
Autonomous System (AS) - a set of routers under a single technical administration with a uniform policy, using one or more interior gateway protocols and metrics to determine how to route packets within the autonomous system, and using an exterior gateway protocol to determine how to route packets to other autonomous systems.
自治系统（AS）-在单一技术管理下的一组路由器，具有统一的策略，使用一个或多个内部网关协议和度量来确定如何在自治系统内路由数据包，并使用外部网关协议来确定如何将数据包路由到其他自治系统。
Autonomous System number - a 32-bit number that identifies an autonomous system.
自治系统编号-标识自治系统的32位编号。
delegate - transfer of custodianship (that is, the right-to-use) of an IP address block or AS identifier through issuance of a certificate to an entity.
委托-通过向实体颁发证书，将IP地址块或作为标识符的保管权（即使用权）转移。
initial octet - the first octet in the value of a DER encoded BIT STRING [X.690].
初始八位字节-DER编码位字符串[X.690]值中的第一个八位字节。
IP v4 address - a 32-bit identifier written as four decimal numbers, each in the range 0 to 255, separated by a ".". 10.5.0.5 is an example of an IPv4 address.
IP v4地址-一个32位标识符，写为四个十进制数字，每个数字的范围在0到255之间，用“.”分隔。10.5.0.5是IPv4地址的一个示例。
IP v6 address - a 128-bit identifier written as eight hexadecimal quantities, each in the range 0 to ffff, separated by a ":". 2001:0:200:3:0:0:0:1 is an example of an IPv6 address. One string of :0: fields may be replaced by "::", thus 2001:0:200:3::1 represents the same address as the immediately preceding example. (See [RFC3513]).
IP v6地址—一个128位标识符，写为八个十六进制数，每个数的范围为0到ffff，用“：”分隔。2001:0:200:3:0:0:0:1是IPv6地址的一个示例。一个：0:字段字符串可以替换为“：”，因此2001:0:200:3:：1表示与前面示例相同的地址。（见[RFC3513]）。
prefix - a bit string that consists of some number of initial bits of an address, written as an address followed by a "/", and the number of initial bits. 10.5.0.0/16 and 2001:0:200:3:0:0:0:0/64 (or 2001:0:200:3::/64) are examples of prefixes. A prefix is often abbreviated by omitting the less-significant zero fields, but there should be enough fields to contain the indicated number of initial bits. 10.5/16 and 2001:0:200:3/64 are examples of abbreviated prefixes.
前缀-由地址的一些初始位组成的位字符串，写为地址，后跟“/”和初始位的数量。10.5.0.0/16和2001:0:200:3:0:0:0/64（或2001:0:200:3:：/64）是前缀的示例。前缀通常通过省略不太重要的零字段来缩写，但是应该有足够的字段来包含指定数量的初始位。10.5/16和2001:0:200:3/64是缩写前缀的示例。
Regional Internet Registry (RIR) - any of the bodies recognized by IANA as the regional authorities for management of IP addresses and AS identifiers. At the time of writing, these include AfriNIC, APNIC, ARIN, LACNIC, and RIPE NCC.
区域互联网注册处（RIR）-IANA认可的任何机构，作为IP地址和标识符管理的区域机构。在撰写本文时，这些药物包括AfriNIC、APNIC、ARIN、LACNIC和成熟的NCC。
right-to-use - for an IP address prefix, being authorized to specify the AS that may originate advertisements of the prefix throughout the Internet. For an autonomous system identifier, being authorized to operate a network(s) that identifies itself to other network operators using that autonomous system identifier.
使用权-对于IP地址前缀，授权指定可能在整个互联网上发布前缀广告的AS。对于自治系统标识符，被授权操作使用该自治系统标识符向其他网络运营商标识其自身的网络。
subsequent octets - the second through last octets in the value of a DER encoded BIT STRING [X.690].
后续八位字节-DER编码位字符串[X.690]值中的第二个到最后一个八位字节。
trust anchor - a certificate that is to be trusted when performing certification path validation (see [RFC3280]).
信任锚-在执行证书路径验证时要信任的证书（请参阅[RFC3280]）。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, and MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、建议、可能和可选时，应按照[RFC2119]中的说明进行解释。
This extension conveys the allocation of IP addresses to an entity by binding those addresses to a public key belonging to the entity.
此扩展通过将IP地址绑定到属于实体的公钥，将IP地址分配给实体。
IP address space is currently managed by a hierarchy nominally rooted at IANA, but managed by the RIRs. IANA allocates IP address space to the RIRs, who in turn allocate IP address space to Internet service providers (ISPs), who may allocate IP address space to down stream providers, customers, etc. The RIRs also may assign IP address space to organizations who are end entities, i.e., organizations who will not be reassigning any of their space to other organizations. (See [RFC2050] and related RIR policy documents for the guidelines on the allocation and assignment process).
IP地址空间目前由名义上植根于IANA的层次结构管理，但由RIRs管理。IANA将IP地址空间分配给RIR，RIR将IP地址空间分配给互联网服务提供商（ISP），ISP可将IP地址空间分配给下游提供商、客户等。RIR还可将IP地址空间分配给作为最终实体的组织，即：。，不会将其任何空间重新分配给其他组织的组织。（有关分配和分配流程的指南，请参见[RFC2050]和相关RIR政策文件）。
The IP address delegation extension is intended to enable verification of the proper delegation of IP address blocks, i.e., of the authorization of an entity to use or sub-allocate IP address space. Accordingly, it makes sense to take advantage of the inherent authoritativeness of the existing administrative framework for allocating IP address space. As described in Section 1 above, this will be achieved by issuing certificates carrying the extension described in this section. An example of one use of the information in this extension is an entity using it to verify the authorization of an organization to originate a BGP UPDATE advertising a path to a particular IP address block; see, e.g., [RFC1771], [S-BGP].
IP地址授权扩展旨在验证IP地址块的正确授权，即实体使用或分配IP地址空间的授权。因此，利用现有管理框架分配IP地址空间的固有权威性是有意义的。如上文第1节所述，这将通过签发带有本节所述扩展名的证书来实现。在该扩展中使用信息的一个示例是实体使用该信息来验证组织发起BGP更新的授权，该BGP更新宣传到特定IP地址块的路径；例如，参见[RFC1771]，[S-BGP]。
There are two families of IP addresses: IPv4 and IPv6.
有两类IP地址：IPv4和IPv6。
An IPv4 address is a 32-bit quantity that is written as four decimal numbers, each in the range 0 through 255, separated by a dot ("."). 10.5.0.5 is an example of an IPv4 address.
IPv4地址是一个32位的数字，以四个十进制数字的形式写入，每个数字的范围为0到255，以点（“.”分隔。10.5.0.5是IPv4地址的一个示例。
An IPv6 address is a 128-bit quantity that is written as eight hexadecimal numbers, each in the range 0 through ffff, separated by a semicolon (":"); 2001:0:200:3:0:0:0:1 is an example of an IPv6 address. IPv6 addresses frequently have adjacent fields whose value is 0. One such group of 0 fields may be abbreviated by two semicolons ("::"). The previous example may thus be represented by 2001:0:200:3::1.
IPv6地址是一个128位的数量，以八个十六进制数字的形式写入，每个数字的范围为0到ffff，以分号（“：”）分隔；2001:0:200:3:0:0:0:1是IPv6地址的一个示例。IPv6地址通常具有值为0的相邻字段。一组这样的0字段可以用两个分号（“：”）缩写。因此，前面的示例可以用2001:0:200:3:：1表示。
An address prefix is a set of 2^k continuous addresses whose most-significant bits are identical. For example, the set of 512 IPv4 addresses from 10.5.0.0 through 10.5.1.255 all have the same 23 most-significant bits. The set of addresses is written by appending a slash ("/") and the number of constant bits to the lowest address in the set. The prefix for the example set is 10.5.0.0/23, and contains 2^(32-23) = 2^9 addresses. The set of IPv6 addresses 2001:0:200:0:0:0:0:0 through 2001:0:3ff:ffff:ffff:ffff:ffff:ffff (2^89 addresses) is represented by 2001:0:200:0:0:0:0:0/39 or equivalently 2001:0:200::/39. A prefix may be abbreviated by omitting the least-significant zero fields, but there should be enough fields to contain the indicated number of constant bits. The abbreviated forms of the example IPv4 prefix is 10.5.0/23, and of the example IPv6 prefix is 2001:0:200/39.
地址前缀是一组最高有效位相同的2^k连续地址。例如，从10.5.0.0到10.5.1.255的512个IPv4地址集都具有相同的23个最高有效位。地址集是通过在该集的最低地址上附加一个斜杠（“/”）和常量位数来写入的。示例集的前缀为10.5.0.0/23，包含2^（32-23）=2^9个地址。IPv6地址集2001:0:200:0:0:0:0:0到2001:0:3ff:ffff:ffff:ffff:ffff（2^89个地址）由2001:0:200:0:0:0:0:0/39或等效的2001:0:200:：/39表示。前缀可以通过省略最低有效零字段来缩写，但是应该有足够的字段来包含指定数量的常量位。示例IPv4前缀的缩写形式为10.5.0/23，示例IPv6前缀的缩写形式为2001:0:200/39。
An IP address or prefix is encoded in the IP address delegation extension as a DER-encoded ASN.1 BIT STRING containing the constant most-significant bits. Recall [X.690] that the DER encoding of a BIT STRING consists of the BIT STRING type (0x03), followed by (an encoding of) the number of value octets, followed by the value. The value consists of an "initial octet" that specifies the number of unused bits in the last value octet, followed by the "subsequent octets" that contain the octets of the bit string. (For IP addresses, the encoding of the length will be just the length.)
IP地址或前缀在IP地址委派扩展中编码为DER编码的ASN.1位字符串，其中包含常量最高有效位。回想一下[X.690]，位字符串的DER编码由位字符串类型（0x03）组成，后跟（编码）值八位字节数，后跟值。该值由一个“初始八位字节”组成，该八位字节指定最后一个值八位字节中未使用的位数，然后是包含位字符串八位字节的“后续八位字节”。（对于IP地址，长度的编码将仅为长度。）
In the case of a single address, all the bits are constant, so the bit string for an IPv4 address contains 32 bits. The subsequent octets in the DER-encoding of the address 10.5.0.4 are 0x0a 0x05 0x00 0x04. Since all the bits in the last octet are used, the initial octet is 0x00. The octets in the DER-encoded BIT STRING is thus:
对于单个地址，所有位都是常量，因此IPv4地址的位字符串包含32位。地址10.5.0.4的DER编码中的后续八位字节为0x0a 0x05 0x00 0x04。由于使用了最后一个八位字节中的所有位，因此初始八位字节为0x00。因此，DER编码位串中的八位字节为：
Type Len Unused Bits ... 0x03 0x05 0x00 0x0a 0x05 0x00 0x04
输入Len未使用的位。。。0x03 0x05 0x00 0x0a 0x05 0x00 0x04
Similarly, the DER-encoding of the prefix 10.5.0/23 is:
类似地，前缀10.5.0/23的DER编码是：
Type Len Unused Bits ... 0x03 0x04 0x01 0x0a 0x05 0x00
输入Len未使用的位。。。0x03 0x04 0x01 0x0a 0x05 0x00
In this case, the three subsequent octets contain 24 bits, but the prefix only uses 23, so there is one unused bit in the last octet, thus the initial octet is 1 (the DER require that all unused bits MUST be set to zero-bits).
在这种情况下，三个后续八位字节包含24位，但前缀仅使用23位，因此最后一个八位字节中有一个未使用的位，因此初始八位字节为1（DER要求所有未使用的位必须设置为零位）。
The DER-encoding of the IPv6 address 2001:0:200:3:0:0:0:1 is:
IPv6地址2001:0:200:3:0:0:0:0:1的DER编码为：
Type Len Unused Bits ... 0x03 0x11 0x00 0x20 0x01 0x00 0x00 0x02 0x00 0x00 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01
输入Len未使用的位。。。0x03 0x11 0x00 0x20 0x01 0x00 0x00 0x00 0x02 0x00 0x00 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01
and the DER-encoding of the prefix 2001:0:200/39, which has one unused bit in the last octet, is:
前缀2001:0:200/39在最后八位字节中有一个未使用的比特，其DER编码为：
Type Len Unused Bits ... 0x03 0x06 0x01 0x20 0x01 0x00 0x00 0x02
输入Len未使用的位。。。0x03 0x06 0x01 0x20 0x01 0x00 0x00 0x02
While any contiguous range of IP addresses can be represented by a set of contiguous prefixes, a more concise representation is achieved by encoding the range as a SEQUENCE containing the lowest address and the highest address, where each address is encoded as a BIT STRING. Within the SEQUENCE, the bit string representing the lowest address in the range is formed by removing all the least-significant zero-bits from the address, and the bit string representing the highest address in the range is formed by removing all the least-significant one-bits. The DER BIT STRING encoding requires that all the unused bits in the last octet MUST be set to zero-bits. Note that a prefix can always be expressed as a range, but a range cannot always be expressed as a prefix.
虽然IP地址的任何连续范围都可以由一组连续前缀表示，但通过将该范围编码为包含最低地址和最高地址的序列，可以实现更简洁的表示，其中每个地址都编码为位字符串。在该序列内，通过从该地址移除所有最低有效零位来形成表示该范围内最低地址的位串，并且通过移除所有最低有效一位来形成表示该范围内最高地址的位串。DER位字符串编码要求最后八位字节中所有未使用的位必须设置为零位。请注意，前缀始终可以表示为范围，但范围不能始终表示为前缀。
The range of addresses represented by the prefix 10.5.0/23 is 10.5.0.0 through 10.5.1.255. The lowest address ends in sixteen zero-bits that are removed. The DER-encoding of the resulting sixteen-bit string is:
前缀10.5.0/23表示的地址范围为10.5.0.0至10.5.1.255。最低地址以十六个被删除的零位结束。结果16位字符串的DER编码为：
Type Len Unused Bits ... 0x03 0x03 0x00 0x0a 0x05
输入Len未使用的位。。。0x03 0x03 0x00 0x0a 0x05
The highest address ends in nine one-bits that are removed. The DER-encoding of the resulting twenty-three-bit string is:
最高地址以删除的9个1位结尾。结果23位字符串的DER编码为：
Type Len Unused Bits ... 0x03 0x04 0x01 0x0a 0x05 0x00
输入Len未使用的位。。。0x03 0x04 0x01 0x0a 0x05 0x00
The prefix 2001:0:200/39 can be encoded as a range where the DER-encoding of the lowest address (2001:0:200::) is:
前缀2001:0:200/39可以编码为一个范围，其中最低地址（2001:0:200:：）的DER编码为：
Type Len Unused Bits ... 0x03 0x06 0x01 0x20 0x01 0x00 0x00 0x02
输入Len未使用的位。。。0x03 0x06 0x01 0x20 0x01 0x00 0x00 0x02
and the largest address (2001:0:3ff:ffff:ffff:ffff:ffff:ffff), which, after removal of the ninety least-significant one-bits leaves a thirty-eight bit string, is encoded as:
最大地址（2001:0:3ff:ffff:ffff:ffff:ffff:ffff）在去除90个最低有效位后留下38位字符串，编码为：
Type Len Unused Bits ... 0x03 0x06 0x02 0x20 0x01 0x00 0x00 0x00
输入Len未使用的位。。。0x03 0x06 0x02 0x20 0x01 0x00 0x00 0x00
The special case of all IP address blocks, i.e., a prefix of all zero-bits -- "0/0", MUST be encoded per the DER with a length octet of one, an initial octet of zero, and no subsequent octets:
所有IP地址块的特殊情况，即所有零位的前缀--“0/0”，必须按照DER进行编码，长度八位组为1，初始八位组为零，且无后续八位组：
Type Len Unused Bits ... 0x03 0x01 0x00
输入Len未使用的位。。。0x03 0x01 0x00
Note that for IP addresses the number of trailing zero-bits is significant. For example, the DER-encoding of 10.64/12:
请注意，对于IP地址，尾随零位的数量非常重要。例如，10.64/12的DER编码：
Type Len Unused Bits ... 0x03 0x03 0x04 0x0a 0x40
输入Len未使用的位。。。0x03 0x03 0x04 0x0a 0x40
is different than the DER-encoding of 10.64.0/20:
与10.64.0/20的DER编码不同：
Type Len Unused Bits ... 0x03 0x04 0x04 0x0a 0x40 0x00
输入Len未使用的位。。。0x03 0x04 0x04 0x0a 0x40 0x00
The OID for this extension is id-pe-ipAddrBlocks.
此扩展的OID是id pe IPAddressBlocks。
id-pe-ipAddrBlocks OBJECT IDENTIFIER ::= { id-pe 7 }
id-pe-ipAddrBlocks OBJECT IDENTIFIER ::= { id-pe 7 }
where [RFC3280] defines:
其中[RFC3280]定义：
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 }
This extension SHOULD be CRITICAL. The intended use of this extension is to connote a right-to-use for the block(s) of IP addresses identified in the extension. A CA marks the extension as CRITICAL to convey the notion that a relying party MUST understand the semantics of the extension to make use of the certificate for the purpose it was issued. Newly created applications that use certificates containing this extension are expected to recognize the extension.
这种扩展应该是至关重要的。此扩展的预期用途是指对扩展中标识的IP地址块的使用权。CA将扩展标记为传达依赖方必须理解扩展的语义才能将证书用于颁发目的这一概念的关键。使用包含此扩展的证书的新创建的应用程序应该能够识别该扩展。
id-pe-ipAddrBlocks OBJECT IDENTIFIER ::= { id-pe 7 }
id-pe-ipAddrBlocks OBJECT IDENTIFIER ::= { id-pe 7 }
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
The IPAddrBlocks type is a SEQUENCE OF IPAddressFamily types.
IPAddressBlocks类型是一系列IPAddressFamily类型。
The IPAddressFamily type is a SEQUENCE containing an addressFamily and ipAddressChoice element.
IPAddressFamily类型是包含addressFamily和ipAddressChoice元素的序列。
The addressFamily element is an OCTET STRING containing a two-octet Address Family Identifier (AFI), in network byte order, optionally followed by a one-octet Subsequent Address Family Identifier (SAFI). AFIs and SAFIs are specified in [IANA-AFI] and [IANA-SAFI], respectively.
addressFamily元素是一个八位字节字符串，包含两个八位字节的地址族标识符（AFI），按网络字节顺序排列，可选后跟一个八位字节的后续地址族标识符（SAFI）。[IANA-AFI]和[IANA-SAFI]中分别规定了AFI和SAFI。
If no authorization is being granted for a particular AFI and optional SAFI, then there MUST NOT be an IPAddressFamily member for that AFI/SAFI in the IPAddrBlocks SEQUENCE.
如果未为特定AFI和可选SAFI授予授权，则IPAddressBlocks序列中不得有该AFI/SAFI的IPAddressFamily成员。
There MUST be only one IPAddressFamily SEQUENCE per unique combination of AFI and SAFI. Each SEQUENCE MUST be ordered by ascending addressFamily values (treating the octets as unsigned quantities). An addressFamily without a SAFI MUST precede one that contains an SAFI. When both IPv4 and IPv6 addresses are specified, the IPv4 addresses MUST precede the IPv6 addresses (since the IPv4 AFI of 0001 is less than the IPv6 AFI of 0002).
每个AFI和SAFI的唯一组合只能有一个IPAddressFamily序列。每个序列必须按递增的addressFamily值排序（将八位字节视为无符号量）。没有SAFI的addressFamily必须位于包含SAFI的addressFamily之前。指定IPv4和IPv6地址时，IPv4地址必须位于IPv6地址之前（因为IPv4 AFI为0001小于IPv6 AFI为0002）。
The ipAddressChoice element is of type IPAddressChoice. The IPAddressChoice type is a CHOICE of either an inherit or addressesOrRanges element.
ipAddressChoice元素的类型为ipAddressChoice。IPAddressChoice类型是继承或AddressOrranges元素的选择。
If the IPAddressChoice CHOICE contains the inherit element, then the set of authorized IP addresses for the specified AFI and optional SAFI is taken from the issuer's certificate, or from the issuer's issuer's certificate, recursively, until a certificate containing an IPAddressChoice containing an addressesOrRanges element is located.
如果IPAddressChoice选项包含inherit元素，则指定AFI和可选SAFI的授权IP地址集将递归地从颁发者的证书或颁发者的颁发者的证书中获取，直到找到包含AddressOrranges元素的IPAddressChoice的证书为止。
The addressesOrRanges element is a SEQUENCE OF IPAddressOrRange types. The addressPrefix and addressRange elements MUST be sorted using the binary representation of:
AddressOrranges元素是IPAddressOrRange类型的序列。addressPrefix和addressRange元素必须使用以下二进制表示形式进行排序：
<lowest IP address in range> | <prefix length>
<lowest IP address in range> | <prefix length>
where "|" represents concatenation. Note that the octets in this representation (a.b.c.d | length for IPv4 or s:t:u:v:w:x:y:z | length for IPv6) are not the octets that are in the DER-encoded BIT STRING value. For example, given two addressPrefix:
其中“|”表示串联。请注意，此表示形式中的八位字节（IPv4为a.b.c.d|长度，IPv6为s:t:u:v:w:x:y:z |长度）不是DER编码位字符串值中的八位字节。例如，给定两个addressPrefix：
IP addr | length DER encoding
---------------- ------------------------
Type Len Unused Bits...
10.32.0.0 | 12 03 03 04 0a 20
10.64.0.0 | 16 03 03 00 0a 40
IP addr | length DER encoding
---------------- ------------------------
Type Len Unused Bits...
10.32.0.0 | 12 03 03 04 0a 20
10.64.0.0 | 16 03 03 00 0a 40
the prefix 10.32.0.0/12 MUST come before the prefix 10.64.0.0/16 since 32 is less than 64; whereas if one were to sort by the DER BIT STRINGs, the order would be reversed as the unused bits octet would sort in the opposite order. Any pair of IPAddressOrRange choices in an extension MUST NOT overlap each other. Any contiguous address prefixes or ranges MUST be combined into a single range or, whenever possible, a single prefix.
前缀10.32.0.0/12必须在前缀10.64.0.0/16之前，因为32小于64；然而，如果要按DER位字符串排序，则顺序将颠倒，因为未使用的位八位组将按相反的顺序排序。扩展中的任何一对IPAddressOrRange选项不得相互重叠。任何连续的地址前缀或范围必须组合成一个范围，或者尽可能组合成一个前缀。
The IPAddressOrRange type is a CHOICE of either an addressPrefix (an IP prefix or address) or an addressRange (an IP address range) element.
IPAddressOrRange类型可以选择addressPrefix（IP前缀或地址）或addressRange（IP地址范围）元素。
This specification requires that any range of addresses that can be encoded as a prefix MUST be encoded using an IPAddress element (a BIT STRING), and any range that cannot be encoded as a prefix MUST be encoded using an IPAddressRange (a SEQUENCE containing two BIT STRINGs). The following pseudo code illustrates how to select the encoding of a given range of addresses.
本规范要求可以编码为前缀的任何地址范围必须使用IPAddress元素（位字符串）进行编码，不能编码为前缀的任何地址范围必须使用IPAddressRange（包含两个位字符串的序列）进行编码。下面的伪代码说明了如何选择给定地址范围的编码。
LET N = the number of matching most-significant bits in the lowest and highest addresses of the range IF all the remaining bits in the lowest address are zero-bits AND all the remaining bits in the highest address are one-bits THEN the range MUST be encoded as an N-bit IPAddress ELSE the range MUST be encoded as an IPAddressRange
设N=范围最低和最高地址中匹配的最高有效位的数量如果最低地址中的所有剩余位为零位，而最高地址中的所有剩余位为一位，则该范围必须编码为N位IPAddress，否则该范围必须编码为IPAddressRange
The addressPrefix element is an IPAddress type. The IPAddress type defines a range of IP addresses in which the most-significant (left-most) N bits of the address remain constant, while the remaining bits (32 - N bits for IPv4, or 128 - N bits for IPv6) may be either zero or one. For example, the IPv4 prefix 10.64/12 corresponds to the addresses 10.64.0.0 to 10.79.255.255, while 10.64/11 corresponds to 10.64.0.0 to 10.95.255.255. The IPv6 prefix 2001:0:2/48 represents addresses 2001:0:2:: to 2001:0:2:ffff:ffff:ffff:ffff:ffff.
addressPrefix元素是IPAddress类型。IPAddress类型定义了一个IP地址范围，其中地址的最高有效（最左侧）N位保持不变，而剩余位（IPv4为32-N位，IPv6为128-N位）可以是零或一。例如，IPv4前缀10.64/12对应于地址10.64.0.0至10.79.255.255，而10.64/11对应于地址10.64.0.0至10.95.255.255。IPv6前缀2001:0:2/48表示地址2001:0:2:：到2001:0:2:ffff:ffff:ffff:ffff:ffff。
An IP address prefix is encoded as a BIT STRING. The DER encoding of a BIT STRING uses the initial octet of the string to specify how many of the least-significant bits of the last subsequent octet are
IP地址前缀编码为位字符串。位字符串的DER编码使用字符串的初始八位字节来指定最后一个后续八位字节的最低有效位的数量
unused. The DER encoding specifies that these unused bits MUST be set to zero-bits.
未使用的。DER编码指定这些未使用的位必须设置为零位。
Example: 128.0.0.0 = 1000 0000.0000 0000.0000 0000.0000 0000 to 143.255 255 255 = 1000 1111.1111 1111.1111 1111.1111 1111 bit string to encode = 1000 Type Len Unused Bits ... Encoding = 0x03 0x02 0x04 0x80
示例：128.0.0.0=1000 0000.0000 0000.0000.0000 0000至143.255 255 255=1000 1111.1111 1111.1111 1111编码位串=1000类型Len未使用位。。。编码=0x03 0x02 0x04 0x80
The addressRange element is of type IPAddressRange. The IPAddressRange type consists of a SEQUENCE containing a minimum (element min) and maximum (element max) IP address. Each IP address is encoded as a BIT STRING. The semantic interpretation of the minimum address in an IPAddressRange is that all the unspecified bits (for the full length of the IP address) are zero-bits. The semantic interpretation of the maximum address is that all the unspecified bits are one-bits. The BIT STRING for the minimum address results from removing all the least-significant zero-bits from the minimum address. The BIT STRING for the maximum address results from removing all the least-significant one-bits from the maximum address.
addressRange元素的类型为IPAddressRange。IPAddressRange类型由包含最小（元素最小）和最大（元素最大）IP地址的序列组成。每个IP地址都编码为位字符串。IPAddressRange中最小地址的语义解释是所有未指定位（IP地址的全长）都是零位。最大地址的语义解释是所有未指定的位都是一位。最小地址的位字符串是从最小地址中删除所有最低有效零位的结果。最大地址的位字符串是从最大地址中删除所有最低有效位的结果。
Example:
129.64.0.0 = 1000 0001.0100 0000.0000 0000.0000 0000
to 143.255.255.255 = 1000 1111.1111 1111.1111 1111.1111 1111
minimum bit string = 1000 0001.01
maximum bit string = 1000
Encoding = SEQUENCE {
Type Len Unused Bits ...
min 0x03 0x03 0x06 0x81 0x40
max 0x03 0x02 0x04 0x80
}
Example:
129.64.0.0 = 1000 0001.0100 0000.0000 0000.0000 0000
to 143.255.255.255 = 1000 1111.1111 1111.1111 1111.1111 1111
minimum bit string = 1000 0001.01
maximum bit string = 1000
Encoding = SEQUENCE {
Type Len Unused Bits ...
min 0x03 0x03 0x06 0x81 0x40
max 0x03 0x02 0x04 0x80
}
To simplify the comparison of IP address blocks when performing certification path validation, a maximum IP address MUST contain at least one bit whose value is 1, i.e., the subsequent octets may not be omitted nor all zero.
为了在执行认证路径验证时简化IP地址块的比较，最大IP地址必须至少包含一个值为1的位，即后续八位字节不能省略，也不能全部为零。
Certification path validation of a certificate containing the IP address delegation extension requires additional processing. As each certificate in a path is validated, the IP addresses in the IP address delegation extension of that certificate MUST be subsumed by IP addresses in the IP address delegation extension in the issuer's certificate. Validation MUST fail when this is not the case. A
包含IP地址委派扩展的证书的证书路径验证需要额外的处理。当验证路径中的每个证书时，该证书的IP地址委派扩展中的IP地址必须包含在颁发者证书的IP地址委派扩展中的IP地址中。如果不是这样，验证必须失败。A.
certificate that is a trust anchor for certification path validation of certificates containing the IP address delegation extension, as well as all certificates along the path, MUST each contain the IP address delegation extension. The initial set of allowed address ranges is taken from the trust anchor certificate.
作为包含IP地址委派扩展的证书的证书路径验证的信任锚点的证书，以及路径上的所有证书，都必须包含IP地址委派扩展。允许的初始地址范围集取自信任锚证书。
This extension conveys the allocation of autonomous system (AS) identifiers to an entity by binding those AS identifiers to a public key belonging to the entity.
此扩展通过将自治系统（AS）标识符的分配绑定到属于实体的公钥，将其传递给实体。
AS identifier delegation is currently managed by a hierarchy nominally rooted at IANA, but managed by the RIRs. IANA allocates AS identifiers to the RIRs, who in turn assign AS identifiers to organizations who are end entities, i.e., will not be re-allocating any of their AS identifiers to other organizations. The AS identifier delegation extension is intended to enable verification of the proper delegation of AS identifiers, i.e., of the authorization of an entity to use these AS identifiers. Accordingly, it makes sense to take advantage of the inherent authoritativeness of the existing administrative framework for management of AS identifiers. As described in Section 1 above, this will be achieved by issuing certificates carrying the extension described in this section. An example of one use of the information in this extension is an entity using it to verify the authorization of an organization to manage the AS identified by an AS identifier in the extension. The use of this extension to represent assignment of AS identifiers is not intended to alter the procedures by which AS identifiers are managed, or when an AS should be used c.f., [RFC1930].
AS标识符委派目前由名义上植根于IANA的层次结构管理，但由RIRs管理。IANA将作为标识符分配给RIR，RIR将作为标识符分配给作为最终实体的组织，即不会将其任何AS标识符重新分配给其他组织。AS标识符授权扩展旨在验证AS标识符的正确授权，即实体使用这些标识符的授权。因此，利用现有管理AS标识符的行政框架固有的权威性是有意义的。如上文第1节所述，这将通过签发带有本节所述扩展名的证书来实现。在此扩展中使用信息的一个示例是实体使用它来验证组织管理扩展中AS标识符标识的AS的授权。使用此扩展来表示AS标识符的分配并不是为了改变管理AS标识符的过程，也不是为了改变AS应在何时使用c.f.[RFC1930]。
The OID for this extension is id-pe-autonomousSysIds.
此扩展的OID是id pe autonomousSysIds。
id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 8 }
id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 8 }
where [RFC3280] defines:
其中[RFC3280]定义：
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 }
This extension SHOULD be CRITICAL. The intended use of this extension is to connote a right-to-use for the AS identifiers in the extension. A CA marks the extension as CRITICAL to convey the notion that a relying party must understand the semantics of the extension to make use of the certificate for the purpose it was issued. Newly created applications that use certificates containing this extension are expected to recognize the extension.
这种扩展应该是至关重要的。此扩展的预期用途是暗示在扩展中使用AS标识符的权利。CA将扩展标记为传达依赖方必须理解扩展的语义才能将证书用于颁发目的这一概念的关键。使用包含此扩展的证书的新创建的应用程序应该能够识别该扩展。
id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 8 }
id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 8 }
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
The ASIdentifiers type is a SEQUENCE containing one or more forms of autonomous system identifiers -- AS numbers (in the asnum element) or routing domain identifiers (in the rdi element). When the ASIdentifiers type contains multiple forms of identifiers, the asnum entry MUST precede the rdi entry. AS numbers are used by BGP, and routing domain identifiers are specified in the IDRP [RFC1142].
ASIdentifiers类型是一个包含一种或多种形式的自治系统标识符的序列——如数字（在asnum元素中）或路由域标识符（在rdi元素中）。当ASIdentifiers类型包含多种形式的标识符时，asnum条目必须位于rdi条目之前。BGP使用数字，IDRP[RFC1142]中指定了路由域标识符。
The asnum and rdi elements are both of type ASIdentifierChoice. The ASIdentifierChoice type is a CHOICE of either the inherit or asIdsOrRanges element.
asnum和rdi元素都是ASIdentifierChoice类型。ASIdentifierChoice类型是继承或asIdsOrRanges元素的选择。
If the ASIdentifierChoice choice contains the inherit element, then the set of authorized AS identifiers is taken from the issuer's certificate, or from the issuer's issuer's certificate, recursively, until a certificate containing an ASIdentifierChoice containing an asIdsOrRanges element is located. If no authorization is being granted for a particular form of AS identifier, then there MUST NOT be a corresponding asnum/rdi member in the ASIdentifiers sequence.
如果ASIdentifierChoice选项包含inherit元素，则授权为标识符的集合将递归地从颁发者的证书或颁发者的证书中获取，直到找到包含asIdsOrRanges元素的ASIdentifierChoice的证书为止。如果没有为特定形式的AS标识符授予授权，则ASIdentifiers序列中不得有相应的asnum/rdi成员。
The asIdsOrRanges element is a SEQUENCE of ASIdOrRange types. Any pair of items in the asIdsOrRanges SEQUENCE MUST NOT overlap. Any contiguous series of AS identifiers MUST be combined into a single range whenever possible. The AS identifiers in the asIdsOrRanges element MUST be sorted by increasing numeric value.
AsidOrranges元素是一系列ASIdOrRange类型。asIdsOrRanges序列中的任何一对项目不得重叠。任何连续的AS标识符序列必须尽可能组合到单个范围中。asIdsOrRanges元素中的AS标识符必须按递增的数值排序。
The ASIdOrRange type is a CHOICE of either a single integer (ASId) or a single sequence (ASRange).
ASIdOrRange类型可以选择单个整数（ASId）或单个序列（ASRange）。
The id element has type ASId.
id元素的类型为ASId。
The range element has type ASRange.
range元素的类型为ASRange。
The ASRange type is a SEQUENCE consisting of a min and a max element, and is used to specify a range of AS identifier values.
ASRange类型是由min和max元素组成的序列，用于指定AS标识符值的范围。
The min and max elements have type ASId. The min element is used to specify the value of the minimum AS identifier in the range, and the max element specifies the value of the maximum AS identifier in the range.
最小和最大元素的类型为ASId。最小元素用于指定范围内最小值作为标识符，最大元素指定范围内最大值作为标识符。
The ASId type is an INTEGER.
ASId类型是一个整数。
3.3. Autonomous System Identifier Delegation Extension Certification Path Validation
3.3. 自治系统标识符委派扩展证书路径验证
Certification path validation of a certificate containing the autonomous system identifier delegation extension requires additional processing. As each certificate in a path is validated, the AS identifiers in the autonomous system identifier delegation extension of that certificate MUST be subsumed by the AS identifiers in the autonomous system identifier delegation extension in the issuer's certificate. Validation MUST fail when this is not the case. A certificate that is a trust anchor for certification path validation of certificates containing the autonomous system identifier delegation extension, as well as all certificates along the path, MUST each contain the autonomous system identifier delegation extension. The initial set of allowed AS identifiers is taken from the trust anchor certificate.
包含自治系统标识符委派扩展的证书的证书路径验证需要额外的处理。当验证路径中的每个证书时，该证书的自治系统标识符委派扩展中的As标识符必须包含在颁发者证书的自治系统标识符委派扩展中的As标识符中。如果不是这样，验证必须失败。作为包含自治系统标识符委派扩展的证书的证书路径验证的信任锚点的证书，以及路径上的所有证书，都必须包含自治系统标识符委派扩展。允许AS标识符的初始集合取自信任锚证书。
This specification describes two X.509 extensions. Since X.509 certificates are digitally signed, no additional integrity service is necessary. Certificates with these extensions need not be kept secret, and unrestricted and anonymous access to these certificates has no security implications.
本规范描述了两个X.509扩展。由于X.509证书是数字签名的，因此不需要额外的完整性服务。具有这些扩展的证书不需要保密，对这些证书的无限制匿名访问没有安全隐患。
However, security factors outside the scope of this specification will affect the assurance provided to certificate users. This section highlights critical issues that should be considered by implementors, administrators, and users.
但是，本规范范围之外的安全因素将影响向证书用户提供的保证。本节重点介绍实施者、管理员和用户应该考虑的关键问题。
These extensions represent authorization information, i.e., a right-to-use for IP addresses or AS identifiers. They were developed to support a secure version of BGP [S-BGP], but may be employed in other contexts. In the secure BGP context, certificates containing these extensions function as capabilities: the certificate asserts that the holder of the private key (the Subject) is authorized to use the IP addresses or AS identifiers represented in the extension(s). As a result of this capability model, the Subject field is largely irrelevant for security purposes, contrary to common PKI conventions.
这些扩展代表授权信息，即使用IP地址或作为标识符的权利。它们是为了支持安全版本的BGP[S-BGP]而开发的，但也可以在其他环境中使用。在安全BGP上下文中，包含这些扩展的证书作为功能发挥作用：证书声明私钥持有者（主体）有权使用IP地址或作为扩展中表示的标识符。由于这种能力模型，主题字段在很大程度上与安全目的无关，这与常见的PKI约定相反。
The authors would like to acknowledge the contributions to this specification by Charles Gardiner, Russ Housley, James Manger, and Jim Schaad.
作者要感谢Charles Gardiner、Russ Housley、James Manger和Jim Schaad对本规范的贡献。
Appendix A -- ASN.1 Module
附录A——ASN.1模块
This normative appendix describes the IP address and AS identifiers extensions used by conforming PKI components in ASN.1 syntax.
本规范性附录描述了符合ASN.1语法的PKI组件使用的IP地址和AS标识符扩展。
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) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- Copyright (C) The Internet Society (2004). This --
-- version of this ASN.1 module is part of RFC 3779; --
-- see the RFC itself for full legal notices. --
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) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- Copyright (C) The Internet Society (2004). This --
-- version of this ASN.1 module is part of RFC 3779; --
-- see the RFC itself for full legal notices. --
-- EXPORTS ALL --
--全部出口--
IMPORTS
进口
-- PKIX specific OIDs and arcs --
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) };
-- PKIX specific OIDs and arcs --
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 Delegation Extension OID --
--IP地址委派扩展OID--
id-pe-ipAddrBlocks OBJECT IDENTIFIER ::= { id-pe 7 }
id-pe-ipAddrBlocks OBJECT IDENTIFIER ::= { id-pe 7 }
-- IP Address Delegation Extension Syntax --
--IP地址委派扩展语法--
IPAddrBlocks ::= SEQUENCE OF IPAddressFamily
IPAddrBlocks ::= SEQUENCE OF IPAddressFamily
IPAddressFamily ::= SEQUENCE { -- AFI & opt SAFI --
addressFamily OCTET STRING (SIZE (2..3)),
ipAddressChoice IPAddressChoice }
IPAddressFamily ::= SEQUENCE { -- AFI & opt 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
-- Autonomous System Identifier Delegation Extension OID --
--自治系统标识符委派扩展OID--
id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 8 }
id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 8 }
-- Autonomous System Identifier Delegation Extension Syntax --
--自治系统标识符委派扩展语法--
ASIdentifiers ::= SEQUENCE {
asnum [0] ASIdentifierChoice OPTIONAL,
rdi [1] ASIdentifierChoice OPTIONAL }
ASIdentifiers ::= SEQUENCE {
asnum [0] ASIdentifierChoice OPTIONAL,
rdi [1] 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
END
终止
Appendix B -- Examples of IP Address Delegation Extensions
附录B——IP地址委派扩展示例
A critical X.509 v3 certificate extension that specifies: IPv4 unicast address prefixes 1) 10.0.32/20 i.e., 10.0.32.0 to 10.0.47.255 2) 10.0.64/24 i.e., 10.0.64.0 to 10.0.64.255 3) 10.1/16 i.e., 10.1.0.0 to 10.1.255.255 4) 10.2.48/20 i.e., 10.2.48.0 to 10.2.63.255 5) 10.2.64/24 i.e., 10.2.64.0 to 10.2.64.255 6) 10.3/16 i.e., 10.3.0.0 to 10.3.255.255, and 7) inherits all IPv6 addresses from the issuer's certificate would be (in hexadecimal):
一个关键的X.509 v3证书扩展，指定：IPv4单播地址前缀1）10.0.32/20，即10.0.32.0至10.0.47.255 2）10.0.64/24，即10.0.64.0至10.0.64.255 3）10.1/16，即10.1.0.0至10.1.255.255 4）10.2.48/20，即10.2.48.0至10.2.63.255 5）10.2.64/24，即10.2.64.0至10.2.64.3.6）。，10.3.0.0至10.3.255.255，以及7）从颁发者的证书继承所有IPv6地址将是（十六进制）：
30 46 Extension {
06 08 2b06010505070107 extnID 1.3.6.1.5.5.7.1.7
01 01 ff critical
04 37 extnValue {
30 35 IPAddrBlocks {
30 2b IPAddressFamily {
04 03 0001 01 addressFamily: IPv4 Unicast
IPAddressChoice
30 24 addressesOrRanges {
30 46 Extension {
06 08 2b06010505070107 extnID 1.3.6.1.5.5.7.1.7
01 01 ff critical
04 37 extnValue {
30 35 IPAddrBlocks {
30 2b IPAddressFamily {
04 03 0001 01 addressFamily: IPv4 Unicast
IPAddressChoice
30 24 addressesOrRanges {
IPAddressOrRange
03 04 04 0a0020 addressPrefix 10.0.32/20
IPAddressOrRange
03 04 00 0a0040 addressPrefix 10.0.64/24
IPAddressOrRange
03 03 00 0a01 addressPrefix 10.1/16
IPAddressOrRange
30 0c addressRange {
03 04 04 0a0230 min 10.2.48.0
03 04 00 0a0240 max 10.2.64.255
} -- addressRange
IPAddressOrRange
03 03 00 0a03 addressPrefix 10.3/16
} -- addressesOrRanges
} -- IPAddressFamily
30 06 IPAddressFamily {
04 02 0002 addressFamily: IPv6
IPAddressChoice
05 00 inherit from issuer
} -- IPAddressFamily
} -- IPAddrBlocks
} -- extnValue
} -- Extension
IPAddressOrRange
03 04 04 0a0020 addressPrefix 10.0.32/20
IPAddressOrRange
03 04 00 0a0040 addressPrefix 10.0.64/24
IPAddressOrRange
03 03 00 0a01 addressPrefix 10.1/16
IPAddressOrRange
30 0c addressRange {
03 04 04 0a0230 min 10.2.48.0
03 04 00 0a0240 max 10.2.64.255
} -- addressRange
IPAddressOrRange
03 03 00 0a03 addressPrefix 10.3/16
} -- addressesOrRanges
} -- IPAddressFamily
30 06 IPAddressFamily {
04 02 0002 addressFamily: IPv6
IPAddressChoice
05 00 inherit from issuer
} -- IPAddressFamily
} -- IPAddrBlocks
} -- extnValue
} -- Extension
This example illustrates how the prefixes and ranges are sorted.
此示例说明如何对前缀和范围进行排序。
+ Prefix 1 MUST precede prefix 2, even though the number of unused bits (4) in prefix 1 is larger than the number of unused bits (0) in prefix 2.
+ 前缀1必须在前缀2之前，即使前缀1中未使用的位数（4）大于前缀2中未使用的位数（0）。
+ Prefix 2 MUST precede prefix 3 even though the number of octets (4) in the BIT STRING encoding of prefix 2 is larger than the number of octets (3) in the BIT STRING encoding of prefix 3.
+ 即使前缀2的位字符串编码中的八位字节数（4）大于前缀3的位字符串编码中的八位字节数（3），前缀2也必须在前缀3之前。
+ Prefixes 4 and 5 are adjacent (representing the range of addresses from 10.2.48.0 to 10.2.64.255), so MUST be combined into a range (since the range cannot be encoded by a single prefix).
+ 前缀4和5是相邻的（表示从10.2.48.0到10.2.64.255的地址范围），因此必须组合到一个范围中（因为该范围不能由单个前缀编码）。
+ Note that the six trailing zero bits in the max element of the range are significant to the semantic interpretation of the value (as all unused bits are interpreted to be 1's, not 0's). The four trailing zero bits in the min element are not significant and MUST be removed (thus the (4) unused bits in the encoding of the min element). (DER encoding requires that any unused bits in the last subsequent octet MUST be set to zero.)
+ 请注意，范围最大元素中的六个尾随零位对于值的语义解释非常重要（因为所有未使用的位都被解释为1，而不是0）。min元素中的四个尾随零位不重要，必须删除（因此min元素编码中的（4）个未使用位）。（DER编码要求最后一个后续八位字节中的任何未使用位必须设置为零。）
+ The range formed by prefixes 4 and 5 MUST precede prefix 6 even though the SEQUENCE tag for a range (30) is larger than the tag for the BIT STRING (03) used to encode prefix 6.
+ 由前缀4和5形成的范围必须在前缀6之前，即使范围（30）的序列标记大于用于编码前缀6的位字符串（03）的标记。
+ The IPv4 information MUST precede the IPv6 information since the address family identifier for IPv4 (0001) is less than the identifier for IPv6 (0002).
+ IPv4信息必须位于IPv6信息之前，因为IPv4（0001）的地址族标识符小于IPv6（0002）的标识符。
An extension specifying the IPv6 prefix 2001:0:2/48 and the IPv4 prefixes 10/8 and 172.16/12, and which inherits all IPv4 multicast addresses from the issuer's certificate would be (in hexadecimal):
指定IPv6前缀2001:0:2/48和IPv4前缀10/8和172.16/12并从颁发者的证书继承所有IPv4多播地址的扩展名为（十六进制）：
30 3d Extension {
06 08 2b06010505070107 extnID 1.3.6.1.5.5.7.1.7
01 01 ff critical
04 2e extnValue {
30 2c IPAddrBlocks {
30 10 IPAddressFamily {
04 03 0001 01 addressFamily: IPv4 Unicast
IPAddressChoice
30 09 addressesOrRanges {
IPAddressOrRange
03 02 00 0a addressPrefix 10/8
IPAddressOrRange
03 03 04 b010 addressPrefix 172.16/12
} -- addressesOrRanges
} -- IPAddressFamily
30 07 IPAddressFamily {
04 03 0001 02 addressFamily: IPv4 Multicast
IPAddressChoice
05 00 inherit from issuer
} -- IPAddressFamily
30 0f IPAddressFamily {
04 02 0002 addressFamily: IPv6
IPAddressChoice
30 09 addressesOrRanges {
IPAddressOrRange
03 07 00 200100000002 addressPrefix 2001:0:2/47
} -- addressesOrRanges
} -- IPAddressFamily
} -- IPAddrBlocks
} -- extnValue
} -- Extension
30 3d Extension {
06 08 2b06010505070107 extnID 1.3.6.1.5.5.7.1.7
01 01 ff critical
04 2e extnValue {
30 2c IPAddrBlocks {
30 10 IPAddressFamily {
04 03 0001 01 addressFamily: IPv4 Unicast
IPAddressChoice
30 09 addressesOrRanges {
IPAddressOrRange
03 02 00 0a addressPrefix 10/8
IPAddressOrRange
03 03 04 b010 addressPrefix 172.16/12
} -- addressesOrRanges
} -- IPAddressFamily
30 07 IPAddressFamily {
04 03 0001 02 addressFamily: IPv4 Multicast
IPAddressChoice
05 00 inherit from issuer
} -- IPAddressFamily
30 0f IPAddressFamily {
04 02 0002 addressFamily: IPv6
IPAddressChoice
30 09 addressesOrRanges {
IPAddressOrRange
03 07 00 200100000002 addressPrefix 2001:0:2/47
} -- addressesOrRanges
} -- IPAddressFamily
} -- IPAddrBlocks
} -- extnValue
} -- Extension
Appendix C -- Example of an AS Identifier Delegation Extension
附录C——AS标识符委派扩展的示例
An extension that specifies AS numbers 135, 3000 to 3999, and 5001, and which inherits all routing domain identifiers from the issuer's certificate would be (in hexadecimal):
指定为数字135、3000到3999和5001，并从颁发者证书继承所有路由域标识符的扩展名为（十六进制）：
30 2b Extension {
06 08 2b06010505070108 extnID 1.3.6.1.5.5.7.1.8
01 01 ff critical
04 1c extnValue {
30 1a ASIdentifiers {
a0 14 asnum
ASIdentifierChoice
30 12 asIdsOrRanges {
ASIdOrRange
02 02 0087 ASId
ASIdOrRange
30 08 ASRange {
02 02 0bb8 min
02 02 0f9f max
} -- ASRange
ASIdOrRange
02 02 1389 ASId
} -- asIdsOrRanges
} -- asnum
a1 02 rdi {
ASIdentifierChoice
05 00 inherit from issuer
} -- rdi
} -- ASIdentifiers
} -- extnValue
} -- Extension
30 2b Extension {
06 08 2b06010505070108 extnID 1.3.6.1.5.5.7.1.8
01 01 ff critical
04 1c extnValue {
30 1a ASIdentifiers {
a0 14 asnum
ASIdentifierChoice
30 12 asIdsOrRanges {
ASIdOrRange
02 02 0087 ASId
ASIdOrRange
30 08 ASRange {
02 02 0bb8 min
02 02 0f9f max
} -- ASRange
ASIdOrRange
02 02 1389 ASId
} -- asIdsOrRanges
} -- asnum
a1 02 rdi {
ASIdentifierChoice
05 00 inherit from issuer
} -- rdi
} -- ASIdentifiers
} -- extnValue
} -- Extension
Appendix D -- Use of X.509 Attribute Certificates
附录D——X.509属性证书的使用
This appendix discusses issues arising from a proposal to use attribute certificates (ACs, as specified in [RFC3281]) to convey, from the Regional Internet Registries (RIRs) to the end-user organizations, the "right-to-use" for IP address blocks or AS identifiers.
本附录讨论了使用属性证书（ACs，如[RFC3281]中所述）从区域互联网注册中心（RIR）向最终用户组织传达IP地址块的“使用权”或作为标识符的建议所产生的问题。
The two resources, AS identifiers and IP address blocks, are currently managed differently. All organizations with the right-to-use for an AS identifier receive the authorization directly from an RIR. Organizations with a right-to-use for an IP address block receive the authorization either directly from an RIR, or indirectly, e.g., from a down stream service provider, who might receive its
这两种资源（标识符和IP地址块）目前的管理方式不同。所有有权使用AS标识符的组织都直接从RIR获得授权。具有IP地址块使用权的组织可以直接从RIR接收授权，也可以间接地（例如）从可能接收其IP地址块的下游服务提供商接收授权
authorization from an Internet service provider, who in turn gets its authorization from a RIR. Note that AS identifiers might be sub-allocated in the future, so the mechanisms used should not rely upon a three level hierarchy.
来自互联网服务提供商的授权，而互联网服务提供商又从RIR获得授权。请注意，由于标识符可能在将来进行子分配，因此所使用的机制不应依赖于三级层次结构。
In section 1 of RFC 3281, two reasons are given for why the use of ACs might be preferable to the use of public key certificates (PKCs) with extensions that convey the authorization information:
在RFC 3281的第1节中，给出了使用ACs可能比使用公钥证书（PKC）更可取的两个原因，以及传递授权信息的扩展：
"Authorization information may be placed in a PKC extension or placed in a separate attribute certificate (AC). The placement of authorization information in PKCs is usually undesirable for two reasons. First, authorization information often does not have the same lifetime as the binding of the identity and the public key. When authorization information is placed in a PKC extension, the general result is the shortening of the PKC useful lifetime. Second, the PKC issuer is not usually authoritative for the authorization information. This results in additional steps for the PKC issuer to obtain authorization information from the authoritative source."
“授权信息可以放在PKC扩展中，也可以放在单独的属性证书（AC）中。在PKC中放置授权信息通常是不可取的，原因有两个。首先，授权信息通常与身份和公钥的绑定不具有相同的生存期。当将授权信息放置在PKC扩展中时，通常会缩短PKC的有效生存期。其次，PKC颁发者通常不具有授权信息的权威性。这会导致PKC颁发者采取额外步骤从权威来源获取授权信息。”
"For these reasons, it is often better to separate authorization information from the PKC. Yet, authorization information also needs to be bound to an identity. An AC provides this binding; it is simply a digitally signed (or certified) identity and set of attributes."
由于这些原因，通常最好将授权信息与PKC分开。但是，授权信息也需要绑定到标识。AC提供此绑定；它只是一个数字签名（或认证）标识和一组属性
In the case of the IP address and AS identifier authorizations, these reasons do not apply. First, the public key certificates are issued exclusively for authorization, so the certificate lifetime corresponds exactly to the authorization lifetime, which is often tied to a contractual relationship between the issuer and entity receiving the authorization. The Subject and Issuer names are only used for chaining during certification path validation, and the names need not correspond to any physical entity. The Subject name in the PKCs may actually be randomly assigned by the issuing CA, allowing the resource holder limited anonymity. Second, the certificate hierarchy is constructed so that the certificate issuer is authoritative for the authorization information.
对于IP地址和AS标识符授权，这些原因不适用。首先，公钥证书是专门为授权而颁发的，因此证书生命周期与授权生命周期完全对应，授权生命周期通常与颁发者和接收授权的实体之间的合同关系有关。Subject和Issuer名称仅用于证书路径验证期间的链接，并且名称不需要与任何物理实体相对应。PKCs中的主体名称实际上可能由颁发CA随机分配，从而允许资源持有者有限的匿名性。其次，构造证书层次结构，使证书颁发者对授权信息具有权威性。
Thus the two points in the first cited paragraph above are not true in the case of AS number and IP address block allocations. The point of the second cited paragraph is also not applicable as the resources are not being bound to an identity but to the holder of the private key corresponding to the public key in the PKC.
因此，在AS编号和IP地址块分配的情况下，上面引用的第一段中的两点是不正确的。引用的第二段的观点也不适用，因为资源不受身份的约束，而是与PKC中的公钥对应的私钥持有人的约束。
RFC 3281 specifies several requirements that a conformant Attribute Certificate must meet. In relation to S-BGP, the more-significant requirements are:
RFC 3281规定了符合性属性证书必须满足的几个要求。关于S-BGP，更重要的要求是：
1 from section 1: "this specification does NOT RECOMMEND the use of AC chains. Other (future) specifications may address the use of AC chains."
1第1节：“本规范不建议使用交流链。其他（未来）规范可能涉及交流链的使用。”
Allocation from IANA to RIRs to ISPs to DSPs and assignment to end organizations would require the use of chains, at least for IP address blocks. A description of how the superior's AC should be located and how it should be processed would have to be provided. Readers of this document are encouraged to propose ways the chaining might be avoided.
从IANA到RIR、从ISP到DSP的分配以及到终端组织的分配都需要使用链，至少对于IP地址块是这样。必须提供上级AC的位置和处理方式说明。鼓励本文档的读者提出避免链接的方法。
2 from section 4.2.9: "section 4.3 defines the extensions that MAY be used with this profile, and whether or not they may be marked critical. If any other critical extension is used, the AC does not conform to this profile. However, if any other non-critical extension is used, the AC does conform to this profile."
第4.2.9节中的第2条：“第4.3节定义了可用于此配置文件的扩展，以及它们是否可标记为关键扩展。如果使用任何其他关键扩展，AC不符合此配置文件。但是，如果使用任何其他非关键扩展，AC不符合此配置文件。”
This means that the delegation extensions defined in this specification, which are critical, could not be simply placed into an AC. They could be used if not marked critical, but the intended use requires that the extensions be critical so that the certificates containing them cannot be used as identity certificates by an unsuspecting application.
这意味着本规范中定义的关键授权扩展不能简单地放在AC中。如果没有标记为关键，则可以使用这些扩展，但预期用途要求这些扩展是关键的，以便包含它们的证书不能被毫无戒心的应用程序用作身份证书。
3 from section 4.5: "an AC issuer, MUST NOT also be a PKC issuer. That is, an AC issuer cannot be a CA as well."
第4.5节第3节：“AC发行人不得同时也是PKC发行人。也就是说，AC发行人不能同时也是CA。”
This means that for each AC issuer there would need to be a separate CA to issue the PKC that contains the public key of the AC holder. The AC issuer cannot issue the PKC of the holder, and the PKC issuer cannot sign the AC. Thus, each entity in the PKI would need to operate an AC issuer in addition to its CA. There would be twice as many certificate issuers and CRLs to process to support Attribute certificates than are needed if PKCs are used. The possibility of mis-alignment also arises when there are two issuers issuing certificates for a single purpose.
这意味着，对于每个AC发行人，需要有一个单独的CA来发行包含AC持有人公钥的PKC。AC发行人不能发行持有人的PKC，PKC发行人也不能签署AC。因此，PKI中的每个实体除了其CA之外，还需要运营一个AC发行人。要处理以支持属性证书的证书发行人和CRL的数量将是使用PKC时所需数量的两倍。当有两个发行人为同一目的发行证书时，也会出现不一致的可能性。
The AC model of RFC 3281 implies that the AC holder presents the AC to the AC verifier when the holder wants to substantiate an attribute or authorization. The intended usage for the extensions defined herein does not have a direct interaction between an AC verifier (a NOC) and the AC issuers (all RIRs and NOCs). Given a
RFC 3281的AC模型意味着，当AC持有者希望证实属性或授权时，AC持有者向AC验证者出示AC。本文定义的扩展的预期用途在AC验证者（NOC）和AC发行者（所有RIR和NOC）之间没有直接交互。给予
signature on a claimed right-to-use object, the "AC verifier" can locate the AC holder's PKC, but there is no direct way to locate the Subject's AC(s).
在声称的使用权对象上签名，“AC验证者”可以找到AC持有人的PKC，但无法直接找到受试者的AC。
4 from section 5: "4. The AC issuer MUST be directly trusted as an AC issuer (by configuration or otherwise)."
第5节第4节：“4.必须直接信任AC发行人作为AC发行人（通过配置或其他方式）。”
This is not true in the case of a right-to-use for an IP address block, which is allocated through a hierarchy. Certification path validation of the AC will require chaining up through the delegation hierarchy. Having to configure each relying party (NOC) to "trust" every other NOC does not scale, and such "trust" has resulted in failures that the proposed security mechanisms are designed to prevent. A single PKI with a trusted root is used, not thousands of individually trusted per-ISP AC issuers.
对于通过层次结构分配的IP地址块的使用权，情况并非如此。AC的认证路径验证需要通过委托层次结构进行链接。必须将每个依赖方（NOC）配置为“信任”每个其他NOC无法扩展，而这种“信任”已导致拟定安全机制旨在防止的故障。使用具有受信任根的单个PKI，而不是每个ISP AC颁发者数千个单独受信任的PKI。
The amount of work that would be required to properly validate an AC is larger than for the mechanism that places the certificate extensions defined in this document in the PKCs. There would be twice as many certificates to be validated, in addition to the ACs. There could be a considerable increase in the management burden required to support ACs.
正确验证AC所需的工作量大于将本文档中定义的证书扩展放置在PKCs中的机制所需的工作量。除了ACs之外，还有两倍的证书需要验证。支持ACs所需的管理负担可能会大幅增加。
References
工具书类
Normative References
规范性引用文件
[IANA-AFI] http://www.iana.org/assignments/address-family-numbers.
[IANA-AFI]http://www.iana.org/assignments/address-family-numbers.
[IANA-SAFI] http://www.iana.org/assignments/safi-namespace.
[IANA-SAFI]http://www.iana.org/assignments/safi-namespace.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280]Housley，R.，Polk，W.，Ford，W.和D.Solo，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）概要”，RFC 32802002年4月。
[X.690] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998, "Information Technology - ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)".
[X.690]ITU-T建议X.690（1997）| ISO/IEC 8825-1:1998，“信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”。
Informational References
参考资料
[RFC791] Postel, J., "Internet Protocol -- DARPA Internet Program Protocol Specification", RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议——DARPA互联网程序协议规范”，RFC7911981年9月。
[RFC1142] D. Oran, Ed., "OSI IS-IS Intra-domain Routing Protocol", RFC 1142, February 1990.
[RFC1142]D.Oran主编，“OSI IS-IS域内路由协议”，RFC1142，1990年2月。
[RFC1771] Rekhter, Y. and T. Li, Eds., "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771]Rekhter，Y.和T.Li，编辑，“边界网关协议4（BGP-4）”，RFC 17711995年3月。
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", BCP 6, RFC 1930, March 1996.
[RFC1930]霍金森，J.和T.贝茨，“自主系统（AS）的创建、选择和注册指南”，BCP 6，RFC 1930，1996年3月。
[RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and J. Postel, "Internet Registry IP Allocation Guidelines", BCP 12, RFC 2050, November 1996.
[RFC2050]Hubbard，K.，Kosters，M.，Conrad，D.，Karrenberg，D.和J.Postel，“互联网注册IP分配指南”，BCP 12，RFC 2050，1996年11月。
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3513]Hinden，R.和S.Deering，“互联网协议版本6（IPv6）寻址体系结构”，RFC 3513，2003年4月。
[RFC3281] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[RFC3281]Farrell，S.和R.Housley，“用于授权的Internet属性证书配置文件”，RFC 3281，2002年4月。
[S-BGP] S. Kent, C. Lynn, and K. Seo, "Secure Border Gateway Protocol (S-BGP)," IEEE JSAC Special Issue on Network Security, April 2000.
[S-BGP]S.Kent，C.Lynn和K.Seo，“安全边界网关协议（S-BGP）”，IEEE JSAC网络安全特刊，2000年4月。
Authors' Address
作者地址
Charles Lynn BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA
Charles Lynn BBN Technologies 10美国马萨诸塞州剑桥莫尔顿街02138号
Phone: +1 (617) 873-3367
EMail: CLynn@BBN.Com
Phone: +1 (617) 873-3367
EMail: CLynn@BBN.Com
Stephen Kent BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA
Stephen Kent BBN Technologies美国马萨诸塞州剑桥莫尔顿街10号，邮编02138
Phone: +1 (617) 873-3988
EMail: Kent@BBN.Com
Phone: +1 (617) 873-3988
EMail: Kent@BBN.Com
Karen Seo BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA
Karen Seo BBN Technologies美国马萨诸塞州剑桥莫尔顿街10号，邮编02138
Phone: +1 (617) 873-3152
EMail: KSeo@BBN.Com
Phone: +1 (617) 873-3152
EMail: KSeo@BBN.Com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。