[要約] RFC 5274は、CMS上での証明書管理メッセージ（CMC）の準拠要件に関するものであり、証明書の要求、更新、取り消し、再発行などの操作を定義しています。このRFCの目的は、CMCプロトコルの実装者が準拠要件を理解し、適切に実装するためのガイドラインを提供することです。
Network Working Group J. Schaad
Request for Comments: 5274 Soaring Hawk Consulting
Category: Standards Track M. Myers
TraceRoute Security, Inc.
June 2008
Certificate Management Messages over CMS (CMC): Compliance Requirements
CMS（CMC）を介した証明書管理メッセージ：コンプライアンス要件
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This document provides a set of compliance statements about the CMC (Certificate Management over CMS) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents. This document provides the information needed to make a compliant version of CMC.
このドキュメントは、CMC（CMS上の証明書管理）登録プロトコルに関する一連のコンプライアンスステートメントを提供します。CMC登録プロトコルのASN.1構造と輸送メカニズムは、他のドキュメントで説明されています。このドキュメントは、CMCの準拠バージョンを作成するために必要な情報を提供します。
Table of Contents
目次
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3
4. Requirements for All Entities . . . . . . . . . . . . . . . . 3
4.1. Cryptographic Algorithm Requirements . . . . . . . . . . . 4
4.2. Controls . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. CRMF Feature Requirements . . . . . . . . . . . . . . . . 8
4.4. Requirements for Clients . . . . . . . . . . . . . . . . . 8
5. Requirements for Servers . . . . . . . . . . . . . . . . . . . 8
6. Requirements for EEs . . . . . . . . . . . . . . . . . . . . . 8
7. Requirements for RAs . . . . . . . . . . . . . . . . . . . . . 8
8. Requirements for CAs . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . . 11
The CMC (Certificate Management over CMS) 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.
CMC（CMS以上の証明書管理）プロトコルは、クライアント/サーバーの関係に関して設計されています。最も簡単な場合、クライアントは証明書の要求者（つまり、エンティティ（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.
RASは、現在このドキュメントでカバーされていない専門的な目的に役立つ場合があります。そのような目的の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 agents, 2) all servers, 3) all clients, 4) all End-Entities, 5) all Registration Entities, 6) all Certificate Authorities.
このドキュメントは6つのセクションに分割され、各セクションはCMCモデルのエージェントのクラスに固有の要件を指定します。これらは1）すべてのエージェント、2）すべてのサーバー、3）すべてのクライアント、4）すべてのエンドエンティティ、5）すべての登録エンティティ、6）すべての証明書当局。
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) refers to the entity that owns a key pair and for whom a certificate is issued.
エンドエンティティ（EE）とは、重要なペアを所有し、証明書が発行されるエンティティを指します。
Registration Authority (RA) or Local RA (LRA) refers to an entity that acts as an intermediary between the EE and the CA. Multiple RAs can exist between the End-Entity and the Certification Authority. RAs may perform additional services such as key generation or key archival. This document uses the term RA for both RA and LRA.
登録機関（RA）またはローカルRA（LRA）は、EEとCAの間の仲介者として機能するエンティティを指します。エンドエンティティと認証機関の間に複数のRAが存在する可能性があります。RASは、キージェネレーションやキーアーカイブなどの追加サービスを実行する場合があります。このドキュメントでは、RAとLRAの両方にRAという用語を使用しています。
Certification Authority (CA) refers to the entity that issues certificates.
認証機関（CA）とは、証明書を発行するエンティティを指します。
Client refers to an entity that creates a PKI Request. In this document, both RAs and EEs can be clients.
クライアントは、PKIリクエストを作成するエンティティを指します。このドキュメントでは、RASと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応答を作成するエンティティを指します。このドキュメントでは、CASとRASの両方がサーバーになります。
PKCS #10 refers to the Public Key Cryptography Standard #10 [PKCS10], which defines a certification request syntax.
PKCS＃10は、公開キー暗号標準＃10 [PKCS10]を指します。これは、認証要求の構文を定義しています。
CRMF refers to the Certificate Request Message Format RFC [CRMF]. CMC uses this certification request syntax defined in this document as part of the protocol.
CRMFは、証明書リクエストメッセージフォーマットRFC [CRMF]を指します。CMCは、このドキュメントで定義されているこの認証要求の構文をプロトコルの一部として使用します。
CMS refers to the Cryptographic Message Syntax RFC [CMS]. This document provides for basic cryptographic services including encryption and signing with and without key management.
CMSは、暗号化メッセージの構文RFC [CMS]を指します。このドキュメントは、重要な管理の有無にかかわらず、暗号化や署名などの基本的な暗号化サービスを提供します。
PKI Request/Response 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リクエストには、認定リクエスト、取り消しリクエストなどが含まれます。PKI応答には、証明書のみのメッセージ、失敗メッセージなどが含まれます。
Proof-of-Identity refers to the client proving they are who they say that they are to the server.
アイデンティティの証明とは、クライアントが彼らがサーバーにいると言う人であることを証明することを指します。
Proof-of-Possession (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 end-entity.
Proof-of-Possession（POP）とは、公開鍵に対応する秘密鍵が所有されており、エンドエンティティによって使用できることを証明するために使用できる値を指します。
Transport wrapper refers to the outermost CMS wrapping layer.
トランスポートラッパーは、最も外側のCMSラッピングレイヤーを指します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [MUST].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[必須]で説明されていると解釈される。
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リクエストをサポートする必要があります。
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構文の使用をサポートする必要があります。認証要求のPKCS＃10構文のサポートは、サーバーによって実装される必要があります。
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オブジェクトに入力しないでください。FailInfoフィールドを使用して、この情報を中継する必要があります。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トランスポートメカニズムを実装する必要があります。他の輸送メカニズムが実装される場合があります。
All entities MUST verify DSA-SHA1 and RSA-SHA1 signatures in SignedData (see [CMS-ALG]). Entities MAY verify other signature algorithms. It is strongly suggested that RSA-PSS with SHA-1 be verified (see [CMS-RSA-PSS]). It is strongly suggested that SHA-256 using RSA and RSA-PSS be verified (see [RSA-256]).
すべてのエンティティは、SignedDataでDSA-SHA1およびRSA-SHA1の署名を検証する必要があります（[CMS-Alg]を参照）。エンティティは、他の署名アルゴリズムを検証する場合があります。SHA-1を使用したRSA-PSSを検証することを強くお勧めします（[CMS-RSA-PSS]を参照）。RSAおよびRSA-PSSを使用したSHA-256を検証することを強くお勧めします（[RSA-256を参照]）。
All entities MUST generate either DSA-SHA1 or RSA-SHA1 signatures for SignedData (see [CMS-ALG]). Other signatures algorithms MAY be used for generation.
すべてのエンティティは、SignedDataのDSA-SHA1またはRSA-SHA1の署名を生成する必要があります（[CMS-Alg]を参照）。その他の署名アルゴリズムは、生成に使用できます。
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のコンテンツ暗号化アルゴリズムとして高度な暗号化標準（AES）をサポートする必要があります（[CMS-AES]を参照）。他のコンテンツ暗号化アルゴリズムが実装される場合があります。
All entities MUST support RSA as a key transport algorithm for EnvelopedData (see [CMS-ALG]). All entities SHOULD support RSA-OAEP (see [CMS-RSA-OAEP]) as a key transport algorithm. Other key transport algorithms MAY be implemented.
すべてのエンティティは、RSAをEnvelopedDataの重要な輸送アルゴリズムとしてサポートする必要があります（[CMS-Alg]を参照）。すべてのエンティティは、主要な輸送アルゴリズムとしてRSA-OAEP（[CMS-RSA-OAEP]を参照）をサポートする必要があります。他の主要な輸送アルゴリズムが実装される場合があります。
If an entity supports key agreement for EnvelopedData, it MUST support Diffie-Hellman (see [CMS-DH]).
エンティティがEnvelopedDataの重要な契約をサポートしている場合、Diffie-Hellmanをサポートする必要があります（[CMS-DH]を参照）。
If an entity supports PasswordRecipientInfo for EnvelopedData or AuthenticatedData, it MUST support PBKDF2 [PBKDF2] for key derivation algorithms. It MUST support AES key wrap (see [AES-WRAP] as the key encryption algorithm.
エンティティがEnvelopedDataまたはAuthenticatedDataのPasswordRecipientInfoをサポートしている場合、キー派生アルゴリズムのPBKDF2 [PBKDF2]をサポートする必要があります。AESキーラップ（[AES-Wrap]をキー暗号化アルゴリズムとして参照してください。
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: SHA-1 MUST be implemented for hashAlgId. SHA-256 SHOULD be implemented for hashAlgId. HMAC-SHA1 MUST be implemented for macAlgId. HMAC-SHA256 SHOULD be implemented for macAlgId.
アイデンティティ証明バージョン2コントロールのアルゴリズム要件（[CMC-struct]のセクション6.2.1）は次のとおりです。SHA-1は、hashalgidのために実装する必要があります。SHA-256はハシャルギー用に実装する必要があります。HMAC-SHA1はMacalGIDに実装する必要があります。HMAC-SHA256はMacalGID用に実装する必要があります。
Algorithm requirements for the Pop Link Witness Version 2 control (Section 6.3.1 of [CMC-STRUCT]) are: SHA-1 MUST be implemented for keyGenAlgorithm. SHA-256 SHOULD be implemented for keyGenAlgorithm. PBKDF2 [PBKDF2] MAY be implemented for keyGenAlgorithm. HMAC-SHA1 MUST be implemented for macAlgorithm. HMAC-SHA256 SHOULD be implemented for macAlgorithm.
POP Link Witnessバージョン2コントロール（[CMC-struct]のセクション6.3.1）のアルゴリズム要件は次のとおりです。SHA-1は、keygenalgorithmに実装する必要があります。SHA-256は、keygenalgorithmに実装する必要があります。PBKDF2 [PBKDF2]は、keygenalgorithmに実装できます。HMAC-SHA1は、マカルゴリズムに実装する必要があります。HMAC-SHA256は、マカルゴリズムに実装する必要があります。
Algorithm requirements for the Encrypted POP and Decrypted POP controls (Section 6.7 of [CMC-STRUCT]) are: SHA-1 MUST be implemented for witnessAlgID. SHA-256 SHOULD be implemented for witnessAlgID. HMAC-SHA1 MUST be implemented for thePOPAlgID. HMAC-SHA256 SHOULD be implemented for thePOPAlgID.
暗号化されたPOPおよび復号化されたPOPコントロールのアルゴリズム要件（[CMC-struct]のセクション6.7）は次のとおりです。SHA-1は、WithingalGidのために実装する必要があります。SHA-256は、WithingalGidのために実装する必要があります。hmac-sha1は、ポパルジッドのために実装する必要があります。hmac-sha256は、popalgid用に実装する必要があります。
Algorithm requirements for Publish Trust Anchors control (Section 6.15 of [CMC-STRUCT]) are: SHA-1 MUST be implemented for hashAlgorithm. SHA-256 SHOULD be implemented for hashAlgorithm.
パブリッシュトラストアンカーコントロール（[CMC-struct]のセクション6.15）のアルゴリズム要件は次のとおりです。SHA-1はハシャルゴリズムに実装する必要があります。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をサポートする必要があります。EESは[DH-POP]のセクション3をサポートする場合があります。POP検証を行うCASとRASは、[DH-POP]のセクション4をサポートする必要があり、[DH-POP]のセクション3をサポートする必要があります。
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.
署名を作成できないキーに署名アルゴリズムを使用する必要があるEESは、[CMC-struct]の付録Cをサポートし、暗号化/復号化されたポップコントロールをサポートする必要があります。ポップ検証を行うCASとRASは、この署名アルゴリズムをサポートし、暗号化/復号化されたポップコントロールをサポートする必要があります。
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) |
| | | | |
| Authenticate 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) |
+----------------------------+----------+----------+----------+
Table 1: CMC Control Attributes
表1：CMC制御属性
Notes:
ノート：
1. CAs SHOULD implement this control if designed to work with RAs.
1. CASは、RASで動作するように設計されている場合、このコントロールを実装する必要があります。
2. CAs MUST implement this control if designed to work with RAs.
2. CASは、RASで動作するように設計されている場合、このコントロールを実装する必要があります。
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. EESは、（a）キー契約アルゴリズムをサポートする場合、または（b）ハードウェアキーがPOPを提供できない環境で動作する必要がある場合にのみこれを実装する必要があります。
5. RAs SHOULD implement this if they implement RA POP Witness.
5. RAは、RA POP証人を実装する場合、これを実装する必要があります。
Strong consideration should be given to implementing the Authenticate Data and Publish Trust Anchors controls as this gives a simple method for distributing trust anchors into 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 controls identification and identityProof will perform the same service and are more specifically defined.
登録制御トークンID-regctrl-regtokenおよびid-regctrl-authtokenは使用してはなりません。これらのアイテムを交換するために特定のCMC機能は使用されませんが、一般にCMCコントロールの識別とIDPROOFは同じサービスを実行し、より具体的に定義されています。
The control token id-regCtrl-pkiArchiveOptions SHOULD NOT be supported. An alternative method is under development to provide this functionality.
コントロールトークンID-regctrl-pkiarchiveoptionsはサポートされるべきではありません。この機能を提供するための代替方法が開発中です。
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 entity implements Diffie-Hellman, it MUST implement either the DH-POP Proof-of-Possession as defined in [DH-POP], Section 4, or the challenge-response POP controls id-cmc-encryptedPOP and id-cmc-decryptedPOP.
エンティティがdiffie-hellmanを実施する場合、[DH-POP]、セクション4、またはChallenge-Response Pop Controls ID-CMC-IncryptedPopおよびID-CMC-で定義されているDH-POP Proof-of-Possessionのいずれかを実装する必要があります。DecryptedPop。
RAs SHOULD be able to do delegated POP. RAs implementing this feature MUST implement the id-cmc-lraPOPWitness control.
RASは委任されたポップを行うことができるはずです。この機能を実装するRASは、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のプロモーションを実装する必要があります。
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.
CASがRASを使用して環境で機能するように提供することを強くお勧めします。このようなサポートの実装は、これにより、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.
CASは、証明書を発行する前に、すべてのパブリックキーの少なくとも最小限のチェックを実行する必要があります。少なくとも、ポップ操作で構文のチェックが発生します。さらに、CASは、DSA-SHA1およびDHキーの小さなサブグループ[小型グループ]またはRSAキーの既知の悪い指数など、既知の不良キーの簡単なチェックを実行する必要があります。
CAs MUST enforce POP checking before issuing any certificate. CAs MAY delegate the POP operation to an RA for those cases where 1) a challenge/response message pair must be used, 2) an RA performs escrow of a key and checks for POP in that manner, or 3) an unusual algorithm is used and that validation is done at the RA.
CASは、証明書を発行する前にポップチェックを実施する必要があります。CASは、1）チャレンジ/応答メッセージペアを使用する必要がある場合、2）RAがキーのエスクローを実行し、その方法でPOPをチェックする、または3）異常なアルゴリズムを使用する場合、POP操作をRAに委任することができます。そして、その検証はRAで行われます。
CAs SHOULD implement both the DH-POP Proof-of-Possession as defined in [DH-POP], Section 4, and the challenge-response POP controls id-cmc-encryptedPOP and id-cmc-decryptedPOP.
CASは、[DH-POP]、セクション4で定義されているDH-POP Proof-of-Possession、およびChallenge-Response Pop Controls ID-CMC-IncryptedPopとID-CMC-DecryptedPopの両方を実装する必要があります。
This document uses [CMC-STRUCT] and [CMC-TRANS] as building blocks to this document. 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]です。
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.
著者は、この文書に記載されている多くの概念を開発し、書くことの仕事について、ブライアン・ラマッキアに感謝したいと思います。著者はまた、アレックス・ディーコンとバーブ・フォックスの貢献に感謝したいと思います。
[CMC-STRUCT] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, June 2008.
[CMC-struct] Schaad、J。およびM. Myers、「CMS（CMC）の証明書管理」、RFC 5272、2008年6月。
[CMC-TRANS] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC): Transport Protocols", RFC 5273, June 2008.
[CMC-Trans] Schaad、J。およびM. Myers、「CMS（CMC）の証明書管理：輸送プロトコル」、RFC 5273、2008年6月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS] Housley、R。、「暗号化メッセージ構文（CMS）」、RFC 3852、2004年7月。
[CMS-AES] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.
[CMS-AES] Schaad、J。、「暗号化メッセージ構文（CMS）での高度な暗号化標準（AES）暗号化アルゴリズムの使用」、RFC 3565、2003年7月。
[CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[CMS-Alg] Housley、R。、「暗号化メッセージ構文（CMS）アルゴリズム」、RFC 3370、2002年8月。
[CMS-DH] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[CMS-DH] Rescorla、E。、「Diffie-Hellman Key Asmational Method」、RFC 2631、1999年6月。
[CRMF] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, September 2005.
[CRMF] Schaad、J。、「インターネットX.509公開キーインフラストラクチャ証明書リクエストメッセージフォーマット（CRMF）」、RFC 4211、2005年9月。
[CMS-RSA-OAEP] Housley, R., "Use of the RSAES-OAEP Key Transport Algorithm in the Cryptographic Message Syntax (CMS)", RFC 3560, July 2003.
[CMS-RSA-OAEP] Housley、R。、「暗号化メッセージ構文（CMS）でのRSAES-OAEPキートランスポートアルゴリズムの使用」、RFC 3560、2003年7月。
[CMS-RSA-PSS] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS)", RFC 4056, June 2005.
[CMS-RSA-PSS] Schaad、J。、「暗号化メッセージ構文（CMS）でのRSASSA-PSS署名アルゴリズムの使用」、RFC 4056、2005年6月。
[DH-POP] Prafullchandra, H. and J. Schaad, "Diffie-Hellman Proof-of-Possession Algorithms", RFC 2875, June 2000.
[DH-POP] Prafullchandra、H。およびJ. Schaad、「Diffie-Hellman Proof-of-Possession algorithms」、RFC 2875、2000年6月。
[MUST] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.
[必須] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、RFC 2119、BCP 14、1997年3月。
[RSA-256] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005.
[RSA-256] Schaad、J.、Kaliski、B。、およびR. Housley、「インターネットで使用するRSA暗号化の追加アルゴリズムと識別子X.509公開鍵インフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 4055、2005年6月。
[PBKDF2] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000.
[PBKDF2] Kaliski、B。、「PKCS＃5：パスワードベースの暗号化仕様バージョン2.0」、RFC 2898、2000年9月。
[AES-WRAP] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[AES-Wrap] Schaad、J。およびR. Housley、「Advanced Encryption Standard（AES）Key Wrap Algorithm」、RFC 3394、2002年9月。
[PKCS10] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification v1.7", RFC 2986, November 2000.
[PKCS10] Nystrom、M。およびB. Kaliski、「PKCS＃10：認定要求構文仕様V1.7」、RFC 2986、2000年11月。
[SMALL-SUB-GROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME", RFC 2785, March 2000.
[Small-Sub-Group] Zuccherato、R。、「S/MIMEのDiffie-Hellmanキー契約法に対する「小型」攻撃を回避する方法」、RFC 2785、2000年3月。
[HASH-ATTACKS] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[ハッシュ攻撃] Hoffman、P。およびB. Schneier、「インターネットプロトコルにおける暗号化のハッシュに対する攻撃」、RFC 4270、2005年11月。
Authors' Addresses
著者のアドレス
Jim Schaad Soaring Hawk Consulting PO Box 675 Gold Bar, WA 98251
Jim Schaad Soaring Hawk Consulting Po Box 675 Gold Bar、WA 98251
Phone: (425) 785-1031 EMail: jimsch@nwlink.com
電話：（425）785-1031メール：jimsch@nwlink.com
Michael Myers TraceRoute Security, Inc.
MichaelMyers Traceroute Security、Inc。
EMail: mmyers@fastq.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。