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は、証明書要求に関して、サーバーとなり、証明書発行者に対するクライアントになります。 Rasの任意の数は、このように画像に挿入することができます。
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は現在、このドキュメントでカバーされていない、特殊な目的を果たすことができます。その一つの目的は、キーエスクロー・エージェントになります。そのため、暗号化キーのためのすべての証明書要求は、この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はエンドエンティティと認証局の間に存在することができます。 RAは、このようなキー生成やキーのアーカイブなどの追加サービスを行うことができます。この文書では、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.
Serverは、PKIの要求を処理し、PKI応答を作成するエンティティを指します。この文書では、両方のCAとRAはサーバーにすることができます。
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.
プルーフ・オブ・持ち手（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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[MUST]に記載されているように解釈されます。
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フィールドが使用される場合、追加のCMCStatusInfoV2項目がfailInfoフィールドと同一の身体部分のために存在することが示唆されます。
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]).
すべてのエンティティは（[CMS-ALG]を参照）のSignedDataでDSA-SHA1およびRSA-SHA1署名を確かめなければなりません。エンティティは、他の署名アルゴリズムを検証することができます。それは強く（[CMS-RSA-PSS]参照）SHA-1とRSA-PSSを検証することを示唆しています。それは強くSHA-256使ってRSAとRSA-PSSを検証することが示唆された（参照[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.
すべてのエンティティは（[CMS-ALG]を参照）のSignedDataのためのDSA-SHA1またはRSA-SHA1署名のいずれかを発生させなければなりません。他の署名アルゴリズムを生成するために使用されるかもしれません。
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.
すべてのエンティティは（[CMS-AES]を参照）EnvelopedDataのためのコンテンツ暗号化アルゴリズムとしてAES（Advanced Encryption Standard）をサポートしなければなりません。その他のコンテンツの暗号化アルゴリズムを実装することができます。
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.
すべてのエンティティがEnvelopedDataのための主要な輸送アルゴリズムとしてRSAをサポートしなければならない（参照[CMS-ALG]）。すべてのエンティティは、キートランスポートアルゴリズムとして（[CMS-RSA-OAEP]を参照）RSA-OAEPをサポートする必要があります。その他の主要な輸送アルゴリズムが実装されてもよいです。
If an entity supports key agreement for EnvelopedData, it MUST support Diffie-Hellman (see [CMS-DH]).
エンティティがEnvelopedDataのための重要な合意をサポートしている場合、それはディフィー・ヘルマン（参照[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-WRAP]を参照してくださいAESキーラップをサポートしなければなりません。
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は、hashAlgIdのために実施されるべきです。 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.
ポップリンク証人バージョン2制御（[CMC-STRUCT]のセクション6.3.1）のためのアルゴリズムの要件は次のとおりSHA-1はkeyGenAlgorithmために実施されなければなりません。 SHA-256は、keyGenAlgorithmのために実施されるべきです。 PBKDF2は、[PBKDF2] keyGenAlgorithmのために実施することができます。 HMAC-SHA1はmacAlgorithmのために実装しなければなりません。 HMAC-SHA256はmacAlgorithmのために実施されるべきです。
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はwitnessAlgIDために実施されなければなりません。 SHA-256は、witnessAlgIDのために実施されるべきです。 HMAC-SHA1はthePOPAlgIDのために実装しなければなりません。 HMAC-SHA256はthePOPAlgIDのために実施されるべきです。
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.
トラストアンカーを発行制御のためのアルゴリズム要件（セクション6.15 [CMC-STRUCT]）である：SHA-1 hashAlgorithmのために実装しなければなりません。 SHA-256は、hashAlgorithmのために実施されるべきです。
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をサポートしなければなりません。 EEのは、[DH-POP]のセクション3をサポートするかもしれません。 POP検証を行うCAおよびRAは、[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.
[CMC-STRUCT]の付録Cをサポートしなければならない署名を生成することができず、暗号化/復号化さPOPコントロールをサポートしなければならないキーの署名アルゴリズムを使用する必要のEE。 POP検証を行うCAおよびRAは、この署名アルゴリズムをサポートしなければならないし、暗号化/復号化されたPOPのコントロールをサポートしなければなりません。
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:
ノート：
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を提供することができない環境で動作する必要がある場合は、これを実装する必要があります。
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は、識別を制御し、identityProofが同じサービスを実行し、より具体的に定義されています。
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.
エンティティは、ディフィー・ヘルマンを実装している場合、それは実証の所有で定義されているDH-POPのいずれかを実装しなければならない[DH-POP]、第4、またはチャレンジレスポンスPOPコントロールID-CMC encryptedPOP及びID-CMC- decryptedPOP。
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].
[CMC-STRUCT]のセクション3.2.3でカバーされてすべてのRAは、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.
CAが強く示唆されたRAのある環境で動作するために提供します。これはRAの上ではなく、CAでかなりの行政の相互作用の委任を許可するような支援の実施を強く示唆しています
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は、証明書を発行する前に、すべての公開鍵に少なくとも最小限のチェックを実行しなければなりません。最低でも、構文のチェックは、POP操作で発生します。また、CAは、このような小さな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.
CAはすべての証明書を発行する前にPOPチェックを強制しなければなりません。 CAは、1）チャレンジ/レスポンスのメッセージペアが使用されなければならないような場合のためにRAにPOP操作を委任することができる、2）RAは、そのようにしてPOPのためのキーのエスクローとチェックを行い、または3）異常なアルゴリズムが使用されていますそしてその検証は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.
CAは実証の所有DH-POPの両方を実装する必要がで定義されている[DH-POP]、第4、及びチャレンジレスポンスPOPを制御するencryptedPOP-ID-CMC及び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]を使用しています。これら二つの文書のセキュリティセクションを参照して含まれています。
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つの例は、[小サブグループ]および[HASH攻撃]。
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劉とジェフ・ワインスタインの参加に感謝しています。
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.マイヤーズ、 "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.マイヤーズ、 "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.、RFC 3565、2003年7月 "のAdvanced Encryption Standard（AES）暗号メッセージ構文（CMS）での暗号化アルゴリズムの使用"。
[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]レスコラ、E.、 "ディフィー・ヘルマン鍵共有方式"、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.、RFC 4056、2005年6月 "暗号メッセージ構文（CMS）でRSASSA-PSS署名アルゴリズムの使用"。
[DH-POP] Prafullchandra, H. and J. Schaad, "Diffie-Hellman Proof-of-Possession Algorithms", RFC 2875, June 2000.
[DH-POP] Prafullchandra氏、H.及びJ. Schaad、 "ディフィー - ヘルマンプルーフ・オブ・所有アルゴリズム"、RFC 2875、2000年6月。
[MUST] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.
ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、RFC 2119、BCP 14、1997年3月[MUST]。
[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氏、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィールで使用するRSA暗号のための追加のアルゴリズムと識別子"、 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氏、 "高度暗号化標準（AES）キーラップアルゴリズム"、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.
[HASH攻撃]ホフマン、P.とB.シュナイアー、「インターネットプロトコルで暗号化ハッシュに対する攻撃」、RFC 4270、2005年11月。
Authors' Addresses
著者のアドレス
Jim Schaad Soaring Hawk Consulting PO Box 675 Gold Bar, WA 98251
ジムSchaad高騰ホークコンサルティング私書箱675ゴールドバー、WA 98251
Phone: (425) 785-1031 EMail: jimsch@nwlink.com
電話：（425）785-1031 Eメール：jimsch@nwlink.com
Michael Myers TraceRoute Security, Inc.
マイケル・マイヤーズTRACEROUTE Security社
EMail: mmyers@fastq.com
メールアドレス：mmyers@fastq.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。