[要約] RFC 9981は、リソース公開キー基盤（RPKI）の署名付きオブジェクトであるマニフェストにおいて、マニフェスト番号が最大値に達した際の発行者および証明書利用者の挙動を規定した標準化文書です。従来のRFC 9286では考慮されていなかったエッジケースへの対処法を明確にし、動作の一貫性を保証します。
Internet Engineering Task Force (IETF) T. Harrison
Request for Comments: 9981 G. Michaelson
Updates: 9286 APNIC
Category: Standards Track J. Snijders
ISSN: 2070-1721 BSD
May 2026
The Resource Public Key Infrastructure (RPKI) makes use of signed objects called "manifests", each of which includes a "manifest number". This document updates RFC 9286 by specifying issuer and Relying Party (RP) behaviour when a manifest number reaches the largest possible value, a situation not considered in RFC 9286.
リソース公開キー基盤 (RPKI) は、「マニフェスト」と呼ばれる署名付きオブジェクトを利用します。各オブジェクトには「マニフェスト番号」が含まれています。この文書は、マニフェスト番号が考えられる最大値に達したときの発行者と証明書利用者 (RP) の動作を指定することにより、RFC 9286 を更新します。この状況は RFC 9286 では考慮されていません。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
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.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc9981.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9981 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. Requirements Language
2. Manifest Number Handling
3. Manifest Filenames
4. Manifest SIA Verification
5. Comparison with RFC 8488
6. General Repository Handling
7. Operational Considerations
8. Security Considerations
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Acknowledgements
Authors' Addresses
The Resource Public Key Infrastructure (RPKI) [RFC6480] makes use of signed objects [RFC6488] called "manifests" [RFC9286]. A manifest lists each file that an issuer intends to include within an RPKI repository [RFC6481]. Manifests can also be used to detect certain forms of attack against a repository. Manifests include a "manifest number" (manifestNumber), which an issuer must increment by one whenever it issues a new manifest, and Relying Parties (RPs) are required to verify that a newly retrieved manifest for a given Certification Authority (CA) has a higher manifestNumber than the previously validated manifest (Section 4.2.1 of [RFC9286]).
リソース公開鍵基盤 (RPKI) [RFC6480] は、「マニフェスト」[RFC9286] と呼ばれる署名付きオブジェクト [RFC6488] を利用します。マニフェストには、発行者が RPKI リポジトリ [RFC6481] 内に含める予定の各ファイルがリストされます。マニフェストを使用して、リポジトリに対する特定の形式の攻撃を検出することもできます。マニフェストには「マニフェスト番号」(manifestNumber) が含まれており、発行者は新しいマニフェストを発行するたびにこの番号を 1 ずつ増分する必要があり、依存当事者 (RP) は、特定の証明機関 (CA) の新しく取得したマニフェストのマニフェスト番号が以前に検証されたマニフェストよりも大きいことを検証する必要があります ([RFC9286] のセクション 4.2.1)。
However, the manifestNumber field is 20 octets in length (i.e., bounded), and no behaviour is specified for when a manifestNumber reaches the largest possible value (2^159-1). When that value is reached, some RP implementations will accept a new manifest for the CA only once the current manifest has expired, while others will not accept a new manifest at all.
ただし、manifestNumber フィールドの長さは 20 オクテット (つまり、制限されている) であり、manifestNumber が可能な最大値 (2^159-1) に達したときの動作は指定されていません。この値に達すると、一部の RP 実装は現在のマニフェストの有効期限が切れた場合にのみ CA の新しいマニフェストを受け入れますが、他の実装は新しいマニフェストをまったく受け入れません。
While it is practically impossible for an issuer to reach the largest possible value under normal operating conditions (it would require that the issuer issue one manifest per second for 23,171,956,451,847,141,650,870 quintillion years), there is still a chance that it could be reached due to bugs in the issuance or publication systems or incorrect/inadvertent use of those systems. For example:
通常の動作条件下で発行者が可能な最大値に到達することは事実上不可能ですが (発行者は 23,171,956,451,847,141,650,870 京年間、1 秒あたり 1 つのマニフェストを発行する必要があります)、発行システムや公開システムのバグ、またはそれらのシステムの誤った/不注意な使用により、この値に到達する可能性はまだあります。例えば：
* Incrementing by large values when issuing manifests, such that the time to reach that largest value is reduced.
* マニフェストの発行時に大きな値ずつ増加するため、最大値に到達するまでの時間が短縮されます。
* Reissuing new manifests in an infinite delay-free loop, such that the manifestNumber increases by a large value in a comparatively short period of time.
* 遅延のない無限ループで新しいマニフェストを再発行すると、manifestNumber が比較的短期間で大きな値だけ増加します。
* Inadvertently setting the manifestNumber to the largest possible value, such that the issuer will no longer be able to publish usable manifests for that repository.
* 誤って、manifestNumber を可能な限り最大の値に設定すると、発行者はそのリポジトリで使用可能なマニフェストを公開できなくなります。
These scenarios might also arise in combination and be more severe as a result. For example, a CA might increase the manifestNumber by a large value on reissuance and also reissue the manifest more frequently than is necessary.
これらのシナリオは組み合わせて発生し、結果としてより深刻になる可能性もあります。たとえば、CA は再発行時に、manifestNumber を大きな値だけ増加させたり、マニフェストを必要以上に頻繁に再発行したりする可能性があります。
For a subordinate CA, the risk of repository invalidation due to such a problem can be addressed by the issuer using the key rollover process [RFC6489] to get a new CA certificate. RPs will treat this new certificate as though it represents a distinct CA; the manifestNumber can be reset at that point.
下位 CA の場合、このような問題によるリポジトリの無効化のリスクは、発行者がキー ロールオーバー プロセス [RFC6489] を使用して新しい CA 証明書を取得することで対処できます。RP は、この新しい証明書を別個の CA を表すかのように扱います。その時点で、manifestNumber をリセットできます。
However, this option is not available for RPKI Trust Anchors (TAs). If a TA publishes a manifest with the largest-possible manifestNumber value, then it is difficult to rely on the TA after that point, since (as described previously) some RPs will not accept a new manifest until the current one has expired, while others will reject all new manifests indefinitely. Particularly in the case of TAs, the manifest validity period may be quite long, too. Issuing a new TA and distributing the associated Trust Anchor Locator (TAL) [RFC8630] to clients would involve a large amount of work for TA operators and RPs. Additionally, depending on the RP implementation being used, there would be a limited degree of RPKI protection by way of that TA for the time between the issuance of the problematic manifest and the installation of the new TAL.
ただし、このオプションは RPKI トラスト アンカー (TA) では使用できません。TA が可能な限り最大の ManifestNumber 値を持つマニフェストを公開した場合、その時点以降は TA に依存することは困難になります。これは、(前述したように) 一部の RP は現在のマニフェストの有効期限が切れるまで新しいマニフェストを受け入れず、他の RP はすべての新しいマニフェストを無期限に拒否するためです。特に TA の場合、マニフェストの有効期間も非常に長い場合があります。新しい TA を発行し、関連するトラスト アンカー ロケーター (TAL) [RFC8630] をクライアントに配布するには、TA オペレーターと RP にとって多大な作業が必要になります。さらに、使用されている RP 実装によっては、問題のあるマニフェストの発行から新しい TAL のインストールまでの間、その TA による RPKI 保護の程度が限定的になります。
In order to avoid these problems, this document updates [RFC9286] by defining how issuers and RPs can handle this scenario in order to facilitate ongoing use of an affected repository.
これらの問題を回避するために、この文書では、影響を受けるリポジトリの継続的な使用を容易にするために、発行者と RP がこのシナリオを処理する方法を定義することにより [RFC9286] を更新します。
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] で説明されているように解釈されます。
For a given CA, an RP MUST NOT reject a new manifest issued by that CA on the basis of it not having a higher manifestNumber than a previously validated manifest if the new manifest has a different filename from that of the previously validated manifest. In other words, an RP has to reset its stored manifestNumber for a given CA if the CA changes the filename of its manifest. This is an update to the requirements set out in Section 4.2.1 of [RFC9286].
特定の CA について、新しいマニフェストのファイル名が以前に検証されたマニフェストのファイル名と異なる場合、RP は、その CA によって発行された新しいマニフェストを、以前に検証されたマニフェストよりも大きいマニフェスト番号を持たないという理由で拒否してはなりません (MUST NOT)。言い換えれば、CA がマニフェストのファイル名を変更した場合、RP は特定の CA の保存されているマニフェスト番号をリセットする必要があります。これは、[RFC9286] のセクション 4.2.1 に規定されている要件の更新です。
With this behaviour, it is possible for a CA to be configured such that, any time it issues a new manifest, it uses a new filename for that manifest. If a CA were configured in this way, the manifestNumber validation set out in Section 4.2.1 of [RFC9286] would have no purpose. To avoid this outcome, CAs SHOULD NOT use new filenames for manifests except in situations where such a change is necessary to address the invalidity problem described in this document. Similarly, an RP MUST alert its operators when a manifest filename changes for a given CA.
この動作により、新しいマニフェストを発行するたびに、そのマニフェストに新しいファイル名を使用するように CA を構成することが可能になります。CA がこのように設定されている場合、[RFC9286] のセクション 4.2.1 に規定されているマニフェスト番号の検証は無意味になります。この結果を避けるために、CA は、この文書で説明されている無効性の問題に対処するためにそのような変更が必要な場合を除き、マニフェストに新しいファイル名を使用すべきではありません。同様に、RP は、特定の CA のマニフェスト ファイル名が変更された場合に、オペレータに警告しなければなりません (MUST)。
[RFC9286] requires that RPs perform two replay-related checks on newly retrieved manifests:
[RFC9286] では、RP が新しく取得したマニフェストに対して 2 つのリプレイ関連のチェックを実行することを要求しています。
1. Check that the purported new manifest has a greater manifestNumber than the cached manifest, and
1. 新しいマニフェストと称されるもののマニフェスト番号がキャッシュされたマニフェストよりも大きいことを確認し、
2. Check that the purported new manifest has a more recent thisUpdate than the cached manifest.
2. 新しいマニフェストと称するものに、キャッシュされたマニフェストよりも新しい thisUpdate があることを確認してください。
An RP that implements the behaviour in this section will momentarily omit the manifestNumber check following a manifest filename change. So long as the RP still performs the second check described above, it will be protected against replay attacks.
このセクションの動作を実装する RP は、マニフェスト ファイル名の変更に続いて、manifestNumber チェックを一時的に省略します。RP が上記の 2 番目のチェックを実行している限り、RP はリプレイ攻撃から保護されます。
A CA specifies its manifest URI by way of a Subject Information Access (SIA) entry with an accessMethod of id-ad-rpkiManifest (Section 4.8.8.1 of [RFC6487]). For the purposes of this document, the manifest filename is the final segment of the path of the accessLocation URI from that SIA entry.
CA は、id-ad-rpkiManifest の accessMethod を持つ Subject Information Access (SIA) エントリを介してマニフェスト URI を指定します ([RFC6487] のセクション 4.8.8.1)。このドキュメントの目的では、マニフェスト ファイル名は、その SIA エントリからの accessLocation URI のパスの最後のセグメントです。
Section 4.8.8.1 of [RFC6487] states that a CA may include in its certificate multiple id-ad-rpkiManifest SIA entries. For comparisons, an RP may use the filename from any one of the id-ad-rpkiManifest SIA entries in the previously validated CA certificate. If that filename does not appear in any of the id-ad-rpkiManifest SIA entries in the CA certificate that is currently being validated, then the manifest filename has changed for the purposes of this document.
[RFC6487] のセクション 4.8.8.1 には、CA がその証明書に複数の id-ad-rpkiManifest SIA エントリを含めることができると記載されています。比較のために、RP は、以前に検証された CA 証明書内の id-ad-rpkiManifest SIA エントリのいずれかのファイル名を使用できます。現在検証中の CA 証明書の id-ad-rpkiManifest SIA エントリのいずれにもそのファイル名が表示されない場合、マニフェスト ファイル名はこのドキュメントの目的のために変更されています。
The corollary of the behaviour defined in the previous paragraph is that a CA that includes multiple id-ad-rpkiManifest SIA entries in its certificate and wants to rely on the behaviour defined in this document MUST ensure that none of the manifest filenames in the previous CA certificate appear in the newly issued CA certificate. If one of the manifest filenames from the previous CA certificate appears in the newly issued CA certificate, then an RP that is using that manifest filename for comparisons will determine that the manifest filename for the CA has not changed and will therefore not reset its stored manifestNumber for the CA.
前の段落で定義された動作の結果として、証明書に複数の id-ad-rpkiManifest SIA エントリが含まれており、この文書で定義された動作に依存したい CA は、以前の CA 証明書のマニフェスト ファイル名が新しく発行された CA 証明書に表示されないようにする必要があります。以前の CA 証明書のマニフェスト ファイル名の 1 つが新しく発行された CA 証明書に表示される場合、そのマニフェスト ファイル名を比較に使用している RP は、CA のマニフェスト ファイル名が変更されていないと判断し、そのため CA に保存されているマニフェスト番号をリセットしません。
To avoid certain forms of replay attack, RPs MUST verify that the URI in the accessLocation in one of the id-ad-signedObject accessMethod instances in the manifest's SIA extension exactly matches the URI presented in the RPKI Repository Delta Protocol (RRDP) [RFC8182] "publish" element or the path presented by remote rsync servers. If this verification check is unsuccessful, then the fetch has failed, and the RP MUST proceed per Section 6.6 of [RFC9286].
特定の形式のリプレイ攻撃を回避するために、RP は、マニフェストの SIA 拡張にある id-ad-signedObject accessMethod インスタンスの 1 つの accessLocation の URI が、RPKI リポジトリ デルタ プロトコル (RRDP) [RFC8182] の「publish」要素で示される URI、またはリモート rsync サーバーによって示されるパスと正確に一致することを確認しなければなりません (MUST)。この検証チェックが失敗した場合、フェッチは失敗しており、RP は [RFC9286] のセクション 6.6 に従って続行しなければなりません (MUST)。
Section 3.2.1 of [RFC8488] describes a manifest-selection approach for RPs that involves collecting all unexpired valid manifests for a CA and then selecting from that collection the manifest that has the highest manifestNumber. The approach set out in this document is different from that approach.
[RFC8488] のセクション 3.2.1 では、CA の有効期限が切れていない有効なマニフェストをすべて収集し、そのコレクションから最も高いマニフェスト番号を持つマニフェストを選択する、RP のマニフェスト選択アプローチについて説明しています。この文書で説明されているアプローチは、そのアプローチとは異なります。
Section 2 contains a specific update to [RFC9286] for the handling of manifest numbers, in order to address one potential permanent invalidity scenario. RPs that encounter other permanent invalidity scenarios should also consider how those can be addressed such that the scenario does not require the relevant CA or TA to perform a key rollover operation. For example, in the event that an RP recognises that a permanent invalidity scenario has occurred, the RP could alert the operator and provide an option to the operator to stop relying on cached data for the affected repository so that the CA can rectify the problem.
セクション 2 には、潜在的な永久無効シナリオの 1 つに対処するために、マニフェスト番号の処理に関する [RFC9286] の特定の更新が含まれています。他の永続的無効シナリオに遭遇した RP は、そのシナリオで関連する CA または TA がキー ロールオーバー操作を実行する必要がないように、それらのシナリオにどのように対処できるかを検討する必要もあります。たとえば、永久無効シナリオが発生したことを RP が認識した場合、RP はオペレータに警告し、CA が問題を修正できるように、影響を受けるリポジトリのキャッシュ データへの依存を停止するオプションをオペレータに提供できます。
CA software may opt to support the manifest number reset functionality in various ways. For example, it could change the manifest filename when the manifestNumber reaches a certain threshold, or it could alert the operator in this scenario and request confirmation that the filename should be changed.
CA ソフトウェアは、さまざまな方法でマニフェスト番号リセット機能をサポートすることを選択する場合があります。たとえば、manifestNumber が特定のしきい値に達したときにマニフェスト ファイル名を変更したり、このシナリオではオペレータに警告を発してファイル名を変更する必要があるかどうかの確認を要求したりできます。
The RPKI primarily exists to support and improve security of the global Internet routing system. Reliability improvements to the RPKI itself, such as outlined in this document, strengthen its dependability (see Section 8 of [RFC6480]).
RPKI は主に、グローバル インターネット ルーティング システムのセキュリティをサポートおよび向上させるために存在します。この文書で概説されているような RPKI 自体の信頼性の向上により、その信頼性が強化されます ([RFC6480] のセクション 8 を参照)。
See Section 2, Paragraph 3 regarding the effect of skipping the manifestNumber check with respect to replay attacks. To protect against replay attacks in the absence of this check, RPs should ensure that they are verifying the thisUpdate value per the requirements of [RFC9286].
リプレイ攻撃に関するマニフェスト番号チェックをスキップした場合の影響については、セクション 2、段落 3 を参照してください。このチェックがない場合のリプレイ攻撃から保護するために、RP は [RFC9286] の要件に従って thisUpdate 値を検証していることを確認する必要があります。
Section 4 describes an additional protection against certain forms of replay attack.
セクション 4 では、特定の形式のリプレイ攻撃に対する追加の保護について説明します。
Although this document updates [RFC9286], the security considerations from [RFC9286] remain relevant.
この文書は [RFC9286] を更新していますが、[RFC9286] のセキュリティに関する考慮事項は依然として関連しています。
This document has no IANA actions.
この文書には 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>.
[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>.
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object
Template for the Resource Public Key Infrastructure
(RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
<https://www.rfc-editor.org/info/rfc6488>.
[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>.
[RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
"The RPKI Repository Delta Protocol (RRDP)", RFC 8182,
DOI 10.17487/RFC8182, July 2017,
<https://www.rfc-editor.org/info/rfc8182>.
[RFC9286] Austein, R., Huston, G., Kent, S., and M. Lepinski,
"Manifests for the Resource Public Key Infrastructure
(RPKI)", RFC 9286, DOI 10.17487/RFC9286, June 2022,
<https://www.rfc-editor.org/info/rfc9286>.
[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>.
[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>.
[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification
Authority (CA) Key Rollover in the Resource Public Key
Infrastructure (RPKI)", BCP 174, RFC 6489,
DOI 10.17487/RFC6489, February 2012,
<https://www.rfc-editor.org/info/rfc6489>.
[RFC8488] Muravskiy, O. and T. Bruijnzeels, "RIPE NCC's
Implementation of Resource Public Key Infrastructure
(RPKI) Certificate Tree Validation", RFC 8488,
DOI 10.17487/RFC8488, December 2018,
<https://www.rfc-editor.org/info/rfc8488>.
[RFC8630] Huston, G., Weiler, S., Michaelson, G., Kent, S., and T.
Bruijnzeels, "Resource Public Key Infrastructure (RPKI)
Trust Anchor Locator", RFC 8630, DOI 10.17487/RFC8630,
August 2019, <https://www.rfc-editor.org/info/rfc8630>.
The authors would like to thank Theo Buehler, Ben Maddison, Rob Austein, Tim Bruijnzeels, Russ Housley, Mohamed Boucadair, Luigi Iannone, Daniele Ceccarelli, Darren Dukes, Maria Ines Robles, Barry Leiba, Éric Vyncke, Gorry Fairhurst, Andy Newton, Roman Danyliw, Mike Bishop, and Deb Cooley for their review and feedback on this document.
著者らは、Theo Buehler、Ben Maddison、Rob Ausstein、Tim Bruijnzeels、Russ Housley、Mohamed Boucadair、Luigi Iannone、Daniele Ceccarelli、Darren Dukes、Maria Ines Robles、Barry Leiba、Éric Vyncke、Gorry Fairhurst、Andy Newton、Roman Danyliw、Mike Bishop、およびDeb Cooley に、このドキュメントに関するレビューとフィードバックをいただきました。
Tom Harrison
Asia Pacific Network Information Centre
6 Cordelia St
South Brisbane QLD 4101
Australia
Email: tomh@apnic.net
George G. Michaelson
Asia-Pacific Network Information Centre
6 Cordelia St
South Brisbane QLD 4101
Australia
Email: ggm@apnic.net
Job Snijders
BSD Software Development
Amsterdam
The Netherlands
Email: job@bsd.nl
URI: https://www.bsd.nl