RFC3779 日本語訳
3779 X.509 Extensions for IP Addresses and AS Identifiers. C. Lynn, S.Kent, K. Seo. June 2004. (Format: TXT=60732 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Lynn
Request for Comments: 3779 S. Kent
Category: Standards Track K. Seo
BBN Technologies
June 2004
コメントを求めるワーキンググループC.リン要求をネットワークでつないでください: 3779秒間ケントカテゴリ: 標準化過程K.Seo BBN技術2004年6月
X.509 Extensions for IP Addresses and AS Identifiers
IPアドレスと識別子としてのX.509拡張子
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(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証明書拡張子を定義します。 1番目はIPあて先ブロックのリスト、または証明書の対象への接頭語を縛ります。 秒は自律システム識別子のリストを証明書の対象に縛ります。 これらの拡張子は、拡大に含まれたIPアドレスと自律システム識別子を使用するために対象の認可を伝えるのに使用されるかもしれません。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3
2. IP Address Delegation Extension. . . . . . . . . . . . . . . . 5
2.1. Context. . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Encoding of an IP Address or Prefix. . . . . . . 5
2.1.2. Encoding of a Range of IP Addresses. . . . . . . 7
2.2. Specification. . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. OID. . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2. Criticality. . . . . . . . . . . . . . . . . . . 9
2.2.3. Syntax . . . . . . . . . . . . . . . . . . . . . 9
2.2.3.1. Type IPAddrBlocks. . . . . . . . . . . 9
2.2.3.2. Type IPAddressFamily . . . . . . . . . 9
2.2.3.3. Element addressFamily. . . . . . . . . 10
2.2.3.4. Element ipAddressChoice and Type
IPAddressChoice. . . . . . . . . . . . 10
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 用語。 . . . . . . . . . . . . . . . . . . . . . . 3 2. IPアドレス代表団拡大。 . . . . . . . . . . . . . . . 5 2.1. 文脈。 . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. IPアドレスか接頭語がコード化されます。 . . . . . . 5 2.1.2. さまざまなIPアドレスがコード化されます。 . . . . . . 7 2.2. 仕様。 . . . . . . . . . . . . . . . . . . . . . 8 2.2.1. OID。 . . . . . . . . . . . . . . . . . . . . . . 8 2.2.2. 臨界。 . . . . . . . . . . . . . . . . . . 9 2.2.3. 構文、.92.2 .3 .1。 IPAddrBlocksをタイプしてください。 . . . . . . . . . . 9 2.2.3.2. タイプIPAddressFamily. . . . . . . . . 9 2.2.3.3。 要素addressFamily。 . . . . . . . . 10 2.2.3.4. 要素ipAddressChoiceとタイプIPAddressChoice。 . . . . . . . . . . . 10
Lynn, et al. Standards Track [Page 1] RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
リン、他 規格は2004年6月にIP AddrとIDとしてRFC3779X.509拡張子を追跡します[1ページ]。
2.2.3.5. Element inherit. . . . . . . . . . . . 10
2.2.3.6. Element addressesOrRanges. . . . . . . 10
2.2.3.7. Type IPAddressOrRange. . . . . . . . . 11
2.2.3.8. Element addressPrefix and Type
IPAddress. . . . . . . . . . . . . . . 11
2.2.3.9. Element addressRange and Type
IPAddressRange . . . . . . . . . . . . 12
2.3. IP Address Delegation Extension Certification Path
Validation . . . . . . . . . . . . . . . . . . . . . . . 12
3. Autonomous System Identifier Delegation Extension. . . . . . . 13
3.1. Context . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Specification. . . . . . . . . . . . . . . . . . . . . . 13
3.2.1. OID. . . . . . . . . . . . . . . . . . . . . . . 13
3.2.2. Criticality. . . . . . . . . . . . . . . . . . . 14
3.2.3. Syntax . . . . . . . . . . . . . . . . . . . . . 14
3.2.3.1. Type ASIdentifiers . . . . . . . . . . 14
3.2.3.2. Elements asnum, rdi, and Type
ASIdentifierChoice . . . . . . . . . . 14
3.2.3.3. Element inherit. . . . . . . . . . . . 15
3.2.3.4. Element asIdsOrRanges. . . . . . . . . 15
3.2.3.5. Type ASIdOrRange . . . . . . . . . . . 15
3.2.3.6. Element id . . . . . . . . . . . . . . 15
3.2.3.7. Element range. . . . . . . . . . . . . 15
3.2.3.8. Type ASRange . . . . . . . . . . . . . 15
3.2.3.9. Elements min and max . . . . . . . . . 15
3.2.3.10. Type ASId. . . . . . . . . . . . . . . 15
3.3. Autonomous System Identifier Delegation Extension
Certification Path Validation. . . . . . . . . . . . . . . . 16
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 16
5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 16
Appendix A -- ASN.1 Module . . . . . . . . . . . . . . . . . . . . 17
Appendix B -- Examples of IP Address Delegation Extensions . . . . 18
Appendix C -- Example of an AS Identifier Delegation Extension . . 21
Appendix D -- Use of X.509 Attribute Certificates. . . . . . . . . 21
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Normative References . . . . . . . . . . . . . . . . . . . . . . . 24
Informative References . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 27
2.2.3.5. 要素は世襲されます。 . . . . . . . . . . . 10 2.2.3.6. 要素addressesOrRanges。 . . . . . . 10 2.2.3.7. IPAddressOrRangeをタイプしてください。 . . . . . . . . 11 2.2.3.8. 要素addressPrefixとタイプIPAddress。 . . . . . . . . . . . . . . 11 2.2.3.9. 要素addressRangeとタイプIPAddressRange. . . . . . . . . . . . 12 2.3。 IPアドレス代表団拡大証明経路合法化. . . . . . . . . . . . . . . . . . . . . . . 12 3。 自律システム識別子代表団拡張子。 . . . . . . 13 3.1. 文脈. . . . . . . . . . . . . . . . . . . . . . . . 13 3.2。 仕様。 . . . . . . . . . . . . . . . . . . . . . 13 3.2.1. OID。 . . . . . . . . . . . . . . . . . . . . . . 13 3.2.2. 臨界。 . . . . . . . . . . . . . . . . . . 14 3.2.3. 構文、.143.2 .3 .1。 タイプASIdentifiers. . . . . . . . . . 14 3.2.3.2。 要素はrdi、およびType ASIdentifierChoice.143.2にasnumされます。.3 .3。 要素は世襲されます。 . . . . . . . . . . . 15 3.2.3.4. 要素asIdsOrRanges。 . . . . . . . . 15 3.2.3.5. タイプASIdOrRange. . . . . . . . . . . 15 3.2.3.6。 要素イド. . . . . . . . . . . . . . 15 3.2.3.7。 要素範囲。 . . . . . . . . . . . . 15 3.2.3.8. タイプASRange. . . . . . . . . . . . . 15 3.2.3.9。 要素分、.153.2に.10に.3に最大限にしてください。 ASIdをタイプしてください。 . . . . . . . . . . . . . . 15 3.3. 自律システム識別子代表団拡大証明経路合法化。 . . . . . . . . . . . . . . . 16 4. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 16 5. 承認。 . . . . . . . . . . . . . . . . . . . . . . . 16 付録A--ASN.1モジュール. . . . . . . . . . . . . . . . . . . . 17付録B--IPアドレス代表団拡大. . . . 18付録Cに関する例--例、識別子代表団拡張子. . 21付録D--X.509属性証明書の使用。 . . . . . . . . 21の参照箇所. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24の引用規格. . . . . . . . . . . . . . . . . . . . . . . 24の有益な参照. . . . . . . . . . . . . . . . . . . . . . 25作者のアドレスの.26の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 27
Lynn, et al. Standards Track [Page 2] RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
リン、他 規格は2004年6月にIP AddrとIDとしてRFC3779X.509拡張子を追跡します[2ページ]。
1. Introduction
1. 序論
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)まで1セットのIPアドレスと自律システム識別子の権利から使用の転送をインターネット接続サービス業者(ISP)に認可する2つのX.509 v3証明書拡張子とユーザ組織を定義します。 1番目はIPアドレス接頭語としてしばしば表されたIPあて先ブロックのリストを証明書の対象(秘密鍵所有者)に縛ります。 秒は証明書の対象(秘密鍵所有者)に自律システム(AS)識別子のリストを縛ります。 証明書の発行人はIPあて先ブロックとAS識別子の(「割り当てる」)セットの管理人の任務を証明書の対象に移す権威がある実体(例えば、IANA、地方のインターネット登録、またはISP)です。 これらの証明書は1セットのIPアドレス接頭語とAS識別子の権利から使用について確かめるスケーラブルな手段を提供します。 それらはルーティング情報の合法性と正当性について確かめるために、Secure 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つの例を比較できます。 2番目に、彼らは情報の最小量のサイズコード化を達成します。 3番目に、彼らは証明経路合法化を実行するとき、1パスのアルゴリズムを使用するために信用にパーティーを許します。 信用パーティーは、情報を分類するか、または特に、数個の境界ケース(隣接しているか、重なっているか、包括された範囲)を扱うためにアルゴリズムをチェックする部分集合の余分なコードを実行する必要はありません。
1.1. Terminology
1.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:
読者が「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)プロフィール」[RFC3280]、「インターネットプロトコル」[RFC791]、「インターネットプロトコルバージョン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]を見る)へのリソースの管理人の任務の転送。
Lynn, et al. Standards Track [Page 3] RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
リン、他 規格は2004年6月にIP AddrとIDとしてRFC3779X.509拡張子を追跡します[3ページ]。
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.
自治のSystem(AS)--一定の方針があるただ一つの技術的な管理の下における、1セットのルータ、内部の1つ以上の門以上を使用して、自律システムと、外のゲートウェイを使用する中でパケットを発送する方法を決定するプロトコルと測定基準は、他の自律システムにパケットを発送する方法を決定するために議定書を作ります。
Autonomous System number - a 32-bit number that identifies an
autonomous system.
自治の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あて先ブロックかAS識別子の管理人の任務(すなわち、権利から使用)の転送。
initial octet - the first octet in the value of a DER encoded BIT
STRING [X.690].
初期の八重奏--DERの値における最初の八重奏はBIT STRING[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進数と、それぞれ範囲に0〜255に書かれた32ビットの識別子はaを切り離した」、」 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つの16進量として書かれた128ビットの識別子(ffffへの範囲0のそれぞれ)はaで分離した」:、」 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.
「接頭語--それを少し結ぶのはアドレスがa」/で従って書かれたアドレスの何らかの数の初期のビットから成る」、および初期のビットの数。 または、そして、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.
地方のインターネットRegistry(RIR)--IPアドレスとAS識別子の管理のための地方分権として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を指定するのが認可される場合、それはインターネット中で接頭語の広告を溯源するかもしれません。 自律システム識別子に関しては、ネットワークを経営するのが認可されて、それは、その自律システム識別子を使用することで他のネットワーク・オペレータにそれ自体を特定します。
Lynn, et al. Standards Track [Page 4] RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
リン、他 規格は2004年6月にIP AddrとIDとしてRFC3779X.509拡張子を追跡します[4ページ]。
subsequent octets - the second through last octets in the value of a
DER encoded BIT STRING [X.690].
その後の八重奏--DERの値における最後の八重奏による2番目はBIT STRING[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]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
2. IP Address Delegation Extension
2. IPアドレス代表団拡大
This extension conveys the allocation of IP addresses to an entity by binding those addresses to a public key belonging to the entity.
この拡大は、実体に属す公開鍵にそれらのアドレスを縛ることによって、IPアドレスの配分を実体に伝えます。
2.1. Context
2.1. 文脈
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はインターネット接続サービス業者(ISP)にIPアドレス空間を割り当てます)。(インターネット接続サービス業者は、流れのプロバイダー、顧客などより倒すために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 UPDATEを溯源するために組織の認可について確かめるのにそれを使用する実体です。 例えば[RFC1771]、[S-BGP]を見てください。
2.1.1. Encoding of an IP Address or Prefix
2.1.1. IPアドレスか接頭語のコード化
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アドレスは4つの10進数と、それぞれ範囲に0〜255に書かれている32ビットの量です、ドットによって切り離されて(「」、)。 10.5.0.5 IPv4アドレスが例がありますか?
Lynn, et al. Standards Track [Page 5] RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
リン、他 規格は2004年6月にIP AddrとIDとしてRFC3779X.509拡張子を追跡します[5ページ]。
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進数として書かれている128ビットの量です、それぞれセミコロンによって切り離されたffffを通した範囲0で(「:」、)、。 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連続することのセットがだれのものを最も記述するということです。重要なビットは同じです。 例えば、512IPv4のセットが10.5から.0を記述する、.0、通じて、10.5、.1、.255、すべてには、同じ23の最上位ビットがあります。 アドレスのセットは、スラッシュ(「/」)と一定のビットの数をセットで最も低いアドレスに追加することによって、書かれています。 例のセットのための接頭語が10.5である、.0、.0/23、2つの^9 2^(32-23)=アドレスを含んでいます。 IPv6アドレスのセット、2001 : 0:、200:0:0、:、0:0:0、: ffff(2^89のアドレス)が表される2001:0:3ff:ffff:ffff:ffff:ffff、2001 : 0:、200:0:0、:、0:0:0/39、同等である、2001:0:200:、:/39. 接頭語は最も最少に重要なゼロ磁場を省略することによって、簡略化されるかもしれませんが、一定のビットの示された数を含むことができるくらいの分野があるべきです。 例のIPv4接頭語の簡略化されたフォームが10.5である、.0/23、2001:0:200/39は例のIPv6接頭語の、そうです。
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.1BIT STRINGとしてIPアドレス代表団拡大でコード化されます。 BIT STRINGのDERコード化がBIT STRINGタイプ(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ビットを含んでいます。 アドレスのDER-コード化におけるその後の八重奏、10.5、.0、.4、0x0aである、0×05、0×00、0×04 最後の八重奏におけるすべてのビットが使用されているので、初期の八重奏は0×00です。 その結果、DERによってコード化されたBIT STRINGの八重奏は以下の通りです。
Type Len Unused Bits ...
0x03 0x05 0x00 0x0a 0x05 0x00 0x04
レンUnusedのビットをタイプしてください… 0×03 0×05 0×00 0x0a0x05 0×00、0×04
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
レンUnusedのビットをタイプしてください… 0×03 0×04 0×01 0x0a0x05 0×00
Lynn, et al. Standards Track [Page 6] RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
リン、他 規格は2004年6月にIP AddrとIDとしてRFC3779X.509拡張子を追跡します[6ページ]。
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).
接頭語は23しか使用しません、そして、したがって、最後の八重奏には未使用の1ビットがあります、そして、この場合、3つのその後の八重奏が24ビットを含みますが、その結果、初期の八重奏は1(DERは、すべての未使用のビットをゼロ・ビットに設定しなければならないのを必要とする)です。
The DER-encoding of the IPv6 address 2001:0:200:3:0:0:0:1 is:
IPv6アドレスのDER-コード化、2001 : 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
レンUnusedのビットをタイプしてください… 0×03 0×11 0×00、0×20、0×01、0×00、0×00、0×02、0×00、0×00、0×03、0×00、0×00、0×00、0×00、0×00、0×00、0×00、0×01
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-コード化は以下の通りです。(接頭語は最後の八重奏で未使用の1ビットを持っています)。
Type Len Unused Bits ...
0x03 0x06 0x01 0x20 0x01 0x00 0x00 0x02
レンUnusedのビットをタイプしてください… 0×03 0×06 0×01、0×20、0×01、0×00、0×00、0×02
2.1.2. Encoding of a Range of IP Addresses
2.1.2. さまざまなIPアドレスのコード化
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.
1セットの隣接の接頭語でどんな隣接の範囲のIPアドレスも表すことができますが、より簡潔な表現は、含む中で各アドレスがBIT STRINGとしてコード化される最も低いアドレスとアドレス最も高いSEQUENCEとして範囲をコード化することによって、達成されます。 SEQUENCEの中では、表す中で範囲でアドレス最も低いビット列は最も最少にすべての重要を取り除くことによって、形成されます、そして、アドレスからの無ビットで表す中で範囲でアドレス最も高いビット列は最も最少にすべての重要を1ビット取り除くことによって、形成されます。 DER BIT STRINGコード化は、最後の八重奏におけるすべての未使用のビットをゼロ・ビットに設定しなければならないのを必要とします。 範囲としていつも接頭語を表すことができますが、接頭語としていつも範囲を言い表すことができるというわけではないことに注意してください。
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 23.0/時表されたアドレスの範囲が10.5である、.0、.0、通じて、10.5 .1 .255。 最も低いアドレスは取り除かれる16ゼロ・ビットに終わります。 結果として起こる16ビット列のDER-コード化は以下の通りです。
Type Len Unused Bits ...
0x03 0x03 0x00 0x0a 0x05
レンUnusedのビットをタイプしてください… 0×03 0×03 0×00 0x0a0x05
The highest address ends in nine one-bits that are removed. The DER- encoding of the resulting twenty-three-bit string is:
最も高いアドレスは取り除かれる9 1ビットに終わります。 結果として起こる20-3ビット列のDERコード化は以下の通りです。
Type Len Unused Bits ...
0x03 0x04 0x01 0x0a 0x05 0x00
レンUnusedのビットをタイプしてください… 0×03 0×04 0×01 0x0a0x05 0×00
Lynn, et al. Standards Track [Page 7] RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
リン、他 規格は2004年6月にIP AddrとIDとしてRFC3779X.509拡張子を追跡します[7ページ]。
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
レンUnusedのビットをタイプしてください… 0×03 0×06 0×01、0×20、0×01、0×00、0×00、0×02
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:
そして、90最も最少に重要な1ビットの取り外しが38ビット列を残した後に以下としてコード化される中で最も大きいアドレス(2001:0:3ff:ffff:ffff:ffff:ffff: ffff)
Type Len Unused Bits ...
0x03 0x06 0x02 0x20 0x01 0x00 0x00 0x00
レンUnusedのビットをタイプしてください… 0×03 0×06 0×02、0×20、0×01、0×00、0×00、0×00
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
レンUnusedのビットをタイプしてください… 0×03 0×01 0×00
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
レンUnusedのビットをタイプしてください… 0×03 0×03 0×04 0x0a0x40
is different than the DER-encoding of 10.64.0/20:
10.64のDER-コード化.0/20と、異なります:
Type Len Unused Bits ...
0x03 0x04 0x04 0x0a 0x40 0x00
レンUnusedのビットをタイプしてください… 0×03 0×04 0×04 0x0a0x40 0×00
2.2. Specification
2.2. 仕様
2.2.1. OID
2.2.1. OID
The OID for this extension is id-pe-ipAddrBlocks.
この拡大のためのOIDはイド-pe-ipAddrBlocksです。
id-pe-ipAddrBlocks OBJECT IDENTIFIER ::= { id-pe 7 }
イド-pe-ipAddrBlocks物の識別子:、:= イド-pe7
where [RFC3280] defines:
[RFC3280]が以下を定義するところ
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
イド-pkix OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
イド-pe OBJECT IDENTIFIER:、:= イド-pkix1
Lynn, et al. Standards Track [Page 8] RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
リン、他 規格は2004年6月にIP AddrとIDとしてRFC3779X.509拡張子を追跡します[8ページ]。
2.2.2. Criticality
2.2.2. 臨界
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.
この拡大SHOULD、CRITICALになってください。 この拡張子の意図している使用は拡大で特定されたIPアドレスのブロックの権利から使用を内包することです。 カリフォルニアは、信用パーティーが、拡大の意味論がそれが発行された目的のための証明書を利用するのを理解しなければならないという概念を伝えるためにCRITICALとして拡大をマークします。 この拡大を含む証明書を使用する新たに作成されたアプリケーションが拡大を認識すると予想されます。
2.2.3. Syntax
2.2.3. 構文
id-pe-ipAddrBlocks OBJECT IDENTIFIER ::= { id-pe 7 }
イド-pe-ipAddrBlocks物の識別子:、:= イド-pe7
IPAddrBlocks ::= SEQUENCE OF IPAddressFamily
IPAddrBlocks:、:= IPAddressFamilyの系列
IPAddressFamily ::= SEQUENCE { -- AFI & optional SAFI --
addressFamily OCTET STRING (SIZE (2..3)),
ipAddressChoice IPAddressChoice }
IPAddressFamily:、:= 系列--AFIと任意のサフィ--addressFamily OCTET STRING(SIZE(2 .3))、ipAddressChoice IPAddressChoice
IPAddressChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
addressesOrRanges SEQUENCE OF IPAddressOrRange }
IPAddressChoice:、:= 選択{NULL--発行人から世襲するのを引き継いでください--addressesOrRanges SEQUENCE OF IPAddressOrRange}
IPAddressOrRange ::= CHOICE {
addressPrefix IPAddress,
addressRange IPAddressRange }
IPAddressOrRange:、:= 選択addressPrefix IPAddress、addressRange IPAddressRange
IPAddressRange ::= SEQUENCE {
min IPAddress,
max IPAddress }
IPAddressRange:、:= 系列分IPAddress、最大IPAddress
IPAddress ::= BIT STRING
IPAddress:、:= ビット列
2.2.3.1. Type IPAddrBlocks
2.2.3.1. IPAddrBlocksをタイプしてください。
The IPAddrBlocks type is a SEQUENCE OF IPAddressFamily types.
IPAddrBlocksタイプはSEQUENCE OF IPAddressFamilyがタイプするということです。
2.2.3.2. Type IPAddressFamily
2.2.3.2. IPAddressFamilyをタイプしてください。
The IPAddressFamily type is a SEQUENCE containing an addressFamily and ipAddressChoice element.
IPAddressFamilyタイプはaddressFamilyとipAddressChoice要素を含むSEQUENCEです。
Lynn, et al. Standards Track [Page 9] RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
リン、他 規格は2004年6月にIP AddrとIDとしてRFC3779X.509拡張子を追跡します[9ページ]。
2.2.3.3. Element addressFamily
2.2.3.3. 要素addressFamily
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要素は2八重奏のAddress Family Identifier(AFI)を含むOCTET STRINGです、1八重奏のSubsequent Address Family Identifier(サフィ)によって任意に続かれたネットワークバイトオーダーで。 AFIsとSAFIsは[IANA-AFI]と[IANA-サフィ]でそれぞれ指定されます。
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と任意のサフィに承諾されていないなら、そのAFI/サフィへのIPAddressFamilyメンバーがIPAddrBlocks SEQUENCEにいるはずがありません。
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とサフィのユニークな組み合わせあたり1IPAddressFamily SEQUENCEしかないに違いありません。 各SEQUENCE MUST、addressFamily値を昇ることによって、命令されてください(無記名の量として八重奏を扱って)。 サフィのないaddressFamilyはサフィを含むものに先行しなければなりません。 IPv4とIPv6アドレスの両方が指定されるとき、IPv4アドレスはIPv6アドレスに先行しなければなりません(0001年のIPv4 AFIが0002年のIPv6 AFI以下であるので)。
2.2.3.4. Element ipAddressChoice and Type IPAddressChoice
2.2.3.4. 要素ipAddressChoiceとタイプIPAddressChoice
The ipAddressChoice element is of type IPAddressChoice. The IPAddressChoice type is a CHOICE of either an inherit or addressesOrRanges element.
タイプIPAddressChoiceにはipAddressChoice要素があります。 世襲してください。IPAddressChoiceタイプがどちらかのCHOICEである、または、addressesOrRanges要素。
2.2.3.5. Element inherit
2.2.3.5. 要素は世襲されます。
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と任意のサフィへの認可されたIPアドレスのセットが発行人の証明書から抜粋されるか、または発行人の発行人の証明書から、再帰的に、IPAddressChoiceを含む証明書までaddressesOrRanges要素を含むのは見つけられています。
2.2.3.6. Element addressesOrRanges
2.2.3.6. 要素addressesOrRanges
The addressesOrRanges element is a SEQUENCE OF IPAddressOrRange types. The addressPrefix and addressRange elements MUST be sorted using the binary representation of:
addressesOrRanges要素はSEQUENCE OF IPAddressOrRangeがタイプするということです。 以下の2進法表示を使用して、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のための長さかIPv6のためのs:t:u:v:w:x:y:z|長さ)における八重奏がDERによってコード化されたBIT STRING値にはある八重奏でないことに注意してください。 例えば、与えられた2addressPrefix:
Lynn, et al. Standards Track [Page 10] RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
リン、他 規格は2004年6月にIP AddrとIDとしてRFC3779X.509拡張子を追跡します[10ページ]。
IP addr | length DER encoding
---------------- ------------------------
Type Len Unused Bits...
10.32.0.0 | 12 03 03 04 0a 20
10.64.0.0 | 16 03 03 00 0a 40
IP addr| 長さのDERコード化---------------- ------------------------ レンUnusedのビットをタイプしてください… 10.32.0.0 | 12 03 03 04 0a20 10.64.0、.0| 16 03 03 00 0a40
the prefix 10.32.0.0/12 MUST come before the prefix 10.64.0.0/16 since 32 is less than 64; whereas if one were to sort by the DER BIT STRINGs, the order would be reversed as the unused bits octet would sort in the opposite order. Any pair of IPAddressOrRange choices in an extension MUST NOT overlap each other. Any contiguous address prefixes or ranges MUST be combined into a single range or, whenever possible, a single prefix.
10.32に.0/12が接頭語10.64の前に来させなければならない.0を前に置いてください。.0 32以来の.0/16は64未満です。 種類に1つがDER BIT STRINGsであるなら、オーダーは八重奏が反対のオーダーで分類する未使用のビットとして逆にされるでしょうにが。 拡大における、どんな組のIPAddressOrRange選択も互いを重ね合わせてはいけません。 ただ一つの範囲か可能であるときはいつも、ただ一つの接頭語にどんな隣接のアドレス接頭語や範囲も結合しなければなりません。
2.2.3.7. Type IPAddressOrRange
2.2.3.7. 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アドレスの範囲)要素のどちらかのCHOICEです。
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要素(BIT STRING)、および接頭語をコード化しなければならないときコード化できないどんな範囲も使用して、IPAddressRange(2BIT STRINGsを含むSEQUENCE)を使用して、接頭語としてコード化できるどんな範囲のアドレスもコード化しなければならないのを必要とします。 以下の中間コードは与えられた範囲のアドレスのコード化を選択する方法を例証します。
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
LET Nが数と等しい、最も低いアドレスのすべての残っているビットがゼロ・ビットであり、最も高いアドレスのすべての残っているビットが1ビットのTHENであるなら範囲の最も低くて最も高いアドレスの最上位ビットを合わせることにおいて、範囲はN-ビットIPAddress ELSEとしてコード化されて、IPAddressRangeとして範囲をコード化しなければならないということであるに違いありません。
2.2.3.8. Element addressPrefix and Type IPAddress
2.2.3.8. 要素addressPrefixとタイプIPAddress
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アドレスを定義します、残っているビット(32--IPv4、または128のためのNビット--IPv6のための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: ffffに。
An IP address prefix is encoded as a BIT STRING. The DER encoding of a BIT STRING uses the initial octet of the string to specify how many of the least-significant bits of the last subsequent octet are
IPアドレス接頭語はBIT STRINGとしてコード化されます。 BIT STRINGのDERコード化は、最後のその後の八重奏の最下位ビットのいくつがあるかを指定するのにストリングの初期の八重奏を使用します。
Lynn, et al. Standards Track [Page 11] RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
リン、他 規格は2004年6月にIP AddrとIDとしてRFC3779X.509拡張子を追跡します[11ページ]。
unused. The DER encoding specifies that these unused bits MUST be set to zero-bits.
未使用。 DERコード化は、これらの未使用のビットをゼロ・ビットに設定しなければならないと指定します。
Example:
128.0.0.0 = 1000 0000.0000 0000.0000 0000.0000 0000
to 143.255 255 255 = 1000 1111.1111 1111.1111 1111.1111 1111
bit string to encode = 1000
Type Len Unused Bits ...
Encoding = 0x03 0x02 0x04 0x80
例: 128.0.0.0 = 1000 0000.0000 0000.0000 0000.0000 0000 =1000TypeレンUnused Bitsを…コード化する143.255 255 255 = 1000 1111.1111 1111.1111 1111.1111 1111ビット列に =0x03 0×02をコード化する、0×04、0×80
2.2.3.9. Element addressRange and Type IPAddressRange
2.2.3.9. 要素addressRangeとタイプIPAddressRange
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.
タイプIPAddressRangeにはaddressRange要素があります。 IPAddressRangeタイプは最小(要素分)の、そして、最大(要素最大)のIPアドレスを含むSEQUENCEから成ります。 それぞれのIPアドレスはBIT STRINGとしてコード化されます。 IPAddressRangeの最小のアドレスの意味解釈はすべての不特定のビット(IPアドレスの完全な長さのための)がゼロ・ビットであるということです。 最大のアドレスの意味解釈はすべての不特定のビットが1ビットであるということです。 最小のアドレスのためのBIT STRINGは最小のアドレスからすべての最も最少に重要なゼロ・ビットで離れたところに取り外しから生じます。 最大のためのBIT STRINGは最も最少にすべての重要を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の最大のビット列=1000EncodingはSEQUENCEと等しいです。レンUnused Bits分0×03 0×03 0×06 0×81 0×40最大0x03 0x02 0x04…0×80をタイプしてください。
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アドレスがすなわち値が1である少なくとも1ビットを含まなければならないIPあて先ブロックの比較を簡素化するために、その後の八重奏は省略されないかもしれません。またはすべてのゼロ。
2.3. IP Address Delegation Extension Certification Path Validation
2.3. IPアドレス代表団拡大証明経路合法化
Certification path validation of a certificate containing the IP address delegation extension requires additional processing. As each certificate in a path is validated, the IP addresses in the IP address delegation extension of that certificate MUST be subsumed by IP addresses in the IP address delegation extension in the issuer's certificate. Validation MUST fail when this is not the case. A
IPアドレス代表団拡大を含む証明書の証明経路合法化は追加処理を必要とします。 経路の各証明書が有効にされるとき、発行人の証明書におけるIPアドレス代表団拡大でIPアドレスでその証明書のIPアドレス代表団拡大におけるIPアドレスを包括しなければなりません。 これがそうでないときに、合法化は失敗しなければなりません。 A
Lynn, et al. Standards Track [Page 12] RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
リン、他 規格は2004年6月にIP AddrとIDとしてRFC3779X.509拡張子を追跡します[12ページ]。
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アドレス代表団拡大を含まなければなりません。 許容アドレスの範囲の始発は信用アンカー証明書から抜粋されます。
3. Autonomous System Identifier Delegation Extension
3. 自律システム識別子代表団拡張子
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)識別子の配分を実体に伝えます。
3.1. Context
3.1. 文脈
AS identifier delegation is currently managed by a hierarchy nominally rooted at IANA, but managed by the RIRs. IANA allocates AS identifiers to the RIRs, who in turn assign AS identifiers to organizations who are end entities, i.e., will not be re-allocating any of their AS identifiers to other organizations. The AS identifier delegation extension is intended to enable verification of the proper delegation of AS identifiers, i.e., of the authorization of an entity to use these AS identifiers. Accordingly, it makes sense to take advantage of the inherent authoritativeness of the existing administrative framework for management of AS identifiers. As described in Section 1 above, this will be achieved by issuing certificates carrying the extension described in this section. An example of one use of the information in this extension is an entity using it to verify the authorization of an organization to manage the AS identified by an AS identifier in the extension. The use of this extension to represent assignment of AS identifiers is not intended to alter the procedures by which AS identifiers are managed, or when an AS should be used c.f., [RFC1930].
AS識別子代表団は、現在名目上はIANAに根づいている階層構造によって管理されますが、RIRsによって経営されます。 IANAはRIRsへの識別子をASに割り当てて、だれが順番にすなわち終わりの実体である組織への識別子をASに割り当てるかがそれらのAS識別子のいずれも他の組織に再割当てしないでしょう。 AS識別子代表団拡張子が、すなわち、AS識別子の適切な代表団、実体の認可の検証がこれらのAS識別子を使用するのを可能にすることを意図します。 それに従って、それはASの管理に既存の管理枠組みの固有の正式を利用する意味を識別子にします。 セクション1で説明されるように、上に、これはこのセクションで説明された拡大を載せる証明書を発行することによって、達成されるでしょう。 この拡大における情報の1つの使用に関する例はAS識別子によって拡大で特定されたASを管理するために組織の認可について確かめるのにそれを使用する実体です。 AS識別子の課題を表すこの拡張子の使用がどのAS識別子が管理されるか、そして、ASがいつ中古のc.f.であるべきであるまでに手順を変更することを意図しません、[RFC1930。]
3.2. Specification
3.2. 仕様
3.2.1. OID
3.2.1. OID
The OID for this extension is id-pe-autonomousSysIds.
この拡大のためのOIDはイド-pe-autonomousSysIdsです。
id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 8 }
イド-pe-autonomousSysIds物の識別子:、:= イド-pe8
where [RFC3280] defines:
[RFC3280]が以下を定義するところ
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
イド-pkix OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
イド-pe OBJECT IDENTIFIER:、:= イド-pkix1
Lynn, et al. Standards Track [Page 13] RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
リン、他 規格は2004年6月にIP AddrとIDとしてRFC3779X.509拡張子を追跡します[13ページ]。
3.2.2. Criticality
3.2.2. 臨界
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.
この拡大SHOULD、CRITICALになってください。 この拡張子の意図している使用は拡大でAS識別子の権利から使用を内包することです。 カリフォルニアは、信用パーティーが、拡大の意味論がそれが発行された目的のための証明書を利用するのを理解しなければならないという概念を伝えるためにCRITICALとして拡大をマークします。 この拡大を含む証明書を使用する新たに作成されたアプリケーションが拡大を認識すると予想されます。
3.2.3. Syntax
3.2.3. 構文
id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 8 }
イド-pe-autonomousSysIds物の識別子:、:= イド-pe8
ASIdentifiers ::= SEQUENCE {
asnum [0] EXPLICIT ASIdentifierChoice OPTIONAL,
rdi [1] EXPLICIT ASIdentifierChoice OPTIONAL}
ASIdentifiers:、:= 系列asnum[0]EXPLICIT ASIdentifierChoice OPTIONAL、rdi[1]EXPLICIT ASIdentifierChoice OPTIONAL
ASIdentifierChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
asIdsOrRanges SEQUENCE OF ASIdOrRange }
ASIdentifierChoice:、:= 選択{NULL--発行人から世襲するのを引き継いでください--asIdsOrRanges SEQUENCE OF ASIdOrRange}
ASIdOrRange ::= CHOICE {
id ASId,
range ASRange }
ASIdOrRange:、:= 選択イドASId、範囲ASRange
ASRange ::= SEQUENCE {
min ASId,
max ASId }
ASRange:、:= 系列分ASId、最大ASId
ASId ::= INTEGER
ASId:、:= 整数
3.2.3.1. Type ASIdentifiers
3.2.3.1. ASIdentifiersをタイプしてください。
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タイプは1つ以上のフォームに関する自律システム識別子を含むSEQUENCEです--AS番号(asnum要素の)か経路ドメイン識別子(rdi要素の)。 ASIdentifiersタイプが複数のフォームに関する識別子を含むとき、asnumエントリーはrdiエントリーに先行しなければなりません。 AS番号はBGPによって使用されます、そして、経路ドメイン識別子はIDRP[RFC1142]で指定されます。
3.2.3.2. Elements asnum, rdi, and Type ASIdentifierChoice
3.2.3.2. Elements asnum、rdi、およびType ASIdentifierChoice
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タイプがどちらかのCHOICEである、または、asIdsOrRanges要素。
Lynn, et al. Standards Track [Page 14] RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
リン、他 規格は2004年6月にIP AddrとIDとしてRFC3779X.509拡張子を追跡します[14ページ]。
3.2.3.3. Element inherit
3.2.3.3. 要素は世襲されます。
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選択が含んでいる、要素を引き継いでください、次に、認可されたAS識別子のセットが発行人の証明書から抜粋されるか、または発行人の発行人の証明書から、再帰的に、ASIdentifierChoiceを含む証明書までasIdsOrRanges要素を含むのは見つけられています。 認可が全く特定のフォームに関するAS識別子のために承諾されていないなら、ASIdentifiers系列には対応するasnum/rdiメンバーがいるはずがありません。
3.2.3.4. Element asIdsOrRanges
3.2.3.4. 要素asIdsOrRanges
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 SEQUENCEのどんな組の項目も重なってはいけません。 可能であるときはいつも、どんな隣接のシリーズに関するAS識別子もただ一つの範囲に結合しなければなりません。 数値を増加させることによって、asIdsOrRanges要素のAS識別子を分類しなければなりません。
3.2.3.5. Type ASIdOrRange
3.2.3.5. ASIdOrRangeをタイプしてください。
The ASIdOrRange type is a CHOICE of either a single integer (ASId) or a single sequence (ASRange).
ASIdOrRangeタイプはただ一つの整数(ASId)かただ一つの系列(ASRange)のどちらかのCHOICEです。
3.2.3.6. Element id
3.2.3.6. 要素イド
The id element has type ASId.
イド要素には、タイプASIdがあります。
3.2.3.7. Element range
3.2.3.7. 要素範囲
The range element has type ASRange.
範囲要素には、タイプASRangeがあります。
3.2.3.8. Type ASRange
3.2.3.8. 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タイプは、分と最大要素から成るSEQUENCEであり、さまざまなAS識別子値を指定するのに使用されます。
3.2.3.9. Elements min and max
3.2.3.9. 要素分と最大
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があります。 分、要素、使用されている、範囲の最小のAS識別子の値を指定してください。そうすれば、最大要素は範囲の最大のAS識別子の値を指定します。
3.2.3.10. Type ASId
3.2.3.10. ASIdをタイプしてください。
The ASId type is an INTEGER.
ASIdタイプはINTEGERです。
Lynn, et al. Standards Track [Page 15] RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
リン、他 規格は2004年6月にIP AddrとIDとしてRFC3779X.509拡張子を追跡します[15ページ]。
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識別子の始発は信用アンカー証明書から抜粋されます。
4. Security Considerations
4. セキュリティ問題
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アドレスかAS識別子について使用している右を表します。 それらは、BGP[S-BGP]の安全なバージョンを支持するために開発されましたが、他の文脈で使われるかもしれません。 安全なBGP関係では、これらの拡大を含む証明書が能力として機能します: 証明書は、秘密鍵(Subject)の所有者が拡大で表されたIPアドレスかAS識別子を使用するのに権限を与えられると断言します。 この能力モデルの結果、Subject分野はセキュリティ目的のために主に無関係です、一般的なPKIコンベンションとは逆に。
5. Acknowledgments
5. 承認
The authors would like to acknowledge the contributions to this specification by Charles Gardiner, Russ Housley, James Manger, and Jim Schaad.
作者はチャールズ・ガーディナー、ラスHousley、ジェームスManger、およびジムSchaadでこの仕様への貢献を承諾したがっています。
Lynn, et al. Standards Track [Page 16] RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
リン、他 規格は2004年6月にIP AddrとIDとしてRFC3779X.509拡張子を追跡します[16ページ]。
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. --
ip-addrとident(30)としての特定された組織(3)dod(6)のIPAddrAndASCertExtnの(5)メカニズム(5)pkix(7)モッズ(0)イドiso(1)インターネット(1)セキュリティモッズDEFINITIONS EXPLICIT TAGS:、:= 始まってください--Copyright(C)インターネット協会(2004)。 これ----このASN.1モジュールのバージョンはRFC3779の一部です。 -- -- 完全な法定の通知に関してRFC自身を見てください。 --
-- 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の特定のOIDsとアーク--イド-pe FROM PKIX1Explicit88のiso(1)の特定されて組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イド-pkix1明白な(18)。
-- IP Address Delegation Extension OID --
-- IPアドレス代表団拡大OID--
id-pe-ipAddrBlocks OBJECT IDENTIFIER ::= { id-pe 7 }
イド-pe-ipAddrBlocks物の識別子:、:= イド-pe7
-- IP Address Delegation Extension Syntax --
-- IPアドレス代表団拡大構文--
IPAddrBlocks ::= SEQUENCE OF IPAddressFamily
IPAddrBlocks:、:= IPAddressFamilyの系列
IPAddressFamily ::= SEQUENCE { -- AFI & opt SAFI --
addressFamily OCTET STRING (SIZE (2..3)),
ipAddressChoice IPAddressChoice }
IPAddressFamily:、:= 系列--、AFI、選んでください、サフィ--addressFamily OCTET STRING(SIZE(2 .3))、ipAddressChoice IPAddressChoice
IPAddressChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
addressesOrRanges SEQUENCE OF IPAddressOrRange }
IPAddressChoice:、:= 選択{NULL--発行人から世襲するのを引き継いでください--addressesOrRanges SEQUENCE OF IPAddressOrRange}
IPAddressOrRange ::= CHOICE {
addressPrefix IPAddress,
addressRange IPAddressRange }
IPAddressOrRange:、:= 選択addressPrefix IPAddress、addressRange IPAddressRange
IPAddressRange ::= SEQUENCE {
min IPAddress,
max IPAddress }
IPAddressRange:、:= 系列分IPAddress、最大IPAddress
IPAddress ::= BIT STRING
IPAddress:、:= ビット列
Lynn, et al. Standards Track [Page 17] RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
リン、他 規格は2004年6月にIP AddrとIDとしてRFC3779X.509拡張子を追跡します[17ページ]。
-- Autonomous System Identifier Delegation Extension OID --
-- 自律システム識別子代表団拡大OID--
id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 8 }
イド-pe-autonomousSysIds物の識別子:、:= イド-pe8
-- Autonomous System Identifier Delegation Extension Syntax --
-- 自律システム識別子代表団拡大構文--
ASIdentifiers ::= SEQUENCE {
asnum [0] ASIdentifierChoice OPTIONAL,
rdi [1] ASIdentifierChoice OPTIONAL }
ASIdentifiers:、:= 系列asnum[0]ASIdentifierChoice OPTIONAL、rdi[1]ASIdentifierChoice OPTIONAL
ASIdentifierChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
asIdsOrRanges SEQUENCE OF ASIdOrRange }
ASIdentifierChoice:、:= 選択{NULL--発行人から世襲するのを引き継いでください--asIdsOrRanges SEQUENCE OF ASIdOrRange}
ASIdOrRange ::= CHOICE {
id ASId,
range ASRange }
ASIdOrRange:、:= 選択イドASId、範囲ASRange
ASRange ::= SEQUENCE {
min ASId,
max ASId }
ASRange:、:= 系列分ASId、最大ASId
ASId ::= INTEGER
ASId:、:= 整数
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、10.0.47.255 2への.0) 10.0.64/24、すなわち、10.0、.64、10.0.64.255 3への.0) 10.1/16、すなわち、10.1、.0、10.1.255.255 4への.0) 10.2.48/20、すなわち、10.2、.48、10.2.63.255 5への.0) 10.2.64/24、すなわち、10.2、.64、10.2.64.255 6への.0) .255、および7は)発行人の証明書からすべてのIPv6アドレスを引き継ぎます。10.3/16、すなわち、10.3、.0、.0〜10.3、.255、あるでしょう(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 {
30 46拡大、06 08 2b06010505070107 extnID1.3.6.1.5.5.7.1.7 01 01ff批判的な04 37extnValue、30 35IPAddrBlocks、30 2b IPAddressFamily、04 03 0001 01addressFamily: IPv4 Unicast IPAddressChoice30 24addressesOrRanges
Lynn, et al. Standards Track [Page 18] RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
リン、他 規格は2004年6月にIP AddrとIDとしてRFC3779X.509拡張子を追跡します[18ページ]。
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
IPAddressOrRange03 04 04 0a0020 addressPrefix10.0.32/20IPAddressOrRange03 04 00 0a0040 addressPrefix10.0.64/24IPAddressOrRange03 03 00 0a01 addressPrefix10.1/16IPAddressOrRange30 0c addressRange03 04 04 0a0230分10.2.48.0 03 04 00 0a0240最大10.2.64.255--、addressRange IPAddressOrRange03 03 00 0a03 addressPrefix10.3/16 -- addressesOrRanges -- IPAddressFamily30 06IPAddressFamily、04 02 0002addressFamily: IPv6 IPAddressChoice05 00は発行人から世襲します。 -- IPAddressFamily -- IPAddrBlocks -- extnValue -- 拡大
This example illustrates how the prefixes and ranges are sorted.
この例は接頭語と範囲がどう分類されるかを例証します。
+ Prefix 1 MUST precede prefix 2, even though the number of unused
bits (4) in prefix 1 is larger than the number of unused bits (0)
in prefix 2.
+ 接頭語1は接頭語2に先行しなければなりません、接頭語1の未使用のビット(4)の数が接頭語2の未使用のビット(0)の数より大きいのですが。
+ Prefix 2 MUST precede prefix 3 even though the number of octets
(4) in the BIT STRING encoding of prefix 2 is larger than the
number of octets (3) in the BIT STRING encoding of prefix 3.
接頭語2のBIT STRINGコード化における、八重奏(4)の数は接頭語3のBIT STRINGコード化における、八重奏(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になるように解釈されるとき)メモ。 中の4個の引きずっているゼロ・ビット、分、要素、重要でなく、取り除かなければならない、(その結果、コード化における(4)未使用のビット、分、要素、) (DERコード化は、最後のその後の八重奏におけるどんな未使用のビットもゼロに設定しなければならないのを必要とします。)
Lynn, et al. Standards Track [Page 19] RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
リン、他 規格は2004年6月にIP AddrとIDとしてRFC3779X.509拡張子を追跡します[19ページ]。
+ 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.
範囲(30)へのSEQUENCEタグはBIT STRING(03)のためのタグが以前はよく接頭語6をコード化していたより大きいのですが、+ 接頭語4と5によって形成された範囲は接頭語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情報は、IPv4(0001)のためのアドレス家族識別子が識別子以下であるので、IPv6(0002)のために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):
発行人の証明書からすべてのIPv4マルチキャストアドレスを引き継ぐIPv6接頭語2001:0:2/48とIPv4接頭語10/8と172.16/12を指定する拡大はこと(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
30 3d拡張子; { 06 08 2b06010505070107 extnID、1.3 .6 .1 .5 .5 .7 .1; 7 01 01ff重要な04 2e extnValue; { 30 2c IPAddrBlocks; { 30 10IPAddressFamily、04 03 0001 01addressFamily: IPv4 Unicast IPAddressChoice30 09addressesOrRanges IPAddressOrRange03 02 00 0a addressPrefix10/8IPAddressOrRange03 03 04b010 addressPrefix172.16/12--、addressesOrRanges; IPAddressFamily30 07IPAddressFamily、04 03 0001 02addressFamily: IPv4 Multicast IPAddressChoice05 00は発行人から世襲します--、IPAddressFamily30 0f IPAddressFamily、04 02 0002addressFamily: IPv6 IPAddressChoice30 09addressesOrRanges IPAddressOrRange03 07 00 200100000002addressPrefix2001:0:2/47--、addressesOrRanges、--、IPAddressFamily; } IPAddrBlocks; } extnValue; } -- 拡大
Lynn, et al. Standards Track [Page 20] RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
リン、他 規格は2004年6月にIP AddrとIDとしてRFC3779X.509拡張子を追跡します[20ページ]。
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):
AS No.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
30 2b拡張子、06 08 2b06010505070108 extnID1.3.6.1.5.5.7.1.8 01 01ff批判的な04 1c extnValue、30 1a ASIdentifiers、a0 14asnum ASIdentifierChoice30 12asIdsOrRanges、ASIdOrRange02 02 0087ASId ASIdOrRange30 08ASRange02 02 0bb8分02 02 0f9f最大--、ASRange ASIdOrRange02 02 1389ASId、--、asIdsOrRanges、--ASIdentifierChoice05 00が発行人から引き継ぐasnum a1 02rdi--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.
この付録はRegionalインターネットRegistries(RIRs)からエンドユーザ組織までIPあて先ブロックかAS識別子の「権利から使用」を運ぶのに、属性証明書(中で指定されるとしてのACs[RFC3281])を使用するという提案から起こる問題について議論します。
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
2つのリソース(AS識別子とIPあて先ブロック)が、現在、異なって管理されます。 AS識別子の権利から使用によるすべての組織が直接RIRから認可を受けます。 IPあて先ブロックの権利から使用による組織が直接RIRから認可を受けるか、または間接的と、例えば、流れのサービスプロバイダーの下側へのaから受信される、それ。(aはそうするかもしれません)。
Lynn, et al. Standards Track [Page 21] RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
リン、他 規格は2004年6月にIP AddrとIDとしてRFC3779X.509拡張子を追跡します[21ページ]。
authorization from an Internet service provider, who in turn gets its authorization from a RIR. Note that AS identifiers might be sub- allocated in the future, so the mechanisms used should not rely upon a three level hierarchy.
インターネット接続サービス業者からの認可。(順番に、インターネット接続サービス業者は、RIRから認可を得ます)。 使用されるメカニズムが3の平らな階層構造を当てにされるはずがないためにAS識別子が将来サブ割り当てられるかもしれないことに注意してください。
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:
RFC3281のセクション1では、2つの理由が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."
「認可情報は、PKCの拡大に置かれるか、または別々の属性証明書(西暦)に置かれるかもしれません。」 通常、PKCsの認可情報のプレースメントは2つの理由で望ましくありません。 まず最初に、認可情報には、アイデンティティと公開鍵の結合と同じ寿命がしばしばあるというわけではありません。 認可情報がPKCの拡大に置かれるとき、一般的な結果はPKCの役に立つ生涯の短縮です。 2番目に、認可情報には、通常、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と認可情報をしばしば切り離すほうがよいです。」 しかし、また、認可情報は、アイデンティティに縛られる必要があります。 西暦はこの結合を提供します。 「それは単にデジタルにサインされて、(公認される)のアイデンティティとセットの属性です。」
In the case of the IP address and AS identifier authorizations, these reasons do not apply. First, the public key certificates are issued exclusively for authorization, so the certificate lifetime corresponds exactly to the authorization lifetime, which is often tied to a contractual relationship between the issuer and entity receiving the authorization. The Subject and Issuer names are only used for chaining during certification path validation, and the names need not correspond to any physical entity. The Subject name in the PKCs may actually be randomly assigned by the issuing CA, allowing the resource holder limited anonymity. Second, the certificate hierarchy is constructed so that the certificate issuer is authoritative for the authorization information.
IPアドレスとAS識別子承認の場合では、これらの理由は適用されません。 最初に排他的に認可のためにそのように公開鍵証明書を発行する、生涯を証明してください、ちょうど認可生涯に対応しています。(それは、しばしば認可を受ける発行人と実体との契約上の関係に結ばれます)。 SubjectとIssuer名は証明経路合法化の間、鎖を作るのに使用されるだけです、そして、名前はどんな物理的実体とも食い違わなければなりません。 PKCsのSubject名は実際に発行カリフォルニアによって手当たりしだいに割り当てられるかもしれません、リソースの所有者の限られた匿名を許容して。 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アドレスブロック配分の場合に当てはまりません。 第2引用されたパラグラフのポイントはまた、リソースが制限されている状態でないようにアイデンティティに適切であるのではなく、PKCで公開鍵に対応する秘密鍵の所有者に適切です。
Lynn, et al. Standards Track [Page 22] RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
リン、他 規格は2004年6月にIP AddrとIDとしてRFC3779X.509拡張子を追跡します[22ページ]。
RFC 3281 specifies several requirements that a conformant Attribute Certificate must meet. In relation to S-BGP, the more-significant requirements are:
RFC3281はconformant Attribute Certificateが会わなければならないといういくつかの要件を指定します。 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から: 「この仕様はどんなRECOMMENDにも交流チェーンを使用しません。」 「他の(将来)の仕様は交流チェーンの使用を記述するかもしれません。」
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.
DSPsへのISPと組織を終わらせる課題へのIANAからRIRsまでの配分はチェーンの使用を必要とするでしょう、少なくともIPあて先ブロック。 上司の西暦がどのように見つけられるべきであるか、そして、それがどのように処理されるべきであるかに関する記述を提供しなければならないでしょう。 このドキュメントの読者が推論が避けられるかもしれない方法を提案するよう奨励されます。
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はこのプロフィールとそれらが批判的であるとマークされるかもしれないかどうかと共に使用されるかもしれない拡張子を定義します。」 いかなる他の批判的な拡大も使用されているなら、西暦はこのプロフィールに従いません。 「しかしながら、いかなる他の非臨界拡大も使用されているなら、西暦はこのプロフィールに従います。」
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.
これは、この仕様に基づき定義された代表団拡大(批判的である)は西暦に絶対に置くことができなかったことを意味します。 それらを使用したか、または批判的であるとマークできましたが、意図している使用は、拡大がアイデンティティ証明書として疑わないアプリケーションでそれらを含む証明書を使用できないくらい重要であることを必要とします。
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から: 「また、交流発行人はPKC発行人であるはずがありません。」 「すなわち、交流発行人はまた、カリフォルニアであるはずがありません。」
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.
これは、そこのそれぞれの交流発行人のためのそれが、交流所有者の公開鍵を含むPKCを発行するのに別々のカリフォルニアである必要を意味します。 交流発行人は所有者のPKCを発行できません、そして、PKC発行人は西暦にサインできません。 したがって、PKIの各実体は、カリフォルニアに加えて交流発行人を経営する必要があるでしょう。 PKCsが使用されているなら、多くがAttribute証明書を支えるために処理するために必要とされるより発行人とCRLsを証明するので、二度あるでしょう。 また、ただ一つの目的のための証明書を発行する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
RFC3281の交流モデルは、所有者が属性か認可を実体化したがっているとき、交流所有者が交流検証に西暦を提示すると暗示します。 ここに定義された拡大のための意図している用法は交流検証(NOC)と交流発行人(すべてのRIRsとNOCs)の間に直接的な相互作用を持っていません。 aを与えました。
Lynn, et al. Standards Track [Page 23] RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
リン、他 規格は2004年6月にIP AddrとIDとしてRFC3779X.509拡張子を追跡します[23ページ]。
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).
権利から使用への要求された物における署名、「交流検証」は交流所有者のPKCの場所を見つけることができますが、Subjectの西暦の場所を見つけるどんなダイレクト方法もありません。
4 from section 5: "4. The AC issuer MUST be directly trusted as an
AC issuer (by configuration or otherwise)."
4 セクション5から: "4. 「交流発行人(構成かそうでないのによる)として直接交流発行人を信じなければなりません。」
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あて先ブロックの権利から使用の場合に当てはまりません。 西暦の証明経路合法化は、代表団階層構造を通して鎖でつなぐのを必要とするでしょう。 他のあらゆるNOCを「信じる」ためにそれぞれの信用パーティー(NOC)を構成しなければならないのは比例しません、そして、そのような「信用」は提案されたセキュリティー対策が防ぐように設計されている失敗をもたらしました。 信じられた根がある独身のPKIは1ISPあたり何千もの個別に信じられた交流発行人ではなく使用されます。
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.
適切に西暦を有効にするのに必要である仕事量は本書ではPKCsで定義された証明書拡張子を置くメカニズムより多くです。 同じくらい多くのACsに加えて有効にされるべき証明書が二度あるでしょう。 負担がACsを支持するのを必要とした管理のかなりの増加があるかもしれません。
References
参照
Normative References
引用規格
[IANA-AFI] http://www.iana.org/assignments/address-family-numbers.
[IANA-AFI] http://www.iana.org/assignments/address-family-numbers 。
[IANA-SAFI] http://www.iana.org/assignments/safi-namespace.
[IANA-サフィ] 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.、「Indicate Requirement LevelへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.とポークとW.とフォードとW.と一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280、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/IEC8825-1: 1998 「情報技術--ASN.1コード化は以下を統治します」。 「基本的なコード化の仕様は(BER)、正準な符号化規則(CER)、および顕著な符号化規則(DER)を統治します。」
Lynn, et al. Standards Track [Page 24] RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
リン、他 規格は2004年6月にIP AddrとIDとしてRFC3779X.509拡張子を追跡します[24ページ]。
Informational References
情報の参照
[RFC791] Postel, J., "Internet Protocol -- DARPA Internet Program
Protocol Specification", RFC 791, September 1981.
[RFC791] ポステル、J.、「インターネットは議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」RFC791、1981年9月。
[RFC1142] D. Oran, Ed., "OSI IS-IS Intra-domain Routing Protocol",
RFC 1142, February 1990.
[RFC1142] D.オラン、エド、「OSI、-、イントラドメインルーティング・プロトコル、」、RFC1142、2月1990日
[RFC1771] Rekhter, Y. and T. Li, Eds., "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[RFC1771] RekhterとY.とT.李、Eds、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC1771、3月1995日
[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.ベイツ、「Autonomous System(AS)の創造、選択、および登録のためのガイドライン」BCP6、RFC1930(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配分ガイドライン」、BCP12、RFC2050、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)アドレッシング体系」、RFC3513、2003年4月。
[RFC3281] Farrell, S. and R. Housley, "An Internet Attribute
Certificate Profile for Authorization", RFC 3281, April
2002.
[RFC3281]ファレルとS.とR.Housley、「認可のためのインターネット属性証明書プロフィール」、RFC3281、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.Seoは「ボーダ・ゲイトウェイ・プロトコル(S-BGP)を保証します」、ネットワークセキュリティにおけるIEEE JSAC増刊、2000年4月。
Lynn, et al. Standards Track [Page 25] RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
リン、他 規格は2004年6月にIP AddrとIDとしてRFC3779X.509拡張子を追跡します[25ページ]。
Authors' Address
作者のアドレス
Charles Lynn BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA
チャールズリンBBN Technologies10モールトン聖ケンブリッジ、MA02138米国
Phone: +1 (617) 873-3367 EMail: CLynn@BBN.Com
以下に電話をしてください。 +1 (617) 873-3367 メールしてください: CLynn@BBN.Com
Stephen Kent BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA
スティーブンケントBBN技術10モールトン聖ケンブリッジ、MA02138米国
Phone: +1 (617) 873-3988 EMail: Kent@BBN.Com
以下に電話をしてください。 +1 (617) 873-3988 メールしてください: Kent@BBN.Com
Karen Seo BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA
カレンSeo BBN Technologies10モールトン聖ケンブリッジ、MA02138米国
Phone: +1 (617) 873-3152 EMail: KSeo@BBN.Com
以下に電話をしてください。 +1 (617) 873-3152 メールしてください: KSeo@BBN.Com
Lynn, et al. Standards Track [Page 26] RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
リン、他 規格は2004年6月にIP AddrとIDとしてRFC3779X.509拡張子を追跡します[26ページ]。
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Lynn, et al. Standards Track [Page 27]
リン、他 標準化過程[27ページ]
一覧
スポンサーリンク
