Internet Engineering Task Force (IETF) H. Brockhaus
Request for Comments: 9810 D. von Oheimb
Obsoletes: 4210, 9480 Siemens
Updates: 5912 M. Ounsworth
Category: Standards Track J. Gray
ISSN: 2070-1721 Entrust
July 2025
This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides interactions between client systems and PKI components such as a Registration Authority (RA) and a Certification Authority (CA).
このドキュメントでは、インターネットX.509公開キーインフラストラクチャ（PKI）証明書管理プロトコル（CMP）について説明しています。プロトコルメッセージは、x.509v3証明書の作成と管理に対して定義されます。CMPは、クライアントシステムと登録機関（RA）や認定機関（CA）などのPKIコンポーネントとの相互作用を提供します。
This document adds support for management of certificates containing a Key Encapsulation Mechanism (KEM) public key and uses EnvelopedData instead of EncryptedValue. This document also includes the updates specified in Section 2 and Appendix A.2 of RFC 9480.
このドキュメントは、キーカプセル化メカニズム（KEM）の公開キーを含む証明書の管理のサポートを追加し、暗号化されたバリューではなく封筒を使用します。このドキュメントには、RFC 9480のセクション2および付録A.2で指定された更新も含まれています。
This document obsoletes RFC 4210, and together with RFC 9811, it also obsoletes RFC 9480. Appendix F of this document updates Section 9 of RFC 5912.
このドキュメントはRFC 4210を廃止し、RFC 9811とともに、RFC 9480を廃止します。このドキュメントの付録Fは、RFC 5912のセクション9を更新します。
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/rfc9810.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9810で取得できます。
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ライセンステキストを含める必要があります。
1. Introduction
1.1. Changes Made by RFC 4210
1.2. Updates Made by RFC 9480
1.3. Changes Made by This Document
2. Terminology and Abbreviations
3. PKI Management Overview
3.1. PKI Management Model
3.1.1. Definitions of PKI Entities
3.1.1.1. Subjects and End Entities
3.1.1.2. Certification Authority
3.1.1.3. Registration Authority
3.1.1.4. Key Generation Authority
3.1.2. PKI Management Requirements
3.1.3. PKI Management Operations
4. Assumptions and Restrictions
4.1. End Entity Initialization
4.2. Initial Registration/Certification
4.2.1. Criteria Used
4.2.1.1. Initiation of Registration/Certification
4.2.1.2. End Entity Message Origin Authentication
4.2.1.3. Location of Key Generation
4.2.1.4. Confirmation of Successful Certification
4.2.2. Initial Registration/Certification Schemes
4.2.2.1. Centralized Scheme
4.2.2.2. Basic Authenticated Scheme
4.3. POP of Private Key
4.3.1. Signature Keys
4.3.2. Encryption Keys
4.3.3. Key Agreement Keys
4.3.4. KEM Keys
4.4. Root CA Key Update
4.4.1. CA Operator Actions
4.4.2. Verifying Certificates
4.4.2.1. Verification in Cases 1 and 4
4.4.2.2. Verification in Case 2
4.4.2.3. Verification in Case 3
4.4.3. Revocation - Change of the CA Key
4.5. EKU for PKI Entities
5. Data Structures
5.1. Overall PKI Message
5.1.1. PKI Message Header
5.1.1.1. ImplicitConfirm
5.1.1.2. ConfirmWaitTime
5.1.1.3. OrigPKIMessage
5.1.1.4. CertProfile
5.1.1.5. KemCiphertextInfo
5.1.2. PKI Message Body
5.1.3. PKI Message Protection
5.1.3.1. Shared Secret Information
5.1.3.2. DH Key Pairs
5.1.3.3. Signature
5.1.3.4. Key Encapsulation
5.1.3.5. Multiple Protection
5.2. Common Data Structures
5.2.1. Requested Certificate Contents
5.2.2. Encrypted Values
5.2.3. Status Codes and Failure Information for PKI Messages
5.2.4. Certificate Identification
5.2.5. Out-of-Band Root CA Public Key
5.2.6. Archive Options
5.2.7. Publication Information
5.2.8. POP Structures
5.2.8.1. raVerified
5.2.8.2. POPOSigningKey Structure
5.2.8.3. POPOPrivKey Structure
5.2.8.4. Summary of POP Options
5.2.9. GeneralizedTime
5.3. Operation-Specific Data Structures
5.3.1. Initialization Request
5.3.2. Initialization Response
5.3.3. Certification Request
5.3.4. Certification Response
5.3.5. Key Update Request Content
5.3.6. Key Update Response Content
5.3.7. Key Recovery Request Content
5.3.8. Key Recovery Response Content
5.3.9. Revocation Request Content
5.3.10. Revocation Response Content
5.3.11. Cross-Certification Request Content
5.3.12. Cross-Certification Response Content
5.3.13. CA Key Update Announcement Content
5.3.14. Certificate Announcement
5.3.15. Revocation Announcement
5.3.16. CRL Announcement
5.3.17. PKI Confirmation Content
5.3.18. Certificate Confirmation Content
5.3.19. PKI General Message Content
5.3.19.1. CA Protocol Encryption Certificate
5.3.19.2. Signing Key Pair Types
5.3.19.3. Encryption / Key Agreement Key Pair Types
5.3.19.4. Preferred Symmetric Algorithm
5.3.19.5. Updated CA Key Pair
5.3.19.6. CRL
5.3.19.7. Unsupported Object Identifiers
5.3.19.8. Key Pair Parameters
5.3.19.9. Revocation Passphrase
5.3.19.10. ImplicitConfirm
5.3.19.11. ConfirmWaitTime
5.3.19.12. Original PKIMessage
5.3.19.13. Supported Language Tags
5.3.19.14. CA Certificates
5.3.19.15. Root CA Update
5.3.19.16. Certificate Request Template
5.3.19.17. CRL Update Retrieval
5.3.19.18. KEM Ciphertext
5.3.20. PKI General Response Content
5.3.21. Error Message Content
5.3.22. Polling Request and Response
6. Mandatory PKI Management Functions
6.1. Root CA Initialization
6.2. Root CA Key Update
6.3. Subordinate CA Initialization
6.4. CRL Production
6.5. PKI Information Request
6.6. Cross-Certification
6.6.1. One-Way Request-Response Scheme
6.7. End Entity Initialization
6.7.1. Acquisition of PKI Information
6.7.2. Out-of-Band Verification of the Root CA Key
6.8. Certificate Request
6.9. Key Update
7. Version Negotiation
7.1. Supporting RFC 2510 Implementations
7.1.1. Clients Talking to RFC 2510 Servers
7.1.2. Servers Receiving Version cmp1999 PKIMessages
8. Security Considerations
8.1. On the Necessity of POP
8.2. POP with a Decryption Key
8.3. POP by Exposing the Private Key
8.4. Attack Against DH Key Exchange
8.5. Perfect Forward Secrecy
8.6. Private Keys for Certificate Signing and CMP Message
Protection
8.7. Entropy of Random Numbers, Key Pairs, and Shared Secret
Information
8.8. Recurring Usage of KEM Keys for Message Protection
8.9. Trust Anchor Provisioning Using CMP Messages
8.10. Authorizing Requests for Certificates with Specific EKUs
8.11. Usage of CT Logs
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Reasons for the Presence of RAs
Appendix B. The Use of Revocation Passphrase
Appendix C. PKI Management Message Profiles (REQUIRED)
C.1. General Rules for Interpretation of These Profiles
C.2. Algorithm Use Profile
C.3. POP Profile
C.4. Initial Registration/Certification (Basic Authenticated
Scheme)
C.5. Certificate Request
C.6. Key Update Request
Appendix D. PKI Management Message Profiles (OPTIONAL)
D.1. General Rules for Interpretation of These Profiles
D.2. Algorithm Use Profile
D.3. Self-Signed Certificates
D.4. Root CA Key Update
D.5. PKI Information Request/Response
D.6. Cross-Certification Request/Response (1-way)
D.7. In-Band Initialization Using External Identity Certificate
Appendix E. Variants of Using KEM Keys for PKI Message Protection
Appendix F. Compilable ASN.1 Definitions
Acknowledgements
Authors' Addresses
This document describes the Internet X.509 PKI CMP. Protocol messages are defined for certificate creation and management. The term "certificate" in this document refers to an X.509v3 certificate as defined in [RFC5280].
このドキュメントでは、インターネットx.509 PKI CMPについて説明しています。プロトコルメッセージは、証明書の作成と管理のために定義されています。このドキュメントの「証明書」という用語は、[RFC5280]で定義されているX.509V3証明書を指します。
[RFC4210] differs from [RFC2510] in the following areas:
[RFC4210]は、次の領域で[RFC2510]とは異なります。
* The PKI management message profile section is split to two appendices: the required profile and the optional profile. Some of the formerly mandatory functionality is moved to the optional profile.
* PKI管理メッセージプロファイルセクションは、必要なプロファイルとオプションプロファイルの2つの付録に分割されます。以前の必須機能の一部は、オプションのプロファイルに移動されます。
* The message confirmation mechanism has changed substantially.
* メッセージ確認メカニズムは大幅に変化しました。
* A new polling mechanism is introduced, deprecating the old polling method at the CMP transport level.
* CMP輸送レベルで古いポーリング方法を非難し、新しいポーリングメカニズムが導入されています。
* The CMP transport protocol issues are handled in a separate document [RFC6712], thus the "Transports" section is removed.
* CMPトランスポートプロトコルの問題は、別のドキュメント[RFC6712]で処理されるため、「輸送」セクションが削除されます。
* A new implicit confirmation method is introduced to reduce the number of protocol messages exchanged in a transaction.
* トランザクションで交換されるプロトコルメッセージの数を減らすために、新しい暗黙の確認方法が導入されています。
* The new specification contains some less prominent protocol enhancements and improved explanatory text on several issues.
* 新しい仕様には、いくつかの顕著なプロトコルの強化といくつかの問題に関する説明テキストが改善されています。
CMP Updates [RFC9480] and CMP Algorithms [RFC9481] updated [RFC4210], supporting the PKI management operations specified in the Lightweight CMP Profile [RFC9483], in the following areas:
CMPは[RFC9480]およびCMPアルゴリズム[RFC9481]を更新し、[RFC4210]を更新し、次の領域で軽量CMPプロファイル[RFC9483]で指定されたPKI管理操作をサポートします。
* Added new extended key usages (EKUs) for various CMP server types, e.g., RA and CA, to express the authorization of the certificate holder that acts as the indicated type of PKI management entity.
* さまざまなCMPサーバータイプ、たとえばRAやCAの新しい拡張キー使用法（EKU）を追加して、指定されたタイプのPKI管理エンティティとして機能する証明書所有者の承認を表明しました。
* Extended the description of multiple protection to cover additional use cases, e.g., batch processing of messages.
* 追加のユースケース、たとえばメッセージのバッチ処理をカバーするために、複数の保護の説明を拡張しました。
* Used the Cryptographic Message Syntax (CMS) [RFC5652] type EnvelopedData as the preferred choice instead of EncryptedValue to better support crypto agility in CMP.
* 暗号化されたメッセージの構文（CMS）[RFC5652]を使用して、CMPの暗号性の俊敏性をより適切にサポートするために、暗号化されたバリューの代わりに、封筒として優先選択としてタイプを使用しました。
For reasons of completeness and consistency, the type EncryptedValue has been exchanged in all occurrences. This includes the protection of centrally generated private keys, encryption of certificates, Proof-of-Possession (POP) methods, and protection of revocation passphrases. To properly differentiate the support of EnvelopedData instead of EncryptedValue, CMP version 3 is introduced in case a transaction is supposed to use EnvelopedData.
完全性と一貫性の理由により、タイプの暗号化されたバリューはすべての出来事で交換されています。これには、中央に生成されたプライベートキーの保護、証明書の暗号化、所有証明（POP）方法、および取り消しパスフレーゼの保護が含まれます。暗号化されたValueの代わりにEnvelopedDataのサポートを適切に区別するために、CMPバージョン3は、トランザクションがEnvelopedDataを使用することになっている場合に導入されます。
Note: According to point 9 in Section 2.1 of [RFC4211], the use of the EncryptedValue structure has been deprecated in favor of the EnvelopedData structure. [RFC4211] offers the EncryptedKey structure a choice of EncryptedValue and EnvelopedData for migration to EnvelopedData.
注：[RFC4211]のセクション2.1のポイント9によると、暗号化された値構造の使用は、封筒構造を支持して非推奨されています。[RFC4211]は、暗号化されたキー構造に、暗号化されたバリューと封筒の選択の選択を提供します。
* Offered an optional hashAlg field in CertStatus supporting cases when a certificate needs to be confirmed, but the certificate was signed using a signature algorithm that does not indicate a specific hash algorithm to use for computing the certHash. This is also in preparation for upcoming post-quantum algorithms.
* 証明書を確認する必要がある場合、証明書をサポートするケースをサポートするcertStatusでオプションのハスハルグフィールドを提供しましたが、証明書は、Certhashの計算に使用する特定のハッシュアルゴリズムを示さない署名アルゴリズムを使用して署名されました。これは、今後のQuantum後のアルゴリズムにも備えています。
* Added new general message types to request CA certificates, a root CA update, a certificate request template, or Certificate Revocation List (CRL) updates.
* CA証明書、ルートCAアップデート、証明書リクエストテンプレート、または証明書の取り消しリスト（CRL）アップデートを要求する新しい一般的なメッセージタイプが追加されました。
* Extended the use of polling to p10cr, certConf, rr, genm, and error messages.
* ポーリングの使用をP10CR、CERTCONF、RR、GENM、およびエラーメッセージに拡張しました。
* Deleted the mandatory algorithm profile in Appendix C.2 and instead referred to Section 7 of [RFC9481].
* 付録C.2の必須アルゴリズムプロファイルを削除し、代わりに[RFC9481]のセクション7を参照しました。
* Added Sections 8.6, 8.7, 8.9, and 8.10 to the security considerations.
* セキュリティ上の考慮事項にセクション8.6、8.7、8.9、および8.10を追加しました。
This document obsoletes [RFC4210] and [RFC9480].
この文書は、[RFC4210]および[RFC9480]を廃止します。
Backward compatibility with CMP version 2 is maintained wherever possible. Updates to CMP version 2 improve crypto agility, extend the polling mechanism, add new general message types, and add EKUs to identify special CMP server authorizations. CMP version 3 is introduced for changes to the ASN.1 syntax, which support EnvelopedData, certConf with hashAlg, POPOPrivKey with agreeMAC, and RootCaKeyUpdateContent in ckuann messages.
CMPバージョン2との後方互換性は、可能な限り維持されます。CMPバージョン2の更新は、暗号の俊敏性を改善し、ポーリングメカニズムを拡張し、新しい一般的なメッセージタイプを追加し、EKUを追加して特別なCMPサーバーの認可を特定します。CMPバージョン3は、asn.1の構文の変更について導入されます。これは、封筒、hashalgを備えた証明書、ckuannメッセージのrootcakeyupdatecontentをサポートします。
The updates made in this document include the changes specified by Section 2 and Appendix A.2 of [RFC9480] as described in Section 1.2. Additionally, this document updates the content of [RFC4210] in the following areas:
このドキュメントで行われた更新には、セクション1.2で説明されている[RFC9480]のセクション2および付録A.2で指定された変更が含まれます。さらに、このドキュメントは、次の領域の[RFC4210]のコンテンツを更新します。
* Added Section 3.1.1.4 introducing the Key Generation Authority (KGA).
* セクション3.1.1.4を追加して、主要生成局（KGA）を紹介しました。
* Extended Section 3.1.2 regarding use of Certificate Transparency (CT) logs.
* 証明書の透明性（CT）ログの使用に関するセクション3.1.2拡張。
* Updated Section 4.4 introducing RootCaKeyUpdateContent as an alternative to using a repository to acquire new root CA certificates.
* 更新されたセクション4.4 rootcakeyupdatecontentの導入リポジトリを使用して新しいルートCA証明書を取得する代わりに。
* Added Section 5.1.1.3 containing a description of origPKIMessage content, moved here from Section 5.1.3.4.
* セクション5.1.3.4からここに移動したOrigpKimessageコンテンツの説明を含むセクション5.1.1.3を追加しました。
* Added support for KEM keys for POP to Sections 4.3 and 5.2.8, for message protection to Sections 5.1.1 and 5.1.3.4 and Appendix E, and for usage with CMS EnvelopedData to Section 5.2.2.
* セクション4.3および5.2.8へのPOPのKEMキーのサポートを追加し、セクション5.1.1および5.1.3.4および付録Eへのメッセージ保護、およびCMS EnvelopedDataでのセクション5.2.2の使用のためのサポートを追加しました。
* Deprecated CAKeyUpdAnnContent in favor of RootCaKeyUpdateContent.
* rootcakeyupdatecontentを支持して、cakeyupdanncontentを非推奨。
* Incorporated the request message behavioral clarifications from Appendix C of [RFC4210] to Section 5. The definition of altCertTemplate was incorporated into Section 5.2.1, and the clarification on POPOSigningKey and on POPOPrivKey was incorporated into Section 5.2.8.
* [RFC4210]の付録Cから[RFC4210]の付録Cからセクション5までのリクエストメッセージの動作の明確化を組み込みました。AltCertTemplateの定義はセクション5.2.1に組み込まれ、PoposimingKeyおよびPopoprivkeyの明確化がセクション5.2.8に組み込まれました。
* Added support for CMS EnvelopedData to different POP methods for transferring encrypted private keys, certificates, and challenges to Section 5.2.8.
* CMS EnvelopedDataのサポートが、暗号化されたプライベートキー、証明書、およびセクション5.2.8に課題を転送するためのさまざまなPOPメソッドに追加されました。
* Added Sections 8.1, 8.5, 8.8, and 8.11 to the security considerations.
* セキュリティ上の考慮事項にセクション8.1、8.5、8.8、および8.11を追加しました。
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] で説明されているように解釈されます。
This document relies on the terminology defined in [RFC5280]. The most important abbreviations are listed below:
このドキュメントは、[RFC5280]で定義されている用語に依存しています。最も重要な略語を以下に示します。
CA:
CA:
Certification Authority
認証機関
CMP:
CMP:
Certificate Management Protocol
証明書管理プロトコル
CMS:
CMS:
Cryptographic Message Syntax
暗号化メッセージ構文
CRL:
CRL:
Certificate Revocation List
証明書の取り消しリスト
CRMF:
CRMF：
Certificate Request Message Format
証明書リクエストメッセージフォーマット
KEM:
KEM:
Key Encapsulation Mechanism
キーカプセル化メカニズム
KGA:
KGA:
Key Generation Authority
主要な世代の権限
LRA:
LRA:
Local Registration Authority
地方登録機関
MAC:
MAC:
Message Authentication Code
メッセージ認証コード
PKI:
PKI:
Public Key Infrastructure
公開鍵インフラストラクチャ
POP:
POP:
Proof-of-Possession
所有の証明
RA:
RA:
Registration Authority
登録機関
TEE:
TEE:
Trusted Execution Environment
信頼できる実行環境
The PKI must be structured to be consistent with the types of individuals who must administer it. Providing such administrators with unbounded choices not only complicates the software required but also increases the chances that a subtle mistake by an administrator or software developer will result in broader compromise. Similarly, restricting administrators with cumbersome mechanisms will cause them not to use the PKI.
PKIは、それを管理しなければならない個人のタイプと一致するように構成する必要があります。このような管理者に無制限の選択肢を提供することは、必要なソフトウェアを複雑にするだけでなく、管理者またはソフトウェア開発者による微妙な間違いがより広範な妥協をもたらす可能性を高めます。同様に、管理者を扱いにくいメカニズムで制限すると、PKIを使用しません。
Management protocols are REQUIRED to support online interactions between PKI components. For example, a management protocol might be used between a CA and a client system with which a key pair is associated or between two CAs that issue cross-certificates for each other.
PKIコンポーネント間のオンラインインタラクションをサポートするには、管理プロトコルが必要です。たとえば、管理プロトコルは、CAとキーペアが関連付けられているクライアントシステムの間で使用される場合があります。
Before specifying particular message formats and procedures, we first define the entities involved in PKI management and their interactions (in terms of the PKI management functions required). We then group these functions in order to accommodate different identifiable types of end entities.
特定のメッセージ形式と手順を指定する前に、まずPKI管理に関与するエンティティとその相互作用を定義します（必要なPKI管理機能の観点から）。次に、さまざまな識別可能なタイプのエンティティに対応するために、これらの関数をグループ化します。
The entities involved in PKI management include the end entity (i.e., the entity to whom the certificate is issued) and the CA (i.e., the entity that issues the certificate). An RA might also be involved in PKI management.
PKI管理に関与するエンティティには、最終エンティティ（つまり、証明書が発行されるエンティティ）とCA（つまり、証明書を発行するエンティティ）が含まれます。RAはPKI管理にも関与している可能性があります。
The term "subject" is used here to refer to the entity to whom the certificate is issued, typically named in the subject or subjectAltName field of a certificate. When we wish to distinguish the tools and/or software used by the subject (e.g., a local certificate management module), we will use the term "subject equipment". In general, the term "end entity", rather than "subject", is preferred in order to avoid confusion with the field name. It is important to note that the end entities here will include not only human users of applications but also applications themselves (e.g., for Internet Key Exchange Protocol (IKE) / IPsec) or devices (e.g., routers or industrial control systems). This factor influences the protocols that the PKI management operations use; for example, application software is far more likely to know exactly which certificate extensions are required than are human users. PKI management entities are also end entities in the sense that they are sometimes named in the subject or subjectAltName field of a certificate or cross-certificate. Where appropriate, the term "end entity" will be used to refer to end entities who are not PKI management entities.
「件名」という用語は、証明書が発行されるエンティティを指すために使用されます。主題が使用するツールやソフトウェア（現地証明書管理モジュールなど）を区別したい場合は、「主題機器」という用語を使用します。一般に、フィールド名との混乱を避けるために、「主題」よりも「終了エンティティ」という用語が好まれます。ここの最終エンティティには、アプリケーションの人間ユーザーだけでなく、アプリケーション自体（たとえば、インターネットキーエクスチェンジプロトコル（IKE） / IPSEC）またはデバイス（ルーターや産業制御システムなど）も含まれることに注意することが重要です。この要因は、PKI管理操作が使用するプロトコルに影響を与えます。たとえば、アプリケーションソフトウェアは、人間のユーザーよりもどの証明書拡張機能が必要かを正確に知る可能性がはるかに高くなります。PKI管理エンティティは、証明書またはクロス認証の主題またはsubjectnameフィールドで時々命名されるという意味で、エンティティも終了します。必要に応じて、「終了エンティティ」という用語は、PKI管理エンティティではないエンディティを指すために使用されます。
All end entities require secure local access to some information -- at a minimum, their own name and private key, the name of a CA that is directly trusted by this entity, and that CA's public key (or a fingerprint of the public key where a self-certified version is available elsewhere). Implementations MAY use secure local storage for more than this minimum (e.g., the end entity's own certificates or application-specific information). The form of storage will also vary -- from files to tamper-resistant cryptographic tokens. The information stored in such local, trusted storage is referred to here as the end entity's TEE, also known as Personal Security Environment (PSE).
すべてのエンティティには、少なくとも独自の名前、秘密鍵、このエンティティから直接信頼されているCAの名前、およびCAの公開鍵（または自己認証バージョンが他の場所で利用可能な公開鍵の指紋）の名前を安全にアクセスする必要があります。実装は、この最小限よりも安全なローカルストレージを使用する場合があります（例：End Entity独自の証明書またはアプリケーション固有の情報）。ストレージの形式も異なります - ファイルから抵抗性のある暗号化トークンまで。このようなローカルで信頼できるストレージに保存されている情報は、ここでは、個人セキュリティ環境（PSE）としても知られている最終エンティティのティーと呼ばれます。
Though TEE formats are beyond the scope of this document (they are very dependent on equipment, et cetera), a generic interchange format for TEEs is defined here: a certification response message (see Section 5.3.4) MAY be used.
TEE形式はこのドキュメントの範囲を超えていますが（機器などに非常に依存しています）、TEEの一般的な交換形式はここで定義されています。認定応答メッセージ（セクション5.3.4を参照）を使用できます。
The CA may or may not actually be a real "third party" from the end entity's point of view. Quite often, the CA will actually belong to the same organization as the end entities it supports.
CAは、実際には、エンティティの視点から実際に「サードパーティ」である場合があります。多くの場合、CAは実際にサポートする最終エンティティと同じ組織に属します。
Again, we use the term "CA" to refer to the entity named in the issuer field of a certificate. When it is necessary to distinguish the software or hardware tools used by the CA, we use the term "CA equipment".
繰り返しますが、「CA」という用語を使用して、証明書の発行者フィールドで指定されたエンティティを参照します。CAが使用するソフトウェアまたはハードウェアツールを区別する必要がある場合は、「CA機器」という用語を使用します。
The CA equipment will often include both an "offline" component and an "online" component, with the CA private key only available to the "offline" component. This is, however, a matter for implementers (though it is also relevant as a policy issue).
CA機器には、多くの場合、「オフライン」コンポーネントと「オンライン」コンポーネントの両方が含まれ、CAの秘密鍵は「オフライン」コンポーネントのみが利用できます。ただし、これは実装者にとっての問題です（ただし、ポリシーの問題としても関連しています）。
We use the term "root CA" to indicate a CA that is directly trusted by an end entity; that is, securely acquiring the value of a root CA public key requires some out-of-band step(s). This term is not meant to imply that a root CA is necessarily at the top of any hierarchy, simply that the CA in question is trusted directly. The "root CA" may provide its trust anchor information with or without using a certificate. In some circumstances, such a certificate may be self-signed, but in other circumstances, it may be cross-signed, signed by a peer, signed by a superior CA, or unsigned.
「ルートCA」という用語を使用して、最終エンティティによって直接信頼されるCAを示します。つまり、ルートCAの公開キーの価値を安全に取得するには、バンド外のステップが必要です。この用語は、ルートCAが必然的に階層の一番上にあることを意味するものではなく、問題のCAが直接信頼されていることを意味します。「ルートCA」は、証明書の有無にかかわらず、信頼のアンカー情報を提供する場合があります。状況によっては、そのような証明書は自己署名されている場合がありますが、他の状況では、それはクロス署名、ピアによって署名されたり、優れたCAによって署名されたり、署名されていない場合があります。
Note that other documents like [X509.2019] and [RFC5280] use the term "trusted CA" or "trust anchor" instead of "root CA". This document continues using "root CA" based on the above definition because it is also present in the ASN.1 syntax that cannot be changed easily.
[X509.2019]や[RFC5280]などの他のドキュメントは、「ルートCA」ではなく「信頼できるCA」または「信頼アンカー」という用語を使用していることに注意してください。このドキュメントは、上記の定義に基づいて「ルートCA」を使用しています。これは、簡単に変更できないASN.1構文にも存在するためです。
A "subordinate CA" is one that is not a root CA for the end entity in question. Often, a subordinate CA will not be a root CA for any entity, but this is not mandatory.
「下位CA」は、問題の最終エンティティのルートCAではないものです。多くの場合、下位CAはどのエンティティにとってもルートCAではありませんが、これは必須ではありません。
In addition to end entities and CAs, many environments call for the existence of an RA separate from the CA. The functions that the RA may carry out will vary from case to case but MAY include identity checking, token distribution, checking certificate requests and authentication of their origin, revocation reporting, name assignment, archival of key pairs, et cetera.
エンディティとCAに加えて、多くの環境では、CAとは別のRAの存在が必要です。RAが実行する可能性のある機能は、ケースごとに異なりますが、身元確認、トークン分布、オリジンの認証と認証、取り消し報告、名前の割り当て、キーペアのアーカイブ、ET CETERAが含まれる場合があります。
This document views the RA as an OPTIONAL component: When it is not present, the CA is assumed to be able to carry out the RA's functions so that the PKI management protocols are the same from the end entity's point of view.
このドキュメントでは、RAをオプションのコンポーネントと見なします。それが存在しない場合、CAはRAの関数を実行できると想定されているため、PKI管理プロトコルがエンティティの視点から同じになります。
Again, we distinguish, where necessary, between the RA and the tools used (the "RA equipment").
繰り返しますが、必要に応じて、使用されたRAと使用されたツール（「RA装置」）を区別します。
Note that an RA is itself an end entity. We further assume that all RAs are in fact certified end entities and that RAs have private keys that are usable for signing. How a particular CA equipment identifies some end entities as RAs is an implementation issue (i.e., this document specifies no special RA certification operation). We do not mandate that the RA is certified by the CA with which it is interacting at the moment (so one RA may work with more than one CA whilst only being certified once).
RAはそれ自体が最終エンティティであることに注意してください。さらに、すべてのRAが実際に認定された最終エンティティであり、RAには署名に使用できるプライベートキーがあると仮定します。RASが実装の問題であるため、特定のCA機器がいくつかのエンティティを識別する方法（つまり、このドキュメントは特別なRA認証操作を指定していません）。RAが現時点で相互作用しているCAによって認定されていることを義務付けません（したがって、1つのRAは1回しか認定されていないが、複数のCAで動作する可能性があります）。
In some circumstances, end entities will communicate directly with a CA even where an RA is present. For example, for initial registration and/or certification, the end entity may use its RA but communicate directly with the CA in order to refresh its certificate.
状況によっては、最終エンティティはRAが存在する場合でもCAと直接通信します。たとえば、初期登録および/または認定の場合、最終エンティティはRAを使用する場合がありますが、証明書を更新するためにCAと直接通信します。
A KGA is a PKI management entity generating key pairs on behalf of an end entity. As the KGA generates the key pair, it knows the public and the private part.
KGAは、終了エンティティに代わってキーペアを生成するPKI管理エンティティです。KGAがキーペアを生成すると、公衆と私的部分を知っています。
This document views the KGA as an OPTIONAL component. When it is not present and central key generation is needed, the CA is assumed to be able to carry out the KGA's functions so that the PKI management protocol messages are the same from the end entity's point of view. If certain tasks of a CA are delegated to other components, this delegation needs authorization, which can be indicated by EKUs (see Section 4.5).
このドキュメントでは、KGAをオプションのコンポーネントと見なしています。PKI管理プロトコルメッセージが終了エンティティの観点から同じになるように、CAは存在しない場合、CAはKGAの機能を実行できると想定されています。CAの特定のタスクが他のコンポーネントに委任された場合、この代表団はEKUで示される可能性があります（セクション4.5を参照）。
Note: When doing central generation of key pairs, implementers should consider the implications of server-side retention on the overall security of the system; in some cases, retention is good, for example, for escrow reasons, but in other cases, the server should clear its copy after delivery to the end entity.
注：重要なペアの中央生成を行う場合、実装者は、システムの全体的なセキュリティに対するサーバー側の保持の意味を考慮する必要があります。場合によっては、例えばエスクロー上の理由で保持が良好ですが、他の場合には、サーバーはエンティティへの配信後にコピーをクリアする必要があります。
Note: If the CA delegates key generation to a KGA, the KGA can be collocated with the RA.
注：CAがKGAにキージェネレーションを代表する場合、KGAをRAと協力できます。
The protocols given here meet the following requirements on PKI management
ここで与えられたプロトコルは、PKI管理に関する次の要件を満たしています
1. PKI management must conform to the ISO/IEC 9594-8/ITU-T X.509 standards, in particular [X509.2019].
1. PKI管理は、特に[X509.2019]、ISO/IEC 9594-8/ITU-T X.509標準に準拠する必要があります。
2. It must be possible to regularly update any key pair without affecting any other key pair.
2. 他のキーペアに影響を与えることなく、キーペアを定期的に更新することが可能である必要があります。
3. The use of confidentiality in PKI management protocols must be kept to a minimum in order to ease acceptance in environments where strong confidentiality might cause regulatory problems.
3. PKI管理プロトコルでの機密性の使用は、強力な機密性が規制上の問題を引き起こす可能性のある環境での受け入れを容易にするために、最小限に抑える必要があります。
4. PKI management protocols must allow the use of different industry-standard cryptographic algorithms (see CMP Algorithms [RFC9481]). This means that any given CA, RA, or end entity may, in principle, use whichever algorithms suit it for its own key pair(s).
4. PKI管理プロトコルは、さまざまな業界標準の暗号化アルゴリズムの使用を許可する必要があります（CMPアルゴリズム[RFC9481]を参照）。これは、特定のCA、RA、またはENDエンティティが、原則として、独自のキーペアに合わせてどのアルゴリズムを使用するかを使用することを意味します。
5. PKI management protocols must not preclude the generation of key pairs by the end entity concerned, by a KGA, or by a CA. Key generation may also occur elsewhere, but for the purposes of PKI management, we can regard key generation as occurring wherever the key is first present at an end entity, KGA, or CA.
5. PKI管理プロトコルは、関係するエンティティ、KGA、またはCAによって、主要ペアの生成を排除してはなりません。キー生成も他の場所で発生する可能性がありますが、PKI管理の目的のために、キー生成は、キーが終了エンティティ、KGA、またはCAで最初に存在する場合でも発生すると見なすことができます。
6. PKI management protocols must support the publication of certificates by the end entity concerned, by an RA, or by a CA. Different implementations and different environments may choose any of the above approaches.
6. PKI管理プロトコルは、関係するエンティティ、RA、またはCAによって証明書の公開をサポートする必要があります。さまざまな実装とさまざまな環境が、上記のアプローチのいずれかを選択する場合があります。
7. PKI management protocols must support the production of Certificate Revocation Lists (CRLs) by allowing certified end entities to make requests for the revocation of certificates. This must be done in such a way that the denial-of-service attacks, which are possible, are not made simpler.
7. PKI管理プロトコルは、認定エンティティが証明書の取り消しの要求を行うことを許可することにより、証明書取消リスト（CRL）の作成をサポートする必要があります。これは、可能なサービス拒否攻撃がより単純にならないように行う必要があります。
8. PKI management protocols must be usable over a variety of "transport" mechanisms, specifically including email, Hypertext Transfer Protocol (HTTP), Message Queuing Telemetry Transport (MQTT), Constrained Application Protocol (CoAP), and various offline and non-networked file transfer methods.
8. PKI管理プロトコルは、具体的には電子メール、ハイパーテキスト転送プロトコル（HTTP）、メッセージキューイングテレメトリートランスポート（MQTT）、制約付きアプリケーションプロトコル（COAP）、およびさまざまなオフラインおよび非ネットワーク化されたファイル転送方法を含む、さまざまな「輸送」メカニズムで使用できる必要があります。
9. Final authority for certification creation rests with the CA. No RA or end entity equipment can assume that any certificate issued by a CA will contain what was requested; a CA may alter certificate field values or may add, delete, or alter extensions according to its operating policy. In other words, all PKI entities (end entities, RAs, KGAs, and CAs) must be capable of handling responses to requests for certificates in which the actual certificate issued is different from that requested (for example, a CA may shorten the validity period requested). Note that policy may dictate that the CA must not publish or otherwise distribute the certificate until the requesting entity has reviewed and accepted the newly created certificate or the POP is completed. In case of publication of the certificate (when using indirect POP, see Section 8.11) or a precertificate in a CT log [RFC9162], the certificate must be revoked if it was not accepted by the end entity or the POP could not be completed.
9. 認証作成の最終的な権限はCAにかかっています。CAが発行した証明書には、要求されたものが含まれていると想定することはできません。CAは、証明書のフィールド値を変更したり、その運用ポリシーに従って拡張機能を追加、削除、または変更する場合があります。言い換えれば、すべてのPKIエンティティ（END ENTITIES、RAS、KGAS、およびCAS）は、発行された実際の証明書が要求された証明書とは異なる証明書の要求に対する応答を処理できる必要があります（たとえば、CAは要求された有効期間を短くすることができます）。リクエストエンティティが新しく作成された証明書を確認および受け入れるか、POPが完了するまで、CAが証明書を公開またはその他の方法で配布してはならないことをポリシーが指示する場合があることに注意してください。証明書の公開（間接POPを使用する場合は、セクション8.11を参照）またはCTログ[RFC9162]の事前認証の場合、最終エンティティによって受け入れられなかった場合、またはPOPが完了できなかった場合、証明書を取り消す必要があります。
10. A graceful, scheduled changeover from one non-compromised CA key pair to the next (CA key update) must be supported (note that if the CA key is compromised, re-initialization must be performed for all entities in the domain of that CA). An end entity whose TEE contains the new CA public key (following a CA key update) may also need to be able to verify certificates verifiable using the old public key. End entities who directly trust the old CA key pair may also need to be able to verify certificates signed using the new CA private key (required for situations where the old CA public key is "hardwired" into the end entity's cryptographic equipment).
10. 1つの非競合化されていないCAキーペアから次の（CAキーアップデート）への優雅なスケジュールされた切り替えをサポートする必要があります（CAキーが侵害された場合、そのCAのドメイン内のすべてのエンティティに対して再目立化を実行する必要があることに注意してください）。TEEに新しいCA公開キー（CAキーの更新に続く）が含まれているエンドエンティティは、古い公開キーを使用して検証可能な証明書を検証できる必要がある場合があります。古いCAキーペアを直接信頼するエンディティは、新しいCAの秘密鍵を使用して署名された証明書を検証できる必要がある場合があります（古いCAの公開キーが最終エンティティの暗号化機器に「ハードワイヤード」である状況に必要です）。
11. The functions of an RA may, in some implementations or environments, be carried out by the CA itself. The protocols must be designed so that end entities will use the same protocol regardless of whether the communication is with an RA or CA. Naturally, the end entity must use the correct RA or CA public key to verify the protection of the communication.
11. RAの機能は、いくつかの実装または環境で、CA自体によって実行される場合があります。プロトコルは、通信がRAまたはCAにあるかどうかに関係なく、エンディティが同じプロトコルを使用するように設計する必要があります。当然、最終エンティティは正しいRAまたはCAの公開キーを使用して、通信の保護を検証する必要があります。
12. Where an end entity requests a certificate containing a given public key value, the end entity must be ready to demonstrate possession of the corresponding private key value. This may be accomplished in various ways, depending on the type of certification request. See Section 4.3 for details of the in-band methods defined for the PKIX-CMP (i.e., CMP) messages.
12. 終了エンティティが特定の公開キー値を含む証明書を要求する場合、最終エンティティは、対応する秘密キー値の所有を実証する準備ができている必要があります。これは、認証要求の種類に応じて、さまざまな方法で達成できます。PKIX-CMP（つまり、CMP）メッセージに対して定義された帯域内のメソッドの詳細については、セクション4.3を参照してください。
The following diagram shows the relationship between the entities defined above in terms of the PKI management operations. The letters in the diagram indicate "protocols" in the sense that a defined set of PKI management messages can be sent along each of the lettered lines.
次の図は、PKI管理操作に関して上記のエンティティ間の関係を示しています。図の文字は、定義されたPKI管理メッセージのセットを各文字行に沿って送信できるという意味で「プロトコル」を示しています。
+---+ cert. publish +------------+ j
| | <--------------------- | End Entity | <-------
| C | g +------------+ "out-of-band"
| e | | ^ loading
| r | | | initial
| t | a | | b registration/
| | | | certification
| / | | | key pair recovery
| | | | key pair update
| C | | | certificate update
| R | PKI "USERS" V | revocation request
| L | -------------------+-+-----+-+------+-+-------------------
| | PKI MANAGEMENT | ^ | ^
| | ENTITIES a | | b a | | b
| R | V | | |
| e | g +------+ d | |
| p | <------------ | RA | <-----+ | |
| o | cert. | | ----+ | | |
| s | publish +------+ c | | | |
| i | | | | |
| t | V | V |
| o | g +------------+ i
| r | <------------------------| CA |------->
| y | h +------------+ "out-of-band"
| | cert. publish | ^ publication
| | CRL publish | |
+---+ | | cross-certification
e | | f cross-certificate
| | update
| |
V |
+------+
| CA-2 |
+------+
Figure 1: PKI Entities
図1：PKIエンティティ
At a high level, the set of operations for which management messages are defined can be grouped as follows.
高レベルでは、管理メッセージが定義される一連の操作を次のようにグループ化できます。
1. CA establishment: When establishing a new CA, certain steps are required (e.g., production of initial CRLs and export of CA public key).
1. CA設立：新しいCAを確立するとき、特定の手順が必要です（例：初期CRLの生産とCA公開鍵の輸出）。
2. End entity initialization: This includes importing a root CA public key and requesting information about the options supported by a PKI management entity.
2. End Entityの初期化：これには、ルートCAの公開キーのインポートと、PKI管理エンティティによってサポートされているオプションに関する情報の要求が含まれます。
3. Certification: Various operations result in the creation of new certificates:
3. 認定：さまざまな操作により、新しい証明書が作成されます。
a. initial registration/certification: This is the process whereby an end entity first makes itself known to a CA or RA, prior to the CA issuing a certificate or certificates for that end entity. The end result of this process (when it is successful) is that a CA issues a certificate for an end entity's public key and returns that certificate to the end entity and/or posts that certificate in a repository. This process may, and typically will, involve multiple "steps", possibly including an initialization of the end entity's equipment. For example, the end entity's equipment must be securely initialized with the public key of a CA, e.g., using zero-touch methods like Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995] or Secure Zero Touch Provisioning (SZTP) [RFC8572], to be used in validating certificate paths. Furthermore, an end entity typically needs to be initialized with its own key pair(s).
a. 初期登録/認証：これは、CAがその最終エンティティの証明書または証明書を発行する前に、最終エンティティが最初にCAまたはRAに自分自身を知られるプロセスです。このプロセスの最終結果（成功した場合）は、CAがEnd End Entityの公開キーの証明書を発行し、その証明書をEnd Entityおよび/またはその証明書にリポジトリに投稿することです。このプロセスは、最終エンティティの機器の初期化を含む、複数の「ステップ」が含まれる場合があります。たとえば、End Entityの機器は、CAの公開鍵で安全に初期化する必要があります。たとえば、リモートセキュアなキーインフラストラクチャ（BRSKI）[RFC8995] [RFC8995]またはセキュアゼロタッチプロビジョニング（SZTP）[RFC8572]などのゼロタッチメソッドを使用して、証明書パスを確認するために使用します。さらに、最終エンティティは通常、独自のキーペアで初期化する必要があります。
b. key pair update: Every key pair needs to be updated regularly (i.e., replaced with a new key pair), and a new certificate needs to be issued.
b. キーペアの更新：すべてのキーペアを定期的に更新する必要があり（つまり、新しいキーペアに置き換えられます）、新しい証明書を発行する必要があります。
c. certificate update: As certificates expire, they may be "refreshed" if nothing relevant in the environment has changed.
c. 証明書の更新：証明書が期限切れになると、環境に関連するものが変更されていない場合、「リフレッシュ」される可能性があります。
d. CA key pair update: As with end entities, CA key pairs need to be updated regularly; however, different mechanisms are required.
d. CAキーペアの更新：END ENTITIESと同様に、CAキーペアを定期的に更新する必要があります。ただし、さまざまなメカニズムが必要です。
e. cross-certification request: One CA requests issuance of a cross-certificate from another CA. For the purposes of this standard, the following terms are defined. A "cross-certificate" is a certificate in which the subject CA and the issuer CA are distinct and SubjectPublicKeyInfo contains a verification key (i.e., the certificate has been issued for the subject CA's signing key pair). When it is necessary to distinguish more finely, the following terms may be used: A cross-certificate is called an "inter-domain cross-certificate" if the subject and issuer CAs belong to different administrative domains; it is called an "intra-domain cross-certificate" otherwise.
e. 相互認証要求：あるCAは、別のCAから相互認証の発行を要求します。この基準の目的のために、次の用語が定義されています。「クロス認証」は、対象CAおよび発行者CAが明確であり、件名PublicKeyInfoが検証キーを含む証明書です（つまり、被験者のCAの署名キーペアに対して証明書が発行されました）。より細かく区別する必要がある場合、次の用語を使用できます。クロス認証は、被験者と発行者CAが異なる管理ドメインに属している場合、「ドメイン間の相互認証」と呼ばれます。それ以外の場合は、「ドメイン内クロス認証」と呼ばれます。
Note 1: The above definition of "cross-certificate" aligns with the defined term "CA-certificate" in X.509. Note that this term is not to be confused with the X.500 "cACertificate" attribute type, which is unrelated.
注1：上記の「クロス認証」の定義は、X.509の定義された用語「Ca certificate」と一致します。この用語は、無関係のX.500 "cacertificate"属性タイプと混同しないことに注意してください。
Note 2: In many environments, the term "cross-certificate", unless further qualified, will be understood to be synonymous with "inter-domain cross-certificate" as defined above.
注2：多くの環境では、「クロス認証」という用語は、さらに資格を与えない限り、上記のように「ドメイン間の相互認証」と同義であると理解されます。
Note 3: Issuance of cross-certificates may be, but is not necessarily, mutual; that is, two CAs may issue cross-certificates for each other.
注3：クロス認証の発行は、必ずしも相互にあるとは限りません。つまり、2つのCASが相互に相互に認証される可能性があります。
f. cross-certificate update: Similar to a normal certificate update but involving a cross-certificate.
f. クロス認証の更新：通常の証明書の更新と同様ですが、クロス認証が含まれます。
4. Certificate/CRL discovery operations: Some PKI management operations result in the publication of certificates or CRLs:
4. 証明書/CRL発見操作：一部のPKI管理操作により、証明書またはCRLの公開が発生します。
a. certificate publication: Having gone to the trouble of producing a certificate, some means for publishing may be needed. The "means" defined in PKIX MAY involve the messages specified in Sections 5.3.13 to 5.3.16 or MAY involve other methods (for example, Lightweight Directory Access Protocol (LDAP)) as described in [RFC4511] or [RFC2585] (the "Operational Protocols" documents of the PKIX series of specifications).
a. 証明書の公開：証明書を作成する問題に取り組んだ場合、公開のための何らかの手段が必要になる場合があります。PKIXで定義されている「平均」には、セクション5.3.13から5.3.16で指定されたメッセージが含まれる場合があります。または、[RFC4511]または[RFC2585]に記載されているように、他の方法（たとえば、軽量ディレクトリアクセスプロトコル（LDAP））を含む場合があります。
b. CRL publication: As for certificate publication.
b. CRLの公開：証明書の公開について。
5. Recovery operations: Some PKI management operations are used when an end entity has "lost" its TEE:
5. 回復操作：一部のPKI管理操作は、最終エンティティがティーを「失った」ときに使用されます。
a. key pair recovery: As an option, user client key materials (e.g., a user's private key used for decryption purposes) MAY be backed up by a CA, an RA, or a key backup system associated with a CA or RA. If an entity needs to recover these backed up key materials (e.g., as a result of a forgotten password or a lost key chain file), a protocol exchange may be needed to support such recovery.
a. キーペアの回復：オプションとして、ユーザークライアントのキー資料（たとえば、復号化目的で使用されるユーザーの秘密鍵）は、CA、RA、またはCAまたはRAに関連するキーバックアップシステムによってバックアップされる場合があります。エンティティがこれらのバックアップされた主要な資料を回復する必要がある場合（たとえば、忘れられたパスワードまたは失われたキーチェーンファイルの結果として）、そのような回復をサポートするためにプロトコル交換が必要になる場合があります。
6. Revocation operations: Some PKI management operations result in the creation of new CRL entries and/or new CRLs:
6. 取り消し操作：一部のPKI管理操作により、新しいCRLエントリおよび/または新しいCRLが作成されます。
a. revocation request: An authorized person advises a CA of an abnormal situation requiring certificate revocation.
a. 取り消しリクエスト：認定者は、CAに証明書の取り消しを必要とする異常な状況を助言します。
7. TEE operations: Whilst the definition of TEE operations (e.g., moving a TEE, changing a PIN, etc.) are beyond the scope of this specification, we do define a PKIMessage (CertRepMessage) that can form the basis of such operations.
7. TEE操作：TEE操作の定義（たとえば、Tシャツの移動、ピンの変更など）はこの仕様の範囲を超えていますが、そのような操作の基礎を形成できるpkimessage（certrepmessage）を定義します。
Note that online protocols are not the only way of implementing the above operations. For all operations, there are offline methods of achieving the same result, and this specification does not mandate use of online protocols. For example, when hardware tokens are used, many of the operations MAY be achieved as part of the physical token delivery.
オンラインプロトコルは、上記の操作を実装する唯一の方法ではないことに注意してください。すべての操作について、同じ結果を達成するオフラインの方法があり、この仕様はオンラインプロトコルの使用を義務付けていません。たとえば、ハードウェアトークンを使用すると、物理トークン配信の一部として多くの操作が達成される場合があります。
Later sections define a set of standard messages supporting the above operations. Transfer protocols for conveying these exchanges in various environments (e.g., offline: file-based; online: email, HTTP [RFC9811], MQTT, and CoAP [RFC9482]) are beyond the scope of this document and must be specified separately. Appropriate transfer protocols MUST be capable of delivering the CMP messages reliably.
後のセクションでは、上記の操作をサポートする一連の標準メッセージを定義します。さまざまな環境でこれらの交換を伝えるためのプロトコル（例：オフライン：ファイルベース;オンライン：電子メール、HTTP [RFC9811]、MQTT、およびCOAP [RFC9482]）は、このドキュメントの範囲を超えており、別々に指定する必要があります。適切な転送プロトコルは、CMPメッセージを確実に配信できる必要があります。
CMP provides inbuilt integrity protection and authentication. The information communicated unencrypted in CMP messages does not contain sensitive information endangering the security of the PKI when intercepted. However, it might be possible for an eavesdropper to utilize the available information to gather confidential technical or business-critical information. Therefore, users should consider protection of confidentiality on lower levels of the protocol stack, e.g., by using TLS [RFC8446], DTLS [RFC9147], or IPsec [RFC7296][RFC4303].
CMPは、組み込みの整合性の保護と認証を提供します。CMPメッセージで暗号化されていない情報には、傍受されたときにPKIのセキュリティを危険にさらす機密情報が含まれていません。ただし、盗聴者が利用可能な情報を利用して、機密の技術的またはビジネス上の情報を収集することが可能かもしれません。したがって、ユーザーは、TLS [RFC8446]、DTLS [RFC9147]、またはIPSEC [RFC7296] [RFC4303]を使用して、プロトコルスタックのより低いレベルの機密性の保護を考慮する必要があります。
The first step for an end entity in dealing with PKI management entities is to request information about the PKI functions supported and to securely acquire a copy of the relevant root CA public key(s).
PKI管理エンティティを扱う最終エンティティの最初のステップは、サポートされているPKI関数に関する情報を要求し、関連するルートCA公開キーのコピーを安全に取得することです。
There are many schemes that can be used to achieve initial registration and certification of end entities. No one method is suitable for all situations due to the range of policies that a CA may implement and the variation in the types of end entity that can occur.
最終エンティティの初期登録と認証を実現するために使用できる多くのスキームがあります。CAが実装する可能性のあるポリシーの範囲と発生する可能性のあるエンティティのタイプの変動により、すべての状況に適した方法はありません。
However, we can classify the initial registration/certification schemes that are supported by this specification. Note that the word "initial", above, is crucial: We are dealing with the situation where the end entity in question has had no previous contact with the PKI, except having received the root CA certificate of that PKI by some zero-touch method like BRSKI [RFC8995] [RFC9733] or SZTP [RFC8572]. In case the end entity already possesses certified keys, then some simplifications/alternatives are possible.
ただし、この仕様でサポートされている最初の登録/認証スキームを分類できます。上記の「初期」という言葉が重要であることに注意してください。BRSKI[RFC8995] [RFC9733]またはSZTP [RFC8572]のようなゼロタッチ法でそのPKIのルートCA証明書を受け取ったことを除いて、問題の最終エンティティがPKIと以前に接触していない状況を扱っています。終了エンティティがすでに認定キーを持っている場合、いくつかの単純化/代替案が可能です。
Having classified the schemes that are supported by this specification, we can then specify some as mandatory and some as optional. The goal is that the mandatory schemes cover a sufficient number of the cases that will arise in real use, whilst the optional schemes are available for special cases that arise less frequently. In this way, we achieve a balance between flexibility and ease of implementation.
この仕様でサポートされているスキームを分類した後、一部は必須でオプションとして指定できます。目標は、必須のスキームが実際の使用で発生する十分な数のケースをカバーしているのに対し、オプションのスキームはあまり頻繁に発生する特別なケースで利用できることです。このようにして、実装の柔軟性と容易さのバランスをとっています。
Further classification of mandatory and optional schemes addressing different environments is available, e.g., in Appendices C and D of this specification on managing human user certificates as well as in the Lightweight CMP Profile [RFC9483] on fully automating certificate management in a machine-to-machine and Internet of Things (IoT) environment. Industry standards such as [ETSI-3GPP.33.310] for mobile networks and [UNISIG.Subset-137] for railroad automation have adopted CMP and defined a series of mandatory schemes for their use cases.
さまざまな環境に対処する必須およびオプションのスキームのさらなる分類は、たとえば、人間のユーザー証明書の管理に関するこの仕様の付録CおよびDで、および機械からマシンとモノのインターネット（IoT）環境での証明書管理を完全に自動化するための軽量CMPプロファイル[RFC9483]で利用可能です。モバイルネットワークの[ETSI-3GPP.33.310]や鉄道自動化の[Unisig.subset-137]などの業界標準は、CMPを採用し、ユースケースの一連の必須スキームを定義しました。
We will now describe the classification of initial registration/ certification schemes.
ここで、初期登録/認証スキームの分類について説明します。
In terms of the PKI messages that are produced, we can regard the initiation of the initial registration/certification exchanges as occurring wherever the first PKI message relating to the end entity is produced. Note that the real-world initiation of the registration/certification procedure may occur elsewhere (e.g., a personnel department may telephone an RA operator or use zero-touch methods like BRSKI [RFC8995] or SZTP [RFC8572]).
作成されたPKIメッセージに関しては、終了エンティティに関連する最初のPKIメッセージが作成されている場合でも発生する最初の登録/認証交換の開始を考慮することができます。登録/認証手順の実際の開始は他の場所で発生する可能性があることに注意してください（たとえば、人事部門はRAオペレーターに電話するか、BRSKI [RFC8995]やSZTP [RFC8572]などのゼロタッチメソッドを使用できます）。
The possible locations are at the end entity, an RA, or a CA.
考えられる場所は、終了エンティティ、RA、またはCAです。
The online messages produced by the end entity that requires a certificate may be authenticated or not. The requirement here is to authenticate the origin of any messages from the end entity to the PKI (CA/RA).
証明書を必要とするEnd Entityによって作成されたオンラインメッセージは、認証されるかどうか。ここでの要件は、最終エンティティからPKI（CA/RA）へのメッセージの原点を認証することです。
In this specification, such authentication is achieved by two different means:
この仕様では、このような認証は2つの異なる手段によって達成されます。
* symmetric: The PKI (CA/RA) issuing the end entity with a secret value (initial authentication key) and reference value (used to identify the secret value) via some out-of-band means. The initial authentication key can then be used to protect relevant PKI messages.
* 対称：PKI（CA/RA）は、帯域外の平均を介して秘密値（初期認証キー）と基準値（秘密値を識別するために使用）を備えた最終エンティティを発行します。その後、初期認証キーを使用して、関連するPKIメッセージを保護できます。
* asymmetric: Using a private key and certificate issued by another PKI trusted for initial authentication, e.g., an Initial Device Identifier (IDevID) IEEE 802.1AR [IEEE.802.1AR-2018]. The trust establishment in this external PKI is out of scope of this document.
* 非対称：初期認証のために信頼された別のPKIによって発行された秘密鍵と証明書を使用します。この外部PKIの信託施設は、この文書の範囲外です。
Thus, we can classify the initial registration/certification scheme according to whether or not the online 'end entity -> PKI management entity' messages are authenticated or not.
したがって、オンラインの「End Entity-> PKI Management Entity」メッセージが認証されているかどうかに応じて、初期登録/認証スキームを分類できます。
Note 1: We do not discuss the authentication of the 'PKI management entity -> end entity' messages here, as this is always REQUIRED. In any case, it can be achieved simply once the root-CA public key has been installed at the end entity's equipment or it can be based on the initial authentication key.
注1：これが常に必要なため、ここでは「PKI管理エンティティ - > End Entity」メッセージの認証については説明しません。いずれにせよ、それは単にルートCAの公開キーがEnd Entityの機器にインストールされた後に達成するか、初期認証キーに基づいていることができます。
Note 2: An initial registration/certification procedure can be secure where the messages from the end entity are authenticated via some out-of-band means (e.g., a subsequent visit).
注2：初期登録/認証手順は、最終エンティティからのメッセージが帯域外の手段を介して認証される場合（例：その後の訪問）を保護できます。
In this specification, "key generation" is regarded as occurring wherever either the public or private component of a key pair first occurs in a PKIMessage. Note that this does not preclude a centralized key generation service by a KGA; the actual key pair MAY have been generated elsewhere and transported to the end entity, RA, or CA using a (proprietary or standardized) key generation request/ response protocol (outside the scope of this specification).
この仕様では、「キー生成」は、キーペアのパブリックまたはプライベートコンポーネントが最初にpkimessageで発生する場合でも発生すると見なされます。これは、KGAによる集中型キージェネレーションサービスを排除しないことに注意してください。実際のキーペアは他の場所で生成され、（独自または標準化された）キー生成要求/応答プロトコル（この仕様の範囲外）を使用して、最終エンティティ、RA、またはCAに輸送された可能性があります。
Thus, there are three possibilities for the location of "key generation": the end entity, a KGA, or a CA.
したがって、「キー生成」の場所には3つの可能性があります。最終エンティティ、KGA、またはCA。
Following the creation of a certificate for an end entity, additional assurance can be gained by having the end entity explicitly confirm successful receipt of the message containing (or indicating the creation of) the certificate. Naturally, this confirmation message must be protected (based on the initial symmetric or asymmetric authentication key or other means).
終了エンティティの証明書の作成に続いて、証明書を含む（または作成を示す）メッセージの受信を成功させる（または証明書の作成を示す）エンティティが明示的に確認されることにより、追加の保証を得ることができます。当然、この確認メッセージは保護する必要があります（初期対称または非対称認証キーまたはその他の手段に基づいています）。
This gives two further possibilities: confirmed or not.
これにより、さらに2つの可能性が得られます。
The criteria above allow for a large number of initial registration/ certification schemes. Examples of possible initial registration/ certification schemes can be found in the following subsections. An entity may support other schemes specified in profiles of PKIX-CMP, such as Appendices C and D or [RFC9483].
上記の基準により、多数の初期登録/認証スキームが可能になります。可能な初期登録/認証スキームの例は、次のサブセクションにあります。エンティティは、付録CやDまたは[RFC9483]など、PKIX-CMPのプロファイルで指定された他のスキームをサポートする場合があります。
In terms of the classification above, this scheme is, in some ways, the simplest possible, where:
上記の分類に関しては、このスキームは、可能な限り最も単純なものです。
* initiation occurs at the certifying CA;
* 認定CAで開始が発生します。
* no online message authentication is required;
* オンラインメッセージ認証は必要ありません。
* "key generation" occurs at the certifying CA (see Section 4.2.1.3); and
* 「キー生成」は、認定CAで発生します（セクション4.2.1.3を参照）。そして
* no confirmation message is required.
* 確認メッセージは必要ありません。
In terms of message flow, this scheme means that the only message required is sent from the CA to the end entity. The message must contain the entire TEE for the end entity. Some out-of-band means must be provided to allow the end entity to authenticate the message received and to decrypt any encrypted values.
メッセージフローに関して、このスキームは、必要なメッセージのみがCAからEnd Entityに送信されることを意味します。メッセージには、終了エンティティのティー全体が含まれている必要があります。最終エンティティが受信したメッセージを認証し、暗号化された値を復号化できるようにするために、いくつかの帯域外の手段を提供する必要があります。
In terms of the classification above, this scheme is where:
上記の分類に関しては、このスキームは次の場所です。
* initiation occurs at the end entity;
* 終了エンティティで開始が発生します。
* message authentication is required;
* メッセージ認証が必要です。
* "key generation" occurs at the end entity (see Section 4.2.1.3); and
* 「キー生成」は、最後のエンティティで発生します（セクション4.2.1.3を参照）。そして
* a confirmation message is recommended.
* 確認メッセージが推奨されます。
Note: An Initial Authentication Key (IAK) can be either a symmetric key or an asymmetric private key with a certificate issued by another PKI trusted for this purpose. The establishment of such trust is out of scope of this document.
注：初期認証キー（IAK）は、対称キーまたは非対称の秘密鍵のいずれかで、この目的で信頼されている別のPKIが発行した証明書を備えています。このような信頼の確立は、この文書の範囲外です。
In terms of message flow, the basic authenticated scheme is as follows:
メッセージフローに関しては、基本的な認証されたスキームは次のとおりです。
End Entity RA/CA
========== =============
out-of-band distribution of Initial Authentication
Key (IAK) and reference value (RA/CA -> end entity)
Key generation
Creation of certification request
Protect request with IAK
-----> certification request ----->
verify request
process request
create response
<----- certification response <-----
handle response
create confirmation
-----> cert conf message ----->
verify confirmation
create response
<----- conf ack (optional) <-----
handle response
Note: Where verification of the cert confirmation message fails, the RA/CA MUST revoke the newly issued certificate if it has been published or otherwise made available.
注：証明書確認メッセージの検証が失敗した場合、RA/CAは、公開されているか、その他の方法で利用可能になった場合、新しく発行された証明書を取り消す必要があります。
POP is where a PKI management entity (CA/RA) verifies if an end entity has access to the private key corresponding to a given public key. The question of whether, and in what circumstances, POPs add value to a PKI is a debate as old as PKI itself! See Section 8.1 for a further discussion on the necessity of POP in PKI.
POPは、特定の公開キーに対応する秘密鍵に終了エンティティがアクセスできる場合、PKI管理エンティティ（CA/RA）が検証する場所です。PKIに価値を追加するのは、PKI自体と同じくらい古い議論であるかどうか、そしてどのような状況でどのような状況にあるかという問題！PKIのPOPの必要性に関する詳細については、セクション8.1を参照してください。
The PKI management operations specified here make it possible for an end entity to prove to a CA/RA that it has possession of (i.e., is able to use) the private key corresponding to the public key for which a certificate is requested (see Section 5.2.8 for different POP methods). A given CA/RA is free to choose how to enforce POP (e.g., out-of-band procedural means versus PKIX-CMP in-band messages) in its certification exchanges (i.e., this may be a policy issue). However, it is REQUIRED that CAs/RAs MUST enforce POP by some means because there are currently many non-PKIX operational protocols in use (various electronic mail protocols are one example) that do not explicitly check the binding between the end entity and the private key. Until operational protocols that do verify the binding (for signature, encryption, key agreement, and KEM key pairs) exist, and are ubiquitous, this binding can only be assumed to have been verified by the CA/RA. Therefore, if the binding is not verified by the CA/RA, certificates in the Internet PKI end up being somewhat less meaningful.
ここで指定されたPKI管理操作により、最終エンティティがCA/RAに所有している（つまり、使用できる）ことを証明することが可能になります。特定のCA/RAは、認定交換でPOP（たとえば、帯域外の手続き的平均とPKIX-CMPインバンドメッセージ）を強制する方法を自由に選択できます（つまり、これはポリシーの問題かもしれません）。ただし、現在使用されている非PKIX運用プロトコル（さまざまな電子メールプロトコルが1つの例）があるため、CAS/RASが何らかの手段でPOPを実施する必要があります。バインディング（署名、暗号化、主要な合意、およびKEMキーペアの場合）を検証する運用プロトコルが存在し、ユビキタスであるまで、この結合はCA/RAによって検証されたとのみ想定できます。したがって、拘束力がCA/RAによって検証されていない場合、インターネットPKIの証明書はやや意味が低くなります。
POP is accomplished in different ways depending upon the type of key for which a certificate is requested. If a key can be used for multiple purposes (e.g., an RSA key), then any appropriate method MAY be used (e.g., a key that may be used for signing, as well as other purposes, MUST NOT be sent to the CA/RA in order to prove possession unless archival of the private key is explicitly desired).
POPは、証明書が要求されるキーのタイプに応じて、さまざまな方法で達成されます。キーを複数の目的（RSAキーなど）に使用できる場合、適切な方法を使用できます（たとえば、署名に使用される可能性のあるキー、およびその他の目的は、秘密鍵のアーカイブが明示的に望ましい場合を除き、所有権を証明するためにCA/RAに送信してはなりません）。
This specification explicitly allows for cases where an end entity supplies the relevant proof to an RA and the RA subsequently attests to the CA that the required proof has been received (and validated!). For example, an end entity wishing to have a signing key certified could send the appropriate signature to the RA, which then simply notifies the relevant CA that the end entity has supplied the required proof. Of course, such a situation may be disallowed by some policies (e.g., CAs may be the only entities permitted to verify POP during certification).
この仕様により、最終エンティティが関連する証明をRAに供給し、その後RAが必要な証明を受け取った（および検証された！）CAに明示的に可能にします。たとえば、署名キーの認定を希望するエンティティは、適切な署名をRAに送信することができます。これにより、関連するCAが必要な証明を提供したことを単純に通知します。もちろん、このような状況は、いくつかのポリシーによって許可されている可能性があります（たとえば、CASは、認証中にPOPを検証することを許可されている唯一のエンティティである可能性があります）。
For signature keys, the end entity can sign a value to prove possession of the private key; see Section 5.2.8.2.
署名キーの場合、最終エンティティは秘密鍵の所有を証明するために値に署名できます。セクション5.2.8.2を参照してください。
For encryption keys, the end entity can provide the private key to the CA/RA (e.g., for archiving), see Section 5.2.8.3.1, or can be required to decrypt a value in order to prove possession of the private key. Decrypting a value can be achieved either directly (see Section 5.2.8.3.3) or indirectly (see Section 5.2.8.3.2).
暗号化キーの場合、最終エンティティはCA/RAの秘密鍵を提供します（たとえば、アーカイブの場合）、セクション5.2.8.3.1を参照するか、秘密鍵の所有を証明するために値を解読するために必要です。値を復号化することは、直接（セクション5.2.8.3.3を参照）または間接的に達成できます（セクション5.2.8.3.2を参照）。
The direct method is for the RA/CA to issue a random challenge to which an immediate response by the end entity is required.
直接的な方法は、RA/CAが最終エンティティによる即時の応答が必要なランダムな課題を発行することです。
The indirect method is to issue a certificate that is encrypted for the end entity (and have the end entity demonstrate its ability to decrypt this certificate in the confirmation message). This allows a CA to issue a certificate in a form that can only be used by the intended end entity.
間接的な方法は、最終エンティティに対して暗号化された証明書を発行することです（そして、エンティティが確認メッセージでこの証明書を復号化する能力を実証します）。これにより、CAは、意図した最終エンティティによってのみ使用できるフォームで証明書を発行できます。
This specification encourages use of the indirect method because it requires no extra messages to be sent (i.e., the proof can be demonstrated using the {request, response, confirmation} triple of messages).
この仕様は、送信する余分なメッセージを必要としないため、間接的な方法の使用を促進します（つまり、{要求、応答、確認}メッセージのトリプルを使用して証明を実証できます）。
For key agreement keys, the end entity and the PKI management entity (i.e., CA or RA) must establish a shared secret key in order to prove that the end entity has possession of the private key.
キー契約キーの場合、最終エンティティとPKI管理エンティティ（つまり、CAまたはRA）は、最終エンティティが秘密鍵を所有していることを証明するために、共有秘密の鍵を確立する必要があります。
Note that this need not impose any restrictions on the keys that can be certified by a given CA. In particular, for Diffie-Hellman (DH) keys, the end entity may freely choose its algorithm parameters provided that the CA can generate a short-term (or one-time) key pair with the appropriate parameters when necessary.
これにより、特定のCAによって認証できるキーに制限を課す必要はないことに注意してください。特に、Diffie-Hellman（DH）キーの場合、最終エンティティは、CAが必要に応じて適切なパラメーターを使用して短期（または1回限りの）キーペアを生成できる場合、そのアルゴリズムパラメーターを自由に選択できます。
For KEM keys, the end entity can provide the private key to the CA/RA (e.g., for archiving), see Section 5.2.8.3.1, or can be required to decrypt a value in order to prove possession of the private key. Decrypting a value can be achieved either directly (see Section 5.2.8.3.3) or indirectly (see Section 5.2.8.3.2).
KEMキーの場合、最終エンティティはCA/RAの秘密鍵を提供することができます（たとえば、アーカイブの場合）、セクション5.2.8.3.1を参照するか、秘密鍵の所有を証明するために値を解読する必要があります。値を復号化することは、直接（セクション5.2.8.3.3を参照）または間接的に達成できます（セクション5.2.8.3.2を参照）。
Note: A definition of KEMs can be found in Section 1 of [RFC9629].
注：KEMの定義は、[RFC9629]のセクション1に記載されています。
The direct method is for the RA/CA to issue a random challenge to which an immediate response by the end entity is required.
直接的な方法は、RA/CAが最終エンティティによる即時の応答が必要なランダムな課題を発行することです。
The indirect method is to issue a certificate that is encrypted for the end entity using a shared secret key derived from a key encapsulated using the public key (and have the end entity demonstrate its ability to use its private key for decapsulation of the KEM ciphertext, derive the shared secret key, decrypt this certificate, and provide a hash of the certificate in the confirmation message). This allows a CA to issue a certificate in a form that can only be used by the intended end entity.
間接的な方法は、公開鍵を使用してカプセル化されたキーから派生した共有シークレットキーを使用して、最終エンティティに対して暗号化された証明書を発行することです（そして、エンティティはKEM暗号文の脱カプセル化のためにその秘密鍵を使用する能力を実証し、共有秘密の鍵を導き出し、この証明書を導き、確認メッセージのハスを提供します）。これにより、CAは、意図した最終エンティティによってのみ使用できるフォームで証明書を発行できます。
This specification encourages use of the indirect method because it requires no extra messages to be sent (i.e., the proof can be demonstrated using the {request, response, confirmation} triple of messages).
この仕様は、送信する余分なメッセージを必要としないため、間接的な方法の使用を促進します（つまり、{要求、応答、確認}メッセージのトリプルを使用して証明を実証できます）。
A certification request message for a KEM certificate SHALL use POPOPrivKey by using the keyEncipherment choice of ProofOfPossession (see Section 5.2.8) in the popo field of CertReqMsg as long as no KEM-specific choice is available.
KEM証明書の認定要求メッセージは、KEM固有の選択肢がない限り、CertreQMSGのPOPOフィールドにあるProofofPossessionのkeyencypherment選択（セクション5.2.8を参照）を使用してPopoprivkeyを使用するものとします。
This discussion only applies to CAs that are directly trusted by some end entities. Recognizing whether a self-signed or non-self-signed CA is supposed to be directly trusted for some end entities is a matter of CA policy and end entity configuration. Thus, this is beyond the scope of this document.
この議論は、一部の最終エンティティから直接信頼されるCAにのみ適用されます。いくつかの最終エンティティに対して自己署名または非自己署名のCAが直接信頼されるかどうかを認識することは、CAポリシーと最終エンティティの構成の問題です。したがって、これはこのドキュメントの範囲を超えています。
The basis of the procedure described here is that the CA protects its new public key using its previous private key and vice versa. Thus, when a CA updates its key pair, it may generate two link certificates: "old with new" and "new with old".
ここで説明する手順の基礎は、CAが以前の秘密鍵を使用して新しい公開キーを保護し、その逆も同様です。したがって、CAがキーペアを更新すると、「古い」、「古いものと新しい」という2つのリンク証明書が生成される場合があります。
Note: The usage of link certificates has been shown to be very specific for each use case, and no assumptions are done on this aspect. RootCaKeyUpdateContent is updated to specify these link certificates as optional.
注：リンク証明書の使用は、各ユースケースに対して非常に具体的であることが示されており、この側面に関する仮定は行われていません。rootcakeyupdateContentが更新され、これらのリンク証明書をオプションとして指定します。
Note: When an LDAP directory is used to publish root CA updates, the old and new root CA certificates together with the two link certificates are stored as cACertificate attribute values.
注：LDAPディレクトリを使用してルートCAの更新を公開する場合、2つのリンク証明書と一緒に古いルートCA証明書と新しいルートCA証明書がcacertificate属性値として保存されます。
When a CA changes its key pair, those entities who have acquired the old CA public key via "out-of-band" means are most affected. These end entities need to acquire the new CA public key in a trusted way. This may be achieved "out-of-band" by using a repository or by using online messages also containing the link certificates "new with old". Once the end entity acquired and properly verified the new CA public key, it must load the new trust anchor information into its trusted store.
CAがキーペアを変更すると、「帯域外」平均を介して古いCAの公開キーを取得したエンティティが最も影響を受けます。これらの最終エンティティは、信頼できる方法で新しいCA公開キーを取得する必要があります。これは、リポジトリを使用するか、リンク証明書を含むオンラインメッセージを使用することにより、「バンド外」を実現できます。最終エンティティが取得し、新しいCA公開キーを適切に検証したら、新しいトラストアンカー情報を信頼できるストアにロードする必要があります。
The data structure used to protect the new and old CA public keys is typically a standard X.509v3 certificate (which may also contain extensions). There are no new data structures required.
新しいおよび古いCAパブリックキーを保護するために使用されるデータ構造は、通常、標準x.509v3証明書です（拡張機能も含まれている場合があります）。新しいデータ構造は必要ありません。
Note: Sometimes self-signed root CA certificates do not make use of X.509v3 extensions and may be X.509v1 certificates. Therefore, a root CA key update must be able to work for version 1 certificates. The use of the X.509v3 KeyIdentifier extension is recommended for easier path building.
注：自己署名のルートCA証明書がX.509V3拡張機能を使用せず、X.509V1証明書を使用しない場合があります。したがって、ルートCAキーアップデートは、バージョン1の証明書で動作できる必要があります。X.509V3 KeyIdentifier拡張機能の使用は、パス構築を容易にするために推奨されます。
Note: While the scheme could be generalized to cover cases where the CA updates its key pair more than once during the validity period of one of its end entities' certificates, this generalization seems of dubious value. Not having this generalization simply means that the validity periods of certificates issued with the old CA key pair cannot exceed the end of the "old with new" certificate validity period.
注：スキームは、CAがその最終エンティティの証明書の1つの有効期間中にキーペアを複数回更新するケースをカバーするために一般化できますが、この一般化は疑わしい価値のようです。この一般化を持たないことは、単に古いCAキーペアで発行された証明書の有効期間が、「新しい」証明書の有効期間の「古い」の終わりを超えることができないことを意味します。
Note: This scheme offers a mechanism to ensures that end entities will acquire the new CA public key, at the latest by the expiry of the last certificate they owned that was signed with the old CA private key. Certificate and/or key update operations occurring at other times do not necessarily require this (depending on the end entity's equipment).
注：このスキームは、最新のエンティティが新しいCAの公開キーを取得することを保証するメカニズムを提供します。他の場合に発生する証明書および/または主要な更新操作は、必ずしもこれを必要とするわけではありません（エンティティのエンティティの機器に応じて）。
Note: In practice, a new root CA may have a slightly different subject Distinguished Name (DN), e.g., indicating a generation identifier like the year of issuance or a version number, for instance, in an Organizational Unit (OU) element. How to bridge trust to the new root CA certificate in a CA DN change or a cross-certificate scenario is out of scope for this document.
注：実際には、新しいルートCAには、わずかに異なる被験者の著名な名前（DN）がある場合があります。たとえば、発行年のような生成識別子や、たとえば組織単位（OU）要素のバージョン番号などの生成識別子を示しています。このドキュメントのCA DNの変更または相互公認シナリオで、CA DNの変更またはクロス認証シナリオで新しいルートCA証明書に信頼を橋渡しする方法。
To change the key of the CA, the CA operator does the following:
CAのキーを変更するには、CAオペレーターが次のことを行います。
1. Generate a new key pair.
1. 新しいキーペアを生成します。
2. Create a certificate containing the new CA public key signed with the new private key or by the private key of some other CA (the "new with new" certificate).
2. 新しい秘密鍵で署名された新しいCA公開キーまたは他のCAの秘密鍵（「新しい」証明書を「新しい」証明書）で構成する証明書を作成します。
3. Optionally: Create a link certificate containing the new CA public key signed with the old private key (the "new with old" certificate).
3. オプションでは、古い秘密鍵（「古い」証明書を「新しい」証明書）に署名した新しいCA公開キーを含むリンク証明書を作成します。
4. Optionally: Create a link certificate containing the old CA public key signed with the new private key (the "old with new" certificate).
4. オプション：新しい秘密鍵（「新しい」証明書を持つ古い証明書）に署名された古いCA公開キーを含むリンク証明書を作成します。
5. Publish these new certificates so that end entities may acquire it, e.g., using a repository or RootCaKeyUpdateContent.
5. これらの新しい証明書を公開して、エンティティがリポジトリまたはrootcakeyUpDatententを使用してそれを取得できるようにします。
The old CA private key is then no longer required when the validity of the "old with old" certificate ended. However, the old CA public key will remain in use for validating the "new with old" link certificate until the new CA public key is loaded into the trusted store. The old CA public key is no longer required (other than for non-repudiation) when all end entities of this CA have securely acquired and stored the new CA public key.
「古い」証明書の有効性が終了した場合、古いCAの秘密鍵は不要になります。ただし、古いCAの公開キーは、新しいCA公開キーが信頼できるストアにロードされるまで、「古い」リンク証明書を検証するために使用され続けます。このCAのすべての最終エンティティが新しいCA公開キーを安全に取得して保存した場合、古いCAの公開キーは（非repudiation以外）必要ありません。
The "new with new" certificate must have a validity period with a notBefore time that is before the notAfter time of the "old with old" certificate and a notAfter time that is after the notBefore time of the next update of this certificate.
「新しい」証明書には、「古い」証明書のすぐ前の時間の前にある時間前に、この証明書の次の更新の前にある時間の後の時間の前にある有効期間がなければなりません。
The "new with old" certificate must have a validity period with the same notBefore time as the "new with new" certificate and a notAfter time by which all end entities of this CA will securely possess the new CA public key (at the latest, at the notAfter time of the "old with old" certificate).
「新しい」証明書は、「新しい」証明書と同じではなく、このCAのすべての最終エンティティが新しいCA公開鍵を安全に所有すると同じ時間と同じである有効期間を持たなければなりません（最新の「古い」証明書のノートの時間に）。
The "old with new" certificate must have a validity period with the same notBefore and notAfter time as the "old with old" certificate.
「古い」証明書には、「古い」証明書と同じであり、その前に時間がかかる有効期間がなければなりません。
Note: Further operational considerations on transition from one root CA self-signed certificate to the next is available in Section 5 of [RFC8649].
注：1つのルートCAの自己署名証明書から次の証明書への移行に関するさらなる運用上の考慮事項は、[RFC8649]のセクション5で利用できます。
Normally when verifying a signature, the verifier verifies (among other things) the certificate containing the public key of the signer. However, once a CA is allowed to update its key, there are a range of new possibilities. These are shown in the table below.
通常、署名を検証するとき、検証者は（とりわけ）署名者の公開鍵を含む証明書を（特に）検証します。ただし、CAがキーを更新することが許可されると、さまざまな新しい可能性があります。これらを下の表に示します。
+======================+======================+=====================+
| | Verifier's TEE | Verifier's TEE |
| | contains NEW public | contains OLD |
| | key | public key |
+======================+======================+=====================+
| Signer's certificate | Case 1: The verifier | Case 2: The |
| is protected using | can directly verify | verifier is |
| NEW key pair | the certificate. | missing the NEW |
| | | public key. |
+======================+----------------------+---------------------+
| Signer's certificate | Case 3: The verifier | Case 4: The |
| is protected using | is missing the OLD | verifier can |
| OLD key pair | public key. | directly verify |
| | | the certificate. |
+======================+----------------------+---------------------+
Table 1
In these cases, the verifier has a local copy of the CA public key that can be used to verify the certificate directly. This is the same as the situation where no key change has occurred.
これらの場合、検証者には、証明書を直接検証するために使用できるCA公開キーのローカルコピーがあります。これは、重要な変更が発生していない状況と同じです。
In case 2, the verifier must get access to the new public key of the CA. Case 2 will arise when the CA operator has issued the verifier's certificate, then changed the CA's key, and then issued the signer's certificate; so it is quite a typical case.
ケース2では、検証者はCAの新しい公開鍵にアクセスする必要があります。CAオペレーターがVerifierの証明書を発行し、CAのキーを変更してから署名者の証明書を発行したときに、ケース2が発生します。したがって、それは非常に典型的なケースです。
The verifier does the following:
検証者は次のことを行います。
1. Get the "new with new" and "new with old" certificates. The location of where to retrieve these certificates may be available in the authority information access extension of the "old with old" certificate (see the access method for caIssuers in Section 4.2.2.1 of [RFC5280]), or it may be locally configured.
1. 「新しい」と「古い」証明書を取得します。これらの証明書を取得する場所の場所は、「古い」証明書の権限情報アクセス拡張で利用可能になる場合があります（[RFC5280]のセクション4.2.2.1のCaissuersのアクセス方法を参照）、または局所的に構成されている場合があります。
a. If a repository is available, look up the certificates in the caCertificate attribute.
a. リポジトリが利用可能な場合は、cacertificate属性の証明書を調べます。
b. If an HTTP or FTP server is available, pick the certificates from the "certs-only" CMS message.
b. HTTPまたはFTPサーバーが利用可能な場合は、「CERTSのみの」CMSメッセージから証明書を選択します。
c. If a CMP server is available, request the certificates using the root CA update the general message (see Section 5.3.19.15).
c. CMPサーバーが使用可能な場合は、ルートCAを使用して証明書に一般的なメッセージを更新します（セクション5.3.19.15を参照）。
d. Otherwise, get the certificates "out-of-band" using any trustworthy mechanism.
d. それ以外の場合は、信頼できるメカニズムを使用して「バンド外」の証明書を取得します。
2. If the certificates are received, check that the validity periods and the subject and issuer fields match. Verify the signatures using the old root CA key (which the verifier has locally).
2. 証明書を受け取った場合は、有効期間と被験者と発行者のフィールドが一致することを確認します。古いルートCAキー（検証者にローカルにある）を使用して署名を確認します。
3. If all checks are successful, securely store the new trust anchor information and validate the signer's certificate.
3. すべてのチェックが成功した場合は、新しいトラストアンカー情報を安全に保存し、署名者の証明書を検証します。
In case 3, the verifier must get access to the old public key of the CA. Case 3 will arise when the CA operator has issued the signer's certificate, then changed the key, and then issued the verifier's certificate.
ケース3では、検証者はCAの古い公開鍵にアクセスする必要があります。CAオペレーターが署名者の証明書を発行し、キーを変更してからVerifierの証明書を発行したときに、ケース3が発生します。
The verifier does the following:
検証者は次のことを行います。
1. Get the "old with new" certificate. The location of where to retrieve these certificates may be available in the authority information access extension of the "new with new" certificate (see caIssuers access method in Section 4.2.2.1 of [RFC5280]), or it may be locally configured.
1. 「新しい」証明書を取得します。これらの証明書を取得する場所の場所は、「新しい」証明書（[RFC5280]のセクション4.2.2.1のCAISSUERSアクセス方法を参照）の権限情報アクセス拡張で利用できる場合があります。
a. If a repository is available, look up the certificate in the caCertificate attribute.
a. リポジトリが利用可能な場合は、cacertificate属性の証明書を調べます。
b. If an HTTP or FTP server is available, pick the certificate from the "certs-only" CMS message.
b. HTTPまたはFTPサーバーが利用可能な場合は、「CERTSのみの」CMSメッセージから証明書を選択します。
c. If a CMP server and an untrusted copy of the old root CA certificate are available (e.g., the signer provided it in-band in the CMP extraCerts filed), request the certificate using the root CA update the general message (see Section 5.3.19.15).
c. CMPサーバーと古いルートCA証明書の信頼できないコピーが利用可能である場合（たとえば、署名者は、提出されたCMPエクストラメートで帯域内を提供しました）、ルートCAを使用して一般的なメッセージを更新して証明書を要求します（セクション5.3.19.15を参照）。
d. Otherwise, get the certificate "out-of-band" using any trustworthy mechanism.
d. それ以外の場合は、信頼できるメカニズムを使用して証明書を「バンド外」に入手します。
2. If the certificate is received, check that the validity periods and the subject and issuer fields match. Verify the signatures using the new root CA key (which the verifier has locally).
2. 証明書を受け取った場合は、有効期間と被験者と発行者のフィールドが一致することを確認します。新しいルートCAキー（検証者がローカルに持っている）を使用して署名を確認します。
3. If all checks were successful, securely store the old trust anchor information and validate the signer's certificate.
3. すべてのチェックが成功した場合は、古いトラストアンカー情報を安全に保存し、署名者の証明書を検証します。
As we saw above, the verification of a certificate becomes more complex once the CA is allowed to change its key. This is also true for revocation checks, as the CA may have signed the CRL using a newer private key than the one within the user's TEE.
上で見たように、CAがキーを変更することが許可されると、証明書の検証がより複雑になります。これは、CAがユーザーのティー内の秘密キーよりも新しい秘密鍵を使用してCRLに署名した可能性があるため、取り消しチェックにも当てはまります。
The analysis of the alternatives is the same as for certificate verification.
代替案の分析は、証明書の検証と同じです。
The EKU extension indicates the purposes for which the certified key pair may be used. Therefore, it restricts the use of a certificate to specific applications.
EKU拡張機能は、認定されたキーペアを使用できる目的を示します。したがって、特定のアプリケーションへの証明書の使用を制限します。
A CA may want to delegate parts of its duties to other PKI management entities. This section provides a mechanism to both prove this delegation and enable automated means for checking the authorization of this delegation. Such delegation may also be expressed by other means, e.g., explicit configuration.
CAは、その義務の一部を他のPKI管理エンティティに委任したい場合があります。このセクションは、この委任を証明するメカニズムを提供し、この委任の認可をチェックするための自動化された手段を可能にします。このような委任は、例えば明示的な構成など、他の手段によって表現される場合があります。
To offer automatic validation for the delegation of a role by a CA to another entity, the certificates used for CMP message protection or signed data for central key generation MUST be issued by the delegating CA and MUST contain the respective EKUs. This proves that the delegating CA authorized this entity to act in the given role, as described below.
CAによる役割の委任のための自動検証を別のエンティティに提供するには、CMPメッセージ保護または中央キー生成の署名データに使用される証明書を委任CAによって発行する必要があり、それぞれのEKUを含める必要があります。これは、以下に説明するように、委任CAがこのエンティティが与えられた役割で行動することを許可したことを証明しています。
The OIDs to be used for these EKUs are:
これらのEKUに使用されるOIDは次のとおりです。
id-kp-cmcCA OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) kp(3) 27 }
id-kp-cmcRA OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) kp(3) 28 }
id-kp-cmKGA OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) kp(3) 32 }
Note: Section 2.10 of [RFC6402] specifies OIDs for a Certificate Management over CMS (CMC) CA and a CMC RA. As the functionality of a CA and RA is not specific to any protocol used for managing certificates (such as CMC or CMP), these EKUs are reused by CMP.
注：[RFC6402]のセクション2.10は、CMS（CMC）CAおよびCMC RAを介した証明書管理のOIDを指定しています。CAとRAの機能は、証明書の管理（CMCやCMPなど）の管理に使用されるプロトコルに固有のものではないため、これらのEKUはCMPによって再利用されます。
The meaning of the id-kp-cmKGA EKU is as follows:
ID-KP-CMKGA EKUの意味は次のとおりです。
CMP KGA:
CMP KGA：
CMP KGAs are CAs or are identified by the id-kp-cmKGA EKU. The CMP KGA knows the private key it generated on behalf of the end entity. This is a very sensitive service and needs specific authorization, which by default is with the CA certificate itself. The CA may delegate its authorization by placing the id-kp-cmKGA EKU in the certificate used to authenticate the origin of the generated private key. The authorization may also be determined through local configuration of the end entity.
CMP KGAはCASであるか、ID-KP-CMKGA EKUによって識別されます。CMP KGAは、最終エンティティに代わって生成された秘密鍵を知っています。これは非常にデリケートなサービスであり、特定の承認が必要であり、デフォルトではCA証明書自体にあります。CAは、生成された秘密鍵の原点を認証するために使用される証明書にID-KP-CMKGA EKUを証明書に配置することにより、承認を委任することができます。承認は、最終エンティティのローカル構成によっても決定される場合があります。
This section contains descriptions of the data structures required for PKI management messages. Section 6 describes constraints on their values and the sequence of events for each of the various PKI management operations.
このセクションには、PKI管理メッセージに必要なデータ構造の説明が含まれています。セクション6では、さまざまなPKI管理操作のそれぞれの値と一連のイベントに関する制約について説明します。
All of the messages used in this specification for the purposes of PKI management use the following structure:
PKI管理の目的でこの仕様で使用されるすべてのメッセージは、次の構造を使用します。
PKIMessage ::= SEQUENCE {
header PKIHeader,
body PKIBody,
protection [0] PKIProtection OPTIONAL,
extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate
OPTIONAL
}
PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage
The PKIHeader contains information that is common to many PKI messages.
PKIHeaderには、多くのPKIメッセージに共通の情報が含まれています。
The PKIBody contains message-specific information.
pkibodyにはメッセージ固有の情報が含まれています。
The PKIProtection, when used, contains bits that protect the PKI message.
PKIPROTECTIONは、使用すると、PKIメッセージを保護するビットが含まれています。
The extraCerts field can contain certificates that may be useful to the recipient. For example, this can be used by a CA or RA to present an end entity with certificates that it needs to verify its own new certificate (for example, if the CA that issued the end entity's certificate is not a root CA for the end entity). Note that this field does not necessarily contain a certification path; the recipient may have to sort, select from, or otherwise process the extra certificates in order to use them.
Extracertsフィールドには、受信者に役立つ可能性のある証明書を含めることができます。たとえば、これはCAまたはRAが使用して、独自の新しい証明書を検証する必要がある証明書を終了エンティティに提示することができます（たとえば、エンティティの証明書を発行したCAが終了エンティティのルートCAではない場合）。このフィールドには必ずしも認証パスが含まれているわけではないことに注意してください。受信者は、使用するために追加の証明書を並べ替え、選択、または処理する必要がある場合があります。
All PKI messages require some header information for addressing and transaction identification. Some of this information will also be present in a transport-specific envelope. However, if the PKI message is protected, then this information is also protected (i.e., we make no assumption about secure transport).
すべてのPKIメッセージには、アドレス指定とトランザクション識別のためのヘッダー情報が必要です。この情報の一部は、輸送固有のエンベロープにも存在します。ただし、PKIメッセージが保護されている場合、この情報も保護されています（つまり、安全な輸送について仮定しません）。
The following data structure is used to contain this information:
次のデータ構造は、この情報を抑えるために使用されます。
PKIHeader ::= SEQUENCE {
pvno INTEGER { cmp1999(1), cmp2000(2),
cmp2021(3) },
sender GeneralName,
recipient GeneralName,
messageTime [0] GeneralizedTime OPTIONAL,
protectionAlg [1] AlgorithmIdentifier{ALGORITHM, {...}}
OPTIONAL,
senderKID [2] KeyIdentifier OPTIONAL,
recipKID [3] KeyIdentifier OPTIONAL,
transactionID [4] OCTET STRING OPTIONAL,
senderNonce [5] OCTET STRING OPTIONAL,
recipNonce [6] OCTET STRING OPTIONAL,
freeText [7] PKIFreeText OPTIONAL,
generalInfo [8] SEQUENCE SIZE (1..MAX) OF
InfoTypeAndValue OPTIONAL
}
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
The usage of the protocol version number (pvno) is described in Section 7.
プロトコルバージョン番号（PVNO）の使用については、セクション7で説明されています。
The sender field contains the name of the sender of the PKIMessage. This name (in conjunction with senderKID, if supplied) should be sufficient to indicate the key to use to verify the protection on the message. If nothing about the sender is known to the sending entity (e.g., in the initial request message, where the end entity may not know its own DN, email name, IP address, etc.), then the "sender" field MUST contain a "NULL-DN" value in the directoryName choice. A "NULL-DN" is a SEQUENCE OF relative DNs of zero length and is encoded as 0x3000. In such a case, the senderKID field MUST hold an identifier (i.e., a reference number) that indicates to the receiver the appropriate shared secret information to use to verify the message.
送信者フィールドには、pkimessageの送信者の名前が含まれています。この名前（供給されている場合は、senderkidと併せて）は、メッセージの保護を検証するために使用する鍵を示すのに十分でなければなりません。送信者について送信エンティティに知られていない場合（例：最終エンティティが独自のDN、電子メール名、IPアドレスなどを知らない最初の要求メッセージで）、「送信者」フィールドには、ディレクトリ名の選択に「null-dn」値を含める必要があります。「null-dn」は、長さがゼロの相対DNSのシーケンスであり、0x3000としてエンコードされます。そのような場合、SenderKidフィールドは、メッセージを検証するために使用する適切な共有秘密情報を受信者に示す識別子（つまり、参照番号）を保持する必要があります。
The recipient field contains the name of the recipient of the PKIMessage. This name (in conjunction with recipKID, if supplied) should be usable to verify the protection on the message.
受信フィールドには、pkimessageの受信者の名前が含まれています。この名前（Recistkidと併せて、提供される場合）は、メッセージの保護を検証するために使用できる必要があります。
The protectionAlg field specifies the algorithm used to protect the message. If no protection bits are supplied (note that PKIProtection is OPTIONAL), then this field MUST be omitted; if protection bits are supplied, then this field MUST be supplied.
Protectionalgフィールドは、メッセージを保護するために使用されるアルゴリズムを指定します。保護ビットが供給されない場合（pkiprotectionがオプションであることに注意してください）、このフィールドは省略する必要があります。保護ビットが供給される場合は、このフィールドに供給する必要があります。
senderKID and recipKID are usable to indicate which keys have been used to protect the message (recipKID will normally only be required where protection of the message uses DH or Elliptic Curve Diffie-Hellman (ECDH) keys). These fields MUST be used if required to uniquely identify a key (e.g., if more than one key is associated with a given sender name). The senderKID SHOULD be used in any case.
SenderKidとRecipkidは、メッセージを保護するために使用されたキーを示すために使用可能です（通常、メッセージの保護がDHまたはElliptic Curve Diffie-Hellman（ECDH）キーを使用する場合にのみ必要です）。これらのフィールドは、キーをユニークに識別するために必要な場合に使用する必要があります（たとえば、特定の送信者名に複数のキーが関連付けられている場合）。SenderKidは、いずれにしても使用する必要があります。
Note: The recommendation of using senderKID has changed since [RFC4210], where it was recommended to be omitted if not needed to identify the protection key.
注：SenderKidの使用の推奨事項は、[RFC4210]以来変更されました。これは、保護キーを特定するために必要でない場合は省略することをお勧めしました。
The transactionID field within the message header is to be used to allow the recipient of a message to correlate this with an ongoing transaction. This is needed for all transactions that consist of more than just a single request/response pair. For transactions that consist of a single request/response pair, the rules are as follows. A client MUST populate the transactionID field if the message contains an infoValue of type KemCiphertextInfo (see Section 5.1.3.4). In all other cases, the client MAY populate the transactionID field of the request. If a server receives such a request that has the transactionID field set, then it MUST set the transactionID field of the response to the same value. If a server receives such request with a missing transactionID field, then it MUST populate the transactionID field if the message contains a KemCiphertextInfo field. In all other cases, the server MAY set the transactionID field of the response.
メッセージヘッダー内のTransactionIDフィールドを使用して、メッセージの受信者がこれを継続的なトランザクションと相関させることができます。これは、単一のリクエスト/応答ペア以上のもので構成されるすべてのトランザクションに必要です。単一のリクエスト/応答ペアで構成されるトランザクションの場合、ルールは次のとおりです。メッセージにタイプKemciphertextinfoの情報値が含まれている場合、クライアントはTransactionIDフィールドに入力する必要があります（セクション5.1.3.4を参照）。他のすべての場合において、クライアントはリクエストのTransactionIDフィールドに入力する場合があります。サーバーがTransactionIDフィールドセットを備えたそのような要求を受信した場合、同じ値への応答のTransactionIDフィールドを設定する必要があります。サーバーが不足しているTransactionIDフィールドでそのような要求を受信した場合、メッセージにKemciphertextinfoフィールドが含まれている場合、TransactionIDフィールドに入力する必要があります。他のすべての場合、サーバーは応答のトランザクションIDフィールドを設定する場合があります。
For transactions that consist of more than just a single request/ response pair, the rules are as follows. If the message contains an infoValue of type KemCiphertextInfo, the client MUST generate a transactionID; otherwise, the client SHOULD generate a transactionID for the first request. If a server receives such a request that has the transactionID field set, then it MUST set the transactionID field of the response to the same value. If a server receives such request with a missing transactionID field, then it MUST populate the transactionID field of the response with a server-generated ID. Subsequent requests and responses MUST all set the transactionID field to the thus established value. In all cases where a transactionID is being used, a given client MUST NOT have more than one transaction with the same transactionID in progress at any time (to a given server). Servers are free to require uniqueness of the transactionID or not, as long as they are able to correctly associate messages with the corresponding transaction. Typically, this means that a server will require the {client, transactionID} tuple to be unique, or even the transactionID alone to be unique, if it cannot distinguish clients based on any transport-level information. A server receiving the first message of a transaction (which requires more than a single request/response pair) that contains a transactionID that does not allow it to meet the above constraints (typically because the transactionID is already in use) MUST send back an ErrorMsgContent with a PKIFailureInfo of transactionIdInUse. It is RECOMMENDED that the clients fill the transactionID field with 128 bits of (pseudo-)random data for the start of a transaction to reduce the probability of having the transactionID in use at the server.
単一のリクエスト/応答ペア以上のもので構成されるトランザクションの場合、ルールは次のとおりです。メッセージにkemciphertextinfoのタイプの情報が含まれている場合、クライアントはトランザクションIDを生成する必要があります。それ以外の場合、クライアントは最初のリクエストのためにトランザクションIDを生成する必要があります。サーバーがTransactionIDフィールドセットを備えたそのような要求を受信した場合、同じ値への応答のTransactionIDフィールドを設定する必要があります。サーバーが不足しているTransactionIDフィールドでそのような要求を受信した場合、サーバーで生成されたIDを使用して、応答のトランザクションIDフィールドに設置する必要があります。その後のリクエストと応答はすべて、TransactionIDフィールドをこのように確立された値に設定する必要があります。TransactionIDが使用されているすべての場合において、特定のクライアントは、いつでも（特定のサーバーに）進行中の同じトランザクションIDを使用して複数のトランザクションを持っている必要があります。サーバーは、対応するトランザクションにメッセージを正しく関連付けることができる限り、TransactionIDの独自性を自由に必要とします。通常、これは、サーバーが{クライアント、トランザクションID}タプルが一意であることを要求することを意味します。または、トランスポートレベルの情報に基づいてクライアントを区別できない場合は、トランザクションIDだけであることが一意であることを意味します。トランザクションの最初のメッセージ（単一のリクエスト/応答ペアを必要とする）を受信するサーバーは、上記の制約を満たさないトランザクションID（通常、トランザクションIDがすでに使用されているため）を含む必要があります。クライアントは、トランザクションの開始時にTransactionIDフィールドを128ビットの（擬似）ランダムデータで埋めて、サーバーでTransactionIDを使用する可能性を減らすことをお勧めします。
The senderNonce and recipNonce fields protect the PKIMessage against replay attacks. The senderNonce will typically be 128 bits of (pseudo-)random data generated by the sender, whereas the recipNonce is copied from the senderNonce field of the previous message in the transaction.
SendernonceとRecistnonceフィールドは、リプレイ攻撃からPkimessageを保護します。Sendernonceは通常、送信者によって生成された128ビットの（擬似）ランダムデータになりますが、Recipnonceはトランザクションの前のメッセージのSendernonceフィールドからコピーされます。
The messageTime field contains the time at which the sender created the message. This may be useful to allow end entities to correct/ check their local time for consistency with the time on a central system.
Messagetimeフィールドには、送信者がメッセージを作成する時間が含まれています。これは、最終エンティティが中央システムの時間との一貫性について現地時間を修正/確認できるようにするのに役立つ場合があります。
The freeText field may be used to send a human-readable message to the recipient (in any number of languages). Each UTF8String MAY include a language tag [RFC5646] to indicate the language of the contained text. The first language used in this sequence indicates the desired language for replies.
フリーテキストフィールドを使用して、人間の読み取り可能なメッセージを受信者に（任意の数の言語で）送信することができます。各UTF8STRINGには、含まれるテキストの言語を示す言語タグ[RFC5646]が含まれる場合があります。このシーケンスで使用される第一言語は、返信に望ましい言語を示します。
The generalInfo field may be used to send machine-processable additional data to the recipient. The following generalInfo extensions are defined and MAY be supported.
GeneralInfoフィールドを使用して、マシン処理可能な追加データを受信者に送信できます。以下のgeneralInfo拡張機能が定義されており、サポートされる場合があります。
This is used by the end entity to inform the CA or RA that it does not wish to send a certificate confirmation for issued certificates.
これは、終了エンティティによって使用されて、発行された証明書の証明書確認を送信したくないことをCAまたはRAに通知します。
id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13}
ImplicitConfirmValue ::= NULL
If the CA grants the request to the end entity, it MUST put the same extension in the PKIHeader of the response. If the end entity does not find the extension in the response, it MUST send the certificate confirmation.
CAが最終エンティティへの要求を付与する場合、同じ拡張機能を応答のpkiheaderに配置する必要があります。終了エンティティが応答に拡張機能を見つけられない場合、証明書の確認を送信する必要があります。
This is used by the CA or RA to inform the end entity how long it intends to wait for the certificate confirmation before revoking the certificate and deleting the transaction.
これは、CAまたはRAによって使用されて、証明書を取り消してトランザクションを削除する前に証明書確認を待つ予定であるエンティティを通知します。
id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14}
ConfirmWaitTimeValue ::= GeneralizedTime
An RA MAY include the original PKIMessage from the end entity in the generalInfo field of the PKIHeader of a PKIMessage. This is used by the RA to inform the CA of the original PKIMessage that it received from the end entity and modified in some way (e.g., added or modified particular field values or added new extensions) before forwarding the new PKIMessage. This accommodates, for example, cases in which the CA wishes to check the message origin, the POP, or other information on the original end entity message.
RAには、pkimessageのpkiheaderのGeneralInfoフィールドにある最終エンティティからの元のpkimessageが含まれる場合があります。これはRAで使用され、CAに最終エンティティから受け取った元の潜水積を通知し、新しいpkimessageを転送する前に何らかの方法で変更され（たとえば、特定のフィールド値または追加された新しい拡張機能を追加または変更した）ことを通知します。これは、たとえば、CAがメッセージの原点、POP、または元のEndエンティティメッセージのその他の情報を確認したい場合に対応します。
Note: If the changes made by the RA to the original PKIMessage break the POP of a certificate request, the RA can set the popo field of the new PKIMessage to raVerified (see Section 5.2.8.4).
注：RAが元のPkimessageに加えた変更が証明書リクエストのポップを破壊すると、RAは新しいPkimessageのPopoフィールドをラバイ化に設定できます（セクション5.2.8.4を参照）。
Unless the OrigPKIMessage infoValue is in the header of a nested message, it MUST contain exactly one PKIMessage. The contents of OrigPKIMessage infoValue in the header of a nested message MAY contain multiple PKIMessage structures, which MUST be in the same order as the PKIMessage structures in PKIBody.
OrigpKimessage InfoValueがネストされたメッセージのヘッダーにある場合を除き、正確に1つのpkimessageを含める必要があります。ネストされたメッセージのヘッダーにあるOrigpKimessage InfoValueの内容には、複数のpkimessage構造が含まれている場合があります。これは、pkibodyのpkimessage構造と同じ順序でなければなりません。
id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15}
OrigPKIMessageValue ::= PKIMessages
This is used by the end entity to indicate specific certificate profiles, e.g., when requesting a new certificate or a certificate request template (see Section 5.3.19.16).
これは、新しい証明書プロファイルを示すために最終エンティティによって使用されます。たとえば、新しい証明書または証明書要求テンプレートを要求する場合（セクション5.3.19.16を参照）。
id-it-certProfile OBJECT IDENTIFIER ::= {id-it 21}
CertProfileValue ::= SEQUENCE SIZE (1..MAX) OF UTF8String
When used in a p10cr message, the CertProfileValue sequence MUST NOT contain multiple certificate profile names. When used in an ir/cr/kur/genm message, the CertProfileValue sequence MUST NOT contain more certificate profile names than the number of CertReqMsg or GenMsgContent InfoTypeAndValue elements contained in the message body.
P10CRメッセージで使用する場合、certProfilevalueシーケンスには複数の証明書プロファイル名を含めてはなりません。IR/CR/KUR/GENMメッセージで使用する場合、certProfilevalueシーケンスには、メッセージ本文に含まれるcertreqmsgまたはgenmsgcontent infotypeandvalue要素の数よりも多くの証明書プロファイル名を含めることはできません。
The certificate profile names in the CertProfileValue sequence relate to the CertReqMsg or GenMsgContent InfoTypeAndValue elements in the given order. An empty string means no certificate profile name is associated with the respective CertReqMsg or GenMsgContent InfoTypeAndValue element. If the CertProfileValue sequence contains less certificate profile entries than CertReqMsg or GenMsgContent InfoTypeAndValue elements, the remaining CertReqMsg or GenMsgContent InfoTypeAndValue elements have no profile name associated with them.
CertProfileValueシーケンスの証明書プロファイル名は、指定された順序でcertreqMSGまたはgenmsgContentインフォタイプアンドバリュー要素に関連しています。空の文字列は、証明書プロファイル名がそれぞれのcertreqmsgまたはgenmsgcontent infotypeandValue要素に関連付けられていないことを意味します。CertProfileValueシーケンスにCertreQMSGまたはGenmsgContent InfotypeandValue要素よりも少ない証明書プロファイルエントリが含まれている場合、残りのCertreQMSGまたはGenmsgContent InfotypeandValue要素には、それらに関連するプロファイル名がありません。
A PKI entity MAY provide the KEM ciphertext for MAC-based message protection using KEM (see Section 5.1.3.4) in the generalInfo field of a request message to a PKI management entity if it knows that the PKI management entity uses a KEM key pair and has its public key.
PKIエンティティは、PKI管理エンティティがKEMキーペアを使用し、公開キーを持っていることを知っている場合、PKI管理エンティティへの要求メッセージの一般的なフィールドのKEM（セクション5.1.3.4を参照）を使用して、Macベースのメッセージ保護用のKEM Ciphertextを提供できます。
id-it-KemCiphertextInfo OBJECT IDENTIFIER ::= { id-it 24 }
KemCiphertextInfoValue ::= KemCiphertextInfo
For more details of KEM-based message protection, see Section 5.1.3.4. See Section 5.3.19.18 for the definition of {id-it 24}.
KEMベースのメッセージ保護の詳細については、セクション5.1.3.4を参照してください。{id-it 24}の定義については、セクション5.3.19.18を参照してください。
PKIBody ::= CHOICE {
ir [0] CertReqMessages, --Initialization Req
ip [1] CertRepMessage, --Initialization Resp
cr [2] CertReqMessages, --Certification Req
cp [3] CertRepMessage, --Certification Resp
p10cr [4] CertificationRequest, --PKCS #10 Cert. Req.
popdecc [5] POPODecKeyChallContent, --pop Challenge
popdecr [6] POPODecKeyRespContent, --pop Response
kur [7] CertReqMessages, --Key Update Request
kup [8] CertRepMessage, --Key Update Response
krr [9] CertReqMessages, --Key Recovery Req
krp [10] KeyRecRepContent, --Key Recovery Resp
rr [11] RevReqContent, --Revocation Request
rp [12] RevRepContent, --Revocation Response
ccr [13] CertReqMessages, --Cross-Cert. Request
ccp [14] CertRepMessage, --Cross-Cert. Resp
ckuann [15] CAKeyUpdContent, --CA Key Update Ann.
cann [16] CertAnnContent, --Certificate Ann.
rann [17] RevAnnContent, --Revocation Ann.
crlann [18] CRLAnnContent, --CRL Announcement
pkiconf [19] PKIConfirmContent, --Confirmation
nested [20] NestedMessageContent, --Nested Message
genm [21] GenMsgContent, --General Message
genp [22] GenRepContent, --General Response
error [23] ErrorMsgContent, --Error Message
certConf [24] CertConfirmContent, --Certificate Confirm
pollReq [25] PollReqContent, --Polling Request
pollRep [26] PollRepContent --Polling Response
}
The specific types are described in Section 5.3 below.
特定のタイプについては、以下のセクション5.3で説明します。
Some PKI messages will be protected for integrity.
一部のPKIメッセージは、完全性のために保護されます。
Note: If an asymmetric algorithm is used to protect a message and the relevant public component has been certified already, then the origin of the message can also be authenticated. On the other hand, if the public component is uncertified, then the message origin cannot be automatically authenticated but may be authenticated via out-of-band means.
注：非対称アルゴリズムを使用してメッセージを保護し、関連するパブリックコンポーネントがすでに認定されている場合、メッセージの起源も認証できます。一方、パブリックコンポーネントが認証されていない場合、メッセージの原点は自動的に認証されることはできませんが、帯域外の手段を介して認証される場合があります。
When protection is applied, the following structure is used:
保護が適用されると、次の構造が使用されます。
PKIProtection ::= BIT STRING
The input to the calculation of PKIProtection is the DER encoding of the following data structure:
pkiprotectionの計算への入力は、次のデータ構造のderエンコードです。
ProtectedPart ::= SEQUENCE {
header PKIHeader,
body PKIBody
}
There MAY be cases in which the PKIProtection BIT STRING is deliberately not used to protect a message (i.e., this OPTIONAL field is omitted) because other protection, external to PKIX, will be applied instead. Such a choice is explicitly allowed in this specification. Examples of such external protection include CMS [RFC5652] and Security Multiparts [RFC1847] encapsulation of the PKIMessage (or simply the PKIBody (omitting the CHOICE tag), if the relevant PKIHeader information is securely carried in the external mechanism). It is noted, however, that many such external mechanisms require that the end entity already possesses a public-key certificate, a unique DN, and/or other such infrastructure-related information. Thus, they may not be appropriate for initial registration, key-recovery, or any other process with "bootstrapping" characteristics. For those cases, it may be necessary that the PKIProtection parameter be used. In the future, if/when external mechanisms are modified to accommodate bootstrapping scenarios, the use of PKIProtection may become rare or non-existent.
PKIXの外部である他の保護が代わりに適用されるため、メッセージを保護するためにPKIPROTECTION BIT文字列が意図的に使用されない場合があります（つまり、このオプションフィールドは省略されます）。このような選択は、この仕様で明示的に許可されています。このような外部保護の例には、関連するpkiheader情報が外部メカニズムで安全に運ばれる場合、CMS [RFC5652]およびセキュリティマルチパート[RFC1847]のカプセル化（または単にpkibody（選択タグを省略））のカプセル化が含まれます。ただし、そのような外部メカニズムの多くは、最終エンティティがすでに公開キー証明書、一意のDN、および/またはその他のインフラストラクチャ関連情報を所有していることを要求していることに注意してください。したがって、最初の登録、キー回復、または「ブートストラップ」特性を備えたその他のプロセスには適していない場合があります。これらの場合には、pkiprotectionパラメーターを使用する必要がある場合があります。将来的には、ブートストラップシナリオに対応するために外部メカニズムが変更された場合、PKIPROTECTIONの使用はまれまたは存在しない場合があります。
Depending on the circumstances, the PKIProtection bits may contain a MAC or signature. Only the following cases can occur:
状況に応じて、PKIPROTECTIONビットにはMACまたは署名が含まれる場合があります。次のケースのみが発生する可能性があります。
In this case, the sender and recipient share secret information with sufficient entropy (established via out-of-band means). PKIProtection will contain a MAC value, and the protectionAlg MAY be one of the options described in Section 6.1 of CMP Algorithms [RFC9481].
この場合、送信者と受信者は、十分なエントロピー（帯域外の手段を介して確立された）で秘密情報を共有します。PKIPROTECTIONにはMAC値が含まれ、保護物はCMPアルゴリズム[RFC9481]のセクション6.1で説明されているオプションの1つである可能性があります。
The algorithm identifier id-PasswordBasedMac is defined in Section 4.4 of [RFC4211] and updated by [RFC9045]. It is mentioned in Section 6.1.1 of [RFC9481] for backward compatibility. More modern alternatives are listed in Section 6.1 of [RFC9481].
アルゴリズム識別子ID-PassWordBasedMacは、[RFC4211]のセクション4.4で定義され、[RFC9045]によって更新されます。後方互換性については、[RFC9481]のセクション6.1.1で言及されています。[RFC9481]のセクション6.1に、より近代的な代替品がリストされています。
id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13}
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
iterationCount INTEGER,
mac AlgorithmIdentifier
}
The following text gives a method of key expansion to be used when the MAC algorithm requires an input length that is larger than the size of the one-way function (OWF).
次のテキストは、MACアルゴリズムが一方向関数（OWF）のサイズよりも大きい入力長を必要とする場合に使用する重要な拡張の方法を示します。
Note: Section 4.4 of [RFC4211] and [RFC9045] do not mention this key expansion method or give an example using HMAC algorithms where key expansion is not needed. It is recognized that this omission in [RFC4211] can lead to confusion and possible incompatibility if key expansion [RFC4210] is not used when needed. Therefore, when key expansion is required (when K > H), the key expansion defined in the following text MUST be used.
注：[RFC4211]および[RFC9045のセクション4.4]は、この重要な拡張方法に言及したり、キー拡張が不要なHMACアルゴリズムを使用して例を挙げたりしません。[RFC4211]でのこの省略は、必要に応じて主要な拡張[RFC4210]が使用されない場合、混乱と非互換性につながる可能性があることが認識されています。したがって、キー拡張が必要な場合（K> Hの場合）、次のテキストで定義されているキー拡張を使用する必要があります。
In the above protectionAlg, the salt value is appended to the shared secret input. The OWF is then applied iterationCount times, where the salted secret is the input to the first iteration and, for each successive iteration, the input is set to be the output of the previous iteration. The output of the final iteration (called "BASEKEY" for ease of reference, with a size of "H") is what is used to form the symmetric key. If the MAC algorithm requires a K-bit key and K <= H, then the most significant K bits of BASEKEY are used. If K > H, then all of BASEKEY is used for the most significant H bits of the key, OWF("1" || BASEKEY) is used for the next most significant H bits of the key, OWF("2" || BASEKEY) is used for the next most significant H bits of the key, and so on, until all K bits have been derived. [Here "N" is the ASCII byte encoding the number N and "||" represents concatenation.]
上記の保護では、塩値は共有秘密の入力に追加されます。その後、OWFは反復時間を適用します。ここで、塩漬けの秘密は最初の反復への入力であり、連続する各反復に対して、入力は前の反復の出力に設定されます。最終的な反復の出力（参照を容易にするための「basekey」と呼ばれ、「H」のサイズのサイズ）は、対称キーを形成するために使用されるものです。MacアルゴリズムにKビットキーとk <= hが必要な場合、ベースキーの最も重要なKビットが使用されます。k> hの場合、すべてのBaseKeyがキーの最も重要なHビットに使用される場合、OWF（ "1" || baseKey）がキーの次の重要なHビットに使用されます。OWF（ "2" || basekey）は、すべてのKビットが導出されるまで次の最も重要なHビットなどに使用されます。[ここでは、 "n"はnと「||」をエンコードするASCIIバイトです。連結を表します。]
Note: It is RECOMMENDED that the fields of PBMParameter remain constant throughout the messages of a single transaction (e.g., ir/ip/certConf/pkiConf) to reduce the overhead associated with PasswordBasedMac computation.
注：PBMParameterのフィールドは、パスワードベースMAC計算に関連するオーバーヘッドを減らすために、単一のトランザクション（例：IR/IP/CERTCONF/PKICONF）のメッセージ全体で一定のままでいることをお勧めします。
Where the sender and receiver possess finite-field or elliptic-curve-based DH certificates with compatible DH parameters in order to protect the message, the end entity must generate a symmetric key based on its private DH key value and the DH public key of the recipient of the PKI message. PKIProtection will contain a MAC value keyed with this derived symmetric key, and the protectionAlg will be the following:
送信者とレシーバーが、互換性のあるDHパラメーターを備えた有限フィールドまたは楕円曲線ベースのDH証明書をメッセージを保護するために持っている場合、最終エンティティは、プライベートDHキー値とPKIメッセージの受信者のDH公開キーに基づいて対称キーを生成する必要があります。PKIPROTECTIONには、この派生した対称キーでキー付きMAC値が含まれ、保護は次のとおりです。
id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30}
DHBMParameter ::= SEQUENCE {
owf AlgorithmIdentifier,
-- AlgId for an OWF
mac AlgorithmIdentifier
-- the MAC AlgId
}
In the above protectionAlg, OWF is applied to the result of the DH computation. The OWF output (called "BASEKEY" for ease of reference, with a size of "H") is what is used to form the symmetric key. If the MAC algorithm requires a K-bit key and K <= H, then the most significant K bits of BASEKEY are used. If K > H, then all of BASEKEY is used for the most significant H bits of the key, OWF("1" || BASEKEY) is used for the next most significant H bits of the key, OWF("2" || BASEKEY) is used for the next most significant H bits of the key, and so on, until all K bits have been derived. [Here "N" is the ASCII byte encoding the number N and "||" represents concatenation.]
上記の保護物では、OWFがDH計算の結果に適用されます。OWF出力（「H」のサイズを備えた参照のための「ベースキー」と呼ばれる）は、対称キーを形成するために使用されるものです。MacアルゴリズムにKビットキーとk <= hが必要な場合、ベースキーの最も重要なKビットが使用されます。k> hの場合、すべてのBaseKeyがキーの最も重要なHビットに使用される場合、OWF（ "1" || baseKey）がキーの次の重要なHビットに使用されます。OWF（ "2" || basekey）は、すべてのKビットが導出されるまで次の最も重要なHビットなどに使用されます。[ここでは、 "n"はnと「||」をエンコードするASCIIバイトです。連結を表します。]
Note: Hash algorithms that can be used as OWFs are listed in Section 2 of CMP Algorithms [RFC9481].
注：OWFとして使用できるハッシュアルゴリズムは、CMPアルゴリズム[RFC9481]のセクション2にリストされています。
In this case, the sender possesses a signature key pair and simply signs the PKI message. PKIProtection will contain the signature value and the protectionAlg will be an AlgorithmIdentifier for a digital signature, which MAY be one of the options described in Section 3 of CMP Algorithms [RFC9481].
この場合、送信者は署名キーペアを所有し、PKIメッセージに単純に署名します。PKIPROTECTIONには署名値が含まれ、PrittionalGはデジタル署名のアルゴリズムのIndidifierになります。これは、CMPアルゴリズム[RFC9481]のセクション3で説明されているオプションの1つである可能性があります。
In case the sender of a message has a KEM key pair, it can be used to establish a shared secret key for MAC-based message protection. This can be used for message authentication.
メッセージの送信者がKEMキーペアを持っている場合、Macベースのメッセージ保護の共有シークレットキーを確立するために使用できます。これは、メッセージ認証に使用できます。
This approach uses the definition of KEM algorithm functions in Section 1 of [RFC9629] as follows:
このアプローチでは、次のように[RFC9629]のセクション1のKEMアルゴリズム関数の定義を使用します。
A KEM algorithm provides three functions:
KEMアルゴリズムは3つの関数を提供します。
1. KeyGen() -> (pk, sk): Generate a public key (pk) and a private (secret) key (sk).
1. keygen（） - >（PK、SK）：公開キー（PK）とプライベート（秘密）キー（SK）を生成します。
2. Encapsulate(pk) -> (ct, ss): Given the public key (pk), produce a ciphertext (ct) and a shared secret (ss).
2. cancapsulate（pk） - >（ct、ss）：公開鍵（PK）が与えられた場合、暗号文（CT）と共有秘密（SS）を生成します。
3. Decapsulate(sk, ct) -> (ss): Given the private key (sk) and the ciphertext (ct), produce the shared secret (ss).
3. Decapsulate（SK、CT） - >（SS）：秘密鍵（SK）と暗号文（CT）を与えられた場合、共有秘密（SS）を生成します。
To support a particular KEM algorithm, the PKI entity that possesses a KEM key pair and wishes to use it for MAC-based message protection MUST support the KEM Decapsulate() function. The PKI entity that wishes to verify the MAC-based message protection MUST support the KEM Encapsulate() function. The respective public KEM key is usually carried in a certificate [ML-KEM].
特定のKEMアルゴリズムをサポートするには、KEMキーペアを所有し、MACベースのメッセージ保護に使用したいPKIエンティティは、KEM Decapsulate（）関数をサポートする必要があります。Macベースのメッセージ保護を確認したいPKIエンティティは、KEM cankapsulate（）関数をサポートする必要があります。それぞれの公開KEMキーは通常、証明書[ML-KEM]に携帯されています。
Note: Both PKI entities send and receive messages in a PKI management operation. Both PKI entities may independently wish to protect messages using their KEM key pairs. For ease of explanation, we use the terms "Alice" to denote the PKI entity possessing the KEM key pair and who wishes to provide MAC-based message protection and "Bob" to denote the PKI entity having Alice's authentic public KEM key and who needs to verify the MAC-based protection provided by Alice.
注：両方のPKIエンティティは、PKI管理操作でメッセージを送信および受信します。両方のPKIエンティティは、KEMキーペアを使用してメッセージを独立して保護したい場合があります。説明のために、「アリス」という用語を使用して、KEMキーペアを所有するPKIエンティティを示し、Macベースのメッセージ保護と「ボブ」を提供して、Aliceの本物の公開KEMキーを有するPKIエンティティを示し、Aliceが提供するMacベースの保護を検証する必要があります。
Assuming Bob has Alice's KEM public key, he generates the ciphertext using KEM encapsulation and transfers it to Alice in an InfoTypeAndValue structure. Alice then retrieves the KEM shared secret from the ciphertext using KEM decapsulation and the associated KEM private key. Using a key derivation function (KDF), Alice derives a shared secret key from the KEM shared secret and other data sent by Bob. PKIProtection will contain a MAC value calculated using that shared secret key, and the protectionAlg will be the following:
ボブにアリスのKEMの公開鍵があると仮定すると、彼はKEMカプセル化を使用して暗号文を生成し、インフォタイプと値の構造でアリスに転送します。その後、アリスは、KEMの脱カプセル化と関連するKEM秘密鍵を使用して、暗号文からKEM共有秘密を回収します。キー派生関数（KDF）を使用して、アリスは、KEM共有秘密とボブが送信したその他のデータから共有された秘密の鍵を導き出します。pkiprotectionには、その共有秘密の鍵を使用して計算されたMAC値が含まれ、保護は次のとおりです。
id-KemBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 16}
KemBMParameter ::= SEQUENCE {
kdf AlgorithmIdentifier{KEY-DERIVATION, {...}},
kemContext [0] OCTET STRING OPTIONAL,
len INTEGER (1..MAX),
mac AlgorithmIdentifier{MAC-ALGORITHM, {...}}
}
Note: The OID for id-KemBasedMac was assigned on the private-use arc { iso(1) member-body(2) us(840) nortelnetworks(113533) entrust(7) } and not assigned on an IANA-owned arc because the authors wished to place it on the same branch as the existing OIDs for id-PasswordBasedMac and id-DHBasedMac.
注：ID-KembasedMacのOIDは、個人用アークに割り当てられました{ISO（1）メンバーボディ（2）US（840）nortelnetworks（113533）は（113533）委任状（7）}を委任し、著者がIDの既存のoidmacのために既存のoidmacのためにIDパスのために既存のoidmacのために既存のoidmacのために同じブランチに配置することを望んでいたため、IANAが所有するアークに割り当てられていません。
kdf is the algorithm identifier of the chosen KDF, and any associated parameters, used to derive the shared secret key.
KDFは、選択されたKDFのアルゴリズム識別子であり、共有シークレットキーを導出するために使用される関連パラメーターです。
kemContext MAY be used to transfer additional algorithm-specific context information (see also the definition of ukm in Section 3 of [RFC9629]).
KemContextは、追加のアルゴリズム固有のコンテキスト情報を転送するために使用できます（[RFC9629]のセクション3のUKMの定義も参照）。
len is the output length of the KDF and MUST be the desired size of the key to be used for MAC-based message protection.
LENはKDFの出力長であり、Macベースのメッセージ保護に使用するキーの望ましいサイズでなければなりません。
mac is the algorithm identifier of the chosen MAC algorithm, and any associated parameters, used to calculate the MAC value.
Macは、選択したMacアルゴリズムのアルゴリズム識別子であり、Mac値の計算に使用される関連するパラメーターです。
The KDF and MAC algorithms MAY be chosen from the options in CMP Algorithms [RFC9481].
KDFおよびMACアルゴリズムは、CMPアルゴリズム[RFC9481]のオプションから選択できます。
The InfoTypeAndValue transferring the KEM ciphertext uses OID id-it-KemCiphertextInfo. It contains a KemCiphertextInfo structure, as defined in Section 5.3.19.18.
KEM Ciphertextを転送するInfotypeandValueは、OID ID-IT-KEMCIPHERTEXTINFOを使用します。セクション5.3.19.18で定義されているように、Kemciphertextinfo構造が含まれています。
Note: This InfoTypeAndValue can be carried in a genm/genp message body, as specified in Section 5.3.19.18, or in the generalInfo field of PKIHeader in messages of other types (see Section 5.1.1.5).
注：このinfotypeandValueは、セクション5.3.19.18で指定されているように、他のタイプのメッセージでpkiheaderのgeneralInfoフィールドで指定されているように、Genm/genpメッセージ本文で運ぶことができます（セクション5.1.1.5を参照）。
In the following, a generic message flow for MAC-based protection using KEM is specified in more detail. It is assumed that Bob possesses Alice's public KEM key. Alice can be the initiator of a PKI management operation or the responder. For more detailed figures, see Appendix E.
以下では、KEMを使用したMACベースの保護の汎用メッセージフローが詳細に指定されています。ボブはアリスの公開Kemキーを所有していると想定されています。アリスは、PKI管理操作またはレスポンダーのイニシエーターになることができます。より詳細な図については、付録Eを参照してください。
Generic Message Flow:
一般的なメッセージフロー：
Step# Alice Bob
---------------------------------------------------------------------
1 perform KEM Encapsulate
<-- KEM Ciphertext <--
2 perform KEM Decapsulate,
perform key derivation,
format message with
MAC-based protection
--> message -->
3 perform key derivation,
verify MAC-based
protection
------------------- Alice authenticated by Bob --------------------
Figure 2: Generic Message Flow When Alice Has a KEM Key Pair
図2：アリスがKEMキーペアを持っているときの一般的なメッセージフロー
1. Bob needs to possess Alice's authentic public KEM key (pk), for instance, contained in a KEM certificate that was received and successfully validated by Bob beforehand.
1. たとえば、ボブは、Aliceの本物の公開KEMキー（PK）を所有している必要があります。たとえば、BOBが事前に受け取って正常に検証したKEM証明書に含まれています。
Bob generates a shared secret (ss) and the associated ciphertext (ct) using the KEM Encapsulate function with Alice's public KEM key (pk). Bob MUST NOT reuse the ss and ct for other PKI management operations. From this data, Bob produces a KemCiphertextInfo structure, including the KEM algorithm identifier and the ciphertext (ct) and sends it to Alice in an InfoTypeAndValue structure, as defined in Section 5.3.19.18.
Bob generates a shared secret (ss) and the associated ciphertext (ct) using the KEM Encapsulate function with Alice's public KEM key (pk).Bob MUST NOT reuse the ss and ct for other PKI management operations.このデータから、BobはKEMCIPHERTEXTINFO構造を生成し、KEMアルゴリズム識別子とciphertext（CT）を含み、セクション5.3.19.18で定義されているように、InfotypeandValue構造でアリスに送信します。
Encapsulate(pk) -> (ct, ss)
cancapsulate（pk） - >（ct、ss）
2. Alice decapsulates the shared secret (ss) from the ciphertext (ct) using the KEM Decapsulate function and its private KEM key (sk).
2. アリスは、KEM脱カプセル化関数とそのプライベートKEMキー（SK）を使用して、暗号文（CT）から共有秘密（SS）を脱カプセル化します。
Decapsulate(ct, sk) -> (ss)
Decapsulate（CT、SK） - >（SS）
If the decapsulation operation outputs an error, any failInfo field in an error response message SHALL contain the value badMessageCheck and the PKI management operation SHALL be terminated.
カプセル化操作がエラーを出力する場合、エラー応答メッセージの故障フィールドには値が含まれ、PKI管理操作が終了するものとします。
Alice derives the shared secret key (ssk) using a KDF. The shared secret (ss) is used as input key material for the KDF, and the value len is the desired output length of the KDF as required by the MAC algorithm to be used for message protection. KDF, len, and MAC will be transferred to Bob in the protectionAlg KemBMParameter. The DER-encoded KemOtherInfo structure, as defined below, is used as context for the KDF.
アリスは、KDFを使用して共有シークレットキー（SSK）を導き出します。Shared Secret（SS）はKDFの入力キー資料として使用され、値lenはメッセージ保護に使用されるMACアルゴリズムで必要とされるKDFの望ましい出力長です。KDF、LEN、およびMACは、Protectiong KembmparameterでBoBに転送されます。以下に定義するDer-Encoded Kemotherinfo構造は、KDFのコンテキストとして使用されます。
KDF(ss, len, context)->(ssk)
kdf（ss、len、context） - >（ssk）
The shared secret key (ssk) is used for MAC-based protection by Alice.
共有シークレットキー（SSK）は、アリスによるMacベースの保護に使用されます。
3. Bob derives the same shared secret key (ssk) using the KDF. Also here, the shared secret (ss) is used as input key material for the KDF, the value len is the desired output length for the KDF, and the DER-encoded KemOtherInfo structure constructed in the same way as on Alice's side is used as context for the KDF.
3. ボブは、KDFを使用して同じ共有シークレットキー（SSK）を導き出します。また、ここでは、共有秘密（SS）はKDFの入力キー材料として使用され、値lenはKDFの希望の出力長であり、アリス側と同じ方法で構築されたderエンコードされたkemotherinfo構造がKDFのコンテキストとして使用されます。
KDF(ss, len, context)->(ssk)
kdf（ss、len、context） - >（ssk）
Bob uses the shared secret key (ssk) for verifying the MAC-based protection of the message received and in this way authenticates Alice.
ボブは、共有Secret Key（SSK）を使用して、受信したメッセージのMacベースの保護を確認し、このようにアリスを認証します。
This shared secret key (ssk) can be reused by Alice for MAC-based protection of further messages sent to Bob within the current PKI management operation.
この共有シークレットキー（SSK）は、現在のPKI管理操作内でBOBに送信されたさらなるメッセージのMACベースの保護のために、Aliceが再利用できます。
This approach employs the notation of KDF(IKM, L, info) as described in Section 5 of [RFC9629] with the following changes:
このアプローチは、[RFC9629]のセクション5で説明されているように、KDF（IKM、L、情報）の表記を採用しています。
* IKM is the input key material. It is the symmetric secret called "ss" resulting from the KEM.
* IKMは入力キー資料です。これは、KEMから生じる「SS」と呼ばれる対称的な秘密です。
* L is dependent of the MAC algorithm that is used with the shared secret key for CMP message protection and is called "len" in this document.
* Lは、CMPメッセージ保護の共有シークレットキーで使用され、このドキュメントでは「len」と呼ばれるMacアルゴリズムに依存します。
* info is an additional input to the KDF, is called "context" in this document, and contains the DER-encoded KemOtherInfo structure defined as:
* 情報はKDFへの追加の入力であり、このドキュメントの「コンテキスト」と呼ばれ、次のように定義されたderエンコードされたkemothorinfo構造が含まれています。
KemOtherInfo ::= SEQUENCE {
staticString PKIFreeText,
transactionID OCTET STRING,
kemContext [0] OCTET STRING OPTIONAL
}
staticString MUST be "CMP-KEM".
スタチックストリングは「CMP-KEM」でなければなりません。
transactionID MUST be the value from the message containing the ciphertext (ct) in KemCiphertextInfo.
TransactionIDは、kemciphertextinfoのciphertext（ct）を含むメッセージからの値である必要があります。
Note: The transactionID is used to ensure domain separation of the derived shared secret key between different PKI management operations. For all PKI management operations with more than one exchange, the transactionID MUST be set anyway (see Section 5.1.1). In case Bob provided an infoValue of type KemCiphertextInfo to Alice in the initial request message (see Figure 4 of Appendix E), the transactionID MUST be set by Bob.
注：TransactionIDは、異なるPKI管理操作間で派生した共有シークレットキーのドメイン分離を確保するために使用されます。複数のExchangeを使用したすべてのPKI管理操作については、とにかくTransactionIDを設定する必要があります（セクション5.1.1を参照）。ボブが最初のリクエストメッセージでkemciphertextinfoのタイプの情報値をアリスに提供した場合（付録Eの図4を参照）、トランザクションIDはBOBによって設定する必要があります。
kemContext MAY contain additional algorithm-specific context information.
KemContextには、追加のアルゴリズム固有のコンテキスト情報が含まれる場合があります。
* OKM is the output keying material of the KDF used for MAC-based message protection of length len and is called "ssk" in this document.
* OKMは、長さLENのMacベースのメッセージ保護に使用されるKDFの出力キーイング材料であり、このドキュメントでは「SSK」と呼ばれます。
There are various ways that Alice can request and Bob can provide the KEM ciphertext (see Appendix E for details). The KemCiphertextInfo can be requested using PKI general messages, as described in Section 5.3.19.18. Alternatively, the generalInfo field of the PKIHeader can be used to convey the same request and response InfoTypeAndValue structures, as described in Section 5.1.1.5. The procedure also works without Alice explicitly requesting the KEM ciphertext in case Bob knows one of Alice's KEM keys beforehand and can expect that she is ready to use it.
アリスが要求し、ボブがKEM Ciphertextを提供できるさまざまな方法があります（詳細については、付録Eを参照）。セクション5.3.19.18で説明されているように、KemciphertextinfoはPKI一般メッセージを使用して要求できます。あるいは、PKIHEADERの一般的なフィールドを使用して、セクション5.1.1.5で説明されているように、同じ要求と応答のインフォマチーアンド値構造を伝えることができます。また、この手順は、アリスのKemキーの1つを事前に知っており、彼女がそれを使用する準備ができていることを期待できる場合に備えて、AliceがKem Ciphertextを明示的に要求せずに機能しません。
If both the initiator and responder in a PKI management operation have KEM key pairs, this procedure can be applied by both entities independently, establishing and using different shared secret keys for either direction.
PKI管理操作のイニシエーターとレスポンダーの両方がKEMキーペアを持っている場合、この手順は両方のエンティティによって独立して適用され、どちらの方向にも異なる共有シークレットキーを確立および使用できます。
When receiving a protected PKI message, a PKI management entity, such as an RA, MAY forward that message adding its own protection. Additionally, multiple PKI messages MAY be aggregated. There are several use cases for such messages.
保護されたPKIメッセージを受信すると、RAなどのPKI管理エンティティは、独自の保護を追加するメッセージを転送する場合があります。さらに、複数のPKIメッセージが集約される場合があります。そのようなメッセージにはいくつかのユースケースがあります。
* The RA confirms having validated and authorized a message and forwards the original message unchanged.
* RAは、メッセージを検証および承認したことを確認し、元のメッセージを変更せずに転送します。
* A PKI management entity collects several messages that are to be forwarded in the same direction and forwards them in a batch. Request messages can be transferred as a batch upstream (towards the CA); response or announce messages can be transferred as a batch downstream (towards an RA but not to the end entity). For instance, this can be used when bridging an offline connection between two PKI management entities.
* PKI管理エンティティは、同じ方向に転送されるメッセージを収集し、それらをバッチに転送します。リクエストメッセージは、上流のバッチとして（CAに向かって）転送できます。応答またはアナウンスメッセージは、下流のバッチとして転送できます（RAに向かって、最終エンティティではありません）。たとえば、これは、2つのPKI管理エンティティ間のオフライン接続を橋渡しするときに使用できます。
These use cases are accomplished by nesting the messages within a new PKI message. The structure used is as follows:
これらのユースケースは、新しいPKIメッセージ内でメッセージをネストすることによって達成されます。使用される構造は次のとおりです。
NestedMessageContent ::= PKIMessages
In case an RA needs to modify a request message, it MAY include the original PKIMessage in the generalInfo field of the modified message, as described in Section 5.1.1.3.
RAがリクエストメッセージを変更する必要がある場合、セクション5.1.1.3で説明されているように、変更されたメッセージの一般的なフィールドに元のpkimessageを含めることができます。
Before specifying the specific types that may be placed in a PKIBody, we define some data structures that are used in more than one case.
pkibodyに配置される可能性のある特定のタイプを指定する前に、複数のケースで使用されるいくつかのデータ構造を定義します。
Various PKI management messages require that the originator of the message indicate some of the fields that are required to be present in a certificate. The CertTemplate structure allows entities requesting a certificate to specify the data fields that they want to be included. Typically, they are required to provide at least the publicKey field. A CertTemplate structure is identical to a TBSCertificate structure (see [RFC5280]) but with all fields optional/situational.
さまざまなPKI管理メッセージには、メッセージの発信者が証明書に存在する必要があるフィールドの一部を示す必要があります。CERTTEMPLATE構造により、証明書を要求するエンティティが含まれているデータフィールドを指定することができます。通常、少なくともパブリックキーフィールドを提供する必要があります。証明書構造は、TBSCertificate構造と同一です（[RFC5280]を参照）が、すべてのフィールドがオプション/状況に伴います。
Note: Even if the originator completely specifies the contents of a certificate it requires, a CA is free to modify fields within the certificate actually issued. If the modified certificate is unacceptable to the requester, the requester MUST send back a certConf message that either does not include this certificate (via a CertHash) or does include this certificate (via a CertHash) along with a status of "rejected". See Section 5.3.18 for the definition and use of CertHash and the certConf message.
注：発信者が必要な証明書の内容を完全に指定したとしても、CAは実際に発行された証明書内のフィールドを自由に変更できます。修正された証明書が要求者に受け入れられない場合、リクエスターは、この証明書を（Certhashを介して）含めないか、この証明書（Certhashを介して）を「拒否」のステータスとともに含める証明書を送信する必要があります。CerthashおよびCertConfメッセージの定義と使用については、セクション5.3.18を参照してください。
Note: Before requesting a new certificate, an end entity can request a certTemplate structure as a kind of certificate request blueprint in order to learn which data the CA expects to be present in the certificate request (see Section 5.3.19.16).
注：新しい証明書を要求する前に、End Entityは、CAが証明書リクエストに存在すると予想されるデータを学習するために、証明書リクエストの青写真の一種としてCertTemplate構造を要求できます（セクション5.3.19.16を参照）。
See CRMF [RFC4211] for CertTemplate syntax.
CERTTEMPLATE構文については、CRMF [RFC4211]を参照してください。
If certTemplate is an empty SEQUENCE (i.e., all fields omitted), then the controls field in the CertRequest structure MAY contain the id-regCtrl-altCertTemplate control, specifying a template for a certificate other than an X.509v3 public-key certificate. Conversely, if certTemplate is not empty (i.e., at least one field is present), then controls MUST NOT contain id-regCtrl-altCertTemplate. The new control is defined as follows:
CertTemplateが空のシーケンス（つまり、すべてのフィールドが省略されている）である場合、certrequest構造のコントロールフィールドには、x.509v3パブリックキー証明書以外の証明書のテンプレートを指定して、id-regctrl-altcerttemplateコントロールを含める場合があります。逆に、certtemplateが空でない場合（つまり、少なくとも1つのフィールドが存在する）、コントロールにはID-regctrl-altcerttemplateを含めてはなりません。新しいコントロールは次のように定義されています。
id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) pkip(5) regCtrl(1) 7}
AltCertTemplate ::= AttributeTypeAndValue
Also see [RFC4212] for more details on how to manage certificates in alternative formats using CRMF [RFC4211] syntax.
また、CRMF [RFC4211]構文を使用して、代替形式で証明書を管理する方法の詳細については、[RFC4212]を参照してください。
When encrypted data like a private key, certificate, POP challenge, or revocation passphrase is sent in PKI messages, it is RECOMMENDED to use the EnvelopedData structure. In some cases, this is accomplished by using the EncryptedKey data structure instead of EncryptedValue.
秘密鍵、証明書、ポップチャレンジ、または撤回パスフレーズなどの暗号化されたデータがPKIメッセージで送信される場合、EnvelopedData構造を使用することをお勧めします。場合によっては、これは、暗号化されたValueの代わりに暗号化されたデータ構造を使用することによって実現されます。
EncryptedKey ::= CHOICE {
encryptedValue EncryptedValue, -- deprecated
envelopedData [0] EnvelopedData }
See Certificate Request Message Format (CRMF) [RFC4211] for EncryptedKey and EncryptedValue syntax and Cryptographic Message Syntax (CMS) [RFC5652] for EnvelopedData syntax. Using the EncryptedKey data structure offers the choice to either use EncryptedValue (for backward compatibility only) or EnvelopedData. The use of the EncryptedValue structure has been deprecated in favor of the EnvelopedData structure. Therefore, it is RECOMMENDED to use EnvelopedData.
EnvelopedData Syntaxについては、証明書要求メッセージフォーマット（CRMF）[RFC4211]を参照してください。暗号化されたKeyデータ構造を使用すると、暗号化されたValue（後方互換のみ）またはEnvelopedDataを使用する選択を提供します。暗号化されたバリュー構造の使用は、封筒構造を支持して非推奨されています。したがって、EnvelopedDataを使用することをお勧めします。
Note: The EncryptedKey structure defined in CRMF [RFC4211] is used here, which makes the update backward compatible. Using the new syntax with the untagged default choice EncryptedValue is bits-on-the-wire compatible with the old syntax.
注：CRMF [RFC4211]で定義されている暗号化されたキー構造はここで使用されているため、更新を後方に互換性のあるものにします。Untagged Default Choice EncryptedValueを使用して新しい構文を使用すると、古い構文と互換性があります。
To indicate support for EnvelopedData, the pvno cmp2021 has been introduced. Details on the usage of the protocol version number are described in Section 7.
EnvelopedDataのサポートを示すために、PVNO CMP2021が導入されました。プロトコルバージョン番号の使用に関する詳細については、セクション7で説明します。
The EnvelopedData structure is RECOMMENDED to be used in CMP to transport a private key, certificate, POP challenge, or revocation passphrase in encrypted form as follows:
EnvelopedData構造は、CMPで使用して、次のように暗号化された形式で秘密鍵、証明書、ポップチャレンジ、または取り消しパスフレーズを輸送することをお勧めします。
* It contains only one RecipientInfo structure because the content is encrypted only for one recipient.
* コンテンツは1人の受信者に対してのみ暗号化されているため、1つのRecipientIntInfo構造が含まれています。
* It may contain a private key in the AsymmetricKeyPackage structure (which is placed in the encryptedContentInfo field), as defined in [RFC5958], that is wrapped in a SignedData structure, as specified in Section 5 of [RFC5652] and [RFC8933], signed by the KGA or CA.
* [RFC5958]で定義されているように、[RFC5652]および[RFC8933のセクション5で指定されているように、SignedData構造に包まれているように、非対称Keypackage構造（暗号化されたContentInfoフィールドに配置されている）の秘密鍵が含まれている場合があります。
* It may contain a certificate, POP challenge, or revocation passphrase directly in the encryptedContent field.
* 暗号化されたコンテンツフィールドに直接、証明書、ポップチャレンジ、または取り消しパスフレーズが含まれる場合があります。
The content of the EnvelopedData structure, as specified in Section 6 of [RFC5652], MUST be encrypted using a newly generated symmetric content-encryption key. This content-encryption key MUST be securely provided to the recipient using one of four key management techniques.
[RFC5652]のセクション6で指定されているように、封筒構造の内容は、新しく生成された対称コンテンツ暗号化キーを使用して暗号化する必要があります。このコンテンツ暗号化キーは、4つの主要な管理手法のいずれかを使用して、受信者に安全に提供する必要があります。
The choice of the key management technique to be used by the sender depends on the credential available at the recipient:
送信者が使用する重要な管理手法の選択は、受信者で利用可能な資格情報によって異なります。
* recipient's certificate with an algorithm identifier and a public key that supports key transport and where any given key usage extension allows keyEncipherment: The content-encryption key will be protected using the key transport key management technique, as specified in Section 6.2.1 of [RFC5652].
* アルゴリズムの識別子とキー輸送をサポートするアルゴリズムの証明書と、特定のキー使用拡張により、キーエンファイメントが許可される場合の公開キー：[RFC5652]のセクション6.2.1で指定されているキートランスポートキー管理手法を使用して、コンテンツ - 暗号化キーは保護されます。
* recipient's certificate with an algorithm identifier and a public key that supports key agreement and where any given key usage extension allows keyAgreement: The content-encryption key will be protected using the key agreement key management technique, as specified in Section 6.2.2 of [RFC5652].
* アルゴリズムの識別子とキー契約をサポートするアルゴリズムの証明書と、特定のキーの使用拡張によりキーアグメントが許可される公開キー：[RFC5652]のセクション6.2.2で指定されているキー契約キー管理手法を使用して、コンテンツ暗号化キーは保護されます。
* a password or shared secret: The content-encryption key will be protected using the password-based key management technique, as specified in Section 6.2.4 of [RFC5652].
* パスワードまたは共有秘密：[RFC5652]のセクション6.2.4で指定されているように、パスワードベースのキー管理手法を使用して、コンテンツ暗号化キーは保護されます。
* recipient's certificate with an algorithm identifier and a public key that supports KEM and where any given key usage extension allows keyEncipherment: The content-encryption key will be protected using the key management technique for KEM keys, as specified in [RFC9629].
* [RFC9629]で指定されているように、KEMのキー管理手法を使用して、Algorithm IdentifierとKEMをサポートし、特定のキー使用拡張機能をサポートする公開キーを使用したレシピエントの証明書と、特定のキーの使用拡張機能が可能な場合、コンテンツ - 結晶化キーは保護されます。
Note: There are cases where the algorithm identifier, the type of the public key, and the key usage extension will not be sufficient to decide on the key management technique to use, e.g., when rsaEncryption is the algorithm identifier. In such cases, it is a matter of local policy to decide.
注：アルゴリズム識別子、公開キーのタイプ、およびキーの使用法拡張機能が、たとえば、rsaencryptionがアルゴリズム識別子である場合に使用するキー管理手法を決定するのに十分ではない場合があります。そのような場合、決定するのは現地の方針の問題です。
All response messages will include some status information. The following values are defined.
すべての応答メッセージには、いくつかのステータス情報が含まれます。次の値が定義されています。
PKIStatus ::= INTEGER {
accepted (0),
grantedWithMods (1),
rejection (2),
waiting (3),
revocationWarning (4),
revocationNotification (5),
keyUpdateWarning (6)
}
Responders may use the following syntax to provide more information about failure cases.
レスポンダーは、次の構文を使用して、故障ケースに関する詳細情報を提供する場合があります。
PKIFailureInfo ::= BIT STRING {
badAlg (0),
badMessageCheck (1),
badRequest (2),
badTime (3),
badCertId (4),
badDataFormat (5),
wrongAuthority (6),
incorrectData (7),
missingTimeStamp (8),
badPOP (9),
certRevoked (10),
certConfirmed (11),
wrongIntegrity (12),
badRecipientNonce (13),
timeNotAvailable (14),
unacceptedPolicy (15),
unacceptedExtension (16),
addInfoNotAvailable (17),
badSenderNonce (18),
badCertTemplate (19),
signerNotTrusted (20),
transactionIdInUse (21),
unsupportedVersion (22),
notAuthorized (23),
systemUnavail (24),
systemFailure (25),
duplicateCertReq (26)
}
PKIStatusInfo ::= SEQUENCE {
status PKIStatus,
statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL
}
In order to identify particular certificates, the CertId data structure is used.
特定の証明書を特定するために、CertIDデータ構造が使用されます。
See [RFC4211] for CertId syntax.
CertID構文については[RFC4211]を参照してください。
Each root CA that provides a self-signed certificate must be able to publish its current public key via some "out-of-band" means or together with the respective link certificate using an online mechanism. While such mechanisms are beyond the scope of this document, we define data structures that can support such mechanisms.
自己署名証明書を提供する各ルートCAは、オンラインメカニズムを使用して、いくつかの「帯域外」平均を介して、またはそれぞれのリンク証明書を使用して現在の公開キーを公開できる必要があります。このようなメカニズムはこのドキュメントの範囲を超えていますが、そのようなメカニズムをサポートできるデータ構造を定義します。
There are generally two methods available: Either the CA directly publishes its self-signed certificate, or this information is available via the directory (or equivalent) and the CA publishes a hash of this value to allow verification of its integrity before use.
通常、2つの方法があります。CAは、自己署名証明書を直接公開するか、この情報がディレクトリ（または同等）を介して利用可能であり、CAはこの値のハッシュを公開して、使用前にその完全性の検証を可能にします。
Note: As an alternative to out-of-band distribution of root CA public keys, the CA can provide the self-signed certificate together with link certificates, e.g., using RootCaKeyUpdateContent (Section 5.3.19.15).
注：ルートCAパブリックキーのバンド外配布の代替として、CAは、rootcakeyupdatecontent（セクション5.3.19.15）を使用して、リンク証明書と一緒に自己署名証明書をリンク証明書とともに提供できます。
OOBCert ::= Certificate
The fields within this certificate are restricted as follows:
この証明書内のフィールドは、次のように制限されています。
* The certificate MUST be self-signed (i.e., the signature must be verifiable using the SubjectPublicKeyInfo field);
* 証明書は自己署名する必要があります（つまり、署名はsubjectpublickeyinfoフィールドを使用して検証可能でなければなりません）。
* The subject and issuer fields MUST be identical;
* 主題と発行者のフィールドは同一でなければなりません。
* If the subject field contains a "NULL-DN", then both subjectAltNames and issuerAltNames extensions MUST be present and have exactly the same value; and
* サブジェクトフィールドに「null-dn」が含まれている場合、subjectaltnamesとissueraltnames拡張機能の両方が存在し、まったく同じ値を持つ必要があります。そして
* The values of all other extensions must be suitable for a self-signed certificate (e.g., key identifiers for the subject and issuer must be the same).
* 他のすべての拡張機能の値は、自己署名証明書に適している必要があります（たとえば、被験者と発行者のキー識別子は同じでなければなりません）。
OOBCertHash ::= SEQUENCE {
hashAlg [0] AlgorithmIdentifier OPTIONAL,
certId [1] CertId OPTIONAL,
hashVal BIT STRING
}
The intention of the hash value is that anyone who has securely received the hash value (via the out-of-band means) can verify a self-signed certificate for that CA.
ハッシュ値の意図は、（帯域外の手段を介して）ハッシュ値を安全に受け取った人なら誰でも、そのCAの自己署名証明書を検証できることです。
Requesters may indicate that they wish the PKI to archive a private key value using the PKIArchiveOptions structure.
要求者は、PKIがPKIarchiveoptions構造を使用して秘密キー値をアーカイブすることを望んでいることを示す場合があります。
See [RFC4211] for PKIArchiveOptions syntax.
pkiarchiveoptions構文については[RFC4211]を参照してください。
Requesters may indicate that they wish the PKI to publish a certificate using the PKIPublicationInfo structure.
要求者は、PKIがPKIPUBLICITIONINFO構造を使用して証明書を公開することを望んでいることを示している場合があります。
See [RFC4211] for PKIPublicationInfo syntax.
pkipublicationinfo構文については[RFC4211]を参照してください。
The POP structure used is indicated in the popo field of type ProofOfPossession in the CertReqMsg sequence (see Section 4 of [RFC4211]).
使用されるPOP構造は、CertreQMSGシーケンスのタイプ証明のPOPOフィールドに示されています（[RFC4211]のセクション4を参照）。
ProofOfPossession ::= CHOICE {
raVerified [0] NULL,
signature [1] POPOSigningKey,
keyEncipherment [2] POPOPrivKey,
keyAgreement [3] POPOPrivKey
}
An end entity MUST NOT use raVerified. If an RA performs changes to a certification request breaking the provided POP, or if the RA requests a certificate on behalf of an end entity and cannot provide the POP itself, the RA MUST use raVerified. Otherwise, it SHOULD NOT use raVerified.
最終エンティティは、raverifiedを使用してはなりません。RAが提供されたPOPを破壊する認定リクエストの変更を実行する場合、またはRAがEnd Entityに代わって証明書を要求し、POP自体を提供できない場合、RAはRaverifiedを使用する必要があります。それ以外の場合は、raverifiedを使用しないでください。
When introducing raVerified, the RA MUST check the existing POP, or it MUST ensure by other means that the end entity is the holder of the private key. The RA MAY provide the original message containing the POP in the generalInfo field using the id-it-origPKIMessage (see Section 5.1.1.3) enabling the CA to verify it.
Raverifiedを導入する場合、RAは既存のPOPをチェックする必要があります。または、他の手段で最終エンティティが秘密鍵の所有者であることを確認する必要があります。RAは、CAがそれを検証できるようにするID-IT-OrigpKimessage（セクション5.1.1.3を参照）を使用して、GeneralInfoフィールドのPOPを含む元のメッセージを提供する場合があります。
If the certification request is for a key pair that supports signing (i.e., a request for a verification certificate), then the POP of the private key is demonstrated through use of the POPOSigningKey structure; for details, see Section 4.1 of [RFC4211].
認定要求が、署名をサポートするキーペア（つまり、検証証明書のリクエスト）の場合、秘密鍵のポップがポポジンキー構造を使用して実証されます。詳細については、[RFC4211]のセクション4.1を参照してください。
POPOSigningKey ::= SEQUENCE {
poposkInput [0] POPOSigningKeyInput OPTIONAL,
algorithmIdentifier AlgorithmIdentifier,
signature BIT STRING
}
POPOSigningKeyInput ::= SEQUENCE {
authInfo CHOICE {
sender [0] GeneralName,
publicKeyMAC PKMACValue
},
publicKey SubjectPublicKeyInfo
}
PKMACValue ::= SEQUENCE {
algId AlgorithmIdentifier,
value BIT STRING
}
Note: For the purposes of this specification, the ASN.1 comment given in Appendix C of [RFC4211] pertains not only to certTemplate but also to the altCertTemplate control, as defined in Section 5.2.1.
注：この仕様の目的のために、[RFC4211]の付録Cに記載されているASN.1コメントは、セクション5.2.1で定義されているように、証明書だけでなくAltCertTemplateコントロールにも関係しています。
If certTemplate (or the altCertTemplate control) contains the subject and publicKey values, then poposkInput MUST be omitted and the signature MUST be computed on the DER-encoded value of the certReq field of the CertReqMsg (or the DER-encoded value of AltCertTemplate). If certTemplate/altCertTemplate does not contain both the subject and public key values (i.e., if it contains only one of these or neither), then poposkInput MUST be present and the signature MUST be computed on the DER-encoded value of poposkInput (i.e., the "value" OCTETs of the POPOSigningKeyInput DER).
certtemplate（またはaltcerttemplateコントロール）にサブジェクト値とpublicKey値が含まれている場合、poposkinpupを省略し、署名をcertreqmsgのcertreqフィールドのderエンコード値（またはaltcertttemplateのderエンコード値）で計算する必要があります。certtemplate/altcertTemplateに、サブジェクトと公開の両方の値（つまり、これらの1つのみが含まれている場合、またはどちらも含まれていない場合）の両方が含まれていない場合、ポポスキンが存在する必要があり、署名はポポスキンプットのderエンコード値（すなわち、ポポスキーインプットderの「値」オクターセット）に計算する必要があります。
In the special case that the CA/RA has a DH certificate that is known to the end entity and the certification request is for a key agreement key pair, the end entity can also use the POPOSigningKey structure (where the algorithmIdentifier field is DHBasedMAC and the signature field is the MAC) for demonstrating POP.
CA/RAが最終エンティティで知られているDH証明書を持っており、認証要求はキー契約のキーペアに対して既知のDH証明書を持っているという特別なケースでは、End EntityはPopoSigingKey構造（AlgorithmididentifierフィールドがDHBasedMacであり、署名フィールドはMACです）を使用することもできます。
If the certification request is for a key pair that does not support signing (i.e., a request for an encryption or key agreement certificate), then the POP of the private key is demonstrated through use of the POPOPrivKey structure in one of the following three ways; for details see Sections 4.2 and 4.3 in [RFC4211].
認定リクエストが、署名をサポートしないキーペア（つまり、暗号化またはキー契約証明書のリクエスト）の場合、秘密鍵のPOPは、次の3つの方法のいずれかでPopOprivkey構造を使用することで実証されます。詳細については、[RFC4211]のセクション4.2および4.3を参照してください。
POPOPrivKey ::= CHOICE {
thisMessage [0] BIT STRING, -- deprecated
subsequentMessage [1] SubsequentMessage,
dhMAC [2] BIT STRING, -- deprecated
agreeMAC [3] PKMACValue,
encryptedKey [4] EnvelopedData
}
SubsequentMessage ::= INTEGER {
encrCert (0),
challengeResp (1)
}
When using agreeMAC or encryptedKey choices, the pvno cmp2021(3) MUST be used. Details on the usage of the protocol version number are described in Section 7.
AmmareMacまたは暗号化された選択の選択を使用する場合、PVNO CMP2021（3）を使用する必要があります。プロトコルバージョン番号の使用に関する詳細については、セクション7で説明します。
This method mentioned previously in Section 4.3 demonstrates POP of the private key by including the encrypted private key in the CertRequest in the POPOPrivKey structure or in the PKIArchiveOptions control structure. This method SHALL only be used if archival of the private key is desired.
セクション4.3で前述したこの方法は、ポポプリフキー構造またはpkiarchiveoptionsコントロール構造のcertrequestに暗号化された秘密鍵を含めることにより、秘密鍵のPOPを示しています。この方法は、秘密鍵のアーカイブが必要な場合にのみ使用されます。
For a certification request message indicating cmp2021(3) in the pvno field of the PKIHeader, the encrypted private key MUST be transferred in the encryptedKey choice of POPOPrivKey (or within the PKIArchiveOptions control) in a CMS EnvelopedData structure, as defined in Section 5.2.2.
PKIHeaderのPVNOフィールドでCMP2021（3）を示す認定要求メッセージの場合、暗号化された秘密鍵は、セクション5.2.2で定義されているCMSエンベロープデタ構造のポポプリブキーの暗号化されたキーの選択肢（またはPKIarchiveoptionsコントロール内）で転送する必要があります。
Note: The thisMessage choice has been deprecated in favor of encryptedKey. When using cmp2000(2) in the certification request message header for backward compatibility, the thisMessage choice of POPOPrivKey is used containing the encrypted private key in an EncryptedValue structure wrapped in a BIT STRING. This allows the necessary conveyance and protection of the private key while maintaining bits-on-the-wire compatibility with [RFC4211].
注：ThisMessageの選択は、暗号化されたKeyを支持して非推奨されています。後方互換性のために認定要求メッセージヘッダーでCMP2000（2）を使用する場合、Popoprivkeyのこのメッサージの選択は、ビット文字列に包まれた暗号化されたバリュー構造に暗号化された秘密鍵を含む使用されます。これにより、[RFC4211]とのワイヤーの互換性を維持しながら、秘密鍵の必要な伝達と保護が可能になります。
The indirect method mentioned previously in Section 4.3 demonstrates POP of the private key by having the CA return the requested certificate in encrypted form (see Section 5.2.2). This method is indicated in the CertRequest by requesting the encrCert option in the subsequentMessage choice of POPOPrivKey.
セクション4.3で前述した間接的な方法は、CAに暗号化されたフォームで要求された証明書を返すことにより、秘密鍵のPOPを示しています（セクション5.2.2を参照）。この方法は、PopOprivkeyの後続のメッサージの選択でENCRCERTオプションを要求することにより、CertRequestに示されています。
end entity RA/CA
---- req ---->
<--- rep (enc cert) -----
---- conf (cert hash) ---->
<--- ack -----
The end entity proves knowledge of the private key to the CA by providing the correct CertHash for this certificate in the certConf message. This demonstrates POP because the end entity can only compute the correct CertHash if it is able to recover the encrypted certificate, and it can only recover the certificate if it is able to obtain the symmetric key using the required private key. Clearly, for this to work, the CA MUST NOT publish the certificate until the certConf message arrives (when certHash is to be used to demonstrate POP). See Section 5.3.18 for further details, and see Section 8.11 for security considerations regarding use of CT logs.
End Entityは、CERTCONFメッセージでこの証明書の正しいCerthashを提供することにより、CAの秘密鍵の知識を証明します。これは、暗号化された証明書を回復できる場合にのみ正しいCerthashを計算できるため、POPを示し、必要な秘密鍵を使用して対称キーを取得できる場合にのみ証明書を回復できるためです。明らかに、これが機能するためには、CAがCERTCONFメッセージが到着するまで証明書を公開してはなりません（CerthashがPOPを実証するために使用する場合）。詳細については、セクション5.3.18を参照してください。CTログの使用に関するセキュリティに関する考慮事項については、セクション8.11を参照してください。
The recipient SHOULD maintain a context of the PKI management operation, e.g., using transactionID and certReqId, to identify the private key to use when decrypting the EnvelopedData containing the newly issued certificate. The recipient may be unable to use the RecipientInfo structure as it refers to the certificate that is still encrypted. The sender MUST populate the rid field as specified by CMS, and the client MAY ignore it.
受信者は、PKI管理操作のコンテキストを維持する必要があります。たとえば、TransactionIDおよびCertreQIDを使用して、新しく発行された証明書を含む封筒を復号化するときに使用する秘密鍵を特定する必要があります。受信者は、まだ暗号化されている証明書を指すため、受信者の構造を使用できない場合があります。送信者は、CMSで指定されているようにRIDフィールドに入力する必要があり、クライアントはそれを無視する場合があります。
The direct method mentioned previously in Section 4.3 demonstrates POP of the private key by having the end entity engage in a challenge-response protocol (using the messages popdecc of type POPODecKeyChall and popdecr of type POPODecKeyResp; see below) between CertReqMessages and CertRepMessage. This method is indicated in the CertRequest by requesting the challengeResp option in the subsequentMessage choice of POPOPrivKey.
セクション4.3で前述した直接的な方法は、最終エンティティにチャレンジ応答プロトコルに従事させることにより、秘密鍵のPOPを示しています（型PopodeckeyChallのメッセージPopDeccと型PopodeckeyRespのPopDecrを使用して、以下を参照）certreqmessagesとcertrepmessageの間。この方法は、PopoPrivkeyの後続のメッサージ選択でChallengerespオプションを要求することにより、Certrequestで示されます。
Note: This method would typically be used in an environment in which an RA verifies POP and then makes a certification request to the CA on behalf of the end entity. In such a scenario, the CA trusts the RA to have done POP correctly before the RA requests a certificate for the end entity.
注：この方法は通常、RAがPOPを検証し、最終エンティティに代わってCAに認証要求を行う環境で使用されます。このようなシナリオでは、CAは、RAが終了エンティティの証明書を要求する前に、RAが正しくポップしたと信頼しています。
The complete protocol then looks as follows (note that req' does not necessarily encapsulate req as a nested message):
完全なプロトコルは次のように見えます（Req 'は必ずしもネストされたメッセージとしてReqをカプセル化するわけではないことに注意してください）：
end entity RA CA
---- req ---->
<--- chall ---
---- resp --->
---- req' --->
<--- rep -----
---- conf --->
<--- ack -----
<--- rep -----
---- conf --->
<--- ack -----
This protocol is obviously much longer than the exchange given in Section 5.2.8.3.2 above but allows a Local Registration Authority (LRA) to be involved and has the property that the certificate itself is not actually created until the POP is complete. In some environments, a different order of the above messages may be required, such as the following (this may be determined by policy):
このプロトコルは明らかに上記のセクション5.2.8.3.2で与えられた交換よりもはるかに長いが、ローカル登録機関（LRA）が関与することを可能にし、POPが完了するまで証明書自体が実際に作成されないというプロパティを持っています。一部の環境では、次のような上記のメッセージの異なる順序が必要になる場合があります（これはポリシーによって決定される場合があります）。
end entity RA CA
---- req ---->
<--- chall ---
---- resp --->
---- req' --->
<--- rep -----
<--- rep -----
---- conf --->
---- conf --->
<--- ack -----
<--- ack -----
The challenge-response messages for POP of a private key are specified as follows (for decryption keys, see [MvOV97], p.404 for details). This challenge-response exchange is associated with the preceding certification request message (and subsequent certification response and confirmation messages) by the transactionID used in the PKIHeader and by the protection applied to the PKIMessage.
秘密キーのPOPの課題応答メッセージは、次のように指定されています（復号化キーについては、[MVOV97]、p.404を参照してください）。この課題反応交換は、PKIHeaderで使用されたTransactionIDおよびPKIMESSAGEに適用される保護によって、前の認定要求メッセージ（およびその後の認証応答と確認メッセージ）に関連付けられています。
POPODecKeyChallContent ::= SEQUENCE OF Challenge
Challenge ::= SEQUENCE {
owf AlgorithmIdentifier OPTIONAL,
witness OCTET STRING,
challenge OCTET STRING, -- deprecated
encryptedRand [0] EnvelopedData OPTIONAL
}
Rand ::= SEQUENCE {
int INTEGER,
sender GeneralName
}
More details on the fields in this syntax are available in Appendix F.
この構文のフィールドの詳細については、付録Fをご覧ください。
For a popdecc message indicating cmp2021(3) in the pvno field of the PKIHeader, the encryption of Rand MUST be transferred in the encryptedRand field in a CMS EnvelopedData structure as defined in Section 5.2.2. The challenge field MUST contain an empty OCTET STRING.
PKIHEADERのPVNOフィールドでCMP2021（3）を示すPOPDECCメッセージの場合、RANDの暗号化は、セクション5.2.2で定義されているCMS封筒構造の暗号化されたフィールドに転送する必要があります。チャレンジフィールドには、空のオクテット文字列が含まれている必要があります。
The recipient SHOULD maintain a context of the PKI management operation, e.g., using transactionID and certReqId, to identify the private key to use when decrypting encryptedRand. The sender MUST populate the rid field in the EnvelopedData sequence using the issuerAndSerialNumber choice containing a NULL-DN as issuer and the certReqId as serialNumber. The client MAY ignore the rid field.
受信者は、PKI管理操作のコンテキストを維持する必要があります。たとえば、TransactionIDおよびCertreQIDを使用して、暗号化された暗号化時に使用する秘密鍵を特定する必要があります。送信者は、発行者としてnull-dnを含む発行者およびcertreqidをserialnumberとして含む発行者およびsserialnumber選択を使用して、封筒のシーケンスでRIDフィールドを埋める必要があります。クライアントは、RIDフィールドを無視する場合があります。
Note: The challenge field has been deprecated in favor of encryptedRand. When using cmp2000(2) in the popdecc message header for backward compatibility, the challenge field MUST contain the encryption (involving the public key for which the certification request is being made) of Rand and encryptedRand MUST be omitted. Using challenge (omitting the optional encryptedRand field) is bit-compatible with [RFC4210]. Note that the size of Rand, when used with challenge, needs to be appropriate for encryption, involving the public key of the requester. If, in some environment, names are so long that they cannot fit (e.g., very long DNs), then whatever portion will fit should be used (as long as it includes at least the common name, and as long as the receiver is able to deal meaningfully with the abbreviation).
注：チャレンジフィールドは、暗号化されたエンサイプドランドを支持して廃止されました。後方互換性のためにPOPDECCメッセージヘッダーでCMP2000（2）を使用する場合、チャレンジフィールドには、RANDおよび暗号化されたエンサイプランドの暗号化（認証要求が行われている公開鍵を含む）を省略する必要があります。[rfc4210]では、[オプションの暗号化]フィールドを除外すること（オプションの暗号化されたフィールドを省略）を使用することができます。RANDのサイズは、チャレンジで使用する場合、要求者の公開鍵を含む暗号化に適している必要があることに注意してください。一部の環境では、名前が非常に長いため、適合できない場合（たとえば、非常に長いDNS）、適合する部分を使用する必要があります（少なくとも共通名が含まれている限り、レシーバーが略語に有意義に対処できる限り）。
POPODecKeyRespContent ::= SEQUENCE OF INTEGER
On receiving the popdecc message, the end entity decrypts all included challenges and responds with a popdecr message containing the decrypted integer values in the same order.
POPDECCメッセージを受信すると、End Entityはすべて課題を復活させ、同じ順序で復号化された整数値を含むPOPDECRメッセージで応答します。
The text in this section provides several options with respect to POP techniques. Using "SK" for "signing key", "EK" for "encryption key", "KAK" for "key agreement key", and "KEMK" for "key encapsulation mechanism key", the techniques may be summarized as follows:
このセクションのテキストは、ポップテクニックに関するいくつかのオプションを提供します。「キーに署名する」に「SK」、「暗号化キー」の「EK」、「キー契約キー」の「KAK」、および「キーカプセル化メカニズムキー」の「KEMK」を使用すると、テクニックは次のように要約できます。
RAVerified;
raverified;
SKPOP;
skpop;
EKPOPThisMessage; -- deprecated
ekpopthismessage;- 非推奨
KAKPOPThisMessage; -- deprecated
kakpopthismessage;- 非推奨
EKPOPEncryptedKey;
ekpopencryptedKey;
KAKPOPEncryptedKey;
kakpopencryptedkey;
KEMKPOPEncryptedKey;
kemkpopencryptedkey;
KAKPOPThisMessageDHMAC;
kakpopthismessagedhmac;
EKPOPEncryptedCert;
ekpopencryptedcert;
KAKPOPEncryptedCert;
kakpopencryptedcert;
KEMKPOPEncryptedCert;
kemkpopencryptedcert;
EKPOPChallengeResp;
ekpopchallengeresp;
KAKPOPChallengeResp; and
Kakpopchallengeresp;そして
KEMKPOPChallengeResp.
kemkpopchallengeresp。
Given this array of options, it is natural to ask how an end entity can know what is supported by the CA/RA (i.e., which options it may use when requesting certificates). The following guidelines should clarify this situation for end entity implementers.
この一連のオプションを考えると、最終エンティティがCA/RAによってサポートされているものをどのように知ることができるかを尋ねるのは自然です（つまり、証明書を要求するときに使用するオプション）。次のガイドラインは、エンディティの実装者のこの状況を明確にする必要があります。
* RAVerified: This is not an end entity decision; the RA uses this if and only if it has verified POP before forwarding the request on to the CA, so it is not possible for the end entity to choose this technique.
* raverified：これは最終エンティティの決定ではありません。RAは、リクエストをCAに転送する前にPOPを検証した場合にのみこれを使用しているため、最終エンティティがこの手法を選択することはできません。
* SKPOP: If the end entity has a signing key pair, this is the only POP method specified for use in the request for a corresponding certificate.
* Skpop：End Entityに署名キーペアがある場合、これは対応する証明書の要求で使用するために指定された唯一のPOPメソッドです。
* EKPOPThisMessage (deprecated), KAKPOPThisMessage (deprecated), EKPOPEncryptedKey, KAKPOPEncryptedKey, KEMKPOPEncryptedKey: Whether or not to give up its private key to the CA/RA is an end entity decision. If the end entity decides to reveal its key, then these are the only POP methods available in this specification to achieve this (and the key pair type and protocol version used will determine which of these methods to use). The reason for deprecating EKPOPThisMessage and KAKPOPThisMessage options has been given in Section 5.2.8.3.1.
* ekpopthismessage（削除）、kakpopthismessage（deprecated）、ekpopencryptedkey、kakpopencryptedkey、kemkpopencryptedkey：ca/raの秘密鍵を放棄するかどうかは最終エンティティの決定です。End Entityがそのキーを明らかにすることを決定した場合、これらはこの仕様で使用できる唯一のPOPメソッドです（および使用するキーペアのタイプとプロトコルバージョンは、これらの使用方法のどれを決定します）。ekpopthismessageとKakpopthissageのオプションを非難する理由は、セクション5.2.8.3.1に記載されています。
* KAKPOPThisMessageDHMAC: The end entity can only use this method if (1) the CA/RA has a DH certificate available for this purpose and (2) the end entity already has a copy of this certificate. If both these conditions hold, then this technique is clearly supported and may be used by the end entity, if desired.
* kakpopthismessagedhmac：最終エンティティは、（1）CA/RAにこの目的で利用可能なDH証明書がある場合にのみこの方法を使用できます。これらの両方の条件が保持されている場合、この手法は明確にサポートされており、必要に応じて最終エンティティで使用される場合があります。
* EKPOPEncryptedCert, KAKPOPEncryptedCert, KEMKPOPEncryptedCert, EKPOPChallengeResp, KAKPOPChallengeResp, and KEMKPOPChallengeResp: The end entity picks one of these (in the subsequentMessage field) in the request message, depending upon preference and key pair type. The end entity is not doing POP at this point; it is simply indicating which method it wants to use. Therefore, if the CA/RA replies with a "badPOP" error, the end entity can re-request using the other POP method chosen in subsequentMessage. Note, however, that this specification encourages the use of the EncryptedCert choice and, furthermore, says that the challenge-response would typically be used when an RA is involved and doing POP verification. Thus, the end entity should be able to make an intelligent decision regarding which of these POP methods to choose in the request message.
* ekpopencryptedcert、kakpopencryptedcert、kemkpopencryptedcert、ekpopchallengeresp、kakpopchallengeresp、およびkemkpopchallengeresp：kemkpopchallengeresp：エンディティは、リクエストメッセージとキーペアのタイプに応じて、リクエストメッセージにおいてこれらの1つ（後続のメッシャーフィールド）を選択します。最終エンティティはこの時点でポップを行っていません。使用したい方法を単に示しているだけです。したがって、CA/RAが「バッドポップ」エラーで応答する場合、End Entityは、後続のメッセージで選択された他のPOPメソッドを使用して再リケストできます。ただし、この仕様は暗号化された選択の選択の使用を促進し、さらに、RAが関与してポップ検証を行うときにチャレンジ応答が使用されると述べていることに注意してください。したがって、最終エンティティは、リクエストメッセージでこれらのポップメソッドのどれを選択するかについて、インテリジェントな決定を下すことができるはずです。
GeneralizedTime is a standard ASN.1 type and SHALL be used as specified in Section 4.1.2.5.2 of [RFC5280].
GeneralizedTimeは標準のASN.1タイプであり、[RFC5280]のセクション4.1.2.5.2で指定されているように使用するものとします。
An Initialization request message contains as the PKIBody a CertReqMessages data structure, which specifies the requested certificate(s). Typically, SubjectPublicKeyInfo, KeyId, and Validity are the template fields that may be supplied for each certificate requested (see the profiles defined in Section 4.1.1 of [RFC9483] and Appendices C.4 and D.7 for further information). This message is intended to be used for entities when first initializing into the PKI.
初期化要求メッセージには、pkibodyとしてCertreqMessagesデータ構造として含まれています。これは、要求された証明書を指定します。通常、subjectpublickeyinfo、keyID、および有効性は、要求された各証明書に対して提供される可能性のあるテンプレートフィールドです（詳細については、[RFC9483]のセクション4.1.1および付録C.4およびD.7で定義されているプロファイルを参照）。このメッセージは、最初にPKIに初期化するときにエンティティに使用することを目的としています。
See Section 5.2.1 and [RFC4211] for CertReqMessages syntax.
CertreqMessagesの構文については、セクション5.2.1および[RFC4211]を参照してください。
An Initialization response message contains as the PKIBody a CertRepMessage data structure, which has for each certificate requested a PKIStatusInfo field, a subject certificate, and possibly a private key (normally encrypted using EnvelopedData; see Section 4.1.6 of [RFC9483] for further information).
初期化応答メッセージには、pkibodyとしてCertrepmessageデータ構造として含まれています。各証明書には、pkistatusinfoフィールド、サブジェクト証明書、および場合によっては秘密鍵（通常は封筒を使用して暗号化されています。詳細については[RFC9483]のセクション4.1.6を参照）が含まれています。
See Section 5.3.4 for CertRepMessage syntax. Note that if the PKI message protection is "shared secret information" (see Section 5.1.3.1), then any certificate transported in the caPubs field may be directly trusted as a root CA certificate by the initiator.
CertrePmessageの構文については、セクション5.3.4を参照してください。PKIメッセージ保護が「共有秘密情報」である場合（セクション5.1.3.1を参照）、Capubsフィールドで輸送される証明書は、イニシエーターによってルートCA証明書として直接信頼される場合があることに注意してください。
A Certification request message contains as the PKIBody a CertReqMessages data structure, which specifies the requested certificates (see the profiles defined in Section 4.1.2 of [RFC9483] and Appendix C.2 for further information). This message is intended to be used for existing PKI entities who wish to obtain additional certificates.
認定要求メッセージには、PKIBODY A CertreQMessagesデータ構造として含まれています。これは、要求された証明書を指定します（詳細については、[RFC9483]のセクション4.1.2で定義されているプロファイルを参照）。このメッセージは、追加の証明書を取得したい既存のPKIエンティティに使用することを目的としています。
See Section 5.2.1 and [RFC4211] for CertReqMessages syntax.
CertreqMessagesの構文については、セクション5.2.1および[RFC4211]を参照してください。
Alternatively, the PKIBody MAY be a CertificationRequest (this structure is fully specified by the ASN.1 structure CertificationRequest given in [RFC2986]; see the profiles defined in Section 4.1.4 of [RFC9483] for further information). This structure may be required for certificate requests for signing key pairs when interoperation with legacy systems is desired, but its use is strongly discouraged whenever not absolutely necessary.
あるいは、PKIBODYは認証リケストである可能性があります（この構造は、[RFC2986]に与えられたASN.1構造認証再クエストによって完全に指定されています。詳細については、[RFC9483]のセクション4.1.4で定義されているプロファイルを参照してください）。この構造は、レガシーシステムとの相互操作が望まれている場合、キーペアに署名するための証明書リクエストに必要な場合がありますが、その使用は絶対に必要ではない場合は強く落胆します。
A Certification response message contains as the PKIBody a CertRepMessage data structure, which has a status value for each certificate requested and optionally has a CA public key, failure information, a subject certificate, and an encrypted private key.
認証応答メッセージには、PKIBODYとしてCertrePmessageデータ構造が含まれています。これには、各証明書のステータス値が要求され、オプションでCAの公開キー、障害情報、件名証明書、暗号化された秘密鍵が含まれています。
CertRepMessage ::= SEQUENCE {
caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate
OPTIONAL,
response SEQUENCE OF CertResponse
}
CertResponse ::= SEQUENCE {
certReqId INTEGER,
status PKIStatusInfo,
certifiedKeyPair CertifiedKeyPair OPTIONAL,
rspInfo OCTET STRING OPTIONAL
-- analogous to the id-regInfo-utf8Pairs string defined
-- for regInfo in CertReqMsg [RFC4211]
}
CertifiedKeyPair ::= SEQUENCE {
certOrEncCert CertOrEncCert,
privateKey [0] EncryptedKey OPTIONAL,
-- See [RFC4211] for comments on encoding.
publicationInfo [1] PKIPublicationInfo OPTIONAL
}
CertOrEncCert ::= CHOICE {
certificate [0] CMPCertificate,
encryptedCert [1] EncryptedKey
}
A p10cr message contains exactly one CertificationRequestInfo data structure, as specified in PKCS #10 [RFC2986], but no certReqId. Therefore, the certReqId in the corresponding Certification Response (cp) message MUST be set to -1.
P10CRメッセージには、PKCS＃10 [RFC2986]で指定されているように、Certreqidはありませんが、Certreqidは1つあります。したがって、対応する認証応答（CP）メッセージのCertreQIDは-1に設定する必要があります。
Only one of the failInfo (in PKIStatusInfo) and certificate (in CertifiedKeyPair) fields can be present in each CertResponse (depending on the status). For some status values (e.g., waiting), neither of the optional fields will be present.
FailInfo（pkistatusinfoで）と証明書（認定Keypair）の1つのみが、各Certresponse（ステータスに応じて）に存在する可能性があります。一部のステータス値（待機）の場合、オプションのフィールドはどちらも存在しません。
Given an EncryptedCert and the relevant decryption key, the certificate may be obtained. The purpose of this is to allow a CA to return the value of a certificate but with the constraint that only the intended recipient can obtain the actual certificate. The benefit of this approach is that a CA may reply with a certificate even in the absence of proof that the requester is the end entity that can use the relevant private key (note that the proof is not obtained until the certConf message is received by the CA). Thus, the CA will not have to revoke that certificate in the event that something goes wrong with the POP (but MAY do so anyway, depending upon policy).
暗号化された暗号化と関連する復号化キーを考えると、証明書が取得される場合があります。これの目的は、CAが証明書の値を返すことを許可することですが、意図した受信者のみが実際の証明書を取得できるという制約があります。このアプローチの利点は、CAが関連する秘密鍵を使用できる最終エンティティであるという証明がない場合でも証明書に返信できることです（CARがCARTCONFメッセージを受信するまで証明は取得されないことに注意してください）。したがって、CAは、POPに何か問題が発生した場合にその証明書を取り消す必要はありません（ただし、とにかく、ポリシーに応じてそうすることができます）。
The use of EncryptedKey is described in Section 5.2.2.
暗号化されたキーの使用については、セクション5.2.2で説明しています。
Note: To indicate support for EnvelopedData, the pvno cmp2021 has been introduced. Details on the usage of different protocol version numbers are described in Section 7.
注：EnvelopedDataのサポートを示すために、PVNO CMP2021が導入されました。さまざまなプロトコルバージョン番号の使用に関する詳細については、セクション7で説明します。
For key update requests, the CertReqMessages syntax is used. Typically, SubjectPublicKeyInfo, KeyId, and Validity are the template fields that may be supplied for each key to be updated (see the profiles defined in Section 4.1.3 of [RFC9483] and Appendix C.6 for further information). This message is intended to be used to request updates to existing (non-revoked and non-expired) certificates (therefore, it is sometimes referred to as a "Certificate Update" operation). An update is a replacement certificate containing either a new subject public key or the current subject public key (although the latter practice may not be appropriate for some environments).
キーアップデートリクエストには、CertreQMessages構文が使用されます。通常、subjectpublickeyinfo、keyID、および有効性は、更新する各キーに提供されるテンプレートフィールドです（詳細については[RFC9483]のセクション4.1.3および付録C.6で定義されているプロファイルを参照）。このメッセージは、既存の（非回転および非走行されていない）証明書の更新をリクエストするために使用することを目的としています（したがって、「証明書更新」操作と呼ばれることもあります）。更新は、新しい件名の公開キーまたは現在の件名の公開キーのいずれかを含む交換証明書です（ただし、後者のプラクティスは環境には適切ではない場合があります）。
See Section 5.2.1 and [RFC4211] for CertReqMessages syntax.
CertreqMessagesの構文については、セクション5.2.1および[RFC4211]を参照してください。
For key update responses, the CertRepMessage syntax is used. The response is identical to the initialization response.
主要な更新応答には、certrepmessage構文が使用されます。応答は、初期化応答と同じです。
See Section 5.3.4 for CertRepMessage syntax.
CertrePmessageの構文については、セクション5.3.4を参照してください。
For key recovery requests, the syntax used is identical to the initialization request CertReqMessages. Typically, SubjectPublicKeyInfo and KeyId are the template fields that may be used to supply a signature public key for which a certificate is required.
キーリカバリリクエストの場合、使用される構文は初期化リクエストCertreQMessagesと同じです。通常、subjectpublickeyinfoとkeyIDは、証明書が必要な署名公開鍵を提供するために使用できるテンプレートフィールドです。
See Section 5.2.1 and [RFC4211] for CertReqMessages syntax. Note that if a key history is required, the requester must supply a protocol encryption key control in the request message.
CertreqMessagesの構文については、セクション5.2.1および[RFC4211]を参照してください。重要な履歴が必要な場合、要求者はリクエストメッセージにプロトコル暗号化キーコントロールを提供する必要があることに注意してください。
For key recovery responses, the following syntax is used. For some status values (e.g., waiting), none of the optional fields will be present.
主要な回復応答には、次の構文が使用されます。一部のステータス値（待機）の場合、オプションのフィールドは存在しません。
KeyRecRepContent ::= SEQUENCE {
status PKIStatusInfo,
newSigCert [0] Certificate OPTIONAL,
caCerts [1] SEQUENCE SIZE (1..MAX) OF
Certificate OPTIONAL,
keyPairHist [2] SEQUENCE SIZE (1..MAX) OF
CertifiedKeyPair OPTIONAL
}
When requesting revocation of a certificate (or several certificates), the following data structure is used (see the profiles defined in Section 4.2 of [RFC9483] for further information). The name of the requester is present in the PKIHeader structure.
証明書（または複数の証明書）の取り消しを要求する場合、次のデータ構造が使用されます（詳細については、[RFC9483]のセクション4.2で定義されているプロファイルを参照）。要求者の名前は、pkiheader構造に存在します。
RevReqContent ::= SEQUENCE OF RevDetails
RevDetails ::= SEQUENCE {
certDetails CertTemplate,
crlEntryDetails Extensions OPTIONAL
}
The revocation response is the response to the above message. If produced, this is sent to the requester of the revocation. (A separate revocation announcement message MAY be sent to the subject of the certificate for which revocation was requested.)
取り消し応答は、上記のメッセージに対する応答です。作成された場合、これは取り消しの要求者に送信されます。（失効が要求された証明書の主題に送信される可能性があります。）
RevRepContent ::= SEQUENCE {
status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo,
revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL,
crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList
OPTIONAL
}
Cross-certification requests use the same syntax (CertReqMessages) as normal certification requests, with the restriction that the key pair MUST have been generated by the requesting CA and the private key MUST NOT be sent to the responding CA (see the profiles defined in Appendix D.6 for further information). This request MAY also be used by subordinate CAs to get their certificates signed by the parent CA.
相互認証要求は、通常の認証要求と同じ構文（certreqmessages）を使用します。キーペアが要求CAによって生成された必要があるという制限は、応答CAに送信されてはなりません（詳細については、付録D.6で定義されているプロファイルを参照）。このリクエストは、親CAが署名した証明書を取得するために、下位CASによっても使用される場合があります。
See Section 5.2.1 and [RFC4211] for CertReqMessages syntax.
CertreqMessagesの構文については、セクション5.2.1および[RFC4211]を参照してください。
Cross-certification responses use the same syntax (CertRepMessage) as normal certification responses, with the restriction that no encrypted private key can be sent.
相互認証応答は、通常の認証応答と同じ構文（certrepmessage）を使用します。暗号化された秘密鍵を送信できないという制限があります。
See Section 5.3.4 for CertRepMessage syntax.
CertrePmessageの構文については、セクション5.3.4を参照してください。
When a CA updates its own key pair, the following data structure MAY be used to announce this event.
CAが独自の重要なペアを更新すると、次のデータ構造を使用してこのイベントを発表できます。
RootCaKeyUpdateContent ::= SEQUENCE {
newWithNew CMPCertificate,
newWithOld [0] CMPCertificate OPTIONAL,
oldWithNew [1] CMPCertificate OPTIONAL
}
CAKeyUpdContent ::= CHOICE {
cAKeyUpdAnnV2 CAKeyUpdAnnContent, -- deprecated
cAKeyUpdAnnV3 [0] RootCaKeyUpdateContent
}
When using RootCaKeyUpdateContent in the ckuann message, the pvno cmp2021 MUST be used. Details on the usage of the protocol version number are described in Section 7.
ckuannメッセージでrootcakeyupdatecontentを使用する場合、PVNO CMP2021を使用する必要があります。プロトコルバージョン番号の使用に関する詳細については、セクション7で説明します。
In contrast to CAKeyUpdAnnContent as supported with cmp2000, RootCaKeyUpdateContent offers omitting newWithOld and oldWithNew, depending on the needs of the end entity.
CMP2000でサポートされているCakeYupDannContentとは対照的に、RootCakeyUpDateContentは、最終エンティティのニーズに応じて、NewWitholdとOldwithNewを省略しています。
This structure MAY be used to announce the existence of certificates.
この構造は、証明書の存在を発表するために使用できます。
Note that this message is intended to be used for those cases (if any) where there is no pre-existing method for publication of certificates; it is not intended to be used where, for example, X.500 is the method for publication of certificates.
このメッセージは、証明書の公開のための既存の方法がない場合（もしあれば）（ある場合）に使用することを目的としていることに注意してください。たとえば、X.500が証明書の公開方法である場合、使用することを意図していません。
CertAnnContent ::= Certificate
When a CA has revoked, or is about to revoke, a particular certificate, it MAY issue an announcement of this (possibly upcoming) event.
CAが特定の証明書を取り消した、または取り消そうとしている場合、この（おそらく今後の）イベントの発表を発行する可能性があります。
RevAnnContent ::= SEQUENCE {
status PKIStatus,
certId CertId,
willBeRevokedAt GeneralizedTime,
badSinceDate GeneralizedTime,
crlDetails Extensions OPTIONAL
}
A CA MAY use such an announcement to warn (or notify) a subject that its certificate is about to be (or has been) revoked. This would typically be used where the request for revocation did not come from the subject concerned.
CAは、そのような発表を使用して、その証明書が取り消されようとしている（または取り消された）主題に警告する（または通知）することができます。これは通常、取り消しの要求が関係する主題から得られなかった場合に使用されます。
The willBeRevokedAt field contains the time at which a new entry will be added to the relevant CRLs.
Willberevokedatフィールドには、関連するCRLに新しいエントリが追加される時間が含まれています。
When a CA issues a new CRL (or set of CRLs), the following data structure MAY be used to announce this event.
CAが新しいCRL（またはCRLのセット）を発行すると、次のデータ構造を使用してこのイベントを発表できます。
CRLAnnContent ::= SEQUENCE OF CertificateList
This data structure is used in the protocol exchange as the final PKIMessage. Its content is the same in all cases -- actually, there is no content since the PKIHeader carries all the required information.
このデータ構造は、プロトコル交換で最終的なpkimessageとして使用されます。そのコンテンツはすべての場合に同じです。実際、PKIHeaderには必要なすべての情報が含まれているため、コンテンツはありません。
PKIConfirmContent ::= NULL
Use of this message for certificate confirmation is NOT RECOMMENDED; certConf SHOULD be used instead. Upon receiving a pkiconf for a certificate response, the recipient MAY treat it as a certConf with all certificates being accepted.
証明書確認のためにこのメッセージを使用することは推奨されません。代わりにCERTCONFを使用する必要があります。証明書の応答のためにPKICONFを受け取ると、受信者はそれをすべての証明書が受け入れられ、それを証明書作成者として扱うことができます。
This data structure is used by the client to send a confirmation to the CA/RA to accept or reject certificates.
このデータ構造は、クライアントがCA/RAに確認を送信して証明書を受け入れるか拒否するために使用されます。
CertConfirmContent ::= SEQUENCE OF CertStatus
CertStatus ::= SEQUENCE {
certHash OCTET STRING,
certReqId INTEGER,
statusInfo PKIStatusInfo OPTIONAL,
hashAlg [0] AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}
OPTIONAL
}
The hashAlg field SHOULD be used only in exceptional cases where the signatureAlgorithm of the certificate to be confirmed does not specify a hash algorithm in the OID or in the parameters or no hash algorithm is specified for hashing certificates signed using the signatureAlgorithm. Note that for EdDSA, a hash algorithm is specified in Section 3.3 of [RFC9481], such that the hashAlg field is not needed for EdDSA. Otherwise, the certHash value SHALL be computed using the same hash algorithm as used to create and verify the certificate signature or as specified for hashing certificates signed using the signatureAlgorithm. If hashAlg is used, the CMP version indicated by the certConf message header must be cmp2021(3).
Hashalgフィールドは、確認される証明書のSignaturealGorithmがOIDまたはパラメーターまたはHashアルゴリズムなしでHashアルゴリズムを指定しない例外的な場合にのみ使用する必要があります。EDDSAの場合、Hashアルゴリズムが[RFC9481]のセクション3.3で指定されているため、HashalgフィールドはEDDSAに必要ではないことに注意してください。それ以外の場合、Certhash値は、証明書の署名の作成と検証に使用されるのと同じハッシュアルゴリズムを使用して、またはSignatureAlgorithmを使用して署名されたハッシュ証明書に指定されている場合に計算するものとします。Hashalgを使用する場合、CERTCONFメッセージヘッダーで示されるCMPバージョンはCMP2021（3）でなければなりません。
For any particular CertStatus, omission of the statusInfo field indicates acceptance of the specified certificate. Alternatively, explicit status details (with respect to acceptance or rejection) MAY be provided in the statusInfo field, perhaps for auditing purposes at the CA/RA.
特定の証明書については、StatusInfoフィールドの省略は、指定された証明書の受け入れを示します。あるいは、おそらくCA/RAでの監査目的で、StatusInfoフィールドで明示的なステータスの詳細を（受け入れまたは拒否に関して）提供することができます。
Within CertConfirmContent, omission of a CertStatus structure corresponding to a certificate supplied in the previous response message indicates rejection of the certificate. Thus, an empty CertConfirmContent (a zero-length SEQUENCE) MAY be used to indicate rejection of all supplied certificates. See Section 5.2.8.3.2 for a discussion of the certHash field with respect to POP.
CertConfirmContentでは、以前の応答メッセージで提供された証明書に対応する証明書構造の省略は、証明書の拒否を示しています。したがって、空のcertconfirmcontent（ゼロ長のシーケンス）を使用して、すべての供給された証明書の拒否を示すことができます。POPに関するCerthashフィールドの議論については、セクション5.2.8.3.2を参照してください。
InfoTypeAndValue ::= SEQUENCE {
infoType OBJECT IDENTIFIER,
infoValue ANY DEFINED BY infoType OPTIONAL
}
-- where {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4}
GenMsgContent ::= SEQUENCE OF InfoTypeAndValue
This MAY be used by the end entity to get a certificate from the CA to use to protect sensitive information during the protocol.
これは、プロトコル中に機密情報を保護するために使用するためにCAから証明書を取得するために最終エンティティによって使用される場合があります。
GenMsg: {id-it 1}, < absent >
GenRep: {id-it 1}, Certificate | < absent >
End entities MUST ensure that the correct certificate is used for this purpose.
エンティティは、この目的のために正しい証明書が使用されることを確認する必要があります。
This MAY be used by the end entity to get the list of signature algorithms whose subject public key values the CA is willing to certify.
これは、CAがCAが認証する意思があると主張する署名アルゴリズムのリストを取得するために、End Entityによって使用される場合があります。
GenMsg: {id-it 2}, < absent >
GenRep: {id-it 2}, SEQUENCE SIZE (1..MAX) OF
AlgorithmIdentifier
Note: For the purposes of this exchange, rsaEncryption and sha256WithRSAEncryption, for example, are considered to be equivalent; the question being asked is, "Is the CA willing to certify an RSA public key?"
注：この交換の目的のために、たとえば、rsaEcnecryptionとsha256 -withrsaencryptionは同等であると見なされます。尋ねられる質問は、「CAはRSAの公開鍵を認定することをいとわないのですか？」です。
Note: In case several elliptic curves are supported, several id-ecPublicKey elements as defined in [RFC5480] need to be given, one per named curve.
注：いくつかの楕円曲線がサポートされている場合、[RFC5480]で定義されているいくつかのID-EcpublicKey要素を指定された曲線ごとに与えられる必要があります。
This MAY be used by the client to get the list of encryption / key agreement algorithms whose subject public key values the CA is willing to certify.
これは、CAがCAが認定する意思があると主題と評価する暗号化 /キー契約アルゴリズムのリストを取得するためにクライアントが使用することができます。
GenMsg: {id-it 3}, < absent >
GenRep: {id-it 3}, SEQUENCE SIZE (1..MAX) OF
AlgorithmIdentifier
Note: In case several elliptic curves are supported, several id-ecPublicKey elements as defined in [RFC5480] need to be given, one per named curve.
注：いくつかの楕円曲線がサポートされている場合、[RFC5480]で定義されているいくつかのID-EcpublicKey要素を指定された曲線ごとに与えられる必要があります。
This MAY be used by the client to get the CA-preferred symmetric encryption algorithm for any confidential information that needs to be exchanged between the end entity and the CA (for example, if the end entity wants to send its private decryption key to the CA for archival purposes).
これは、クライアントが使用して、最終エンティティとCAの間で交換する必要がある機密情報に対してCA優先対称暗号化アルゴリズムを取得することができます（たとえば、最終エンティティがアーカイブの目的でCAにプライベート復号化キーを送信したい場合）。
GenMsg: {id-it 4}, < absent >
GenRep: {id-it 4}, AlgorithmIdentifier
This MAY be used by the CA to announce a CA key update event.
これは、CAによってCAキーアップデートイベントを発表するために使用できます。
GenMsg: {id-it 18}, RootCaKeyUpdateValue
See Section 5.3.13 for details of CA key update announcements.
CAキーアップデートアナウンスの詳細については、セクション5.3.13を参照してください。
This MAY be used by the client to get a copy of the latest CRL.
これは、クライアントが最新のCRLのコピーを取得するために使用できます。
GenMsg: {id-it 6}, < absent >
GenRep: {id-it 6}, CertificateList
This is used by the server to return a list of object identifiers that it does not recognize or support from the list submitted by the client.
これは、クライアントが提出したリストから認識またはサポートしていないオブジェクト識別子のリストを返すためにサーバーによって使用されます。
GenRep: {id-it 7}, SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER
This MAY be used by the end entity to request the domain parameters to use for generating the key pair for certain public-key algorithms. It can be used, for example, to request the appropriate P, Q, and G to generate the DH/DSA key or to request a set of well-known elliptic curves.
これは、特定のパブリックキーアルゴリズムのキーペアを生成するために使用するドメインパラメーターを要求するために、End Entityによって使用される場合があります。たとえば、適切なp、q、gを要求してDH/DSAキーを生成するか、よく知られている楕円曲線のセットを要求するために使用できます。
GenMsg: {id-it 10}, OBJECT IDENTIFIER -- (Algorithm object-id)
GenRep: {id-it 11}, AlgorithmIdentifier | < absent >
An absent infoValue in the GenRep indicates that the algorithm specified in GenMsg is not supported.
GenRepに存在しない情報値は、GenMSGで指定されたアルゴリズムがサポートされていないことを示しています。
End entities MUST ensure that the parameters are acceptable to it and that the GenRep message is authenticated (to avoid substitution attacks).
最終エンティティは、パラメーターがそれに受け入れられ、GenRepメッセージが認証されていることを確認する必要があります（代替攻撃を避けるため）。
This MAY be used by the end entity to send a passphrase to a CA/RA for the purpose of authenticating a later revocation request (in the case that the appropriate signing private key is no longer available to authenticate the request). See Appendix B for further details on the use of this mechanism.
これは、後の取り消し要求を認証する目的で、パスフレーズをCA/RAに送信するためにEndエンティティによって使用される場合があります（適切な署名秘密キーがリクエストを認証するためにもはや利用できなくなる場合）。このメカニズムの使用に関する詳細については、付録Bを参照してください。
GenMsg: {id-it 12}, EncryptedKey
GenRep: {id-it 12}, < absent >
The use of EncryptedKey is described in Section 5.2.2.
暗号化されたキーの使用については、セクション5.2.2で説明しています。
See Section 5.1.1.1 for the definition and use of {id-it 13}.
{id-it 13}の定義と使用については、セクション5.1.1.1を参照してください。
See Section 5.1.1.2 for the definition and use of {id-it 14}.
{id-it 14}の定義と使用については、セクション5.1.1.2を参照してください。
See Section 5.1.1.3 for the definition and use of {id-it 15}.
{id-it 15}の定義と使用については、セクション5.1.1.3を参照してください。
This MAY be used to determine the appropriate language tag [RFC5646] to use in subsequent messages. The sender sends its list of supported languages (in order of most to least preferred); the receiver returns the one it wishes to use. (Note: Each UTF8String MUST include a language tag.) If none of the offered tags are supported, an error MUST be returned.
これは、後続のメッセージで使用する適切な言語タグ[RFC5646]を決定するために使用できます。送信者は、サポートされている言語のリストを送信します（最大の順に最小限の順に）。レシーバーは、使用したいものを返します。（注：各UTF8STRINGには言語タグを含める必要があります。）提供されたタグがサポートされていない場合、エラーを返す必要があります。
GenMsg: {id-it 16}, SEQUENCE SIZE (1..MAX) OF UTF8String
GenRep: {id-it 16}, SEQUENCE SIZE (1) OF UTF8String
This MAY be used by the client to get CA certificates.
これは、CA証明書を取得するためにクライアントが使用できます。
GenMsg: {id-it 17}, < absent >
GenRep: {id-it 17}, SEQUENCE SIZE (1..MAX) OF
CMPCertificate | < absent >
This MAY be used by the client to get an update of a root CA certificate, which is provided in the body of the request message. In contrast to the ckuann message, this approach follows the request/ response model.
これは、クライアントがリクエストメッセージの本文で提供されるルートCA証明書の更新を取得するために使用できます。ckuannメッセージとは対照的に、このアプローチはリクエスト/応答モデルに従います。
The end entity SHOULD reference its current trust anchor in RootCaCertValue in the request body, giving the root CA certificate if available.
End Entityは、リクエスト本体のrootCaCertValueの現在の信頼アンカーを参照し、利用可能な場合はルートCA証明書を提供する必要があります。
GenMsg: {id-it 20}, RootCaCertValue | < absent >
GenRep: {id-it 18}, RootCaKeyUpdateValue | < absent >
RootCaCertValue ::= CMPCertificate
RootCaKeyUpdateValue ::= RootCaKeyUpdateContent
RootCaKeyUpdateContent ::= SEQUENCE {
newWithNew CMPCertificate,
newWithOld [0] CMPCertificate OPTIONAL,
oldWithNew [1] CMPCertificate OPTIONAL
}
Note: In contrast to CAKeyUpdAnnContent (which was deprecated with pvno cmp2021), RootCaKeyUpdateContent offers omitting newWithOld and oldWithNew, depending on the needs of the end entity.
注：cakeyupdanncontent（PVNO CMP2021で非推奨）とは対照的に、rootcakeyupdateContentは、最終エンティティのニーズに応じて、NewWitholdとOldwithNewを省略します。
This MAY be used by the client to get a template containing requirements for certificate request attributes and extensions. The controls id-regCtrl-algId and id-regCtrl-rsaKeyLen MAY contain details on the types of subject public keys the CA is willing to certify.
これは、クライアントが証明書要求属性と拡張機能の要件を含むテンプレートを取得するために使用できます。CONTROLSS ID-REGCTRL-ALGIDおよびID-REGCTRL-RSAKEYLENには、CAが認定する意思がある対象のパブリックキーの種類に関する詳細が含まれている場合があります。
The id-regCtrl-algId control MAY be used to identify a cryptographic algorithm (see Section 4.1.2.7 of [RFC5280]) other than rsaEncryption. The algorithm field SHALL identify a cryptographic algorithm. The contents of the optional parameters field will vary according to the algorithm identified. For example, when the algorithm is set to id-ecPublicKey, the parameters identify the elliptic curve to be used; see [RFC5480].
ID-regctrl-algidコントロールを使用して、rsaencryption以外の暗号化アルゴリズム（[RFC5280]のセクション4.1.2.7を参照）を識別できます。アルゴリズムフィールドは、暗号化アルゴリズムを特定するものとします。オプションのパラメーターフィールドの内容は、特定されたアルゴリズムによって異なります。たとえば、アルゴリズムがid-ecpublickeyに設定されている場合、パラメーターは使用する楕円曲線を識別します。[RFC5480]を参照してください。
Note: The client may specify a profile name in the certProfile field (see Section 5.1.1.4).
注：クライアントは、CertProfileフィールドにプロファイル名を指定できます（セクション5.1.1.4を参照）。
The id-regCtrl-rsaKeyLen control SHALL be used for algorithm rsaEncryption and SHALL contain the intended modulus bit length of the RSA key.
Id-regctrl-rsakeylenコントロールは、アルゴリズムrsaencryptionに使用され、RSAキーの意図した弾性弾性ビット長を含めるものとします。
GenMsg: {id-it 19}, < absent >
GenRep: {id-it 19}, CertReqTemplateContent | < absent >
CertReqTemplateValue ::= CertReqTemplateContent
CertReqTemplateContent ::= SEQUENCE {
certTemplate CertTemplate,
keySpec Controls OPTIONAL }
Controls ::= SEQUENCE SIZE (1..MAX) OF AttributeTypeAndValue
id-regCtrl-algId OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) pkip(5) regCtrl(1) 11 }
AlgIdCtrl ::= AlgorithmIdentifier{ALGORITHM, {...}}
id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) pkip(5) regCtrl(1) 12 }
RsaKeyLenCtrl ::= INTEGER (1..MAX)
The CertReqTemplateValue contains the prefilled certTemplate to be used for a future certificate request. The publicKey field in the certTemplate MUST NOT be used. In case the PKI management entity wishes to specify supported public-key algorithms, the keySpec field MUST be used. One AttributeTypeAndValue per supported algorithm or RSA key length MUST be used.
certreqTemplateValueには、将来の証明書リクエストに使用される事前に済む証明書が含まれています。CERTTEMPLATE内のPublicKeyフィールドを使用してはなりません。PKI管理エンティティがサポートされているパブリックキーアルゴリズムの指定を希望する場合は、キーセペックフィールドを使用する必要があります。サポートされているアルゴリズムまたはRSAキーの長さごとに1つの属性タイプアンドバリューを使用する必要があります。
Note: The controls for an ASN.1 type are defined in Section 6 of CRMF [RFC4211].
注：ASN.1タイプのコントロールは、CRMF [RFC4211]のセクション6で定義されています。
This MAY be used by the client to get new CRLs, specifying the source of the CRLs and the thisUpdate value of the latest CRL it already has, if available. A CRL source is given either by a DistributionPointName or the GeneralNames of the issuing CA. The DistributionPointName should be treated as an internal pointer to identify a CRL that the server already has and not as a way to ask the server to fetch CRLs from external locations. The server SHALL only provide those CRLs that are more recent than the ones indicated by the client.
これは、クライアントが新しいCRLSを取得するために使用する場合があり、CRLSのソースと、利用可能な場合は既に持っている最新のCRLのThisupDate値を指定できます。CRLソースは、DistributionPointNameまたは発行の一般名のいずれかによって与えられます。DistributionPointNameは、サーバーが既に持っているCRLを識別するための内部ポインターとして扱われ、サーバーに外部の場所からCRLを取得するように依頼する方法としてではありません。サーバーは、クライアントが示すものよりも最近のCRLのみを提供するものとします。
GenMsg: {id-it 22}, SEQUENCE SIZE (1..MAX) OF CRLStatus
GenRep: {id-it 23}, SEQUENCE SIZE (1..MAX) OF
CertificateList | < absent >
CRLSource ::= CHOICE {
dpn [0] DistributionPointName,
issuer [1] GeneralNames }
CRLStatus ::= SEQUENCE {
source CRLSource,
thisUpdate Time OPTIONAL }
This MAY be used by a PKI entity to get the KEM ciphertext for MAC-based message protection using KEM (see Section 5.1.3.4).
これは、KEMを使用したMacベースのメッセージ保護用のKEM Ciphertextを取得するためにPKIエンティティによって使用される場合があります（セクション5.1.3.4を参照）。
The PKI entity that possesses a KEM key pair can request the ciphertext by sending an InfoTypeAndValue structure of type KemCiphertextInfo where the infoValue is absent. The ciphertext can be provided in the following genp message with an InfoTypeAndValue structure of the same type.
KEMキーペアを所有するPKIエンティティは、情報バリューが存在しない場合にkemciphertextinfoのタイプのインフォタイプアンドバリュー構造を送信することにより、ciphertextを要求できます。暗号文は、同じタイプのInfotypeandValue構造を持つ次のGenpメッセージで提供できます。
GenMsg: {id-it 24}, < absent >
GenRep: {id-it 24}, KemCiphertextInfo
KemCiphertextInfo ::= SEQUENCE {
kem AlgorithmIdentifier{KEM-ALGORITHM, {...}},
ct OCTET STRING
}
kem is the algorithm identifier of the KEM algorithm, and any associated parameters, used to generate the ciphertext (ct).
KEMは、kemアルゴリズムのアルゴリズム識別子であり、関連するパラメーターであり、ciphertext（CT）を生成するために使用されます。
ct is the ciphertext output from the KEM Encapsulate function.
CTは、KEM Encapsulate関数からの暗号文の出力です。
Note: These InfoTypeAndValue structures can also be transferred in the generalInfo field of the PKIHeader in messages of other types (see Section 5.1.1.5).
注：これらのInfotypeandValue構造は、他のタイプのメッセージでPKIHeaderのGeneralINFOフィールドでも転送することができます（セクション5.1.1.5を参照）。
GenRepContent ::= SEQUENCE OF InfoTypeAndValue
Examples of GenReps that MAY be supported include those listed in the subsections of Section 5.3.19.
サポートできるGenRepsの例には、セクション5.3.19のサブセクションにリストされている例が含まれます。
This data structure MAY be used by an end entity, CA, or RA to convey error information and by a PKI management entity to initiate delayed delivery of responses.
このデータ構造は、エラー情報を伝えるためにエンドエンティティ、CA、またはRAによって、およびPKI管理エンティティが応答の遅延配信を開始するために使用できます。
ErrorMsgContent ::= SEQUENCE {
pKIStatusInfo PKIStatusInfo,
errorCode INTEGER OPTIONAL,
errorDetails PKIFreeText OPTIONAL
}
This message MAY be generated at any time during a PKI transaction. If the client sends this request, the server MUST respond with a pkiconf response or another error message if any part of the header is not valid.
このメッセージは、PKIトランザクション中にいつでも生成される場合があります。クライアントがこのリクエストを送信した場合、ヘッダーの一部が無効である場合、サーバーはPKICONF応答または別のエラーメッセージで応答する必要があります。
In case a PKI management entity sends an error message to the end entity with the pKIStatusInfo field containing the status "waiting", the end entity SHOULD initiate polling as described in Section 5.3.22. If the end entity does not initiate polling, both sides MUST treat this message as the end of the transaction (if a transaction is in progress).
PKI管理エンティティがステータス「待機」を含むPkistatusInfoフィールドを使用してエラーエンティティにエラーメッセージを送信した場合、最終エンティティはセクション5.3.22で説明されているようにポーリングを開始する必要があります。最終エンティティが投票を開始しない場合、双方はこのメッセージをトランザクションの終わりとして扱う必要があります（トランザクションが進行中の場合）。
If protection is desired on the message, the client MUST protect it using the same technique (i.e., signature or MAC) as the starting message of the transaction. The CA MUST always sign it with a signature key.
メッセージに保護が必要な場合、クライアントは、トランザクションの開始メッセージと同じ手法（つまり、署名またはMac）を使用してそれを保護する必要があります。CAは常に署名キーで署名する必要があります。
This pair of messages is intended to handle scenarios in which the client needs to poll the server to determine the status of an outstanding response (i.e., when the "waiting" PKIStatus has been received).
このメッセージのペアは、クライアントがサーバーを投票して未解決の応答のステータスを決定する必要があるシナリオを処理することを目的としています（つまり、「待機」Pkistatusが受信されたとき）。
PollReqContent ::= SEQUENCE OF SEQUENCE {
certReqId INTEGER }
PollRepContent ::= SEQUENCE OF SEQUENCE {
certReqId INTEGER,
checkAfter INTEGER, -- time in seconds
reason PKIFreeText OPTIONAL }
Unless implicit confirmation has been requested and granted, in response to an ir, cr, p10cr, kur, krr, or ccr request message, polling is initiated with an ip, cp, kup, krp, or ccp response message containing status "waiting". For any type of request message, polling can be initiated with an error response message with status "waiting". The following clauses describe how polling messages are used. It is assumed that multiple certConf messages can be sent during transactions. There will be one sent in response to each ip, cp, kup, krp, or ccp that contains a CertStatus for an issued certificate.
IR、CR、P10CR、KUR、KRR、またはCCRリクエストメッセージに応じて、暗黙の確認が要求され、付与されていない限り、IP、CP、KUP、KRP、またはCCP応答メッセージを「待機」を含むCCP応答メッセージでポーリングが開始されます。あらゆるタイプのリクエストメッセージの場合、ステータス「待機」を備えたエラー応答メッセージでポーリングを開始できます。次の条項では、ポーリングメッセージの使用方法について説明します。トランザクション中に複数のCERTCONFメッセージを送信できると想定されています。発行された証明書の証明書を含む各IP、CP、KUP、KRP、またはCCPに応答して送信されます。
1. In response to an ip, cp, kup, krp, or ccp message, an end entity will send a certConf for all issued certificates and expect a pkiconf for each certConf. An end entity will send a pollReq message in response to each CertResponse element of an ip, cp, or kup message with status "waiting" and in response to an error message with status "waiting". Its certReqId MUST be either the index of a CertResponse data structure with status "waiting" or -1 referring to the complete response.
1. IP、CP、KUP、KRP、またはCCPメッセージに応じて、終了エンティティはすべての発行された証明書にCERTCONFを送信し、各CERTCONFにPKICONFを期待します。End Entityは、IP、CP、またはKUPメッセージの各Certresponse要素に応答して、「待機」を伴うPollReqメッセージを送信し、ステータス「待機」を持つエラーメッセージに応答します。そのcertreqidは、ステータス「待機」を伴うcertresponseデータ構造のインデックスまたは完全な応答を指す-1でなければなりません。
2. In response to a pollReq, a CA/RA will return an ip, cp, kup, krp, or ccp if one or more of the still pending requested certificates are ready or the final response to some other type of request is available; otherwise, it will return a pollRep.
2. Pollreqに応じて、CA/RAは、保留中の要求された証明書の1つ以上が準備ができている場合、または他のタイプのリクエストに対する最終的な応答が利用可能な場合、CA/RAはIP、CP、KUP、KRP、またはCCPを返します。それ以外の場合は、Pollrepを返します。
3. If the end entity receives a pollRep, it will wait for at least the number of seconds given in the checkAfter field before sending another pollReq.
3. End EntityがPollrepを受信した場合、別のPollreqを送信する前に、Checkafterフィールドで与えられた少なくとも秒数を待ちます。
Note that the checkAfter value heavily depends on the certificate management environment. There are different possible reasons for a delayed delivery of response messages, e.g., high load on the server's backend, offline transfer of messages between two PKI management entities, or required RA operator approval. Therefore, the checkAfter time can vary greatly. This should also be considered by the transfer protocol.
Checkafter値は、証明書管理環境に大きく依存することに注意してください。応答メッセージの配信が遅れた理由は、サーバーのバックエンドの高負荷、2つのPKI管理エンティティ間のメッセージのオフライン転送、または必要なRAオペレーターの承認など、さまざまな理由があります。したがって、チェックアフター時間は大きく異なる場合があります。これは、転送プロトコルでも考慮する必要があります。
4. If the end entity receives an ip, cp, kup, krp, or ccp, then it will be treated in the same way as the initial response; if it receives any other response, then this will be treated as the final response to the original request.
4. 最終エンティティがIP、CP、KUP、KRP、またはCCPを受信すると、初期応答と同じ方法で扱われます。他の応答を受信した場合、これは元のリクエストに対する最終的な応答として扱われます。
The following client-side state machine describes polling for individual CertResponse elements at the example of an ir request message.
次のクライアント側の状態マシンでは、IRリクエストメッセージの例で個々のcertresponse要素のポーリングについて説明しています。
START
|
v
Send ir
| ip
v
Check status
of returned <------------------------+
certs |
| |
+------------------------>|<------------------+ |
| | | |
| (issued) v (waiting) | |
Add to <----------- Check CertResponse ------> Add to |
conf list for each certificate pending list |
/ \ |
/ \ (empty conf list) |
(conf list) / \ |
/ \ ip |
/ \ +-----------------+
(empty pending list) V V | pollRep
END <---- Send certConf Send pollReq---------->Wait
| ^ ^ |
| | | |
+-----------------+ +---------------+
(pending list)
In the following exchange, the end entity is enrolling for two certificates in one request.
次の交換では、最終エンティティは1つのリクエストで2つの証明書に登録しています。
Step# End entity PKI
---------------------------------------------------------------------
1 format ir
2 --> ir -->
3 handle ir
4 manual intervention is
required for both certs
5 <-- ip <--
6 process ip
7 format pollReq
8 --> pollReq -->
9 check status of cert requests,
certificates not ready
10 format pollRep
11 <-- pollRep <--
12 wait
13 format pollReq
14 --> pollReq -->
15 check status of cert requests,
one certificate is ready
16 format ip
17 <-- ip <--
18 handle ip
19 format certConf
20 --> certConf -->
21 handle certConf
22 format ack
23 <-- pkiconf <--
24 format pollReq
25 --> pollReq -->
26 check status of certificate,
certificate is ready
27 format ip
28 <-- ip <--
29 handle ip
30 format certConf
31 --> certConf -->
32 handle certConf
33 format ack
34 <-- pkiconf <--
The following client-side state machine describes polling for a complete response message.
次のクライアント側の状態マシンは、完全な応答メッセージのポーリングについて説明しています。
Start
|
| Send request
v
+----------- Receive response ------------+
| |
| ip/cp/kup/krp/ccp/error with | other
| status "waiting" | response
| |
v |
+------> Polling |
| | |
| | Send pollReq |
| | Receive response |
| | |
| v |
+-----------+------------------->+<-------------------+
pollRep other response |
v
Handle response
|
v
End
In the following exchange, the end entity is sending a general message request, and the response is delayed by the server.
次の交換では、最終エンティティが一般的なメッセージ要求を送信しており、応答はサーバーによって遅れます。
Step# End entity PKI
---------------------------------------------------------------------
1 format genm
2 --> genm -->
3 handle genm
4 delay in response is necessary
5 format error message "waiting"
with certReqId set to -1
6 <-- error <--
7 process error
8 format pollReq
9 --> pollReq -->
10 check status of original request,
general message response not
ready
11 format pollRep
12 <-- pollRep <--
13 wait
14 format pollReq
15 --> pollReq -->
16 check status of original request,
general message response is
ready
17 format genp
18 <-- genp <--
19 handle genp
Some of the PKI management functions outlined in Section 3.1 are described in this section.
セクション3.1で概説されているPKI管理関数の一部は、このセクションで説明されています。
This section deals with functions that are "mandatory" in the sense that all end entity and CA/RA implementations MUST be able to provide the functionality described. This part is effectively the profile of the PKI management functionality that MUST be supported. Note, however, that the management functions described in this section do not need to be accomplished using the PKI messages defined in Section 5 if alternate means are suitable for a given environment. See Section 7 of [RFC9483] and Appendix C for profiles of the PKIMessage structures that MUST be supported for specific use cases.
このセクションでは、すべての最終エンティティとCA/RAの実装が説明されている機能を提供できる必要があるという意味で、「必須」の関数を扱います。この部分は、効果的にサポートする必要があるPKI管理機能のプロファイルです。ただし、このセクションで説明した管理機能は、特定の環境に適している場合、セクション5で定義されたPKIメッセージを使用して達成する必要はないことに注意してください。特定のユースケースでサポートする必要があるpkimessage構造のプロファイルについては、[RFC9483]のセクション7および付録Cを参照してください。
[See Section 3.1.1.2 for this document's definition of "root CA".]
[このドキュメントの「ルートCA」の定義については、セクション3.1.1.2を参照してください。]
If a newly created root CA is at the top of a PKI hierarchy, it usually produces a "self-certificate", which is a certificate structure with the profile defined for the "newWithNew" certificate issued following a root CA key update.
新しく作成されたルートCAがPKI階層の上部にある場合、通常、「自己認証」を生成します。これは、ルートCAキーアップデートに続いて発行された「NewWithNew」証明書のプロファイルを持つ証明書構造です。
In order to make the CA's self-certificate useful to end entities that do not acquire the self-certificate via "out-of-band" means, the CA must also produce a fingerprint for its certificate. End entities that acquire this fingerprint securely via some "out-of-band" means can then verify the CA's self-certificate and, hence, the other attributes contained therein.
CAの自己認証を有用にするためには、「帯域外」平均を介して自己認証を取得しないエンティティを終了するために、CAは証明書の指紋を作成する必要があります。いくつかの「帯域外」手段を介してこの指紋を安全に取得するエンティティは、CAの自己認証、したがって、そこに含まれる他の属性を検証できます。
The data structure used to carry the fingerprint may be the OOBCertHash (see Section 5.2.5).
指紋を運ぶために使用されるデータ構造は、obcerthashである可能性があります（セクション5.2.5を参照）。
CA keys (as all other keys) have a finite lifetime and will have to be updated on a periodic basis. The certificates NewWithNew, NewWithOld, and OldWithNew (see Section 4.4.1) MAY be issued by the CA to aid existing end entities who hold the current root CA certificate (OldWithOld) to transition securely to the new root CA certificate (NewWithNew) and to aid new end entities who will hold NewWithNew to acquire OldWithOld securely for verification of existing data.
CAキー（他のすべてのキーとして）には有限の寿命があり、定期的に更新する必要があります。NewWithNew、NewWithold、およびOldwithNew（セクション4.4.1を参照）は、現在のルートCA証明書（OldWithold）を保持している既存のエンティティ（NewWithnew）にしっかりと移行し、NewWithold Securelyの既存のデータを獲得するためにNewWithold Securelyのためにnewithold Securelyを取得するためにNewWithold Securelyの獲得を支援する既存の最終エンティティを支援するために、CAによって発行される場合があります。
[See Section 3.1.1.2 for this document's definition of "subordinate CA".]
[このドキュメントの「下位CA」の定義については、セクション3.1.1.2を参照してください。]
From the perspective of PKI management protocols, the initialization of a subordinate CA is the same as the initialization of an end entity. The only difference is that the subordinate CA must also produce an initial revocation list.
PKI管理プロトコルの観点から見ると、下位CAの初期化は終了エンティティの初期化と同じです。唯一の違いは、下位CAが最初の取り消しリストも作成する必要があることです。
Before issuing any certificates, a newly established CA (which issues CRLs) must produce "empty" versions of each CRL, which are to be periodically produced.
証明書を発行する前に、新しく確立されたCA（CRLを発行する）は、定期的に作成される各CRLの「空の」バージョンを作成する必要があります。
When a PKI entity (CA, RA, or end entity) wishes to acquire information about the current status of a CA, it MAY send that CA a request for such information.
PKIエンティティ（CA、RA、またはENDエンティティ）がCAの現在のステータスに関する情報を取得したい場合、CAのCAにそのような情報のリクエストを送信する場合があります。
The CA MUST respond to the request by providing (at least) all of the information requested by the requester. If some of the information cannot be provided, then an error must be conveyed to the requester.
CAは、要求者が要求したすべての情報を（少なくとも）提供することにより、要求に応答する必要があります。情報の一部を提供できない場合は、リクエスターにエラーを伝える必要があります。
If PKIMessages are used to request and supply this PKI information, then the request MUST be the GenMsg message, the response MUST be the GenRep message, and the error MUST be the Error message. These messages are protected using a MAC based on shared secret information (e.g., password-based MAC; see Section 6.1 of "CMP Algorithms" [RFC9481]) or using any asymmetric authentication means such as a signature (if the end entity has an existing certificate).
このPKI情報を要求して提供するためにpkimessagesを使用している場合、リクエストはGenmsgメッセージでなければならず、応答はGenRepメッセージでなければならず、エラーはエラーメッセージでなければなりません。これらのメッセージは、共有された秘密情報（パスワードベースのMAC、「CMPアルゴリズム」のセクション6.1を参照[RFC9481]を参照）に基づいてMACを使用して保護されます。
The requester CA is the CA that will become the subject of the cross-certificate; the responder CA will become the issuer of the cross-certificate.
リクエスターCAは、クロス認証の対象となるCAです。Responder CAは、クロス認証の発行者になります。
The requester CA must be "up and running" before initiating the cross-certification operation.
リクエスターCAは、相互認定操作を開始する前に「上昇している」必要があります。
The cross-certification scheme is essentially a one-way operation; that is, when successful, this operation results in the creation of one new cross-certificate. If the requirement is that cross-certificates be created in "both directions", then each CA, in turn, must initiate a cross-certification operation (or use another scheme).
相互認証スキームは、本質的に一方向の操作です。つまり、成功すると、この操作により、1つの新しいクロス認証が作成されます。要件が「両方方向」にクロス認証が作成される場合、各CAは、相互認定操作を開始する（または別のスキームを使用）する必要があります。
This scheme is suitable where the two CAs in question can already verify each other's signatures (they have some common points of trust) or where there is an out-of-band verification of the origin of the certification request.
このスキームは、問題の2つのCAが互いの署名（いくつかの共通の信頼ポイントがある）をすでに検証できる場合、または認証要求の起源の帯域外検証がある場合に適しています。
Detailed Description:
詳細な説明：
Cross-certification is initiated at one CA known as the responder. The CA administrator for the responder identifies the CA it wants to cross-certify and the responder CA equipment generates an authorization code. The responder CA administrator passes this authorization code by out-of-band means to the requester CA administrator. The requester CA administrator enters the authorization code at the requester CA in order to initiate the online exchange.
相互認証は、レスポンダーとして知られる1つのCAで開始されます。ResponderのCA管理者は、相互認定を取得するCAを識別し、Responder CA機器が認証コードを生成します。Responder CA管理者は、この承認コードを帯域外の手段でリクエスターCA管理者に渡します。Requester CA管理者は、オンライン交換を開始するために、Requester CAに承認コードを入力します。
The authorization code is used for authentication and integrity purposes. This is done by generating a symmetric key based on the authorization code and using the symmetric key for generating MACs on all messages exchanged. (Authentication may alternatively be done using signatures instead of MACs, if the CAs are able to retrieve and validate the required public keys by some means, such as an out-of-band hash comparison.)
認証コードは、認証と整合性の目的で使用されます。これは、承認コードに基づいて対称キーを生成し、交換されたすべてのメッセージでMACを生成するための対称キーを使用することによって行われます。（CASが帯域外ハッシュ比較など、必要なパブリックキーを何らかの手段で取得および検証できる場合、認証はMacの代わりに署名を使用して行われる場合があります。）
The requester CA initiates the exchange by generating a cross-certification request (ccr) with a fresh random number (requester random number). The requester CA then sends the ccr message to the responder CA. The fields in this message are protected from modification with a MAC based on the authorization code.
リクエスターCAは、新鮮な乱数（要求者乱数）で相互認証要求（CCR）を生成することにより、交換を開始します。リクエスターCAは、CCRメッセージをレスポンダーCAに送信します。このメッセージのフィールドは、承認コードに基づいてMACを使用して変更から保護されています。
Upon receipt of the ccr message, the responder CA validates the message and the MAC, saves the requester random number, and generates its own random number (responder random number). It then generates (and archives, if desired) a new requester certificate that contains the requester CA public key and is signed with the responder CA signature private key. The responder CA responds with the cross-certification response (ccp) message. The fields in this message are protected from modification with a MAC based on the authorization code.
CCRメッセージを受信すると、Responder CAはメッセージとMACを検証し、リクエスターの乱数を保存し、独自の乱数（Responder乱数）を生成します。次に、要求者CAの公開キーを含み、Responder CAの署名秘密鍵で署名された新しい要求者証明書を生成（および必要に応じて）生成します（必要に応じて）生成します。Responder CAは、相互認証応答（CCP）メッセージで応答します。このメッセージのフィールドは、承認コードに基づいてMACを使用して変更から保護されています。
Upon receipt of the ccp message, the requester CA validates the message (including the received random numbers) and the MAC. The requester CA responds with the certConf message. The fields in this message are protected from modification with a MAC based on the authorization code. The requester CA MAY write the requester certificate to the Repository as an aid to later certificate path construction.
CCPメッセージを受信すると、Requester CAはメッセージ（受信した乱数を含む）とMACを検証します。Requester CAは、CERTCONFメッセージで応答します。このメッセージのフィールドは、承認コードに基づいてMACを使用して変更から保護されています。リクエスターCAは、後の証明書パス構築への援助として、リクエスター証明書をリポジトリに書き込むことができます。
Upon receipt of the certConf message, the responder CA validates the message and the MAC and sends back an acknowledgement using the pkiconf message. It MAY also publish the requester certificate as an aid to later path construction.
CERTCONFメッセージを受信すると、Responder CAはメッセージとMACを検証し、PKICONFメッセージを使用して確認を送信します。また、後のパス構築への援助として、リクエスター証明書を公開することもできます。
Notes:
注：
1. The ccr message must contain a "complete" certification request; that is, all fields except the serial number (including, e.g., a BasicConstraints extension) must be specified by the requester CA.
1. CCRメッセージには、「完全な」認定リクエストが含まれている必要があります。つまり、シリアル番号を除くすべてのフィールド（たとえば、基本的な構成拡張を含む）は、リクエスターCAによって指定する必要があります。
2. The ccp message SHOULD contain the verification certificate of the responder CA; if present, the requester CA must then verify this certificate (for example, via the "out-of-band" mechanism).
2. CCPメッセージには、レスポンダーCAの検証証明書を含める必要があります。存在する場合、要求者CAはこの証明書を検証する必要があります（たとえば、「帯域外」メカニズムを介して）。
(A simpler, non-interactive model of cross-certification may also be envisioned, in which the issuing CA acquires the subject CA's public key from some repository, verifies it via some out-of-band mechanism, and creates and publishes the cross-certificate without the subject CA's explicit involvement. This model may be perfectly legitimate for many environments, but since it does not require any protocol message exchanges, its detailed description is outside the scope of this specification.)
相互認証のよりシンプルで非相互作用しない非対話的モデルも想定される可能性があります。発行CAは、発行CAが被験者CAの公開キーをいくつかのリポジトリから取得し、帯域外メカニズムからいくつかの帯域外のメカニズムを介して検証し、対象CAの明示的な関与なしにクロス認証を作成および公開します。仕様。）
As with CAs, end entities must be initialized. Initialization of end entities requires at least two steps:
CASと同様に、最終エンティティを初期化する必要があります。ENDエンティティの初期化には、少なくとも2つのステップが必要です。
* acquisition of PKI information
* PKI情報の取得
* out-of-band verification of one root-CA public key
* 1つのルートCA公開キーのバンド外の検証
(Other possible steps include the retrieval of trust condition information and/or out-of-band verification of other CA public keys.)
（他の考えられる手順には、信頼状態情報の検索および/または他のCAパブリックキーの帯域外検証が含まれます。）
The information REQUIRED is:
必要な情報は次のとおりです。
* the current root-CA public key
* 現在のルートCA公開キー
* (if the certifying CA is not a root-CA) the certification path from the root CA to the certifying CA together with appropriate revocation lists
* （認定CAがルートCAではない場合）適切な取り消しリストと一緒に、ルートCAから認証CAへの認証パス
* the algorithms and algorithm parameters that the certifying CA supports for each relevant usage
* 認証CAが関連する使用ごとにサポートするアルゴリズムとアルゴリズムパラメーター
Additional information could be required (e.g., supported extensions or CA policy information) in order to produce a certification request that will be successful. However, for simplicity, we do not mandate that the end entity acquires this information via the PKI messages. The end result is simply that some certification requests may fail (e.g., if the end entity wants to generate its own encryption key, but the CA doesn't allow that).
成功する認定要求を作成するために、追加情報（サポートされている拡張情報やCAポリシー情報など）が必要になる場合があります。ただし、簡単にするために、最終エンティティがPKIメッセージを介してこの情報を取得することを義務付けていません。最終結果は、一部の認証要求が失敗する可能性があることです（たとえば、最終エンティティが独自の暗号化キーを生成したいが、CAはそれを許可しない場合）。
The required information MAY be acquired as described in Section 6.5.
セクション6.5で説明されているように、必要な情報を取得できます。
An end entity must securely possess the public key of its root CA. One method to achieve this is to provide the end entity with the CA's self-certificate fingerprint via some secure "out-of-band" means. The end entity can then securely use the CA's self-certificate.
最終エンティティは、ルートCAの公開鍵を安全に所有する必要があります。これを達成する1つの方法は、安全な「帯域外」平均を介してCAの自己認証指紋を最終エンティティに提供することです。最終エンティティは、CAの自己認証を安全に使用できます。
See Section 6.1 for further details.
詳細については、セクション6.1を参照してください。
An initialized end entity MAY request an additional certificate at any time (for any purpose). This request will be made using the certification request (cr) message. If the end entity already possesses a signing key pair (with a corresponding verification certificate), then this cr message will typically be protected by the entity's digital signature. The CA returns the new certificate (if the request is successful) in a CertRepMessage.
初期化された終了エンティティは、いつでも追加の証明書を要求する場合があります（いかなる目的でも）。このリクエストは、認定リクエスト（CR）メッセージを使用して行われます。End Entityがすでに署名キーペアを持っている場合（対応する検証証明書を使用）、このCRメッセージは通常、エンティティのデジタル署名によって保護されます。CAは、certrepmessageで新しい証明書（リクエストが成功した場合）を返します。
When a key pair is due to expire, the relevant end entity MAY request a key update; that is, it MAY request that the CA issue a new certificate for a new key pair (or, in certain circumstances, a new certificate for the same key pair). The request is made using a key update request (kur) message (referred to, in some environments, as a "Certificate Update" operation). If the end entity already possesses a signing key pair (with a corresponding verification certificate), then this message will typically be protected by the entity's digital signature. The CA returns the new certificate (if the request is successful) in a key update response (kup) message, which is syntactically identical to a CertRepMessage.
キーペアの有効期限が切れる場合、関連する最終エンティティはキーアップデートを要求する場合があります。つまり、CAが新しいキーペアの新しい証明書を発行することを要求する場合があります（または、特定の状況では、同じキーペアの新しい証明書）。リクエストは、キーアップデートリクエスト（KUR）メッセージ（一部の環境では、「証明書の更新」操作と呼ばれます）を使用して行われます。End Entityが既に署名キーペアを持っている場合（対応する検証証明書を使用）、このメッセージは通常、エンティティのデジタル署名によって保護されます。CAは、CertrePmessageと構文的に同一のキーアップデート応答（KUP）メッセージで新しい証明書（リクエストが成功した場合）を返します。
This section defines the version negotiation used to support older protocols between clients and servers.
このセクションでは、クライアントとサーバー間の古いプロトコルをサポートするために使用されるバージョンのネゴシエーションを定義します。
If a client knows the protocol version(s) supported by the server (e.g., from a previous PKIMessage exchange or via some out-of-band means), then it MUST send a PKIMessage with the highest version supported by both it and the server. If a client does not know what version(s) the server supports, then it MUST send a PKIMessage using the highest version it supports with the following exception: Version cmp2021 SHOULD only be used if cmp2021 syntax is needed for the request being sent or for the expected response.
クライアントがサーバーでサポートされているプロトコルバージョンを知っている場合（たとえば、以前のPkimessage Exchangeから、またはいくつかの帯域外の手段による）、ITとサーバーの両方でサポートされている最高バージョンでpkimessageを送信する必要があります。クライアントがサーバーがサポートするバージョンがわからない場合、次の例外を除いてサポートする最高版を使用してPKIMESSAGEを送信する必要があります。バージョンCMP2021は、リクエストが送信されるか、予想される応答に必要な場合にのみ使用する必要があります。
Note: Using cmp2000 as the default pvno value is done to avoid extra message exchanges for version negotiation and to foster compatibility with cmp2000 implementations. Version cmp2021 syntax is only needed if a message exchange uses EnvelopedData, hashAlg (in CertStatus), POPOPrivKey with agreeMAC, or ckuann with RootCaKeyUpdateContent.
注：デフォルトのPVNO値としてCMP2000を使用することは、バージョンの交渉のための追加のメッセージ交換を回避し、CMP2000の実装との互換性を促進するために行われます。バージョンCMP2021構文は、メッセージ交換がEnvelopedData、Hashalg（certStatus）、AmmaryとPopoprivkey、またはrootcakeyupdatecontentを使用したckuannを使用する場合にのみ必要です。
If a server receives a message with a version that it supports, then the version of the response message MUST be the same as the received version. If a server receives a message with a version higher or lower than it supports, then it MUST send back an ErrorMsg with the unsupportedVersion bit set (in the failureInfo field of the pKIStatusInfo). If the received version is higher than the highest supported version, then the version in the error message MUST be the highest version the server supports; if the received version is lower than the lowest supported version, then the version in the error message MUST be the lowest version the server supports.
サーバーがサポートするバージョンを使用してメッセージを受信した場合、応答メッセージのバージョンは受信バージョンと同じでなければなりません。サーバーがサポートよりも高いまたは低いバージョンのメッセージを受信する場合、サポートされていないバージョンビットセットを使用してErrorMSGを送信する必要があります（pkistatusinfoの故障フィールド）。受信バージョンが最高のサポートバージョンよりも高い場合、エラーメッセージのバージョンはサーバーがサポートする最高版でなければなりません。受信したバージョンが最低サポートバージョンよりも低い場合、エラーメッセージのバージョンはサーバーがサポートする最低バージョンでなければなりません。
If a client gets back an ErrorMsgContent with the unsupportedVersion bit set and a version it supports, then it MAY retry the request with that version.
クライアントが、サポートされていないバージョンビットセットとサポートするバージョンを使用してErrorMSGContentを取り戻すと、そのバージョンでリクエストを再試行する場合があります。
[RFC2510] did not specify the behavior of implementations receiving versions they did not understand since there was only one version in existence. With the introduction of the revision in [RFC4210], the following versioning behavior is recommended.
[RFC2510]は、存在するバージョンが1つしかなかったため、理解できなかったバージョンを受信する実装の動作を指定しませんでした。[RFC4210]での改訂の導入により、次のバージョン化動作が推奨されます。
If, after sending a message with a pvno value higher than cmp1999, a client receives an ErrorMsgContent with a version of cmp1999, then it MUST abort the current transaction.
CMP1999よりも高いPVNO値を持つメッセージを送信した後、クライアントはCMP1999のバージョンでERRORMSGCONTENTを受信した場合、現在のトランザクションを中止する必要があります。
If a client receives a non-error PKIMessage with a version of cmp1999, then it MAY decide to continue the transaction (if the transaction hasn't finished) using the semantics described in [RFC2510]. If it does not choose to do so and the transaction is not finished, then it MUST abort the transaction and send an ErrorMsgContent with a version of cmp1999.
クライアントがCMP1999のバージョンを使用して非誤差pkimessageを受信した場合、[RFC2510]で説明されているセマンティクスを使用して、トランザクション（トランザクションが終了していない場合）を継続することを決定する場合があります。そうすることを選択しておらず、トランザクションが終了していない場合は、トランザクションを中止し、CMP1999のバージョンでErrormsgContentを送信する必要があります。
If a server receives a version cmp1999 message, it MAY revert to the behavior described in [RFC2510] and respond with version cmp1999 messages. If it does not choose to do so, then it MUST send back an ErrorMsgContent as described above in Section 7.
サーバーがバージョンCMP1999メッセージを受信した場合、[RFC2510]で説明されている動作に戻り、バージョンCMP1999メッセージで応答する場合があります。そうすることを選択しない場合は、上記のセクション7で説明したように、ErrormSgContentを送り返す必要があります。
It is well established that the role of a CA is to verify that the name and public key belong to the end entity prior to issuing a certificate. If an entity holding a private key obtains a certificate containing the corresponding public key issued for a different entity, it can authenticate as the entity named in the certificate. This facilitates masquerading. It is not entirely clear what security guarantees are lost if an end entity is able to obtain a certificate containing a public key that they do not possess the corresponding private key for. There are some scenarios, described as "forwarding attacks" in Appendix A of [Gueneysu], in which this can lead to protocol attacks against a naively implemented sign-then-encrypt protocol, but in general, it merely results in the end entity obtaining a certificate that they cannot use.
CAの役割は、証明書を発行する前に名前と公開鍵が最終エンティティに属していることを確認することであることが十分に確立されています。秘密鍵を保持しているエンティティが、別のエンティティに発行された対応する公開キーを含む証明書を取得した場合、証明書に名前が付けられたエンティティとして認証できます。これにより、仮面舞踏会が容易になります。最終エンティティが対応する秘密鍵を所有していない公開キーを含む証明書を取得できる場合、セキュリティ保証が失われるものは完全には明らかではありません。[Gueneysu]の付録Aに「転送攻撃」と呼ばれるいくつかのシナリオがあります。これにより、これは、単純に実装されたSign-Then-Incryptプロトコルに対するプロトコル攻撃につながる可能性がありますが、一般的に、使用できない証明書を取得するエンティティが得られるだけです。
Some cryptographic considerations are worth explicitly spelling out. In the protocols specified above, when an end entity is required to prove possession of a decryption key, it is effectively challenged to decrypt something (its own certificate). This scheme (and many others!) could be vulnerable to an attack if the possessor of the decryption key in question could be fooled into decrypting an arbitrary challenge and returning the cleartext to an attacker. Although in this specification a number of other failures in security are required in order for this attack to succeed, it is conceivable that some future services (e.g., notary, trusted time) could potentially be vulnerable to such attacks. For this reason, we reiterate the general rule that implementations should be very careful about decrypting arbitrary "ciphertext" and revealing recovered "plaintext" since such a practice can lead to serious security vulnerabilities.
いくつかの暗号化の考慮事項は、明示的に綴る価値があります。上記のプロトコルでは、復号化キーの所有を証明するために終了エンティティが必要な場合、何か（独自の証明書）を復号化することは事実上挑戦します。このスキーム（および他の多くのもの！）は、問題の復号化キーの所有者が任意の課題を解読し、攻撃者にクリアテキストを返すことにだまされる可能性がある場合、攻撃に対して脆弱になる可能性があります。この仕様では、この攻撃が成功するためにはセキュリティの他の多くの失敗が必要ですが、将来のサービス（例えば、公証人、信頼できる時間など）がそのような攻撃に対して脆弱である可能性があると考えられます。このため、任意の「暗号文」を復号化し、そのようなプラクティスが深刻なセキュリティの脆弱性につながる可能性があるため、実装が任意の「暗号文」を復号化し、回復した「プレーンテキスト」を明らかにすることに非常に注意する必要があるという一般的なルールを繰り返します。
The client MUST return the decrypted values only if they match the expected content type. In an indirect method, the decrypted value MUST be a valid certificate, and in a direct method, the decrypted value MUST be a Rand as defined in Section 5.2.8.3.3.
クライアントは、予想されるコンテンツタイプと一致する場合にのみ、復号化された値を返す必要があります。間接的な方法では、復号化された値は有効な証明書でなければならず、直接的な方法では、復号化された値はセクション5.2.8.3.3で定義されているRANDでなければなりません。
Note also that exposing a private key to the CA/RA as a POP technique can carry some security risks (depending upon whether or not the CA/ RA can be trusted to handle such material appropriately). Implementers are advised to:
また、POPテクニックとしてCA/ RAに秘密鍵を公開すると、セキュリティリスクがあることに注意してください（CA/ RAがそのような資料を適切に処理すると信頼できるかどうかに応じて）。実装者には次のようにアドバイスされています。
* Exercise caution in selecting and using this particular POP mechanism.
* この特定のポップメカニズムの選択と使用に注意してください。
* Only use this POP mechanism if archival of the private key is desired.
* 秘密鍵のアーカイブが必要な場合にのみ、このポップメカニズムを使用してください。
* When appropriate, have the user of the application explicitly state that they are willing to trust the CA/RA to have a copy of their private key before proceeding to reveal the private key.
* 必要に応じて、アプリケーションのユーザーに、秘密鍵を明らかにするために進む前に、CA/RAが秘密鍵のコピーを持っていると信頼する意思があると明示的に述べてください。
A small subgroup attack during a DH key exchange may be carried out as follows. A malicious end entity may deliberately choose DH parameters that enable it to derive (a significant number of bits of) the DH private key of the CA during a key archival or key recovery operation. Armed with this knowledge, the end entity would then be able to retrieve the decryption private key of another unsuspecting end entity, EE2, during EE2's legitimate key archival or key recovery operation with that CA. In order to avoid the possibility of such an attack, two courses of action are available. (1) The CA may generate a fresh DH key pair to be used as a protocol encryption key pair for each end entity with which it interacts. (2) The CA may enter into a key validation protocol (not specified in this document) with each requesting end entity to ensure that the end entity's protocol encryption key pair will not facilitate this attack. Option (1) is clearly simpler (requiring no extra protocol exchanges from either party) and is therefore RECOMMENDED.
DHキー交換中の小さなサブグループ攻撃は、次のように実行できます。悪意のある最終エンティティは、キーアーカイブまたはキーリカバリ操作中にCAのDH秘密鍵を（かなりの数のビット）導出できるようにするDHパラメーターを意図的に選択できます。この知識で武装して、最終エンティティは、EE2の合法的なキーアーカイブまたはキーリカバリ操作中に、疑いを持たないエンティティEE2の復号化の秘密鍵を取得できるようになります。このような攻撃の可能性を回避するために、2つのアクションコースが利用可能です。（1）CAは、それが相互作用する各エンティティのプロトコル暗号化キーペアとして使用する新しいDHキーペアを生成する場合があります。（2）CAは、各エンティティのプロトコル暗号化キーペアがこの攻撃を容易にしないことを確認するために、各エンティティを要求する各要求エンティティでキー検証プロトコル（このドキュメントで指定されていない）を入力することができます。オプション（1）は明らかに単純で（どちらの当事者からの追加のプロトコル交換を必要としない）ため、推奨されます。
Long-term security typically requires perfect forward secrecy (pfs). When transferring encrypted long-term confidential values such as centrally generated private keys or revocation passphrases, pfs is likely important. Yet, it is not needed for CMP message protection providing integrity and authenticity because transfer of PKI messages is usually completed in very limited time. For the same reason, it is not typically required for the indirect method to provide a POP (Section 5.2.8.3.2) delivering the newly issued certificate in encrypted form.
通常、長期的なセキュリティには、完全なフォワード秘密（PFS）が必要です。中央に生成されたプライベートキーや取り消しパスフレーズなど、暗号化された長期の機密値を転送する場合、PFSが重要です。しかし、PKIメッセージの転送は通常非常に限られた時間で完了するため、CMPメッセージ保護を整合性と信頼性を提供するためには必要ありません。同じ理由で、間接的な方法がPOP（セクション5.2.8.3.2）を提供するためには、暗号化された形式で新たに発行された証明書を提供することは通常必要ではありません。
Encrypted values (Section 5.2.2) are transferred using CMS EnvelopedData [RFC5652], which does not offer pfs. In cases where long-term security is needed, CMP messages SHOULD be transferred over a mechanism that provides pfs, such as TLS with appropriate cipher suites selected.
暗号化された値（セクション5.2.2）は、PFSを提供しないCMS EnvelopedData [RFC5652]を使用して転送されます。長期的なセキュリティが必要な場合、CMPメッセージは、適切な暗号スイートを選択したTLSなどのPFSを提供するメカニズムを介して転送する必要があります。
A CA should not reuse its certificate signing key for other purposes, such as protecting CMP responses and TLS connections. This way, exposure to other parts of the system and the number of uses of this particularly critical key are reduced to a minimum.
CAは、CMP応答やTLS接続の保護など、他の目的で証明書署名キーを再利用しないでください。このようにして、システムの他の部分への露出とこの特に重要なキーの使用数は最小限に抑えられます。
Implementations must generate nonces and private keys from random input. The use of inadequate pseudorandom number generators (PRNGs) to generate cryptographic keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys and to search the resulting small set of possibilities than brute-force searching the whole key space. As an example of predictable random numbers, see [CVE-2008-0166]; consequences of low-entropy random numbers are discussed in Mining Your Ps and Qs [MiningPsQs]. The generation of quality random numbers is difficult. ISO/IEC 20543:2019 [ISO.20543-2019], NIST SP 800-90A Rev.1 [NIST.SP.800_90Ar1], BSI AIS 31 V2.0 [AIS31], and other specifications offer valuable guidance in this area.
実装は、ランダム入力からNONCESとプライベートキーを生成する必要があります。暗号化キーを生成するために不十分な擬似ランダム数ジェネレーター（PRNGS）を使用すると、セキュリティがほとんどまたはまったくなりません。攻撃者は、キーを生成したPRNG環境を再現し、キー空間全体を検索するブルートフォースよりも、結果として生じる小さな可能性のセットを検索する方がはるかに簡単になる場合があります。予測可能な乱数の例として、[CVE-2008-0166]を参照してください。低エントロピー乱数の結果は、PSおよびQS [MiningPsQS]をマイニングする際に議論されています。品質の乱数の生成は困難です。ISO/IEC 20543：2019 [ISO.20543-2019]、Nist SP 800-90A Rev.1 [nist.sp.800_90AR1]、BSI AIS 31 V2.0 [AIS31]、およびその他の仕様は、この分野で貴重なガイダンスを提供します。
If shared secret information is generated by a cryptographically secure random number generator (CSRNG), it is safe to assume that the entropy of the shared secret information equals its bit length. If no CSRNG is used, the entropy of shared secret information depends on the details of the generation process and cannot be measured securely after it has been generated. If user-generated passwords are used as shared secret information, their entropy cannot be measured. Passwords generated from user-supplied entropy are typically insufficient for protected delivery of centrally generated keys or trust anchors.
共有秘密情報が暗号化された安全な乱数ジェネレーター（CSRNG）によって生成される場合、共有された秘密情報のエントロピーがビットの長さに等しいと仮定することは安全です。CSRNGが使用されない場合、共有された秘密情報のエントロピーは、生成プロセスの詳細に依存し、生成後に安全に測定することはできません。ユーザー生成されたパスワードが共有秘密情報として使用される場合、それらのエントロピーを測定することはできません。ユーザーがサポートしたエントロピーから生成されたパスワードは、通常、中央で生成されたキーまたは信頼アンカーの保護された配信には不十分です。
If the entropy of shared secret information protecting the delivery of a centrally generated key pair is known, it should not be less than the security strength of that key pair; if the shared secret information is reused for different key pairs, the security of the shared secret information should exceed the security strength of each individual key pair.
中央に生成されたキーペアの配信を保護する共有秘密情報のエントロピーがわかっている場合、そのキーペアのセキュリティ強度よりも少ないはずです。共有された秘密情報が異なるキーペアに対して再利用される場合、共有された秘密情報のセキュリティは、個々のキーペアのセキュリティ強度を超える必要があります。
For the case of a PKI management operation that delivers a new trust anchor (e.g., a root CA certificate), using caPubs or genp that is (a) not concluded in a timely manner or (b) where the shared secret information is reused for several key management operations, the entropy of the shared secret information, if known, should not be less than the security strength of the trust anchor being managed by the operation. The shared secret information should have an entropy that at least matches the security strength of the key material being managed by the operation. Certain use cases may require shared secret information that may be of a low security strength, e.g., a human-generated password. It is RECOMMENDED that such secret information be limited to a single PKI management operation.
（a）タイムリーな方法で結論付けられていないカプブまたはGenpを使用して、新しいトラストアンカー（例：ルートCA証明書）を提供するPKI管理操作の場合、または共有された秘密情報がいくつかの重要な管理操作のために再利用される場合、共有された秘密情報のエントロピーが既知である場合は、操業を管理するための信頼のセキュリティ強度よりも少ない場合はありません。共有された秘密情報には、少なくとも操作によって管理されている重要な資料のセキュリティ強度に一致するエントロピーが必要です。特定のユースケースには、セキュリティ強度が低い場合がある共有秘密情報が必要になる場合があります。たとえば、人間で生成されたパスワードなどです。このような秘密情報を単一のPKI管理操作に限定することをお勧めします。
Importantly for this section, further information about algorithm use profiles and their security strength is available in Section 7 of CMP Algorithms [RFC9481].
このセクションでは、アルゴリズムに関する詳細情報はプロファイルを使用し、そのセキュリティ強度はCMPアルゴリズム[RFC9481]のセクション7で利用できます。
For each PKI management operation using MAC-based message protection involving KEM (see Section 5.1.3.4), the KEM Encapsulate() function, providing a fresh KEM ciphertext (ct) and shared secret (ss), MUST be invoked.
KEMを含むMACベースのメッセージ保護を使用した各PKI管理操作（セクション5.1.3.4を参照）、KEM encapsulate（）関数は、新鮮なKEM Ciphertext（CT）と共有Secret（SS）を提供する必要があります。
It is assumed that the overall data size of the CMP messages in a PKI management operation protected by a single shared secret key is small enough not to introduce extra security risks.
単一の共有シークレットキーによって保護されているPKI管理操作のCMPメッセージの全体的なデータサイズは、追加のセキュリティリスクを導入しないほど小さいと想定されています。
To be appropriate for use with this specification, the KEM algorithm MUST explicitly be designed to be secure when the public key is used many times. For example, a KEM algorithm with a single-use public key is not appropriate because the public key is expected to be carried in a long-lived certificate [RFC5280] and used over and over. Thus, KEM algorithms that offer indistinguishability under adaptive chosen ciphertext attack (IND-CCA2) security are appropriate. A common design pattern for obtaining IND-CCA2 security with public key reuse is to apply the Fujisaki-Okamoto (FO) transform [Fujisaki] or a variant of the FO transform [Hofheinz].
この仕様で使用するのに適しているため、公開キーを何度も使用する場合、KEMアルゴリズムを明示的に安全にするように設計する必要があります。たとえば、公開キーは長寿命の証明書[RFC5280]に携帯され、何度も使用されると予想されるため、単一使用の公開キーを持つKEMアルゴリズムは適切ではありません。したがって、適応的に選択されたCiphertext攻撃（IND-CCA2）セキュリティの下で区別不可能を提供するKEMアルゴリズムが適切です。公開キーの再利用を使用してIND-CCA2セキュリティを取得するための一般的な設計パターンは、富士キサキオカモト（FO）変換[藤崎]またはFO変換[Hofheinz]のバリアントを適用することです。
Therefore, given a long-term public key using an IND-CCA2-secure KEM algorithm, there is no limit to the number of CMP messages that can be authenticated using KEM keys for MAC-based message protection.
したがって、IND-CCA2-Secure KEMアルゴリズムを使用した長期的な公開キーを考えると、Macベースのメッセージ保護のためにKEMキーを使用して認証できるCMPメッセージの数に制限はありません。
A provider of trust anchors, which may be an RA involved in configuration management of its clients, MUST NOT include to-be-trusted CA certificates in a CMP message unless the specific deployment scenario can ensure that it is adequate that the receiving end entity trusts these certificates, e.g., by loading them into its trust store.
クライアントの構成管理に関与するRAである可能性のあるトラストアンカーのプロバイダーは、特定の展開シナリオが受信エンティティがこれらの証明書を信頼していることを確実に保証できない限り、CMPメッセージに、実証されたCA証明書をCMPメッセージに含めるべきではありません。
Whenever an end entity receives in a CMP message a CA certificate to be used as a trust anchor (for example, in the caPubs field of a certificate response or in a general response), it MUST properly authenticate the message sender with existing trust anchors without requiring new trust anchor information included in the message.
End EntityがCMPメッセージでTrustアンカーとして使用するCA証明書を受信するときはいつでも（たとえば、証明書応答のカプブフィールドまたは一般的な応答のフィールドで）、メッセージに含まれる新しいトラストアンカー情報を必要とせずに既存のトラストアンカーでメッセージ送信者を適切に認証する必要があります。
Additionally, the end entity MUST verify that the sender is an authorized source of trust anchors. This authorization is governed by local policy and typically indicated using shared secret information or with a signature-based message protection using a certificate issued by a PKI that is explicitly authorized for this purpose.
さらに、最終エンティティは、送信者が信頼のアンカーの承認されたソースであることを確認する必要があります。この許可は、ローカルポリシーに準拠しており、通常、共有された秘密情報を使用して、またはこの目的のために明示的に承認されたPKIによって発行された証明書を使用して署名ベースのメッセージ保護を使用して示されます。
When a CA issues a certificate containing EKU extensions as defined in Section 4.5, this expresses delegation of an authorization that originally is only with the CA certificate itself. Such delegation is a very sensitive action in a PKI, and therefore, special care must be taken when approving such certificate requests to ensure that only legitimate entities receive a certificate containing such an EKU.
CAがセクション4.5で定義されているようにEKU拡張機能を含む証明書を発行する場合、これは元々CA証明書自体のみにある認可の委任を表します。このような委任はPKIで非常に敏感なアクションであるため、正当なエンティティのみがそのようなEKUを含む証明書を受け取ることを確認するために、そのような証明書リクエストを承認する際には特別な注意を払わなければなりません。
CAs that support indirect POP MUST NOT also publish final certificates to CT logs [RFC9162] before having received the certConf message containing the certHash of that certificate to complete the POP. The risk is that a malicious actor could fetch the final certificate from the CT log and use that to spoof a response to the implicit POP challenge via a certConf response. This risk does not apply to CT precertificates, so those are OK to publish.
間接POPをサポートするCASは、POPを完了するためにその証明書のCerthashを含むCertConfメッセージを受信する前に、CTログ[RFC9162]に最終証明書を公開してはなりません。リスクは、悪意のあるアクターがCTログから最終証明書を取得し、それを使用して、CertConf応答を介して暗黙のPOPチャレンジへの応答をスプーフィングできることです。このリスクはCTの既製のものには適用されないため、公開することは問題ありません。
If a certificate or its precertificate was published in a CT log, it must be revoked if a required certConf message could not be verified, especially when the implicit POP was used.
証明書またはその教員がCTログに公開された場合、特に暗黙のポップが使用された場合、必要なCERTCONFメッセージを検証できなかった場合は取り消す必要があります。
This document updates the ASN.1 modules in Appendix A.2 of CMP Updates [RFC9480]. The OID 116 (id-mod-cmp2023-02) was registered in the "SMI Security for PKIX Module Identifier" registry to identify the updated ASN.1 module.
このドキュメントは、CMP更新[RFC9480]の付録A.2のASN.1モジュールを更新します。OID 116（ID-MOD-CMP2023-02）は、「PKIXモジュール識別子のSMIセキュリティ」レジストリに登録され、更新されたASN.1モジュールを識別しました。
IANA has added the following entry in the "SMI Security for PKIX CMP Information Types" registry within the SMI Numbers registry group (see <https://www.iana.org/assignments/smi-numbers>) [RFC7299]:
IANAは、SMI番号レジストリグループ内の「PKIX CMP情報タイプのSMIセキュリティ」レジストリに次のエントリを追加しました（<https://www.iana.org/assignments/smi-numbers>）[RFC7299]：
Decimal:
小数：
24
24
Description:
説明：
id-it-KemCiphertextInfo
is-it-kem ciphertext情報
Reference:
参照：
RFC 9810
RFC 9810
Note that the new OID 1.2.840.113533.7.66.16 was registered by Entrust, and not by IANA, for id-KemBasedMac in the arc 1.2.840.113533.7.66. This was done to match the previous registrations for id-PasswordBasedMac and id-DHBasedMac, which are also on the Entrust private arc.
新しいOID 1.2.840.113533.7.66.16は、ARC 1.2.840.113533.7.66のID-KembasedMacについて、IANAではなく委任によって登録されたことに注意してください。これは、ID-PassWordBasedMacおよびID-DHBasedMacの以前の登録と一致するために行われました。
All existing references to [RFC2510], [RFC4210], and [RFC9480] at <https://www.iana.org/assignments/smi-numbers> except those in the "SMI Security for PKIX Module Identifier" registry have been replaced with references to this document.
[rfc2510]、[rfc4210]、[rfc9480]、<https://www.iana.org/assignments/smi-numbers>のすべての既存の参照は、「pkixモジュール識別子識別子識別子のSMIセキュリティ」レジストリを除き、この文書への参照に置き換えられています。
[MvOV97] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook
of Applied Cryptography", CRC Press ISBN 0-8493-8523-7,
1996, <https://cacr.uwaterloo.ca/hac/>.
[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>.
[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
Classes and Attribute Types Version 2.0", RFC 2985,
DOI 10.17487/RFC2985, November 2000,
<https://www.rfc-editor.org/info/rfc2985>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/info/rfc2986>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)", RFC 4211,
DOI 10.17487/RFC4211, September 2005,
<https://www.rfc-editor.org/info/rfc4211>.
[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>.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
<https://www.rfc-editor.org/info/rfc5480>.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,
DOI 10.17487/RFC5958, August 2010,
<https://www.rfc-editor.org/info/rfc5958>.
[RFC6402] Schaad, J., "Certificate Management over CMS (CMC)
Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011,
<https://www.rfc-editor.org/info/rfc6402>.
[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>.
[RFC8933] Housley, R., "Update to the Cryptographic Message Syntax
(CMS) for Algorithm Identifier Protection", RFC 8933,
DOI 10.17487/RFC8933, October 2020,
<https://www.rfc-editor.org/info/rfc8933>.
[RFC9045] Housley, R., "Algorithm Requirements Update to the
Internet X.509 Public Key Infrastructure Certificate
Request Message Format (CRMF)", RFC 9045,
DOI 10.17487/RFC9045, June 2021,
<https://www.rfc-editor.org/info/rfc9045>.
[RFC9481] Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray,
"Certificate Management Protocol (CMP) Algorithms",
RFC 9481, DOI 10.17487/RFC9481, November 2023,
<https://www.rfc-editor.org/info/rfc9481>.
[RFC9629] Housley, R., Gray, J., and T. Okubo, "Using Key
Encapsulation Mechanism (KEM) Algorithms in the
Cryptographic Message Syntax (CMS)", RFC 9629,
DOI 10.17487/RFC9629, August 2024,
<https://www.rfc-editor.org/info/rfc9629>.
[AIS31] Killmann, W. and W. Schindler, "A proposal for:
Functionality classes for random number generators -
Version 2.0", Federal Office for Information Security
(BSI), September 2011,
<https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/
Zertifizierung/Interpretationen/AIS_31_Functionality_class
es_for_random_number_generators_e.pdf>.
[CVE-2008-0166]
National Institute of Science and Technology (NIST),
"National Vulnerability Database - CVE-2008-0166", May
2008, <https://nvd.nist.gov/vuln/detail/CVE-2008-0166>.
[ETSI-3GPP.33.310]
3GPP, "Network Domain Security (NDS); Authentication
Framework (AF)", 3GPP TS 33.310 16.6.0, December 2020,
<http://www.3gpp.org/ftp/Specs/html-info/33310.htm>.
[Fujisaki] Fujisaki, E. and T. Okamoto, "Secure Integration of
Asymmetric and Symmetric Encryption Schemes", Journal of
Cryptology, vol. 26, no. 1, pp. 80-101,
DOI 10.1007/s00145-011-9114-1, December 2011,
<https://doi.org/10.1007/s00145-011-9114-1>.
[Gueneysu] Gueneysu, T., Hodges, P., Land, G., Ounsworth, M.,
Stebila, D., and G. Zaverucha, "Proof-of-possession for
KEM certificates using verifiable generation", Cryptology
ePrint Archive, Paper 2022/703, 2022,
<https://eprint.iacr.org/2022/703>.
[Hofheinz] Hofheinz, D., Hövelmanns, K., and E. Kiltz, "A Modular
Analysis of the Fujisaki-Okamoto Transformation", Theory
of Cryptography (TCC 2017), Lecture Notes in Computer
Science, vol. 10677, pp. 341-371,
DOI 10.1007/978-3-319-70500-2_12, November 2017,
<https://doi.org/10.1007/978-3-319-70500-2_12>.
[IEEE.802.1AR-2018]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks - Secure Device Identity", IEEE Std 802.1AR-2018,
DOI 10.1109/ieeestd.2018.8423794, August 2018,
<https://doi.org/10.1109/ieeestd.2018.8423794>.
[ISO.20543-2019]
ISO/IEC, "Information technology -- Security techniques --
Test and analysis methods for random bit generators within
ISO/IEC 19790 and ISO/IEC 15408", ISO/IEC 20543:2019,
October 2019, <https://www.iso.org/standard/68296.html>.
[MiningPsQs]
Heninger, N., Durumeric, Z., Wustrow, E., and J. A.
Halderman, "Mining Your Ps and Qs: Detection of Widespread
Weak Keys in Network Devices", 21st USENIX Security
Symposium (USENIX Security 12), August 2012,
<https://www.usenix.org/conference/usenixsecurity12/
technical-sessions/presentation/heninger>.
[ML-KEM] Turner, S., Kampanakis, P., Massimo, J., and B.
Westerbaan, "Internet X.509 Public Key Infrastructure -
Algorithm Identifiers for the Module-Lattice-Based Key-
Encapsulation Mechanism (ML-KEM)", Work in Progress,
Internet-Draft, draft-ietf-lamps-kyber-certificates-11, 22
July 2025, <https://datatracker.ietf.org/doc/html/draft-
ietf-lamps-kyber-certificates-11>.
[NIST.SP.800_90Ar1]
Barker, E. B. and J. M. Kelsey, "Recommendation for Random
Number Generation Using Deterministic Random Bit
Generators", NIST SP 800-90Ar1,
DOI 10.6028/NIST.SP.800-90Ar1, June 2015,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-90Ar1.pdf>.
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, DOI 10.17487/RFC1847,
October 1995, <https://www.rfc-editor.org/info/rfc1847>.
[RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key
Infrastructure Certificate Management Protocols",
RFC 2510, DOI 10.17487/RFC2510, March 1999,
<https://www.rfc-editor.org/info/rfc2510>.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP",
RFC 2585, DOI 10.17487/RFC2585, May 1999,
<https://www.rfc-editor.org/info/rfc2585>.
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
"Internet X.509 Public Key Infrastructure Certificate
Management Protocol (CMP)", RFC 4210,
DOI 10.17487/RFC4210, September 2005,
<https://www.rfc-editor.org/info/rfc4210>.
[RFC4212] Blinov, M. and C. Adams, "Alternative Certificate Formats
for the Public-Key Infrastructure Using X.509 (PKIX)
Certificate Management Protocols", RFC 4212,
DOI 10.17487/RFC4212, October 2005,
<https://www.rfc-editor.org/info/rfc4212>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
Protocol (LDAP): The Protocol", RFC 4511,
DOI 10.17487/RFC4511, June 2006,
<https://www.rfc-editor.org/info/rfc4511>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
DOI 10.17487/RFC5912, June 2010,
<https://www.rfc-editor.org/info/rfc5912>.
[RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules
for the Cryptographic Message Syntax (CMS) and the Public
Key Infrastructure Using X.509 (PKIX)", RFC 6268,
DOI 10.17487/RFC6268, July 2011,
<https://www.rfc-editor.org/info/rfc6268>.
[RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key
Infrastructure -- HTTP Transfer for the Certificate
Management Protocol (CMP)", RFC 6712,
DOI 10.17487/RFC6712, September 2012,
<https://www.rfc-editor.org/info/rfc6712>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7299] Housley, R., "Object Identifier Registry for the PKIX
Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014,
<https://www.rfc-editor.org/info/rfc7299>.
[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>.
[RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
Touch Provisioning (SZTP)", RFC 8572,
DOI 10.17487/RFC8572, April 2019,
<https://www.rfc-editor.org/info/rfc8572>.
[RFC8649] Housley, R., "Hash Of Root Key Certificate Extension",
RFC 8649, DOI 10.17487/RFC8649, August 2019,
<https://www.rfc-editor.org/info/rfc8649>.
[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
May 2021, <https://www.rfc-editor.org/info/rfc8995>.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/info/rfc9147>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
December 2021, <https://www.rfc-editor.org/info/rfc9162>.
[RFC9480] Brockhaus, H., von Oheimb, D., and J. Gray, "Certificate
Management Protocol (CMP) Updates", RFC 9480,
DOI 10.17487/RFC9480, November 2023,
<https://www.rfc-editor.org/info/rfc9480>.
[RFC9482] Sahni, M., Ed. and S. Tripathi, Ed., "Constrained
Application Protocol (CoAP) Transfer for the Certificate
Management Protocol", RFC 9482, DOI 10.17487/RFC9482,
November 2023, <https://www.rfc-editor.org/info/rfc9482>.
[RFC9483] Brockhaus, H., von Oheimb, D., and S. Fries, "Lightweight
Certificate Management Protocol (CMP) Profile", RFC 9483,
DOI 10.17487/RFC9483, November 2023,
<https://www.rfc-editor.org/info/rfc9483>.
[RFC9733] von Oheimb, D., Ed., Fries, S., and H. Brockhaus, "BRSKI
with Alternative Enrollment (BRSKI-AE)", RFC 9733,
DOI 10.17487/RFC9733, March 2025,
<https://www.rfc-editor.org/info/rfc9733>.
[RFC9811] Brockhaus, H., von Oheimb, D., Ounsworth, M., and J. Gray,
"Internet X.509 Public Key Infrastructure -- HTTP Transfer
for the Certificate Management Protocol (CMP)", RFC 9811,
July 2025, <https://www.rfc-editor.org/info/rfc9811>.
[UNISIG.Subset-137]
UNISIG, "ERTMS/ETCS On-line Key Management FFFIS", Subset-
137, V1.0.0, December 2015,
<https://www.era.europa.eu/system/files/2023-01/
sos3_index083_-_subset-137_v100.pdf>.
[X509.2019]
ITU-T, "Information technology - Open Systems
Interconnection - The Directory: Public-key and attribute
certificate frameworks", ITU-T Recommendation X.509
(10/2019), October 2019,
<https://handle.itu.int/11.1002/1000/14033>.
The reasons that justify the presence of an RA can be split into those that are due to technical factors and those that are organizational in nature. Technical reasons include the following.
RAの存在を正当化する理由は、技術的要因と本質的に組織的な要因によるものに分割される可能性があります。技術的な理由には、以下が含まれます。
* If hardware tokens are in use, then not all end entities will have the equipment needed to initialize these; the RA equipment can include the necessary functionality (this may also be a matter of policy).
* ハードウェアトークンが使用されている場合、すべてのエンティティがこれらを初期化するために必要な機器を持っているわけではありません。RA機器には、必要な機能を含めることができます（これはポリシーの問題でもあります）。
* Some end entities may not have the capability to publish certificates; again, the RA may be suitably placed for this.
* 一部のエンティティには、証明書を公開する機能がない場合があります。繰り返しますが、RAはこれに適した場所に配置される可能性があります。
* The RA will be able to issue signed revocation requests on behalf of end entities associated with it, whereas the end entity may not be able to do this (if the key pair is completely lost).
* RAは、それに関連するエンディティに代わって署名された失効リクエストを発行することができますが、最終エンティティはこれを行うことができない場合があります（キーペアが完全に失われた場合）。
Some of the organizational reasons that argue for the presence of an RA are the following.
RAの存在を主張する組織の理由のいくつかは、次のとおりです。
* It may be more cost effective to concentrate functionality in the RA equipment than to supply functionality to all end entities (especially if special token initialization equipment is to be used).
* すべての最終エンティティに機能を供給するよりも、RA機器に機能を集中させる方が費用対効果が高い場合があります（特に特別なトークン初期化機器を使用する場合）。
* Establishing RAs within an organization can reduce the number of CAs required, which is sometimes desirable.
* 組織内でRASを確立すると、必要なCAの数を減らすことができますが、これは望ましいこともあります。
* RAs may be better placed to identify people with their "electronic" names, especially if the CA is physically remote from the end entity.
* RAは、特にCAが最終エンティティから物理的にリモートである場合、「電子」名を持つ人々を識別するために配置される可能性があります。
* For many applications, there will already be some administrative structure in place so that candidates for the role of RA are easy to find (which may not be true of the CA).
* 多くのアプリケーションでは、RAの役割の候補者が簡単に見つけることができるように、すでに何らかの管理構造が整っています（CAには当てはまらないかもしれません）。
Further reasons relevant for automated machine-to-machine certificate lifecycle management are available in the Lightweight CMP Profile [RFC9483].
自動化されたマシンからマシンまでの証明書のライフサイクル管理に関連するさらなる理由は、軽量CMPプロファイル[RFC9483]で利用できます。
A revocation request must incorporate suitable security mechanisms, including proper authentication, in order to reduce the probability of successful denial-of-service attacks. A digital signature or DH/ KEM-based message protection on the request -- REQUIRED to support within this specification depending on the key type used if revocation requests are supported -- can provide the authentication required, but there are circumstances under which an alternative mechanism may be desirable (e.g., when the private key is no longer accessible and the entity wishes to request a revocation prior to re-certification of another key pair). In order to accommodate such circumstances, a password-based MAC (see Section 6.1 of CMP Algorithms [RFC9481]) on the request is also REQUIRED to support within this specification (subject to local security policy for a given environment) if revocation requests are supported and if shared secret information can be established between the requester and the responder prior to the need for revocation.
取り消し要求には、サービス拒否攻撃を成功させる確率を減らすために、適切な認証を含む適切なセキュリティメカニズムを組み込む必要があります。デジタル署名またはDH/ KEMベースのリクエスト保護 - 取り消し要求がサポートされている場合に使用されるキータイプに応じてこの仕様内でサポートするために必要な認証を提供することができますが、代替メカニズムが望ましい状況があります（たとえば、プライベートキーがもはや別のキーペアの再認証のための採点を要求したい場合）。このような状況に対応するために、この仕様内でサポートするパスワードベースのMAC（CMPアルゴリズム[RFC9481]のセクション6.1 [RFC9481]を参照）も必要です（特定の環境の現地セキュリティポリシーの対象となります）。
A mechanism that has seen use in some environments is "revocation passphrase", in which a value of sufficient entropy (i.e., a relatively long passphrase rather than a short password) is shared between (only) the entity and the CA/RA at some point prior to revocation; this value is later used to authenticate the revocation request.
一部の環境で使用されているメカニズムは「取り消しパスフレーズ」です。このメカニズムでは、十分なエントロピーの値（つまり、短いパスワードではなく比較的長いパスフレーズ）が、取り消し前のある時点でエンティティとCA/RAの間で（のみ）共有されます。この値は、後で取り消し要求を認証するために使用されます。
In this specification, the following technique to establish shared secret information (i.e., a revocation passphrase) is OPTIONAL to support. Its precise use in CMP messages is as follows.
この仕様では、共有された秘密情報（つまり、取り消しパスフレーズ）を確立するための次の手法がオプションをサポートするためにオプションです。CMPメッセージでのその正確な使用は次のとおりです。
* The OID and value specified in Section 5.3.19.9 MAY be sent in a GenMsg message at any time or MAY be sent in the generalInfo field of the PKIHeader of any PKIMessage at any time. (In particular, the EncryptedKey structure as described in Section 5.2.2 may be sent in the header of the certConf message that confirms acceptance of certificates requested in an initialization request or certificate request message.) This conveys a revocation passphrase chosen by the entity to the relevant CA/RA. When EnvelopedData is used, this is in the decrypted bytes of the encryptedContent field. When EncryptedValue is used, this is in the decrypted bytes of the encValue field. Furthermore, the transfer is accomplished with appropriate confidentiality characteristics.
* セクション5.3.19.9で指定されているOIDと値は、いつでもGENMSGメッセージで送信されるか、いつでもpkimessageのpkiheaderの一般的なフィールドで送信される場合があります。（特に、セクション5.2.2で説明されている暗号化されたキー構造は、初期化要求または証明書リクエストメッセージで要求された証明書の受け入れを確認するCERTCONFメッセージのヘッダーに送信される場合があります。）これは、エンティティによって選択されたCA/RAに選択された取り消しパスフレーズを伝えます。EnvelopedDataを使用すると、これは暗号化されたコンテンツフィールドの復号化されたバイトにあります。暗号化されたValueを使用すると、これはエンクバリューフィールドの復号化されたバイトにあります。さらに、転送は適切な機密性の特性で達成されます。
* If a CA/RA receives the revocation passphrase (OID and value specified in Section 5.3.19.9) in a GenMsg, it MUST construct and send a GenRep message that includes the OID (with absent value) specified in Section 5.3.19.9. If the CA/RA receives the revocation passphrase in the generalInfo field of a PKIHeader of any PKIMessage, it MUST include the OID (with absent value) in the generalInfo field of the PKIHeader of the corresponding response PKIMessage. If the CA/RA is unable to return the appropriate response message for any reason, it MUST send an error message with a status of "rejection" and, optionally, a failInfo reason set.
* CA/RAがGENMSGでCA/RAが取り消しパスフレーズ（OIDおよび値5.3.19.9で指定されている値）を受信した場合、セクション5.3.19.9で指定されているOID（存在しない値を持つ）を含むGenRepメッセージを構築および送信する必要があります。CA/RAが、pkimessageのpkiheaderのGeneralInfoフィールドで取り消しパスフレーズを受信した場合、対応する応答pkimessageのpkiheaderのGeneralInfoフィールドにoid（価値がない）を含める必要があります。CA/RAが何らかの理由で適切な応答メッセージを返すことができない場合、「拒否」のステータス、およびオプションではfailinfo理由セットのエラーメッセージを送信する必要があります。
* Either the localKeyId attribute of EnvelopedData as specified in [RFC2985] or the valueHint field of EncryptedValue MAY contain a key identifier (chosen by the entity, along with the passphrase itself) to assist in later retrieval of the correct passphrase (e.g., when the revocation request is constructed by the end entity and received by the CA/RA).
* [RFC2985]で指定されているEnvelopedDataのLocalKeyID属性または暗号化されたバリューのValueHintフィールドには、キー識別子（エンティティによって選択され、パスフレーズ自体とともに選択）が含まれている場合があります。
* The revocation request message is protected by a password-based MAC (see Section 6.1 of "CMP Algorithms" [RFC9481]) with the revocation passphrase as the key. If appropriate, the senderKID field in the PKIHeader MAY contain the value previously transmitted in localKeyId or valueHint.
* 取り消し要求メッセージは、パスワードベースのMAC（「CMPアルゴリズム」のセクション6.1を参照[RFC9481]）によって保護されており、撤回パスフレーズはキーです。必要に応じて、pkiheaderのsenderkidフィールドには、localkeyidまたはvaluehintで以前に送信された値が含まれている場合があります。
Note: For a message transferring a revocation passphrase indicating cmp2021(3) in the pvno field of the PKIHeader, the encrypted passphrase MUST be transferred in the envelopedData choice of EncryptedKey as defined in Section 5.2.2. When using cmp2000(2) in the message header for backward compatibility, the encryptedValue is used. This allows the necessary conveyance and protection of the passphrase while maintaining bits-on-the-wire compatibility with [RFC4210]. The encryptedValue choice has been deprecated in favor of encryptedData.
注：PKIHeaderのPVNOフィールドでCMP2021（3）を示す取り消しパスフレーズを転送するメッセージの場合、セクション5.2.2で定義されている暗号化された暗号化されたKeyの選択肢で暗号化されたパスフレーズを転送する必要があります。後方互換性のためにメッセージヘッダーでCMP2000（2）を使用する場合、暗号化されたバリューが使用されます。これにより、[RFC4210]とワイヤーのビット互換性を維持しながら、必要な輸送とパスフレーズの保護が可能になります。暗号化されたバリューの選択は、暗号化されたDataを支持して廃止されました。
Using the technique specified above, the revocation passphrase may be initially established and updated at any time without requiring extra messages or out-of-band exchanges. For example, the revocation request message itself (protected and authenticated through a MAC that uses the revocation passphrase as a key) may contain, in the PKIHeader, a new revocation passphrase to be used for authenticating future revocation requests for any of the entity's other certificates. In some environments, this may be preferable to mechanisms that reveal the passphrase in the revocation request message, since this can allow a denial-of-service attack in which the revealed passphrase is used by an unauthorized third party to authenticate revocation requests on the entity's other certificates. However, because the passphrase is not revealed in the request message, there is no requirement that the passphrase must always be updated when a revocation request is made (that is, the same passphrase MAY be used by an entity to authenticate revocation requests for different certificates at different times).
上記で指定された手法を使用すると、取り消しパスフレーズは、追加のメッセージや帯域外の交換を必要とせずに、いつでもいつでも確立および更新できます。たとえば、取り消しリクエストメッセージ自体（失効パスフレーズをキーとして使用するMACを介して保護および認証された）には、PKIHeaderには、エンティティの他の証明書の将来の取り消し要求を認証するために使用される新しい取り消しパスフレーズが含まれている場合があります。一部の環境では、これは取り消しリクエストメッセージのパスフレーズを明らかにするメカニズムよりも好ましい場合があります。これにより、明らかにされたパスフレーズが不正な第三者が使用するサービス拒否攻撃が可能であるため、エンティティの他の証明書の取り消し要求を認証することができます。ただし、パスフレーズはリクエストメッセージで明らかにされていないため、失効リクエストが行われたときにパスフレーズを常に更新する必要はありません（つまり、同じパスフレーズをエンティティが使用して、異なる時期に異なる証明書のリクエストを認証することができます）。
Furthermore, the above technique can provide strong cryptographic protection over the entire revocation request message even when a digital signature is not used. Techniques that do authentication of the revocation request by simply revealing the revocation passphrase typically do not provide cryptographic protection over the fields of the request message (so that a request for revocation of one certificate may be modified by an unauthorized third party to a request for revocation of another certificate for that entity).
さらに、上記の手法は、デジタル署名が使用されていない場合でも、取り消し要求メッセージ全体で強力な暗号化保護を提供できます。取り消しパスフレーズを明らかにするだけで取り消し要求の認証を行う手法は、通常、要求メッセージのフィールドに暗号化保護を提供しません（そのため、1つの証明書の取り消しの要求は、そのエンティティの別の証明書の取り消し要求のために不正な第三者によって変更される可能性があります）。
This appendix contains detailed profiles for those PKIMessages that MUST be supported by conforming implementations (see Section 6).
この付録には、実装を適合させることでサポートする必要があるこれらのpkimessageの詳細なプロファイルが含まれています（セクション6を参照）。
Note: Appendices C and D focus on PKI management operations managing certificates for human end entities. In contrast, the Lightweight CMP Profile [RFC9483] focuses on typical use cases of industrial and IoT scenarios supporting highly automated certificate lifecycle management scenarios.
注：付録CおよびDは、人間の最終エンティティの証明書を管理するPKI管理操作に焦点を当てています。対照的に、軽量CMPプロファイル[RFC9483]は、高度に自動化された証明書ライフサイクル管理シナリオをサポートする産業およびIoTシナリオの典型的なユースケースに焦点を当てています。
Profiles for the PKIMessages used in the following PKI management operations are provided:
次のPKI管理操作で使用されるPKIMESSAGEのプロファイルが提供されます。
* initial registration/certification
* 初期登録/認定
* basic authenticated scheme
* 基本的な認証されたスキーム
* certificate request
* 証明書リクエスト
* key update
* キーアップデート
1. Where OPTIONAL or DEFAULT fields are not mentioned in individual profiles, they SHOULD be absent from the relevant message (i.e., a receiver can validly reject a message containing such fields as being syntactically incorrect). Mandatory fields are not mentioned if they have an obvious value. The protocol version number MUST be set as specified in Section 7).
1. 個々のプロファイルでオプションまたはデフォルトのフィールドが言及されていない場合、関連するメッセージに存在しないはずです（つまり、受信者は、このフィールドを含むメッセージを構文的に間違っていることを有効に拒否できます）。必須のフィールドは、明らかな値を持っている場合、言及されていません。プロトコルバージョン番号は、セクション7で指定されているように設定する必要があります。
2. Where structures occur in more than one message, they are separately profiled as appropriate.
2. 構造が複数のメッセージで発生する場合、必要に応じて個別にプロファイルされます。
3. The algorithmIdentifiers from PKIMessage structures are profiled separately.
3. pkimessage構造からのアルゴリズムのdididifiersは、個別にプロファイルされています。
4. A "special" X.500 DN is called the "NULL-DN"; this means a DN containing a zero-length SEQUENCE OF RelativeDistinguishedNames (its DER encoding is then '3000'H).
4. 「特別な」X.500 DNは「null-dn」と呼ばれます。これは、relativedististinguednamesのゼロ長シーケンスを含むDNを意味します（そのderエンコーディングは '3000'h）。
5. Where a GeneralName is required for a field, but no suitable value is available (e.g., an end entity produces a request before knowing its name), then the GeneralName is to be an X.500 NULL-DN (i.e., the Name field of the CHOICE is to contain a NULL-DN).
5. フィールドには一般名が必要ですが、適切な値が利用できない場合（たとえば、エンティティはその名前を知る前にリクエストを生成します）、一般名はx.500 null-dnになります（つまり、選択の名前フィールドはnull-dnを含むことです）。
6. Where a profile omits to specify the value for a GeneralName, then the NULL-DN value is to be present in the relevant PKIMessage field. This occurs with the sender field of the PKIHeader for some messages.
6. プロファイルが省略して一般名の値を指定する場合、null-dn値は関連するpkimessageフィールドに存在します。これは、一部のメッセージに対してPKIHeaderの送信者フィールドで発生します。
7. Where any ambiguity arises due to naming of fields, the profile names these using a "dot" notation (e.g., "certTemplate.subject" means the subject field within a field called certTemplate).
7. フィールドの命名によりあいまいさが生じる場合、プロファイルは「ドット」表記（「certtemplate.subject」を意味する」を使用してこれらに名前を付けます。
8. Where a "SEQUENCE OF types" is part of a message, a zero-based array notation is used to describe fields within the SEQUENCE OF (e.g., crm[0].certReq.certTemplate.subject refers to a subfield of the first CertReqMsg contained in a request message).
8. 「タイプのシーケンス」がメッセージの一部である場合、ゼロベースの配列表記を使用して、一連のシーケンス内のフィールドを記述します（例えば、CRM [0] .Certreq.CertTemplate.Subjectは、リクエストメッセージに含まれる最初のcertreqMSGのサブフィールドを指します）。
9. All PKI message exchanges in Appendices C.4 to C.6 require a certConf message to be sent by the initiating entity and a pkiconf message to be sent by the responding entity. The pkiconf is not included in some of the profiles given since its body is NULL and its header contents are clear from the context. Any authenticated means can be used for the protectionAlg (e.g., password-based MAC, if shared secret information is known, or signature).
9. 付録C.4からC.6のすべてのPKIメッセージ交換では、開始エンティティによって送信されるCERTCONFメッセージと、応答エンティティによって送信されるPKICONFメッセージが必要です。PKICONFは、その体がヌルであり、そのヘッダーの内容がコンテキストから明確であるため、与えられたいくつかのプロファイルには含まれていません。認証された手段は、保護物に使用できます（たとえば、共有された秘密情報がわかっている場合、または署名）。
For specifications of algorithm identifiers and respective conventions for conforming implementations, please refer to Section 7.1 of CMP Algorithms [RFC9481].
アルゴリズム識別子の仕様と、実装を適合させるためのそれぞれの規則については、CMPアルゴリズム[RFC9481]のセクション7.1を参照してください。
The table below describes the POP fields for use (in signature field of pop field of ProofOfPossession structure) when proving possession of a private signing key that corresponds to a public verification key for which a certificate has been requested.
以下の表は、証明書が要求されている公開検証キーに対応するプライベート署名キーの所有を証明する際の使用のためのポップフィールド（POPPOSSESTION構造のポップフィールドの署名フィールド）について説明しています。
+=====================+=============+===========================+
| Field | Value | Comment |
+=====================+=============+===========================+
| algorithmIdentifier | MSG_SIG_ALG | only signature protection |
| | | is allowed for this proof |
+---------------------+-------------+---------------------------+
| signature | present | bits calculated using |
| | | MSG_SIG_ALG |
+---------------------+-------------+---------------------------+
Table 2
Note: For examples of MSG_SIG_ALG OIDs, see Section 3 of CMP Algorithms [RFC9481].
注：MSG_SIG_ALG OIDSの例については、CMPアルゴリズム[RFC9481]のセクション3を参照してください。
POP of a private decryption key that corresponds to a public encryption key for which a certificate has been requested does not use this profile; the CertHash field of the certConf message is used instead.
証明書が要求されたパブリック暗号化キーに対応するプライベート復号化キーのポップは、このプロファイルを使用しません。代わりに、CERTCONFメッセージのCerthashフィールドが使用されます。
Not every CA/RA will do POP (of signing key, decryption key, or key agreement key) in the PKIX-CMP in-band certification request protocol (how POP is done MAY ultimately be a policy issue that is made explicit for any given CA in its publicized Policy OID and Certification Practice Statement). However, this specification mandates that CA/RA entities MUST do POP (by some means) as part of the certification process. All end entities MUST be prepared to provide POP (i.e., these components of the PKIX-CMP protocol MUST be supported).
すべてのCA/RAが、PKIX-CMPインバンド認定リクエストプロトコルで（署名キー、復号化キー、またはキー契約キー）を（署名キー、復号化キー、またはキー契約キーの）POPを実行するわけではありません（最終的に行われる方法は、公表されたポリシーOIDおよび認定慣行声明の任意のCAに対して明示されるポリシーの問題である可能性があります）。ただし、この仕様は、CA/RAエンティティが認証プロセスの一部として（何らかの方法で）POPを行う必要があることを義務付けています。すべてのエンティティをPOPを提供するために準備する必要があります（つまり、PKIX-CMPプロトコルのこれらのコンポーネントをサポートする必要があります）。
An (uninitialized) end entity requests a (first) certificate from a CA. When the CA responds with a message containing a certificate, the end entity replies with a certificate confirmation. The CA sends a pkiconf message back, closing the transaction. All messages are authenticated.
（非初期化されていない）エンティティは、caから（最初の）証明書を要求します。CAが証明書を含むメッセージで応答すると、End Entityは証明書の確認で応答します。CAはPKICONFメッセージを送り返し、トランザクションを閉じます。すべてのメッセージは認証されています。
This scheme allows the end entity to request certification of a locally generated public key (typically a signature key). The end entity MAY also choose to request the centralized generation and certification of another key pair (typically an encryption key pair).
このスキームにより、エンティティはローカルに生成された公開キー（通常は署名キー）の認証を要求できます。End Entityは、別のキーペアの集中生成と認証を要求することもできます（通常、暗号化キーペア）。
Certification may only be requested for one locally generated public key (for more, use separate PKIMessages).
認定は、1つのローカルで生成された公開キーに対してのみ要求される場合があります（詳細については、個別のpkimessageを使用してください）。
The end entity MUST support POP of the private key associated with the locally generated public key.
最終エンティティは、ローカルに生成された公開キーに関連付けられている秘密鍵のPOPをサポートする必要があります。
Preconditions:
前提条件：
1. The end entity can authenticate the CA's signature based on out-of-band means.
1. 最終エンティティは、帯域外の平均に基づいてCAの署名を認証できます。
2. The end entity and the CA share a symmetric MACing key.
2. End EntityとCAは、対称マッキングキーを共有します。
Message Flow:
メッセージフロー：
Step# End entity PKI
---------------------------------------------------------------------
1 format ir
2 --> ir -->
3 handle ir
4 format ip
5 <-- ip <--
6 handle ip
7 format certConf
8 --> certConf -->
9 handle certConf
10 format pkiconf
11 <-- pkiconf <--
12 handle pkiconf
For this profile, we mandate that the end entity MUST include all (i.e., one or two) CertReqMsg in a single PKIMessage and that the PKI (CA) MUST produce a single response PKIMessage that contains the complete response (i.e., including the OPTIONAL second key pair, if it was requested and if centralized key generation is supported). For simplicity, we also mandate that this message MUST be the final one (i.e., no use of "waiting" status value).
このプロファイルでは、最終エンティティには1つのpkimessageにすべて（1つまたは2つの）certreqmsgを含める必要があり、PKI（CA）は、完全な応答を含む単一の応答pkimessageを作成する必要があることを義務付けています。簡単にするために、このメッセージが最後のものでなければならないことを義務付けています（つまり、「待機」ステータス値を使用しない）。
The end entity has an out-of-band interaction with the CA/RA. This transaction established the shared secret, the referenceNumber, and optionally the DN used for both the sender and subject name in the certificate template. See Section 8.7 for security considerations on quality of shared secret information.
End Entityには、CA/RAとの外れの相互作用があります。このトランザクションは、共有秘密、ReferenCeNumber、およびオプションでは、証明書テンプレートの送信者と件名名の両方に使用されるDNを確立しました。共有された秘密情報の品質に関するセキュリティに関する考慮事項については、セクション8.7を参照してください。
Initialization Request -- ir
初期化リクエスト-IR
Field Value
recipient CA name
-- the name of the CA who is being asked to produce a certificate
protectionAlg MSG_MAC_ALG
-- only MAC protection is allowed for this request, based
-- on initial authentication key
senderKID referenceNum
-- the reference number that the CA has previously issued
-- to the end entity (together with the MACing key)
transactionID present
-- implementation-specific value, meaningful to end
-- entity.
-- [If already in use at the CA, then a rejection message MUST
-- be produced by the CA]
senderNonce present
-- 128 (pseudo-)random bits
freeText any valid value
body ir (CertReqMessages)
only one or two CertReqMsg
are allowed
-- if more certificates are required, requests MUST be
-- packaged in separate PKIMessages
CertReqMsg one or two present
-- see below for details, note: crm[0] means the first
-- (which MUST be present), crm[1] means the second (which
-- is OPTIONAL, and used to ask for a centrally generated key)
crm[0].certReq. fixed value of zero
certReqId
-- this is the index of the template within the message
crm[0].certReq present
certTemplate
-- MUST include subject public key value, otherwise unconstrained
crm[0].pop... optionally present if public key
POPOSigningKey from crm[0].certReq.certTemplate is
a signing key
-- POP MAY be required in this exchange
-- (see Appendix D.3 for details)
crm[0].certReq. optionally present
controls.archiveOptions
-- the end entity MAY request that the locally generated
-- private key be archived
crm[0].certReq. optionally present
controls.publicationInfo
-- the end entity MAY ask for publication of resulting cert.
crm[1].certReq fixed value of one
certReqId
-- the index of the template within the message
crm[1].certReq present
certTemplate
-- MUST NOT include actual public key bits, otherwise
-- unconstrained (e.g., the names need not be the same as in
-- crm[0]). Note that subjectPublicKeyInfo MAY be present
-- and contain an AlgorithmIdentifier followed by a
-- zero-length BIT STRING for the subjectPublicKey if it is
-- desired to inform the CA/RA of algorithm and parameter
-- preferences regarding the to-be-generated key pair.
crm[1].certReq. present [object identifier MUST be
PROT_ENC_ALG]
controls.protocolEncrKey
-- if centralized key generation is supported by this CA,
-- this short-term asymmetric encryption key (generated by
-- the end entity) will be used by the CA to encrypt (a
-- symmetric key used to encrypt) a private key generated by
-- the CA on behalf of the end entity
crm[1].certReq. optionally present
controls.archiveOptions
crm[1].certReq. optionally present
controls.publicationInfo
protection present
-- bits calculated using MSG_MAC_ALG
Initialization Response -- ip
初期化応答-IP
Field Value
sender CA name
-- the name of the CA who produced the message
messageTime present
-- time at which CA produced message
protectionAlg MSG_MAC_ALG
-- only MAC protection is allowed for this response
senderKID referenceNum
-- the reference number that the CA has previously issued to the
-- end entity (together with the MACing key)
transactionID present
-- value from corresponding ir message
senderNonce present
-- 128 (pseudo-)random bits
recipNonce present
-- value from senderNonce in corresponding ir message
freeText any valid value
body ip (CertRepMessage)
contains exactly one response
for each request
-- The PKI (CA) responds to either one or two requests as
-- appropriate. crc[0] denotes the first (always present);
-- crc[1] denotes the second (only present if the ir message
-- contained two requests and if the CA supports centralized
-- key generation).
crc[0]. fixed value of zero
certReqId
-- MUST contain the response to the first request in the
-- corresponding ir message
crc[0].status. present, positive values allowed:
status "accepted", "grantedWithMods"
negative values allowed:
"rejection"
crc[0].status. present if and only if
failInfo crc[0].status.status is "rejection"
crc[0]. present if and only if
certifiedKeyPair crc[0].status.status is
"accepted" or "grantedWithMods"
certificate present unless end entity's public
key is an encryption key and POP
is done in this in-band exchange
encryptedCert present if and only if end entity's
public key is an encryption key and
POP done in this in-band exchange
publicationInfo optionally present
-- indicates where certificate has been published (present
-- at discretion of CA)
crc[1]. fixed value of one
certReqId
-- MUST contain the response to the second request in the
-- corresponding ir message
crc[1].status. present, positive values allowed:
status "accepted", "grantedWithMods"
negative values allowed:
"rejection"
crc[1].status. present if and only if
failInfo crc[0].status.status is "rejection"
crc[1]. present if and only if
certifiedKeyPair crc[0].status.status is "accepted"
or "grantedWithMods"
certificate present
privateKey present
-- Use EnvelopedData; if backward compatibility is required,
-- use EncryptedValue, see Section 5.2.2
publicationInfo optionally present
-- indicates where certificate has been published (present
-- at discretion of CA)
protection present
-- bits calculated using MSG_MAC_ALG
extraCerts optionally present
-- the CA MAY provide additional certificates to the end
-- entity
Certificate confirm -- certConf
証明書確認-CERTCONF
Field Value
sender present
-- same as in ir
recipient CA name
-- the name of the CA who was asked to produce a certificate
transactionID present
-- value from corresponding ir and ip messages
senderNonce present
-- 128 (pseudo-)random bits
recipNonce present
-- value from senderNonce in corresponding ip message
protectionAlg MSG_MAC_ALG
-- only MAC protection is allowed for this message. The
-- MAC is based on the initial authentication key shared
-- between the end entity and the CA.
senderKID referenceNum
-- the reference number that the CA has previously issued
-- to the end entity (together with the MACing key)
body certConf
-- see Section 5.3.18, "PKI Confirmation Content", for the
-- contents of the certConf fields.
-- Note: two CertStatus structures are required if both an
-- encryption and a signing certificate were sent.
protection present
-- bits calculated using MSG_MAC_ALG
Confirmation -- pkiconf
確認-PKICONF
Field Value
sender present
-- same as in ip
recipient present
-- sender name from certConf
transactionID present
-- value from certConf message
senderNonce present
-- 128 (pseudo-)random bits
recipNonce present
-- value from senderNonce from certConf message
protectionAlg MSG_MAC_ALG
-- only MAC protection is allowed for this message.
senderKID referenceNum
body pkiconf
protection present
-- bits calculated using MSG_MAC_ALG
An (initialized) end entity requests a certificate from a CA (for any reason). When the CA responds with a message containing a certificate, the end entity replies with a certificate confirmation. The CA replies with a pkiconf message to close the transaction. All messages are authenticated.
（初期化された）ENDエンティティは、CAから証明書を要求します（何らかの理由で）。CAが証明書を含むメッセージで応答すると、End Entityは証明書の確認で応答します。CAは、トランザクションを閉じるためにPKICONFメッセージで応答します。すべてのメッセージは認証されています。
The profile for this exchange is identical to that given in Appendix C.4, with the following exceptions:
この交換のプロファイルは、付録C.4に記載されているプロファイルと同じです。以下の例外を除きます。
* sender name SHOULD be present;
* 送信者名が存在する必要があります。
* protectionAlg of MSG_SIG_ALG MUST be supported (MSG_MAC_ALG MAY also be supported) in request, response, certConf, and pkiconf messages;
* Request、Response、certConf、およびPKICONFメッセージで、MSG_SIG_ALGのPrittionalGをサポートする必要があります（MSG_MAC_ALGもサポートされる場合があります）。
* senderKID and recipKID are only present if required for message verification;
* SenderKidとRecipkidは、メッセージの確認に必要な場合にのみ存在します。
* body is cr or cp;
* ボディはCRまたはCPです。
* body may contain one or two CertReqMsg structures, but either CertReqMsg may be used to request certification of a locally generated public key or a centrally generated public key (i.e., the position-dependence requirement of Appendix C.4 is removed); and
* ボディには1つまたは2つのcertreqmsg構造が含まれる場合がありますが、CertreqMSGを使用して、ローカルに生成された公開キーまたは中央生成された公開キーの認証を要求する場合があります（つまり、付録C.4の位置依存要件が削除されます）。そして
* protection bits are calculated according to the protectionAlg field.
* 保護ビットは、保護分野に従って計算されます。
An (initialized) end entity requests a certificate from a CA (to update the key pair and/or corresponding certificate that it already possesses). When the CA responds with a message containing a certificate, the end entity replies with a certificate confirmation. The CA replies with a PKIConfirm to close the transaction. All messages are authenticated.
（初期化された）ENDエンティティは、CAから証明書を要求します（すでに所有しているキーペアおよび/または対応する証明書を更新するため）。CAが証明書を含むメッセージで応答すると、End Entityは証明書の確認で応答します。CAは、トランザクションを閉じるためにpkiconfirmで応答します。すべてのメッセージは認証されています。
The profile for this exchange is identical to that given in Appendix C.4, with the following exceptions:
この交換のプロファイルは、付録C.4に記載されているプロファイルと同じです。以下の例外を除きます。
* sender name SHOULD be present;
* 送信者名が存在する必要があります。
* protectionAlg of MSG_SIG_ALG MUST be supported (MSG_MAC_ALG MAY also be supported) in request, response, certConfirm, and PKIConfirm messages;
* Request、Response、CertConfirm、およびPKICONFIRMメッセージで、MSG_SIG_ALGのProtectionalgをサポートする必要があります（MSG_MAC_ALGもサポートされる場合があります）。
* senderKID and recipKID are only present if required for message verification;
* SenderKidとRecipkidは、メッセージの確認に必要な場合にのみ存在します。
* body is kur or kup;
* 体はkurまたはkupです。
* body may contain one or two CertReqMsg structures, but either CertReqMsg may be used to request certification of a locally generated public key or a centrally generated public key (i.e.,the position-dependence requirement of Appendix C.4 is removed);
* ボディには1つまたは2つのcertreqmsg構造が含まれる場合がありますが、CertreqMSGを使用して、ローカルに生成された公開キーまたは中央生成された公開キーの認証を要求する場合があります（つまり、付録C.4の位置依存要件が削除されます）。
* protection bits are calculated according to the protectionAlg field; and
* 保護ビットは、保護分野に従って計算されます。そして
* regCtrl OldCertId SHOULD be used (unless it is clear to both the sender and receiver -- by means not specified in this document -- that it is not needed).
* regctrl oldcertidを使用する必要があります（このドキュメントでは指定されていないことで、送信者と受信機の両方に明確でない限り、それが必要ではないことを）。
This appendix contains detailed profiles for those PKIMessages that MAY be supported by implementations.
この付録には、実装によってサポートされる可能性のあるこれらのpkimessageの詳細なプロファイルが含まれています。
Profiles for the PKIMessages used in the following PKI management operations are provided:
次のPKI管理操作で使用されるPKIMESSAGEのプロファイルが提供されます。
* root CA key update
* ルートCAキーアップデート
* information request/response
* 情報リクエスト/応答
* cross-certification request/response (1-way)
* 相互認証要求/応答（1ウェイ）
* in-band initialization using external identity certificate
* 外部ID証明書を使用したバンドの初期化
Future versions of this document may extend the above to include profiles for the operations listed below (along with other operations, if desired).
このドキュメントの将来のバージョンは、上記を拡張して、以下にリストされている操作のプロファイルを含める場合があります（必要に応じて、他の操作とともに）。
* revocation request
* 取り消しリクエスト
* certificate publication
* 証明書の出版物
* CRL publication
* CRL出版物
Identical to Appendix C.1.
付録C.1と同一。
Identical to Appendix C.2.
付録C.2と同一。
The table below is a profile of how a certificate structure may be "self-signed". These structures are used for distribution of new root CA public keys. This can occur in one of three ways (see Section 4.4 above for a description of the use of these structures):
以下の表は、証明書構造が「自己署名」される方法のプロファイルです。これらの構造は、新しいルートCAパブリックキーの分布に使用されます。これは、3つの方法のいずれかで発生する可能性があります（これらの構造の使用の説明については、上記のセクション4.4を参照してください）：
+============+=============================================+
| Type | Function |
+============+=============================================+
| newWithNew | a "self-signed" certificate; the contained |
| | public key MUST be usable to verify the |
| | signature (though this provides only |
| | integrity and no authentication whatsoever) |
+------------+---------------------------------------------+
| oldWithNew | previous root CA public key signed with new |
| | private key |
+------------+---------------------------------------------+
| newWithOld | new root CA public key signed with previous |
| | private key |
+------------+---------------------------------------------+
Table 3
A newWithNew certificate (including relevant extensions) must contain "sensible" values for all fields. For example, when present, subjectAltName MUST be identical to issuerAltName, and, when present, keyIdentifiers must contain appropriate values, et cetera.
NewWithNew証明書（関連する拡張機能を含む）には、すべてのフィールドに「賢明な」値を含める必要があります。たとえば、存在する場合、subjectaltnameはIssueraltnameと同一である必要があり、存在する場合、keyidentifiersには適切な値などが含まれている必要があります。
A root CA updates its key pair. It then produces a CA key update announcement message that can be made available (via some transport mechanism) to the relevant entities. A confirmation message is not required from the end entities.
ルートCAはキーペアを更新します。次に、関連するエンティティに（何らかの輸送メカニズムを介して）利用可能にすることができるCAキーアップデートアナウンスメッセージを作成します。最終エンティティからは確認メッセージは必要ありません。
ckuann message:
ckuannメッセージ：
+============+================================+=====================+
| Field | Value | Comment |
+============+================================+=====================+
| sender | CA name CA name | |
+------------+--------------------------------+---------------------+
| body | ckuann(RootCaKeyUpdateContent) | |
+------------+--------------------------------+---------------------+
| newWithNew | optionally present | see Appendix D.3 |
| | | above |
+------------+--------------------------------+---------------------+
| newWithOld | optionally present | see Appendix D.3 |
| | | above |
+------------+--------------------------------+---------------------+
| oldWithNew | optionally present | see Appendix D.3 |
| | | above |
+------------+--------------------------------+---------------------+
| extraCerts | optionally present | can be used to |
| | | "publish" |
| | | certificates |
| | | (e.g., |
| | | certificates |
| | | signed using the |
| | | new private key) |
+------------+--------------------------------+---------------------+
Table 4
The end entity sends a general message to the PKI requesting details that will be required for later PKI management operations. The RA/CA responds with a general response. If an RA generates the response, then it will simply forward the equivalent message that it previously received from the CA, with the possible addition of certificates to the extraCerts fields of the PKIMessage. A confirmation message is not required from the end entity.
End Entityは、後のPKI管理操作に必要な詳細を要求するPKIに一般的なメッセージを送信します。RA/CAは、一般的な応答で応答します。RAが応答を生成する場合、PKIMESSAGEのエクストラメッツフィールドに証明書を追加する可能性がある場合、CAから以前に受け取った同等のメッセージを単純に転送します。最終エンティティからは確認メッセージは必要ありません。
Message Flows:
メッセージの流れ：
Step# End entity PKI
---------------------------------------------------------------------
1 format genm
2 --> genm -->
3 handle genm
4 produce genp
5 <-- genp <--
6 handle genp
genM:
Genm：
Field Value
recipient CA name
-- the name of the CA as contained in issuerAltName
-- extensions or issuer fields within certificates
protectionAlg MSG_MAC_ALG or MSG_SIG_ALG
-- any authenticated protection alg.
SenderKID present if required
-- must be present if required for verification of message
-- protection
freeText any valid value
body genr (GenReqContent)
GenMsgContent empty SEQUENCE
-- all relevant information requested
protection present
-- bits calculated using MSG_MAC_ALG or MSG_SIG_ALG
genP:
Genp：
Field Value
sender CA name
-- name of the CA that produced the message
protectionAlg MSG_MAC_ALG or MSG_SIG_ALG
-- any authenticated protection alg.
senderKID present if required
-- must be present if required for verification of message
-- protection
body genp (GenRepContent)
CAProtEncCert present (object identifier one
of PROT_ENC_ALG), with relevant
value
-- to be used if end entity needs to encrypt information for
-- the CA (e.g., private key for recovery purposes)
SignKeyPairTypes present, with relevant value
-- the set of signature algorithm identifiers that this CA will
-- certify for subject public keys
EncKeyPairTypes present, with relevant value
-- the set of encryption / key agreement algorithm identifiers that
-- this CA will certify for subject public keys
PreferredSymmAlg present (object identifier one
of PROT_SYM_ALG) , with relevant
value
-- the symmetric algorithm that this CA expects to be used
-- in later PKI messages (for encryption)
RootCaKeyUpdate optionally present, with
relevant value
-- Use RootCaKeyUpdate; if backward compatibility with cmp2000 is
-- required, use CAKeyUpdateInfo.
-- The CA MAY provide information about a relevant root CA
-- key pair using this field (note that this does not imply
-- that the responding CA is the root CA in question)
CurrentCRL optionally present, with relevant value
-- the CA MAY provide a copy of a complete CRL (i.e.,
-- fullest possible one)
protection present
-- bits calculated using MSG_MAC_ALG or MSG_SIG_ALG
extraCerts optionally present
-- can be used to send some certificates to the end
-- entity. An RA MAY add its certificate here.
This section describes the creation of a single cross-certificate (i.e., not two at once). The requesting CA MAY choose who is responsible for publication of the cross-certificate created by the responding CA through use of the PKIPublicationInfo control.
このセクションでは、単一のクロス認証の作成について説明します（つまり、一度に2つではありません）。要求するCAは、PKIPUblicationInfoコントロールの使用を通じて、応答するCAによって作成されたクロス認証の公開に誰が責任を負うかを選択できます。
Preconditions:
前提条件：
1. Responding CA can verify the origin of the request (possibly requiring out-of-band means) before processing the request.
1. CAの応答は、リクエストを処理する前に、リクエストの原点（おそらく帯域外の手段が必要）を検証できます。
2. Requesting CA can authenticate the authenticity of the origin of the response (possibly requiring out-of-band means) before processing the response.
2. CAを要求することで、応答を処理する前に、応答の起源（おそらく帯域外の手段が必要）の信頼性を認証できます。
The use of certificate confirmation and the corresponding server confirmation is determined by the generalInfo field in the PKIHeader (see Section 5.1.1). The following profile does not mandate support for either confirmation.
証明書の確認と対応するサーバーの確認の使用は、PKIHeaderのGeneralINFOフィールドによって決定されます（セクション5.1.1を参照）。次のプロファイルは、どちらの確認もサポートを義務付けていません。
Message Flows:
メッセージの流れ：
Step# Requesting CA Responding CA
---------------------------------------------------------------------
1 format ccr
2 --> ccr -->
3 handle ccr
4 produce ccp
5 <-- ccp <--
6 handle ccp
ccr:
ccr:
Field Value
sender Requesting CA name
-- the name of the CA who produced the message
recipient Responding CA name
-- the name of the CA who is being asked to produce a certificate
messageTime time of production of message
-- current time at requesting CA
protectionAlg MSG_SIG_ALG
-- only signature protection is allowed for this request
senderKID present if required
-- must be present if required for verification of message
-- protection
recipKID present if required
-- must be present if required for verification of message
-- protection
transactionID present
-- implementation-specific value, meaningful to requesting CA.
-- [If already in use at responding CA, then a rejection message
-- MUST be produced by responding CA]
senderNonce present
-- 128 (pseudo-)random bits
freeText any valid value
body ccr (CertReqMessages)
only one CertReqMsg
allowed
-- if multiple cross-certificates are required, they MUST be
-- packaged in separate PKIMessages
certTemplate present
-- details follow
version v1 or v3
-- v3 STRONGLY RECOMMENDED
signingAlg present
-- the requesting CA must know in advance with which algorithm it
-- wishes the certificate to be signed
subject present
-- may be NULL-DN only if subjectAltNames extension value proposed
validity present
-- MUST be completely specified (i.e., both fields present)
issuer present
-- may be NULL-DN only if issuerAltNames extension value proposed
publicKey present
-- the key to be certified (which must be for a signing algorithm)
extensions optionally present
-- a requesting CA must propose values for all extensions
-- that it requires to be in the cross-certificate
POPOSigningKey present
-- see Appendix C.3: POP Profile
protection present
-- bits calculated using MSG_SIG_ALG
extraCerts optionally present
-- MAY contain any additional certificates that requester wishes
-- to include
ccp:
ccp:
Field Value
sender Responding CA name
-- the name of the CA who produced the message
recipient Requesting CA name
-- the name of the CA who asked for production of a certificate
messageTime time of production of message
-- current time at responding CA
protectionAlg MSG_SIG_ALG
-- only signature protection is allowed for this message
senderKID present if required
-- must be present if required for verification of message
-- protection
recipKID present if required
transactionID present
-- value from corresponding ccr message
senderNonce present
-- 128 (pseudo-)random bits
recipNonce present
-- senderNonce from corresponding ccr message
freeText any valid value
body ccp (CertRepMessage)
only one CertResponse allowed
-- if multiple cross-certificates are required, they MUST be
-- packaged in separate PKIMessages
response present
status present
PKIStatusInfo.status present
-- if PKIStatusInfo.status is one of:
-- accepted, or
-- grantedWithMods,
-- then certifiedKeyPair MUST be present and failInfo MUST
-- be absent
failInfo present depending on
PKIStatusInfo.status
-- if PKIStatusInfo.status is:
-- rejection,
-- then certifiedKeyPair MUST be absent and failInfo MUST be
-- present and contain appropriate bit settings
certifiedKeyPair present depending on
PKIStatusInfo.status
certificate present depending on
certifiedKeyPair
-- content of actual certificate must be examined by requesting CA
-- before publication
protection present
-- bits calculated using MSG_SIG_ALG
extraCerts optionally present
-- MAY contain any additional certificates that responder wishes
-- to include
An (uninitialized) end entity wishes to initialize into the PKI with a CA, CA-1. It uses, for authentication purposes, a pre-existing identity certificate issued by another (external) CA, CA-X. A trust relationship must already have been established between CA-1 and CA-X so that CA-1 can validate the end entity identity certificate signed by CA-X. Furthermore, some mechanism must already have been established within the TEE, also known as PSE, of the end entity that would allow it to authenticate and verify PKIMessages signed by CA-1 (as one example, the TEE may contain a certificate issued for the public key of CA-1, signed by another CA that the end entity trusts on the basis of out-of-band authentication techniques).
（非初期化されていない）エンティティは、CA、CA-1を使用してPKIに初期化したいと考えています。認証のために、別の（外部）CA、CA-Xによって発行された既存のID証明書を使用します。CA-1がCA-Xが署名した最終エンティティID証明書を検証できるように、CA-1とCA-Xの間に信頼関係がすでに確立されている必要があります。さらに、いくつかのメカニズムは、PSEとしても知られているティー内ですでに確立されている必要があります。これにより、CA-1が署名したpkimessageを認証および検証できるようにします（1つの例として、TEEには、帯域存在の認証技術に基づいて最終エンティティが信頼する別のCAが署名したCA-1の公開鍵について発行された証明書が含まれている場合があります）。
The end entity sends an initialization request to start the transaction. When CA-1 responds with a message containing the new certificate, the end entity replies with a certificate confirmation. CA-1 replies with a pkiconf message to close the transaction. All messages are signed (the end entity messages are signed using the private key that corresponds to the public key in its external identity certificate; the CA-1 messages are signed using the private key that corresponds to the public key in a certificate that can be chained to a trust anchor in the end entity's TEE).
End Entityは、トランザクションを開始するための初期化リクエストを送信します。CA-1が新しい証明書を含むメッセージで応答すると、End Entityは証明書確認で応答します。CA-1は、PKICONFメッセージで返信して、トランザクションを閉じます。すべてのメッセージに署名されます（End Entityメッセージは、外部ID証明書の公開キーに対応する秘密鍵を使用して署名されます。CA-1メッセージは、End EntityのTシャツの信頼アンカーにチェーンできる公開キーに対応する秘密鍵を使用して署名されます）。
The profile for this exchange is identical to that given in Appendix C.4, with the following exceptions:
この交換のプロファイルは、付録C.4に記載されているプロファイルと同じです。以下の例外を除きます。
* the end entity and CA-1 do not share a symmetric MACing key (i.e., there is no out-of-band shared secret information between these entities);
* End EntityとCA-1は、対称的なマッキングキーを共有していません（つまり、これらのエンティティ間にバンド外の共有秘密情報はありません）。
* sender name in ir MUST be present (and identical to the subject name present in the external identity certificate);
* IRの送信者名は存在する必要があります（および外部ID証明書に存在する件名と同じ）。
* protectionAlg of MSG_SIG_ALG MUST be used in all messages;
* MSG_SIG_ALGのProtectionalgは、すべてのメッセージで使用する必要があります。
* external identity certificate MUST be carried in ir extraCerts field
* 外部ID証明書は、IRエクストラメートフィールドに携帯する必要があります
* senderKID and recipKID are not used;
* SenderKidとRecipkidは使用されていません。
* body is ir or ip; and
* ボディはIRまたはIPです。そして
* protection bits are calculated according to the protectionAlg field.
* 保護ビットは、保護分野に従って計算されます。
As described in Section 5.1.3.4, any party in a PKI management operation may wish to use a KEM key pair for message protection. Possible cases are described below.
セクション5.1.3.4で説明されているように、PKI管理操作の当事者は、メッセージ保護のためにKEMキーペアを使用することを望む場合があります。可能なケースを以下に説明します。
For any PKI management operation started by a PKI entity with any type of request message, the following message flows describe the use of a KEM key. There are two cases to distinguish, namely whether the PKI entity or the PKI management entity owns a KEM key pair. If both sides own KEM key pairs, the flows need to be combined such that for each direction a shared secret key is established.
あらゆるタイプのリクエストメッセージを持つPKIエンティティによって開始されたPKI管理操作については、次のメッセージフローがKEMキーの使用を説明しています。区別する2つのケースがあります。つまり、PKIエンティティまたはPKI管理エンティティがKEMキーペアを所有しているかどうかです。両側がKEMキーペアを所有している場合、各方向に共有された秘密の鍵が確立されるように、フローを組み合わせる必要があります。
In the following message flows, Alice indicates the PKI entity that uses a KEM key pair for message authentication and Bob provides the KEM ciphertext using Alice's public KEM key, as described in Section 5.1.3.4.
次のメッセージフローで、アリスはメッセージ認証にKEMキーペアを使用するPKIエンティティを示し、Bobはセクション5.1.3.4で説明されているように、AliceのパブリックKEMキーを使用してKEM Ciphertextを提供します。
Step# PKI entity PKI management entity
(Alice) (Bob)
---------------------------------------------------------------------
1 format unprotected genm
of type
KemCiphertextInfo
without value, and
KEM certificate in
extraCerts
2 --> genm -->
3 validate KEM certificate
4 perform KEM Encapsulate
5 format unprotected genp
of type
KemCiphertextInfo
providing KEM ciphertext
6 <-- genp <--
7 perform KEM Decapsulate
8 perform key derivation
to get ssk
9 format request with
MAC-based protection
10 --> request -->
11 perform key derivation
to get ssk
12 verify MAC-based
protection
-------- PKI entity authenticated by PKI management entity --------
13 format response with
protection depending on
available key material
14 <-- response <--
15 verify protection
provided by the
PKI management entity
16 Further messages of this PKI management operation
can be exchanged with MAC-based protection by the PKI
entity using the established shared secret key (ssk)
Figure 3: Message Flow When the PKI Entity Has a KEM Key Pair and Certificate
図3：PKIエンティティにKEMキーペアと証明書があるときのメッセージフロー
Step# PKI entity PKI management entity
(Bob) (Alice)
---------------------------------------------------------------------
1 perform KEM Encapsulate
2 format request providing
KEM ciphertext in
generalInfo of type
KemCiphertextInfo,
and with protection
depending on available
key material
3 --> request -->
4 perform KEM Decapsulate
5 perform key derivation
to get ssk
6 format response with
MAC-based protection
7 <-- response <--
8 perform key derivation
to get ssk
9 verify MAC-based
protection
-------- PKI management entity authenticated by PKI entity --------
10 Further messages of this PKI management operation
can be exchanged with MAC-based protection by the
PKI management entity using the established
shared secret key (ssk)
Figure 4: Message Flow When the PKI Entity Knows That the PKI Management Entity Uses a KEM Key Pair and Has the Authentic Public Key
図4：メッセージフローPKIエンティティがPKI管理エンティティがKEMキーペアを使用し、本物の公開キーを持っていることを知っているとき
Note: Figure 4 describes the situation where KEM-based message protection may not require more than one message exchange. In this case, the transactionID MUST also be used by the PKI entity (Bob) to ensure domain separation between different PKI management operations.
注：図4は、KEMベースのメッセージ保護が複数のメッセージ交換を必要としない状況を説明しています。この場合、TransactionIDは、PKIエンティティ（BOB）によっても使用され、異なるPKI管理操作間のドメイン分離を確保する必要があります。
Step# PKI entity PKI management entity
(Bob) (Alice)
---------------------------------------------------------------------
1 format request with
protection depending
on available key
material
2 --> request -->
3 format unprotected error
with status "rejection"
and failInfo
"wrongIntegrity" and KEM
certificate in
extraCerts
4 <-- error <--
5 validate KEM certificate
6 proceed as shown in the figure before
Figure 5: Message Flow When the PKI Entity Does Not Know That the PKI Management Entity Uses a KEM Key Pair
図5：PKIエンティティがPKI管理エンティティがKEMキーペアを使用していることがわからない場合のメッセージフロー
This section contains the updated 2002 ASN.1 module from [RFC5912], which was updated in [RFC9480]. This module replaces the module in Section 9 of [RFC5912]. The module contains those changes to the normative ASN.1 module from Appendix F of [RFC4210] that were specified in [RFC9480], as well as changes made in this document. This module makes reference to ASN.1 structures defined in [RFC6268], as well as the UTF-8 encoding defined in [RFC3629].
このセクションには、[RFC9480]で更新された[RFC5912]の更新された2002 ASN.1モジュールが含まれています。このモジュールは、[RFC5912]のセクション9のモジュールを置き換えます。このモジュールには、[RFC9480]で指定された[RFC4210]の付録Fからの規範ASN.1モジュールの変更と、このドキュメントで行われた変更が含まれています。このモジュールは、[RFC6268]で定義されているASN.1構造と、[RFC3629]で定義されているUTF-8エンコードを参照します。
PKIXCMP-2023
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-cmp2023-02(116) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
IMPORTS
AttributeSet{}, SingleAttribute{}, Extensions{}, EXTENSION, ATTRIBUTE
FROM PKIX-CommonTypes-2009
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)}
AlgorithmIdentifier{}, SIGNATURE-ALGORITHM, ALGORITHM,
DIGEST-ALGORITHM, MAC-ALGORITHM, KEY-DERIVATION
FROM AlgorithmInformation-2009
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58)}
Certificate, CertificateList, Time, id-kp
FROM PKIX1Explicit-2009
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)}
DistributionPointName, GeneralNames, GeneralName, KeyIdentifier
FROM PKIX1Implicit-2009
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)}
CertTemplate, PKIPublicationInfo, EncryptedKey, CertId,
CertReqMessages, Controls, RegControlSet, id-regCtrl
FROM PKIXCRMF-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-crmf2005-02(55) }
-- The import of EncryptedKey is added due to the updates made
-- in [RFC9480]. EncryptedValue does not need to be imported
-- anymore and is therefore removed here.
CertificationRequest
FROM PKCS-10
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkcs10-2009(69)}
-- (specified in [RFC2986] with 1993 ASN.1 syntax and IMPLICIT
-- tags). Alternatively, implementers may directly include
-- the syntax of [RFC2986] in this module.
localKeyId
FROM PKCS-9
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
modules(0) pkcs-9(1)}
-- The import of localKeyId is added due to the updates made in
-- [RFC9480]
EnvelopedData, SignedData
FROM CryptographicMessageSyntax-2010
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cms-2009(58)}
-- The import of EnvelopedData and SignedData from [RFC6268] is
-- added due to the updates made in CMP Updates [RFC9480]
KEM-ALGORITHM
FROM KEMAlgorithmInformation-2023 -- [RFC9629]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-kemAlgorithmInformation-2023(109) }
-- The import of KEM-ALGORITHM was added due to the updates made
-- in [RFC9810]
;
-- History of the PKIXCMP ASN.1 modules
-- [RFC2510]
-- 1988 Syntax, PKIXCMP, 1.3.6.1.5.5.7.0.9 (id-mod-cmp)
-- Obsoleted by RFC 4210 PKIXCMP, 1.3.6.1.5.5.7.0.16
-- (id-mod-cmp2000)
-- [RFC4210]
-- 1988 Syntax, PKIXCMP, 1.3.6.1.5.5.7.0.16 (id-mod-cmp2000)
-- Replaced by RFC 9480 PKIXCMP, 1.3.6.1.5.5.7.0.99
-- (id-mod-cmp2021-88)
-- [RFC5912]
-- 2002 Syntax, PKIXCMP-2009, 1.3.6.1.5.5.7.0.50
-- (id-mod-cmp2000-02)
-- Replaced by RFC 9480 PKIXCMP-2021, 1.3.6.1.5.5.7.0.100
-- (id-mod-cmp2021-02)
-- [RFC9480]
-- 1988 Syntax, PKIXCMP, 1.3.6.1.5.5.7.0.99 (id-mod-cmp2021-88)
-- 2002 Syntax, PKIXCMP-2021, 1.3.6.1.5.5.7.0.100
-- (id-mod-cmp2021-02)
-- Obsoleted by [RFC9810] PKIXCMP-2023, 1.3.6.1.5.5.7.0.116
-- (id-mod-cmp2023-02)
-- [RFC9810]
-- 2002 Syntax, PKIXCMP-2023, 1.3.6.1.5.5.7.0.116
-- (id-mod-cmp2023-02)
-- The rest of the module contains locally defined OIDs and
-- constructs:
CMPCertificate ::= CHOICE { x509v3PKCert Certificate, ... }
-- This syntax, while bits-on-the-wire compatible with the
-- standard X.509 definition of "Certificate", allows the
-- possibility of future certificate types (such as X.509
-- attribute certificates, card-verifiable certificates, or other
-- kinds of certificates) within this Certificate Management
-- Protocol, should a need ever arise to support such generality.
-- Those implementations that do not foresee a need to ever support
-- other certificate types MAY, if they wish, comment out the
-- above structure and "uncomment" the following one prior to
-- compiling this ASN.1 module. (Note that interoperability
-- with implementations that don't do this will be unaffected by
-- this change.)
-- CMPCertificate ::= Certificate
PKIMessage ::= SEQUENCE {
header PKIHeader,
body PKIBody,
protection [0] PKIProtection OPTIONAL,
extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate
OPTIONAL }
PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage
PKIHeader ::= SEQUENCE {
pvno INTEGER { cmp1999(1), cmp2000(2),
cmp2021(3) },
sender GeneralName,
-- identifies the sender
recipient GeneralName,
-- identifies the intended recipient
messageTime [0] GeneralizedTime OPTIONAL,
-- time of production of this message (used when sender
-- believes that the transport will be "suitable", i.e.,
-- that the time will still be meaningful upon receipt)
protectionAlg [1] AlgorithmIdentifier{ALGORITHM, {...}}
OPTIONAL,
-- algorithm used for calculation of protection bits
senderKID [2] KeyIdentifier OPTIONAL,
recipKID [3] KeyIdentifier OPTIONAL,
-- to identify specific keys used for protection
transactionID [4] OCTET STRING OPTIONAL,
-- identifies the transaction, i.e., this will be the same in
-- corresponding request, response, certConf, and pkiconf
-- messages
senderNonce [5] OCTET STRING OPTIONAL,
recipNonce [6] OCTET STRING OPTIONAL,
-- nonces used to provide replay protection, senderNonce
-- is inserted by the creator of this message; recipNonce
-- is a nonce previously inserted in a related message by
-- the intended recipient of this message.
freeText [7] PKIFreeText OPTIONAL,
-- this may be used to indicate context-specific instructions
-- (this field is intended for human consumption)
generalInfo [8] SEQUENCE SIZE (1..MAX) OF
InfoTypeAndValue OPTIONAL
-- this may be used to convey context-specific information
-- (this field is not primarily intended for human consumption)
}
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
-- text encoded as UTF-8 string [RFC3629]
PKIBody ::= CHOICE { -- message-specific body elements
ir [0] CertReqMessages, --Initialization Request
ip [1] CertRepMessage, --Initialization Response
cr [2] CertReqMessages, --Certification Request
cp [3] CertRepMessage, --Certification Response
p10cr [4] CertificationRequest, --imported from [RFC2986]
popdecc [5] POPODecKeyChallContent, --pop Challenge
popdecr [6] POPODecKeyRespContent, --pop Response
kur [7] CertReqMessages, --Key Update Request
kup [8] CertRepMessage, --Key Update Response
krr [9] CertReqMessages, --Key Recovery Request
krp [10] KeyRecRepContent, --Key Recovery Response
rr [11] RevReqContent, --Revocation Request
rp [12] RevRepContent, --Revocation Response
ccr [13] CertReqMessages, --Cross-Cert. Request
ccp [14] CertRepMessage, --Cross-Cert. Response
ckuann [15] CAKeyUpdContent, --CA Key Update Ann.
cann [16] CertAnnContent, --Certificate Ann.
rann [17] RevAnnContent, --Revocation Ann.
crlann [18] CRLAnnContent, --CRL Announcement
pkiconf [19] PKIConfirmContent, --Confirmation
nested [20] NestedMessageContent, --Nested Message
genm [21] GenMsgContent, --General Message
genp [22] GenRepContent, --General Response
error [23] ErrorMsgContent, --Error Message
certConf [24] CertConfirmContent, --Certificate Confirm
pollReq [25] PollReqContent, --Polling Request
pollRep [26] PollRepContent --Polling Response
}
PKIProtection ::= BIT STRING
ProtectedPart ::= SEQUENCE {
header PKIHeader,
body PKIBody }
id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2)
usa(840) nt(113533) nsn(7) algorithms(66) 13 }
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
-- Note: Implementations MAY wish to limit acceptable sizes
-- of this string to values appropriate for their environment
-- in order to reduce the risk of denial-of-service attacks.
owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}},
-- AlgId for the OWF
iterationCount INTEGER,
-- number of times the OWF is applied
-- Note: Implementations MAY wish to limit acceptable sizes
-- of this integer to values appropriate for their environment
-- in order to reduce the risk of denial-of-service attacks.
mac AlgorithmIdentifier{MAC-ALGORITHM, {...}}
-- AlgId of the MAC algorithm
}
id-DHBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2)
usa(840) nt(113533) nsn(7) algorithms(66) 30 }
DHBMParameter ::= SEQUENCE {
owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}},
-- AlgId for an OWF
mac AlgorithmIdentifier{MAC-ALGORITHM, {...}}
-- AlgId of the MAC algorithm
}
-- id-KemBasedMac and KemBMParameter were added in [RFC9810]
id-KemBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2)
usa(840) nt(113533) nsn(7) algorithms(66) 16 }
KemBMParameter ::= SEQUENCE {
kdf AlgorithmIdentifier{KEY-DERIVATION, {...}},
-- AlgId of the Key Derivation Function algorithm
kemContext [0] OCTET STRING OPTIONAL,
-- MAY contain additional algorithm-specific context information
len INTEGER (1..MAX),
-- Defines the length of the keying material output of the KDF
-- SHOULD be the maximum key length of the MAC function
mac AlgorithmIdentifier{MAC-ALGORITHM, {...}}
-- AlgId of the MAC algorithm
}
PKIStatus ::= INTEGER {
accepted (0),
-- you got exactly what you asked for
grantedWithMods (1),
-- you got something like what you asked for; the
-- requester is responsible for ascertaining the differences
rejection (2),
-- you don't get it, more information elsewhere in the message
waiting (3),
-- the request body part has not yet been processed; expect to
-- hear more later (note: proper handling of this status
-- response MAY use the polling req/rep PKIMessages specified
-- in Section 5.3.22; alternatively, polling in the underlying
-- transport layer MAY have some utility in this regard)
revocationWarning (4),
-- this message contains a warning that a revocation is
-- imminent
revocationNotification (5),
-- notification that a revocation has occurred
keyUpdateWarning (6)
-- update already done for the oldCertId specified in
-- CertReqMsg
}
PKIFailureInfo ::= BIT STRING {
-- since we can fail in more than one way!
-- More codes may be added in the future if/when required.
badAlg (0),
-- unrecognized or unsupported algorithm identifier
badMessageCheck (1),
-- integrity check failed (e.g., signature did not verify)
badRequest (2),
-- transaction not permitted or supported
badTime (3),
-- messageTime was not sufficiently close to the system time,
-- as defined by local policy
badCertId (4),
-- no certificate could be found matching the provided criteria
badDataFormat (5),
-- the data submitted has the wrong format
wrongAuthority (6),
-- the authority indicated in the request is different from the
-- one creating the response token
incorrectData (7),
-- the requester's data is incorrect (for notary services)
missingTimeStamp (8),
-- when the timestamp is missing but should be there
-- (by policy)
badPOP (9),
-- the POP failed
certRevoked (10),
-- the certificate has already been revoked
certConfirmed (11),
-- the certificate has already been confirmed
wrongIntegrity (12),
-- KEM ciphertext missing for MAC-based protection of response,
-- or not valid integrity of message received (password based
-- instead of signature or vice versa)
badRecipientNonce (13),
-- not valid recipient nonce, either missing or wrong value
timeNotAvailable (14),
-- the TSA's time source is not available
unacceptedPolicy (15),
-- the requested TSA policy is not supported by the TSA
unacceptedExtension (16),
-- the requested extension is not supported by the TSA
addInfoNotAvailable (17),
-- the additional information requested could not be
-- understood or is not available
badSenderNonce (18),
-- not valid sender nonce, either missing or wrong size
badCertTemplate (19),
-- not valid cert. template or missing mandatory information
signerNotTrusted (20),
-- signer of the message unknown or not trusted
transactionIdInUse (21),
-- the transaction identifier is already in use
unsupportedVersion (22),
-- the version of the message is not supported
notAuthorized (23),
-- the sender was not authorized to make the preceding
-- request or perform the preceding action
systemUnavail (24),
-- the request cannot be handled due to system unavailability
systemFailure (25),
-- the request cannot be handled due to system failure
duplicateCertReq (26)
-- certificate cannot be issued because a duplicate
-- certificate already exists
}
PKIStatusInfo ::= SEQUENCE {
status PKIStatus,
statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL }
OOBCert ::= CMPCertificate
OOBCertHash ::= SEQUENCE {
hashAlg [0] AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}
OPTIONAL,
certId [1] CertId OPTIONAL,
hashVal BIT STRING
-- hashVal is calculated over the DER encoding of the
-- self-signed certificate with the identifier certID.
}
POPODecKeyChallContent ::= SEQUENCE OF Challenge
-- One Challenge per encryption or key agreement key certification
-- request (in the same order as these requests appear in
-- CertReqMessages).
-- encryptedRand was added in [RFC9810]
Challenge ::= SEQUENCE {
owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}
OPTIONAL,
-- MUST be present in the first Challenge; MAY be omitted in
-- any subsequent Challenge in POPODecKeyChallContent (if
-- omitted, then the owf used in the immediately preceding
-- Challenge is to be used).
witness OCTET STRING,
-- the result of applying the OWF to a
-- randomly generated INTEGER, A. (Note that a different
-- INTEGER MUST be used for each Challenge.)
challenge OCTET STRING,
-- MUST be used for cmp2000(2) popdecc messages and MUST be
-- the encryption of Rand (using a mechanism depending on the
-- private key type).
-- MUST be an empty OCTET STRING for cmp2021(3) popdecc messages.
-- Note: Using challenge omitting the optional encryptedRand is
-- bit-compatible to the syntax without adding this optional
-- field.
encryptedRand [0] EnvelopedData OPTIONAL
-- MUST be omitted for cmp2000(2) popdecc messages.
-- MUST be used for cmp2021(3) popdecc messages and MUST contain
-- the encrypted value of Rand using CMS EnvelopedData using the
-- key management technique depending on the private key type as
-- defined in Section 5.2.2.
}
-- Rand was added in [RFC9480]
Rand ::= SEQUENCE {
-- Rand is encrypted involving the public key to form the content of
-- challenge or encryptedRand in POPODecKeyChallContent
int INTEGER,
-- the randomly generated INTEGER A (above)
sender GeneralName
-- the sender's name (as included in PKIHeader)
}
POPODecKeyRespContent ::= SEQUENCE OF INTEGER
-- One INTEGER per encryption or key agreement key certification
-- request (in the same order as these requests appear in
-- CertReqMessages). The retrieved INTEGER A (above) is returned to
-- the sender of the corresponding Challenge.
CertRepMessage ::= SEQUENCE {
caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate
OPTIONAL,
response SEQUENCE OF CertResponse }
CertResponse ::= SEQUENCE {
certReqId INTEGER,
-- to match this response with the corresponding request (a value
-- of -1 is to be used if certReqId is not specified in the
-- corresponding request, which can only be a p10cr)
status PKIStatusInfo,
certifiedKeyPair CertifiedKeyPair OPTIONAL,
rspInfo OCTET STRING OPTIONAL
-- analogous to the id-regInfo-utf8Pairs string defined
-- for regInfo in CertReqMsg [RFC4211]
}
CertifiedKeyPair ::= SEQUENCE {
certOrEncCert CertOrEncCert,
privateKey [0] EncryptedKey OPTIONAL,
-- See [RFC4211] for comments on encoding.
-- Changed from EncryptedValue to EncryptedKey as a CHOICE of
-- EncryptedValue and EnvelopedData due to the changes made in
-- [RFC9480].
-- Using the choice EncryptedValue is bit-compatible to the
-- syntax without this change.
publicationInfo [1] PKIPublicationInfo OPTIONAL }
CertOrEncCert ::= CHOICE {
certificate [0] CMPCertificate,
encryptedCert [1] EncryptedKey
-- Changed from Encrypted Value to EncryptedKey as a CHOICE of
-- EncryptedValue and EnvelopedData due to the changes made in
-- [RFC9480].
-- Using the choice EncryptedValue is bit-compatible to the
-- syntax without this change.
}
KeyRecRepContent ::= SEQUENCE {
status PKIStatusInfo,
newSigCert [0] CMPCertificate OPTIONAL,
caCerts [1] SEQUENCE SIZE (1..MAX) OF
CMPCertificate OPTIONAL,
keyPairHist [2] SEQUENCE SIZE (1..MAX) OF
CertifiedKeyPair OPTIONAL }
RevReqContent ::= SEQUENCE OF RevDetails
RevDetails ::= SEQUENCE {
certDetails CertTemplate,
-- allows requester to specify as much as they can about
-- the cert. for which revocation is requested
-- (e.g., for cases in which serialNumber is not available)
crlEntryDetails Extensions{{...}} OPTIONAL
-- requested crlEntryExtensions
}
RevRepContent ::= SEQUENCE {
status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo,
-- in same order as was sent in RevReqContent
revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL,
-- IDs for which revocation was requested
-- (same order as status)
crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL
-- the resulting CRLs (there may be more than one)
}
CAKeyUpdAnnContent ::= SEQUENCE {
oldWithNew CMPCertificate, -- old pub signed with new priv
newWithOld CMPCertificate, -- new pub signed with old priv
newWithNew CMPCertificate -- new pub signed with new priv
}
-- CAKeyUpdContent was added in [RFC9810]
CAKeyUpdContent ::= CHOICE {
cAKeyUpdAnnV2 CAKeyUpdAnnContent, -- deprecated
cAKeyUpdAnnV3 [0] RootCaKeyUpdateContent
}
-- With cmp2021, the use of CAKeyUpdAnnContent is deprecated, use
-- RootCaKeyUpdateContent instead.
CertAnnContent ::= CMPCertificate
RevAnnContent ::= SEQUENCE {
status PKIStatus,
certId CertId,
willBeRevokedAt GeneralizedTime,
badSinceDate GeneralizedTime,
crlDetails Extensions{{...}} OPTIONAL
-- extra CRL details (e.g., crl number, reason, location, etc.)
}
CRLAnnContent ::= SEQUENCE OF CertificateList
PKIConfirmContent ::= NULL
NestedMessageContent ::= PKIMessages
-- CertReqTemplateContent, AttributeTypeAndValue,
-- ExpandedRegControlSet, id-regCtrl-altCertTemplate,
-- AltCertTemplate, regCtrl-algId, id-regCtrl-algId, AlgIdCtrl,
-- regCtrl-rsaKeyLen, id-regCtrl-rsaKeyLen, and RsaKeyLenCtrl
-- were added in [RFC9480]
CertReqTemplateContent ::= SEQUENCE {
certTemplate CertTemplate,
-- prefilled certTemplate structure elements
-- The SubjectPublicKeyInfo field in the certTemplate MUST NOT
-- be used.
keySpec Controls OPTIONAL
-- MAY be used to specify supported algorithms
-- Controls ::= SEQUENCE SIZE (1..MAX) OF AttributeTypeAndValue
-- as specified in CRMF [RFC4211]
}
AttributeTypeAndValue ::= SingleAttribute{{ ... }}
ExpandedRegControlSet ATTRIBUTE ::= { RegControlSet |
regCtrl-altCertTemplate | regCtrl-algId | regCtrl-rsaKeyLen, ... }
regCtrl-altCertTemplate ATTRIBUTE ::=
{ TYPE AltCertTemplate IDENTIFIED BY id-regCtrl-altCertTemplate }
id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= { id-regCtrl 7 }
AltCertTemplate ::= AttributeTypeAndValue
-- specifies a template for a certificate other than an X.509v3
-- public key certificate
regCtrl-algId ATTRIBUTE ::=
{ TYPE AlgIdCtrl IDENTIFIED BY id-regCtrl-algId }
id-regCtrl-algId OBJECT IDENTIFIER ::= { id-regCtrl 11 }
AlgIdCtrl ::= AlgorithmIdentifier{ALGORITHM, {...}}
-- SHALL be used to specify supported algorithms other than RSA
regCtrl-rsaKeyLen ATTRIBUTE ::=
{ TYPE RsaKeyLenCtrl IDENTIFIED BY id-regCtrl-rsaKeyLen }
id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { id-regCtrl 12 }
RsaKeyLenCtrl ::= INTEGER (1..MAX)
-- SHALL be used to specify supported RSA key lengths
-- RootCaKeyUpdateContent, CRLSource, and CRLStatus were added in
-- [RFC9480]
RootCaKeyUpdateContent ::= SEQUENCE {
newWithNew CMPCertificate,
-- new root CA certificate
newWithOld [0] CMPCertificate OPTIONAL,
-- X.509 certificate containing the new public root CA key
-- signed with the old private root CA key
oldWithNew [1] CMPCertificate OPTIONAL
-- X.509 certificate containing the old public root CA key
-- signed with the new private root CA key
}
CRLSource ::= CHOICE {
dpn [0] DistributionPointName,
issuer [1] GeneralNames }
CRLStatus ::= SEQUENCE {
source CRLSource,
thisUpdate Time OPTIONAL }
-- KemCiphertextInfo and KemOtherInfo were added in [RFC9810]
KemCiphertextInfo ::= SEQUENCE {
kem AlgorithmIdentifier{KEM-ALGORITHM, {...}},
-- AlgId of the KEM algorithm
ct OCTET STRING
-- Ciphertext output from the Encapsulate function
}
KemOtherInfo ::= SEQUENCE {
staticString PKIFreeText,
-- MUST be "CMP-KEM"
transactionID OCTET STRING,
-- MUST contain the values from the message previously received
-- containing the ciphertext (ct) in KemCiphertextInfo
kemContext [0] OCTET STRING OPTIONAL
-- MAY contain additional algorithm-specific context information
}
INFO-TYPE-AND-VALUE ::= TYPE-IDENTIFIER
InfoTypeAndValue ::= SEQUENCE {
infoType INFO-TYPE-AND-VALUE.
&id({SupportedInfoSet}),
infoValue INFO-TYPE-AND-VALUE.
&Type({SupportedInfoSet}{@infoType}) }
SupportedInfoSet INFO-TYPE-AND-VALUE ::= { ... }
-- Example InfoTypeAndValue contents include, but are not limited
-- to, the following (uncomment in this ASN.1 module and use as
-- appropriate for a given environment):
--
-- id-it-caProtEncCert OBJECT IDENTIFIER ::= {id-it 1}
-- CAProtEncCertValue ::= CMPCertificate
-- id-it-signKeyPairTypes OBJECT IDENTIFIER ::= {id-it 2}
-- SignKeyPairTypesValue ::= SEQUENCE SIZE (1..MAX) OF
-- AlgorithmIdentifier{{...}}
-- id-it-encKeyPairTypes OBJECT IDENTIFIER ::= {id-it 3}
-- EncKeyPairTypesValue ::= SEQUENCE SIZE (1..MAX) OF
-- AlgorithmIdentifier{{...}}
-- id-it-preferredSymmAlg OBJECT IDENTIFIER ::= {id-it 4}
-- PreferredSymmAlgValue ::= AlgorithmIdentifier{{...}}
-- id-it-caKeyUpdateInfo OBJECT IDENTIFIER ::= {id-it 5}
-- CAKeyUpdateInfoValue ::= CAKeyUpdAnnContent
-- - id-it-caKeyUpdateInfo was deprecated with cmp2021
-- id-it-currentCRL OBJECT IDENTIFIER ::= {id-it 6}
-- CurrentCRLValue ::= CertificateList
-- id-it-unsupportedOIDs OBJECT IDENTIFIER ::= {id-it 7}
-- UnsupportedOIDsValue ::= SEQUENCE SIZE (1..MAX) OF
-- OBJECT IDENTIFIER
-- id-it-keyPairParamReq OBJECT IDENTIFIER ::= {id-it 10}
-- KeyPairParamReqValue ::= OBJECT IDENTIFIER
-- id-it-keyPairParamRep OBJECT IDENTIFIER ::= {id-it 11}
-- KeyPairParamRepValue ::= AlgorithmIdentifier{{...}}
-- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12}
-- RevPassphraseValue ::= EncryptedKey
-- - Changed from Encrypted Value to EncryptedKey as a CHOICE
-- - of EncryptedValue and EnvelopedData due to the changes
-- - made in [RFC9480]
-- - Using the choice EncryptedValue is bit-compatible to
-- - the syntax without this change
-- id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13}
-- ImplicitConfirmValue ::= NULL
-- id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14}
-- ConfirmWaitTimeValue ::= GeneralizedTime
-- id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15}
-- OrigPKIMessageValue ::= PKIMessages
-- id-it-suppLangTags OBJECT IDENTIFIER ::= {id-it 16}
-- SuppLangTagsValue ::= SEQUENCE OF UTF8String
-- id-it-caCerts OBJECT IDENTIFIER ::= {id-it 17}
-- CaCertsValue ::= SEQUENCE SIZE (1..MAX) OF
-- CMPCertificate
-- - id-it-caCerts added in [RFC9480]
-- id-it-rootCaKeyUpdate OBJECT IDENTIFIER ::= {id-it 18}
-- RootCaKeyUpdateValue ::= RootCaKeyUpdateContent
-- - id-it-rootCaKeyUpdate added in [RFC9480]
-- id-it-certReqTemplate OBJECT IDENTIFIER ::= {id-it 19}
-- CertReqTemplateValue ::= CertReqTemplateContent
-- - id-it-certReqTemplate added in [RFC9480]
-- id-it-rootCaCert OBJECT IDENTIFIER ::= {id-it 20}
-- RootCaCertValue ::= CMPCertificate
-- - id-it-rootCaCert added in [RFC9480]
-- id-it-certProfile OBJECT IDENTIFIER ::= {id-it 21}
-- CertProfileValue ::= SEQUENCE SIZE (1..MAX) OF
-- UTF8String
-- - id-it-certProfile added in [RFC9480]
-- id-it-crlStatusList OBJECT IDENTIFIER ::= {id-it 22}
-- CRLStatusListValue ::= SEQUENCE SIZE (1..MAX) OF
-- CRLStatus
-- - id-it-crlStatusList added in [RFC9480]
-- id-it-crls OBJECT IDENTIFIER ::= {id-it 23}
-- CRLsValue ::= SEQUENCE SIZE (1..MAX) OF
-- CertificateList
-- - id-it-crls added in [RFC9480]
-- id-it-KemCiphertextInfo OBJECT IDENTIFIER ::= {id-it 24}
-- KemCiphertextInfoValue ::= KemCiphertextInfo
-- - id-it-KemCiphertextInfo was added in [RFC9810]
--
-- where
--
-- id-pkix OBJECT IDENTIFIER ::= {
-- iso(1) identified-organization(3)
-- dod(6) internet(1) security(5) mechanisms(5) pkix(7)}
-- and
-- id-it OBJECT IDENTIFIER ::= {id-pkix 4}
--
--
-- This construct MAY also be used to define new PKIX Certificate
-- Management Protocol request and response messages or
-- general-purpose (e.g., announcement) messages for future needs
-- or for specific environments.
GenMsgContent ::= SEQUENCE OF InfoTypeAndValue
-- May be sent by end entity, RA, or CA (depending on message
-- content). The OPTIONAL infoValue parameter of InfoTypeAndValue
-- will typically be omitted for some of the examples given above.
-- The receiver is free to ignore any contained OIDs that it
-- does not recognize. If sent from end entity to CA, the empty set
-- indicates that the CA may send
-- any/all information that it wishes.
GenRepContent ::= SEQUENCE OF InfoTypeAndValue
-- The receiver MAY ignore any contained OIDs that it does not
-- recognize.
ErrorMsgContent ::= SEQUENCE {
pKIStatusInfo PKIStatusInfo,
errorCode INTEGER OPTIONAL,
-- implementation-specific error codes
errorDetails PKIFreeText OPTIONAL
-- implementation-specific error details
}
CertConfirmContent ::= SEQUENCE OF CertStatus
CertStatus ::= SEQUENCE {
certHash OCTET STRING,
-- the hash of the certificate, using the same hash algorithm
-- as is used to create and verify the certificate signature
certReqId INTEGER,
-- to match this confirmation with the corresponding req/rep
statusInfo PKIStatusInfo OPTIONAL,
hashAlg [0] AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} OPTIONAL
-- the hash algorithm to use for calculating certHash
-- SHOULD NOT be used in all cases where the AlgorithmIdentifier
-- of the certificate signature specifies a hash algorithm
}
PollReqContent ::= SEQUENCE OF SEQUENCE {
certReqId INTEGER }
PollRepContent ::= SEQUENCE OF SEQUENCE {
certReqId INTEGER,
checkAfter INTEGER, -- time in seconds
reason PKIFreeText OPTIONAL }
--
-- EKU extension for PKI entities used in CMP
-- operations, added due to the changes made in [RFC9480]
-- The EKUs for the CA and RA are reused from CMC, as defined in
-- [RFC6402]
--
-- id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 }
-- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 }
id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 }
END
The authors of this document wish to thank Carlisle Adams, Stephen Farrell, Tomi Kause, and Tero Mononen, the original authors of [RFC4210], for their work.
この文書の著者は、[RFC4210]の元の著者であるCarlisle Adams、Stephen Farrell、Tomi Kause、およびTero Mononenに感謝したいと考えています。
We also thank all reviewers of this document for their valuable feedback.
また、この文書のすべてのレビュアーが貴重なフィードバックをしてくれたことにも感謝します。
Adding KEM support to this document was partly funded by the German Federal Ministry of Education and Research in the project Quoryptan through grant number 16KIS2033.
この文書へのKEMサポートの追加は、助成金番号16KIS2033を通じて、プロジェクトQuoryptanのドイツ連邦教育省によって部分的に資金提供されていました。
Hendrik Brockhaus
Siemens
Werner-von-Siemens-Strasse 1
80333 Munich
Germany
Email: hendrik.brockhaus@siemens.com
URI: https://www.siemens.com
David von Oheimb
Siemens
Werner-von-Siemens-Strasse 1
80333 Munich
Germany
Email: david.von.oheimb@siemens.com
URI: https://www.siemens.com
Mike Ounsworth
Entrust
1187 Park Place
Minneapolis, MN 55379
United States of America
Email: mike.ounsworth@entrust.com
URI: https://www.entrust.com
John Gray
Entrust
1187 Park Place
Minneapolis, MN 55379
United States of America
Email: john.gray@entrust.com
URI: https://www.entrust.com