[要約] RFC 8209は、BGPsecルーター証明書、証明書失効リスト、および証明書リクエストのためのプロファイルに関するものです。このRFCの目的は、BGPセキュリティのための効果的な証明書管理を提供することです。
Internet Engineering Task Force (IETF) M. Reynolds
Request for Comments: 8209 IPSw
Updates: 6487 S. Turner
Category: Standards Track sn3rd
ISSN: 2070-1721 S. Kent
BBN
September 2017
A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests
BGPsecルーター証明書、証明書失効リスト、および認証要求のプロファイル
Abstract
概要
This document defines a standard profile for X.509 certificates used to enable validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPsec. BGP is the standard for inter-domain routing in the Internet; it is the "glue" that holds the Internet together. BGPsec is being developed as one component of a solution that addresses the requirement to provide security for BGP. The goal of BGPsec is to provide full AS path validation based on the use of strong cryptographic primitives. The end entity (EE) certificates specified by this profile are issued to routers within an AS. Each of these certificates is issued under a Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificate. These CA certificates and EE certificates both contain the AS Resource extension. An EE certificate of this type asserts that the router or routers holding the corresponding private key are authorized to emit secure route advertisements on behalf of the AS(es) specified in the certificate. This document also profiles the format of certification requests and specifies Relying Party (RP) certificate path validation procedures for these EE certificates. This document extends the RPKI; therefore, this document updates the RPKI Resource Certificates Profile (RFC 6487).
このドキュメントでは、BGPsecと呼ばれるプロトコルの拡張機能の一部として、ボーダーゲートウェイプロトコル（BGP）で自律システム（AS）パスの検証を有効にするために使用されるX.509証明書の標準プロファイルを定義します。 BGPは、インターネットのドメイン間ルーティングの標準です。それはインターネットをまとめる「接着剤」です。 BGPsecは、BGPにセキュリティを提供する要件に対処するソリューションの1つのコンポーネントとして開発されています。 BGPsecの目標は、強力な暗号プリミティブの使用に基づいて完全なASパス検証を提供することです。このプロファイルで指定されたエンドエンティティ（EE）証明書は、AS内のルーターに発行されます。これらの証明書はそれぞれ、リソース公開鍵インフラストラクチャ（RPKI）証明機関（CA）証明書の下で発行されます。これらのCA証明書とEE証明書には、どちらもASリソース拡張が含まれています。このタイプのEE証明書は、対応する秘密鍵を保持する1つまたは複数のルーターが、証明書で指定されたASに代わって安全なルートアドバタイズメントを発行することを許可されていることを表明します。このドキュメントでは、認証要求の形式もプロファイルし、これらのEE証明書の証明書利用者（RP）証明書パス検証手順を指定します。このドキュメントはRPKIを拡張します。したがって、このドキュメントはRPKIリソース証明書プロファイル（RFC 6487）を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8209.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8209で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. Describing Resources in Certificates ............................4
3. Updates to RFC 6487 .............................................6
3.1. BGPsec Router Certificate Fields ...........................6
3.1.1. Subject .............................................6
3.1.2. Subject Public Key Info .............................6
3.1.3. BGPsec Router Certificate Version 3
Extension Fields ....................................6
3.1.3.1. Basic Constraints ..........................6
3.1.3.2. Extended Key Usage .........................6
3.1.3.3. Subject Information Access .................7
3.1.3.4. IP Resources ...............................7
3.1.3.5. AS Resources ...............................7
3.2. BGPsec Router Certificate Request Profile ..................7
3.3. BGPsec Router Certificate Validation .......................8
3.4. Router Certificates and Signing Functions in the RPKI ......8
4. Design Notes ....................................................9
5. Implementation Considerations ...................................9
6. Security Considerations ........................................10
7. IANA Considerations ............................................10
8. References .....................................................11
8.1. Normative References ......................................11
8.2. Informative References ....................................12
Appendix A. ASN.1 Module ..........................................14
Acknowledgements ..................................................15
Authors' Addresses ................................................15
This document defines a profile for X.509 end entity (EE) certificates [RFC5280] for use in the context of certification of Autonomous System (AS) paths in the BGPsec protocol. Such certificates are termed "BGPsec Router Certificates". The holder of the private key associated with a BGPsec Router Certificate is authorized to send secure route advertisements (BGPsec UPDATEs) on behalf of the AS(es) named in the certificate. A router holding the private key is authorized to send route advertisements (to its peers) identifying the router's AS number (ASN) as the source of the advertisements. A key property provided by BGPsec is that every AS along the AS path can verify that the other ASes along the path have authorized the advertisement of the given route (to the next AS along the AS path).
このドキュメントは、BGPsecプロトコルで自律システム（AS）パスの認証のコンテキストで使用するためのX.509エンドエンティティ（EE）証明書[RFC5280]のプロファイルを定義します。このような証明書は「BGPsecルーター証明書」と呼ばれます。 BGPsecルーター証明書に関連付けられた秘密鍵の所有者は、証明書で指定されたASに代わって、安全なルートアドバタイズメント（BGPsec UPDATE）を送信することを許可されます。プライベートキーを保持しているルーターは、ルーターのAS番号（ASN）をアドバタイズのソースとして識別するルートアドバタイズを（ピアに）送信することを許可されます。 BGPsecが提供する重要な特性は、ASパスに沿ったすべてのASが、パスに沿った他のASが特定のルート（ASパスに沿った次のASへ）の通知を承認したことを確認できることです。
This document is a profile of [RFC6487], which is a profile of [RFC5280]; thus, this document updates [RFC6487]. It establishes requirements imposed on a Resource Certificate that is used as a BGPsec Router Certificate, i.e., it defines constraints for certificate fields and extensions for the certificate to be valid in this context. This document also profiles the certification requests used to acquire BGPsec Router Certificates. Finally, this document specifies the Relying Party (RP) certificate path validation procedures for these certificates.
このドキュメントは、[RFC5280]のプロファイルである[RFC6487]のプロファイルです。したがって、このドキュメントは[RFC6487]を更新します。これは、BGPsecルーター証明書として使用されるリソース証明書に課せられる要件を確立します。つまり、証明書のフィールドと証明書の拡張がこのコンテキストで有効になるように制約を定義します。このドキュメントでは、BGPsecルーター証明書の取得に使用される認証要求についても説明します。最後に、このドキュメントでは、これらの証明書の証明書利用者（RP）証明書パス検証手順を指定します。
It is assumed that the reader is familiar with the terms and concepts described in "A Profile for X.509 PKIX Resource Certificates" [RFC6487], "BGPsec Protocol Specification" [RFC8205], "A Border Gateway Protocol 4 (BGP-4)" [RFC4271], "BGP Security Vulnerabilities Analysis" [RFC4272], "Considerations in Validating the Path in BGP" [RFC5123], and "Capabilities Advertisement with BGP-4" [RFC5492].
「X.509 PKIXリソース証明書のプロファイル」[RFC6487]、「BGPsecプロトコル仕様」[RFC8205]、「ボーダーゲートウェイプロトコル4（BGP-4）」で説明されている用語と概念に読者が精通していることを前提としています。 「[RFC4271]、「BGPセキュリティ脆弱性分析」[RFC4272]、「BGPでパスを検証する際の考慮事項」[RFC5123]、および「BGP-4での機能アドバタイズメント」[RFC5492]。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Figure 1 depicts some of the entities in the Resource Public Key Infrastructure (RPKI) and some of the products generated by RPKI entities. IANA issues a Certification Authority (CA) certificate to each Regional Internet Registry (RIR). The RIR in turn issues a CA certificate to an Internet Service Provider (ISP). The ISP in turn issues EE certificates to itself to enable verification of signatures on RPKI signed objects. The CA also generates Certificate Revocation Lists (CRLs). These CA and EE certificates are referred to as "Resource Certificates" and are profiled in [RFC6487]. [RFC6480] envisioned using Resource Certificates to enable verification of manifests [RFC6486] and Route Origin Authorizations (ROAs) [RFC6482]. ROAs and manifests include the Resource Certificates used to verify them.
図1は、リソース公開鍵インフラストラクチャ（RPKI）のエンティティの一部と、RPKIエンティティによって生成された製品の一部を示しています。 IANAは、各地域インターネットレジストリ（RIR）に証明機関（CA）証明書を発行します。次に、RIRはCA証明書をインターネットサービスプロバイダー（ISP）に発行します。次にISPは、自身にEE証明書を発行して、RPKIで署名されたオブジェクトの署名を検証できるようにします。 CAは、証明書失効リスト（CRL）も生成します。これらのCAおよびEE証明書は「リソース証明書」と呼ばれ、[RFC6487]でプロファイルされています。 [RFC6480]リソース証明書を使用して、マニフェスト[RFC6486]およびRoute Origin Authorizations（ROA）[RFC6482]の検証を可能にすることを想定しています。 ROAとマニフェストには、それらを検証するために使用されるリソース証明書が含まれます。
+---------+ +------+
| CA Cert |---| IANA |
+---------+ +------+
\
+---------+ +-----+
| CA Cert |---| RIR |
+---------+ +-----+
\
+---------+ +-----+
| CA Cert |---| ISP |
+---------+ +-----+
/ | | |
+-----+ / | | | +-----+
| CRL |--+ | | +---| ROA |
+-----+ | | +-----+
| | +----------+
+----+ | +---| Manifest |
+-| EE |---+ +----------+
| +----+
+-----+
Figure 1
図1
This document defines another type of Resource Certificate, which is referred to as a "BGPsec Router Certificate". The purpose of this certificate is explained in Section 1 and falls within the scope of appropriate uses defined within [RFC6484]. The issuance of BGPsec Router Certificates has minimal impact on RPKI CAs because the RPKI CA certificate and CRL profile remain unchanged (i.e., they are as specified in [RFC6487]). Further, the algorithms used to generate RPKI CA certificates that issue the BGPsec Router Certificates and the CRLs necessary to check the validity of the BGPsec Router Certificates remain unchanged (i.e., they are as specified in [RFC7935]). The only impact is that RPKI CAs will need to be able to process a profiled certificate request (see Section 3.2) signed with algorithms found in [RFC8208]. BGPsec Router Certificates are used only to verify the signature on the BGPsec certificate request (only CAs process these) and the signature on a BGPsec UPDATE message [RFC8205] (only BGPsec routers process these); BGPsec Router Certificates are not used to process manifests and ROAs or verify signatures on Certificates or CRLs.
このドキュメントでは、「BGPsecルーター証明書」と呼ばれる別のタイプのリソース証明書を定義します。この証明書の目的はセクション1で説明されており、[RFC6484]で定義されている適切な使用の範囲に含まれます。 BGPsecルーター証明書の発行は、RPKI CA証明書とCRLプロファイルが変更されないままであるため（つまり、[RFC6487]で指定されているとおり）、RPKI CAへの影響は最小限です。さらに、BGPsecルーター証明書を発行するRPKI CA証明書を生成するために使用されるアルゴリズムと、BGPsecルーター証明書の有効性をチェックするために必要なCRLは変更されません（つまり、[RFC7935]で指定されているとおりです）。唯一の影響は、RPKI CAが、[RFC8208]にあるアルゴリズムで署名されたプロファイル済み証明書要求（セクション3.2を参照）を処理できる必要があることです。 BGPsecルーター証明書は、BGPsec証明書要求の署名（CAのみがこれらを処理する）とBGPsec UPDATEメッセージの署名[RFC8205]（BGPsecルーターのみがこれらを処理する）を検証するためにのみ使用されます。 BGPsecルーター証明書は、マニフェストとROAの処理、または証明書またはCRLの署名の検証には使用されません。
This document enumerates only the differences between this profile and the profile in [RFC6487]. Note that BGPsec Router Certificates are EE certificates, and as such there is no impact on the algorithm agility procedure described in [RFC6916].
このドキュメントでは、このプロファイルと[RFC6487]のプロファイルの違いのみを列挙しています。 BGPsecルーター証明書はEE証明書であるため、[RFC6916]で説明されているアルゴリズムの俊敏性手順には影響がないことに注意してください。
A BGPsec Router Certificate is consistent with the profile in [RFC6487] as modified by the specifications in this section. As such, it is a valid X.509 public key certificate and consistent with the PKIX profile [RFC5280]. The differences between this profile and the profile in [RFC6487] are specified in this section.
BGPsecルーター証明書は、このセクションの仕様によって変更された[RFC6487]のプロファイルと一致しています。そのため、これは有効なX.509公開鍵証明書であり、PKIXプロファイル[RFC5280]と一致しています。このプロファイルと[RFC6487]のプロファイルの違いは、このセクションで指定されています。
Encoding options for the common name that are supported are printableString and UTF8String. For BGPsec Router Certificates, it is RECOMMENDED that the common name attribute contain the literal string "ROUTER-" followed by the 32-bit ASN [RFC3779] encoded as eight hexadecimal digits and that the serial number attribute contain the 32-bit BGP Identifier [RFC4271] (i.e., the router ID) encoded as eight hexadecimal digits. If there is more than one ASN, the choice of which to include in the common name is at the discretion of the Issuer. If the same certificate is issued to more than one router (and hence the private key is shared among these routers), the choice of the router ID used in this name is at the discretion of the Issuer.
サポートされている共通名のエンコーディングオプションは、printableStringとUTF8Stringです。 BGPsecルーター証明書の場合、共通名属性にリテラル文字列「ROUTER-」とそれに続く32ビットのASN [RFC3779]が8桁の16進数としてエンコードされ、シリアル番号属性に32ビットのBGP IDが含まれることが推奨されます[ RFC4271]（つまり、ルータID）8桁の16進数としてエンコードされます。複数のASNがある場合、共通名に含めるASNの選択は、発行者の裁量に委ねられています。同じ証明書が複数のルーターに発行されている（したがって、秘密鍵がこれらのルーター間で共有されている）場合、この名前で使用されるルーターIDの選択は、発行者の裁量に任されます。
Refer to Section 3.1 of [RFC8208].
[RFC8208]のセクション3.1を参照してください。
BGPsec speakers are EEs; therefore, the Basic Constraints extension must not be present, as per [RFC6487].
BGPsecスピーカーはEEです。したがって、[RFC6487]のように、基本制約拡張が存在してはなりません。
BGPsec Router Certificates MUST include the Extended Key Usage (EKU) extension. As specified in [RFC6487], this extension must not be marked critical. This document defines one EKU for BGPsec Router Certificates:
BGPsecルーター証明書には、Extended Key Usage（EKU）拡張が含まれている必要があります。 [RFC6487]で指定されているように、この拡張機能を重要とマークしてはなりません。このドキュメントでは、BGPsecルーター証明書に1つのEKUを定義しています。
id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) kp(3) }
id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp 30 }
A BGPsec router MUST require the EKU extension be present in a BGPsec Router Certificate it receives. If multiple KeyPurposeId values are included, the BGPsec routers need not recognize all of them, as long as the required KeyPurposeId value is present. BGPsec routers MUST reject certificates that do not contain the BGPsec Router EKU even if they include the anyExtendedKeyUsage OID defined in [RFC5280].
BGPsecルーターは、受信するBGPsecルーター証明書にEKU拡張が存在する必要があります。複数のKeyPurposeId値が含まれている場合、必要なKeyPurposeId値が存在する限り、BGPsecルーターはそれらすべてを認識する必要はありません。 BGPsecルーターは、[RFC5280]で定義されたanyExtendedKeyUsage OIDが含まれていても、BGPsecルーターEKUを含まない証明書を拒否する必要があります。
This extension is not used in BGPsec Router Certificates. It MUST be omitted.
この拡張機能は、BGPsecルーター証明書では使用されません。省略する必要があります。
This extension is not used in BGPsec Router Certificates. It MUST be omitted.
この拡張機能は、BGPsecルーター証明書では使用されません。省略する必要があります。
Each BGPsec Router Certificate MUST include the AS Resources extension, as specified in Section 4.8.11 of [RFC6487]. The AS Resources extension MUST include one or more ASNs, and the "inherit" element MUST NOT be specified.
[RFC6487]のセクション4.8.11で指定されているように、各BGPsecルーター証明書にはASリソース拡張が含まれている必要があります。 ASリソース拡張には1つ以上のASNを含める必要があり、「継承」要素を指定してはなりません（MUST NOT）。
Refer to Section 6 of [RFC6487]. The only differences between this profile and the profile in [RFC6487] are as follows:
[RFC6487]のセクション6を参照してください。このプロファイルと[RFC6487]のプロファイルの違いは次のとおりです。
o The Basic Constraints extension:
o 基本制約拡張：
If included, the CA MUST NOT honor the cA boolean if set to TRUE.
含める場合、CAは、TRUEに設定されている場合、cAブール値を尊重してはなりません。
o The EKU extension:
o てぇ えく えｘてんしおん：
If included, id-kp-bgpsec-router MUST be present (see Section 3.1.3.2). If included, the CA MUST honor the request for id-kp-bgpsec-router.
含まれる場合、id-kp-bgpsec-routerが存在する必要があります（セクション3.1.3.2を参照）。含まれている場合、CAはid-kp-bgpsec-routerの要求を尊重する必要があります。
o The Subject Information Access (SIA) extension:
o サブジェクト情報アクセス（SIA）拡張：
If included, the CA MUST NOT honor the request to include the extension.
含まれている場合、CAは拡張を含める要求を尊重してはなりません。
o The SubjectPublicKeyInfo field is specified in [RFC8208].
o SubjectPublicKeyInfoフィールドは[RFC8208]で指定されています。
o The request is signed with the algorithms specified in [RFC8208].
o リクエストは[RFC8208]で指定されたアルゴリズムで署名されています。
The validation procedure used for BGPsec Router Certificates is identical to the validation procedure described in Section 7 of [RFC6487] (and any RFC that updates that procedure), as modified below. For example, in step 3 (of the criteria listed in Section 7.2 of [RFC6487]), "The certificate contains all fields that MUST be present" refers to the fields that are required by this specification.
BGPsecルーター証明書に使用される検証手順は、[RFC6487]のセクション7で説明されている検証手順（およびその手順を更新するRFC）と同じですが、以下が変更されています。たとえば、（[RFC6487]のセクション7.2にリストされている基準の）ステップ3で、「証明書には存在する必要があるすべてのフィールドが含まれています」は、この仕様で必要とされるフィールドを指します。
The differences are as follows:
違いは次のとおりです。
o BGPsec Router Certificates MUST include the BGPsec Router EKU defined in Section 3.1.3.2.
o BGPsecルーター証明書には、セクション3.1.3.2で定義されたBGPsecルーターEKUを含める必要があります。
o BGPsec Router Certificates MUST NOT include the SIA extension.
o BGPsecルーター証明書にSIA拡張を含めてはなりません（MUST NOT）。
o BGPsec Router Certificates MUST NOT include the IP Resources extension.
o BGPsecルーター証明書にIPリソース拡張を含めてはなりません（MUST NOT）。
o BGPsec Router Certificates MUST include the AS Resources extension.
o BGPsecルーター証明書には、ASリソース拡張が含まれている必要があります。
o BGPsec Router Certificates MUST include the subjectPublicKeyInfo field described in [RFC8208].
o BGPsecルーター証明書には、[RFC8208]で説明されているsubjectPublicKeyInfoフィールドを含める必要があります。
NOTE: BGPsec RPs will need to support the algorithms in [RFC8208], which are used to validate BGPsec signatures, as well as the algorithms in [RFC7935], which are needed to validate signatures on BGPsec certificates, RPKI CA certificates, and RPKI CRLs.
注：BGPsec RPは、BGPsec署名の検証に使用される[RFC8208]のアルゴリズムと、BGPsec証明書、RPKI CA証明書、およびRPKI CRLの署名の検証に必要な[RFC7935]のアルゴリズムをサポートする必要があります。 。
As described in Section 1, the primary function of BGPsec Router Certificates in the RPKI is for use in the context of certification of AS paths in the BGPsec protocol.
セクション1で説明したように、RPKIのBGPsecルーター証明書の主な機能は、BGPsecプロトコルでのASパスの認証のコンテキストで使用することです。
The private key associated with a router EE certificate may be used multiple times in generating signatures in multiple instances of the BGPsec_PATH attribute Signature Segments [RFC8205]. That is, the BGPsec Router Certificate is used to validate multiple signatures.
ルーターEE証明書に関連付けられた秘密キーは、BGPsec_PATH属性の署名セグメント[RFC8205]の複数のインスタンスで署名を生成する際に複数回使用される場合があります。つまり、BGPsecルーター証明書は、複数の署名を検証するために使用されます。
BGPsec Router Certificates are stored in the issuing CA's repository, where a repository following [RFC6481] MUST use a .cer filename extension for the certificate file.
BGPsecルーター証明書は、発行元のCAのリポジトリに格納されます。[RFC6481]に準拠するリポジトリでは、証明書ファイルに.cerファイル名拡張子を使用する必要があります。
The BGPsec Router Certificate profile is based on the Resource Certificate profile as specified in [RFC6487]. As a result, many of the design choices herein are a reflection of the design choices that were taken in that prior work. The reader is referred to [RFC6484] for a fuller discussion of those choices.
BGPsecルーター証明書プロファイルは、[RFC6487]で指定されているリソース証明書プロファイルに基づいています。結果として、ここでの設計の選択の多くは、その以前の作業で採用された設計の選択を反映しています。読者はそれらの選択のより完全な議論のために[RFC6484]を参照されます。
CAs are required by the Certificate Policy (CP) [RFC6484] to issue properly formed BGPsec Router Certificates regardless of what is present in the certificate request, so there is some flexibility permitted in the certificate requests:
証明書ポリシー（CP）[RFC6484]では、証明書要求の内容に関係なく、適切に形成されたBGPsecルーター証明書を発行するためにCAが必要であるため、証明書要求にはある程度の柔軟性があります。
o BGPsec Router Certificates are always EE certificates; therefore, requests to issue a CA certificate result in EE certificates;
o BGPsecルーター証明書は常にEE証明書です。したがって、CA証明書の発行を要求すると、EE証明書が生成されます。
o BGPsec Router Certificates are always EE certificates; therefore, requests for Key Usage extension values keyCertSign and cRLSign result in certificates with neither of these values;
o BGPsecルーター証明書は常にEE証明書です。したがって、Key Usage拡張値keyCertSignおよびcRLSignを要求すると、これらの値のどちらもない証明書が生成されます。
o BGPsec Router Certificates always include the BGPsec Router EKU value; therefore, requests without the value result in certificates with the value; and,
o BGPsecルーター証明書には、常にBGPsecルーターのEKU値が含まれています。したがって、値のない要求は、値のある証明書になります。そして、
o BGPsec Router Certificates never include the SIA extension; therefore, requests with this extension result in certificates without the extension.
o BGPsecルーター証明書にSIA拡張が含まれることはありません。したがって、この拡張子を持つ要求は、拡張子のない証明書になります。
Note that this behavior is similar to the CA including the AS Resources extension in issued BGPsec Router Certificates, despite the fact that it is not present in the request.
この動作は、要求に存在しないにもかかわらず、発行されたBGPsecルーター証明書にASリソース拡張を含むCAと同様であることに注意してください。
This document permits the operator to include a list of ASNs in a BGPsec Router Certificate. In that case, the router certificate would become invalid if any one of the ASNs is removed from any superior CA certificate along the path to a trust anchor. Operators could choose to avoid this possibility by issuing a separate BGPsec Router Certificate for each distinct ASN, so that the router certificates for ASNs that are retained in the superior CA certificate would remain valid.
このドキュメントにより、オペレーターはBGPsecルーター証明書にASNのリストを含めることができます。その場合、トラストアンカーへのパスに沿って、いずれかのASNが上位のCA証明書から削除されると、ルーター証明書は無効になります。オペレーターは、異なるASNごとに個別のBGPsecルーター証明書を発行することにより、この可能性を回避し、上位のCA証明書に保持されているASNのルーター証明書を有効なままにすることができます。
The security considerations of [RFC6487] apply.
[RFC6487]のセキュリティに関する考慮事項が適用されます。
A BGPsec Router Certificate will fail RPKI validation as defined in [RFC6487] because the cryptographic algorithms used are different. Consequently, an RP needs to identify the EKU to determine the appropriate Validation constraint.
使用される暗号化アルゴリズムが異なるため、[RFC6487]で定義されているように、BGPsecルーター証明書はRPKI検証に失敗します。したがって、RPはEKUを識別して、適切な検証制約を決定する必要があります。
A BGPsec Router Certificate is an extension of the RPKI [RFC6480] to encompass routers. It is a building block of BGPsec and is used to validate signatures on BGPsec Signature Segment origination of signed path segments [RFC8205]. Thus, its essential security function is the secure binding of one or more ASNs to a public key, consistent with the RPKI allocation/assignment hierarchy.
BGPsecルーター証明書は、ルーターを含むRPKI [RFC6480]の拡張です。これはBGPsecのビルディングブロックであり、署名されたパスセグメントのBGPsec署名セグメントの発信時に署名を検証するために使用されます[RFC8205]。したがって、その重要なセキュリティ機能は、1つ以上のASNを公開鍵に安全にバインドすることであり、RPKI割り当て/割り当ての階層と一致しています。
Hash functions [RFC8208] are used when generating the two key identifier extensions (i.e., Subject Key Identifier and Issuer Key Identifier) included in BGPsec certificates. However, as noted in [RFC6818], collision resistance is not a required property of one-way hash functions when used to generate key identifiers. Regardless, hash collisions are unlikely, but they are possible, and if detected an operator should be alerted. A Subject Key Identifier collision might cause the incorrect certificate to be selected from the cache, resulting in a failed signature validation.
ハッシュ関数[RFC8208]は、BGPsec証明書に含まれる2つのキー識別子拡張（つまり、サブジェクトキー識別子と発行者キー識別子）を生成するときに使用されます。ただし、[RFC6818]で説明されているように、キー識別子の生成に使用される場合、衝突抵抗は一方向ハッシュ関数の必須プロパティではありません。とにかく、ハッシュの衝突は起こりそうもありませんが、それは可能であり、検出された場合、オペレーターに警告する必要があります。サブジェクトキー識別子の衝突により、キャッシュから誤った証明書が選択され、署名の検証に失敗する場合があります。
This document makes use of two OIDs in the SMI registry for PKIX. One is for the ASN.1 module [X680] [X690] in Appendix A, and it comes from the "SMI Security for PKIX Module Identifier" IANA registry (id-mod-bgpsec-eku). The other is for the BGPsec Router EKU defined in Section 3.1.3.2 and Appendix A, and it comes from the "SMI Security for PKIX Extended Key Purpose" IANA registry (id-kp-bgpsec-router). These OIDs were assigned before management of the PKIX Arc was handed to IANA. The references in those registries have been updated to point to this document.
このドキュメントでは、PKIXのSMIレジストリで2つのOIDを使用します。 1つは、付録AのASN.1モジュール[X680] [X690]用であり、「SMI Security for PKIX Module Identifier」IANAレジストリ（id-mod-bgpsec-eku）に由来します。もう1つは、セクション3.1.3.2および付録Aで定義されているBGPsecルーターEKU用で、「PKIX拡張キーの目的のためのSMIセキュリティー」IANAレジストリー（id-kp-bgpsec-router）からのものです。これらのOIDは、PKIXアークの管理がIANAに渡される前に割り当てられました。これらのレジストリの参照は、このドキュメントを指すように更新されました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, DOI 10.17487/RFC3779, June 2004, <https://www.rfc-editor.org/info/rfc3779>.
[RFC3779] Lynn、C.、Kent、S.、K。Seo、「X.509 Extensions for IP Addresses and AS Identifiers」、RFC 3779、DOI 10.17487 / RFC3779、2004年6月、<https：//www.rfc -editor.org/info/rfc3779>。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.
[RFC4271] Rekhter、Y。、編、Li、T。、編、S。Hares、編、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月、<https://www.rfc-editor.org/info/rfc4271>。
[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, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, <https://www.rfc-editor.org/info/rfc6481>.
[RFC6481] Huston、G.、Loomans、R。、およびG. Michaelson、「リソース証明書リポジトリ構造のプロファイル」、RFC 6481、DOI 10.17487 / RFC6481、2012年2月、<https：//www.rfc-editor。 org / info / rfc6481>。
[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, <https://www.rfc-editor.org/info/rfc6486>.
[RFC6486] Austein、R.、Huston、G.、Kent、S。、およびM. Lepinski、「Manifests for the Resource Public Key Infrastructure（RPKI）」、RFC 6486、DOI 10.17487 / RFC6486、2012年2月、<https： //www.rfc-editor.org/info/rfc6486>。
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, <https://www.rfc-editor.org/info/rfc6487>.
[RFC6487] Huston、G.、Michaelson、G。、およびR. Loomans、「X.509 PKIXリソース証明書のプロファイル」、RFC 6487、DOI 10.17487 / RFC6487、2012年2月、<https：//www.rfc- editor.org/info/rfc6487>。
[RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, August 2016, <https://www.rfc-editor.org/info/rfc7935>.
[RFC7935] Huston、G。およびG. Michaelson、編、「リソースの公開鍵インフラストラクチャで使用するアルゴリズムと鍵サイズのプロファイル」、RFC 7935、DOI 10.17487 / RFC7935、2016年8月、<https：// www .rfc-editor.org / info / rfc7935>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8205] Lepinski, M., Ed., and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, <https://www.rfc-editor.org/info/rfc8205>.
[RFC8205] Lepinski、M。、編、およびK. Sriram、編、「BGPsecプロトコル仕様」、RFC 8205、DOI 10.17487 / RFC8205、2017年9月、<https://www.rfc-editor.org/info / rfc8205>。
[RFC8208] Turner, S. and O. Borchert, "BGP Algorithms, Key Formats, and Signature Formats", RFC 8208, DOI 10.17487/RFC8208, September 2017, <https://www.rfc-editor.org/info/rfc8208>.
[RFC8208]ターナー、S。およびO.ボーチャート、「BGPアルゴリズム、キー形式、および署名形式」、RFC 8208、DOI 10.17487 / RFC8208、2017年9月、<https://www.rfc-editor.org/info/ rfc8208>。
[X680] ITU-T, "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, ISO/IEC 8824-1, August 2015, <https://www.itu.int/rec/T-REC-X.680/en>.
[X680] ITU-T、「情報技術-抽象構文記法1（ASN.1）：基本記法の仕様」、ITU-T勧告X.680、ISO / IEC 8824-1、2015年8月、<https：// www.itu.int/rec/T-REC-X.680/en>。
[X690] ITU-T, "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1, August 2015, <https://www.itu.int/rec/T-REC-X.690/en>.
[X690] ITU-T、「情報技術-ASN.1エンコーディングルール：基本エンコーディングルール（BER）、正規エンコーディングルール（CER）およびDistinguished Encodingルール（DER）の仕様」、ITU-T勧告X.690、ISO / IEC 8825-1、2015年8月、<https://www.itu.int/rec/T-REC-X.690/en>。
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, <https://www.rfc-editor.org/info/rfc4272>.
[RFC4272] Murphy、S。、「BGP Security Vulnerabilities Analysis」、RFC 4272、DOI 10.17487 / RFC4272、2006年1月、<https://www.rfc-editor.org/info/rfc4272>。
[RFC5123] White, R. and B. Akyol, "Considerations in Validating the Path in BGP", RFC 5123, DOI 10.17487/RFC5123, February 2008, <https://www.rfc-editor.org/info/rfc5123>.
[RFC5123] White、R。およびB. Akyol、「BGPでのパスの検証に関する考慮事項」、RFC 5123、DOI 10.17487 / RFC5123、2008年2月、<https://www.rfc-editor.org/info/rfc5123> 。
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, <https://www.rfc-editor.org/info/rfc5492>.
[RFC5492] Scudder、J。およびR. Chandra、「BGP-4を使用した機能のアドバタイズ」、RFC 5492、DOI 10.17487 / RFC5492、2009年2月、<https://www.rfc-editor.org/info/rfc5492>。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC6480] Lepinski、M。およびS. Kent、「安全なインターネットルーティングをサポートするインフラストラクチャ」、RFC 6480、DOI 10.17487 / RFC6480、2012年2月、<https://www.rfc-editor.org/info/rfc6480> 。
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, <https://www.rfc-editor.org/info/rfc6482>.
[RFC6482] Lepinski、M.、Kent、S.、D。Kong、「A Route for Route Origin Authorizations（ROAs）」、RFC 6482、DOI 10.17487 / RFC6482、2012年2月、<https：//www.rfc- editor.org/info/rfc6482>。
[RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)", BCP 173, RFC 6484, DOI 10.17487/RFC6484, February 2012, <https://www.rfc-editor.org/info/rfc6484>.
[RFC6484]ケント、S。、コング、D。、ソ、K。、およびR.ワトロ、「リソース公開鍵インフラストラクチャ（RPKI）の証明書ポリシー（CP）」、BCP 173、RFC 6484、DOI 10.17487 / RFC6484 、2012年2月、<https://www.rfc-editor.org/info/rfc6484>。
[RFC6818] Yee, P., "Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 6818, DOI 10.17487/RFC6818, January 2013, <https://www.rfc-editor.org/info/rfc6818>.
[RFC6818] Yee、P。、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profiles」の更新、RFC 6818、DOI 10.17487 / RFC6818、2013年1月、<https：//www.rfc- editor.org/info/rfc6818>。
[RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 2013, <https://www.rfc-editor.org/info/rfc6916>.
[RFC6916]ガリアーノ、R。、ケント、S。、およびS.ターナー、「リソース公開鍵インフラストラクチャ（RPKI）のアルゴリズムの俊敏性手順」、BCP 182、RFC 6916、DOI 10.17487 / RFC6916、2013年4月、<https： //www.rfc-editor.org/info/rfc6916>。
BGPSECEKU { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-bgpsec-eku(84) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
ベギン
-- EXPORTS ALL --
-すべてエクスポート-
-- IMPORTS NOTHING --
-何もインポートしない-
-- OID Arc --
-OIDアーク-
id-kp OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) kp(3) }
-- BGPsec Router Extended Key Usage --
-BGPsecルーターの拡張キー使用法-
id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp 30 }
END
終わり
Acknowledgements
謝辞
We would like to thank Geoff Huston, George Michaelson, and Robert Loomans for their work on [RFC6487], which this work is based on. In addition, the efforts of Matt Lepinski were instrumental in preparing this work. Additionally, we'd like to thank Rob Austein, Roque Gagliano, Richard Hansen, Geoff Huston, David Mandelberg, Sandra Murphy, and Sam Weiler for their reviews and comments.
この作業のベースとなっている[RFC6487]の作業について、Geoff Huston、George Michaelson、およびRobert Loomansに感謝します。さらに、マット・レピンスキーの努力はこの作品を準備するのに役立ちました。また、レビューとコメントをいただいたRob Austein、Roque Gagliano、Richard Hansen、Geoff Huston、David Mandelberg、Sandra Murphy、Sam Weilerにも感謝いたします。
Authors' Addresses
著者のアドレス
Mark Reynolds Island Peak Software 328 Virginia Road Concord, MA 01742 United States of America
マークレイノルズアイランドピークソフトウェア328 Virginia Road Concord、MA 01742アメリカ合衆国
Email: mcr@islandpeaksoftware.com
Sean Turner sn3rd
ショーンターナーsn3rd
Email: sean@sn3rd.com
Stephen Kent Raytheon BBN Technologies 10 Moulton St. Cambridge, MA 02138 United States of America
スティーブンケントレイセオンBBNテクノロジーズ10 Moulton St. Cambridge、MA 02138アメリカ合衆国
Email: kent@alum.mit.edu