[要約] RFC 10004は、CMC準拠実装に必要な機能と処理を、すべてのエンティティ、クライアント、サーバー、エンドエンティティ、登録機関、認証局ごとに規定します。暗号アルゴリズム、制御、CRMF機能などの必須・任意要件を整理し、基本構文のRFC 10002およびトランスポートのRFC 10003とともに完全なCMC仕様を構成します。
Internet Engineering Task Force (IETF) J. Mandel, Ed.
Request for Comments: 10004 AKAYLA, Inc.
Obsoletes: 5274, 6402 S. Turner, Ed.
Category: Standards Track sn3rd
ISSN: 2070-1721 July 2026
This document provides a set of compliance statements about the Certificate Management over CMS (CMC) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents (RFCs 10002 and 10003). This document provides the information needed to make a compliant version of CMC.
この文書では、CMS 経由の証明書管理 (CMC) 登録プロトコルに関する一連の準拠声明を提供します。ASN.1 構造と CMC 登録プロトコルのトランスポート メカニズムについては、他の文書 (RFC 10002 および 10003) で説明されています。このドキュメントには、CMC の準拠バージョンを作成するために必要な情報が記載されています。
This document obsoletes RFCs 5274 and 6402.
この文書は RFC 5274 および 6402 を廃止します。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc10004.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc10004 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この文書には、2008 年 11 月 10 日より前に発行または一般公開された IETF 文書または IETF 寄稿の資料が含まれている場合があります。この資料の一部の著作権を管理している人物は、IETF 標準プロセス外でそのような資料の変更を許可する権利を IETF トラストに付与していない可能性があります。かかる資料の著作権を管理する者から適切なライセンスを取得しない限り、この文書を IETF 標準プロセスの外で変更することはできません。また、RFC として出版するための形式にするか、英語以外の言語に翻訳する場合を除き、IETF 標準プロセスの外でその派生著作物を作成することはできません。
1. Introduction
2. Terminology
3. Requirements Terminology
4. Changes Since RFCs 5274 and 6402
5. Requirements for All Entities
5.1. Cryptographic Algorithm Requirements
5.2. Controls
5.3. CRMF Feature Requirements
6. Requirements for Clients
7. Requirements for Servers
8. Requirements for EEs
9. Requirements for RAs
10. Requirements for CAs
11. Security Considerations
12. IANA Considerations
13. References
13.1. Normative References
13.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
The Certificate Management over CMS (CMC) protocol is designed in terms of a client/server relationship. In the simplest case, the client is the requestor of the certificate (i.e., the End-Entity (EE)) and the server is the issuer of the certificate (i.e., the Certification Authority (CA)). The introduction of a Registration Authority (RA) into the set of agents complicates the picture only slightly. The RA becomes the server with respect to the certificate requestor, and it becomes the client with respect to the certificate issuer. Any number of RAs can be inserted into the picture in this manner.
CMS 経由の証明書管理 (CMC) プロトコルは、クライアント/サーバーの関係に基づいて設計されています。最も単純なケースでは、クライアントは証明書の要求者 (つまり、エンドエンティティ (EE)) であり、サーバーは証明書の発行者 (つまり、認証局 (CA)) です。エージェントのセットに登録局 (RA) を導入しても、状況はわずかに複雑になります。RA は、証明書要求者に対してはサーバーとなり、証明書発行者に対してはクライアントになります。この方法で、任意の数の RA をピクチャに挿入できます。
The RAs may serve specialized purposes that are not currently covered by this document. One such purpose would be a Key Escrow agent. As such, all certificate requests for encryption keys would be directed through this RA, and it would take appropriate action to do the key archival. Key recovery requests could be defined in the CMC methodology allowing for the Key Escrow agent to perform that operation acting as the final server in the chain of agents.
RA は、現在この文書でカバーされていない特殊な目的を果たす場合があります。そのような目的の 1 つは、キー エスクロー エージェントです。そのため、暗号化キーに対するすべての証明書リクエストはこの RA を通じて送信され、キーのアーカイブを行うために適切なアクションが実行されます。キー回復リクエストを CMC 方法論で定義すると、キー エスクロー エージェントがエージェント チェーンの最後のサーバーとして機能してその操作を実行できるようになります。
If there are multiple RAs in the system, it is considered normal that not all RAs will see all certificate requests. The routing between the RAs may be dependent on the content of the certificate requests involved.
システム内に複数の RA がある場合、すべての RA がすべての証明書要求を認識できるわけではないのが通常であると考えられます。RA 間のルーティングは、関係する証明書要求の内容に依存する場合があります。
This document is divided into six sections, each section specifying the requirements that are specific to a class of agents in the CMC model. These are 1) all entities, 2) all servers, 3) all clients, 4) all EEs, 5) all RAs, and 6) all CAs.
このドキュメントは 6 つのセクションに分かれており、各セクションでは CMC モデルのエージェントのクラスに固有の要件を指定しています。これらは、1) すべてのエンティティ、2) すべてのサーバー、3) すべてのクライアント、4) すべての EE、5) すべての RA、および 6) すべての CA です。
This document obsoletes RFCs 5274 [CMC-COMPv1] and 6402 [CMC-Updates].
この文書は、RFC 5274 [CMC-COMPv1] および 6402 [CMC-Updates] を廃止します。
There are several different terms, abbreviations, and acronyms used in this document that we define here for convenience and consistency of usage:
このドキュメントではいくつかの異なる用語、略語、頭字語が使用されていますが、便宜と使用の一貫性のためにここで定義します。
End-Entity (EE):
エンドエンティティ (EE):
Refers to the entity that owns a key pair and for whom a certificate is issued.
キーペアを所有し、証明書が発行されるエンティティを指します。
Registration Authority (RA) or Local RA (LRA):
登録局 (RA) またはローカル RA (LRA):
Refers to an entity that acts as an intermediary between the EE and the CA. Multiple RAs can exist between the EE and the CA. RAs may perform additional services such as key generation or key archival. This document uses the term RA for both RA and LRA.
EE と CA の間の仲介者として機能するエンティティを指します。EE と CA の間には複数の RA が存在できます。RA は、キーの生成やキーのアーカイブなどの追加サービスを実行する場合があります。この文書では、RA と LRA の両方に対して RA という用語を使用します。
Certification Authority (CA):
認証局 (CA):
Refers to the entity that issues certificates.
証明書を発行するエンティティを指します。
Client:
クライアント:
Refers to an entity that creates a Public Key Infrastructure (PKI) Request. In this document, both RAs and EEs can be clients.
公開キー基盤 (PKI) リクエストを作成するエンティティを指します。このドキュメントでは、RA と EE の両方がクライアントになることができます。
Server:
サーバ:
Refers to the entities that process PKI Requests and create PKI Responses. In this document, both CAs and RAs can be servers.
PKI 要求を処理し、PKI 応答を作成するエンティティを指します。このドキュメントでは、CA と RA の両方がサーバーになることができます。
PKCS #10:
PKCS #10:
Refers to the Public Key Cryptography Standard #10 [PKCS10], which defines a certification request syntax.
証明書要求の構文を定義する公開鍵暗号化標準 #10 [PKCS10] を指します。
CRMF:
CRMF:
Refers to the Certificate Request Message Format [CRMF]. CMC uses this certification request syntax defined in this document as part of the protocol.
証明書要求メッセージ形式 [CRMF] を指します。CMC は、この文書で定義されているこの認証要求構文をプロトコルの一部として使用します。
CMS:
CMS:
Refers to the Cryptographic Message Syntax [CMS]. This document provides for basic cryptographic services including encryption and signing with and without key management.
暗号メッセージ構文 [CMS] を指します。この文書では、鍵管理の有無にかかわらず、暗号化と署名を含む基本的な暗号化サービスについて説明します。
PKI Request/Response:
PKI リクエスト/レスポンス:
Refers to the requests/responses described in this document. PKI Requests include certification requests, revocation requests, etc. PKI Responses include certs-only messages, failure messages, etc.
このドキュメントで説明されているリクエスト/レスポンスを指します。PKI 要求には、証明書要求、失効要求などが含まれます。PKI 応答には、証明書のみのメッセージ、失敗メッセージなどが含まれます。
Proof-of-Identity:
身元証明:
Refers to the client proving they are who they say that they are to the server.
クライアントがサーバーに対して自分が誰であるかを証明することを指します。
Proof-of-Possession (POP):
所有証明 (POP):
Refers to a value that can be used to prove that the private key corresponding to a public key is in the possession and can be used by an EE. See Section 2.1 of [CMC-STRUCT].
公開鍵に対応する秘密鍵が所有されており、EE が使用できることを証明するために使用できる値を指します。[CMC-STRUCT] のセクション 2.1 を参照してください。
Transport wrapper:
トランスポートラッパー:
Refers to the outermost CMS wrapping layer.
最も外側の CMS ラッピング層を指します。
Entity:
実在物：
Refers to EE, RA (or LRA), or CA.
EE、RA (または LRA)、または CA を指します。
HMAC:
HMAC:
Refers to the Hashed Message Authentication Code. CMC uses the ASN.1 module defined in [HMAC-ALGS].
ハッシュされたメッセージ認証コードを指します。CMC は、[HMAC-ALGS] で定義されている ASN.1 モジュールを使用します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
Merged [CMC-Updates] text.
[CMC-Updates] テキストを統合しました。
Updated the Introduction, changed "all agents" to "all entities" in the overview to maintain consistency throughout the document, and renumbered the section headers.
概要を更新し、ドキュメント全体の一貫性を維持するために概要の「すべてのエージェント」を「すべてのエンティティ」に変更し、セクション ヘッダーの番号を変更しました。
Added RA Identity Proof Witness and Response Body controls to Table 1.
RA Identity Proof Witness および Response Body のコントロールを表 1 に追加しました。
Updated the Cryptographic Algorithm Requirements:
暗号アルゴリズム要件を更新しました。
* Replaced SHA-1 with SHA-256
* SHA-1 を SHA-256 に置き換えました
* Replaced HMAC-SHA-1 with HMAC-SHA-256
* HMAC-SHA-1 を HMAC-SHA-256 に置き換えました。
* Added algorithms for AuthEnvelopedData
* AuthEnvelopedData のアルゴリズムを追加しました
Added a paragraph to maintain backward algorithm compatibility.
アルゴリズムの下位互換性を維持するための段落を追加しました。
All [CMC-STRUCT] and [CMC-TRANS] compliance statements MUST be adhered to unless specifically stated otherwise in this document.
この文書に特に明記されていない限り、すべての [CMC-STRUCT] および [CMC-TRANS] 準拠ステートメントに従わなければなりません。
All entities MUST support Full PKI Requests, Simple PKI Responses, and Full PKI Responses. Servers SHOULD support Simple PKI Requests.
すべてのエンティティは、完全な PKI 要求、単純な PKI 応答、および完全な PKI 応答をサポートしなければなりません。サーバーはシンプルな PKI リクエストをサポートすべきです(SHOULD)。
All entities MUST support the use of the CRMF syntax for certification requests. Support for the PKCS #10 syntax for certification requests SHOULD be implemented by servers.
すべてのエンティティは、証明書リクエストに対する CRMF 構文の使用をサポートしなければなりません (MUST)。証明書リクエストの PKCS #10 構文のサポートはサーバーによって実装されるべきです (SHOULD)。
The extendedFailInfo field SHOULD NOT be populated in the CMCStatusInfoV2 object; the failInfo field SHOULD be used to relay this information. If the extendedFailInfo field is used, it is suggested that an additional CMCStatusInfoV2 item exist for the same body part with a failInfo field.
extendedFailInfo フィールドは CMCStatusInfoV2 オブジェクトに設定すべきではありません (SHOULD NOT)。この情報を中継するには、failInfo フィールドを使用する必要があります (SHOULD)。extendedFailInfo フィールドが使用される場合、failInfo フィールドを持つ同じ本文部分に追加の CMCStatusInfoV2 項目が存在することが推奨されます。
All entities MUST implement the HTTP transport mechanism as defined in [CMC-TRANS]. Other transport mechanisms MAY be implemented.
すべてのエンティティは、[CMC-TRANS] で定義されている HTTP トランスポート メカニズムを実装しなければなりません (MUST)。他のトランスポートメカニズムが実装されてもよい(MAY)。
All entities MUST verify RSA-SHA256 signatures in SignedData; (see [CMS-ALG2]). Entities MAY verify other signature algorithms.
すべてのエンティティは、SignedData 内の RSA-SHA256 署名を検証しなければなりません。([CMS-ALG2] を参照)。エンティティは他の署名アルゴリズムを検証してもよい(MAY)。
All entities MUST generate RSA-SHA256 signatures for SignedData; (see [CMS-ALG2]). Other signature algorithms MAY be used for generation.
すべてのエンティティは、SignedData の RSA-SHA256 署名を生成しなければなりません。([CMS-ALG2] を参照)。他の署名アルゴリズムを生成に使用してもよい(MAY)。
All entities MUST support Advanced Encryption Standard (AES) as the content encryption algorithm for EnvelopedData; (see [CMS-AES]). Other content encryption algorithms MAY be implemented.
すべてのエンティティは、EnvelopedData のコンテンツ暗号化アルゴリズムとして Advanced Encryption Standard (AES) をサポートしなければなりません。([CMS-AES]を参照)。他のコンテンツ暗号化アルゴリズムを実装してもよい(MAY)。
All entities MUST support AES-GCM (Galois/Counter Mode) as the authenticated content encryption algorithm for AuthEnvelopedData; (see [CMS-AES-AE]). They MUST also support a 12-octet nonce size and a 12-octet Integrity Check Value (ICV) length. Other content encryption algorithms MAY be implemented.
すべてのエンティティは、AuthEnvelopedData の認証済みコンテンツ暗号化アルゴリズムとして AES-GCM (ガロア/カウンター モード) をサポートしなければなりません。([CMS-AES-AE]を参照)。また、12 オクテットのノンス サイズと 12 オクテットの整合性チェック値 (ICV) 長もサポートしなければなりません (MUST)。他のコンテンツ暗号化アルゴリズムを実装してもよい(MAY)。
All entities MUST support RSA as a key transport algorithm for EnvelopedData and AuthEnvelopedData; see [CMS-ALG2]. Other key transport algorithms MAY be implemented.
すべてのエンティティは、EnvelopedData および AuthEnvelopedData の鍵トランスポート アルゴリズムとして RSA をサポートしなければなりません (MUST)。[CMS-ALG2] を参照してください。他の鍵トランスポートアルゴリズムを実装してもよい(MAY)。
If an entity supports key agreement for EnvelopedData or AuthEnvelopedData, it MUST support Diffie-Hellman (DH); (see [CMS-DH]).
エンティティが EnvelopedData または AuthEnvelopedData の鍵合意をサポートする場合、Diffie-Hellman (DH) をサポートしなければなりません。([CMS-DH]を参照)。
If an entity supports PasswordRecipientInfo for EnvelopedData, AuthenticatedData, or AuthEnvelopedData, it MUST support Password-Based Key Derivation Function 2 (PBKDF2) [PBKDF2] for key derivation algorithms. It MUST support AES key wrap (see [AES-WRAP]) as the key encryption algorithm.
エンティティが EnvelopedData、AuthenticatedData、または AuthEnvelopedData の PasswordRecipientInfo をサポートする場合、鍵導出アルゴリズムとして Password-Based Key Derivation Function 2 (PBKDF2) [PBKDF2] をサポートしなければなりません (MUST)。鍵暗号化アルゴリズムとして AES 鍵ラップ ([AES-WRAP] を参照) をサポートしなければなりません (MUST)。
If AuthenticatedData is supported, PasswordRecipientInfo MUST be supported.
AuthenticatedData がサポートされている場合は、PasswordRecipientInfo もサポートされなければなりません。
Algorithm requirements for the Identity Proof Version 2 control (Section 6.2.1 of [CMC-STRUCT]) are as follows:
Identity Proof バージョン 2 コントロールのアルゴリズム要件 ([CMC-STRUCT] のセクション 6.2.1) は次のとおりです。
* SHA-256 MUST be implemented for hashAlgId.
* hashAlgId には SHA-256 を実装する必要があります。
* HMAC-SHA256 MUST be implemented for macAlgId.
* HMAC-SHA256 を macAlgId に実装する必要があります。
Algorithm requirements for the Pop Link Witness Version 2 control (Section 6.3.1.1 of [CMC-STRUCT]) are as follows:
Pop Link Witness バージョン 2 コントロールのアルゴリズム要件 ([CMC-STRUCT] のセクション 6.3.1.1) は次のとおりです。
* SHA-256 MUST be implemented for keyGenAlgorithm.
* keyGenAlgorithm には SHA-256 を実装する必要があります。
* PBKDF2 [PBKDF2] MAY be implemented for keyGenAlgorithm.
* PBKDF2 [PBKDF2] keyGenAlgorithm 用に実装してもよい(MAY)。
* HMAC-SHA256 MUST be implemented for macAlgorithm.
* HMAC-SHA256 は macAlgorithm に実装されなければなりません。
Algorithm requirements for the Encrypted POP and Decrypted POP controls (Section 6.7 of [CMC-STRUCT]) are as follows:
暗号化 POP および復号化 POP コントロール ([CMC-STRUCT] のセクション 6.7) のアルゴリズム要件は次のとおりです。
* SHA-256 MUST be implemented for witnessAlgID.
* SHA-256 は、witnessAlgID に対して実装されなければなりません。
* HMAC-SHA256 MUST be implemented for thePOPAlgID.
* POPAlgID には HMAC-SHA256 を実装する必要があります。
Algorithm requirements for Publish Trust Anchors control (Section 6.15 of [CMC-STRUCT]) are as follows:
パブリッシュ トラスト アンカー制御のアルゴリズム要件 ([CMC-STRUCT] のセクション 6.15) は次のとおりです。
* SHA-256 MUST be implemented for hashAlgorithm.
* hashAlgorithm には SHA-256 を実装する必要があります。
If an EE generates DH keys for certification, it MUST support Section 4 of [DH-POP]. EEs MAY support Section 3 of [DH-POP]. CAs and RAs that do POP verification MUST support Section 4 of [DH-POP] and SHOULD support Section 3 of [DH-POP].
EE が認証用の DH キーを生成する場合、[DH-POP] のセクション 4 をサポートしなければなりません (MUST)。EE は [DH-POP] のセクション 3 をサポートしてもよい(MAY)。POP 検証を行う CA および RA は、[DH-POP] のセクション 4 をサポートしなければならず (MUST)、[DH-POP] のセクション 3 をサポートする必要があります (SHOULD)。
EEs that need to use a signature algorithm for keys that cannot produce a signature MUST support Appendix C of [CMC-STRUCT] and MUST support the Encrypted/Decrypted POP controls. CAs and RAs that do POP verification MUST support this signature algorithm and MUST support the Encrypted/Decrypted POP controls.
署名を生成できない鍵に対して署名アルゴリズムを使用する必要がある EE は、[CMC-STRUCT] の付録 C をサポートしなければならず、暗号化/復号化された POP コントロールをサポートしなければなりません。POP 検証を行う CA および RA は、この署名アルゴリズムをサポートしなければならず、暗号化/復号化された POP コントロールをサポートしなければなりません。
For backward compatibility with the previous version of CMC, servers MAY offer the algorithms specified therein, but SHOULD use the CMC requests to identify which certificates should be transitioned to more secure algorithms, if possible.
以前のバージョンの CMC との下位互換性のために、サーバーはそこで指定されたアルゴリズムを提供してもよい (MAY) が、可能であれば、どの証明書をより安全なアルゴリズムに移行する必要があるかを識別するために CMC リクエストを使用すべきである (SHOULD)。
The following table lists the name and level of support required for each control.
次の表に、各コントロールに必要なサポートの名前とレベルを示します。
+============================+==========+==========+==========+
| Control | EE | RA | CA |
+============================+==========+==========+==========+
| Extended CMC Status Info | MUST | MUST | MUST |
+----------------------------+----------+----------+----------+
| CMC Status Info | SHOULD | SHOULD | SHOULD |
+----------------------------+----------+----------+----------+
| Identity Proof Version 2 | MUST | MUST | MUST |
+----------------------------+----------+----------+----------+
| Identity Proof | SHOULD | SHOULD | SHOULD |
+----------------------------+----------+----------+----------+
| Identification | MUST | MUST | MUST |
+----------------------------+----------+----------+----------+
| POP Link Random | MUST | MUST | MUST |
+----------------------------+----------+----------+----------+
| POP Link Witness Version 2 | MUST | MUST | MUST |
+----------------------------+----------+----------+----------+
| POP Link Witness | SHOULD | MUST | MUST |
+----------------------------+----------+----------+----------+
| Data Return | MUST | MUST | MUST |
+----------------------------+----------+----------+----------+
| Modify Cert Request | N/A | MUST | (2) |
+----------------------------+----------+----------+----------+
| Add Extensions | N/A | MAY | (1) |
+----------------------------+----------+----------+----------+
| Transaction ID | MUST | MUST | MUST |
+----------------------------+----------+----------+----------+
| Sender Nonce | MUST | MUST | MUST |
+----------------------------+----------+----------+----------+
| Recipient Nonce | MUST | MUST | MUST |
+----------------------------+----------+----------+----------+
| Encrypted POP | (4) | (5) | SHOULD |
+----------------------------+----------+----------+----------+
| Decrypted POP | (4) | (5) | SHOULD |
+----------------------------+----------+----------+----------+
| RA POP Witness | N/A | SHOULD | (1) |
+----------------------------+----------+----------+----------+
| Get Certificate | OPTIONAL | OPTIONAL | OPTIONAL |
+----------------------------+----------+----------+----------+
| Get CRL | OPTIONAL | OPTIONAL | OPTIONAL |
+----------------------------+----------+----------+----------+
| Revocation Request | SHOULD | SHOULD | MUST |
+----------------------------+----------+----------+----------+
| Registration Info | SHOULD | SHOULD | SHOULD |
+----------------------------+----------+----------+----------+
| Response Information | SHOULD | SHOULD | SHOULD |
+----------------------------+----------+----------+----------+
| Query Pending | MUST | MUST | MUST |
+----------------------------+----------+----------+----------+
| Confirm Cert. Acceptance | MUST | MUST | MUST |
+----------------------------+----------+----------+----------+
| Publish Trust Anchors | (3) | (3) | (3) |
+----------------------------+----------+----------+----------+
| Authenticated Data | (3) | (3) | (3) |
+----------------------------+----------+----------+----------+
| Batch Request | N/A | MUST | (2) |
+----------------------------+----------+----------+----------+
| Batch Responses | N/A | MUST | (2) |
+----------------------------+----------+----------+----------+
| Publication Information | OPTIONAL | OPTIONAL | OPTIONAL |
+----------------------------+----------+----------+----------+
| Control Processed | N/A | MUST | (2) |
+----------------------------+----------+----------+----------+
| RA Identity Proof Witness | N/A | MUST | (2) |
+----------------------------+----------+----------+----------+
| Response Body | (6) | (6) | N/A |
+----------------------------+----------+----------+----------+
Table 1: CMC Control Attributes
表 1: CMC 制御属性
Notes:
注:
1. CAs SHOULD implement this control if designed to work with RAs.
1. CA は、RA と連携するように設計されている場合、この制御を実装する必要があります (SHOULD)。
2. CAs MUST implement this control if designed to work with RAs.
2. CA は、RA と連携するように設計されている場合、この制御を実装しなければなりません。
3. Implementation is OPTIONAL for these controls. We strongly suggest that they be implemented in order to populate client trust anchors.
3. これらのコントロールの実装はオプションです。クライアントのトラスト アンカーを設定するためにこれらを実装することを強くお勧めします。
4. EEs only need to implement this if (a) they support key agreement algorithms or (b) they need to operate in environments where the hardware keys cannot provide POP.
4. EE は、(a) キー合意アルゴリズムをサポートする場合、または (b) ハードウェア キーが POP を提供できない環境で動作する必要がある場合にのみ、これを実装する必要があります。
5. RAs SHOULD implement this if they implement RA POP Witness.
5. RA は、RA POP Witness を実装する場合、これを実装する必要があります (SHOULD)。
6. EEs SHOULD implement this if designed to work with RAs and MUST implement if intended to be used in environments where RAs are used for identity validation or key generation. RAs SHOULD implement and validate responses for consistency.
6. EE は、RA と連携するように設計されている場合はこれを実装すべきであり、RA が ID 検証または鍵生成に使用される環境で使用することを意図している場合は実装しなければなりません。RA は、応答の一貫性を実装および検証する必要があります (SHOULD)。
Strong consideration should be given to implementing the Authenticated Data and Publish Trust Anchors controls as this gives a simple method for distributing trust anchors to clients without user intervention.
これにより、ユーザーの介入なしにトラスト アンカーをクライアントに配布する簡単な方法が得られるため、認証済みデータおよびトラスト アンカーの公開コントロールの実装については、十分に考慮する必要があります。
The following additional restrictions are placed on CRMF features:
CRMF 機能には、次の追加の制限が課されます。
* The registration control tokens id-regCtrl-regToken and id-regCtrl-authToken MUST NOT be used. No specific CMC feature is used to replace these items, but generally the CMC control's identification and identityProof will perform the same service and are more specifically defined.
* 登録制御トークン id-regCtrl-regToken および id-regCtrl-authToken は使用してはなりません (MUST NOT)。これらの項目を置き換えるために特定の CMC 機能は使用されませんが、通常、CMC コントロールの ID と identityProof は同じサービスを実行し、より具体的に定義されます。
* The control token id-regCtrl-pkiArchiveOptions SHOULD NOT be supported. See Section 3.2.1.3.3 of [CMC-STRUCT] and Section 3.2.1.3.3 of [CMC-STRUCT] for alternative methods.
* コントロール トークン id-regCtrl-pkiArchiveOptions はサポートすべきではありません (SHOULD NOT)。代替方法については、[CMC-STRUCT] のセクション 3.2.1.3.3 および [CMC-STRUCT] のセクション 3.2.1.3.3 を参照してください。
* The behavior of id-regCtrl-oldCertID is not presently used. It is replaced by issuing the new certificate and using the id-cmc-publishCert to remove the old certificate from publication. This operation would not normally be accompanied by an immediate revocation of the old certificate; however, that can be accomplished by the id-cmc-revokeRequest control.
* id-regCtrl-oldCertID の動作は現在使用されていません。新しい証明書を発行し、id-cmc-publishCert を使用して古い証明書を公開から削除することで置き換えられます。通常、この操作には古い証明書の即時失効は伴いません。ただし、これは id-cmc-revokeRequest コントロールによって実現できます。
* The id-regCtrl-protocolEncrKey is not used.
* id-regCtrl-protocolEncrKey は使用されません。
There are no additional requirements.
追加の要件はありません。
There are no additional requirements.
追加の要件はありません。
If an EE implements Diffie-Hellman, it MUST implement either the DH POP Proof-of-Possession as defined in Section 4 of [DH-POP] or the challenge-response POP controls id-cmc-encryptedPOP and id-cmc-decryptedPOP.
EE が Diffie-Hellman を実装する場合、[DH-POP] のセクション 4 で定義されている DH POP 所有証明、またはチャレンジ/レスポンス POP 制御 id-cmc-encryptedPOP および id-cmc-decryptedPOP のいずれかを実装しなければなりません (MUST)。
RAs SHOULD be able to do delegated POP. RAs implementing this feature MUST implement the id-cmc-lraPOPWitness control.
RA は委任された POP を実行できる必要があります。この機能を実装する RA は、id-cmc-lraPOPWitness コントロールを実装する必要があります。
All RAs MUST implement the promotion of the id-aa-cmc-unsignedData as covered in Section 3.2.3 of [CMC-STRUCT].
すべての RA は、[CMC-STRUCT] のセクション 3.2.3 で説明されているように、id-aa-cmc-unsignedData のプロモーションを実装しなければなりません (MUST)。
Providing for CAs to work in an environment with RAs is strongly suggested. Implementation of such support is strongly suggested as this permits the delegation of substantial administrative interaction onto an RA rather than at the CA.
CA が RA のある環境で動作できるようにすることを強くお勧めします。このようなサポートの実装は、CA ではなく RA への実質的な管理対話の委任を可能にするため、強く推奨されます。
CAs MUST perform at least minimal checks on all public keys before issuing a certificate. At a minimum, a check for syntax would occur with the POP operation. Additionally, CAs SHOULD perform simple checks for known bad keys such as small subgroups for DSA-SHA1 and DH keys [SMALL-SUB-GROUP] or known bad exponents for RSA keys.
CA は、証明書を発行する前に、すべての公開鍵に対して少なくとも最小限のチェックを実行しなければなりません (MUST)。少なくとも、POP 操作では構文チェックが行われます。さらに、CA は、DSA-SHA1 および DH 鍵 [SMALL-SUB-GROUP] の小さなサブグループ、または RSA 鍵の既知の不正な指数など、既知の不正な鍵の単純なチェックを実行する必要があります (SHOULD)。
CAs MUST enforce POP checking before issuing any certificate. CAs MAY delegate the POP operation to an RA for those cases where:
CA は証明書を発行する前に POP チェックを強制しなければなりません。CA は、次の場合に POP 操作を RA に委任してもよい(MAY)。
1. a challenge/response message pair must be used,
1. チャレンジ/レスポンス メッセージのペアを使用する必要があります。
2. an RA performs escrow of a key and checks for POP in that manner, or
2. RA がキーのエスクローを実行し、その方法で POP をチェックする、または
3. an unusual algorithm is used and that validation is done at the RA.
3. 通常とは異なるアルゴリズムが使用され、その検証は RA で行われます。
CAs SHOULD implement both the DH-POP Proof-of-Possession as defined in Section 4 of [DH-POP] and the challenge-response POP controls id-cmc-encryptedPOP and id-cmc-decryptedPOP.
CA は、[DH-POP] のセクション 4 で定義されている DH-POP 所有証明と、チャレンジ/レスポンス POP 制御の id-cmc-encryptedPOP および id-cmc-decryptedPOP の両方を実装すべきです (SHOULD)。
This document uses [CMC-STRUCT] and [CMC-TRANS] as building blocks. The security sections of those two documents are included by reference.
このドキュメントでは、[CMC-STRUCT] と [CMC-TRANS] を構成要素として使用します。これら 2 つのドキュメントのセキュリティに関するセクションは、参照により組み込まれています。
Knowledge of how an entity is expected to operate is vital in determining which sections of requirements are applicable to that entity. Care needs to be taken in determining which sections apply and fully implementing the necessary code.
要件のどのセクションがそのエンティティに適用されるかを判断するには、エンティティがどのように運営されると予想されるかについての知識が不可欠です。どのセクションが適用されるかを判断し、必要なコードを完全に実装するには注意が必要です。
Cryptographic algorithms have and will be broken or weakened. Implementers and users need to check that the cryptographic algorithms listed in this document make sense from a security level. The IETF from time to time may issue documents dealing with the current state of the art. Two examples of such documents are [SMALL-SUB-GROUP] and [HASH-ATTACKS].
暗号アルゴリズムは壊れたり弱くなったりしていますし、今後も壊れるでしょう。実装者とユーザーは、この文書にリストされている暗号化アルゴリズムがセキュリティ レベルから見て意味があるかどうかを確認する必要があります。IETF は、最新技術を扱う文書を発行することがあります。このような文書の 2 つの例は、[SMALL-SUB-GROUP] と [HASH-ATTACKS] です。
This document has no IANA actions.
この文書には IANA のアクションはありません。
[AES-WRAP] Schaad, J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,
October 2002, <https://www.rfc-editor.org/info/rfc3394>.
[CMC-STRUCT]
Mandel, J., Ed. and S. Turner, Ed., "Certificate
Management over CMS (CMC)", RFC 10002,
DOI 10.17487/RFC10002, July 2026,
<https://www.rfc-editor.org/info/rfc10002>.
[CMC-TRANS]
Mandel, J., Ed. and S. Turner, Ed., "Certificate
Management over CMS (CMC): Transport Protocols",
RFC 10003, DOI 10.17487/RFC10003, July 2026,
<https://www.rfc-editor.org/info/rfc10003>.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.
[CMS-AES] Schaad, J., "Use of the Advanced Encryption Standard (AES)
Encryption Algorithm in Cryptographic Message Syntax
(CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003,
<https://www.rfc-editor.org/info/rfc3565>.
[CMS-AES-AE]
Housley, R., "Using AES-CCM and AES-GCM Authenticated
Encryption in the Cryptographic Message Syntax (CMS)",
RFC 5084, DOI 10.17487/RFC5084, November 2007,
<https://www.rfc-editor.org/info/rfc5084>.
[CMS-ALG2] Turner, S., "Using SHA2 Algorithms with Cryptographic
Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January
2010, <https://www.rfc-editor.org/info/rfc5754>.
[CMS-DH] Rescorla, E., "Diffie-Hellman Key Agreement Method",
RFC 2631, DOI 10.17487/RFC2631, June 1999,
<https://www.rfc-editor.org/info/rfc2631>.
[CRMF] 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>.
[DH-POP] Schaad, J. and H. Prafullchandra, "Diffie-Hellman Proof-
of-Possession Algorithms", RFC 6955, DOI 10.17487/RFC6955,
May 2013, <https://www.rfc-editor.org/info/rfc6955>.
[HMAC-ALGS]
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>.
[PBKDF2] Kario, A., "Use of Password-Based Message Authentication
Code 1 (PBMAC1) in PKCS #12 Syntax", RFC 9879,
DOI 10.17487/RFC9879, September 2025,
<https://www.rfc-editor.org/info/rfc9879>.
[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>.
[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>.
[CMC-COMPv1]
Schaad, J. and M. Myers, "Certificate Management Messages
over CMS (CMC): Compliance Requirements", RFC 5274,
DOI 10.17487/RFC5274, June 2008,
<https://www.rfc-editor.org/info/rfc5274>.
[CMC-Updates]
Schaad, J., "Certificate Management over CMS (CMC)
Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011,
<https://www.rfc-editor.org/info/rfc6402>.
[HASH-ATTACKS]
Hoffman, P. and B. Schneier, "Attacks on Cryptographic
Hashes in Internet Protocols", RFC 4270,
DOI 10.17487/RFC4270, December 2005,
<https://www.rfc-editor.org/info/rfc4270>.
[PKCS10] 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>.
[SMALL-SUB-GROUP]
Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
Attacks on the Diffie-Hellman Key Agreement Method for S/
MIME", RFC 2785, DOI 10.17487/RFC2785, March 2000,
<https://www.rfc-editor.org/info/rfc2785>.
Obviously, the authors would like to thank Jim Schaad and Michael Myers for their work on [CMC-COMPv1].
明らかに、著者らは [CMC-COMPv1] の取り組みについて Jim Schaad と Michael Myers に感謝したいと思います。
Thank you to Mike Bishop, Mohamed Boucadair, and Erik Kline for reviewing the document and providing comments.
文書をレビューし、コメントを提供してくださった Mike Bishop、Mohamed Boucadair、および Erik Kline に感謝します。
The Acknowledgments section from RFC 5274 follows:
RFC 5274 の謝辞セクションは次のとおりです。
The authors and the PKIX Working Group are grateful for the participation of Xiaoyi Liu and Jeff Weinstein in helping to author the original versions of this document.
著者と PKIX ワーキング グループは、このドキュメントのオリジナル版の作成に協力してくれた Xiaoyi Liu と Jeff Weinstein の参加に感謝しています。
The authors would like to thank Brian LaMacchia for his work in developing and writing up many of the concepts presented in this document. The authors would also like to thank Alex Deacon and Barb Fox for their contributions.
著者らは、この文書に記載されている概念の多くを開発し、執筆した Brian LaMacchia 氏に感謝の意を表します。著者らは、貢献してくれた Alex Deacon と Barb Fox にも感謝したいと思います。
Jim Schaad
August Cellars
Michael Myers
TraceRoute Security, Inc.
Joseph Mandel (editor)
AKAYLA, Inc.
Email: joe@akayla.com
Sean Turner (editor)
sn3rd
Email: sean@sn3rd.com