Internet Engineering Task Force (IETF)                       J. Snijders
Request for Comments: 9829                                              
Updates: 6487                                                B. Maddison
Category: Standards Track                                     Workonline
ISSN: 2070-1721                                               T. Buehler
                                                                 OpenBSD
                                                               July 2025
        
Handling of Resource Public Key Infrastructure (RPKI) Certificate Revocation List (CRL) Number Extensions
リソースのハンドリング公開キーインフラストラクチャ(RPKI)証明書取消リスト(CRL)番号拡張機能
Abstract
概要

This document revises how the Resource Public Key Infrastructure (RPKI) handles Certificate Revocation List (CRL) Number extensions. This document updates RFC 6487.

このドキュメントは、リソース公開キーインフラストラクチャ(RPKI)が証明書の取り消しリスト(CRL)番号拡張機能をどのように処理するかを修正します。このドキュメントは、RFC 6487を更新します。

Status of This Memo
本文書の位置付け

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.

このドキュメントは、インターネットエンジニアリングタスクフォース(IETF)の製品です。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/rfc9829.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9829で取得できます。

著作権表示

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権(c)2025 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ドキュメント(https://trustee.ietf.org/license-info)に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。

Table of Contents
目次
   1.  Introduction
     1.1.  Requirements Language
     1.2.  Related Work
     1.3.  Changes from RFC 6487
   2.  Summary
   3.  Updates to RFC 6487
     3.1.  Updates to Section 5
     3.2.  Update to Section 7.2
   4.  Operational Considerations
   5.  Security Considerations
   6.  IANA Considerations
   7.  References
     7.1.  Normative References
     7.2.  Informative References
   Acknowledgements
   Authors' Addresses
        
1. Introduction
1. はじめに

Section 5.2.3 of [RFC5280] describes the value of the Certificate Revocation List (CRL) Number extension as a monotonically increasing sequence number, which "allows users to easily determine when a particular CRL supersedes another CRL". In other words, in Public Key Infrastructures (PKIs) in which it is possible for Relying Parties (RPs) to encounter multiple usable CRLs, the CRL Number extension is a means for an RP to determine which CRLs to rely upon.

[RFC5280]のセクション5.2.3では、証明書の取り消しリスト(CRL)拡張の値を単調に増加させるシーケンス番号として説明します。これにより、「特定のCRLが別のCRLに取って代わる時期をユーザーが簡単に判断できます」。言い換えれば、パーティー(RPS)が複数の使用可能なCRLに遭遇することが可能である公開キーインフラストラクチャ(PKI)では、CRL番号拡張はRPがどのCRLに依存するかを決定する手段です。

In the Resource Public Key Infrastructure (RPKI), a well-formed manifest fileList contains exactly one entry for its associated CRL, together with a collision-resistant message digest of that CRL's contents (see Section 2.2 of [RFC6481] and Section 2 of [RFC9286]). Additionally, the target of the CRL Distribution Points extension in an RPKI Resource Certificate is the same CRL object listed on the issuing Certification Authorities (CAs) current manifest (see Section 4.8.6 of [RFC6487]). Together, these properties guarantee that RPKI RPs will always be able to unambiguously identify exactly one current CRL for each RPKI CA. Thus, in the RPKI, the ordering functionality provided by CRL Numbers is fully subsumed by monotonically increasing manifest numbers (Section 4.2.1 of [RFC9286]), thereby obviating the need for RPKI RPs to process CRL Number extensions at all.

リソース公開キーインフラストラクチャ(RPKI)では、適切に形成されたマニフェストフィルリストには、関連するCRLの1つのエントリが含まれ、そのCRLの内容の衝突耐性メッセージダイジェスト([RFC6481]のセクション2.2を参照)および[RFC9286]のセクション2を参照)。さらに、RPKIリソース証明書のCRL配布ポイント拡張のターゲットは、発行認証当局(CAS)の現在のマニフェストにリストされているCRLオブジェクトと同じです([RFC6487]のセクション4.8.6を参照)。合わせて、これらのプロパティは、RPKI RPSが常にRPKI CAに常に1つの現在のCRLを明確に識別できることを保証します。したがって、RPKIでは、CRL番号によって提供される順序機能は、単調にマニフェスト数を増加させることによって完全に包含されます([RFC9286]のセクション4.2.1)。

Therefore, although the CRL Number extension is mandatory in RPKI CRLs for compliance with the X.509 v2 CRL Profile (Section 5 of [RFC5280]), any use of this extension by RPKI RPs merely adds complexity and fragility to RPKI Resource Certificate path validation. This document mandates that RPKI RPs ignore the CRL Number extension.

