Internet Engineering Task Force (IETF) M. Lepinski
Request for Comments: 6480 S. Kent
Category: Informational BBN Technologies
ISSN: 2070-1721 February 2012
An Infrastructure to Support Secure Internet Routing
Abstract
抽象
This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters.
この文書は、インターネットルーティングのセキュリティ向上をサポートするためのインフラストラクチャのアーキテクチャについて説明します。このアーキテクチャの基盤は、IPアドレス空間と自律システム（AS）番号の割り当ての階層を表すリソース公開鍵インフラストラクチャ（RPKI）です。そしてRPKI、ならびに改善されたルーティング・セキュリティのために必要な他の署名されたオブジェクトを含むデータオブジェクトを格納し、広めるための分散リポジトリシステム。このアーキテクチャの最初のアプリケーションとして、文書では、IPアドレス空間の正当な所有者が明示的かつ検証可能そのアドレス空間にルートを発信するために、1つの以上のASを認可する方法について説明します。そのような検証権限をより確実BGPルートフィルタを構築するために、例えば、使用することができます。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6480.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6480で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. Public Key Infrastructure for Internet Number Resources .........4
2.1. Role in the Overall Architecture ...........................5
2.2. CA Certificates ............................................6
2.3. End-Entity (EE) Certificates ...............................7
2.4. Trust Anchors ..............................................8
3. Route Origination Authorizations ................................9
3.1. Role in the Overall Architecture ...........................9
3.2. Syntax and Semantics ......................................10
4. Repositories ...................................................11
4.1. Role in the Overall Architecture ..........................12
4.2. Contents and Structure ....................................12
4.3. Access Protocols ..........................................14
4.4. Access Control ............................................15
5. Manifests ......................................................15
5.1. Syntax and Semantics ......................................15
6. Local Cache Maintenance ........................................16
7. Common Operations ..............................................17
7.1. Certificate Issuance ......................................17
7.2. CA Key Rollover ...........................................18
7.3. ROA Management ............................................19
7.3.1. Single-Homed Subscribers ...........................20
7.3.2. Multi-Homed Subscribers ............................20
7.3.3. Provider-Independent Address Space .................21
8. Security Considerations ........................................21
9. IANA Considerations ............................................21
10. Acknowledgments ...............................................22
11. References ....................................................22
11.1. Normative References .....................................22
11.2. Informative References ...................................23
This document describes an architecture for an infrastructure to support improved security for BGP routing [RFC4271] for the Internet. The architecture encompasses three principle elements:
この文書は、インターネットのBGPルーティング[RFC4271]のための改良されたセキュリティをサポートするためのインフラストラクチャのアーキテクチャを説明しています。アーキテクチャは、3つの主要な要素が含まれます：
o Resource Public Key Infrastructure (RPKI)
Oリソース公開鍵インフラストラクチャ（RPKI）
o digitally signed routing objects to support routing security
Oデジタルルーティングセキュリティをサポートするために、ルーティングオブジェクトに署名しました
o a distributed repository system to hold the PKI objects and the signed routing objects
PKIオブジェクトを保持するための分散リポジトリシステムおよび署名されたルーティングオブジェクトO
The architecture described by this document enables an entity to verifiably assert that it is the legitimate holder of a set of IP addresses or a set of Autonomous System (AS) numbers. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. In addition to this initial application, the infrastructure defined by this architecture also is intended to provide future support for security protocols such as Secure BGP [S-BGP] or Secure Origin BGP [soBGP]. This architecture is applicable to the routing of both IPv4 and IPv6 datagrams. IPv4 and IPv6 are currently the only address families supported by this architecture. Thus, for example, use of this architecture with MPLS labels is beyond the scope of this document.
この文書によって記述アーキテクチャは、検証可能、それはIPアドレスのセットまたは自律システム（AS）番号の組の正当所有者であることを主張するエンティティを可能にします。このアーキテクチャの最初のアプリケーションとして、文書では、IPアドレス空間の正当な所有者が明示的かつ検証可能そのアドレス空間にルートを発信するために、1つの以上のASを認可する方法について説明します。そのような検証権限をより確実BGPルートフィルタを構築するために、例えば、使用することができます。この最初のアプリケーションに加えて、このアーキテクチャによって定義されたインフラストラクチャはまた、セキュアなBGP [S-BGP]またはSecure起源BGP [soBGP]などのセキュリティプロトコルの将来のサポートを提供することを目的とします。このアーキテクチャは、IPv4とIPv6の両方のデータグラムのルーティングに適用可能です。 IPv4とIPv6は、現在、このアーキテクチャでサポートされている唯一のアドレスファミリーです。したがって、例えば、MPLSラベルと、このアーキテクチャの使用は、この文書の範囲外です。
In order to facilitate deployment, the architecture takes advantage of existing technologies and practices. The structure of the PKI element of the architecture corresponds to the existing resource allocation structure. Thus management of this PKI is a natural extension of the resource-management functions of the organizations that are already responsible for IP address and AS number resource allocation. Likewise, existing resource allocation and revocation practices have well-defined correspondents in this architecture. Note that while the initial focus of this architecture is routing security applications, the PKI described in this document could be used to support other applications that make use of attestations of IP address or AS number resource holdings.
展開を容易にするために、アーキテクチャは、既存の技術と実践を利用しています。アーキテクチャのPKI要素の構造は、既存のリソース割り当て構造に相当します。したがって、このPKIの管理は、すでにIPアドレスとAS番号リソースの割り当てを担当する組織の資源管理機能の自然な拡張です。同様に、既存のリソース割り当てと失効慣行は、このアーキテクチャで特派を明確に定義されています。このアーキテクチャの初期の焦点はセキュリティアプリケーションをルーティングしている間、この文書で説明するPKIは、IPアドレスの数や資源保有ASアテステーションを利用する他のアプリケーションをサポートするために使用することができることに注意してください。
To ease implementation, existing IETF standards are used wherever possible; for example, extensive use is made of the X.509 certificate profile defined by the Public Key Infrastructure using X.509 (PKIX) [RFC5280] working group and the extensions for IP addresses and AS numbers representation defined in RFC 3779 [RFC3779]. Also, Cryptographic Message Syntax (CMS) [RFC5652] is used as the syntax
実装を容易にするために、既存のIETF標準を可能な限り使用されています。例えば、広範な使用は、公開鍵インフラストラクチャ使用してX.509（PKIX）[RFC5280]ワーキンググループとIPアドレスの拡張で定義されたX.509証明書プロファイルで作られており、数字の表現としてRFC 3779 [RFC3779]で定義されています。また、暗号メッセージ構文（CMS）[RFC5652]は構文として使用されます
for the newly defined signed objects [RFC6488] required by this infrastructure.
このインフラストラクチャによって要求される新たに定義された署名されたオブジェクト[RFC6488]のために。
As noted above, the architecture is comprised of three main components: an X.509 PKI in which certificates attest to holdings of IP address space and AS numbers; non-certificate signed objects (including route origination authorizations and manifests) used by the infrastructure; and a distributed repository system that makes all of these signed objects available for use by ISPs in making routing decisions. These three basic components enable several security functions; most notably the cryptographic validation that an autonomous system is authorized to originate routes to a given prefix [RFC6483].
上述したように、アーキテクチャは、3つの主要コンポーネントで構成されています証明書はIPアドレス空間とAS番号保有を証明するX.509 PKI。非証明書は、インフラストラクチャによって使用される（経路発信権限およびマニフェストを含む）オブジェクトに署名しました。そして、ルーティング決定を行うことでISPによる使用のためにこれらの署名のオブジェクトのすべてが利用できるように分散リポジトリシステム。これらの3つの基本的な構成要素は、複数のセキュリティ機能を有効にします。最も顕著な自律システムが許可されている暗号化検証は、所定のプレフィクス[RFC6483]へのルートを発信します。
It is assumed that the reader is familiar with the terms and concepts described in "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280] and "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779].
[読者が「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール」[RFC5280]と「IPアドレスとAS識別子のためのX.509拡張機能」で説明した用語と概念に精通していると仮定されますRFC3779]。
Throughout this document, we use the terms "address space holder" or "holder of IP address space" interchangeably to refer to a legitimate holder of IP address space who has received this address space through the standard IP address allocation hierarchy. That is, the address space holder has either directly received the address space as an allocation from a Regional Internet Registry (RIR) or IANA; or else the address space holder has received the address space as a sub-allocation from a National Internet Registry (NIR) or Local Internet Registry (LIR). We use the term "resource holder" to refer to a legitimate holder of either IP address or AS number resources.
このドキュメントでは、我々は、標準のIPアドレス割り当て階層を通じてこのアドレス空間を受信したIPアドレス空間の正当な所有者を指すために互換用語「アドレス空間ホルダー」や「IPアドレス空間の所有者」を使用します。すなわち、アドレス空間ホルダが直接地域インターネットレジストリ（RIR）またはIANAから割り当てとしてアドレス空間を受けている、です。または他のアドレス空間ホルダーは、国別インターネットレジストリ（NIR）またはローカルインターネットレジストリ（LIR）からサブ割り当てなどのアドレス空間を受けています。私たちは、IPアドレスやAS番号リソースのいずれかの正当な所有者を参照するために用語「リソースホルダー」を使用します。
Throughout this document, we use the terms "registry" and "ISP" to refer to an entity that has an IP address space and/or AS number allocation that it is permitted to sub-allocate.
このドキュメントでは、我々は、および/またはそれがサブ割り当てに許可されている番号の割り当てAS IPアドレス空間を持つエンティティを参照するために用語「レジストリ」と「ISP」を使用します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "推奨NOT"、および「OPTIONAL RFC 2119 [RFC2119]に記載されているように「この文書に解釈されるべきです。
Because the holder of a block of IP address space is entitled to define the topological destination of IP datagrams whose destinations fall within that block, decisions about inter-domain routing are inherently based on knowledge of the allocation of the IP address space. Thus, a basic function of this architecture is to provide cryptographically verifiable attestations as to these allocations. In current practice, the allocation of IP addresses is hierarchical. The root of the hierarchy is IANA. Below IANA are five Regional Internet Registries (RIRs), each of which manages address and AS number allocation within a defined geopolitical region. In some regions, the third tier of the hierarchy includes National Internet Registries (NIRs) as well as Local Internet Registries (LIRs) and subscribers with so-called provider-independent ("portable") allocations. (The term "LIR" is used in some regions to refer to what other regions define as an ISP. Throughout the rest of this document, we will use the term "LIR/ISP" to simplify references to these entities.) In other regions, the third tier consists only of LIRs/ISPs and subscribers with provider-independent allocations.
IPアドレス空間のブロックのホルダーは目的地、そのブロック内に属するIPデータグラムのトポロジカル先を定義するために資格を与えているため、ドメイン間ルーティングに関する決定は、本質的にIPアドレス空間の割り当ての知識に基づいています。したがって、このアーキテクチャの基本的な機能は、これらの割り当てのような暗号検証アテステーションを提供することです。現在実際には、IPアドレスの割り当ては階層的です。階層のルートはIANAです。 IANA以下に定義地政学的領域内のアドレスとAS番号の割り当てを管理それぞれが5地域インターネットレジストリ（のRIR）、です。一部の地域では、階層の第3層は、いわゆるプロバイダに依存しない（「ポータブル」）の配分を国別インターネットレジストリ（NIRが）だけでなく、ローカルインターネットレジストリ（のLIR）と加入者を含んでいます。 （用語「LIRは、」他の地域は、ISPとして定義するものを参照するために、いくつかの地域で使用されている。この文書の残りの部分を通して、私たちはこれらのエンティティへの参照を簡単にするために用語「LIR / ISP」を使用します。）その他の地域で、第3層は、プロバイダに依存しない配分とのLIR / ISPや加入者から成ります。
In general, the holder of a block of IP address space may sub-allocate portions of that block, either to itself (e.g., to a particular unit of the same organization), or to another organization, subject to contractual constraints established by the registries. Because of this structure, IP address allocations can be described naturally by a hierarchic public key infrastructure, in which each certificate attests to an allocation of IP addresses, and issuance of subordinate certificates corresponds to sub-allocation of IP addresses. The above reasoning holds true for AS number resources as well, with the difference that, by convention, AS numbers may not be sub-allocated except by RIRs or NIRs. Thus, allocations of both IP addresses and AS numbers can be expressed by the same PKI. Such a PKI, which is henceforth referred to as the "Resource Public Key Infrastructure (RPKI)", is a central component of this architecture.
一般に、IPアドレス空間のブロックの保持は、それ自体（例えば、同じ組織の特定の単位に）、またはレジストリによって確立された契約上の制約を受ける他の組織、のいずれか、そのブロックの部分をサブ割り当てることができます。この構造のため、IPアドレスの割り当ては、各証明書は、IPアドレスの割り当てを証明し、そして下位証明書の発行がIPアドレスのサブ割り当てに対応する階層公開鍵インフラストラクチャによって自然に記述することができます。上記の推論は慣例により、数字は、サブ割り当てのRIR又はのNIRによる以外ではないかもしれないAS、差と、同様の番号資源にも当てはまります。したがって、IPアドレスとAS番号の両方の割り当ては同じPKIで表すことができます。以後「リソース公開鍵インフラストラクチャ（RPKI）」と呼ばれるそのようなPKIは、このアーキテクチャの中心的なコンポーネントです。
Certificates in this PKI are called resource certificates, and conform to the certificate profile for such certificates [RFC6487]. Resource certificates attest to the allocation by the (certificate) issuer of IP addresses or AS numbers to the subject. They do this by binding the public key contained in the resource certificate to the IP addresses or AS numbers included in the certificate's IP Address Delegation or AS Identifier Delegation extensions, respectively, as defined in RFC 3779 [RFC3779].
このPKIでの証明書は、リソース証明書と呼ばれ、そして、そのような証明書[RFC6487]のための証明書プロファイルに準拠しています。リソース証明書は、IPアドレスの（証明書）発行者または対象にAS番号を割り当てを証明します。 RFC 3779 [RFC3779]で定義されている彼らは、IPアドレスにリソース証明書または証明書のIPアドレス委任またはそれぞれ識別子委任拡張として含まAS番号含まれる公開鍵を結合することによってこれを行います。
An important property of this PKI is that certificates do not attest to the identity of the subject. Therefore, the subject names used in certificates are not intended to be "descriptive". That is, the resource PKI is intended to provide authorization, but not authentication. This is in contrast to most PKIs where the issuer ensures that the descriptive subject name in a certificate is properly associated with the entity that holds the private key corresponding to the public key in the certificate. Because issuers need not verify the right of an entity to use a subject name in a certificate, they avoid the costs and liabilities of such verification. This makes it easier for these entities to take on the additional role of Certification Authority (CA).
このPKIの重要な特性は、証明書が対象の身元を証明していないということです。そのため、証明書で使用されるサブジェクト名は、「記述」であることを意図していません。それは、PKIは、認可を提供することを意図している資源であるが、認証ません。これは、発行者が証明書で記述サブジェクト名が正しく証明書の公開鍵に対応する秘密鍵を保持するエンティティに関連付けられていることを保証し、ほとんどのPKIのとは対照的です。発行者が証明書のサブジェクト名を使用するエンティティの権利を確認する必要はありませんので、彼らは、このような検証のコストと負債を避けます。これは、簡単にこれらのエンティティは、認証局（CA）の追加的な役割を担うようになります。
Most of the certificates in the PKI assert the basic facts on which the rest of the infrastructure operates. CA certificates within the PKI attest to IP address space and AS number holdings. End-entity (EE) certificates are issued by resource holder CAs to delegate the authority attested by their allocation certificates. The primary use for EE certificates is the validation of Route Origination Authorizations (ROAs), signed objects which provide an explicit authorization by an address holder that a given AS is permitted to originate routes to a set of addresses (see Section 3). End-entity certificates are also used to verify other signed objects, such as manifests, which will be used to help ensure the integrity of the repository system (see Section 5).
PKIでの証明書のほとんどは、インフラストラクチャの残りの部分が動作する上での基本的な事実を主張します。 PKI内のCA証明書は、IPアドレス空間とAS番号の保有を証明します。エンドエンティティ（EE）証明書は、その割り当て証明書によって証明権限を委任するために、リソースホルダーのCAによって発行されています。 EE証明書の主な用途は、ルート発信権限（資産収益率）、アドレス（セクション3を参照）のセットへのルートを発信することが許可されているとして与えられたアドレス保持部による明示的な許可を与える署名付きオブジェクトの検証です。エンドエンティティ証明書はまた、リポジトリシステムの整合性を確保するために使用されるマニフェストのような他の署名されたオブジェクトを検証するために使用される（セクション5を参照）。
Any resource holder who is authorized to sub-allocate these resources must be able to issue resource certificates to correspond to these sub-allocations. Thus, for example, CA certificates will be associated with IANA and each of the RIRs, NIRs, and LIRs/ISPs. Also, a CA certificate is required to enable a resource holder to issue ROAs, because it must issue the corresponding end-entity certificate used to validate each ROA. Thus, some entities that do not sub-allocate their resources also will need to have CA certificates for their allocations, e.g., a multi-homed subscriber with a provider-independent allocation, to enable them to issue ROAs. (A subscriber who is not multi-homed, whose allocation comes from an LIR/ISP, and who has not moved to a different LIR/ISP, need not be represented in the PKI. Moreover, a multi-homed subscriber with an allocation from an LIR/ISP may or may not need to be explicitly represented, as discussed in Section 7.3.2).
サブ割り当てるこれらのリソースに許可されている任意のリソースホルダーは、これらのサブ割り当てに対応するようにリソース証明書を発行することができなければなりません。したがって、例えば、CA証明書はIANAとのRIRの各々のNIR、およびのLIR / ISPと関連します。また、CA証明書は、それが各ROAを検証するために使用される対応するエンドエンティティ証明書を発行しなければならないため、資産収益率を発行するために、リソースホルダーを有効にする必要があります。このように、また、そのリソースをサブ割り当てない一部の企業広告費用対効果を出すためにそれらを可能にするために、例えば、その配分のためのCA証明書を持っているプロバイダに依存しない割り当てとマルチホーム加入者が必要になります。その割り当てLIR / ISPから来て、そして異なるLIR / ISPへ移動していないマルチホームではない（加入者、、、しかも。PKIで表現から割り当てとマルチホーム加入する必要はありませんLIR / ISPは、またはセクション7.3.2で説明したように明示的に）表現する必要はなくてもよいです。
Unlike in most PKIs, the distinguished name of the subject in a CA certificate is chosen by the certificate issuer. The subject's distinguished name must not attempt to convey the identity of the subject in a descriptive fashion. The subject's distinguished name must include the CommonName attribute and may additionally include the serial attribute.
ほとんどのPKIとは異なり、CA証明書のサブジェクトの識別名は、証明書発行者によって選択されています。対象者の識別名は、わかりやすい形で対象のアイデンティティを伝えるためにしようとしない必要があります。対象者の識別名は、のCommonName属性を含める必要があり、さらにシリアル属性を含むことができます。
In this PKI, the certificate issuer, being an RIR, NIR, or LIR/ISP, is not in the business of verifying the legal right of the subject to assert a particular identity. Therefore, selecting a distinguished name that does not convey the identity of the subject in a descriptive fashion minimizes the opportunity for the subject to misuse the certificate to assert an identity, and thus minimizes the legal liability of the issuer. Since all CA certificates are issued to subjects with whom the issuer has an existing relationship, it is recommended that the issuer select a subject name that enables the issuer to easily link the certificate to existing database records associated with the subject. For example, an authority may use internal database keys or subscriber IDs as the subject's common name in issued certificates.
このPKIでは、証明書発行者は、RIR、NIR、またはLIR / ISPであること、特定のアイデンティティを主張する主題の法的権利を検証するビジネスではありません。そのため、わかりやすい形で対象のアイデンティティを伝えていない識別名を選択すると、被写体がアイデンティティを主張する証明書を悪用する機会を最小限に抑えるため、発行者の法的責任を最小限に抑えることができます。すべてのCA証明書は、発行者が、既存の関係を持っている人の被験者に対して発行されているので、発行者が簡単に対象に関連付けられている既存のデータベースレコードに証明書をリンクする発行者を可能にサブジェクト名を選択することをお勧めします。たとえば、権限が発行された証明書にサブジェクトの共通名として内部データベースキーまたは加入者IDを使用することができます。
Although the subject's common name in a certificate does not convey identity, it is still the case that the common name must be unique among all subjects to whom a certification authority issues certificates. That is, a CA must not issue certificates to two different entities that use the same common name for the subject.
証明書のサブジェクトの共通名は、アイデンティティを伝えていませんが、それはまだ、すべての被験者は、認証局が証明書を発行する誰に共通名は一意である必要がありそうです。つまり、CAは、被験者に対して同じ共通名を使用する2つの異なるエンティティに証明書を発行してはなりません。
Each resource certificate attests to an allocation of resources to a resource holder, so entities that have allocations from multiple sources will have multiple CA certificates. Note that when an entity receives multiple certificates from different issuers, the subject names in these certificates will generally be different. A CA also may issue distinct certificates for each distinct allocation to the same entity, if the CA and the resource holder agree that such an arrangement will facilitate management and use of the certificates. For example, an LIR/ISP may have several certificates issued to it by one registry, each describing a distinct set of address blocks, because the LIR/ISP desires to treat the allocations as separate.
複数のソースからの割り当てを持っているエンティティは、複数のCA証明書を持っていますので、各リソース証明書は、リソースホルダーへのリソースの割り当てを証明します。実体が異なる発行者から複数の証明書を受信したときに、これらの証明書でサブジェクト名は、一般的に異なるものとなることに注意してください。 CAおよびリソースホルダーは、このような配置は、証明書の管理と使用を容易にすることに同意した場合、CAはまた、同じ実体にそれぞれ異なる割り当てのために別個の証明書を発行することができます。 LIR / ISPは別として割り当てを治療することを望むので、例えば、LIR / ISPは、1つのレジストリ、アドレスブロックの別個のセットを記述するそれぞれによってそれに発行されたいくつかの証明書を有していてもよいです。
The private key corresponding to a public key contained in an EE certificate is not used to sign other certificates in a PKI. The primary function of end-entity certificates in this PKI is the verification of signed objects that relate to the usage of the resources described in the certificate, e.g., ROAs and manifests.
EE証明書に含まれる公開鍵に対応する秘密鍵は、PKI内の他の証明書に署名するために使用されていません。このPKIにおけるエンドエンティティ証明書の主な機能は、証明書、例えば、資産収益率及びマニフェストに記載のリソースの使用に関連する署名されたオブジェクトの検証です。
For ROAs and manifests, there will be a one-to-one correspondence between end-entity certificates and signed objects, i.e., the private key corresponding to each end-entity certificate is used to sign exactly one object, and each object is signed with only one key. This property allows the PKI to be used to revoke these signed objects, rather than creating a new revocation mechanism. When the end-entity certificate used to sign an object has been revoked, the signature on that object (and any corresponding assertions) will be considered invalid, so a signed object can be effectively revoked by revoking the end-entity certificate used to sign it.
資産収益率とマニフェストのために、すなわちエンドエンティティ証明書と署名済みオブジェクトの間に1対1の対応が存在することになる、各エンドエンティティ証明書に対応する秘密鍵は、1つのオブジェクトに署名するために使用され、各オブジェクトがで署名されています1つのキーだけ。このプロパティは、PKIはむしろ新しい失効メカニズムを作成するよりも、これらの署名されたオブジェクトを取り消すために使用されることを可能にします。オブジェクトに署名するために使用されるエンドエンティティ証明書が失効している場合、そのオブジェクトの署名（および任意の対応するアサーションは）ので、署名されたオブジェクトが効果的に署名するために使用されるエンドエンティティ証明書を失効することによって取り消すことができ、無効とされます。
A secondary advantage to this one-to-one correspondence is that the private key corresponding to the public key in a certificate is used exactly once in its lifetime, and thus can be destroyed after it has been used to sign its one object. This fact should simplify key management, since there is no requirement to protect these private keys for an extended period of time.
この1対1対応の二次的な利点は、証明書の公開鍵に対応する秘密鍵は、その生涯で一度だけ使用され、そしてその一つのオブジェクトに署名するために使用された後にこのように破壊することができることです。長期間これらの秘密鍵を保護する必要がないので、この事実は、鍵管理を簡素化する必要があります。
The EE certificate used to verify a signed object appears in the Cryptographic Message Syntax (CMS) wrapper (see [RFC6488]) of the signed object. Therefore, it is not necessary to transmit the EE certificate separately from the signed object. Likewise, it is not necessary for the EE certificate to appear in the RPKI repository system except as part of the corresponding signed object.
署名されたオブジェクトを検証するために使用EE証明書は、署名されたオブジェクトの（[RFC6488]を参照）暗号メッセージ構文（CMS）ラッパーに現れます。したがって、署名されたオブジェクトとは別にEE証明書を送信する必要はありません。 EE証明書が署名された対応するオブジェクトの一部として以外RPKIリポジトリシステムに表示されるため、同様に、それは必要ではありません。
Although this document describes only two uses for end-entity certificates, additional uses will likely be defined in the future. For example, end-entity certificates could be used as a more general authorization for their subjects to act on behalf of the specified resource holder. This could facilitate authentication of inter-ISP interactions, or authentication of interactions with the repository system. These additional uses for end-entity certificates may require retention of the corresponding private keys, even though such retention is not required for keys used to sign ROAs and manifests.
この文書は、エンドエンティティ証明書のための唯一の2つの用途を説明しているが、追加的な用途は、おそらく将来的に定義されます。例えば、エンドエンティティ証明書は、指定されたリソースの所有者の代理として行動するそれぞれの科目のためのより一般的な認可として使用することができます。これは、ISP間の相互作用の認証、またはリポジトリシステムとの相互作用の認証を容易にすることができます。エンドエンティティ証明書のこれらの追加の用途は、このような保持が資産収益率とマニフェストに署名するために使用されるキーを必要としない場合であっても、対応する秘密鍵の保持を必要とするかもしれません。
In any PKI, each relying party (RP) chooses its own set of trust anchors (TAs). This general property of PKIs applies here as well. There is an extant IP address space and AS number allocation hierarchy, and thus IANA and/or the five RIRs are obvious candidates to be default TAs here. Nonetheless, each RP ultimately chooses the set of trust anchors it will use for certificate validation.
いずれのPKIでは、各証明書利用者（RP）は、トラストアンカー（TAS）の独自のセットを選択します。 PKIのこの一般的なプロパティはここにも適用されます。 IANAおよび/または5つのRIRが、ここでデフォルトのTAすべき明白な候補であるため、現存するIPアドレス空間とAS番号の割り当て階層、があります。それにもかかわらず、各RPは、最終的にそれが証明書の検証に使用するトラストアンカーのセットを選択します。
For example, an RP (e.g., an LIR/ISP) could create a trust anchor to which all address space and/or all AS numbers are assigned, and for which the RP knows the corresponding private key. The RP could then issue certificates under this trust anchor to whatever entities in the PKI it wishes, with the result that the certification paths terminating at this locally installed trust anchor will satisfy the validation requirements specified in RFC 3779. A large ISP that uses private IP address space (i.e., RFC 1918) and runs BGP internally will need to create this sort of trust anchor to accommodate a CA to which all private address space is assigned. The RP could then issue certificates under this CA that correspond to the RP's internal use of private address space.
番号が割り当てられているとしては、例えば、RP（例えば、LIR / ISP）は、すべてのアドレス空間と/または全てのトラストアンカーを作成することができ、そしてそのためにRPは対応する秘密鍵を知っています。 RPは、このローカルにインストールトラストアンカーで終了証明書パスがRFC 3779.プライベートIPを使用して大規模なISPで指定された検証要件を満たす、その結果、それは希望PKIでどんなエンティティに、このトラストアンカーの下に証明書を発行することができますアドレス空間（すなわち、RFC 1918）およびBGPは、内部ですべてのプライベートアドレス空間が割り当てられているCAに対応するために、トラストアンカーのこの種を作成する必要があります実行されます。 RPは、プライベートアドレス空間のRPの内部での使用に対応して、このCAの下で証明書を発行することができます。
Note that an RP who elects to create and manage its own set of trust anchors may fail to detect allocation errors that arise under such circumstances, but the resulting vulnerability is local to the RP.
トラストアンカーの独自のセットを作成して管理することを選択RPは、このような状況下で発生する割り当てエラーを検出できない場合がありますが、結果の脆弱性は、RPにローカルです。
It is expected that some parties within the extant IP address space and AS number allocation hierarchy may wish to publish trust anchor material for possible use by relying parties. A standard profile for the publication of trust anchor material for this public key infrastructure can be found in [RFC6490].
現存するIPアドレス空間とAS番号の割り当て階層内のいくつかの当事者が依拠当事者によって可能に使用するトラストアンカーの材料を公開したいことが予想されます。この公開鍵インフラストラクチャのトラストアンカー材料の出版のための標準プロファイルは、[RFC6490]で見つけることができます。
The information on IP address allocation provided by the PKI is not, in itself, sufficient to guide routing decisions. In particular, BGP is based on the assumption that the AS that originates routes for a particular prefix is authorized to do so by the holder of that prefix (or an address block encompassing the prefix); the PKI contains no information about these authorizations. A Route Origination Authorization (ROA) makes such authorization explicit, allowing a holder of IP address space to create an object that explicitly and verifiably asserts that an AS is authorized to originate routes to a given set of prefixes.
PKIによって提供されるIPアドレスの割り当てに関する情報は、それ自体で、ルーティングの決定を導くのに十分ではありません。具体的には、BGPは、特定のプレフィックスのためのルートを発信ASは、その接頭辞のホルダー（またはプレフィックスを包含するアドレスブロック）によってそうすることを許可されていることを前提としています。 PKIは、これらの権限に関する情報が含まれていません。ルート発信許可（ROA）は、IPアドレス空間の所有者が明示的かつ検証可能ASがプレフィックスの所与のセットへのルートを発信することを許可されていることを主張するオブジェクトを作成することができ、そのような許可を明示させます。
A ROA is an attestation that the holder of a set of prefixes has authorized an autonomous system to originate routes for those prefixes. A ROA is structured according to the format described in [RFC6482]. The validity of this authorization depends on the signer of the ROA being the holder of the prefix(es) in the ROA; this fact is asserted by an end-entity certificate from the PKI, whose corresponding private key is used to sign the ROA.
ROAは、プレフィックスの組のホルダが、これらのプレフィックスのルートを発信する自律システムを承認した認証です。 ROAは、[RFC6482]に記述されたフォーマットに従って構成されています。この承認の有効性は、ROAはROAで接頭語（ES）の保持者であることの署名者に依存します。この事実は、対応する秘密鍵ROAに署名するために使用されるPKI、からエンドエンティティ証明書によってアサートされます。
ROAs may be used by relying parties to verify that the AS that originates a route for a given IP address prefix is authorized by the holder of that prefix to originate such a route. For example, an ISP might use validated ROAs as inputs to route filter construction for use by its BGP routers. (See [RFC6483] for information on the use of ROAs to validate the origination of BGP routes.)
資産収益率は、所与のIPアドレスプレフィックスのルートを発信ASは、このような経路を発信するために、そのプレフィックスの所有者によって承認されていることを確認するために、依拠当事者によって使用されてもよいです。例えば、ISPは、BGPルータによって使用するためのルートフィルタ構造への入力として資産収益率を検証し使用するかもしれません。 （BGPルートの発信元を検証するための資産収益率の使用については、[RFC6483]を参照）。
Initially, the repository system will be the primary mechanism for disseminating ROAs, since these repositories will hold the certificates and CRLs needed to verify ROAs. In addition, ROAs also could be distributed in BGP UPDATE messages or via other communication paths, if needed to meet timeliness requirements.
これらのリポジトリは、資産収益率を検証するために必要な証明書とCRLを開催しますので、最初は、リポジトリシステムは、資産収益率を広めるための主要なメカニズムとなります。適時性要件を満たすために必要に応じて加えて、資産収益率は、また、BGPアップデートメッセージまたは他の通信経路を介して配信することができます。
A ROA constitutes an explicit authorization for a single AS to originate routes to one or more prefixes, and is signed by the holder of those prefixes. Conceptually, the ROA syntax consists of two parts, a general CMS template common to all RPKI signed objects
ROAは、一つ以上のプレフィックスへのルートを発信するように単一の明示的な承認を構成し、これらのプレフィックスの所有者によって署名されています。概念的には、ROAの構文は二つの部分、すべてのRPKI署名オブジェクトに共通の一般的なCMSのテンプレートで構成されてい
[RFC6488] and an encapsulated content specific to the ROA that expresses the authorization [RFC6482].
[RFC6488]及び許可[RFC6482]を表しROAに特異的にカプセル化コンテンツ。
At a high level, the ROA's content contains (1) an AS number; (2) a list of IP address prefixes; and, optionally, (3) for each prefix, the maximum length of more specific (longer) prefixes that the AS is also authorized to advertise. (This last element facilitates a compact authorization to advertise, for example, any prefixes of length 20 to 24 bits contained within a given length 20 prefix.)
ハイレベルで、ROAの内容は（1）AS番号を含みます。 （2）IPアドレスプレフィックスのリスト。そして、必要に応じて、（3）各プレフィックスの、より具体的な（長い）の最大長さは、ASはまた、宣伝を許可されているプレフィックス。 （この最後の要素は、指定された長さ20の接頭辞内に含まれる24ビットに、例えば、長さ20のいずれかのプレフィックスを広告するコンパクトな認可を容易にします。）
Note that a ROA contains only a single AS number. Thus, if an ISP has multiple AS numbers that will be authorized to originate routes to the prefix(es) in the ROA, an address space holder will need to issue multiple ROAs to authorize the ISP to originate routes from any of these ASes.
ROAは、単一のAS番号が含まれていることに注意してください。 ISPはROAで接頭語（ES）へのルートを発信することが許可されるAS番号の複数を持っている場合はこのように、アドレス空間保持者は、これらのASのいずれかからのルートを発信するISPを許可するために、複数の資産収益率を発行する必要があります。
A ROA is signed using the private key corresponding to the public key in an end-entity (EE) certificate in the PKI. In order for a ROA to be valid, its corresponding end-entity certificate must be valid, and the IP address prefixes of the ROA must exactly match the IP address prefix(es) specified in the EE certificate's RFC 3779 extension. Therefore, the validity interval of the ROA is implicitly the validity interval of its corresponding certificate. A ROA is revoked by revoking the corresponding EE certificate. There is no independent method of revoking a ROA. One might worry that this revocation model could lead to long CRLs for the CA certification that is signing the EE certificates. However, routing announcements on the public Internet are generally quite long lived. Therefore, as long as the EE certificates used to verify a ROA are given a validity interval of several months, the likelihood that many ROAs would need to be revoked within that time is quite low.
ROAは、PKIにおけるエンドエンティティ（EE）証明書の公開鍵に対応する秘密鍵を用いて署名されます。有効とするROAためには、それに対応するエンドエンティティ証明書が有効である必要があり、およびROAのIPアドレスプレフィックスは正確にEE証明書のRFC 3779の拡張子で指定したIPアドレス接頭語（es）に一致している必要があります。したがって、ROAの有効間隔は、暗黙的に、その対応する証明書の有効期間です。 ROAは、対応するEE証明書を失効させることによって取り消されます。 ROAを取り消すのない独立した方法ではありません。一つは、この失効モデルはEE証明書に署名されたCA証明書のための長期のCRLにつながることを心配かもしれません。しかし、公共のインターネット上のルーティングの発表は、一般的に、非常に長命されています。したがって、限り、ROAを検証するために使用されるEE証明書が、数ヶ月の有効期間を与えているとして、多くの資産収益率は、その時間内に取り消すことが必要となる可能性はかなり低いです。
--------- ---------
| RIR | | NIR |
| CA | | CA |
--------- ---------
| |
| |
| |
--------- ---------
| ISP | | ISP |
| CA 1 | | CA 2 |
--------- ---------
| \ |
| ----- |
| \ |
---------- ---------- ----------
| ISP | | ISP | | ISP |
| EE 1a | | EE 1b | | EE 2 |
---------- ---------- ----------
| | |
| | |
| | |
---------- ---------- ----------
| ROA 1a | | ROA 1b | | ROA 2 |
---------- ---------- ----------
Figure 1: This figure illustrates an ISP with allocations from two sources (an RIR and an NIR). It needs two CA certificates due to the rules defined in RFC 3779.
図1：この図は、2つのソース（RIRおよびNIR）から割り当てとISPを示します。これは、RFC 3779で定義されたルールによる2 CA証明書を必要とします。
Because each ROA is associated with a single end-entity certificate, the set of IP prefixes contained in a ROA must be drawn from an allocation by a single source, i.e., a ROA cannot combine allocations from multiple sources. Address space holders who have allocations from multiple sources, and who wish to authorize an AS to originate routes for these allocations, must issue multiple ROAs to the AS.
各ROAは、単一のエンドエンティティ証明書に関連付けられている、ROAに含まれるIPプレフィクスのセットは単一のソースにより割当てから引き出さなければならないため、すなわち、ROAは、複数のソースから割り当てを組み合わせることはできません。複数のソースからの割り当てを持っており、これらの割り当てのためのルートを発信するASを承認したい人のアドレス空間保持者は、ASに複数の資産収益率を発行する必要があります。
Initially, an LIR/ISP will make use of the resource PKI by acquiring and validating every ROA, to create a table of the prefixes for which each AS is authorized to originate routes. To validate all ROAs, an LIR/ISP needs to acquire all the certificates and CRLs. The primary function of the distributed repository system described here is to store these signed objects and to make them available for download by LIRs/ISPs. Note that this repository system provides a mechanism by which relying parties can pull fresh data at whatever frequency they deem appropriate. However, it does not provide a mechanism for pushing fresh data to relying parties (e.g., by including resource
最初は、LIR / ISPは、各ASがルートを発信することが許可されているプレフィックスのテーブルを作成するために、すべてのROAを取得し、検証することにより、リソースのPKIを利用します。すべての資産収益率を検証するには、LIR / ISPは、すべての証明書とCRLを取得する必要があります。ここで説明する分散リポジトリのシステムの主な機能は、これらの署名オブジェクトを格納するとのLIR / ISPによるダウンロードのためにそれらを利用できるようにすることです。このリポジトリシステムが依拠当事者は、彼らが適切と思わどんな頻度で新鮮なデータを取得することができる機構を提供することに注意してください。しかし、リソースを含めることによって、依拠当事者（例えば、新鮮なデータをプッシュするためのメカニズムを提供しません
PKI objects in BGP or other protocol messages) and such a mechanism is beyond the scope of the current document.
PKIは、BGPまたは他のプロトコルメッセージ内のオブジェクト）とそのような機構は、現在の文書の範囲外です。
The digital signatures on all objects in the repository ensure that unauthorized modification of valid objects is detectable by relying parties. Additionally, the repository system uses manifests (see Section 5) to ensure that relying parties can detect the deletion of valid objects and the insertion of out-of-date, valid signed objects.
リポジトリ内のすべてのオブジェクトのデジタル署名が有効なオブジェクトの不正な変更は、依拠当事者によって検出可能であることを確認してください。また、リポジトリ・システムは、依拠当事者が有効なオブジェクトの削除や期限切れの、有効な署名されたオブジェクトの挿入を検出できることを保証するために（セクション5を参照）マニフェストを使用します。
The repository system is also a point of enforcement for access controls for the signed objects stored in it, e.g., ensuring that records related to an allocation of resources can be manipulated only by authorized parties. The use of access controls prevents denial-of-service attacks based on deletion of or tampering with repository objects. Indeed, although relying parties can detect tampering with objects in the repository, it is preferable that the repository system prevent such unauthorized modifications to the greatest extent possible.
リポジトリ・システムは、リソースの割り当てに関連するレコードのみ認可の当事者によって操作することができることを保証する、例えば、また、その中に格納された署名されたオブジェクトに対するアクセスコントロールの実施の点です。アクセス制御の使用はの削除またはリポジトリオブジェクトの改ざんに基づいてサービス拒否攻撃を防ぎます。依拠当事者は、リポジトリ内のオブジェクトの改ざんを検出することができるが、実際に、リポジトリシステムは、可能な限り、そのような不正な変更を防止することが好ましいです。
The repository system is the untrusted clearing-house for all signed objects that must be globally accessible to relying parties. When certificates and CRLs are created, they are uploaded to this repository, and then downloaded for use by relying parties (primarily LIRs/ISPs). ROAs and manifests are additional examples of such objects, but other types of signed objects may be added to this architecture in the future. This document briefly describes the way signed objects (certificates, CRLs, ROAs, and manifests) are managed in the repository system. As other types of signed objects are added to the repository system, it will be necessary to modify the description, but it is anticipated that most of the design principles will still apply. The repository system is described in detail in [RFC6481].
リポジトリシステムは、依拠当事者へのグローバルアクセス可能である必要があり、すべての署名のオブジェクトのための信頼性のないクリアリングハウスです。証明書とCRLが作成されると、彼らはこのリポジトリにアップロードされ、その後、関係者（主のLIR / ISPの）を頼っで使用するためにダウンロードされます。資産収益率とマニフェストは、このようなオブジェクトの付加的な例であるが、署名されたオブジェクトの他のタイプは、将来的にこのアーキテクチャに追加することができます。この文書では、簡単に署名したオブジェクト（証明書、CRLに、資産収益率、およびマニフェストは）リポジトリシステムで管理する方法を説明します。署名されたオブジェクトの他のタイプは、リポジトリ・システムに追加されると、説明を変更することが必要となるが、設計原理の多くは、まだ適用されることが予想されます。リポジトリシステムは、[RFC6481]に詳細に記載されています。
Although there is a single repository system that is accessed by relying parties, it is comprised of multiple databases. These databases will be distributed among registries (RIRs, NIRs, LIRs/ISPs). At a minimum, the database operated by each registry will contain all CA and EE certificates, CRLs, and manifests signed by the CA(s) associated with that registry. Repositories operated by LIRs/ISPs also will contain ROAs. Registries are encouraged to maintain copies of repository data from their customers, and their customer's customers (etc.), to facilitate retrieval of the whole repository contents by relying parties. Ideally, each RIR will hold PKI data from all entities within its geopolitical scope.
依拠当事者によってアクセスされる単一のリポジトリシステムがあるが、それは、複数のデータベースから構成されています。これらのデータベースはレジストリ（RIRが、NIRが、のLIR / ISPの）の間で分配されます。最低でも、各レジストリによって操作データベースは、そのレジストリに関連付けられているCA（S）によって署名されたすべてのCAおよびEE証明書、CRLの、およびマニフェストを含むことになります。 LIR / ISPが運営リポジトリはまた、資産収益率が含まれています。レジストリは、顧客からのリポジトリデータのコピーを維持することが奨励され、そしてその顧客の顧客は、（など）、依拠当事者によってリポジトリ全体のコンテンツの検索を容易にします。理想的には、各RIRは、その地政学的な範囲内のすべてのエンティティからのPKIデータを保持します。
For every certificate in the PKI, there will be a corresponding file system directory in the repository that is the authoritative publication point for all objects (certificates, CRLs, ROAs, and manifests) verifiable via this certificate. A certificate's Subject Information Access (SIA) extension [RFC5280] contains a URI that references this directory. Additionally, a certificate's Authority Information Access (AIA) extension [RFC5280] contains a URI that references the authoritative location for the CA certificate under which the given certificate was issued. That is, if certificate A is used to verify certificate B, then the AIA extension of certificate B points to certificate A, and the SIA extension of certificate A points to a directory containing certificate B (see Figure 2).
PKI内のすべての証明書のために、この証明書を介して検証するすべてのオブジェクト（証明書、CRLに、資産収益率、及びマニフェスト）に対する権限出版点であるリポジトリ内の対応するファイル・システム・ディレクトリが存在することになります。証明書のサブジェクト情報アクセス（SIA）拡張[RFC5280]は、このディレクトリを参照するURIが含まれています。また、証明書の機関情報アクセス（AIA）拡張[RFC5280]は指定された証明書が発行されたの下にCA証明書の権威ある場所を参照するURIが含まれています。証明書Aは、証明書Bは、証明書Aに証明書B点のAIA拡張、および証明書Bを含むディレクトリに証明書A点のSIA拡張を検証するために使用された場合には、である（図2参照）。
+--------+
+--------->| Cert A |<----+
| | CRLDP | |
| | AIA | |
| +--------- SIA | |
| | +--------+ |
| | |
| | |
| | |
| | +-------------------|------------------+
| | | | |
| +->| +--------+ | +--------+ |
| | | Cert B | | | Cert C | |
| | | CRLDP ----+ | | CRLDP -+-+ |
+----------- AIA | | +----- AIA | | |
| | SIA | | | SIA | | |
| +--------+ | +--------+ | |
| V | |
| +---------+ | |
| | A's CRL |<-----------+ |
| +---------+ |
| A's Repository Publication Directory |
+--------------------------------------+
Figure 2: Use of SIA and AIA extensions in the RPKI
図2：RPKIでSIAとAIAの拡張機能の使用
In Figure 2, certificates B and C are issued by CA A. Therefore, the AIA extensions of certificates B and C point to (certificate) A, and the SIA extension of certificate A points to the repository publication point of CA A's subordinate products, which includes certificates B and C, as well as the CRL issued by A. The CRL Distribution Points (CRLDP) extension in certificates B and C both point to the CRL issued by A.
図2では、証明書B及びCは、CA Aの下位製品のリポジトリ出版ポイントに（証明書）A、および証明書A点のSIA拡張にCA Aにより証明書BとC点のため、AIA拡張を発行しますこれA.によって発行されたCRLに証明書BおよびC、ならびにA.ザCRL配布ポイント（CRLDP）によって発行されたCRLの証明書B及びCにおける拡張の両方の点を含みます
If a CA certificate is reissued with the same public key, it should not be necessary to reissue (with an updated AIA URI) all certificates signed by the certificate being reissued. Therefore, a certification authority SHOULD use a persistent URI naming scheme for issued certificates. That is, reissued certificates should use the same publication point as previously issued certificates having the same subject and public key, and should overwrite such certificates.
CA証明書が同じ公開鍵で再発行された場合、（更新AIA URIで）再発行された証明書によって署名されたすべての証明書を再発行する必要はありません。そのため、認証局が発行した証明書のための永続的なURIの命名規則を使用すべきです。これは、再発行の証明書は同じ主題と公開鍵を持つ以前に発行された証明書と同じパブリケーション・ポイントを使用する必要がありますされており、このような証明書を上書きする必要があります。
Repository operators will choose one or more access protocols that relying parties can use to access the repository system. These protocols will be used by numerous participants in the infrastructure (e.g., all registries, ISPs, and multi-homed subscribers) to maintain their respective portions of it. In order to support these activities, certain basic functionality is required of the suite of access protocols, as described below. No single access protocol needs to implement all of these functions (although that may be the case), but each function MUST be implemented by at least one access protocol deployed by a repository operator.
リポジトリ事業者は、依存者は、リポジトリシステムにアクセスするために使用することができ、1つまたは複数のアクセス・プロトコルを選択します。これらのプロトコルは、それのそれぞれの部分を維持するために、インフラストラクチャ（例えば、すべてのレジストリ、ISPは、マルチホーム加入者）に多数の参加者によって使用されます。以下に述べるように、これらの活動を支援するために、特定の基本的な機能は、アクセス・プロトコルのスイートに要求されます。単一のアクセスプロトコル（つまりケースかもしれないが）、これらの機能のすべてを実装する必要はないが、各機能は、リポジトリオペレータによって配置された少なくとも1つのアクセスプロトコルによって実装されなければなりません。
Download: Access protocols must support the bulk download of repository contents and subsequent download of changes to the downloaded contents, since this will be the most common way in which relying parties interact with the repository system. Other types of download interactions (e.g., download of a single object) may also be supported.
ダウンロード：これは、依存者は、リポジトリシステムと対話する最も一般的な方法となりますので、アクセスプロトコルは、リポジトリの内容とダウンロードしたコンテンツへの変更のその後のダウンロードの一括ダウンロードをサポートしている必要があります。ダウンロード相互作用（例えば、単一のオブジェクトのダウンロード）の他のタイプもサポートすることができます。
Upload/change/delete: Access protocols must also support mechanisms for the issuers of certificates, CRLs, and other signed objects to add them to the repository, and to remove them. Mechanisms for modifying objects in the repository may also be provided. All access protocols that allow modification to the repository (through addition, deletion, or modification of its contents) must support verification of the authorization of the entity performing the modification, so that appropriate access controls can be applied (see Section 4.4).
アップロード/変更/削除：アクセスプロトコルはまた、リポジトリに追加する証明書、CRLの、および他の署名のオブジェクトの発行者のためのメカニズムをサポートしなければならない、とそれらを削除します。リポジトリ内のオブジェクトを変更するための機構を設けてもよいです。 （その内容の追加、削除、または変更を介して）リポジトリに変更を許可するすべてのアクセスプロトコルは、適切なアクセス制御を適用することができるように（セクション4.4を参照）、変更を実行するエンティティの許可の検証をサポートしている必要があります。
To ensure all relying parties are able to acquire all RPKI signed objects, all publication points MUST be accessible via rsync (see [RFC5781] and [RSYNC]), although other download protocols MAY also be supported. A repository publication point may provide update/change/delete functionality via (set of) access protocols that it desires, provided that the supported protocols are clearly communicated to all certification authorities publishing data at a given publication point.
全て依拠当事者がすべてRPKI署名されたオブジェクトを取得することが可能であることを確認するために、すべてのパブリケーション・ポイントは、他のダウンロードプロトコルもサポートすることができるが、（[RFC5781]及び[RSYNC]を参照）のrsyncを介してアクセス可能でなければなりません。リポジトリ出版点は、それが望むアクセスプロトコル（のセット）を介して機能を削除/更新/変更を提供することができる、サポートされているプロトコルが明確に指定されたパブリケーション・ポイントでデータを公開するすべての認証機関に伝達されることを条件とします。
In order to maintain the integrity of information in the repository, controls must be put in place to prevent the addition, deletion, or modification of objects in the repository by unauthorized parties. The identities of parties attempting to make such changes can be authenticated through the relevant access protocols. Although specific access control policies are subject to the local control of repository operators, it is RECOMMENDED that repositories allow only the issuers of signed objects to add, delete, or modify them. Alternatively, it may be advantageous in the future to define a formal delegation mechanism to allow resource holders to authorize other parties to act on their behalf, as suggested in Section 2.3.
リポジトリ内の情報の整合性を維持するためには、コントロールは、権限のない者による追加、削除、またはリポジトリ内のオブジェクトの変更を防ぐために、場所に置かなければなりません。そのような変更を行おうと当事者のアイデンティティは、関連するアクセスプロトコルを使用して認証することができます。特定のアクセス制御ポリシーは、リポジトリの演算子の局所制御の対象となっているが、リポジトリが署名したオブジェクトの唯一の発行者は、追加、削除、またはそれらを変更できるようにすることが推奨されます。また、それは資源保有者は2.3節で提案されているように、彼らに代わって行動するために他の当事者を認可することを可能にするために正式な委任メカニズムを定義するために、将来的に有利であり得ます。
A manifest is a signed object listing of all of the signed objects (except for the manifest itself) issued by an authority responsible for a publication in the repository system. For each unexpired certificate, CRL, or ROA issued by the authority, the manifest contains both the name of the file containing the object, and a hash of the file content.
マニフェストは、リポジトリシステムにおける出版の責任当局によって発行された（マニフェスト自体を除く）署名されたオブジェクトのすべての署名されたオブジェクトのリストです。各期限が切れていない証明書の場合、当局によって発行されたCRL、またはROAは、マニフェストには、オブジェクトを含むファイルの名前、およびファイルコンテンツのハッシュの両方が含まれています。
As with ROAs, a manifest is signed by a private key, for which the corresponding public key appears in an end-entity certificate. This EE certificate, in turn, is signed by the CA in question. Since the private key in an EE certificate is used to sign only a single manifest, then the manifest can be revoked by revoking the EE certificate. In such a case, to avoid needless CRL growth, the EE certificate used to validate a manifest SHOULD expire at the same time that the manifest expires.
資産収益率と同様に、マニフェストは、対応する公開鍵は、エンドエンティティ証明書に表示されている秘密鍵によって署名されています。このEE証明書は、今度は、問題のCAによって署名されています。 EE証明書内の秘密鍵が単一のマニフェストに署名するために使用されるので、その後、マニフェストは、EE証明書を失効することによって取り消すことができます。このような場合には、無駄なCRL成長、マニフェストの有効期限が切れると同時に満了したマニフェストを検証するために使用EE証明書を回避します。
Manifests may be used by relying parties when constructing a local cache (see Section 6) to mitigate the risk of an attacker who deletes files from a repository or replaces current signed objects with stale versions of the same object. Such protection is needed because, although all objects in the repository system are signed, the repository system itself is untrusted.
マニフェストは、リポジトリからファイルを削除したり、同じオブジェクトの古いバージョンでは、現在の署名オブジェクトを置き換え攻撃のリスクを軽減するために（セクション6を参照）、ローカルキャッシュを構築する際に依拠当事者が使用することができます。リポジトリシステム内のすべてのオブジェクトが署名されているが、リポジトリ・システム自体が信頼できない、ため、このような保護が必要です。
A manifest constitutes a list of (the hashes of) all the files in a repository point at a particular point in time. A detailed specification of the manifest's content is provided in [RFC6486] but, at a high level, a manifest consists of (1) a manifest number; (2) the time the manifest was issued; (3) the time of the next planned update; and (4) a list of filename and hash value pairs.
マニフェストは、特定の時点でのリポジトリ・ポイントのすべてのファイル（のハッシュ）のリストを構成しています。マニフェストの内容の詳細な仕様は、[RFC6486]に提供されるが、高いレベルで、マニフェストは、（1）マニフェスト数から成ります。 （2）マニフェストが発行された時刻と、 （3）次の予定の更新の時間。 （4）ファイル名とハッシュ値のペアのリスト。
The manifest number is a sequence number that is incremented each time a manifest is issued by the authority. An authority is REQUIRED to issue a new manifest any time it alters any of its items in the repository, or when the specified time of the next update is reached. A manifest is thus valid until the specified time of the next update or until a manifest is issued with a greater manifest number, whichever comes first. (Note that when an EE certificate is used to sign only a single manifest, whenever the authority issues the new manifest, the CA MUST also issue a new CRL that includes the EE certificate corresponding to the old manifest. The revoked EE certificate for the old manifest will be removed from the CRL when it expires; thus, this procedure ought not to result in significant CRL growth.)
マニフェスト数は、マニフェストが機関によって発行されるたびにインクリメントされたシーケンス番号です。当局は、それがリポジトリ内の項目のいずれかを変える新しいマニフェストの任意の時間を発行する必要があり、または次の更新の指定した時間に達したとき。マニフェストは、次の更新の指定時間までまたはマニフェストが最初に来る方も大きくマニフェスト番号、で発行されるまでこのように有効です。 （EE証明書が権限が新しいマニフェストを発行したときにのみ、単一のマニフェストに署名するために使用されている場合、CAは、古いマニフェストに対応するEE証明書を含む新しいCRLを発行しなければならないことに注意してください。古いため取り消されたEE証明書をそれが期限切れになったときにマニフェストは、CRLから削除されます。したがって、この手順は重要CRLの成長をもたらすことはないはずです）。
In order to utilize signed objects issued under this PKI, a relying party must first obtain a local copy of the valid EE certificates for the PKI. To do so, the relying party performs the following steps:
このPKIに基づいて発行された署名オブジェクトを利用するためには、証明書利用者は、最初のPKIの有効なEE証明書のローカルコピーを取得する必要があります。そのためには、証明書利用者は、次の手順を実行します。
1. Query the repository system to obtain a copy of all certificates, manifests, and CRLs issued under the PKI.
1.クエリPKIに基づいて発行されたすべての証明書、マニフェスト、およびCRLのコピーを入手するためのリポジトリシステム。
2. For each CA certificate in the PKI, verify the signature on the corresponding manifest. Additionally, verify that the current time is earlier than the time indicated in the nextUpdate field of the manifest.
PKI内の各CA証明書2.、対応するマニフェストの署名を検証します。また、現在時刻がマニフェストのnextUpdateのフィールドに示される時間より前であることを確認します。
3. For each manifest, verify that certificates and CRLs issued under the corresponding CA certificate match the hash values contained in the manifest. Additionally, verify that no certificate or manifest listed on the manifest is missing from the repository. If the hash values do not match, or if any certificate or CRL is missing, notify the appropriate repository administrator that the repository data has been corrupted.
各マニフェスト3.は、対応するCA証明書に基づいて発行された証明書とCRLは、マニフェストに含まれるハッシュ値と一致することを検証します。また、マニフェストにリストされない証明書やマニフェストは、リポジトリから欠落していないことを確認します。ハッシュ値が一致しない場合、またはいずれかの証明書またはCRLが見つからない場合は、リポジトリのデータが破損していることを適切なリポジトリ管理者に通知。
4. Validate each EE certificate by constructing and verifying a certification path for the certificate (including checking relevant CRLs) to the locally configured set of TAs. (See [RFC6487] for more details.)
4. TAの局所的に配置されたセットを構築し、（関連したCRLの検査を含む）証明書の認証パスを検証することによって、各EE証明書を検証。 （詳細は[RFC6487]を参照してください。）
Note that since relying parties will perform these operations regularly, it is more efficient for the relying party to request from the repository system only those objects that have changed since the relying party last updated its local cache.
依拠当事者が定期的にこれらの操作を実行しますので、依存者は、リポジトリシステムから証明書利用者が最後のローカルキャッシュを更新以降に変更されたオブジェクトのみを要求するために、それがより効率的であることに注意してください。
Note also that by checking all issued objects against the appropriate manifest, the relying party can be certain that it is not missing an updated version of any object.
適切なマニフェストに対して発行されたすべてのオブジェクトをチェックしてもなお、依拠当事者は、それが任意のオブジェクトの更新バージョンが欠落していないことを確信することができます。
Creating and maintaining the infrastructure described above will entail additional operations as "side effects" of normal resource allocation and routing authorization procedures. For example, a subscriber with provider-independent ("portable") address space who enters a relationship with an ISP will need to issue one or more ROAs identifying that ISP, in addition to conducting any other necessary technical or business procedures. The current primary use of this infrastructure is for route filter construction; using ROAs, route filters can be constructed in an automated fashion with high assurance that the holder of the advertised prefix has authorized the origin AS to originate an advertised route.
上述したインフラストラクチャを作成し、維持することは、通常のリソース割り当ておよびルーティング許可手順の「副作用」として追加の操作を必要とするであろう。例えば、ISPとの関係に入るプロバイダに依存しないと加入者（「ポータブル」）のアドレス空間は、他の必要な技術やビジネス手続きを行うことに加えて、そのISPを特定する1つの以上の資産収益率を発行する必要があります。このインフラストラクチャの現在の主な用途は、ルートフィルタ構造のためのものです。資産収益率を使用して、ルートフィルタは、アドバタイズされたルートを発信すると宣伝プレフィックスの所有者が起源を承認したことを高く保証と自動化された方法で構築することができます。
There are several operational scenarios that require certificates to be issued. Any allocation that may be sub-allocated requires a CA certificate, e.g., so that certificates can be issued as necessary for the sub-allocations. Holders of provider-independent IP address space allocations also must have certificates, so that a ROA can be issued to each ISP that is authorized to originate a route to the allocation (since the allocation does not come from any ISP). Additionally, multi-homed subscribers may require certificates for their allocations if they intend to issue the ROAs for their allocations (see Section 7.3.2). Other resource holders need not be issued CA certificates within the PKI.
発行する証明書を必要とするいくつかの動作シナリオがあります。証明書は、サブ割り当てのために、必要に応じて発行することができるように、サブ割り当てられてもよい任意の割り当ては、例えば、CA証明書を必要とします。 ROAは（割り当てが任意のISPから来ていないので）配分へのルートを発信することが許可されている各ISPに対して発行することができるようにプロバイダに依存しないIPアドレス空間の割り当ての保有者はまた、証明書を持っている必要があります。彼らは彼らの配分のための資産収益率を発行する場合はさらに、マルチホームの加入者は、彼らの配分のための証明書が必要な場合があります（7.3.2項を参照してください）。その他のリソース保有者は、PKI内のCA証明書を発行する必要はありません。
In the long run, a resource holder will not request resource certificates, but rather receive a certificate as a side effect of the allocation process for the resource. However, initial deployment of the RPKI will entail issuance of certificates to existing resource holders as an explicit event. Note that in all cases, the authority issuing a CA certificate will be the entity who allocates resources to the subject. This differs from most PKIs in which a subject can request a certificate from any certification authority.
長期的には、リソースホルダーは、リソース証明書を要求するのではなく、リソースの割り当てプロセスの副作用として、証明書を受け取ることができません。しかし、RPKIの最初の展開は、明示的なイベントとして既存のリソースの所有者に証明書の発行を伴います。すべてのケースでは、CA証明書を発行する機関が対象にリソースを割り当て、エンティティになることに注意してください。これは、被験者がどの認証局から証明書を要求することが可能な最もPKIのとは異なります。
If a resource holder receives multiple allocations over time, it may accrue a collection of resource certificates to attest to them. If a resource holder receives multiple allocations from the same source, the set of resource certificates may be combined into a single resource certificate, if both the issuer and the resource holder agree. This is accomplished by consolidating the IP Address Delegation and AS Identifier Delegation extensions into a single extension (of each type) in a new certificate. However, if these certificates attest to allocations that are valid for different periods of time, creating a certificate that combines them might create problems, as the combined certificate can express only a single validity interval.
リソースの所有者が時間をかけて複数の割り当てを受信した場合、それはそれらを証明するためにリソース証明書のコレクションを計上します。リソース所有者が同じソースから複数の割り当てを受信した場合、発行者と、リソースホルダーの両方が一致した場合、リソースの証明書のセットは、単一のリソース証明書に組み合わせることができます。これは、新しい証明書（各タイプの）単一の拡張にIPアドレス委任とAS識別子委任拡張を統合することによって達成されます。しかし、これらの証明書を組み合わせた証明書は、単一の有効期間を表現できるようにそれらは、問題を作成することができます組み合わせた証明書を作成し、異なる期間のための有効な配分を証明する場合。
If a resource holder's allocations come from different sources, they will be signed by different CAs and cannot be combined. When a set of resources is no longer allocated to a resource holder, any certificates attesting to such an allocation MUST be revoked. A resource holder SHOULD NOT use the same public key in multiple CA certificates that are issued by the same or differing authorities, as reuse of a key pair complicates path construction. Note that since the subject's distinguished name is chosen by the issuer, a subject who receives allocations from two sources generally will receive certificates with different subject names.
資源保有者の割り当てが異なるソースから来る場合、それらは異なるCAによって署名され、組み合わせることはできません。リソースのセットは、もはやリソースホルダーに割り当てられている場合、このような割り当てを証明する任意の証明書は取り消されてはなりません。鍵ペアの再利用は、パス構築が複雑とリソースホルダーは、同じまたは異なる当局によって発行された複数のCA証明書で同じ公開鍵を使用しないでください。対象者の識別名は、発行者によって選ばれているので、2つのソースから割り当てを受けた被験者は、一般に、異なるサブジェクト名を持つ証明書を受け取ることに注意してください。
Whenever a certification authority wishes to change the public key (and corresponding private key) associated with its RPKI CA certificate, it MUST perform a key rollover procedure. Key rollover is typically performed on a periodic basis, where the frequency of key rollovers is specified in the certification practice statement of the given CA. Additionally, unscheduled rollovers may be required in the event of suspected key compromises.
認証局は、そのRPKIのCA証明書に関連付けられた公開鍵（および対応する秘密鍵）を変更したいときはいつでも、キーロールオーバーの手順を実行しなければなりません。キーロールオーバーは通常、キーロールオーバーの頻度が与えられたCAの証明の練習文で指定されている定期的、で行われますまた、予定外のロールオーバーが疑わキー妥協の際に必要になることがあります。
Note that rollover is only required when the CA's key actually changes; it is not required in cases where a new CA certificate is issued with the same key as the previous certificate for this CA. For example, a new CA certificate must be issued if the CA gains or relinquishes a resource, or if the validity period of the resource allocation is extended. However, in such cases, the new certificate will generally use the same public (and private) key as the previous certificate; thus, key rollover is not required.
CAのキーは、実際に変わるときにロールオーバーが必要なだけであることに注意してください。それは、新しいCA証明書は、このCAの前の証明書と同じキーで発行された場合に必要とされていませんたとえば、新しいCA証明書は、CAの利益またはリソースを放棄した場合に発行されなければならない、またはリソース割り当ての有効期間が延長されている場合。しかし、このような場合には、新しい証明書は、一般的に、以前の証明書と同じ公共（および民間）キーを使用します。このように、キーロールオーバーは必要ありません。
The document [RFC6489] specifies a conservative key rollover procedure that should be used by a certification authority when it changes the public (and private) keys associated with its RPKI CA certificate. At a high level, the two key properties of the rollover procedure are as follows. First, as data from RPKI signed objects may be used in routing operations, the procedure ensures that at any point in the rollover procedure, a relying party will never reach incorrect conclusions about the validity of a signed object. Note in particular, that the CA cannot assume that a relying party will use any particular algorithm for constructing a certificate path from an EE certificate to (one of) the relying party's trust anchor(s); therefore, the key rollover procedure is designed to preserve the integrity of the SIA and AIA points within the RPKI hierarchy to the greatest extent possible. Second, the key rollover procedure is designed so that the reissuance of all certificates below the CA in the RPKI hierarchy is not required. Of course, it is necessary to re-sign all certificates issued directly under the CA whose key is changing. However, the SIA and AIA pointers within the certificates are populated so that no further reissuance is required.
ドキュメント[RFC6489]は、それがそのRPKI CA証明書に関連付けられているパブリック（およびプライベート）キーを変更したときに認証局によって使用されるべきである保守的なキーロールオーバー手順を指定します。次のようにハイレベルで、ロールオーバー手順の二つの重要な特性です。 RPKIからのデータは、オブジェクトがルーティング操作で使用することができる署名ように、まず、手順は、ロールオーバー手順の任意の時点で、依拠当事者が署名したオブジェクトの有効性について間違った結論に到達することはありませんことを保証します。 CAは、証明書利用者は、（の1つ）にEE証明書から証明書利用者のトラストアンカー（複数可）証明書パスを構築するための任意の特定のアルゴリズムを使用すると仮定することができないことを、特に注意してください。従って、キーロールオーバー手順を可能な限りRPKI階層内SIAおよびAIAポイントの完全性を維持するように設計されています。 RPKI階層内のCAの下にあるすべての証明書の再発行が必要とされないように第二に、キーロールオーバー手順が設計されています。もちろん、そのキーを変更しているCAの直下に発行されたすべての証明書を再署名する必要があります。それ以上の再発行が必要とされないように、しかし、証明書内のSIAおよびAIAポインタが移入されます。
Whenever a holder of IP address space wants to authorize an AS to originate routes for a prefix within his holdings, he MUST issue an end-entity certificate containing that prefix in an IP Address Delegation extension. He then uses the corresponding private key to sign a ROA containing the designated prefix and the AS number for the AS. The resource holder MAY include more than one prefix in the EE certificate and corresponding ROA if desired. As a prerequisite, then, any address space holder that issues ROAs for a prefix must have a resource certificate for an allocation containing that prefix. The standard procedure for issuing a ROA is as follows:
IPアドレス空間の所有者が彼の保有内のプレフィックスのルートを発信する者として認可したいときはいつでも、彼はIPアドレス委任拡張でそのプレフィックスを含むエンドエンティティ証明書を発行しなければなりません。彼はその後、指定されたプレフィックスとASのためのAS番号を含むROAを署名に対応する秘密鍵を使用しています。所望であれば、リソースホルダーがEE証明書と対応するROAに複数のプレフィックスを含むかもしれません。前提条件として、その後、接頭辞のための資産収益率を発行する任意のアドレス空間保持者は、そのプレフィックスを含む割り当てのためにリソース証明書を持っている必要があります。次のようにROAを発行するための標準的な手順は次のとおりです。
1. Create an end-entity certificate containing the prefix(es) to be authorized in the ROA.
1 ROAで認可される接頭語（es）を含むエンドエンティティ証明書を作成します。
2. Construct the payload of the ROA, including the prefixes in the end-entity certificate and the AS number to be authorized.
2.エンドエンティティ証明書及び許可するAS番号にプレフィックスを含む、ROAのペイロードを構築します。
3. Sign the ROA using the private key corresponding to the end-entity certificate (the ROA is comprised of the payload encapsulated in a CMS signed message [RFC5652]).
3.（ROAは、CMS内にカプセル化ペイロードから構成されているメッセージ[RFC5652]を署名した）エンドエンティティ証明書に対応する秘密鍵を使用してROAサイン。
4. Upload the end-entity certificate and the ROA to the repository system.
4.リポジトリシステムへのエンドエンティティ証明書とROAをアップロードします。
The standard procedure for revoking a ROA is to revoke the corresponding end-entity certificate by creating an appropriate CRL and uploading it to the repository system. The revoked ROA and end-entity certificate SHOULD be removed from the repository system.
ROAを取り消すための標準的な手順は、適切なCRLを作成し、リポジトリ・システムにアップロードすることによって、対応するエンドエンティティ証明書を失効することです。失効ROAとエンドエンティティ証明書は、リポジトリシステムから除去されるべきです。
Care must be taken when revoking ROAs in that revoking a ROA may cause a relying party to treat routing advertisements corresponding to the prefixes and origin AS number in the ROA as unauthorized (and potentially even change routing behavior to no longer forward packets based on those advertisements). In particular, resource holders should adhere to the principle of "make before break" as follows. Before revoking a ROA corresponding to a prefix that the resource holder wishes to be routable on the Internet, it is very important for the resource holder to ensure that there exists another valid alternative ROA that lists the same prefix (possibly indicating a different AS number). Additionally, the resource holder should ensure that the AS indicated in the valid alternative ROA is actually originating routing advertisements to the prefixes in question. Furthermore, a relying party must fetch new ROAs from the repository system before taking any routing action in response to a ROA revocation.
ケアは、その中で資産収益率を取り消すときROAを取り消すことは不正としてROAにAS番号プレフィックスと原点に対応するルーティング広告を治療するための証明書利用者を引き起こし（および潜在的にも、前方もはやにそれらの広告に基づいてパケットをルーティング動作を変更しないことに注意しなければなりません）。特に、資源保有者は、次のように「ブレークする前に行う」の原則を遵守すべきです。リソースの所有者がインターネット上でルーティング可能であることを希望する接頭辞に対応するROAを取り消す前に、同じプレフィックスを（おそらく数AS異なることを示す）示しています別の有効な代替のROAが存在することを確認するために、リソースホルダーのために非常に重要です。また、リソースホルダーは、ASは、ROAが実際に問題のプレフィックスへのルーティング広告を発信している有効な代替に示されていることを確認する必要があります。さらに、証明書利用者は、ROAの失効に応じて任意のルーティングアクションをとる前に、リポジトリシステムから新しい資産収益率をフェッチする必要があります。
In BGP, a single-homed subscriber with Provider Aggregatable (PA) address space does not need to explicitly authorize routes to be originated for the prefix(es) it is using, since its ISP will already advertise a more general prefix and route traffic for the subscriber's prefix as an internal function. Since no routes are originated specifically for prefixes held by these subscribers, no ROAs need to be issued under their allocations; rather, the subscriber's ISP will issue any necessary ROAs for its more general prefixes under resource certificates from its own allocation. Thus, a single-homed subscriber with an IP address allocation from his service provider is not included in the RPKI, i.e., it does not receive a CA certificate, nor issue EE certificates or ROAs.
そのISPは、すでに多くの一般的なプレフィックスとルートトラフィック用をアドバタイズしますので、BGPでは、プロバイダ集約（PA）アドレス空間を持つシングルホーム加入者は、それが使用される接頭語（ES）のために起源することが明示的にルートを承認する必要はありません。内部機能として、加入者の接頭辞。何のルートがこれらの加入者が保有するプレフィックスのために特別に起源されていないので、何の資産収益率は、彼らの配分の下で発行する必要はありません。むしろ、加入者のISPは独自の割り当てからリソース証明書の下での、より一般的なプレフィックスのすべての必要な資産収益率を発行します。このように、彼のサービスプロバイダからIPアドレスの割り当てを持つシングルホーム加入者がRPKIには含まれていない、すなわち、それは、CA証明書を受け取り、またEE証明書や資産収益率を発行することはありません。
Here we consider a subscriber who receives Provider Aggregatable (PA) IP address space from a primary ISP (i.e., the IP addresses used by the subscriber are a subset of ISP A's IP address space allocation) and receives redundant upstream connectivity from one or more secondary ISPs, in addition to the primary ISP. The preferred option for such a multi-homed subscriber is for the subscriber to obtain an AS number and run BGP with each of its upstream providers. In such a case, there are two RECOMMENDED ways for ROA management to be handled. The first is that the primary ISP issues a CA certificate to the subscriber, and the subscriber issues a ROA to containing the subscriber's AS number and the subscriber's IP address prefixes. The second possibility is that the primary ISP does not issue a CA certificate to the subscriber, and instead issues a ROA on the subscriber's behalf that contains the subscriber's AS number and the subscriber's IP address prefixes.
ここでは、主要ISPからプロバイダ集約（PA）IPアドレス空間を受け取る（すなわち、加入者が使用するIPアドレスはISP AのIPアドレス空間の割り当てのサブセットである）、および1つ以上の二から冗長アップストリーム接続を受ける加入者を考えます主要ISPに加えてISPは、。加入者は、AS番号を取得し、その上流プロバイダのそれぞれとBGPを実行するため、このようなマルチホーム加入者のための好ましい選択肢です。このような場合には、ROA管理を処理するための2つの推奨方法があります。最初は主要ISPは加入者にCA証明書を発行し、加入者が加入者のAS番号と加入者のIPアドレスプレフィクスを含むへのROAを出すということです。第2の可能性は、主要ISPは加入者へのCA証明書を発行しないということで、代わりに加入者のAS番号と加入者のIPアドレスのプレフィックスが含まれている加入者の代理としてROAを発行します。
If the subscriber is unable or unwilling to obtain an AS number and run BGP, the another option is that the multi-homed subscriber can request that the primary ISP create a ROA for each secondary ISP that authorizes the secondary ISP to originate routes to the subscriber's prefixes. The primary ISP will also create a ROA containing its own AS number and the subscriber's prefixes, as it is likely in such a case that the primary ISP wishes to advertise precisely the subscriber's prefixes and not an encompassing aggregate. Note that this approach results in inconsistent origin AS numbers for the subscriber's prefixes that are considered undesirable on the public Internet; thus, this approach is NOT RECOMMENDED.
加入者は、AS番号を取得し、BGPを実行することができない、または不本意である場合、別のオプションは、マルチホーム加入者は、プライマリISPが加入者へのルートを発信するための二次ISPを許可各二次ISPのためのROAを作成することを要求することができるということです接頭辞。それは主要ISPが網羅集約正確に加入者のプレフィックスを通知していないことを望むような場合にそうであるよう主要ISPはまた、数および加入者の接頭語としての自分を含むROAを作成します。公共のインターネット上では望ましくないと考えられている加入者のプレフィックスの番号AS矛盾起源で、このアプローチは、結果ことに注意してください。したがって、このアプローチは推奨されません。
A resource holder is said to have provider-independent (portable) address space if the resource holder received its allocation directly from a RIR or NIR. Because the prefixes represented in such allocations are not taken from an allocation held by an ISP, there is no ISP that holds and advertises a more general prefix. A holder of a portable IP address space allocation MUST authorize one or more ASes to originate routes to these prefixes. Thus, the resource holder MUST generate one or more EE certificates and associated ROAs to enable the AS(es) to originate routes for the prefix(es) in question. This ROA is required because none of the ISP's existing ROAs authorize it to originate routes to the subscriber's provider-independent allocation.
リソースホルダーは、リソースホルダーがRIRまたはNIRから直接割り当てを受信した場合、プロバイダに依存しない（ポータブル）のアドレス空間を有すると言われています。そのような配分で示さプレフィックスはISPによって保持された割り当てから取られていないので、より一般的な接頭辞を保持し、アドバタイズしないISPは存在しません。ポータブルIPアドレス空間の割り当ての保有者は、これらのプレフィックスへのルートを発信するために、1つの以上のASを認可しなければなりません。したがって、リソースホルダーは、問題の接頭語（es）のルートを発信する（複数可）を有効にするために、1つ以上のEE証明書および関連資産収益率を生成しなければなりません。 ISPの既存の資産収益率のいずれも加入者のプロバイダに依存しない割り当てへのルートを発信することを許可していないので、このROAが必要です。
The focus of this document is security; hence, security considerations permeate this specification.
この文書の焦点はセキュリティです。したがって、セキュリティ上の考慮事項は、この仕様に浸透します。
The security mechanisms provided by and enabled by this architecture depend on the integrity and availability of the infrastructure it describes. The integrity of objects within the infrastructure is ensured by appropriate controls on the repository system, as described in Section 4.4. Likewise, because the repository system is structured as a distributed database, it should be inherently resistant to denial-of-service attacks; nonetheless, appropriate precautions should also be taken, both through replication and backup of the constituent databases and through the physical security of database servers.
このアーキテクチャによってによって提供され、有効なセキュリティメカニズムは、それが記述するインフラの完全性、可用性に依存します。セクション4.4で説明したように、インフラストラクチャ内のオブジェクトの完全性は、リポジトリシステム上の適切なコントロールによって保証されます。リポジトリシステムは分散データベースとして構成されているので、同様に、それは、サービス拒否攻撃に対して本質的に耐性であるべきです。それにもかかわらず、適切な予防措置も、構成データベースのレプリケーションとバックアップを通って、データベースサーバの物理的なセキュリティによって両方、注意が必要です。
Instructions for IANA's participation in the RPKI are provided in [RFC6491].
RPKIでIANAの参加のための手順は、[RFC6491]で提供されています。
The architecture described in this document is derived from the collective ideas and work of a large group of individuals. This work would not have been possible without the intellectual contributions of George Michaelson, Robert Loomans, Sanjaya and Geoff Huston of APNIC, Robert Kisteleki and Henk Uijterwaal of the RIPE NCC, Tim Christensen and Cathy Murphy of ARIN, Rob Austein of ISC, and Randy Bush of IIJ.
この文書で説明したアーキテクチャは、個人の大規模なグループの集合的なアイデアや作品から派生しています。この作品はジョージ・マイケルソン、ロバートLoomans、サンジャヤとAPNICのジェフ・ヒューストン、ロバートKistelekiとRIPE NCCのヘンク・Uijterwaal、ティム・クリステンセンとARINのキャシー・マーフィー、ISCのロブAusteinと、ランディの知的貢献なしには不可能でしたIIJのブッシュ。
Although we are indebted to everyone who has contributed to this architecture, we would like to especially thank Rob Austein for the concept of a manifest, Geoff Huston for the concept of managing object validity through single-use EE certificate key pairs, and Richard Barnes for help in preparing an early version of this document.
私たちは、このアーキテクチャに貢献してきたすべての人にお世話になっているが、我々はのために特に使い捨てEE証明書の鍵のペアを通じてオブジェクトの有効性を管理する概念のマニフェスト、ジェフ・ヒューストンの概念のためのロブAusteinとに感謝したい、とリチャード・バーンズうこのドキュメントの初期バージョンを製造するのに役立ちます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC3779]リン、C.、ケント、S.、およびK.ソ、 "IPアドレスとAS識別子のためのX.509拡張機能"、RFC 3779、2004年6月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、エド。、李、T.、エド。、およびS.野兎、編、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年5月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652] Housley氏、R.、 "暗号メッセージ構文（CMS）"、STD 70、RFC 5652、2009年9月。
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, February 2010.
[RFC5781]ワイラー、S.、ウォード、D.、およびR. Housley氏、 "rsyncのURIスキーム"、RFC 5781、2010年2月。
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012.
[RFC6481]ヒューストン、G.、Loomans、R.、およびG.マイケルソン、 "リソース証明書リポジトリの構造用プロフィール"、RFC 6481、2012年2月。
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.
[RFC6482] Lepinski、M.、ケント、S.、およびD.コング、 "ルート起源権限のプロファイル（資産収益率）"、RFC 6482、2012年2月。
[RFC6486] Austein, R., Huston., G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure", RFC 6486, February 2012.
[RFC6486] Austeinと、R.、ヒューストン。、G.、ケント、S.、およびM. Lepinski、 "リソース公開鍵インフラストラクチャのためのマニフェスト"、RFC 6486、2012年2月。
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012.
[RFC6487]ヒューストン、G.、マイケルソン、G.、およびR. Loomans、 "X.509 PKIXリソース証明書のプロファイル"、RFC 6487、2012年2月。
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure", RFC 6488, February 2012.
[RFC6488] Lepinski、M.、チー、A.、およびS.ケント、 "リソース公開鍵インフラストラクチャのための署名付きオブジェクトテンプレート"、RFC 6488、2012年2月。
[RFC6491] Manderson, T., Vegoda, L., and S. Kent, "Resource Public Key Infrastructure (RPKI) Objects Issued by IANA", RFC 6491, February 2012.
[RFC6491] Manderson、T.、Vegoda、L.、およびS.ケント、 "IANAによって発行されたリソース公開鍵インフラストラクチャ（RPKI）オブジェクト"、RFC 6491、2012年2月。
[RFC6483] Huston, G. and G. Michaelson, "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)", RFC 6483, February 2012.
[RFC6483]ヒューストン、G.とG.マイケルソン、「リソース証明書の公開鍵インフラストラクチャを使用してルートオリジネーション（PKI）とルート起源権限（資産収益率）の検証」、RFC 6483、2012年2月。
[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", BCP 174, RFC 6489, February 2012.
[RFC6489]ヒューストン、G.、マイケルソン、G.、およびS.ケント、 "リソース公開鍵インフラストラクチャにおける認証局（CA）キーロールオーバー（RPKI）"、BCP 174、RFC 6489、2012年2月。
[RFC6490] Huston, G., Weiler, S., Michaelson, G., and S. Kent, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", RFC 6490, February 2012.
[RFC6490]ヒューストン、G.、ワイラー、S.、マイケルソン、G.、およびS.ケント、 "リソースの公開鍵インフラストラクチャ（RPKI）トラストアンカーロケータ"、RFC 6490、2012年2月。
[RSYNC] rsync web pages, <http://rsync.samba.org/>.
[RSYNC] rsyncのWebページ、<http://rsync.samba.org/>。
[S-BGP] Kent, S., Lynn, C., and Seo, K., "Secure Border Gateway Protocol (Secure-BGP)", IEEE Journal on Selected Areas in Communications Vol. 18, No. 4, April 2000.
[S-BGP]ケント、S.、リン、C.、およびソ、K.、通信VOLに選択された領域に、IEEEジャーナル "ボーダーゲートウェイプロトコル（セキュアBGP）を確保"。 18、第4号、2000年4月。
[soBGP] White, R., "soBGP", May 2005, <ftp://ftp-eng.cisco.com/sobgp/index.html>
[soBGP]ホワイト、R.、 "soBGP"、2005年5月、<ftp://ftp-eng.cisco.com/sobgp/index.html>
Authors' Addresses
著者のアドレス
Matt Lepinski BBN Technologies 10 Moulton St. Cambridge, MA 02138
マット・Lepinski BBNテクノロジーズ10モールトンセントケンブリッジ、MA 02138
EMail: mlepinski@bbn.com
メールアドレス：mlepinski@bbn.com
Stephen Kent BBN Technologies 10 Moulton St. Cambridge, MA 02138
スティーブン・ケントBBNテクノロジーズ10モールトンセントケンブリッジ、MA 02138
EMail: kent@bbn.com
メールアドレス：kent@bbn.com