[要約] RFC 3779は、IPアドレスとAS識別子のためのX.509拡張機能に関する規格です。このRFCの目的は、X.509証明書にIPアドレスとAS識別子を含めるための標準化を提供することです。
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アドレスおよび識別子の拡張機能
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）The Internet Society（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アドレスブロックまたはプレフィックスのリストをバインドします。2番目は、自律システム識別子のリストを証明書の主題にバインドします。これらの拡張機能を使用して、拡張機能に含まれる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.
このドキュメントでは、IANAから地域インターネットレジストリ（RIRS）からインターネットサービスプロバイダー（ISP）とユーザーへの一連のIPアドレスおよび自律システム識別子の使用権の転送を許可する2つのX.509 V3証明書拡張機能を定義します。組織。最初のものは、多くの場合、IPアドレスのプレフィックスとして表されるIPアドレスブロックのリストを、証明書の主題（秘密キー保有者）にバインドします。2番目は、証明書の主題（秘密キーホルダー）の自律システム（as）識別子のリストにバインドします。証明書の発行者は、IPアドレスブロックのセットを（「割り当てる」）の管理者を譲渡する権限を持つ権限を持つエンティティ（例：IANA、地域のインターネットレジストリ、またはISP）です。証明書。これらの証明書は、一連の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つのインスタンスは、等しいオクセットごとに比較できます。第二に、情報の最小サイズのエンコードを実現します。第三に、認定パス検証を実行するときに、当事者がワンパスアルゴリズムを使用することを許可します。特に、頼る当事者は、情報を並べ替えたり、サブセットチェックアルゴリズムに追加のコードを実装して、いくつかの境界ケース（隣接、オーバーラップ、または包含範囲）を処理する必要はありません。
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:
読者は、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」[RFC3280]、「Internet Protocol」[RFC791]、「Internet Protocolバージョン6」に記載されている用語と概念に精通していると想定されています。（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アドレス-4つの10進数として記述された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アドレス-8からFFFFの範囲0からFFFFの範囲で、「：」で区切られた128ビット識別子。2001：0：200：3：0：0：0：1はIPv6アドレスの例です。1つの文字列：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：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アドレスの管理および識別子として地域当局として認識されている機関。執筆時点では、これらにはアフリニック、無呼吸、アリン、lad、熟した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]の値の2番目の最後のオクテット。
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 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アドレススペースをRIRSに割り当てます。RIRSは、IPアドレススペースをインターネットサービスプロバイダー（ISP）に割り当てます。IPアドレススペースをダウンストリームプロバイダー、顧客などに割り当てることができます。RIRSは、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で説明したように、これは、このセクションで説明されている拡張機能を伝える証明書を発行することによって達成されます。この拡張機能の情報の1つの使用の例は、それを使用して、特定のIPアドレスブロックへのパスを宣伝するBGPアップデートを発信する組織の承認を検証するために使用するエンティティです。たとえば、[RFC1771]、[S-BGP]を参照してください。
There are two families of IP addresses: IPv4 and IPv6.
IPアドレスの2つのファミリがあります：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で、ドット（ "）で区切られた範囲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アドレスは、セミコロン（ "："）で区切られた範囲0からFFFFの範囲内の8つの16進数として記述される128ビット数量です。2001：0：200：3：0：0：0：1はIPv6アドレスの例です。IPv6アドレスは、値が0である隣接するフィールドを頻繁に持っています。0フィールドのそのようなグループの1つは、2つのセミコロン（ "::"）によって略される可能性があります。したがって、前の例は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：0：0：0：0：0：0：0から2001：0：0：3ff：FFFF：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アドレスまたはプレフィックスは、DERエンコードされたASN.1ビット文字列として、最も重要な一定のビットを含むDer-Encoded 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-Encodingの後続のオクテットは0x0a 0x05 0x00 0x04です。最後のオクテットのすべてのビットが使用されるため、最初のオクテットは0x00です。したがって、derエンコードされたビット文字列のオクテットは次のとおりです。
Type Len Unused Bits ... 0x03 0x05 0x00 0x0a 0x05 0x00 0x04
タイプレン未使用ビット... 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
タイプレン未使用ビット... 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つあります。ビット）。
The DER-encoding of the IPv6 address 2001:0:200:3:0:0:0:1 is:
IPv6アドレス2001：0：200：3：0：0：0：1のDer-Encodingは次のとおりです。
Type Len Unused Bits ... 0x03 0x11 0x00 0x20 0x01 0x00 0x00 0x02 0x00 0x00 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01
タイプレン未使用ビット... 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：0：200/39のder-encodingは、最後のオクテットに1つの未使用のビットを持っています。
Type Len Unused Bits ... 0x03 0x06 0x01 0x20 0x01 0x00 0x00 0x02
タイプレン未使用ビット... 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ビットで終わります。結果の16ビット文字列のderエンコードは次のとおりです。
Type Len Unused Bits ... 0x03 0x03 0x00 0x0a 0x05
タイプレン未使用ビット... 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
タイプレン未使用ビット... 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は、最低のアドレスのderエンコードが次の範囲としてエンコードできます（2001：0：200：:)
Type Len Unused Bits ... 0x03 0x06 0x01 0x20 0x01 0x00 0x00 0x02
タイプレン未使用ビット... 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ビットの除去後、38ビット文字列を残し、次のようにエンコードされます。
Type Len Unused Bits ... 0x03 0x06 0x02 0x20 0x01 0x00 0x00 0x00
タイプレン未使用ビット... 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
タイプレン未使用ビット... 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
タイプレン未使用ビット... 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
タイプレン未使用ビット... 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.
この拡張機能は重要です。この拡張機能の使用は、拡張機能で識別されたIPアドレスのブロックに対して使用権を暗示することです。CAは、依存している当事者が発行された目的のために証明書を使用するために拡張のセマンティクスを理解しなければならないという概念を伝えるために重要であるとマークします。この拡張機能を含む証明書を使用する新しく作成されたアプリケーションは、拡張機能を認識することが期待されます。
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タイプは、アドレスファミリーと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.
アドレスファミリー要素は、ネットワークバイトの順序で、2オクテットアドレスファミリ識別子（AFI）を含むオクテット文字列であり、オプションで1オクテット後のアドレスファミリ識別子（SAFI）が続きます。AFIと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の一意の組み合わせごとに、iPaddressfamilyシーケンスは1つだけです。各シーケンスは、昇順のアドレスファミリー値（オクテットを符号なしの量として扱う）によって順序付けられる必要があります。SAFIのない住所ファミリーは、SAFIを含むものの前になければなりません。IPv4アドレスとIPv6アドレスの両方が指定されている場合、IPv4アドレスはIPv6アドレスの前になければなりません（0001のIPv4 AFIは0002のIPv6 AFIよりも少ないため）。
The ipAddressChoice element is of type IPAddressChoice. The IPAddressChoice type is a CHOICE of either an inherit or addressesOrRanges element.
iPaddresschoice要素は、iPaddresschoiceタイプです。iPaddresschoiceタイプは、継承またはaddressOranges要素のいずれかの選択です。
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の選択に継承要素が含まれている場合、指定されたAFIおよびオプションのSAFIの許可されたIPアドレスのセットは、発行者の証明書または発行者の発行者の証明書から再帰的に取得されます。位置した。
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>
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またはS：T：U：V：W：X：Y：Z | IPv6の長さ）は、der-Encodedビット文字列値にあるオクテットではないことに注意してください。たとえば、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.64.0.0/16の前にプレフィックス10.32.0.0/12が必要です。一方、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
n =最低のアドレスの残りのビットがすべてゼロビットであり、最高のアドレスの残りのビットがすべて1ビットである場合、範囲の最低および最高のアドレスの一致する最も重要なビットの数をn =n-bit iPaddressとしてエンコードされますelse他の範囲は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タイプは、アドレスの最も重要な（左端）nビットが一定のままである一方のIPアドレスの範囲を定義しますが、残りのビット（IPv4の場合は32 -Nビット、またはIPv6の128 -Nビット）ゼロまたは1つのいずれか。たとえば、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を表します。
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アドレスのプレフィックスは、少し文字列としてエンコードされています。ビット文字列の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
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
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タイプは、最小（要素min）と最大（要素最大）IPアドレスを含むシーケンスで構成されています。各IPアドレスは、少し文字列としてエンコードされます。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
}
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アドレス委任拡張機能とパスに沿ったすべての証明書を含む証明書の認証パス検証の信頼アンカーである証明書は、それぞれに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].
識別子代表団は現在、IANAに名目上根付いたが、RIRSによって管理されている階層によって管理されています。IANAはRIRSに識別子として割り当てます。RIRSは、エンティティであるエンティティである組織に識別子を割り当てます。つまり、識別子を他の組織に再割り当てしません。AS識別子代表団の拡張は、識別子の適切な委任、つまり、これらを識別子として使用するエンティティの承認の検証を可能にすることを目的としています。したがって、識別子を管理するための既存の管理枠組みの固有の権威性を利用することは理にかなっています。上記のセクション1で説明したように、これは、このセクションで説明されている拡張機能を伝える証明書を発行することによって達成されます。この拡張機能の情報の1つの使用の例は、それを使用して、拡張機能のAS識別子によって識別されたものを管理する組織の承認を検証するために使用するエンティティです。識別子の割り当てを表すためにこの拡張機能を使用することは、識別子が管理される手順を変更することを意図していません。
The OID for this extension is id-pe-autonomousSysIds.
この拡張機能のOIDは、ID-PE-AUTONOUSSYSIDSです。
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.
この拡張機能は重要です。この拡張機能の使用は、拡張機能のAS識別子の使用権を暗示することです。CAは、依存している当事者が発行された目的のために証明書を使用するために拡張のセマンティクスを理解しなければならないという概念を伝えるために重要であるとマークします。この拡張機能を含む証明書を使用する新しく作成されたアプリケーションは、拡張機能を認識することが期待されます。
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].
Asidentifiersタイプは、数値（Asnum要素）またはルーティングドメイン識別子（RDI要素）として、1つ以上のフォームの自律システム識別子を含むシーケンスです。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です。asididentifierchoiceタイプは、継承または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を含む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タイプです。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.
範囲要素にはタイプアスランジがあります。
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 Elementで構成されるシーケンスであり、識別子値の範囲を指定するために使用されます。
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があります。MIN要素は、範囲内の識別子として最小値の値を指定するために使用され、最大要素は範囲内の識別子として最大値の値を指定します。
The ASId type is an INTEGER.
ASIDタイプは整数です。
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識別子によって提出する必要があります。これが当てはまらない場合、検証は失敗する必要があります。自律システム識別子委任拡張機能を含む証明書の認証パス検証の信頼アンカーである証明書、およびパスに沿ったすべての証明書には、それぞれ自律システム識別子委任拡張機能を含める必要があります。識別子として許可された最初のセットは、信頼のアンカー証明書から取得されます。
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コンテキストでは、これらの拡張機能を含む証明書は機能として機能します。証明書は、秘密鍵（被験者）の所有者がIPアドレスを使用することを許可されているか、拡張機能に表されている識別子として認定されていると主張します。この能力モデルの結果として、サブジェクトフィールドは、一般的なPKI条約に反して、セキュリティ目的ではほとんど無関係です。
The authors would like to acknowledge the contributions to this specification by Charles Gardiner, Russ Housley, James Manger, and 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.
この規範的な付録では、IPアドレスと、ASN.1構文のPKIコンポーネントを適合させることで使用される識別子拡張機能を説明しています。
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) };
-- 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 I.E.、10.0.32.0から10.0.47.255 2）10.0.64/24 I.E.、10.0.64.0〜10.0.64.255 3）10.11/16 I.E.、10.1.0.0〜10.1.255.255 4）10.2.48/20 I.E.、10.2.48.0〜10.2.63.255 5）10.2.64/24 I.E.、10.2.64.0〜10.2.64.255 6）10.3/16 I.E.10.3.0.0から10.3.255.255、および7）は、発行者の証明書からすべてのIPv6アドレスを継承します（16進数で）：
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
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の未使用ビット（4）の数（4）の数がプレフィックス2の未使用ビットの数（0）よりも大きい場合でも、接頭辞1の前にプレフィックス1が前にある必要があります。
+ 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.)
+ 範囲の最大要素における6つのトレーリングゼロビットは、値のセマンティック解釈にとって重要であることに注意してください（すべての未使用ビットは0ではなく1であると解釈されるため）。MIN要素の4つのトレーリングゼロビットは有意ではなく、除去する必要があります（したがって、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）のタグよりも大きい場合でも、プレフィックス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（0002）の識別子よりも少ないため、IPv4情報はIPv6情報の前に先行する必要があります。
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マルチキャストアドレスを継承する拡張機能は（16進数で）（16進数）になります。
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-識別子代表団の例の例
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として指定され、発行者の証明書からすべてのルーティングドメイン識別子を継承する拡張機能は（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
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.
この付録では、地域のインターネットレジストリ（RIRS）からエンドユーザー組織まで、属性証明書（ACS、[RFC3281]で指定されているACS）を使用するという提案から生じる問題について説明します。アドレスブロックまたは識別子として。
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.
識別子とIPアドレスブロックとしての2つのリソースは、現在異なって管理されています。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では、認証情報を伝える拡張機能を備えた公開キー証明書（PKC）の使用よりも、ACSの使用が望ましい理由について2つの理由が与えられます。
"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）に配置される場合があります。PKCSの許可情報の配置は通常、2つの理由で望ましくありません。まず、認可情報は、しばしばの拘束力と同じ寿命を持たないことがよくあります。IDと公開鍵。許可情報が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から分離する方が良いことがよくあります。しかし、認可情報もIDにバインドする必要があります。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アドレスの場合、および識別子許可として、これらの理由は適用されません。第一に、公開キーの証明書は承認専用に発行されるため、証明書の寿命は承認寿命に正確に対応します。サブジェクト名と発行者名は、認証パス検証中にチェーンにのみ使用され、名前は物理エンティティに対応する必要はありません。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.
したがって、上記の最初に引用された段落の2つのポイントは、AS番号およびIPアドレスブロックの割り当ての場合、真実ではありません。2番目の引用された段落のポイントは、リソースがアイデンティティに縛られていないのではなく、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から：「この仕様では、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.
IANAからRIRSへの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から：「セクション4.3は、このプロファイルで使用できる拡張機能と、それらが重要とマークされるかどうかを定義します。他の非クリティカルな拡張機能が使用されている場合、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に配置できないことを意味します。それらは重要でない場合は使用できますが、意図した使用には、拡張機能が重要であることを要求して、それらを含む証明書を疑いを持たないアプリケーションによってID証明書として使用できません。
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."
3セクション4.5から：「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が使用されている場合、必要な場合よりも属性証明書をサポートするために処理するために、証明書発行者とCRLが2倍の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発行者（すべてのRIRSおよび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)."
4セクション5から：「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）を構成することは、他のすべての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.
[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。and D. Solo、「インターネット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）、標準エンコードルール（CER）および識別済みエンコードルール（DER）の仕様」。
Informational References
情報参照
[RFC791] Postel, J., "Internet Protocol -- DARPA Internet Program Protocol Specification", RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル-DARPAインターネットプログラムプロトコル仕様」、RFC 791、1981年9月。
[RFC1142] D. Oran, Ed., "OSI IS-IS Intra-domain Routing Protocol", RFC 1142, February 1990.
[RFC1142] D. Oran、ed。、「OSI IS-IS-IS IS INTRAドメインルーティングプロトコル」、RFC 1142、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、eds。、「A Border Gateway Protocol 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] Hawkinson、J。およびT. Bates、「自律システムの作成、選択、登録に関するガイドライン（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、「認証のためのインターネット属性証明書プロファイル」、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、「Secure Border Gateway Protocol（S-BGP）」、IEEE JSAC特別号、ネットワークセキュリティ、2000年4月。
Authors' Address
著者の住所
Charles Lynn BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA
チャールズリンBBNテクノロジーズ10モールトンセントケンブリッジ、マサチューセッツ州02138 USA
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 Moulton St. Cambridge、MA 02138 USA
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 Moulton St. Cambridge、MA 02138 USA
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）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。