したがって、X.509 V2 CRLプロファイル([RFC5280]のセクション5)に準拠するために、RPKI CRLSではCRL番号拡張が必須ですが、RPKI RPSによるこの拡張機能を使用すると、RPKIリソース証明書パスパスの検証に複雑さと脆弱性が追加されます。このドキュメントは、RPKI RPSがCRL番号拡張を無視することを義務付けています。

This document updates [RFC6487]. Refer to Section 3 for more details.

このドキュメントは[RFC6487]を更新します。詳細については、セクション3を参照してください。

1.1. Requirements Language
1.1. 要件言語

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] で説明されているように解釈されます。

1.2. 関連作業

The reader is assumed to be familiar with the terms and concepts described in "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280], "A Profile for Resource Certificate Repository Structure" [RFC6481], and "Manifests for the Resource Public Key Infrastructure (RPKI)" [RFC9286].

読者は、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト(CRL)プロファイル」[RFC5280]、「RFC6481] [RFC6481]、および「RPKI)のマニフェスト(RPKI)」[RFC9286]に記載されている用語と概念に精通していると想定されています。

1.3. Changes from RFC 6487
1.3. RFC 6487からの変更

This section summarizes the significant changes between [RFC6487] and this document.

このセクションでは、[RFC6487]とこのドキュメントの間の重要な変化をまとめたものです。

* Revision of CRL Number handling.

* CRL番号処理の改訂。

* Adjustment of step 5 of the Resource Certification Path Validation.

* リソース認証パス検証のステップ5の調整。

* Integration of Errata 3205 [Err3205].

* ERRATA 3205の統合[ERR3205]。

2. Summary
2. まとめ

This document clarifies that, in the RPKI, there is exactly one CRL that is appropriate and relevant for determining the revocation status of a given resource certificate. It is the unique CRL object that is simultaneously:

このドキュメントは、RPKIには、特定のリソース証明書の取消ステータスを決定するのに適切かつ関連するCRLが1つあることを明確にしています。同時に同時にあるユニークなCRLオブジェクトです。

* the target of the certificate's CRL Distribution Points extension, and

* 証明書のCRL配布ポイント拡張の目標、および

* listed in the issuing CA's current manifest fileList and has a matching hash (see Section 4.2.1 of [RFC9286]).

* 発行中のCAの現在のマニフェストフィルリストにリストされており、一致するハッシュがあります([RFC9286]のセクション4.2.1を参照)。

In particular, a resource certificate cannot be validated without consulting the current manifest of the certificate's issuer.

特に、証明書の発行者の現在のマニフェストに相談せずにリソース証明書を検証することはできません。

3. Updates to RFC 6487
3. RFC 6487の更新
3.1. Updates to Section 5
3.1. セクション5の更新

This section updates Section 5 of [RFC6487] as follows:

このセクションは、[RFC6487]のセクション5を次のように更新します。

* First change:

* 最初の変更:

OLD

古い

* Where two or more CRLs are issued by the same CA, the CRL with the highest value of the "CRL Number" field supersedes all other CRLs issued by this CA.

* 2つ以上のCRLが同じCAによって発行される場合、「CRL番号」フィールドの最高値を持つCRLは、このCAによって発行された他のすべてのCRLに取って代わります。

NEW

新しい

* Per Section 5.2.3 of [RFC5280], CAs issue new CRLs using a monotonically increasing sequence number in the "CRL Number" extension. It is RECOMMENDED that the "CRL Number" match the "manifestNumber" of the manifest that will include this CRL (see Section 4.2.1 of [RFC9286]).

* [RFC5280]のセクション5.2.3ごとに、CASは「CRL番号」拡張機能で単調に増加するシーケンス番号を使用して新しいCRLを発行します。「CRL番号」は、このCRLを含むマニフェストの「マニフェストナンバー」と一致することをお勧めします([RFC9286]のセクション4.2.1を参照)。

* Second change:

* 2番目の変更:

OLD

古い

* An RPKI CA MUST include the two extensions, Authority Key Identifier and CRL Number, in every CRL that it issues. RPs MUST be prepared to process CRLs with these extensions. No other CRL extensions are allowed.

* RPKI CAには、発行するすべてのCRLに、Authority Key IdentifierとCRL番号の2つの拡張機能を含める必要があります。これらの拡張機能でCRLを処理するためにRPSを準備する必要があります。他のCRL拡張機能は許可されていません。

NEW

新しい

* An RPKI CA MUST include exactly two extensions in every CRL that it issues: an Authority Key Identifier (AKI) and a CRL Number. No other CRL extensions are allowed.

