Internet Engineering Task Force (IETF) D. Benjamin
Request for Comments: 9618 Google LLC
Updates: 5280 August 2024
Category: Standards Track
ISSN: 2070-1721
This document updates RFC 5280 to replace the algorithm for X.509 policy validation with an equivalent, more efficient algorithm. The original algorithm built a structure that scaled exponentially in the worst case, leaving implementations vulnerable to denial-of-service attacks.
このドキュメントは、RFC 5280を更新して、X.509ポリシー検証のアルゴリズムを同等の効率的なアルゴリズムに置き換えます。元のアルゴリズムは、最悪の場合に指数関数的にスケーリングされる構造を構築し、実装をサービス拒否攻撃に対して脆弱にしました。
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/rfc9618.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9618で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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ライセンステキストを含める必要があります。
1. Introduction
1.1. Summary of Changes from RFC 5280
2. Conventions and Definitions
3. Denial-of-Service Vulnerability
3.1. Policy Trees
3.2. Exponential Growth
3.3. Attack Vector
4. Avoiding Exponential Growth
4.1. Policy Graphs
4.2. Verification Outputs
5. Updates to RFC 5280
5.1. Updates to Section 6.1
5.2. Updates to Section 6.1.2
5.3. Updates to Section 6.1.3
5.4. Updates to Section 6.1.4
5.5. Updates to Section 6.1.5
5.6. Updates to Section 6.1.6
6. Other Mitigations
6.1. Verify Signatures First
6.2. Limit Certificate Depth
6.3. Limit Policy Tree Size
6.4. Inhibit Policy Mapping
6.5. Disable Policy Checking
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Author's Address
[RFC5280] defines a suite of extensions for determining the policies that apply to a certification path. A policy is described by an object identifier (OID) and a set of optional qualifiers.
[RFC5280]認証パスに適用されるポリシーを決定するための一連の拡張機能を定義します。ポリシーは、オブジェクト識別子（OID）とオプションの予選のセットによって説明されます。
Policy validation in [RFC5280] is complex. As an overview, the certificate policies extension (Section 4.2.1.4 of [RFC5280]) describes the policies, with optional qualifiers, under which an individual certificate was issued. The policy mappings extension (Section 4.2.1.5 of [RFC5280]) allows a CA certificate to map its policy OIDs to other policy OIDs in certificates that it issues. Subject to these mappings and other extensions, the certification path's overall policy set is the intersection of policies asserted by each certificate in the path.
[RFC5280]のポリシー検証は複雑です。概要として、証明書ポリシー拡張（[RFC5280]のセクション4.2.1.4）は、個々の証明書が発行されたオプションの予選でポリシーを説明しています。ポリシーマッピング拡張（[RFC5280]のセクション4.2.1.5）により、CA証明書は、発行する証明書の他のポリシーOIDにポリシーOIDをマッピングできます。これらのマッピングおよびその他の拡張機能に従って、認証パスの全体的なポリシーセットは、パス内の各証明書によって主張されたポリシーの交差点です。
The procedure in Section 6.1 of [RFC5280] determines this set in the course of certification path validation. It does so by building a policy tree containing policies asserted by each certificate and the mappings between them. This tree can grow exponentially in the depth of the certification path, which means an attacker, with a small input, can cause a path validator to consume excessive memory and computational resources. This cost asymmetry can lead to a denial-of-service vulnerability in X.509-based applications, such as [CVE-2023-0464] and [CVE-2023-23524].
[RFC5280]のセクション6.1の手順は、認証パス検証の過程でこのセットを決定します。それは、各証明書とそれらの間のマッピングによって主張されたポリシーを含むポリシーツリーを構築することによって行われます。このツリーは、認証パスの深さで指数関数的に成長する可能性があります。つまり、攻撃者は小さな入力を伴うため、パスバリーターが過剰なメモリと計算リソースを消費する可能性があります。このコストの非対称性は、[CVE-2023-0464]や[CVE-2023-23524]などのX.509ベースのアプリケーションのサービス拒否の脆弱性につながる可能性があります。
Section 3 describes this vulnerability. Section 4.1 describes the primary mitigation for this vulnerability, a replacement for the policy tree structure. Section 5 provides updates to [RFC5280] that implement this change. Finally, Section 6 discusses alternative mitigation strategies for X.509 applications.
セクション3では、この脆弱性について説明します。セクション4.1では、この脆弱性の主要な緩和、ポリシーツリー構造の代替について説明します。セクション5では、この変更を実装する[RFC5280]の更新を提供します。最後に、セクション6では、X.509アプリケーションの代替緩和戦略について説明します。
The algorithm for processing certificate policies and policy mappings is replaced with one that builds an equivalent but much more efficient structure. This new algorithm does not change the validity status of any certification path or which certificate policies are valid for it.
証明書マッピングとポリシーマッピングを処理するためのアルゴリズムは、同等のがはるかに効率的な構造を構築するものに置き換えられます。この新しいアルゴリズムは、認証パスの妥当性ステータスや、どの証明書ポリシーが有効であるかを変更しません。
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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This section discusses how the path validation algorithm defined in Section 6.1.2 of [RFC5280] can lead to a denial-of-service vulnerability in X.509-based applications.
このセクションでは、[RFC5280]のセクション6.1.2で定義されているパス検証アルゴリズムが、X.509ベースのアプリケーションのサービス拒否の脆弱性にどのようにつながるかについて説明します。
Section 6.1.2 of [RFC5280] constructs the valid_policy_tree, a tree of certificate policies, during certification path validation. The nodes at any given depth in the tree correspond to policies asserted by a certificate in the certification path. A node's parent policy is the policy in the issuer certificate that was mapped to this policy, and a node's children are the policies the node was mapped to in the subject certificate.
[RFC5280]のセクション6.1.2は、認定パス検証中に、証明書ポリシーのツリーであるvalid_policy_treeを構築します。ツリー内の任意の深さのノードは、認証パスの証明書によって主張されたポリシーに対応しています。ノードの親ポリシーは、このポリシーにマッピングされた発行者証明書のポリシーであり、ノードの子供は、ノードが主題証明書にマッピングされたポリシーです。
For example, suppose a certification path contains:
たとえば、認定パスに次のことを含むとします。
* An intermediate certificate that asserts the following policy OIDs: OID1, OID2, and OID5. It contains mappings from OID1 to OID3 and from OID1 to OID4.
* 次のポリシーOIDSを主張する中間証明書：OID1、OID2、およびOID5。OID1からOID3へ、およびOID1からOID4へのマッピングが含まれています。
* An end-entity certificate that asserts the following policy OIDs: OID2, OID3, and OID6.
* 次のポリシーOIDSを主張するエンドエンティティ証明書：OID2、OID3、およびOID6。
This would result in the tree shown below. Note that OID5 and OID6 are not included or mapped across the whole path, so they do not appear in the final structure.
これにより、以下に示されているツリーが表示されます。OID5とOID6は、パス全体に含まれているかマッピングされていないため、最終構造には表示されないことに注意してください。
+-----------+
Root: | anyPolicy |
+-----------+
|{anyPolicy}|
+-----------+
/ \
/ \
v v
+------------+ +------------+
Intermediate: | OID1 | | OID2 |
(OID5 discarded) +------------+ +------------+
|{OID3, OID4}| | {OID2} |
+------------+ +------------+
| |
| |
v v
+------------+ +------------+
End-entity: | OID3 | | OID2 |
(OID6 discarded) +------------+ +------------+
The complete algorithm for building this structure is described in steps (d), (e), and (f) in Section 6.1.3 of [RFC5280]; steps (h), (i), and (j) in Section 6.1.4 of [RFC5280]; and steps (a), (b), and (g) in Section 6.1.5 of [RFC5280].
この構造を構築するための完全なアルゴリズムは、[RFC5280]のセクション6.1.3の手順（d）、（e）、および（f）で説明されています。[RFC5280]のセクション6.1.4の手順（h）、（i）、および（j）;および[RFC5280]のセクション6.1.5の手順（a）、（b）、および（g）。
The valid_policy_tree grows exponentially in the worst case. In step (d.1) in Section 6.1.3 of [RFC5280], a single policy P can produce multiple child nodes if multiple issuer policies map to P. This can cause the tree size to increase in size multiplicatively at each level.
valid_policy_treeは、最悪の場合に指数関数的に成長します。[RFC5280]のセクション6.1.3のステップ（D.1）では、複数の発行者ポリシーがPにマップすると、単一のポリシーPが複数の子ノードを生成できます。
In particular, consider a certificate chain where every intermediate certificate asserts policies OID1 and OID2 and then contains the full Cartesian product of mappings:
特に、すべての中間証明書がOID1およびOID2を主張し、マッピングの完全なデカルト製品が含まれる証明書チェーンを検討してください。
* OID1 maps to OID1
* OID1はOID1にマップします
* OID1 maps to OID2
* OID1はOID2にマップします
* OID2 maps to OID1
* OID2はOID1にマップします
* OID2 maps to OID2
* OID2はOID2にマップします
At each depth, the tree would double in size. For example, if there are two intermediate certificates and one end-entity certificate, the resulting tree would be as depicted in Figure 1.
各深さで、ツリーのサイズは2倍になります。たとえば、2つの中間証明書と1つのエンドエンティティ証明書がある場合、結果のツリーは図1に示されています。
+-----------------------+
| anyPolicy |
+-----------------------+
| {anyPolicy} |
+-----------------------+
/ \
/ \
v v
+------------+ +------------+
| OID1 | | OID2 |
+------------+ +------------+
|{OID1, OID2}| |{OID1, OID2}|
+------------+ +------------+
/ \ / \
/ \ / \
v v v v
+------------+ +------------+ +------------+ +------------+
| OID1 | | OID2 | | OID1 | | OID2 |
+------------+ +------------+ +------------+ +------------+
|{OID1, OID2}| |{OID1, OID2}| |{OID1, OID2}| |{OID1, OID2}|
+------------+ +------------+ +------------+ +------------+
| | | | | | | |
v v v v v v v v
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| OID1 | | OID2 | | OID1 | | OID2 | | OID1 | | OID2 | | OID1 | | OID2 |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
Figure 1: An Example X.509 Policy Tree with Exponential Growth
図1：指数成長を伴う例X.509ポリシーツリー
An attacker can use the exponential growth to mount a denial-of-service attack against an X.509-based application. The attacker sends a certificate chain as described in Section 3.2 and triggers the target application's certificate validation process. For example, the target application may be a TLS server [RFC8446] that performs client certificate validation. The target application will consume far more resources processing the input than the attacker consumed to send it, which prevents the target application from servicing other clients.
攻撃者は、指数成長を使用して、X.509ベースのアプリケーションに対するサービス拒否攻撃を実施できます。攻撃者は、セクション3.2で説明されているように証明書チェーンを送信し、ターゲットアプリケーションの証明書検証プロセスをトリガーします。たとえば、ターゲットアプリケーションは、クライアント証明書の検証を実行するTLSサーバー[RFC8446]である場合があります。ターゲットアプリケーションは、攻撃者がそれを送信するために消費したよりもはるかに多くのリソースを処理するリソースを消費します。これにより、ターゲットアプリケーションが他のクライアントにサービスを提供することができません。
This document mitigates the denial-of-service vulnerability described in Section 3 by replacing the policy tree with a policy graph structure, which is described in this section. The policy graph grows linearly instead of exponentially. This removes the asymmetric cost in policy validation.
このドキュメントでは、このセクションで説明するポリシーグラフ構造にポリシーツリーを置き換えることにより、セクション3で説明されているサービス拒否の脆弱性を軽減します。ポリシーグラフは、指数関数的ではなく直線的に成長します。これにより、ポリシー検証の非対称コストが削除されます。
X.509 implementations SHOULD perform policy validation by building a policy graph, following the procedure described in Section 5. This replacement procedure computes the same policies as in [RFC5280], but one of the outputs is in a different form. See Section 4.2 for details. Section 6 describes alternative mitigations for implementations that depend on the original, exponential-sized output.
X.509実装は、セクション5で説明した手順に従ってポリシーグラフを構築することによりポリシー検証を実行する必要があります。この置換手順は[RFC5280]と同じポリシーを計算しますが、出力の1つは異なる形式です。詳細については、セクション4.2を参照してください。セクション6では、元の指数サイズの出力に依存する実装の代替緩和について説明します。
The tree structure in [RFC5280] is an unnecessarily inefficient representation of a certification path's policy mappings. When multiple issuer policies map to a single subject policy, the subject policy will correspond to multiple duplicate nodes in the policy tree. Children of the subject policy are then duplicated recursively. This duplication is the source of the exponential growth described in Section 3.2.
[RFC5280]のツリー構造は、認証パスのポリシーマッピングの不必要に非効率的な表現です。複数の発行者ポリシーが単一のサブジェクトポリシーにマッピングされると、サブジェクトポリシーはポリシーツリー内の複数の複製ノードに対応します。主題政策の子どもたちは、再帰的に複製されます。この複製は、セクション3.2で説明されている指数関数的成長の原因です。
A policy graph represents the same information with a directed acyclic graph of policy nodes. It eliminates this duplication by using a single node with multiple parents. See Section 5 for the procedure for building this structure. Figure 2 shows the updated representation of the example in Figure 1.
ポリシーグラフは、ポリシーノードの指向的な非環式グラフを使用した同じ情報を表します。複数の親を持つ単一のノードを使用することにより、この複製を排除します。この構造を構築する手順については、セクション5を参照してください。図2は、図1の例の更新された表現を示しています。
+-----------+
| anyPolicy |
+-----------+
|{anyPolicy}|
+-----------+
/ \
/ \
v v
+------------+ +------------+
| OID1 | | OID2 |
+------------+ +------------+
|{OID1, OID2}| |{OID1, OID2}|
+------------+ +------------+
| \ / |
| \ / |
| \/ |
| /\ |
| / \ |
v v v v
+------------+ +------------+
| OID1 | | OID2 |
+------------+ +------------+
|{OID1, OID2}| |{OID1, OID2}|
+------------+ +------------+
| \ / |
| \ / |
| \/ |
| /\ |
| / \ |
v v v v
+------------+ +------------+
| OID1 | | OID2 |
+------------+ +------------+
Figure 2: A More Efficient Representation of an X.509 Policy Tree
図2：X.509ポリシーツリーのより効率的な表現
This graph's size is bounded linearly by the total number of certificate policies (Section 4.2.1.4 of [RFC5280]) and policy mappings (Section 4.2.1.5 of [RFC5280]). The policy tree in [RFC5280] is the tree of all paths from the root to a leaf in the policy graph, so no information is lost in the graph representation.
このグラフのサイズは、証明書ポリシーの総数（[RFC5280]のセクション4.2.1.4）およびポリシーマッピング（[RFC5280]のセクション4.2.1.5）によって線形に境界を掲載されています。[RFC5280]のポリシーツリーは、ポリシーグラフのルートから葉までのすべてのパスのツリーであるため、グラフ表現では情報が失われません。
Section 6.1.6 of [RFC5280] describes the entire valid_policy_tree structure as an output of the verification process. However, Section 12.2 of [X.509] only describes the following as outputs: the authorities-constrained policies, the user-constrained policies, and their associated qualifiers.
[RFC5280]のセクション6.1.6では、検証プロセスの出力としてvalid_policy_tree構造全体を説明しています。ただし、[X.509]のセクション12.2では、以下を出力として説明しています。当局に制約のあるポリシー、ユーザー制約のポリシー、および関連する修飾子です。
As the valid_policy_tree is the exponential structure, computing it reintroduces the denial-of-service vulnerability. X.509 implementations SHOULD NOT output the entire valid_policy_tree structure; instead, they SHOULD limit output to just the set of authorities-constrained and/or user-constrained policies, as described in [X.509]. Sections 5.6 and 6 discuss other mitigations for applications where this option is not available.
valid_policy_treeは指数構造であるため、それを計算すると、サービス拒否の脆弱性が再導入されます。X.509実装は、valid_policy_tree構造全体を出力しないでください。代わりに、[X.509]で説明されているように、出力を当局に制約のあるおよび/またはユーザー制約のポリシーのセットに制限する必要があります。セクション5.6および6は、このオプションが利用できないアプリケーションの他の緩和について説明します。
X.509 implementations MAY omit policy qualifiers from the output to simplify processing. Note that Section 4.2.1.4 of [RFC5280] already recommends that certification authorities omit policy qualifiers from policy information terms.
X.509実装は、処理を簡素化するために出力からポリシー予選を省略する場合があります。[RFC5280]のセクション4.2.1.4は、認定当局がポリシー情報条件からポリシー予選を省略することをすでに推奨していることに注意してください。
This section provides updates to [RFC5280]. These updates implement the changes described in Section 4.
このセクションでは、[RFC5280]の更新を提供します。これらの更新は、セクション4で説明されている変更を実装します。
Section 6.1 of [RFC5280] is updated as follows:
[RFC5280]のセクション6.1は次のように更新されます。
OLD:
OLD:
A particular certification path may not, however, be appropriate for all applications. Therefore, an application MAY augment this algorithm to further limit the set of valid paths. The path validation process also determines the set of certificate policies that are valid for this path, based on the certificate policies extension, policy mappings extension, policy constraints extension, and inhibit anyPolicy extension. To achieve this, the path validation algorithm constructs a valid policy tree. If the set of certificate policies that are valid for this path is not empty, then the result will be a valid policy tree of depth n, otherwise the result will be a null valid policy tree.
ただし、特定の認証パスは、すべてのアプリケーションに適していない場合があります。したがって、アプリケーションはこのアルゴリズムを強化して、有効なパスのセットをさらに制限する場合があります。パス検証プロセスは、証明書のポリシー拡張、ポリシーマッピングの拡張、ポリシー制約の拡張、および任意のポリシー拡張を阻害することに基づいて、このパスに有効な証明書ポリシーのセットも決定します。これを達成するために、PATH検証アルゴリズムは有効なポリシーツリーを構築します。このパスに有効な証明書ポリシーのセットが空でない場合、結果は深さnの有効なポリシーツリーになります。そうしないと、結果はヌル有効なポリシーツリーになります。
NEW:
NEW:
A particular certification path may not, however, be appropriate for all applications. Therefore, an application MAY augment this algorithm to further limit the set of valid paths. The path validation process also determines the set of certificate policies that are valid for this path, based on the certificate policies extension, policy mappings extension, policy constraints extension, and inhibit anyPolicy extension. To achieve this, the path validation algorithm constructs a valid policy set, which may be empty if no certificate policies are valid for this path.
ただし、特定の認証パスは、すべてのアプリケーションに適していない場合があります。したがって、アプリケーションはこのアルゴリズムを強化して、有効なパスのセットをさらに制限する場合があります。パス検証プロセスは、証明書のポリシー拡張、ポリシーマッピングの拡張、ポリシー制約の拡張、および任意のポリシー拡張を阻害することに基づいて、このパスに有効な証明書ポリシーのセットも決定します。これを達成するために、PATH検証アルゴリズムは有効なポリシーセットを構築します。これは、このパスに対して証明書ポリシーが有効でない場合は空になる場合があります。
The following replaces entry (a) in Section 6.1.2 of [RFC5280]:
以下は、[RFC5280]のセクション6.1.2のエントリ（a）を置き換えます。
(a) valid_policy_graph: A directed acyclic graph of certificate policies with their optional qualifiers; each of the leaves of the graph represents a valid policy at this stage in the certification path validation. If valid policies exist at this stage in the certification path validation, the depth of the graph is equal to the number of certificates in the chain that have been processed. If valid policies do not exist at this stage in the certification path validation, the graph is set to NULL. Once the graph is set to NULL, policy processing ceases. Implementations MAY omit qualifiers if not returned in the output.
(a) valid_policy_graph：オプションの予選を使用した証明書ポリシーの指示された非環式グラフ。グラフの各葉は、認定パス検証のこの段階で有効なポリシーを表します。認定パス検証のこの段階で有効なポリシーが存在する場合、グラフの深さは、処理されたチェーン内の証明書の数に等しくなります。認定パス検証のこの段階で有効なポリシーが存在しない場合、グラフはnullに設定されます。グラフがnullに設定されると、ポリシー処理は停止します。実装は、出力で返されない場合、予選を省略する場合があります。
Each node in the valid_policy_graph includes three data objects: the valid policy, a set of associated policy qualifiers, and a set of one or more expected policy values.
valid_policy_graphの各ノードには、有効なポリシー、関連するポリシー予選のセット、および1つ以上の予想されるポリシー値のセットの3つのデータオブジェクトが含まれています。
Nodes in the graph can be divided into depths, numbered starting from zero. A node at depth x can have zero or more children at depth x+1 and, with the exception of depth zero, one or more parents at depth x-1. No other edges between nodes may exist.
グラフ内のノードは、ゼロから始まる数字の深さに分割できます。深さXのノードには、深さx+1でゼロ以上の子供がいる可能性があります。深さゼロを除き、深さX-1で1人以上の親がいます。ノード間の他のエッジは存在しない可能性があります。
If the node is at depth x, the components of the node have the following semantics:
ノードが深度Xにある場合、ノードのコンポーネントには次のセマンティクスがあります。
(1) The valid_policy is a single policy OID representing a valid policy for the path of length x.
(1) valid_policyは、長さxのパスの有効なポリシーを表す単一のポリシーです。
(2) The qualifier_set is a set of policy qualifiers associated with the valid policy in certificate x. It is only necessary to maintain this field if policy qualifiers are returned to the application. See Section 6.1.5, step (g).
(2) Qualifier_setは、証明書xの有効なポリシーに関連付けられたポリシー修飾子のセットです。ポリシー予選が申請に返された場合にのみ、このフィールドを維持する必要があります。セクション6.1.5、ステップ（g）を参照してください。
(3) The expected_policy_set contains one or more policy OIDs that would satisfy this policy in the certificate x+1.
(3) expection_policy_setには、証明書X+1のこのポリシーを満たす1つ以上のポリシーOIDが含まれています。
The initial value of the valid_policy_graph is a single node with valid_policy anyPolicy, an empty qualifier_set, and an expected_policy_set with the single value anyPolicy. This node is considered to be at depth zero.
valid_policy_graphの初期値は、balid_policyを備えた単一ノード、Anypolicy、空のqualifier_set、および単一値のanypolicyを持つexpection_policy_setです。このノードは深さゼロにあると見なされます。
The graph additionally satisfies the following invariants:
グラフはさらに、次の不変剤を満たしています。
* For any depth x and policy OID P-OID, there is at most one node at depth x whose valid_policy is P-OID.
* 任意の深さXおよびポリシーOID P-OIDについては、Depth Xに最大1つのノードがあり、そのvalid_policyがp-ofです。
* The expected_policy_set of a node whose valid_policy is anyPolicy is always {anyPolicy}.
* AnyPolicyが常に{AnyPolicy}であるというbalid_policyが常に{anypolicy}であるノードのexpection_policy_set。
* A node at depth x whose valid_policy is anyPolicy, except for the one at depth zero, always has exactly one parent: a node at depth x-1 whose valid_policy is also anyPolicy.
* 深さゼロのものを除き、valid_policyがanypolicyである深度xのノードは、常に正確に1つの親を持ちます。
* Each node at depth greater than 0 has either one or more parent nodes whose valid_policy is not anyPolicy or a single parent node whose valid_policy is anyPolicy. That is, a node cannot simultaneously be a child of both anyPolicy and some non-anyPolicy OID.
* 0を超える深さの各ノードには、valid_policyがpolicyではない1つまたは複数の親ノードまたはvalid_policyがanypolicyである単一の親ノードを持っています。つまり、ノードは、同時に、任意のポリティと非仮定的なoidの両方の子供ではありません。
Figure 3 is a graphic representation of the initial state of the valid_policy_graph. Additional figures will use this format to describe changes in the valid_policy_graph during path processing.
図3は、valid_policy_graphの初期状態のグラフィック表現です。追加の図は、この形式を使用して、パス処理中のvalid_policy_graphの変更を説明します。
+----------------+
| anyPolicy | <---- valid_policy
+----------------+
| {} | <---- qualifier_set
+----------------+
| {anyPolicy} | <---- expected_policy_set
+----------------+
Figure 3: Initial Value of the valid_policy_graph State Variable
図3：valid_policy_graph状態変数の初期値
The following replaces steps (d), (e), and (f) in Section 6.1.3 of [RFC5280]:
以下は、[RFC5280]のセクション6.1.3の手順（d）、（e）、および（f）を置き換えます。
(d) If the certificate policies extension is present in the certificate and the valid_policy_graph is not NULL, process the policy information by performing the following steps in order:
(d) 証明書延長が証明書に存在し、valid_policy_graphがnullでない場合は、次の手順を実行してポリシー情報を処理します。
(1) For each policy P not equal to anyPolicy in the certificate policies extension, let P-OID denote the OID for policy P and P-Q denote the qualifier set for policy P. Perform the following steps in order:
(1) 証明書ポリシー拡張の任意のポリティに等しくない各ポリシーPについて、P-OIDがポリシーPおよびP-QのOIDを示すと、ポリシーPの予選セットを示します。次の手順を順に実行します。
(i) Let parent_nodes be the nodes at depth i-1 in the valid_policy_graph where P-OID is in the expected_policy_set. If parent_nodes is not empty, create a child node as follows: set the valid_policy to P-OID, set the qualifier_set to P-Q, set the expected_policy_set to {P-OID}, and set the parent nodes to parent_nodes.
(i) p-policy_graphのp-policy_graphの深さI-1のlater_nodesとexpect_policy_setのノードとします。parent_nodesが空でない場合は、次のように子ノードを作成します。balif_policyをp-ofに設定し、qualifier_setをp-qに設定し、sected_policy_setを{p-of}に設定し、親ノードをparent_nodesに設定します。
For example, consider a valid_policy_graph with a node of depth i-1 where the expected_policy_set is {Gold, White} and a second node where the expected_policy_set is {Gold, Yellow}. Assume the certificate policies Gold and Silver appear in the certificate policies extension of certificate i. The Gold policy is matched, but the Silver policy is not. This rule will generate a child node of depth i for the Gold policy. The result is shown as Figure 4.
たとえば、expection_policy_setが{gold、white}である深さI-1のノードを備えたvalid_policy_graphを考えてください。証明書ポリシーが証明書のポリシーに表示されると仮定します。証明書の拡張i。ゴールド政策は一致していますが、銀の政策はそうではありません。このルールは、金政策のために深さIの子ノードを生成します。結果は図4のように示されています。
+-----------------+ +-----------------+
| Red | | Blue |
+-----------------+ +-----------------+
| {} | | {} | depth i-1
+-----------------+ +-----------------+
| {Gold, White} | | {Gold, Yellow} |
+-----------------+ +-----------------+
\ /
\ /
\ /
v v
+-----------------+
| Gold |
+-----------------+
| {} | depth i
+-----------------+
| {Gold} |
+-----------------+
Figure 4: Processing an Exact Match
図4：正確な一致の処理
(ii) If there was no match in step (i) and the valid_policy_graph includes a node of depth i-1 with the valid_policy anyPolicy, generate a child node with the following values: set the valid_policy to P-OID, set the qualifier_set to P-Q, set the expected_policy_set to {P-OID}, and set the parent node to the anyPolicy node at depth i-1.
（ii）ステップ（i）に一致がなく、valid_policy_graphにvalid_policy anypolicyの深さI-1のノードが含まれている場合、次の値で子ノードを生成します：valif_policyをp-ofに設定し、qualifier_setを設定します。p-q、spected_policy_setを{p-of}に設定し、深さI-1で親ノードをanypolicyノードに設定します。
For example, consider a valid_policy_graph with a node of depth i-1 where the valid_policy is anyPolicy. Assume the certificate policies Gold and Silver appear in the certificate policies extension of certificate i. The Gold policy does not have a qualifier, but the Silver policy has the qualifier Q-Silver. If Gold and Silver were not matched in (i) above, this rule will generate two child nodes of depth i, one for each policy. The result is shown as Figure 5.
たとえば、valid_policyがanypolicyである深さI-1のノードを備えたvalid_policy_graphを検討してください。証明書ポリシーが証明書のポリシーに表示されると仮定します。証明書の拡張i。ゴールドポリシーには予選はありませんが、シルバーポリシーには予選Qシルバーがあります。上記の（i）に金と銀が一致していない場合、このルールは、各ポリシーに1つの深さIの2つの子ノードを生成します。結果は図5のように示されています。
+-----------------+
| anyPolicy |
+-----------------+
| {} |
+-----------------+ depth i-1
| {anyPolicy} |
+-----------------+
/ \
/ \
/ \
v v
+-----------------+ +-----------------+
| Gold | | Silver |
+-----------------+ +-----------------+
| {} | | {Q-Silver} | depth i
+-----------------+ +-----------------+
| {Gold} | | {Silver} |
+-----------------+ +-----------------+
Figure 5: Processing Unmatched Policies When a Leaf Node Specifies anyPolicy
図5：葉のノードがanyPolicyを指定したときに比類のないポリシーの処理
(2) If the certificate policies extension includes the policy anyPolicy with the qualifier set AP-Q and either (a) inhibit_anyPolicy is greater than 0 or (b) i<n and the certificate is self-issued, then:
(2) 証明書のポリシー拡張には、予選セットAP-Qを備えたポリシーが含まれており、（a）阻害_Anypolicyが0または（b）i <nを超えており、証明書は自己発行されます。
For each policy OID P-OID (including anyPolicy) that appears in the expected_policy_set of some node in the valid_policy_graph for depth i-1, if P-OID does not appear as the valid_policy of some node at depth i, create a single child node with the following values: set the valid_policy to P-OID, set the qualifier_set to AP-Q, set the expected_policy_set to {P-OID}, and set the parents to the nodes at depth i-1 where P-OID appears in expected_policy_set.
各ポリシーについて、深さI-1のvalid_policy_graphのいくつかのノードのexpection_policy_setに表示されるp-policy_setに表示されるp-of（anypolicyを含む）、p-ofが深さIの一部のノードのvalid_policyとして表示されない場合、単一の子ノードを作成します次の値を使用して：valid_policyをp-ofに設定し、qualifier_setをAP-Qに設定し、expect_policy_setを{p-of}に設定し、p-policy_setにp-ofが表示される深さI-1のノードに親を設定します。
This is equivalent to running step (1) above as if the certificate policies extension contained a policy with OID P-OID and qualifier set AP-Q.
これは、上記のステップ（1）を実行することと同等です。まるで証明書ポリシーの拡張には、OID P-OIDおよび修飾子セットAP-Qを使用したポリシーが含まれているかのようです。
For example, consider a valid_policy_graph with a node of depth i-1 where the expected_policy_set is {Gold, Silver} and a second node of depth i-1 where the expected_policy_set is {Gold}. Assume anyPolicy appears in the certificate policies extension of certificate i with policy qualifiers AP-Q, but Gold and Silver do not appear. This rule will generate two child nodes of depth i, one for each policy. The result is shown below as Figure 6.
たとえば、DEPTIONのノードを備えたvalid_policy_graphを検討してください。expective_policy_setが{gold、silver}である深さi-1と、equided_policy_setが{gold}である深度i-1の2番目のノードを考えます。AnyPolicyが証明書ポリシーに表示されていると仮定します。証明書Iの拡張Iのポリシー予選AP-Qですが、金と銀は表示されません。このルールは、ポリシーごとに1つずつ、深さIの2つの子ノードを生成します。結果は、図6のように以下に示されています。
+-----------------+ +-----------------+
| Red | | Blue |
+-----------------+ +-----------------+
| {} | | {} | depth i-1
+-----------------+ +-----------------+
| {Gold, Silver} | | {Gold} |
+-----------------+ +-----------------+
| \ |
| \ |
| \ |
| \ |
| \ |
v v v
+-----------------+ +-----------------+
| Silver | | Gold |
+-----------------+ +-----------------+
| {AP-Q} | | {AP-Q} | depth i
+-----------------+ +-----------------+
| {Silver} | | {Gold} |
+-----------------+ +-----------------+
Figure 6: Processing Unmatched Policies When the Certificate Policies Extension Specifies anyPolicy
図6：証明書のポリシー拡張がanyPolicyを指定するときに比類のないポリシーの処理
(3) If there is a node in the valid_policy_graph of depth i-1 or less without any child nodes, delete that node. Repeat this step until there are no nodes of depth i-1 or less without children.
(3) 子ノードなしで深さI-1以下のvalid_policy_graphにノードがある場合は、そのノードを削除します。子供がいない深さI-1以下のノードがなくなるまで、この手順を繰り返します。
For example, consider the valid_policy_graph shown in Figure 7 below. The two nodes at depth i-1 that are marked with an 'X' have no children, and they are deleted. Applying this rule to the resulting graph will cause the nodes at depth i-2 that is marked with a 'Y' to be deleted. In the resulting graph, there are no nodes of depth i-1 or less without children, and this step is complete.
たとえば、以下の図7に示すvalid_policy_graphを検討してください。「x」でマークされている深さI-1の2つのノードには、子供がなく、削除されます。このルールを結果のグラフに適用すると、「Y」が削除された深さI-2のノードが削除されます。結果のグラフでは、子供がいない深度I-1以下のノードはなく、このステップは完了しています。
+-----------+
| | depth i-3
+-----------+
/ | \
/ | \
v v v
+-----------+ +-----------+ +-----------+
| | | | | Y | depth i-2
+-----------+ +-----------+ +-----------+
| \ | |
| \ | |
v v v v
+-----------+ +-----------+ +-----------+
| X | | | | X | depth i-1
+-----------+ +-----------+ +-----------+
/ | \
/ | \
v v v
+-----------+ +-----------+ +-----------+
| | | | | | depth i
+-----------+ +-----------+ +-----------+
Figure 7: Pruning the valid_policy_graph
図7：valid_policy_graphを剪定します
(e) If the certificate policies extension is not present, set the valid_policy_graph to NULL.
(e) 証明書ポリシーの拡張が存在しない場合は、valid_policy_graphをnullに設定します。
(f) Verify that either explicit_policy is greater than 0 or the valid_policy_graph is not equal to NULL.
(f) いずれかのexpricit_policyが0より大きいか、valid_policy_graphがnullと等しくないことを確認します。
The text following step (f) in Section 6.1.3 of [RFC5280], beginning with "If any of steps (a), (b), (c), or (f) fails", is left unmodified.
[RFC5280]のセクション6.1.3のステップ（f）に次のテキストは、「ステップ（a）、（b）、（c）、または（f）fails」のいずれかで始まる場合、変更されていません。
The following replaces step (b) in Section 6.1.4 of [RFC5280]:
以下は、[RFC5280]のセクション6.1.4のステップ（b）を置き換えます。
(b) If a policy mappings extension is present, then for each issuerDomainPolicy ID-P in the policy mappings extension:
(b) ポリシーマッピングの拡張機能が存在する場合、ポリシーマッピング拡張機能の各発行者のID-Pに対して：
(1) If the policy_mapping variable is greater than 0 and there is a node in the valid_policy_graph of depth i where ID-P is the valid_policy, set expected_policy_set to the set of subjectDomainPolicy values that are specified as equivalent to ID-P by the policy mappings extension.
(1) Policy_Mapping変数が0より大きく、深さIのvalid_policy_graphにノードがある場合、id-pはvalid_policyであり、ポリシーマッピングの拡張によってID-Pに等しいものとして指定されているsubjectdomainpolicy値のセットにset_policy_setを設定します。
(2) If the policy_mapping variable is greater than 0 and no node of depth i in the valid_policy_graph has a valid_policy of ID-P but there is a node of depth i with a valid_policy of anyPolicy, then generate a child node of the node of depth i-1 that has a valid_policy of anyPolicy as follows:
(2) policy_mapping変数が0を超えており、valid_policy_graphの深さのノードがない場合、id-pのvalid_policyがありますが、anypolicyのvalid_policyを持つ深さiのノードがあり、深さi-のノードの子ノードを生成します。1次のように、AnyPolicyのvalid_policyを持っている1
(i) set the valid_policy to ID-P;
(i) valid_policyをid-pに設定します。
(ii) set the qualifier_set to the qualifier set of the policy anyPolicy in the certificate policies extension of certificate i; and
（ii）証明書ポリシーの証明書ポリシー拡張におけるポリシーの予選セットに予選_setを設定します。そして
(iii) set the expected_policy_set to the set of subjectDomainPolicy values that are specified as equivalent to ID-P by the policy mappings extension.
（iii）ポリシーマッピング拡張によりID-Pに相当するものとして指定されている件名DomainPolicy値のセットにexpected_Policy_Setを設定します。
(3) If the policy_mapping variable is equal to 0:
(3) policy_mapping変数が0に等しい場合：
(i) delete the node, if any, of depth i in the valid_policy_graph where ID-P is the valid_policy.
(i) valid_policy_graphの深さiのノードを削除します。ここで、id-pはvalid_policyです。
(ii) If there is a node in the valid_policy_graph of depth i-1 or less without any child nodes, delete that node. Repeat this step until there are no nodes of depth i-1 or less without children.
（ii）子ノードなしで深さI-1以下のvalid_policy_graphにノードがある場合は、そのノードを削除します。子供がいない深さI-1以下のノードがなくなるまで、この手順を繰り返します。
The following replaces step (g) in Section 6.1.5 of [RFC5280]:
以下は、[RFC5280]のセクション6.1.5のステップ（g）を置き換えます。
(g) Calculate the user_constrained_policy_set as follows. The user_constrained_policy_set is a set of policy OIDs, along with associated policy qualifiers.
(g) 次のようにuser_constrained_policy_setを計算します。user_constrained_policy_setは、関連するポリシー予選とともに、ポリシーOIDのセットです。
(1) If the valid_policy_graph is NULL, set valid_policy_node_set to the empty set.
(1) valid_policy_graphがnullの場合、valid_policy_node_setを空のセットに設定します。
(2) If the valid_policy_graph is not NULL, set valid_policy_node_set to the set of policy nodes whose valid_policy is not anyPolicy and whose parent list is a single node with valid_policy of anyPolicy.
(2) valid_policy_graphがnullでない場合は、valid_policyが任意ではなく、親リストがanypolicyのvalid_policyを持つ単一ノードであるポリシーノードのセットにvalid_policy_node_setを設定します。
(3) If the valid_policy_graph is not NULL and contains a node of depth n with the valid_policy anyPolicy, add it to valid_policy_node_set.
(3) valid_policy_graphがnullでなく、balid_policy anypolicyの深さnのノードを含んでいる場合は、valid_policy_node_setに追加します。
(4) Compute authority_constrained_policy_set, a set of policy OIDs and associated qualifiers as follows. For each node in valid_policy_node_set:
(4) compute authority_constrained_policy_set、次のように、ポリシーOIDと関連する修飾子のセット。valid_policy_node_setの各ノードについて：
(i) Add the node's valid_policy to authority_constrained_policy_set.
(i) nodeのvalid_policyをauthorid_constrained_policy_setに追加します。
(ii) Collect all qualifiers in the node, its ancestors, and descendants and associate them with valid_policy. Applications that do not use policy qualifiers MAY skip this step to simplify processing.
（ii）ノード、その祖先、子孫のすべての予選を収集し、それらをvalid_policyに関連付けます。ポリシー予選を使用しないアプリケーションは、この手順をスキップして処理を簡素化する場合があります。
(5) Set user_constrained_policy_set to authority_constrained_policy_set.
(5) user_constrained_policy_setをauthority_constrained_policy_setに設定します。
(6) If the user-initial-policy-set is not anyPolicy:
(6) ユーザーInitial-Policy-Setが任意のものではない場合：
(i) Remove any elements of user_constrained_policy_set that do not appear in user-initial-policy-set.
(i) userInitial-policy-setには表示されないuser_constrained_policy_setの要素を削除します。
(ii) If anyPolicy appears in authority_constrained_policy_set with qualifiers AP-Q, for each OID P-OID in user-initial-policy-set that does not appear in user_constrained_policy_set, add P-OID with qualifiers AP-Q to user_constrained_policy_set.
（ii）user_constaredained_policy_setに表示されないユーザーInitial-policy-setの各oid p-ofについて、authoride_constrained_policy_setがauthoride_constrained_policy_setにauthority_constrained_policy_setに表示される場合、user_constared_policy_setにP-OIDを追加します。
In addition, the final paragraph in Section 6.1.5 of [RFC5280] is updated as follows:
さらに、[RFC5280]のセクション6.1.5の最終段落は次のように更新されます。
OLD:
OLD:
If either (1) the value of explicit_policy variable is greater than zero or (2) the valid_policy_tree is not NULL, then path processing has succeeded.
いずれかのいずれかの場合、explicit_policy変数の値がゼロより大きい場合、または（2）valid_policy_treeがnullではない場合、パス処理は成功しました。
NEW:
NEW:
If either (1) the value of explicit_policy is greater than zero, or (2) the user_constrained_policy_set is not empty, then path processing has succeeded.
いずれかのいずれかがゼロより大きい（2）user_constrained_policy_setが空になっていない場合、（2）user_constrained_policy_setが成功しました。
The following replaces Section 6.1.6 of [RFC5280]:
以下は、[RFC5280]のセクション6.1.6に代わるものです。
If path processing succeeds, the procedure terminates, returning a success indication together with the final value of the user_constrained_policy_set, the working_public_key, the working_public_key_algorithm, and the working_public_key_parameters.
パス処理が成功した場合、手順は終了し、user_constrained_policy_set、working_public_key、working_public_key_algorithm、およびworking_public_key_parametersの最終的な値とともに成功指標を返します。
Note that the original procedure described in [RFC5280] included a valid_policy_tree structure as part of the output. This structure grows exponentially in the size of the input, so computing it risks denial-of-service vulnerabilities in X.509-based applications, such as [CVE-2023-0464] and [CVE-2023-23524]. Accordingly, this output is deprecated. Computing this structure is NOT RECOMMENDED.
[RFC5280]で説明されている元の手順には、出力の一部としてvalid_policy_tree構造が含まれていたことに注意してください。この構造は、入力のサイズが指数関数的に成長するため、[CVE-2023-0464]や[CVE-2023-23524]などのX.509ベースのアプリケーションで、ITの計算にリスクを冒します。したがって、この出力は非推奨です。この構造の計算は推奨されません。
An implementation that requires valid_policy_tree for compatibility with legacy systems may compute it from valid_policy_graph by recursively duplicating every multi-parent node. This may be done on-demand when the calling application first requests this output. However, this computation may consume exponential time and memory, so such implementations SHOULD mitigate denial-of-service attacks in other ways, such as by limiting the depth or size of the tree.
Legacy Systemsとの互換性にvalid_policy_treeを必要とする実装は、すべてのマルチ親ノードを再帰的に複製することにより、valid_policy_graphからそれを計算できます。これは、呼び出しアプリケーションが最初にこの出力を要求したときにオンデマンドで行うことができます。ただし、この計算では指数関数的な時間とメモリが消費される可能性があるため、このような実装は、ツリーの深さやサイズを制限するなど、他の方法でサービス拒否攻撃を軽減する必要があります。
X.509 implementations that are unable to switch to the policy graph structure SHOULD mitigate the denial-of-service attack in other ways. This section describes alternate mitigation and partial mitigation strategies.
X.509ポリシーグラフ構造に切り替えることができない実装は、他の方法でサービス拒否攻撃を緩和する必要があります。このセクションでは、代替緩和と部分緩和戦略について説明します。
X.509 validators SHOULD verify signatures in certification paths before or in conjunction with policy verification. This limits the attack to entities in control of CA certificates. For some applications, this may be sufficient to mitigate the attack. However, other applications may still be impacted, for example:
X.509バリデーターは、ポリシー検証と併せて認証パスの署名を検証する必要があります。これにより、CA証明書を管理するエンティティへの攻撃が制限されます。一部のアプリケーションでは、これで攻撃を軽減するのに十分かもしれません。ただし、他のアプリケーションは引き続き影響を受ける可能性があります。たとえば、：
* Any application that evaluates an untrusted PKI, such as a hosting provider that evaluates a customer-supplied PKI
* 顧客が提供するPKIを評価するホスティングプロバイダーなど、信頼されていないPKIを評価するアプリケーション
* Any application that evaluates an otherwise trusted PKI that includes untrusted entities with technically constrained intermediate certificates. If the intermediates do not constrain policy mapping or path length, those entities may be able to perform this attack.
* 技術的に制約されている中間証明書を持つ信頼されていないエンティティを含む、そうでなければ信頼できるPKIを評価するアプリケーション。中間体がポリシーマッピングやパスの長さを制約しない場合、それらのエンティティはこの攻撃を実行できる可能性があります。
The policy tree grows exponentially in the depth of a certification path, so limiting the depth and certificate size can mitigate the attack.
ポリシーツリーは、認証パスの深さで指数関数的に成長するため、深さと証明書のサイズを制限すると、攻撃を軽減できます。
However, this option may not be viable for all applications. Too low of a limit may reject existing paths that the application wishes to accept. Too high of a limit may still admit a denial-of-service attack for the application. By modifying the example in Section 3.2 to increase the number of policies asserted in each certificate, an attacker could still achieve O(N^(depth/2)) scaling.
ただし、このオプションはすべてのアプリケーションで実行可能ではない場合があります。制限が低すぎると、アプリケーションが受け入れたい既存のパスを拒否する場合があります。制限が高すぎると、アプリケーションのサービス拒否攻撃を認める可能性があります。セクション3.2の例を変更して、各証明書で主張されているポリシーの数を増やすことにより、攻撃者はo（n^（深さ/2））スケーリングを達成できます。
The attack can be mitigated by limiting the number of nodes in the policy tree and rejecting the certification path if this limit is reached. This limit should be set high enough to still admit existing valid certification paths for the application but low enough to no longer admit a denial-of-service attack.
攻撃は、ポリシーツリーのノードの数を制限し、この制限に達した場合に認証パスを拒否することにより緩和できます。この制限は、アプリケーションの既存の有効な認証パスをまだ認めるのに十分高く設定する必要がありますが、サービス拒否攻撃を認めることができなくなるほど低くなります。
If policy mapping is disabled via the initial-policy-mapping-inhibit setting (see Section 6.1.1 of [RFC5280]), the attack is mitigated. This also significantly simplifies the X.509 implementation, which reduces the risk of other security bugs. However, this will break compatibility with any existing certification paths that rely on policy mapping.
ポリシーマッピングが初期ポリシーマッピング阻害設定を介して無効になっている場合（[RFC5280]のセクション6.1.1を参照）、攻撃は緩和されます。これにより、X.509の実装も大幅に簡素化され、他のセキュリティバグのリスクが低下します。ただし、これにより、ポリシーマッピングに依存している既存の認証パスとの互換性が損なわれます。
To facilitate this mitigation, certificate authorities SHOULD NOT issue certificates with the policy mappings extension (Section 4.2.1.5 of [RFC5280]). Applications maintaining policies for accepted trust anchors are RECOMMENDED to forbid this extension in participating certificate authorities.
この緩和を促進するために、証明書当局は、ポリシーマッピング拡張機能（[RFC5280]のセクション4.2.1.5）で証明書を発行すべきではありません。受け入れられた信託アンカーのポリシーを維持する申請は、参加証明書当局にこの延長を禁止するために推奨されます。
An X.509 validator can mitigate this attack by disabling policy validation entirely. This may be viable for applications that do not require policy validation. In this case, critical policy-related extensions, notably the policy constraints extension (Section 4.2.1.11 of [RFC5280]), MUST be treated as unrecognized extensions as described in Section 4.2 of [RFC5280] and be rejected.
X.509バリデーターは、ポリシー検証を完全に無効にすることにより、この攻撃を軽減できます。これは、ポリシー検証を必要としないアプリケーションで実行可能です。この場合、重要なポリシー関連の拡張、特にポリシーの制約拡張（[RFC5280]のセクション4.2.1.11）は、[RFC5280]のセクション4.2で説明されているように、認識されていない拡張機能として扱われ、拒否されなければなりません。
Section 3 discusses how the policy tree algorithm in [RFC5280] can lead to denial-of-service vulnerabilities in X.509-based applications, such as [CVE-2023-0464] and [CVE-2023-23524].
セクション3では、[RFC5280]のポリシーツリーアルゴリズムが、[CVE-2023-0464]や[CVE-2023-23524]などのX.509ベースのアプリケーションのサービス拒否の脆弱性にどのようにつながるかについて説明します。
Section 5 replaces this algorithm to avoid this issue. As discussed in Section 4.1, the new structure scales linearly with the input. This means input limits in X.509 validators will more naturally bound processing time, thus avoiding these vulnerabilities.
セクション5では、この問題を回避するためにこのアルゴリズムを置き換えます。セクション4.1で説明したように、新しい構造は入力と直線的にスケーリングします。これは、X.509の入力制限がより自然にバインドされた処理時間を使用することを意味し、したがってこれらの脆弱性を回避します。
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>.
[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>.
[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>.
[CVE-2023-0464]
CVE, "Excessive Resource Usage Verifying X.509 Policy
Constraints", CVE-2023-0464, March 2023,
<https://www.cve.org/CVERecord?id=CVE-2023-0464>.
[CVE-2023-23524]
CVE, "Processing a maliciously crafted certificate may
lead to a denial-of-service", CVE-2023-23524, February
2023, <https://www.cve.org/CVERecord?id=CVE-2023-23524>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[X.509] ITU-T, "Information technology - Open Systems
Interconnection - The Directory: Public-key and attribute
certificate frameworks", ITU-T Recommendation X.509,
October 2019, <https://www.itu.int/rec/T-REC-X.509>.
The author thanks Bob Beck, Adam Langley, Matt Mueller, and Ryan Sleevi for many valuable discussions that led to discovering this issue, understanding it, and developing the mitigation. The author also thanks Martin Thomson, Job Snijders, and John Scudder for their review and feedback on this document.
著者は、この問題を発見し、それを理解し、緩和の開発につながった多くの貴重な議論をしてくれたボブ・ベック、アダム・ラングレー、マット・ミューラー、ライアン・スレビに感謝します。著者はまた、この文書に関するレビューとフィードバックをしてくれたMartin Thomson、Job Snijders、およびJohn Scudderにも感謝します。
David Benjamin
Google LLC
Email: davidben@google.com