[要約] RFC 10007は、CRL検証時に発行者証明書のkeyUsage拡張が存在し、cRLSignビットが設定されていることを必ず確認するようRFC 5280を更新します。これにより、CRL署名を許可されていない鍵で署名されたCRLを検証アルゴリズムが誤って信頼する曖昧さを解消します。
Internet Engineering Task Force (IETF) C. Bonnell
Request for Comments: 10007 DigiCert, Inc.
Updates: 5280 伊藤 忠彦 (T. Ito)
Category: Standards Track セコム株式会社 (SECOM CO., LTD.)
ISSN: 2070-1721 大久保 智史 (T. Okubo)
Penguin Securities Pte. Ltd.
June 2026
RFC 5280 defines the profile of X.509 certificates and Certificate Revocation Lists (CRLs) for use in the Internet. Section 4.2.1.3 of RFC 5280 requires CRL issuer certificates to contain the keyUsage extension with the cRLSign bit asserted. However, the CRL validation algorithm specified in Section 6.3 of RFC 5280 does not explicitly include a corresponding check for the presence of the keyUsage certificate extension. This document updates RFC 5280 to require that check.
RFC 5280 は、インターネットで使用する X.509 証明書と証明書失効リスト (CRL) のプロファイルを定義します。RFC 5280 のセクション 4.2.1.3 では、CRL 発行者証明書に cRLSign ビットがアサートされた keyUsage 拡張を含めることを要求しています。ただし、RFC 5280 のセクション 6.3 で指定されている CRL 検証アルゴリズムには、keyUsage 証明書拡張子の存在に対する対応するチェックが明示的に含まれていません。この文書は、そのチェックを要求するために RFC 5280 を更新します。
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/rfc10007.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc10007 で入手できます。
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
2. Conventions and Definitions
3. The Risk of Trusting CRLs Signed with Non-Certified Keys
4. Checking the Presence of the keyUsage Extension
5. Security Considerations
6. IANA Considerations
7. Normative References
Acknowledgments
Authors' Addresses
[RFC5280] defines the profile of X.509 certificates and certificate revocation lists (CRLs) for use in the Internet. Section 4.2.1.3 of [RFC5280] requires CRL issuer certificates to contain the keyUsage extension with the cRLSign bit asserted. However, the CRL validation algorithm specified in Section 6.3 of [RFC5280] does not explicitly include a corresponding check for the presence of the keyUsage certificate extension. This document updates [RFC5280] to require that check.
[RFC5280] は、インターネットで使用する X.509 証明書と証明書失効リスト (CRL) のプロファイルを定義します。[RFC5280] のセクション 4.2.1.3 では、CRL 発行者証明書に cRLSign ビットがアサートされた keyUsage 拡張を含めることを要求しています。しかし、[RFC5280] のセクション 6.3 で指定されている CRL 検証アルゴリズムには、keyUsage 証明書拡張子の存在に対する対応するチェックが明示的に含まれていません。この文書は、そのチェックを要求するために [RFC5280] を更新します。
Section 3 describes the security concern that motivates this update.
セクション 3 では、このアップデートの動機となっているセキュリティ上の懸念について説明します。
Section 4 updates the CRL validation algorithm (Section 6.3 of [RFC5280]) to resolve this concern.
セクション 4 では、この懸念を解決するために CRL 検証アルゴリズム ([RFC5280] のセクション 6.3) を更新しています。
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] で説明されているように解釈されます。
In some Public Key Infrastructures, entities are delegated by Certification Authorities (CAs) to sign CRLs. CRLs whose scope encompasses certificates that have not been signed by the CRL issuer are known as "indirect CRLs".
一部の公開鍵インフラストラクチャでは、エンティティは CRL に署名するために認証局 (CA) によって委任されます。CRL 発行者によって署名されていない証明書を範囲に含む CRL は、「間接 CRL」と呼ばれます。
Applications that consume CRLs follow the validation algorithm as specified in Section 6.3 of [RFC5280]. In particular, Section 6.3.3 of [RFC5280] contains the following step for CRL validation:
CRL を使用するアプリケーションは、[RFC5280] のセクション 6.3 で指定されている検証アルゴリズムに従います。特に、[RFC5280] のセクション 6.3.3 には、CRL 検証のための次のステップが含まれています。
(f) Obtain and validate the certification path for the issuer of the complete CRL. The trust anchor for the certification path MUST be the same as the trust anchor used to validate the target certificate. If a key usage extension is present in the CRL issuer's certificate, verify that the cRLSign bit is set.
(f) 完全な CRL の発行者の証明書パスを取得して検証します。証明書パスのトラスト アンカーは、ターゲット証明書の検証に使用されるトラスト アンカーと同じでなければなりません。CRL 発行者の証明書にキー使用法の拡張が存在する場合は、cRLSign ビットが設定されていることを確認します。
This step does not explicitly specify a check for the presence of the keyUsage extension itself.
このステップでは、keyUsage 拡張機能自体の存在のチェックを明示的に指定しません。
Similarly, the certificate profile in Section 4 of [RFC5280] does not require the inclusion of the keyUsage extension in a certificate if the certified public key is not used for verifying the signatures of other certificates or CRLs.
同様に、[RFC5280] のセクション 4 の証明書プロファイルでは、認証された公開鍵が他の証明書または CRL の署名の検証に使用されない場合、証明書に keyUsage 拡張機能を含める必要はありません。
CAs can delegate the issuance of CRLs to other entities by issuing to the entity a certificate that asserts the cRLSign bit in the keyUsage extension. The CA will then sign certificates that fall within the scope of the indirect CRL by including the crlDistributionPoints extension (Section 4.2.1.13 of [RFC5280]) and specifying the distinguished name (DN) of the CRL issuer in the cRLIssuer field of the corresponding distribution point.
CA は、keyUsage 拡張機能の cRLSign ビットをアサートする証明書をエンティティに発行することで、CRL の発行を他のエンティティに委任できます。次に CA は、crlDistributionPoints 拡張機能 ([RFC5280] のセクション 4.2.1.13) を含め、対応する配布ポイントの cRLIssuer フィールドに CRL 発行者の識別名 (DN) を指定することにより、間接 CRL の範囲内にある証明書に署名します。
The CRL issuer signs CRLs that assert the indirectCRL boolean within the issuingDistributionPoint extension.
CRL 発行者は、issuesDistributionPoint 拡張機能内で indirectCRL ブール値をアサートする CRL に署名します。
The allowance for the issuance of certificates without the keyUsage extension and the lack of a check for the inclusion of the keyUsage extension during CRL verification can manifest in a security issue. A concrete example is described below:
keyUsage 拡張機能なしで証明書の発行が許可されていること、および CRL 検証中に keyUsage 拡張機能が含まれているかどうかのチェックが欠如していることは、セキュリティ上の問題として現れる可能性があります。具体的な例を以下に説明します。
1. The CA signs an end-entity CRL issuer certificate to subject X that certifies key A for signing CRLs by explicitly including the keyUsage extension and asserting the cRLSign bit in accordance with Section 4.2.1.3 of [RFC5280].
1. CA は、[RFC5280] のセクション 4.2.1.3 に従って、明示的に keyUsage 拡張を含め、cRLSign ビットをアサートすることにより、CRL に署名するための鍵 A を証明するエンドエンティティ CRL 発行者証明書にサブジェクト X に署名します。
2. The CA signs one or more certificates that include the crlDistributionPoints extension with the DN for subject X included in the cRLIssuer field. This indicates that the CRL-based revocation information for these certificates will be provided by subject X.
2. CA は、cRLIssuer フィールドに含まれるサブジェクト X の DN を使用して、crlDistributionPoints 拡張子を含む 1 つ以上の証明書に署名します。これは、これらの証明書の CRL ベースの失効情報がサブジェクト X によって提供されることを示します。
3. The CA signs an end-entity certificate to subject X that certifies key B. This certificate contains no key usage extension, as the certified key is not intended to be used for signing CRLs and could be a "mundane" certificate of any type (e.g., S/MIME, a document signing certificate where the corresponding private key is stored on the file system of the secretary's laptop, etc.).
3. CA は、鍵 B を証明するサブジェクト X に対してエンドエンティティ証明書に署名します。証明された鍵は CRL の署名に使用されることを意図しておらず、任意のタイプの「平凡な」証明書 (S/MIME、対応する秘密鍵が秘書のラップトップのファイル システムに保存されている文書署名証明書など) である可能性があるため、この証明書には鍵使用法の拡張が含まれていません。
4. Subject X signs a CRL using key B and publishes the CRL at the distributionPoint field specified in the crlDistributionPoints extension of the certificates signed in step 2.
4. サブジェクト X は、キー B を使用して CRL に署名し、手順 2 で署名された証明書の crlDistributionPoints 拡張機能で指定された distributionPoint フィールドで CRL を公開します。
5. Relying parties download the CRL published in step 4. The CRL validates successfully according to Section 6.3.3 of [RFC5280], as the CRL issuer DN matches, and the check for the presence of the cRLSign bit in the keyUsage extension is skipped because the keyUsage extension is absent.
5. 証明書利用者は、ステップ 4 で公開された CRL をダウンロードします。 CRL は、CRL 発行者の DN が一致するため、[RFC5280] のセクション 6.3.3 に従って正常に検証され、keyUsage 拡張機能が存在しないため、keyUsage 拡張機能内の cRLSign ビットの存在のチェックはスキップされます。
To remediate the security issue described in Section 3, this document specifies the following amendment to step (f) of the CRL algorithm as specified in Section 6.3.3 of [RFC5280].
セクション 3 で説明されているセキュリティ問題を修正するために、この文書は [RFC5280] のセクション 6.3.3 で指定されている CRL アルゴリズムのステップ (f) に対する次の修正を指定します。
_OLD:_
_古い：_
(f) Obtain and validate the certification path for the issuer of the complete CRL. The trust anchor for the certification path MUST be the same as the trust anchor used to validate the target certificate. If a key usage extension is present in the CRL issuer's certificate, verify that the cRLSign bit is set.
(f) 完全な CRL の発行者の証明書パスを取得して検証します。証明書パスのトラスト アンカーは、ターゲット証明書の検証に使用されるトラスト アンカーと同じでなければなりません。CRL 発行者の証明書にキー使用法の拡張が存在する場合は、cRLSign ビットが設定されていることを確認します。
_NEW:_
_新しい：_
(f) Obtain and validate the certification path for the issuer of the complete CRL. The trust anchor for the certification path MUST be the same as the trust anchor used to validate the target certificate. If the version of the CRL issuer's certificate is version 3 (v3), then verify that the key usage extension is present and verify that the cRLSign bit is set.
(f) 完全な CRL の発行者の証明書パスを取得して検証します。証明書パスのトラスト アンカーは、ターゲット証明書の検証に使用されるトラスト アンカーと同じでなければなりません。CRL 発行者の証明書のバージョンがバージョン 3 (v3) の場合は、キー使用法の拡張機能が存在することを確認し、cRLSign ビットが設定されていることを確認します。
This change ensures that the CRL issuer's key is certified for CRL signing. However, this check is not performed if the CRL issuer's key is certified using a version 1 (v1) or version 2 (v2) X.509 certificate, as these versions do not have an extensions field where the key usage extension can be included.
この変更により、CRL 発行者のキーが CRL 署名に対して認証されるようになります。ただし、CRL 発行者のキーがバージョン 1 (v1) またはバージョン 2 (v2) の X.509 証明書を使用して認証されている場合、これらのバージョンにはキー使用法の拡張機能を含めることができる拡張フィールドがないため、このチェックは実行されません。
If a CA has signed certificates to be used for CRL verification but do not include the keyUsage extension in accordance with Section 4.2.1.3 of [RFC5280], then relying party applications that have implemented the modified verification algorithm as specified in this document will be unable to verify CRLs signed by the CRL issuer in question.
CA が CRL 検証に使用される証明書に署名しているが、[RFC5280] のセクション 4.2.1.3 に従って keyUsage 拡張が含まれていない場合、この文書で指定されている変更された検証アルゴリズムを実装している証明書利用者アプリケーションは、問題の CRL 発行者によって署名された CRL を検証できなくなります。
It is RECOMMENDED that CAs include the keyUsage extension in certificates to be used for CRL verification to ensure that there are no interoperability issues where updated applications are unable to verify CRLs.
更新されたアプリケーションが CRL を検証できないという相互運用性の問題が発生しないように、CA は CRL 検証に使用される証明書に keyUsage 拡張機能を含めることが推奨されます。
If it is not possible to update the profile of CRL issuer certificates, then the policy management authority of the affected Public Key Infrastructure SHOULD update the subject naming requirements to ensure that certificates to be used for different purposes contain unique DNs.
CRL 発行者証明書のプロファイルを更新できない場合、影響を受ける公開鍵インフラストラクチャのポリシー管理機関は、サブジェクトの命名要件を更新して、さまざまな目的で使用される証明書に一意の DN が含まれるようにする必要があります (SHOULD)。
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>.
The authors would like to thank the participants on the LAMPS Working Group mailing list for their insightful feedback and comments. In particular, the authors extend sincere appreciation to Carl Wallace, David Hook, Deb Cooley, John Gray, Michael StJohns, Mike Ounsworth, Mohamed Boucadair, Russ Housley, Serge Mister, and Tomas Gustavsson for their reviews and suggestions, which greatly improved the quality of this document.
著者らは、LAMPS ワーキング グループ メーリング リストの参加者の洞察力に富んだフィードバックとコメントに感謝したいと思います。特に、著者らは、このドキュメントの品質を大幅に向上させた、Carl Wallace、David Hook、Deb Cooley、John Gray、Michael StJohns、Mike Ounsworth、Mohamed Boucadair、Russ Housley、Serge Mister、および Tomas Gustavsson のレビューと提案に心から感謝の意を表します。
Corey Bonnell
DigiCert, Inc.
Email: corey.bonnell@digicert.com
Tadahiko Ito
SECOM CO., LTD.
Email: tadahiko.ito.public@gmail.com
Additional contact information:
伊藤 忠彦
セコム株式会社
Tomofumi Okubo
Penguin Securities Pte. Ltd.
Email: tomofumi.okubo+ietf@gmail.com
Additional contact information:
大久保 智史
Penguin Securities Pte. Ltd.