* RPKI CAには、問題のあるすべてのCRLに正確に2つの拡張機能を含める必要があります。権限キー識別子(AKI)とCRL番号です。他のCRL拡張機能は許可されていません。

- RPs MUST process the AKI extension.

- RPSはAKI拡張機能を処理する必要があります。

- RPs MUST ignore the CRL Number extension except for checking that it is marked as non-critical and contains a non-negative integer less than or equal to 2^159-1.

- RPSは、非批判的であるとマークされており、非陰性整数が2^159-1以下であることを確認することを除き、CRL番号拡張を無視する必要があります。

3.2. Update to Section 7.2
3.2. セクション7.2に更新します

This section updates Section 7.2 of [RFC6487] as follows:

このセクションは、[RFC6487]のセクション7.2を次のように更新します。

OLD

古い

5. The issuer has not revoked the certificate. A revoked certificate is identified by the certificate's serial number being listed on the issuer's current CRL, as identified by the CRLDP of the certificate, the CRL is itself valid, and the public key used to verify the signature on the CRL is the same public key used to verify the certificate itself.

5. 発行者は証明書を取り消していません。取り消された証明書は、証明書の現在のCRLに記載されている証明書のシリアル番号によって識別されます。これは、証明書のCRLDPで識別されるように、CRL自体が有効であり、CRLの署名を検証するために使用される公開キーは、証明書自体を確認するために使用される公開キーと同じです。

NEW

新しい

5. The issuer has not revoked the certificate. A revoked certificate is identified by the certificate's serial number being listed on the issuer's current CRL, as identified by the issuer's current manifest and the CRLDP of the certificate. The CRL is itself valid and the public key used to verify the signature on the CRL is the same public key used to verify the certificate itself.

5. 発行者は証明書を取り消していません。発行者の現在のマニフェストと証明書のCRLDPによって識別されるように、発行者の現在のCRLに記載されている証明書のシリアル番号によって取り消された証明書が特定されます。CRL自体が有効であり、CRLの署名を確認するために使用される公開キーは、証明書自体を確認するために使用される一般のキーと同じです。

4. Operational Considerations
4. 運用上の考慮事項

This document has no additional operational considerations beyond those described in Section 9 of [RFC6487].

このドキュメントには、[RFC6487]のセクション9で説明されているものを超えた追加の運用上の考慮事項はありません。

5. Security Considerations
5. セキュリティに関する考慮事項

The Security Considerations of [RFC3779], [RFC5280], and [RFC6487] apply to Resource Certificates and CRLs.

[RFC3779]、[RFC5280]、および[RFC6487]のセキュリティ上の考慮事項は、リソース証明書とCRLに適用されます。

This document explicates that, in the RPKI, the CRL listed on the certificate issuer's current manifest is the one relevant and appropriate for determining the revocation status of a resource certificate. The hash in the manifest's fileList provides a cryptographic guarantee on the Certification Authority's intent that this is the most recent CRL and removes possible replay vectors.

この文書は、RPKIでは、証明書発行者の現在のマニフェストにリストされているCRLが、リソース証明書の取消ステータスを決定するのに適切で適切なものであることを説明しています。マニフェストのフィルリストのハッシュは、これが最新のCRLであり、可能なリプレイベクターを削除するという認証機関の意図に関する暗号化保証を提供します。

6. IANA Considerations
6. IANAの考慮事項

This document has no IANA actions.

このドキュメントにはIANAアクションがありません。

7. References
7. 参考文献
7.1. Normative References
7.1. 引用文献
   [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>.
        
   [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>.
        
   [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>.
        
   [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>.
        
7.2. Informative References
7.2. 参考引用
   [Err3205]  RFC Errata, Erratum ID 3205, RFC 6487,
              <https://www.rfc-editor.org/errata/eid3205>.
        
   [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>.
        
   [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>.
        
Acknowledgements
謝辞

The authors wish to thank Tom Harrison whose observations prompted this document, Alberto Leiva, Tim Bruijnzeels, Mohamed Boucadair, Geoff Huston, and the IESG for their valuable comments and feedback.

著者は、この文書、アルベルト・レヴァ、ティム・ブルージュンゼル、モハメド・ブーカデア、ジェフ・ヒューストン、およびIESGの貴重なコメントとフィードバックを促したトム・ハリソンに感謝したいと考えています。

Authors' Addresses
著者のアドレス
   Job Snijders
   Amsterdam
   The Netherlands
   Email: job@sobornost.net
        
   Ben Maddison
   Workonline
   Cape Town
   South Africa
   Email: benm@workonline.africa
        
   Theo Buehler
   OpenBSD
   Switzerland
   Email: tb@openbsd.org