[要約] RFC 8360は、RPKIの検証方法に関する再考を提案しています。その目的は、RPKIのセキュリティと信頼性を向上させることです。
Internet Engineering Task Force (IETF) G. Huston
Request for Comments: 8360 G. Michaelson
Category: Standards Track APNIC
ISSN: 2070-1721 C. Martinez
LACNIC
T. Bruijnzeels
RIPE NCC
A. Newton
ARIN
D. Shaw
AFRINIC
April 2018
Resource Public Key Infrastructure (RPKI) Validation Reconsidered
リソース公開鍵インフラストラクチャ（RPKI）の検証の再検討
Abstract
概要
This document specifies an alternative to the certificate validation procedure specified in RFC 6487 that reduces aspects of operational fragility in the management of certificates in the Resource Public Key Infrastructure (RPKI), while retaining essential security features.
このドキュメントは、RFC 6487で指定されている証明書検証手順の代替を示しています。これにより、重要なセキュリティ機能を維持しながら、リソース公開鍵インフラストラクチャ（RPKI）での証明書の管理における運用上の脆弱性の側面が削減されます。
The procedure specified in RFC 6487 requires that Resource Certificates are rejected entirely if they are found to overclaim any resources not contained on the issuing certificate, whereas the validation process defined here allows an issuing Certification Authority (CA) to chose to communicate that such Resource Certificates should be accepted for the intersection of their resources and the issuing certificate.
RFC 6487で指定されている手順では、リソース証明書が発行証明書に含まれていないリソースを過剰に要求した場合、リソース証明書を完全に拒否する必要があります。ここで定義されている検証プロセスにより、発行証明書機関（CA）は、そのようなリソース証明書を通信することを選択できます。それらのリソースと発行証明書の共通部分を受け入れる必要があります。
It should be noted that the validation process defined here considers validation under a single trust anchor (TA) only. In particular, concerns regarding overclaims where multiple configured TAs claim overlapping resources are considered out of scope for this document.
ここで定義されている検証プロセスでは、単一のトラストアンカー（TA）での検証のみが考慮されることに注意してください。特に、複数の構成されたTAが重複するリソースを主張する過剰主張に関する懸念は、このドキュメントの範囲外と見なされます。
This choice is signaled by a set of alternative Object Identifiers (OIDs) per "X.509 Extensions for IP Addresses and AS Identifiers" (RFC 3779) and "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)" (RFC 6484). It should be noted that in case these OIDs are not used for any certificate under a trust anchor, the validation procedure defined here has the same outcome as the procedure defined in RFC 6487.
この選択は、「IPアドレスとAS識別子のX.509拡張機能」（RFC 3779）および「リソース公開鍵インフラストラクチャ（RPKI）の証明書ポリシー（CP）」（RFC）ごとの一連の代替オブジェクト識別子（OID）によって通知されます。 6484）。これらのOIDがトラストアンカーの証明書に使用されていない場合、ここで定義されている検証手順は、RFC 6487で定義されている手順と同じ結果になることに注意してください。
Furthermore, this document provides an alternative to Route Origin Authorization (ROA) (RFC 6482) and BGPsec Router Certificate (BGPsec PKI Profiles -- publication requested) validation.
さらに、このドキュメントは、Route Origin Authorization（ROA）（RFC 6482）およびBGPsecルーター証明書（BGPsec PKIプロファイル-公開要求）検証の代替手段を提供します。
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/rfc8360.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8360で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2. Certificate Validation in the RPKI . . . . . . . . . . . . . 4
3. Operational Considerations . . . . . . . . . . . . . . . . . 5
4. An Amended RPKI Certification Validation Process . . . . . . 7
4.1. Verified Resource Sets . . . . . . . . . . . . . . . . . 7
4.2. Differences with Existing Standards . . . . . . . . . . . 7
4.2.1. Certificate Policy (CP) for Use with Validation
Reconsidered in the RPKI . . . . . . . . . . . . . . 7
4.2.2. An Alternative to X.509 Extensions for IP Addresses
and AS Identifiers (RFC 3779) . . . . . . . . . . . . 8
4.2.3. Addendum to RFC 6268 . . . . . . . . . . . . . . . . 12
4.2.4. An Alternative to the Profile for X.509 PKIX Resource
Certificates . . . . . . . . . . . . . . . . . . . . 14
4.2.5. An Alternative ROA Validation . . . . . . . . . . . . 18
4.2.6. An Alternative to BGPsec Router Certificate
Validation . . . . . . . . . . . . . . . . . . . . . 18
5. Validation Examples . . . . . . . . . . . . . . . . . . . . . 19
5.1. Example 1 -- An RPKI Tree Using the Old OIDs Only . . . . 19
5.2. Example 2 -- An RPKI Tree Using the New OIDs Only . . . . 21
5.3. Example 3 -- An RPKI Tree Using a Mix of Old and New OIDs 23
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.1. Normative References . . . . . . . . . . . . . . . . . . 27
9.2. Informative References . . . . . . . . . . . . . . . . . 28
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
This document specifies an alternative to the certificate validation procedure specified in RFC 6487. Where the procedure specified in RFC 6487 will require that Resource Certificates be rejected entirely if they are found to overclaim any resources not contained on the issuing certificate, the procedure defined here dictates that these Resource Certificates be accepted for the intersection of their resources and the issuing certificate only.
このドキュメントでは、RFC 6487で指定されている証明書検証手順の代替案を指定しています。RFC6487で指定されている手順では、リソース証明書が発行元の証明書に含まれていないリソースを過度に要求していることが判明した場合、リソース証明書を完全に拒否する必要があります。ここで定義されている手順により、これらのリソース証明書は、リソースと発行元証明書の共通部分に対してのみ受け入れられること。
The outcome of both procedures is the same as long as no overclaims occur. Furthermore, the new procedure can never lead to the acceptance of resources that are not validly held on the path of issuing certificates.
過剰請求が発生しない限り、両方の手順の結果は同じです。さらに、新しい手順では、証明書の発行経路で有効に保持されていないリソースを受け入れることはできません。
However, the procedure defined here will limit the impact in case resources are no longer validly held on the path of issuing certificates to attestations, such as Route Origin Authorizations [RFC6482] that refer to these resources only.
ただし、これらのリソースのみを参照するRoute Origin Authorizations [RFC6482]など、証明書を証明書に発行するパス上でリソースが有効に保持されなくなった場合、ここで定義された手順により影響が制限されます。
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]で説明されているように解釈されます。
As currently defined in Section 7.2 of [RFC6487], validation of PKIX certificates that conform to the RPKI profile relies on the use of a path validation process where each certificate in the validation path is required to meet the certificate validation criteria.
[RFC6487]のセクション7.2で現在定義されているように、RPKIプロファイルに準拠するPKIX証明書の検証は、検証パスの各証明書が証明書検証基準を満たす必要があるパス検証プロセスの使用に依存しています。
These criteria require, in particular, that the Internet Number Resources (INRs) of each certificate in the validation path are "encompassed" by INRs on the issuing certificate. The first certificate in the path is required to be a trust anchor, and its resources are considered valid by definition.
これらの基準では、特に、検証パス内の各証明書のインターネット番号リソース（INR）が、発行する証明書のINRによって「包括」されている必要があります。パスの最初の証明書はトラストアンカーである必要があり、そのリソースは定義により有効と見なされます。
For example, in the following sequence:
たとえば、次のシーケンスでは：
Certificate 1 (trust anchor):
Issuer TA,
Subject TA,
Resources 192.0.2.0/24, 198.51.100.0/24,
2001:db8::/32, AS64496-AS64500
Certificate 2:
Issuer TA,
Subject CA1,
Resources 192.0.2.0/24, 198.51.100.0/24, 2001:db8::/32
Certificate 3:
Issuer CA1,
Subject CA2,
Resources 192.0.2.0/24, 198.51.100.0/24, 2001:db8::/32
ROA 1: Embedded Certificate 4 (EE certificate): Issuer CA2, Subject R1, Resources 192.0.2.0/24
ROA 1：埋め込み証明書4（EE証明書）：発行者CA2、件名R1、リソース192.0.2.0/24
Prefix 192.0.2.0/24, Max Length 24, ASN 64496
プレフィックス192.0.2.0/24、最大長24、ASN 64496
All certificates in this scenario are considered valid since the INRs of each certificate are encompassed by those of the issuing certificate. ROA1 is valid because the specified prefix is encompassed by the embedded end entity (EE) certificate, as required by [RFC6482].
各証明書のINRは発行する証明書のINRに含まれるため、このシナリオのすべての証明書は有効と見なされます。 [RFC6482]で要求されているように、指定されたプレフィックスは埋め込みエンドエンティティ（EE）証明書に含まれているため、ROA1は有効です。
The allocations recorded in the RPKI change as a result of resource transfers. For example, the CAs involved in transfer might choose to modify CA certificates in an order that causes some of these certificates to "overclaim" temporarily. A certificate is said to "overclaim" if it includes INRs not contained in the INRs of the CA that issued the certificate in question.
RPKIに記録された割り当ては、リソース転送の結果として変化します。たとえば、転送に関与するCAは、これらの証明書の一部を一時的に「過剰要求」させる順序でCA証明書を変更することを選択する場合があります。問題の証明書を発行したCAのINRに含まれていないINRが含まれている場合、証明書は「過大請求」されていると言われます。
It may also happen that a child CA does not voluntarily request a shrunk Resource Certificate when resources are being transferred or reclaimed by the parent. Furthermore, operational errors that may occur during management of RPKI databases also may create CA certificates that, temporarily, no longer encompass all of the INRs of subordinate certificates.
また、親がリソースを転送または再利用しているときに、子CAが自発的に縮小されたリソース証明書を要求しない場合もあります。さらに、RPKIデータベースの管理中に発生する可能性のある操作エラーは、一時的に従属証明書のすべてのINRを網羅しなくなったCA証明書を作成する可能性もあります。
Consider the following sequence:
次のシーケンスについて考えてみます。
Certificate 1 (trust anchor):
Issuer TA,
Subject TA,
Resources 192.0.2.0/24, 198.51.100.0/24,
2001:db8::/32, AS64496-AS64500
Certificate 2:
Issuer TA,
Subject CA1,
Resources 192.0.2.0/24, 2001:db8::/32
Certificate 3 (invalid):
Issuer CA1,
Subject CA2,
Resources 192.0.2.0/24, 198.51.100.0/24, 2001:db8::/32
ROA 1 (invalid): Embedded Certificate 4 (EE certificate, invalid): Issuer CA2, Subject R1, Resources 192.0.2.0/24
ROA 1（無効）：埋め込み証明書4（EE証明書、無効）：発行者CA2、件名R1、リソース192.0.2.0/24
Prefix 192.0.2.0/24, Max Length 24, ASN 64496
プレフィックス192.0.2.0/24、最大長24、ASN 64496
Here, Certificate 2 from the previous example was reissued by TA to CA1, and the prefix 198.51.100.0/24 was removed. However, CA1 failed to reissue a new Certificate 3 to CA2. As a result, Certificate 3 is now overclaiming and considered invalid; by recursion, the embedded Certificate 4 used for ROA1 is also invalid. And ROA1 is invalid because the specified prefix contained in the ROA is no longer encompassed by a valid embedded EE certificate, as required by [RFC6482].
ここでは、前の例の証明書2がTAによってCA1に再発行され、プレフィックス198.51.100.0/24が削除されました。ただし、CA1は新しい証明書3をCA2に再発行できませんでした。その結果、証明書3は現在、過大請求されており、無効と見なされています。再帰により、ROA1に使用された埋め込み証明書4も無効になります。また、[RFC6482]で要求されているように、ROAに含まれている指定されたプレフィックスが有効な埋め込みEE証明書に含まれていないため、ROA1は無効です。
However, it should be noted that ROA1 does not make use of any of the address resources that were removed from CA1's certificate; thus, it would be desirable if ROA1 could still be viewed as valid. Technically, CA1 should reissue a Certificate 3 to CA2 without 198.51.100.0/24, and then ROA1 would be considered valid according to [RFC6482]. But as long as CA1 does not take this action, ROA1 remains invalid. It would be preferable if ROA1 could be considered valid, since the assertion it makes was not affected by the reduced scope of CA1's certificate.
ただし、ROA1はCA1の証明書から削除されたアドレスリソースを使用しないことに注意してください。したがって、ROA1が引き続き有効であると見なされることが望ましいでしょう。技術的には、CA1は198.51.100.0/24なしで証明書3をCA2に再発行する必要があり、ROA1は[RFC6482]に従って有効と見なされます。ただし、CA1がこのアクションを実行しない限り、ROA1は無効のままです。 ROA1が行うアサーションはCA1の証明書の縮小されたスコープの影響を受けなかったため、ROA1が有効であると見なされることが望ましい。
The problem described above can be considered a low probability problem today. However, the potential impact on routing security would be high if an overclaiming occurred near the apex of the RPKI hierarchy, as this would invalidate the entirety of the subtree located below this point.
上記の問題は、今日、低確率の問題と見なすことができます。ただし、RPKI階層の頂点近くでオーバークレームが発生した場合、ルーティングセキュリティへの潜在的な影響は大きくなります。これにより、このポイントの下にあるサブツリー全体が無効になるためです。
The changes specified here to the validation procedure in [RFC6487] do not change the probability of this problem, but they do limit the impact to just the overclaimed resources. This revised validation algorithm is intended to avoid causing CA certificates to be treated as completely invalid as a result of overclaims. However, these changes are designed to not degrade the security offered by the RPKI. Specifically, ROAs and router certificates will be treated as valid only if all of the resources contained in them are encompassed by all superior certificates along a path to a trust anchor.
ここで[RFC6487]の検証手順に指定された変更は、この問題の確率を変更しませんが、過度に要求されたリソースのみに影響を制限します。この改訂された検証アルゴリズムは、過剰要求の結果としてCA証明書が完全に無効として扱われることを回避することを目的としています。ただし、これらの変更は、RPKIによって提供されるセキュリティを低下させないように設計されています。具体的には、ROAとルーター証明書は、それらに含まれるすべてのリソースがトラストアンカーへのパスに沿ったすべての上位の証明書に含まれている場合にのみ有効として扱われます。
The way this is achieved conceptually is by maintaining a Verified Resource Set (VRS) for each certificate that is separate from the INRs found in the resource extension [RFC3779] in the certificate.
これを概念的に実現する方法は、証明書のリソース拡張[RFC3779]にあるINRとは別の、証明書ごとに検証済みリソースセット（VRS）を維持することです。
4.2.1. Certificate Policy (CP) for Use with Validation Reconsidered in the RPKI
4.2.1. RPKIで再検証された検証で使用する証明書ポリシー（CP）
Note that Section 1.2 of [RFC6484] defines the "Certificate Policy (CP) for the Resource PKI (RPKI)" with the following OID:
[RFC6484]のセクション1.2では、次のOIDを使用して「リソースPKI（RPKI）の証明書ポリシー（CP）」を定義しています。
id-cp-ipAddr-asNumber OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) cp(14) 2 }
Per this document, a new OID for an alternative "Certificate Policy (CP) for use with validation reconsidered in the Resource PKI (RPKI)" has been assigned as follows:
このドキュメントによれば、「リソースPKI（RPKI）で再検討された検証で使用するための証明書ポリシー（CP）」の新しいOIDは、次のように割り当てられています。
id-cp-ipAddr-asNumber-v2 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) cp(14) 3 }
This alternative Certificate Policy is the same as the Certificate Policy described in [RFC6484], except that it is used to drive the decision in Step 8 of the validation procedure described in Section 4.2.4.4.
この代替の証明書ポリシーは、[RFC6484]で説明されている証明書ポリシーと同じですが、セクション4.2.4.4で説明されている検証手順のステップ8で決定を行うために使用される点が異なります。
4.2.2. An Alternative to X.509 Extensions for IP Addresses and AS Identifiers (RFC 3779)
4.2.2. IPアドレスとAS識別子（RFC 3779）のX.509拡張の代替
This document defines an alternative to [RFC3779]. All specifications and procedures described in [RFC3779] apply, with the notable exceptions described in the following subsections.
このドキュメントは、[RFC3779]の代替を定義します。 [RFC3779]で説明されているすべての仕様と手順が適用されますが、次のサブセクションで説明されている注目すべき例外は例外です。
Per this document, an OID has been assigned for the extension id-pe-ipAddrBlocks-v2 (id-pe 28). This OID MUST only be used in conjunction with the alternative Certificate Policy OID defined in Section 4.2.1.
このドキュメントでは、拡張ID-pe-ipAddrBlocks-v2（id-pe 28）にOIDが割り当てられています。このOIDは、セクション4.2.1で定義されている代替の証明書ポリシーOIDと組み合わせてのみ使用する必要があります。
The following is an amended specification to be used as an alternative to the specification in Section 2.2.1 of [RFC3779].
以下は、[RFC3779]のセクション2.2.1の仕様の代替として使用される修正仕様です。
The OID for this extension is id-pe-ipAddrBlocks-v2.
この拡張機能のOIDはid-pe-ipAddrBlocks-v2です。
id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe 28 }
where [RFC5280] defines:
ここで、[RFC5280]は以下を定義します。
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe 28 }
IPAddrBlocks ::= SEQUENCE OF IPAddressFamily
IPAddressFamily ::= SEQUENCE { -- AFI & optional SAFI --
addressFamily OCTET STRING (SIZE (2..3)),
ipAddressChoice IPAddressChoice }
IPAddressChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
addressesOrRanges SEQUENCE OF IPAddressOrRange }
IPAddressOrRange ::= CHOICE {
addressPrefix IPAddress,
addressRange IPAddressRange }
IPAddressRange ::= SEQUENCE {
min IPAddress,
max IPAddress }
IPAddress ::= BIT STRING
Note that the descriptions of objects referenced in the syntax above are defined in Sections 2.2.3.1 through 2.2.3.9 of [RFC3779].
上記の構文で参照されているオブジェクトの説明は、[RFC3779]のセクション2.2.3.1から2.2.3.9で定義されていることに注意してください。
Per this document, an OID has been assigned for the extension id-pe-autonomousSysIds-v2 (id-pe 29). This OID MUST only be used in conjunction with the alternative Certificate Policy OID defined in Section 4.2.1.
このドキュメントによれば、OIDは拡張id-pe-autonomousSysIds-v2（id-pe 29）に割り当てられています。このOIDは、セクション4.2.1で定義されている代替の証明書ポリシーOIDと組み合わせてのみ使用する必要があります。
The following is an amended specification to be used as an alternative to the specification in Section 3.2.1 of [RFC3779].
以下は、[RFC3779]のセクション3.2.1の仕様の代替として使用される修正仕様です。
The OID for this extension is id-pe-autonomousSysIds-v2.
この拡張のOIDはid-pe-autonomousSysIds-v2です。
id-pe-autonomousSysIds-v2 OBJECT IDENTIFIER ::= { id-pe 29 }
where [RFC5280] defines:
ここで、[RFC5280]は以下を定義します。
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
id-pe-autonomousSysIds-v2 OBJECT IDENTIFIER ::= { id-pe 29 }
ASIdentifiers ::= SEQUENCE {
asnum [0] EXPLICIT ASIdentifierChoice OPTIONAL,
rdi [1] EXPLICIT ASIdentifierChoice OPTIONAL}
ASIdentifierChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
asIdsOrRanges SEQUENCE OF ASIdOrRange }
ASIdOrRange ::= CHOICE {
id ASId,
range ASRange }
ASRange ::= SEQUENCE {
min ASId,
max ASId }
ASId ::= INTEGER
4.2.2.5. Amended IP Address Delegation Extension Certification Path Validation
4.2.2.5. 修正されたIPアドレス委任拡張の証明パス検証
Certificate path validation is performed as specified in Section 4.2.4.4.
証明書パスの検証は、セクション4.2.4.4の指定に従って実行されます。
4.2.2.6. Amended Autonomous System Identifier Delegation Extension Certification Path Validation
4.2.2.6. 修正された自律システム識別子の委任拡張の証明パス検証
Certificate path validation is performed as specified in Section 4.2.4.4.
証明書パスの検証は、セクション4.2.4.4の指定に従って実行されます。
Per this document, an OID has been assigned for id-mod-ip-addr-and-as-ident-v2, as follows:
このドキュメントでは、次のようにOIDがid-mod-ip-addr-and-as-ident-v2に割り当てられています。
IPAddrAndASCertExtn-v2 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) mod(0)
id-mod-ip-addr-and-as-ident-v2(90) }
The following is an amended specification to be used as an alternative to the specification in Appendix A of [RFC3779].
以下は、[RFC3779]の付録Aの仕様の代替として使用される修正仕様です。
This normative appendix describes the extensions for IP address and AS identifier delegation used by conforming PKI components in ASN.1 syntax.
この規範的な付録では、ASN.1構文の適合PKIコンポーネントによって使用されるIPアドレスとAS識別子の委任の拡張について説明します。
IPAddrAndASCertExtn-v2 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) mod(0)
id-mod-ip-addr-and-as-ident-v2(90) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
ベギン
-- EXPORTS ALL --
-すべてエクスポート-
IMPORTS
輸入
-- PKIX specific OIDs and arcs --
-PKIX固有のOIDと弧-
id-pe FROM PKIX1Explicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) }
-- IP Address Block and AS Identifiers Syntax --
-IPアドレスブロックとAS識別子の構文-
IPAddrBlocks, ASIdentifiers FROM IPAddrAndASCertExtn { iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) mod(0) id-mod-ip-addr-and-as-ident(30) }
;
-- Validation Reconsidered IP Address Delegation Extension OID --
-検証の再検討されたIPアドレス委任拡張OID-
id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe 28 }
-- Validation Reconsidered IP Address Delegation Extension Syntax --
-- Syntax is imported from RFC 3779 --
-- Validation Reconsidered Autonomous System Identifier --
-- Delegation Extension OID --
id-pe-autonomousSysIds-v2 OBJECT IDENTIFIER ::= { id-pe 29 }
-- Validation Reconsidered Autonomous System Identifier --
-- Delegation Extension Syntax --
-- Syntax is imported from RFC 3779 --
-構文はRFC 3779からインポートされます-
END
終わり
Per this document, an OID has been assigned for id-mod-ip-addr-and-as-ident-2v2 as follows:
このドキュメントによれば、OIDは次のようにid-mod-ip-addr-and-as-ident-2v2に割り当てられています。
IPAddrAndASCertExtn-2010v2 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) mod(0)
id-mod-ip-addr-and-as-ident-2v2(91) }
[RFC6268] is an informational RFC that updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 modules in Section 4.2.2.7 remain the normative version.
[RFC6268]は、ASN.1の2008バージョンに準拠するようにいくつかの補助ASN.1モジュールを更新する情報RFCです。セクション4.2.2.7の1988 ASN.1モジュールは標準バージョンのままです。
The following is an additional module conforming to the 2008 version of ASN.1 to be used with the extensions defined in Sections 4.2.2.1 and 4.2.2.3.
以下は、セクション4.2.2.1および4.2.2.3で定義された拡張機能とともに使用される、ASN.1の2008バージョンに準拠した追加モジュールです。
IPAddrAndASCertExtn-2010v2 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) mod(0)
id-mod-ip-addr-and-as-ident-2v2(91) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
ベギン
EXPORTS ALL; IMPORTS
すべてエクスポート;輸入
-- PKIX specific OIDs and arcs --
-PKIX固有のOIDと弧-
id-pe
FROM PKIX1Explicit-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51)}
EXTENSION
FROM PKIX-CommonTypes-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57)}
-- IP Address Block and AS Identifiers Syntax --
-IPアドレスブロックとAS識別子の構文-
IPAddrBlocks, ASIdentifiers
FROM IPAddrAndASCertExtn-2010
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) mod(0)
id-mod-ip-addr-and-as-ident-2(72) }
;
--
-- Extensions contain the set of extensions defined in this
-- module
--
-- These are intended to be placed in public key certificates
-- and thus should be added to the CertExtensions extension
-- set in PKIXImplicit-2009 defined for RFC 5280
--
Extensions EXTENSION ::= {
ext-pe-ipAddrBlocks-v2 | ext-pe-autonomousSysIds-v2
}
-- Validation Reconsidered IP Address Delegation Extension OID --
-検証の再検討されたIPアドレス委任拡張OID-
ext-pe-ipAddrBlocks-v2 EXTENSION ::= {
SYNTAX IPAddrBlocks
IDENTIFIED BY id-pe-ipAddrBlocks-v2
}
id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe 28 }
-- Validation Reconsidered IP Address Delegation --
-- Extension Syntax --
-- Syntax is imported from RFC 6268 --
-構文はRFC 6268からインポートされます-
-- Validation Reconsidered Autonomous System Identifier --
-- Delegation Extension OID --
ext-pe-autonomousSysIds-v2 EXTENSION ::= {
SYNTAX ASIdentifiers
IDENTIFIED BY id-pe-autonomousSysIds-v2
}
id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 29 }
-- Validation Reconsidered Autonomous System Identifier --
-- Delegation Extension Syntax --
-- Syntax is imported from RFC 6268 --
-構文はRFC 6268からインポートされます-
END
終わり
4.2.4. An Alternative to the Profile for X.509 PKIX Resource Certificates
4.2.4. X.509 PKIXリソース証明書のプロファイルの代替
This document defines an alternative profile for X.509 PKIX Resource Certificates. This profile follows all definitions and procedures described in [RFC6487] with the following notable exceptions.
このドキュメントでは、X.509 PKIXリソース証明書の代替プロファイルを定義しています。このプロファイルは、以下の注目すべき例外を除いて、[RFC6487]で説明されているすべての定義と手順に従います。
The following is an amended specification to be used in this profile, in place of Section 4.8.9 of [RFC6487].
[RFC6487]のセクション4.8.9の代わりに、このプロファイルで使用される修正仕様は次のとおりです。
This extension MUST be present and MUST be marked critical. It MUST include exactly one policy of type id-cp-ipAddr-asNumber-v2, as specified in the updated RPKI CP in Section 4.2.1.
この拡張は存在しなければならず、重要としてマークされていなければなりません。セクション4.2.1の更新されたRPKI CPで指定されているように、id-cp-ipAddr-asNumber-v2タイプのポリシーを1つだけ含める必要があります。
The following is an amended specification to be used in this profile, in place of Section 4.8.10 of [RFC6487].
以下は、[RFC6487]のセクション4.8.10の代わりに、このプロファイルで使用される修正された仕様です。
Either the IP resources extension or the AS resources extension, or both, MUST be present in all RPKI certificates and MUST be marked critical.
IPリソース拡張機能またはASリソース拡張機能のいずれか、あるいはその両方が、すべてのRPKI証明書に存在する必要があり、重要とマークされている必要があります。
This extension contains the list of IP address resources as per Section 4.2.2.1. The value may specify the "inherit" element for a particular Address Family Identifier (AFI) value. In the context of Resource Certificates describing public number resources for use in the public Internet, the Subsequent AFI (SAFI) value MUST NOT be used.
この拡張には、セクション4.2.2.1にあるIPアドレスリソースのリストが含まれています。この値は、特定のアドレスファミリ識別子（AFI）値の「継承」要素を指定する場合があります。公共のインターネットで使用するための公開番号リソースを説明するリソース証明書のコンテキストでは、後続AFI（SAFI）値を使用してはなりません（MUST NOT）。
This extension MUST either specify a non-empty set of IP address records or use the "inherit" setting to indicate that the IP address resource set of this certificate is inherited from that of the certificate's issuer.
この拡張機能は、空でないIPアドレスレコードのセットを指定するか、「継承」設定を使用して、この証明書のIPアドレスリソースセットが証明書の発行者のセットから継承されることを示す必要があります。
The following is an amended specification to be used in this profile, in place of Section 4.8.11 of [RFC6487].
以下は、[RFC6487]のセクション4.8.11の代わりに、このプロファイルで使用される修正された仕様です。
Either the AS resources extension or the IP resources extension, or both, MUST be present in all RPKI certificates and MUST be marked critical.
ASリソース拡張またはIPリソース拡張のいずれか、あるいは両方が、すべてのRPKI証明書に存在しなければならず、クリティカルとしてマークされている必要があります。
This extension contains the list of AS number resources as per Section 4.2.2.3, or it may specify the "inherit" element. Routing Domain Identifier (RDI) values are NOT supported in this profile and MUST NOT be used.
この拡張には、セクション4.2.2.3に従ってAS番号リソースのリストが含まれています。または、「継承」要素を指定する場合があります。ルーティングドメイン識別子（RDI）値はこのプロファイルではサポートされていないため、使用してはなりません（MUST NOT）。
This extension MUST either specify a non-empty set of AS number records or use the "inherit" setting to indicate that the AS number resource set of this certificate is inherited from that of the certificate's issuer.
この拡張は、空でないAS番号レコードのセットを指定するか、「継承」設定を使用して、この証明書のAS番号リソースセットが証明書の発行者のAS番号リソースセットから継承されることを示す必要があります。
The following is an amended specification for path validation to be used in place of Section 7.2 of [RFC6487], which allows for the validation of both certificates following the profile defined in [RFC6487], as well as certificates following the profile described above.
以下は、[RFC6487]のセクション7.2の代わりに使用されるパス検証の修正された仕様です。これにより、[RFC6487]で定義されたプロファイルに従う証明書と、上記のプロファイルに従う証明書の両方の検証が可能になります。
The following algorithm is employed to validate CA and EE resource certificates. It is modeled on the path validation algorithm from [RFC5280] but is modified to make use of the IP Address Delegation and AS Identifier Delegation extensions from [RFC3779].
次のアルゴリズムは、CAおよびEEリソース証明書を検証するために使用されます。 [RFC5280]のパス検証アルゴリズムに基づいてモデル化されていますが、[RFC3779]のIPアドレス委任とAS ID委任拡張を利用するように変更されています。
There are two inputs to the validation algorithm:
検証アルゴリズムには2つの入力があります。
1. a trust anchor
1. トラストアンカー
2. a certificate to be validated
2. 検証する証明書
The algorithm is initialized with two new variables for use in the RPKI: Verified Resource Set-IP (VRS-IP) and Verified Resource Set-AS (VRS-AS). These sets are used to track the set of INRs (IP address space and AS numbers) that are considered valid for each CA certificate. The VRS-IP and VRS-AS sets are initially set to the IP Address Delegation and AS Identifier Delegation values, respectively, from the trust anchor used to perform validation.
アルゴリズムは、RPKIで使用するための2つの新しい変数、検証済みリソースセットIP（VRS-IP）と検証済みリソースセットAS（VRS-AS）で初期化されます。これらのセットは、各CA証明書で有効と見なされるINR（IPアドレス空間とAS番号）のセットを追跡するために使用されます。 VRS-IPおよびVRS-ASセットは、最初に、検証の実行に使用されるトラストアンカーからのIPアドレス委任とAS識別子委任の値にそれぞれ設定されます。
This path validation algorithm verifies, among other things, that a prospective certification path (a sequence of n certificates) satisfies the following conditions:
このパス検証アルゴリズムは、特に、予想される認証パス（n個の証明書のシーケンス）が次の条件を満たすことを確認します。
a. for all 'x' in {1, ..., n-1}, the subject of certificate 'x' is
the issuer of certificate ('x' + 1);
b. certificate '1' is issued by a trust anchor;
b. 証明書「1」はトラストアンカーによって発行されます。
c. certificate 'n' is the certificate to be validated; and
c. 証明書「n」は、検証される証明書です。そして
d. for all 'x' in {1, ..., n}, certificate 'x' is valid.
d. {1、...、n}のすべての 'x'に対して、証明書 'x'は有効です。
Certificate validation requires verifying that all of the following conditions hold, in addition to the certification path validation criteria specified in Section 6 of [RFC5280].
証明書の検証では、[RFC5280]のセクション6で指定されている証明書パス検証基準に加えて、次の条件がすべて満たされていることを検証する必要があります。
1. The signature of certificate x (x>1) is verified using the public key of the issuer's certificate (x-1), using the signature algorithm specified for that public key (in certificate x-1).
1. 証明書x（x> 1）の署名は、発行者の証明書（x-1）の公開鍵を使用して、その公開鍵に指定された署名アルゴリズム（証明書x-1内）を使用して検証されます。
2. The current time lies within the interval defined by the NotBefore and NotAfter values in the Validity field of certificate x.
2. 現在の時刻は、証明書xの有効性フィールドのNotBeforeおよびNotAfter値で定義された間隔内にあります。
3. The Version, Issuer, and Subject fields of certificate x satisfy the constraints established in Sections 4.1 to 4.7 of RFC 6487.
3. 証明書xのバージョン、発行者、および件名フィールドは、RFC 6487のセクション4.1〜4.7で確立された制約を満たします。
4. If certificate x uses the Certificate Policy defined in Section 4.8.9 of [RFC6487], then the certificate MUST contain all extensions defined in Section 4.8 of [RFC6487] that must be present. The value(s) for each of these extensions MUST satisfy the constraints established for each extension in the respective sections. Any extension not thus identified MUST NOT appear in certificate x.
4. 証明書xが[RFC6487]のセクション4.8.9で定義された証明書ポリシーを使用する場合、証明書には、存在する必要のある[RFC6487]のセクション4.8で定義されたすべての拡張機能が含まれている必要があります。これらの拡張のそれぞれの値は、それぞれのセクションで拡張ごとに確立された制約を満たさなければなりません（MUST）。このように識別されていない拡張は、証明書xに表示してはなりません。
5. If certificate x uses the Certificate Policy defined in Section 4.2.4.1, then all extensions defined in Section 4.8 of [RFC6487], except Sections 4.8.9, 4.8.10, and 4.8.11 MUST be present. The certificate MUST contain an extension as defined in Sections 4.2.4.2 or 4.2.4.3, or both. The value(s) for each of these extensions MUST satisfy the constraints established for each extension in the respective sections. Any extension not thus identified MUST NOT appear in certificate x.
5. 証明書xがセクション4.2.4.1で定義された証明書ポリシーを使用する場合、セクション4.8.9、4.8.10、および4.8.11を除く、[RFC6487]のセクション4.8で定義されたすべての拡張が存在しなければなりません。証明書には、セクション4.2.4.2または4.2.4.3、あるいはその両方で定義されている拡張が含まれている必要があります。これらの拡張のそれぞれの値は、それぞれのセクションで拡張ごとに確立された制約を満たさなければなりません（MUST）。このように識別されていない拡張は、証明書xに表示してはなりません。
6. Certificate x MUST NOT have been revoked, i.e., it MUST NOT appear on a Certificate Revocation List (CRL) issued by the CA represented by certificate x-1.
6. 証明書xは失効してはいけません。つまり、証明書x-1で表されるCAによって発行された証明書失効リスト（CRL）に表示されてはいけません。
7. Compute the VRS-IP and VRS-AS set values as indicated below:
7. 以下に示すように、VRS-IPおよびVRS-ASの設定値を計算します。
* If the IP Address Delegation extension is present in certificate x and x=1, set the VRS-IP to the resources found in this extension.
* IPアドレス委任拡張が証明書xとx = 1に存在する場合、VRS-IPをこの拡張で見つかったリソースに設定します。
* If the IP Address Delegation extension is present in certificate x and x>1, set the VRS-IP to the intersection of the resources between this extension and the value of the VRS-IP computed for certificate x-1.
* IPアドレス委任拡張が証明書xとx> 1に存在する場合、この拡張と証明書x-1に対して計算されたVRS-IPの値の間のリソースの共通部分にVRS-IPを設定します。
* If the IP Address Delegation extension is absent in certificate x, set the VRS-IP to NULL.
* 証明書xにIPアドレス委任拡張が存在しない場合は、VRS-IPをNULLに設定します。
* If the IP Address Delegation extension is present in certificate x and x=1, set the VRS-IP to the resources found in this extension.
* IPアドレス委任拡張が証明書xとx = 1に存在する場合、VRS-IPをこの拡張で見つかったリソースに設定します。
* If the AS Identifier Delegation extension is present in certificate x and x>1, set the VRS-AS to the intersection of the resources between this extension and the value of the VRS-AS computed for certificate x-1.
* AS ID委任拡張が証明書xとx> 1に存在する場合、VRS-ASをこの拡張と証明書x-1に対して計算されたVRS-ASの値の間のリソースの共通部分に設定します。
* If the AS Identifier Delegation extension is absent in certificate x, set the VRS-AS to NULL.
* AS ID委任拡張が証明書xにない場合は、VRS-ASをNULLに設定します。
8. If there is any difference in resources in the VRS-IP and the IP Address Delegation extension on certificate x, or the VRS-AS and the AS Identifier Delegation extension on certificate x, then:
8. 証明書xのVRS-IPとIPアドレス委任拡張、または証明書xのVRS-ASとAS ID委任拡張のリソースに違いがある場合、次のようになります。
* If certificate x uses the Certificate Policy defined in Section 4.2.4.1, a warning listing the overclaiming resources for certificate x SHOULD be issued.
* 証明書xがセクション4.2.4.1で定義された証明書ポリシーを使用する場合、証明書xの過剰請求リソースをリストする警告が発行されるべきです（SHOULD）。
* If certificate x uses the Certificate Policy defined in Section 4.8.9 of [RFC6487], then certificate x MUST be rejected.
* 証明書xが[RFC6487]のセクション4.8.9で定義された証明書ポリシーを使用する場合、証明書xは拒否される必要があります。
These rules allow a CA certificate to contain resources that are not present in (all of) the certificates along the path from the trust anchor to the CA certificate. If none of the resources in the CA certificate are present in all certificates along the path, no subordinate certificates could be valid. However, the certificate is not immediately rejected as this may be a transient condition. Not immediately rejecting the certificate does not result in a security problem because the associated VRS sets accurately reflect the resources validly associated with the certificate in question.
これらのルールにより、CA証明書には、トラストアンカーからCA証明書へのパスに沿った証明書（のすべて）には存在しないリソースを含めることができます。パスに沿ったすべての証明書にCA証明書のリソースが存在しない場合、下位の証明書は有効ではありません。ただし、これは一時的な状態である可能性があるため、証明書はすぐには拒否されません。関連付けられているVRSセットは、問題の証明書に有効に関連付けられているリソースを正確に反映しているため、証明書をすぐに拒否しなくてもセキュリティ上の問題は発生しません。
Section 4 of [RFC6482] currently has the following text on the validation of resources on a ROA:
[RFC6482]のセクション4には現在、ROA上のリソースの検証に関する次のテキストがあります。
The IP address delegation extension [RFC3779] is present in the end-entity (EE) certificate (contained within the ROA), and each IP address prefix(es) in the ROA is contained within the set of IP addresses specified by the EE certificate's IP address delegation extension.
IPアドレス委任拡張[RFC3779]は、エンドエンティティ（EE）証明書（ROAに含まれる）に存在し、ROAの各IPアドレスプレフィックスは、EE証明書の証明書で指定されたIPアドレスのセットに含まれますIPアドレス委任拡張。
If the end entity certificate uses the Certificate Policy defined in Section 4.2.4.1, then the following approach must be used instead.
エンドエンティティ証明書がセクション4.2.4.1で定義された証明書ポリシーを使用する場合は、代わりに次のアプローチを使用する必要があります。
The amended IP Address Delegation extension described in Section 4.2.4.2 is present in the end entity (EE) certificate (contained within the ROA), and each IP address prefix(es) in the ROA is contained within the VRS-IP set that is specified as an outcome of EE certificate validation described in Section 4.2.4.4.
セクション4.2.4.2で説明されている修正されたIPアドレス委任拡張は、（ROAに含まれる）エンドエンティティ（EE）証明書に存在し、ROAの各IPアドレスプレフィックスは、次のVRS-IPセットに含まれています。セクション4.2.4.4で説明されているEE証明書検証の結果として指定されます。
Note that this ensures that ROAs can be valid only if all IP address prefixes in the ROA are encompassed by the VRS-IP of all certificates along the path to the trust anchor used to verify it.
これにより、ROA内のすべてのIPアドレスプレフィックスが、検証に使用されるトラストアンカーへのパスに沿ったすべての証明書のVRS-IPに含まれている場合にのみ、ROAが有効になることが保証されます。
Operators MAY issue separate ROAs for each IP address prefix, so that the loss of one or more IP address prefixes from the VRS-IP of any certificate along the path to the trust anchor would not invalidate authorizations for other IP address prefixes.
オペレーターは、IPアドレスプレフィックスごとに個別のROAを発行してもよいため、トラストアンカーへのパスに沿った証明書のVRS-IPから1つ以上のIPアドレスプレフィックスが失われても、他のIPアドレスプレフィックスの承認は無効になりません。
If a BGPsec Router Certificate [RFC8209] uses the Certificate Policy defined in Section 4.2.4.1, then in addition to the BGPsec Router Certificate Validation defined in Section 3.3 of [RFC8209], the following constraint MUST be met:
BGPsecルーター証明書[RFC8209]がセクション4.2.4.1で定義された証明書ポリシーを使用する場合、[RFC8209]のセクション3.3で定義されたBGPsecルーター証明書検証に加えて、次の制約が満たされなければなりません：
o The VRS-AS of BGPsec Router Certificates MUST encompass all Autonomous System Numbers (ASNs) in the AS Resource Identifier Delegation extension.
o BGPsecルーター証明書のVRS-ASは、ASリソース識別子の委任拡張内のすべての自律システム番号（ASN）を含む必要があります。
Operators MAY issue separate BGPsec Router Certificates for different ASNs, so that the loss of an ASN from the VRS-AS of any certificate along the path to the trust anchor would not invalidate router keys for other ASNs.
オペレーターは、異なるASNに対して個別のBGPsecルーター証明書を発行することができるので、トラストアンカーへのパスに沿った証明書のVRS-ASからASNが失われても、他のASNのルーターキーは無効になりません。
In this section, we will demonstrate the outcome of RPKI validation performed using the algorithm and procedures described in Sections 4.2.4.4, 4.2.5, and 4.2.6, under three deployment scenarios:
このセクションでは、セクション4.2.4.4、4.2.5、および4.2.6で説明されているアルゴリズムと手順を使用して実行されたRPKI検証の結果を、3つの展開シナリオで示します。
o An RPKI tree consisting of certificates using the old OIDs only
o 古いOIDのみを使用する証明書で構成されるRPKIツリー
o An RPKI tree consisting of certificates using the new OIDs only
o 新しいOIDのみを使用する証明書で構成されるRPKIツリー
o An RPKI tree consisting of a mix of certificates using either the old or the new OIDs
o 古いOIDまたは新しいOIDのいずれかを使用する証明書の組み合わせで構成されるRPKIツリー
In this context, we refer to a certificate as using the 'old' OIDs, if the certificate uses a combination of the OIDs defined in Section 1.2 of [RFC6484], Section 2.2.1 of [RFC3779], and/or Section 3.2.1 of [RFC3779]. We refer to a certificate as using the 'new' OIDS, if the certificate uses a combination of OIDs defined in Sections 4.2.4.1, 4.2.2.1, and/or Section 4.2.2.3.
このコンテキストでは、証明書が[RFC6484]のセクション1.2、[RFC3779]のセクション2.2.1、またはセクション3.2で定義されたOIDの組み合わせを使用している場合、「古い」OIDを使用していると見なします。 [RFC3779]の1。証明書がセクション4.2.4.1、4.2.2.1、またはセクション4.2.2.3で定義されたOIDの組み合わせを使用する場合、証明書を「新しい」OIDSを使用していると呼びます。
Consider the following example:
次の例について考えてみます。
Certificate 1 (trust anchor):
Issuer: TA,
Subject: TA,
OIDs: OLD,
Resources: 0/0, ::0, AS0-4294967295 (all resources)
Verified Resource Set: 0/0, ::0, AS0-4294967295 (all resources)
Warnings: none
Certificate 2:
Issuer: TA,
Subject: CA1,
OIDs: OLD,
Resources: 192.0.2.0/24, 2001:db8::/32, AS64496
Verified Resource Set: 192.0.2.0/24,
2001:db8::/32, AS64496
Warnings: none
Certificate 3 (invalid):
Issuer: CA1,
Subject: CA2,
OIDs: OLD,
Resources: 192.0.2.0/24, 198.51.100.0/24, AS64496
Verified Resource Set: 192.0.2.0/24, AS64496
検証済みリソースセット：192.0.2.0/24、AS64496
Certificate 3 is considered invalid because resources contains 198.51.100.0/24, which is not found in the Verified Resource Set.
リソースには198.51.100.0/24が含まれているため、証明書3は無効と見なされます。これは、検証済みリソースセットでは見つかりません。
ROA 1 (invalid): Embedded Certificate 4 (EE certificate invalid): Issuer: CA2, Subject: R1, OIDs: OLD, Resources: 192.0.2.0/24 Prefix 192.0.2.0/24, Max Length 24, ASN 64496
ROA 1（無効）：埋め込み証明書4（EE証明書が無効）：発行者：CA2、件名：R1、OID：OLD、リソース：192.0.2.0/24プレフィックス192.0.2.0/24、最大長24、ASN 64496
ROA1 is considered invalid because Certificate 3 is invalid.
証明書3が無効であるため、ROA1は無効と見なされます。
ROA 2 (invalid): Embedded Certificate 5 (EE certificate invalid): Issuer: CA2, Subject: R2, OIDs: OLD, Resources: 198.51.100.0/24 Prefix 198.51.100.0/24, Max Length 24, ASN 64496
ROA 2（無効）：埋め込み証明書5（EE証明書が無効）：発行者：CA2、件名：R2、OID：OLD、リソース：198.51.100.0/24プレフィックス198.51.100.0/24、最大長24、ASN 64496
ROA2 is considered invalid because Certificate 3 is invalid.
証明書3が無効であるため、ROA2は無効と見なされます。
BGPsec Certificate 1 (invalid): Issuer: CA2, Subject: ROUTER-64496, OIDs: NEW, Resources: AS64496
BGPsec証明書1（無効）：発行者：CA2、件名：ROUTER-64496、OID：新規、リソース：AS64496
BGPsec Certificate 1 is invalid because Certificate 3 is invalid.
証明書3が無効であるため、BGPsec証明書1は無効です。
BGPsec Certificate 2 (invalid): Issuer: CA2, Subject: ALL-ROUTERS, OIDs: NEW, Resources: AS64496-AS64497
BGPsec証明書2（無効）：発行者：CA2、件名：ALL-ROUTERS、OID：新規、リソース：AS64496-AS64497
BGPsec Certificate 2 is invalid because Certificate 3 is invalid.
証明書3が無効であるため、BGPsec証明書2は無効です。
Consider the following example under the amended approach:
修正されたアプローチの下で次の例を検討してください。
Certificate 1 (trust anchor):
Issuer: TA,
Subject: TA,
OIDs: NEW,
Resources: 0/0, ::0, AS0-4294967295 (all resources)
Verified Resource Set: 0/0, ::0, AS0-4294967295 (all resources)
Warnings: none
Certificate 2:
Issuer: TA,
Subject: CA1,
OIDs: NEW,
Resources: 192.0.2.0/24, 2001:db8::/32, AS64496
Verified Resource Set: 192.0.2.0/24,
2001:db8::/32, AS64496
Warnings: none
Certificate 3:
Issuer: CA1,
Subject: CA2,
OIDs: NEW,
Resources: 192.0.2.0/24, 198.51.100.0/24, AS64496
Verified Resource Set: 192.0.2.0/24, AS64496
Warnings: overclaim for 198.51.100.0/24
ROA 1 (valid): Embedded Certificate 4 (EE certificate): Issuer: CA2, Subject: R1, OIDs: NEW, Resources: 192.0.2.0/24 Prefix 192.0.2.0/24, Max Length 24, ASN 64496
ROA 1（有効）：埋め込み証明書4（EE証明書）：発行者：CA2、件名：R1、OID：新規、リソース：192.0.2.0/24プレフィックス192.0.2.0/24、最大長24、ASN 64496
Verified Resource Set: 192.0.2.0/24 Warnings: none
検証済みリソースセット：192.0.2.0/24警告：なし
ROA1 is considered valid because the prefix matches the Verified Resource Set on the embedded EE certificate.
ROA1 is considered valid because the prefix matches the Verified Resource Set on the embedded EE certificate.
ROA 2 (invalid): Embedded Certificate 5 (EE certificate invalid): Issuer: CA2, Subject: R2, OIDs: NEW, Resources: 198.51.100.0/24 Prefix 198.51.100.0/24, Max Length 24, ASN 64496
ROA 2（無効）：埋め込み証明書5（EE証明書が無効）：発行者：CA2、件名：R2、OID：新規、リソース：198.51.100.0/24プレフィックス198.51.100.0/24、最大長24、ASN 64496
Verified Resource Set: none (empty set) Warnings: 198.51.100.0/24
検証済みリソースセット：なし（空のセット）警告：198.51.100.0/24
ROA2 is considered invalid because the ROA prefix 198.51.100.0/24 is not contained in the Verified Resource Set.
ROAプレフィックス198.51.100.0/24が検証済みリソースセットに含まれていないため、ROA2は無効と見なされます。
BGPsec Certificate 1 (valid): Issuer: CA2, Subject: ROUTER-64496, OIDs: NEW, Resources: AS64496
BGPsec証明書1（有効）：発行者：CA2、件名：ROUTER-64496、OID：新規、リソース：AS64496
Verified Resource Set: AS64496 Warnings: none
検証済みリソースセット：AS64496警告：なし
BGPsec Certificate 2 (invalid): Issuer: CA2, Subject: ALL-ROUTERS, OIDs: NEW, Resources: AS64496-AS64497
BGPsec証明書2（無効）：発行者：CA2、件名：ALL-ROUTERS、OID：新規、リソース：AS64496-AS64497
Verified Resource Set: AS64496
検証済みリソースセット：AS64496
BGPsec Certificate 2 is invalid because not all of its resources are contained in the Verified Resource Set.
BGPsec Certificate 2 is invalid because not all of its resources are contained in the Verified Resource Set.
Note that this problem can be mitigated by issuing separate certificates for each AS number.
この問題は、AS番号ごとに個別の証明書を発行することで軽減できることに注意してください。
In the following example, new OIDs are used only for CA certificates where the issuing CA anticipates that an overclaim could occur and has a desire to limit the impact of this to just the overclaimed resources in question:
次の例では、新しいOIDはCA証明書に対してのみ使用され、発行CAは過剰請求が発生する可能性があると予測し、この影響を問題の過剰請求されたリソースのみに制限したい場合があります。
Certificate 1 (trust anchor):
Issuer: TA,
Subject: TA,
OIDs: OLD,
Resources: 0/0, ::0, AS0-4294967295 (all resources)
Verified Resource Set: 0/0, ::0, AS0-4294967295 (all resources)
Warnings: none
Note that a trust anchor certificate cannot be found to overclaim. So, using the new OIDs here would not change anything with regards to the validity of this certificate.
トラストアンカー証明書が過剰に要求されていないことに注意してください。したがって、ここで新しいOIDを使用しても、この証明書の有効性に関しては何も変更されません。
Certificate 2:
Issuer: TA,
Subject: CA1,
OIDs: OLD,
Resources: 192.0.2.0/24, 2001:db8::/32, AS64496
Verified Resource Set: 192.0.2.0/24,
2001:db8::/32, AS64496
Warnings: none
Note that since the TA certificate claims all resources, it is impossible to issue a certificate below it that could be found to be overclaiming. Therefore, there is no benefit in using the new OIDs for Certificate 2.
TA証明書はすべてのリソースを要求しているため、過剰に要求されていることが判明した証明書をその下に発行することは不可能であることに注意してください。したがって、証明書2に新しいOIDを使用してもメリットはありません。
Certificate 3:
Issuer: CA1,
Subject: CA2,
OIDs: NEW,
Resources: 192.0.2.0/24, 198.51.100.0/24, AS64496
Verified Resource Set: 192.0.2.0/24, AS64496
Warnings: overclaim for 198.51.100.0/24
Note that CA1 anticipated that it might invalid Certificate 3 issued to CA2, if its own resources on Certificate 2 were modified and old OIDs were used on Certificate 3.
証明書2の独自のリソースが変更され、証明書3で古いOIDが使用された場合、CA1はCA2に発行された証明書3が無効になる可能性があると予想したことに注意してください。
ROA 1 (valid): Embedded Certificate 4 (EE certificate): Issuer: CA2, Subject: R1, OIDs: OLD, Resources: 192.0.2.0/24 Prefix 192.0.2.0/24, Max Length 24, ASN 64496
ROA 1（有効）：埋め込み証明書4（EE証明書）：発行者：CA2、件名：R1、OID：OLD、リソース：192.0.2.0/24プレフィックス192.0.2.0/24、最大長24、ASN 64496
Verified Resource Set: 192.0.2.0/24 Warnings: none
検証済みリソースセット：192.0.2.0/24警告：なし
ROA1 is considered valid because the prefix matches the Verified Resource Set on the embedded EE certificate.
プレフィックスが埋め込みEE証明書の検証済みリソースセットと一致するため、ROA1は有効と見なされます。
ROA 2 (invalid): Embedded Certificate 5 (EE certificate invalid): Issuer: CA2, Subject: R2, OIDs: OLD, Resources: 198.51.100.0/24 Prefix 198.51.100.0/24, Max Length 24, ASN 64496
ROA 2（無効）：埋め込み証明書5（EE証明書が無効）：発行者：CA2、件名：R2、OID：OLD、リソース：198.51.100.0/24プレフィックス198.51.100.0/24、最大長24、ASN 64496
Verified Resource Set: none (empty set)
検証済みリソースセット：なし（空のセット）
ROA2 is considered invalid because resources on its EE certificate contains 198.51.100.0/24, which is not contained in its Verified Resource Set.
EE証明書のリソースには198.51.100.0/24が含まれているため、ROA2は無効と見なされます。これは、検証済みリソースセットには含まれていません。
Note that if new OIDs were used here (as in example 2), ROA 2 would be considered invalid because the prefix is not contained in the Verified Resource Set.
ここで新しいOIDが使用された場合（例2のように）、プレフィックスが検証済みリソースセットに含まれていないため、ROA 2は無効と見なされます。
So, if there is no difference in the validity outcome, one could argue that using old OIDs here is clearest, because any overclaim of ROA prefixes MUST result in it being considered invalid (as described in Section 4.2.5).
したがって、有効性の結果に違いがない場合は、ここで古いOIDを使用するのが最も明確であると主張できます。ROAプレフィックスを過剰に要求すると、無効と見なされるためです（セクション4.2.5で説明）。
BGPsec Certificate 1 (valid): Issuer: CA2, Subject: ROUTER-64496, OIDs: OLD, Resources: AS64496
BGPsec証明書1（有効）：発行者：CA2、件名：ROUTER-64496、OID：OLD、リソース：AS64496
Verified Resource Set: AS64496 Warnings: none
検証済みリソースセット：AS64496警告：なし
BGPsec Certificate 2 (invalid): Issuer: CA2, Subject: ALL-ROUTERS, OIDs: OLD, Resources: AS64496-AS64497
BGPsec証明書2（無効）：発行者：CA2、件名：ALL-ROUTERS、OID：OLD、リソース：AS64496-AS64497
Verified Resource Set: AS64496
検証済みリソースセット：AS64496
BGPsec Certificate 2 is considered invalid because resources contains AS64497, which is not contained in its Verified Resource Set.
検証済みリソースセットに含まれていないAS64497がリソースに含まれているため、BGPsec証明書2は無効と見なされます。
Note that if new OIDs were used here (as in example 2), BGPsec Certificate 2 would be considered invalid because the prefix is not contained in the Verified Resource Set.
ここで（例2のように）新しいOIDが使用された場合、プレフィックスが検証済みリソースセットに含まれていないため、BGPsec証明書2は無効と見なされます。
So, if there is no difference in the validity outcome, one could argue that using old OIDs here is the clearest, because any overclaim on this certificate MUST result in it being considered invalid (as described in Section 4.2.6).
したがって、有効性の結果に違いがない場合は、ここで古いOIDを使用するのが最も明確であると主張できます。これは、この証明書に対する過剰請求により、無効と見なされるためです（セクション4.2.6で説明）。
Also note that, as in example 2, this problem can be mitigated by issuing separate certificates for each AS number.
また、例2のように、この問題は、AS番号ごとに個別の証明書を発行することで軽減できることに注意してください。
This document defines an alternative RPKI validation algorithm, but it does not dictate how this algorithm will be deployed. This should be discussed as a separate effort. That said, the following observations may help this discussion.
このドキュメントでは、代替のRPKI検証アルゴリズムを定義していますが、このアルゴリズムの展開方法については規定していません。これについては、個別の取り組みとして説明する必要があります。とはいえ、以下の観察はこの議論を助けるかもしれません。
Because this document introduces new OIDs and an alternative to the profile for X.509 PKIX Resource Certificates described in [RFC6487], the use of such certificates in the global RPKI will lead to the rejection of such certificates by Relying Party tools that do not (yet) implement the alternative profile described in this document.
このドキュメントでは、[RFC6487]で説明されているX.509 PKIXリソース証明書のプロファイルに代わる新しいOIDと代替案を紹介しているため、グローバルRPKIでそのような証明書を使用すると、そのような証明書は（まだ）このドキュメントで説明されている代替プロファイルを実装します。
For this reason, it is important that such tools are updated before Certification Authorities start to use this specification.
このため、認証局がこの仕様の使用を開始する前に、そのようなツールを更新することが重要です。
However, because the OIDs are defined in each RPKI certificate, there is no strict requirement for all Certification Authorities, or even for all the certificates they issue, to migrate to the new OIDs at the same time. The example in Section 5.3 illustrates a possible deployment where the new OIDs are used only in CA certificates where an accidental overclaim may occur.
ただし、OIDは各RPKI証明書で定義されているため、すべての認証局、またはそれらが発行するすべての証明書に対して、新しいOIDに同時に移行するための厳密な要件はありません。セクション5.3の例は、偶発的な過剰請求が発生する可能性があるCA証明書でのみ新しいOIDが使用される可能性のある配置を示しています。
The authors believe that the revised validation algorithm introduces no new security vulnerabilities into the RPKI, because it cannot lead to any ROA and/or router certificates to be accepted if they contain resources that are not held by the issuer.
著者は、改訂された検証アルゴリズムがRPKIに新しいセキュリティの脆弱性をもたらすことはないと考えています。これは、発行者が保持していないリソースが含まれている場合、ROAやルーター証明書が受け入れられないためです。
IANA has added the following to the "SMI Security for PKIX Certificate Policies" registry:
IANAは、「SMI Security for PKIX Certificate Policies」レジストリに以下を追加しました。
Decimal Description References
10進数の説明の参照
3 id-cp-ipAddr-asNumber-v2 Section 4.2.1
3 id-cp-ipAddr-asNumber-v2セクション4.2.1
IANA has added the following to the "SMI Security for PKIX Certificate Extension" registry:
IANAは、「SMI Security for PKIX Certificate Extension」レジストリに以下を追加しました。
Decimal Description References
10進数の説明の参照
28 id-pe-ipAddrBlocks-v2 Section 4.2.2.1 29 id-pe-autonomousSysIds-v2 Section 4.2.2.3
28 id-pe-ipAddrBlocks-v2セクション4.2.2.1 29 id-pe-autonomousSysIds-v2セクション4.2.2.3
IANA has added the following to the "SMI Security for PKIX Module Identifier" registry:
IANAは、「SMI Security for PKIX Module Identifier」レジストリに以下を追加しました。
Decimal Description References
10進数の説明の参照
90 id-mod-ip-addr-and-as-ident-v2 Section 4.2.2.7 91 id-mod-ip-addr-and-as-ident-2v2 Section 4.2.3
90 id-mod-ip-addr-and-as-ident-v2セクション4.2.2.7 91 id-mod-ip-addr-and-as-ident-2v2セクション4.2.3
[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>。
[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、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[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>。
[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., 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>.
[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>。
[RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests", RFC 8209, DOI 10.17487/RFC8209, September 2017, <https://www.rfc-editor.org/info/rfc8209>.
[RFC8209]レイノルズ、M。、ターナー、S。、およびS.ケント、「BGPsecルーター証明書、証明書失効リスト、および認証要求のプロファイル」、RFC 8209、DOI 10.17487 / RFC8209、2017年9月、<https：/ /www.rfc-editor.org/info/rfc8209>。
[RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)", RFC 6268, DOI 10.17487/RFC6268, July 2011, <https://www.rfc-editor.org/info/rfc6268>.
[RFC6268] Schaad、J。およびS. Turner、「暗号化メッセージ構文（CMS）およびX.509（PKIX）を使用する公開鍵インフラストラクチャのための追加の新しいASN.1モジュール」、RFC 6268、DOI 10.17487 / RFC6268、7月2011、<https://www.rfc-editor.org/info/rfc6268>。
Acknowledgements
謝辞
The authors would like to thank Stephen Kent for reviewing and contributing to this document. We would like to thank Rob Austein for suggesting that separate OIDs should be used to make the behavior of Relying Party tools deterministic, and we would like to thank Russ Housley, Sean Turner, and Tom Petch for their contributions on OID and ASN.1 updates. Finally, we would like to thank Tom Harrison for a general review of this document.
著者は、このドキュメントをレビューして貢献してくれたStephen Kentに感謝します。依存パーティツールの動作を確定的にするために個別のOIDを使用する必要があることを示唆してくれたRob Austeinに感謝します。OIDとASN.1の更新に対する貢献について、Russ Housley、Sean Turner、Tom Petchに感謝します。 。最後に、このドキュメントの一般的なレビューを提供してくれたTom Harrisonに感謝します。
Authors' Addresses
著者のアドレス
Geoff Huston Asia Pacific Network Information Centre 6 Cordelia St South Brisbane, QLD 4101 Australia
Geoff Huston Asia Pacific Network Information Center 6 Cordelia St South Brisbane、QLD 4101 Australia
Phone: +61 7 3858 3100
Email: gih@apnic.net
George Michaelson Asia Pacific Network Information Centre 6 Cordelia St South Brisbane, QLD 4101 Australia
ジョージマイケルソンアジアパシフィックネットワークインフォメーションセンター6 Cordelia St South Brisbane、QLD 4101 Australia
Phone: +61 7 3858 3100
Email: ggm@apnic.net
Carlos M. Martinez Latin American and Caribbean Internet Address Registry Rambla Mexico 6125 Montevideo 11400 Uruguay
カルロスM.マルティネスラテンアメリカおよびカリブ海インターネットアドレスレジストリランブラメキシコ6125モンテビデオ11400ウルグアイ
Phone: +598 2604 2222 Email: carlos@lacnic.net Tim Bruijnzeels RIPE Network Coordination Centre Singel 258 Amsterdam 1016 AB The Netherlands
電話：+598 2604 2222メール：carlos@lacnic.net Tim Bruijnzeels RIPEネットワークコーディネーションセンターSingel 258アムステルダム1016 ABオランダ
Email: tim@ripe.net
Andrew Lee Newton American Registry for Internet Numbers 3635 Concorde Parkway Chantilly, VA 20151 United States of America
Andrew Lee Newton American Registry for Internet Numbers 3635 Concorde Parkway Chantilly、VA 20151アメリカ合衆国
Email: andy@arin.net
Daniel Shaw African Network Information Centre (AFRINIC) 11th Floor, Standard Chartered Tower Cybercity, Ebene Mauritius
ダニエルショーアフリカンネットワークインフォメーションセンター（AFRINIC）11階、スタンダードチャータードタワーサイバーシティ、エベネモーリシャス
Phone: +230 403 51 00
Email: daniel@afrinic.net