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
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.
この文書では、2つの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
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.
この文書は、インターネットサービスプロバイダ（ISP）や利用者への地域インターネットレジストリ（RIRが）を介してIPアドレスとIANAから自律システム識別子のセットのための利用権の移転を許可する2つのX.509 v3証明書拡張を定義します団体。最初は、証明書のサブジェクト（秘密鍵保持者）に、多くの場合、IPアドレスのプレフィックスとして表さIPアドレスブロックのリストを、バインドします。第二は、証明書のサブジェクト（秘密鍵保持者）に自律システム（AS）の識別子のリストをバインドします。証明書の発行者は、エンティティ（例えば、IANA、地域インターネットレジストリ、またはISP）（「割り当て」）の管理権を譲渡する権限を持っているの対象にIPアドレスブロックおよびAS識別子のセットです証明書。これらの証明書は、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は、従わなければなりません本明細書で定義された拡張の符号化に関するいくつかの規則を指定します。これらの符号化規則は、以下の目的を果たします。まず、彼らは延長の値のユニークなエンコーディングにつながります。延長の2つのインスタンスが等しいかどうかのオクテット・バイ・オクテットを比較することができます。第二に、彼らは情報の最小サイズの符号化を達成します。第三に、彼らは、証明書パス検証を実行するときに頼る当事者は1パスアルゴリズムを使用することができます。具体的には、依拠当事者は、情報をソートするために、またはいくつかの境界（隣接し、重複、または包含範囲）のケースを処理するためのアルゴリズムを確認するサブセットに余分なコードを実装する必要はありません。
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:
「インターネットプロトコル」[RFC791]、「インターネットプロトコルバージョン6、読者が「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール」[RFC3280]で説明した用語と概念に精通していると仮定されます（IPv6）のアドレス指定アーキテクチャ」[RFC3513]、 『インターネットレジストリIPの割り当てガイドライン』 [RFC2050]、および関連する地域インターネットレジストリアドレス管理政策文書。いくつかの関連する用語は、次のとおりです。
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） - ルーティング方法自律システム内のパケットをするかを決定するために、1つ以上の内部ゲートウェイプロトコルとメトリックを使用して、均一なポリシーを持つ単一の技術的管理下ルータのセット、および方法を決定するために外部ゲートウェイプロトコルを使用して他の自律システムにパケットをルーティング。
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アドレス - 0〜255の範囲内に4つの10進数、各として書かれた32ビットの識別子によって分離「」。 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バージョン6アドレス - 8進量として書かれた128ビットの識別子、範囲0内の各FFFFに、によって分離されました「：」。 2001：0：200：3：0：0：0：1は、IPv6アドレスの例です。 0：の1つの文字列フィールドが置き換えられてもよい「::」、従って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：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） - IPアドレスの管理のために、識別子として地域の当局としてIANAによって認識体のいずれか。執筆時点では、これらはAfriNIC、APNIC、ARIN、LACNIC、RIPE 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]で説明したように解釈される際のキーワードは、REQUIRED、、NOT SHALL、、、、オプション推奨、およびMAY、とすべきでないものとしてはなりませんしなければなりません。
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 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をルートと階層が管理しますが、のRIRによって管理されています。 IANAは、順番になどのRIRも組織にIPアドレス空間を割り当てることがダウンストリーム・プロバイダー、顧客にIPアドレス空間を割り当てることができるインターネットサービスプロバイダ（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で説明したように、これは、このセクションで説明拡張を搬送する証明書を発行することによって達成されます。この拡張における情報の一の使用例は、特定のIPアドレスブロックへの経路をアドバタイズBGPアップデートを発信するために組織の許可を確認するためにそれを使用するエンティティです。参照、例えば、[RFC1771]、[S-BGP]。
There are two families of IP addresses: IPv4 and IPv6.
IPv4とIPv6：IPアドレス2つのファミリーがあります。
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アドレスは、（「」）、ドットで区切られた4つの10進数として書き込まれた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アドレスは、8つの16進数、範囲0内の各FFFFを介して、セミコロン（「：」）で区切られたように書かれている128ビットの量です。 2001：0：200：3：0：0：0：1は、IPv6アドレスの例です。 IPv6はしばしばその値が0のフィールドの0一つのそのようなグループは、2つのセミコロン（「::」）と略記することができるされている隣接するフィールドを持って対処します。 0：200：3 :: 1前の例では、このように2001で表されてもよいです。
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：0 2001年まで3FF：FFFF：FFFF：FFFF：FFFF：0：200 FFFF（2 ^ 89アドレス）が2001で表されます。 ：0：0：0：0：0/39または同等2001：0：200 :: / 39。プレフィックスは、最下位ゼロフィールドを省略することによって省略することもできるが、一定のビットの示す数を含むのに十分なフィールドが存在すべきです。例えばIPv4のプレフィックスの省略形は、10.5.0 / 23であり、そして例のIPv6プレフィックスは2001：0：39分の200。
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アドレスまたはプレフィックスが一定の最上位ビットを含むDERエンコードされたASN.1のビット列としてIPアドレス委任拡張でエンコードされています。ビット列のDER符号化値に続く値オクテットの数（の符号）、続いてビット列タイプ（0×03）、から成ること[X.690]を思い出してください。値は、ビット列のオクテットを含む「後続のオクテット」に続く最後の値のオクテットの未使用のビットの数を指定する「初期オクテット」から成ります。 （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
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
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).
この場合、3つの後続のオクテットは24ビットを含むが、接頭辞のみ23を使用するため、未使用のビットは、このように最初のオクテットは1（DERは、すべての未使用のビットがゼロに設定されなければならないことを要求され、最後のオクテットでありますビット）。
The DER-encoding of the IPv6 address 2001:0:200:3:0:0:0:1 is:
IPv6アドレス2001 DERエンコーディング：0：200：3：0：0：0：1です。
Type Len Unused Bits ...
0x03 0x11 0x00 0x20 0x01 0x00 0x00 0x02 0x00 0x00 0x03
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 DERエンコーディング：0：39分の200、最後のオクテット内の1つの未使用ビットを有しています。
Type Len Unused Bits ...
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アドレスの任意の連続範囲が連続プレフィックスの集合によって表されることができるが、より簡潔な表現は、最下位アドレスと各アドレスはビット列として符号化された最上位アドレスを含む配列として範囲を符号化することによって達成されます。配列内の、範囲の最下位アドレスを表すビット列をアドレスからのすべての最下位零ビットを除去することにより形成され、その範囲内の最上位アドレスを表すビット列は全て最下位を除去することによって形成されます1ビット。 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.1.255を通して10.5.0.0です。最下位アドレスは16で除去され、ゼロのビットを終了します。得られた16ビットのビット列のDER符号化です。
Type Len Unused Bits ...
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ビットで終わります。得二十から三ビット列のDER符号化です。
Type Len Unused Bits ...
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：0：200：:)である：39分の200は、最下位アドレス（2001のDER符号化範囲として符号化することができます
Type Len Unused Bits ...
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最下位1ビットの除去は、32 8ビット文字列を出た後、としてエンコードされ、。
Type Len Unused Bits ...
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」は、1つの長さオクテット、ゼロの初期オクテット、及び後続のオクテットとDERごとに符号化されなければなりません。
Type Len Unused Bits ...
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
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
The OID for this extension is id-pe-ipAddrBlocks.
この拡張のためのOIDは、ID-PE-ipAddrBlocksです。
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-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.
この拡張はCRITICALであるべきです。この拡張の使用目的は、拡張に識別されたIPアドレスのブロック（S）のための利用権を暗示することです。 CAは、証明書利用者は、それが発行された目的のために証明書を利用するために拡張の意味を理解しなければならないという考えを伝えるためにCRITICALなどの拡張子をマーク。この拡張を含む証明書を使用し、新しく作成されたアプリケーションは、拡張子を認識することが期待されています。
id-pe-ipAddrBlocks OBJECT IDENTIFIER ::= { id-pe 7 }
IPAddrBlocks ::= SEQUENCE OF IPAddressFamily
IPAddressFamily ::= SEQUENCE { -- AFI & optional SAFI --
addressFamily OCTET STRING (SIZE (2..3)),
ipAddressChoice IPAddressChoice }
IPAddressChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
addressesOrRanges SEQUENCE OF IPAddressOrRange }
IPAddressOrRange ::= CHOICE {
addressPrefix IPAddress,
addressRange IPAddressRange }
IPAddressRange ::= SEQUENCE {
min IPAddress,
max IPAddress }
IPAddress ::= BIT STRING
The IPAddrBlocks type is a SEQUENCE OF IPAddressFamily types.
IPAddrBlocksタイプは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要素は、必要に応じて1オクテット次のアドレスファミリ識別子（SAFI）、続いてネットワークバイト順に2オクテットアドレスファミリ識別子（AFI）を含むオクテット文字列です。 AFISとSAFIsは、それぞれ、[IANA-AFI]および[IANA-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に許可されていない場合は、IPAddrBlocksシーケンスでその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のユニークな組み合わせごとに1つだけIPAddressFamilyシーケンスがあるに違いありません。各配列は、（オクテットとして符号なしの数量を治療する）addressFamily値を昇順で順序付けされなければなりません。 SAFIのないaddressFamilyはSAFIが含まれているものを先行しなければなりません。 IPv4およびIPv6アドレスの両方が指定された場合（0001のIPv4のAFIが0002のIPv6のAFI未満であるため）、IPv4アドレスは、IPv6アドレスに先行しなければなりません。
The ipAddressChoice element is of type IPAddressChoice. The IPAddressChoice type is a CHOICE of either an inherit or addressesOrRanges element.
ipAddressChoice要素はタイプIPAddressChoiceです。 IPAddressChoiceタイプは、継承やaddressesOrRanges要素のいずれかの選択です。
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 CHOICEが継承要素が含まれている場合は、指定されたAFIとオプションSAFIのための認可IPアドレスのセットは、発行者の証明書から、または発行者の発行者の証明書から、再帰的に、addressesOrRanges要素をされ含むIPAddressChoiceを含む証明書まで取られます位置しています。
The addressesOrRanges element is a SEQUENCE OF IPAddressOrRange types. The addressPrefix and addressRange elements MUST be sorted using the binary representation of:
addressesOrRanges要素はIPAddressOrRangeタイプのシーケンスです。 addressPrefixとaddressRange要素は、バイナリ表現を使用してソートしなければなりません。
<lowest IP address in range> | <prefix length>
<範囲内で最低のIPアドレス> | <プレフィックス長>
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:
ここで、「|」連結を表します。なお、この表現のオクテット（A.B.C.D | IPv4または秒間長：T：U：V：W：X：Y：Z | IPv6の長さ）は、DER符号化されたビット列の値であるオクテットはありません。例えば、2 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
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.
32未満64であるため、接頭辞10.32.0.0/12は接頭10.64.0.0/16の前に来なければなりません。一つは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（2ビットを含むシーケンスを使用して符号化されなければならないことを要求します列）。以下の擬似コードは、アドレスの所定の範囲の符号化を選択する方法を示す図です。
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
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タイプです。 （ - IPv4のNビット、または128 - IPv6のNビット32）であってもよいたIPAddressタイプは、残りのビットが中にアドレスの最上位（最も左）Nビットは、一定に保たれているIPアドレスの範囲を定義します0または1のどちらか。 10.64 / 11 10.95.255.255に10.64.0.0に対応している、例えば、IPv4のプレフィックス10.64 / 12は、10.79.255.255にアドレス10.64.0.0に相当します。 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 unused. The DER encoding specifies that these unused bits MUST be set to zero-bits.
IPアドレスのプレフィックスは、BIT STRINGとして符号化されています。ビット列のDER符号化は、最後の後続のオクテットの最下位ビットの数を指定する文字列の最初のオクテットを使用して未使用です。 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
例：= 1000タイプ長さの未使用ビットを符号化する128.0.0.0 = 1000 0000.0000 0000.0000 0000.0000 0000 1111 1111.1111 1111.1111 1111.1111 143.255 255 255 = 1000ビット列...エンコード= 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タイプが最小（要素分）を含む配列と最大値（要素max）のIPアドレスで構成されています。各IPアドレスは、BIT STRINGとして符号化されています。 IPAddressRangeの最小アドレスの意味論的解釈は、（IPアドレスの完全長のための）すべての未指定ビットがゼロビットであることです。最大アドレスの意味論的解釈は、全ての未指定ビットが1ビットであることです。最小アドレスからのすべての最下位零ビットを除去することから最小アドレス結果のビット列。最大アドレスからのすべての最下位1ビットを除去することから最大アドレス結果のビット列。
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 }
例：129.64.0.0 = 1000 0001.0100 0000.0000 0000.0000 0000 143.255.255.255 = 1000 1111.1111 1111.1111 1111.1111 1111最小ビット列= 1000 0001.01最大ビット列= 1000エンコーディング= SEQUENCE {タイプ長さの未使用ビット...分0x03の0x03の0x06で0x81と0x40のmaxまで0×03 0×02 0×04は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である、即ち、後続のオクテットを省略したり、すべてのゼロでなくてもよい少なくとも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 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アドレス委任拡張のIPアドレスは、発行者の証明書内のIPアドレス委任拡張内のIPアドレスに包含されなければなりません。これがそうでないとき、検証が失敗しなければなりません。 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をルートと階層が管理しますが、のRIRによって管理されています。 IANAは、順番に、すなわち、他の組織へのAS識別子のいずれかを再割り当てされることはありません、最後の実体である組織への識別子として割り当てるのRIRへの識別子として割り当てます。 AS識別子委任拡張は、識別子としてこれらを使用するには、エンティティの許可の、すなわち、AS識別子の適切な委任の検証を可能にするためのものです。したがって、AS識別子の管理のために既存の管理フレームワークの固有の権威を利用するために理にかなっています。上記のセクション1で説明したように、これは、このセクションで説明拡張を搬送する証明書を発行することによって達成されます。この拡張における情報の一の使用例は、拡張のように識別子によって識別されるように管理する組織の許可を確認するためにそれを使用するエンティティです。 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 }
where [RFC3280] defines:
ここで、[RFC3280]を定義します。
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 }
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.
この拡張はCRITICALであるべきです。この拡張機能の使用目的は、拡張子でAS識別子の利用権を暗示することです。 CAは、証明書利用者は、それが発行された目的のために証明書を利用するために拡張の意味を理解しなければならないという考えを伝えるためにCRITICALなどの拡張子をマーク。この拡張を含む証明書を使用し、新しく作成されたアプリケーションは、拡張子を認識することが期待されています。
id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 8 }
ASIdentifiers ::= SEQUENCE {
asnum [0] EXPLICIT ASIdentifierChoice OPTIONAL,
rdi [1] EXPLICIT ASIdentifierChoice OPTIONAL}
ASIdentifierChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
asIdsOrRanges SEQUENCE OF ASIdOrRange }
ASIdOrRange ::= CHOICE {
id ASId,
range ASRange }
ASRange ::= SEQUENCE {
min ASId,
max ASId }
ASId ::= INTEGER
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].
（RDI素子における）AS番号（asnum要素内）またはルーティングドメイン識別子 - ASIdentifiersタイプは、一つ以上の自律システム識別子の形態を含む配列です。 ASIdentifiersタイプは識別子の複数のフォームが含まれている場合、asnumエントリはRDIエントリに先行しなければなりません。 AS番号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の選択が継承要素が含まれている場合は、識別子として許可のセットは、発行者の証明書から、または発行者の発行者の証明書から、再帰的に、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.
asIdsOrRanges要素はASIdOrRangeタイプのSEQUENCEです。 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.
範囲要素は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タイプはINTEGERです。
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.
この仕様は、2 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のコンテキストでは、機能として、これらの拡張機能を含む証明書：証明書は、秘密鍵（件名）のホルダーがまたは拡張子（S）で表さ識別子としてIPアドレスを使用する権限があることを主張します。この機能モデルの結果として、件名欄には、一般的なPKIの規則に反して、セキュリティ目的のために、主に無関係です。
The authors would like to acknowledge the contributions to this specification by Charles Gardiner, Russ Housley, James Manger, and Jim Schaad.
著者はチャールズ・ガーディナー、ラスHousley、ジェームズ・マネージャ、およびジム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. --
-- 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特定のOIDと円弧 - PKIX1Explicit88からID-PE {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0 ）ID-pkix1-明示（18）}。
-- IP Address Delegation Extension OID --
- IP委任拡張OID住所 -
id-pe-ipAddrBlocks OBJECT IDENTIFIER ::= { id-pe 7 }
-- IP Address Delegation Extension Syntax --
- IP委任拡張構文を住所 -
IPAddrBlocks ::= SEQUENCE OF IPAddressFamily
IPAddressFamily ::= SEQUENCE { -- AFI & opt SAFI --
addressFamily OCTET STRING (SIZE (2..3)),
ipAddressChoice IPAddressChoice }
IPAddressChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
addressesOrRanges SEQUENCE OF IPAddressOrRange }
IPAddressOrRange ::= CHOICE {
addressPrefix IPAddress,
addressRange IPAddressRange }
IPAddressRange ::= SEQUENCE {
min IPAddress,
max IPAddress }
IPAddress ::= BIT STRING
-- Autonomous System Identifier Delegation Extension OID --
- 自律システム識別子委任拡張OID -
id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 8 }
-- Autonomous System Identifier Delegation Extension Syntax --
- 自律システム識別子委任拡張構文 -
ASIdentifiers ::= SEQUENCE {
asnum [0] ASIdentifierChoice OPTIONAL,
rdi [1] ASIdentifierChoice OPTIONAL }
ASIdentifierChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
asIdsOrRanges SEQUENCE OF ASIdOrRange }
ASIdOrRange ::= CHOICE {
id ASId,
range ASRange }
ASRange ::= SEQUENCE {
min ASId,
max ASId }
ASId ::= INTEGER
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 2 10.0.47.255に）10.0.64 / 24、すなわち、10.0.64.0 3 10.0.64.255に）10.1 / 16、すなわち、10.1.0.0すなわち10.2.48 / 20、10.2.48.0すなわち10.2.64 / 24、10.2.64.0すなわち、10.3 / 16）6 10.2.64.255に）5 10.2.63.255に）4 10.1.255.255に、 10.3.255.255に10.3.0.0、および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拡張{06 08 2b06010505070107 extnID 1.3.6.1.5.5.7.1.7 01 01 FF臨界04 37 extnValue {30 35 IPAddrBlocks {30 2B IPAddressFamily {04 03 0001 01 addressFamily：IPv4ユニキャスト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
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は、プレフィックス1における未使用ビット（4）の数は、接頭辞2の未使用ビット（0）の数よりも多い場合であっても、接頭辞2に先行しなければなりません。
+ 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があっても接頭3に先行しなければならないプレフィクス2のビット列の符号化のオクテット（4）の数は、接頭辞3のビット列の符号化におけるオクテットの数（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であると解釈されるように）範囲の最大要素で6つの末尾ゼロのビット値の意味解釈に重要であることに留意されたいです。分素子の4つの末尾のゼロのビットは重要でないと（したがって（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によって形成される範囲は、範囲（30）のための配列タグは、ビット列（03）のタグプレフィックス6を符号化するために使用されるよりも大きいにもかかわらずプレフィックス6に先行しなければなりません。
+ 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のアドレスファミリ識別子（0001）以降のIPv6情報に先行しなければならないIPv4情報は、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):
0：IPv6プレフィックス2001指定拡張2/48とIPv4は10/8と172.16 / 12プレフィックス、および（16進数）であろう発行者の証明書からのすべての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
IPv4ユニキャストIPAddressChoice 30 09 addressesOrRanges {IPAddressOrRange 03 02 00：クリティカル04 2E extnValue {30 2C IPAddrBlocks {30 10 IPAddressFamily {04 03 0001 01 30 addressFamily 3D拡張{06 08 2b06010505070107 extnID 1.3.6.1.5.5.7.1.7 01 01 FF 0AのaddressPrefix 10/8 IPAddressOrRange 03 03 04 B010 addressPrefix 172.16 / 12} - addressesOrRanges} - IPAddressFamily 30 07 IPAddressFamily {04 03 0001 02 addressFamily：IPv4マルチキャストIPAddressChoice発行者から05 00継承} - IPAddressFamily 30 0F IPAddressFamily {04 02 0002 addressFamily：IPv6のIPAddressChoice 30 09 addressesOrRanges {IPAddressOrRange 03 07 00 200100000002 addressPrefix 2001：0：47分の2} - addressesOrRanges} - IPAddressFamily} - IPAddrBlocks} - extnValue} - 拡張
Appendix C -- Example of an AS Identifier Delegation Extension
付録C - などの識別子委任拡張の例
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、3999から3000、および5001 AS指定拡張、および（16進数）のようになります。
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
14 asnum ASIdentifierChoice 30 12 asIdsOrRanges {ASIdOrRange 02 02 0087 ASID ASIdOrRange 30 08 ASRange {02 02 0bb8 A0 30 2B拡張{06 08 2b06010505070108 extnID 1.3.6.1.5.5.7.1.8 01 01 FF臨界04 1C extnValue {30 1A ASIdentifiers {分02 02 0f9f最大} - ASRange ASIdOrRange 02 02 1389 ASID} - asIdsOrRanges} - asnum A1の02 RDI {ASIdentifierChoice発行者から05 00継承} - RDI} - ASIdentifiers} - extnValue} - 拡張
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.
この付録では、（[RFC3281]で指定されているようにACS）IPのための地域インターネットレジストリ（RIRが）からエンドユーザの組織、「利用権」を、伝えるために属性証明書を使用する提案に起因する問題について説明しますアドレスブロックまたはAS識別子。
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 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.
2つのリソースは、識別子とIPアドレスブロックとして、現在は別々に管理されています。 AS識別子のための利用権を持つすべての組織は、RIRから直接許可を受けます。今度はそのを取得するインターネットサービスプロバイダからその承認を受ける可能性があるIPアドレスブロックの利用権を持つ組織ダウンストリームサービスプロバイダから、直接RIRから、または間接的に例えば、認可を受け、 RIRからの認可。識別子があるかもしれない将来に、サブ割り当てられ、そのメカニズムは3つのレベルの階層に頼るべきではない使用していることに注意してください。
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の使用が承認情報を伝える拡張子を持つ公開鍵証明書（PKCS）の使用に好適であるかもしれない理由のために与えられています。
"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."
「認可情報は、PKCSに認可情報の配置は、2つの理由から、通常望ましくない。PKC拡張に配置され、または別個の属性証明書（AC）内に配置することができる。まず、認可情報は、多くの場合の結合と同じ寿命を有していませんアイデンティティと公開鍵。認証情報が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."
。「このような理由から、認証情報もアイデンティティにバインドする必要がありますACはこのバインディングを提供し、PKCから認証情報を分離することが多い方が良いしかし、それは単にデジタル署名された（または認定）のアイデンティティとのセットであります属性。」
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識別子の権限の場合には、これらの理由は適用されません。まず、公開鍵証明書は、認証のためだけに発行され、その証明書の有効期間は、多くの場合、許可を受けた発行者とエンティティ間の契約関係に結ばれる許可の有効期間、に正確に対応します。サブジェクトと発行者名のみ、認証パスの検証時に連鎖するために使用され、名前は任意の物理的実体に対応する必要はありません。 PKCのサブジェクト名は、実際には、ランダムに、リソースホルダー限定匿名性を可能にする、発行CAによって割り当てられてもよいです。証明書発行者が認証情報の権威であるように、第2、証明書の階層が構築されます。
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.
従って最初の2点は、上記段落引用AS番号とIPアドレスブロックの割り当ての場合には真ではありません。リソースがアイデンティティではなくPKCにおける公開鍵に対応する秘密鍵の所有者にバインドされていないように、第2の引用段落の点も適用されていません。
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：「この仕様は、ACチェーンの使用を推奨していませんその他（未来）の仕様は、ACチェーンの使用に対処することができます。」
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.
組織を終了するDSPや割り当てへIANAからのRIRへのISPへの割り当ては、少なくとも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."
図2は、セクション4.2.9から：「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の発行者のためのACホルダーの公開鍵を含むPKCを発行するために、別のCAがあるように必要があるだろうということを意味します。 ACの発行者は、ホルダーのPKCを発行することはできません、とPKCの発行者は、ACに署名することはできません。このように、PKI内の各エンティティは、そのCAに加えて、ACの発行者を操作する必要がありますPKCが使用されている場合に必要とされるよりも、属性証明書をサポートするために処理するために、2倍の数の証明書発行者とCRLがあるでしょう。ミスアライメントの可能性は、単一の目的のために証明書を発行する発行者2が存在する場合に生じます。
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 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).
RFC 3281のACモデルは、所有者が属性または許可を立証したいときは、ACホルダーは、AC検証者にACを提示することを意味します。本明細書で定義される拡張機能の使用目的は、AC検証（NOC）とAC発行者（すべてのRIRとのNOC）との間の直接的な相互作用を有していません。特許請求の右に使用できるオブジェクトの署名を考えると、「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発行者数千ではなく、使用されています。
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に加えて、検証する2倍の数の証明書があるでしょう。 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.
[月-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]ブラドナーの、S.、BCP 14、RFC 2119、1997年3月 "のRFCsにおける使用のためのキーワードは、要求レベルを示すために"。
[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.、ポーク、W.、フォード、W.およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年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）、Canonicalの符号化規則（CER）、および顕著な符号化規則（DER）の仕様"。
Informational References
情報の参照
[RFC791] Postel, J., "Internet Protocol -- DARPA Internet Program Protocol Specification", RFC 791, September 1981.
[RFC791]ポステル、J.、 "インターネットプロトコル - DARPAインターネットプログラムプロトコル仕様"、RFC 791、1981年9月。
[RFC1142] D. Oran, Ed., "OSI IS-IS Intra-domain Routing Protocol", RFC 1142, February 1990.
[RFC1142] D.オラン、エド。、RFC 1142、1990年2月 "OSIは、イントラドメインルーティングプロトコルIS-IS"。
[RFC1771] Rekhter, Y. and T. Li, Eds., "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771] Rekhter、Y.、およびT.李、編、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 1771、1995年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]ハバード、K.、Kosters、M.、コンラッド、D.、Karrenberg、D.およびJ.ポステル、 "インターネット登録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.デアリング、 "インターネットプロトコルバージョン6（IPv6）のアドレス指定アーキテクチャ"、RFC 3513、2003年4月。
[RFC3281] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[RFC3281]ファレル、S.とR. Housley氏、 "認可のためのインターネット属性証明書プロフィール"、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.ケント、C.リン、およびK.ソは、ネットワークセキュリティ、2000年4月にIEEE JSAC特集 "ボーダーゲートウェイプロトコル（S-BGP）を、セキュア"。
Authors' Address
著者の住所
Charles Lynn BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA
チャールズ・リンBBNテクノロジーズ10モールトンセントケンブリッジ、MA 02138 USA
Phone: +1 (617) 873-3367 EMail: CLynn@BBN.Com
電話：+1（617）873-3367 Eメール：CLynn@BBN.Com
Stephen Kent BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA
スティーブン・ケントBBNテクノロジーズ10モールトンセントケンブリッジ、MA 02138 USA
Phone: +1 (617) 873-3988 EMail: Kent@BBN.Com
電話：+1（617）873-3988 Eメール：Kent@BBN.Com
Karen Seo BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA
カレンソBBNテクノロジーズ10モールトンセントケンブリッジ、MA 02138 USA
Phone: +1 (617) 873-3152 EMail: KSeo@BBN.Com
電話：+1（617）873-3152 Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。