RFC5274 日本語訳
5274 Certificate Management Messages over CMS (CMC): ComplianceRequirements. J. Schaad, M. Myers. June 2008. (Format: TXT=27380 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Schaad
Request for Comments: 5274 Soaring Hawk Consulting
Category: Standards Track M. Myers
TraceRoute Security, Inc.
June 2008
Schaadがコメントのために要求するワーキンググループJ.をネットワークでつないでください: カテゴリに相談する5274年の高く昇っているタカ: 標準化過程M.マイアーズトレースルートセキュリティInc.2008年6月
Certificate Management Messages over CMS (CMC): Compliance Requirements
cm(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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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.
このドキュメントは1セットのCMC(CMSの上の証明書Management)登録プロトコルに関する承諾声明を提供します。 ASN.1構造とCMC登録プロトコルのための移送機構は他のドキュメントで含まれています。 このドキュメントは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
1. 概観. . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 要件用語. . . . . . . . . . . . . . . . . . . 3 4 すべての実体. . . . . . . . . . . . . . . . 3 4.1のための要件。 暗号アルゴリズム要件. . . . . . . . . . . 4 4.2。 コントロール. . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3。 CRMFは要件. . . . . . . . . . . . . . . . 8 4.4を特徴とします。 クライアント. . . . . . . . . . . . . . . . . 8 5のための要件。 サーバ. . . . . . . . . . . . . . . . . . . 8 6のための要件。 EEs. . . . . . . . . . . . . . . . . . . . . 8 7のための要件。 RAs. . . . . . . . . . . . . . . . . . . . . 8 8のための要件。 CAs. . . . . . . . . . . . . . . . . . . . . 9 9のための要件。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 9 10。 承認. . . . . . . . . . . . . . . . . . . . . . . 9 11。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 10 11.1。 引用規格. . . . . . . . . . . . . . . . . . . 10 11.2。 有益な参照. . . . . . . . . . . . . . . . . . 11
Schaad & Myers Standards Track [Page 1] RFC 5274 CMC: Compliance June 2008
Schaadとマイアーズ規格はRFC5274CMCを追跡します[1ページ]: 承諾2008年6月
1. Overview
1. 概観
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の上の証明書Management)プロトコルはクライアント/サーバ関係で設計されています。 最も簡単な場合では、クライアントは証明書(すなわち、End Entity(EE))の要請者です、そして、サーバは証明書(すなわち、認証局(カリフォルニア))の発行人です。 エージェントのセットへのRegistration Authority(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.
RAsは現在このドキュメントでカバーされていない専門化している目的に役立つかもしれません。 そのような目的の1つはKey Escrowエージェントでしょう。 そういうものとして、暗号化キーを求めるすべての証明書要求がこのRAを通して向けられるでしょう、そして、それは、記録保管所でキーをするために適切な行動を取るでしょう。 Key Escrowエージェントが最終的なサーバとしてエージェントのチェーンで機能するその操作を実行するのを許容する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.
システムに複数のRAsがあれば、すべてのRAsがすべての証明書要求を見るというわけではないのは正常であると考えられます。 RAsの間のルーティングは要求がかかわった証明書の中身に依存しているかもしれません。
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歳のクライアント) すべてのEnd-実体、5) すべてのRegistration Entities、6) すべてのCertificate Authorities。
2. Terminology
2. 用語
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.
登録Authority(RA)かLocal RA(LRA)がEEとカリフォルニアの間の仲介者として機能する実体について言及します。 複数のRAsがEnd-実体と認証局の間に存在できます。 RAsは記録保管所でキー生成かキーなどの追加サービスを実行するかもしれません。 このドキュメントはRAとLRAの両方にRAという用語を使用します。
Schaad & Myers Standards Track [Page 2] RFC 5274 CMC: Compliance June 2008
Schaadとマイアーズ規格はRFC5274CMCを追跡します[2ページ]: 承諾2008年6月
Certification Authority (CA) refers to the entity that issues
certificates.
認証局(カリフォルニア)は証明書を発行する実体について言及します。
Client refers to an entity that creates a PKI Request. In this
document, both RAs and EEs can be clients.
クライアントはPKI Requestを作成する実体について言及します。 本書では、RAsとEEsの両方がクライアントであるかもしれません。
Server refers to the entities that process PKI Requests and create
PKI Responses. In this document both CAs and RAs can be servers.
サーバはPKI Requestsを処理して、PKI Responsesを作成する実体について言及します。 本書ではCAsとRAsの両方がサーバであるかもしれません。
PKCS #10 refers to the Public Key Cryptography Standard #10
[PKCS10], which defines a certification request syntax.
PKCS#10はPublic Key Cryptography Standard#10[PKCS10]について言及します。(Cryptographyは証明要求構文を定義します)。
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はCertificate Request Message Format 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はCryptographic Message Syntax 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 Request/応答は本書では説明された要求/応答について言及します。 PKI Requestsは証明要求、取消し要求などを含んでいます。 PKI Responsesは本命だけメッセージ、失敗メッセージなどを含んでいます。
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ラッピング層について言及します。
3. Requirements Terminology
3. 要件用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[MUST]で説明されるように本書では解釈されることであるべきですか?
4. Requirements for All Entities
4. すべての実体のための要件
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.
すべての実体がFull PKI Requests、Simple PKI Responses、およびFull PKI Responsesを支持しなければなりません。 サーバSHOULDはSimple PKI Requestsを支持します。
Schaad & Myers Standards Track [Page 3] RFC 5274 CMC: Compliance June 2008
Schaadとマイアーズ規格はRFC5274CMCを追跡します[3ページ]: 承諾2008年6月
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構文のサポートは、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分野が使用されているなら、追加CMCStatusInfoV2の品目がfailInfo分野で同じ身体の部分に存在することが提案されます。
All entities MUST implement the HTTP transport mechanism as defined in [CMC-TRANS]. Other transport mechanisms MAY be implemented.
すべての実体が[CMC-TRANS]で定義されるようにHTTP移送機構を実行しなければなりません。 他の移送機構は実行されるかもしれません。
4.1. Cryptographic Algorithm Requirements
4.1. 暗号アルゴリズム要件
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.
すべての実体がEnvelopedDataに、主要な輸送アルゴリズムとしてRSAを支持しなければなりません([CMS-ALG]を見てください)。 すべての実体SHOULDが主要な輸送アルゴリズムとしてRSA-OAEP([CMS-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を支持しなければなりません。([AES-WRAP]を主要な暗号化アルゴリズムであるとみなしてください。
If AuthenticatedData is supported, PasswordRecipientInfo MUST be supported.
AuthenticatedDataが支持されるなら、PasswordRecipientInfoを支持しなければなりません。
Schaad & Myers Standards Track [Page 4] RFC 5274 CMC: Compliance June 2008
Schaadとマイアーズ規格はRFC5274CMCを追跡します[4ページ]: 承諾2008年6月
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.
Identity Proofバージョン2コントロール(.1セクション6.2[CMC-STRUCT])のためのアルゴリズム要件は以下の通りです。 SHA-1 MUST、hashAlgIdには、実行されてください。 SHA-256 SHOULD、hashAlgIdには、実行されてください。 HMAC-SHA1 MUST、macAlgIdには、実行されてください。 HMAC-SHA256 SHOULD、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コントロール(.1セクション6.3[CMC-STRUCT])のためのアルゴリズム要件は以下の通りです。 SHA-1 MUST、keyGenAlgorithmには、実行されてください。 SHA-256 SHOULD、keyGenAlgorithmには、実行されてください。 PBKDF2[PBKDF2]はkeyGenAlgorithmのために実行されるかもしれません。 HMAC-SHA1 MUST、macAlgorithmには、実行されてください。 HMAC-SHA256 SHOULD、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.
Encrypted POPとDecrypted POPコントロール([CMC-STRUCT]のセクション6.7)のためのアルゴリズム要件は以下の通りです。 SHA-1 MUST、witnessAlgIDには、実行されてください。 SHA-256 SHOULD、witnessAlgIDには、実行されてください。 HMAC-SHA1 MUST、thePOPAlgIDには、実行されてください。 HMAC-SHA256 SHOULD、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.
Publish Trust Anchorsコントロール([CMC-STRUCT]のセクション6.15)のためのアルゴリズム要件は以下の通りです。 SHA-1 MUST、hashAlgorithmには、実行されてください。 SHA-256 SHOULD、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をサポートしなければなりません。 EEsは[DH-POP]のセクション3を支持するかもしれません。 POP検証をするCAsとRAsは[DH-POP]のセクション4と[DH-POP]のSHOULDサポートセクション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]のAppendix Cを支持しなければならなくて、Encrypted/解読されたPOPコントロールを支持しなければなりません。 POP検証をするCAsとRAsはこの署名アルゴリズムを支持しなければならなくて、Encrypted/解読されたPOPコントロールを支持しなければなりません。
Schaad & Myers Standards Track [Page 5] RFC 5274 CMC: Compliance June 2008
Schaadとマイアーズ規格はRFC5274CMCを追跡します[5ページ]: 承諾2008年6月
4.2. Controls
4.2. コントロール
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 |
| | | | |
+----------------------------+----------+----------+----------+ | コントロール| EE| RA| カリフォルニア| +----------------------------+----------+----------+----------+ | 拡張CMC状態インフォメーション| 必須| 必須| 必須| | | | | | | CMC状態インフォメーション| should| should| should| | | | | | | アイデンティティ証拠バージョン2| 必須| 必須| 必須| | | | | | | アイデンティティ証拠| should| should| should| | | | | | | 識別| 必須| 必須| 必須| | | | | | | 無作為の状態でリンクを飛び出させてください。| 必須| 必須| 必須| | | | | | | リンク目撃者バージョン2を飛び出させてください。| 必須| 必須| 必須| | | | | | | リンク目撃者を飛び出させてください。| should| 必須| 必須| | | | | | | データリターン| 必須| 必須| 必須| | | | | | | 本命要求を変更してください。| なし| 必須| (2) | | | | | | | 拡大を加えてください。| なし| 5月| (1) | | | | | | | 取引ID| 必須| 必須| 必須| | | | | | | 送付者一回だけ| 必須| 必須| 必須| | | | | | | 受取人一回だけ| 必須| 必須| 必須| | | | | | | コード化されて、飛び出してください。| (4) | (5) | should| | | | | | | 解読されて、飛び出してください。| (4) | (5) | should| | | | | | | RAは目撃者を飛び出させます。| なし| should| (1) | | | | | | | 証明書を手に入れてください。| 任意| 任意| 任意| | | | | | | CRLを手に入れてください。| 任意| 任意| 任意| | | | | | | 取消し要求| should| should| 必須| | | | | |
Schaad & Myers Standards Track [Page 6] RFC 5274 CMC: Compliance June 2008
Schaadとマイアーズ規格はRFC5274CMCを追跡します[6ページ]: 承諾2008年6月
| 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) |
+----------------------------+----------+----------+----------+
| 登録インフォメーション| should| should| should| | | | | | | 応答情報| should| should| should| | | | | | | 未定の質問| 必須| 必須| 必須| | | | | | | 本命を確認してください。 承認| 必須| 必須| 必須| | | | | | | 信用アンカーを発行してください。| (3) | (3) | (3) | | | | | | | データを認証してください。| (3) | (3) | (3) | | | | | | | バッチ要求| なし| 必須| (2) | | | | | | | バッチ応答| なし| 必須| (2) | | | | | | | 公表情報| 任意| 任意| 任意| | | | | | | コントロールは処理されました。| なし| 必須| (2) | +----------------------------+----------+----------+----------+
Table 1: CMC Control Attributes
テーブル1: CMCコントロール属性
Notes:
注意:
1. CAs SHOULD implement this control if designed to work with RAs.
1. RAsと共に働くように設計されるなら、CAs SHOULDはこのコントロールを実行します。
2. CAs MUST implement this control if designed to work with RAs.
2. RAsと共に働くように設計されるなら、CAsはこのコントロールを実行しなければなりません。
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. (a) 彼らが主要な協定アルゴリズムを支持するか、または(b) ハードウェアキーがPOPを提供できない環境で作動する必要がある場合にだけ、EEsは、これを実行する必要があります。
5. RAs SHOULD implement this if they implement RA POP Witness.
5. 彼らがRA POP Witnessを実行するなら、RAs SHOULDはこれを実行します。
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.
これがユーザ介入なしで信用アンカーをクライアントに分配するための簡単な方法を与えるとき、Authenticate DataとPublish Trust Anchorsコントロールを実行することに対して強い考慮を払うべきです。
Schaad & Myers Standards Track [Page 7] RFC 5274 CMC: Compliance June 2008
Schaadとマイアーズ規格はRFC5274CMCを追跡します[7ページ]: 承諾2008年6月
4.3. CRMF Feature Requirements
4.3. CRMF特徴要件
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.
登録コントロール象徴のイド-regCtrl-regTokenとイド-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.
象徴イド-regCtrl-pkiArchiveOptions SHOULDを制御してください。支持されません。 別法は、この機能性を提供するために開発中です。
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.
イド-regCtrl-oldCertIDの動きは現在、使用されません。 それを公表から古い証明書を取り外すのに新しい証明書を発行して、イド-cmc- publishCertを使用すると取り替えます。 古い証明書の即座の取消しで通常、この操作は伴われないでしょう。 しかしながら、イド-cmc-revokeRequestコントロールでそれを達成できます。
The id-regCtrl-protocolEncrKey is not used.
イド-regCtrl-protocolEncrKeyは使用されていません。
4.4. Requirements for Clients
4.4. クライアントのための要件
There are no additional requirements.
どんな追加要件もありません。
5. Requirements for Servers
5. サーバのための要件
There are no additional requirements.
どんな追加要件もありません。
6. Requirements for EEs
6. EEsのための要件
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.
実体がディフィー-ヘルマンを実行するなら、それはチャレンジレスポンスPOPコントロールの[DH-POP]か、セクション4か、イド-cmc-encryptedPOPとイド-cmc- decryptedPOPで定義されるように所有物のDH-POP Proofを実行しなければなりません。
7. Requirements for RAs
7. RAsのための要件
RAs SHOULD be able to do delegated POP. RAs implementing this feature MUST implement the id-cmc-lraPOPWitness control.
RAs SHOULD、代表として派遣されたPOPができてください。 この特徴を実行するRAsはイド-cmc-lraPOPWitnessコントロールを実行しなければなりません。
All RAs MUST implement the promotion of the id-aa-cmc-unsignedData as covered in Section 3.2.3 of [CMC-STRUCT].
すべてのRAsが.3セクション3.2[CMC-STRUCT]の覆われるとしてのイド-aa-cmc-unsignedDataの販売促進を実行しなければなりません。
Schaad & Myers Standards Track [Page 8] RFC 5274 CMC: Compliance June 2008
Schaadとマイアーズ規格はRFC5274CMCを追跡します[8ページ]: 承諾2008年6月
8. Requirements for CAs
8. CAsのための要件
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.
RAsと共に環境で働くためにCAsに備えるのは強く示されます。 これがかなりの管理相互作用の代表団をカリフォルニアでというよりむしろ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は証明書を下付する前に、すべての公開鍵に少なくとも最小量のチェックを実行しなければなりません。 最小限では、構文のためのチェックはPOP操作で起こるでしょう。 さらに、CAs SHOULDはRSAキーのための小さいサブグループなどの知られているDSA-SHA1に、悪いキーとDHキー[SMALL-SUB-GROUP]か知られている悪い解説者のための簡単なチェックを実行します。
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はどんな証明書も発行する前にチェックするPOPを実施しなければなりません。 珍しいアルゴリズムあたり3は)使用されています、そして、挑戦/応答メッセージあたり1が)対にされるそれらのケースのためのRAへのPOP操作がそうしなければならないCAs5月の代表が使用されて、1RAあたり2が、)キーのエスクローを実行して、POPがないかどうかそんなふうにチェックするか、またはその合法化を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 SHOULDは[DH-POP]で定義される、所有物のDH-POP Proofと、セクション4と、チャレンジレスポンスPOP規制イドcmc-encryptedPOPとイド-cmc-decryptedPOPの両方を実行します。
9. Security Considerations
9. セキュリティ問題
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].
暗号アルゴリズムが弱めて、壊されるか、または弱められるでしょう。 Implementersとユーザは、本書では記載された暗号アルゴリズムがセキュリティー・レベルから理解できるのをチェックする必要があります。 IETFは時々芸術の現状に対処するドキュメントを発行するかもしれません。 そのようなドキュメントに関する2つの例が、[SMALL-SUB-GROUP]と[HASH-ATTACKS]です。
10. Acknowledgements
10. 承認
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リュウとジェフ・ワインスタインの参加に感謝しています。
Schaad & Myers Standards Track [Page 9] RFC 5274 CMC: Compliance June 2008
Schaadとマイアーズ規格はRFC5274CMCを追跡します[9ページ]: 承諾2008年6月
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.
作者は彼の仕事について本書では提示された概念の多くを開発して、詳しく書く際にブライアンLaMacchiaに感謝したがっています。 また、作者は彼らの貢献についてアレックスDeaconとバーブフォックスに感謝したがっています。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[CMC-STRUCT] Schaad, J. and M. Myers, "Certificate Management
over CMS (CMC)", RFC 5272, June 2008.
[CMC-STRUCT] SchaadとJ.とM.マイアーズ、「cm(CMC)の上の証明書管理」、RFC5272、2008年6月。
[CMC-TRANS] Schaad, J. and M. Myers, "Certificate Management
over CMS (CMC): Transport Protocols", RFC 5273,
June 2008.
[CMC、-、移-、]、Schaad、J.、およびM.マイアーズ、「cm(CMC)の上の管理を証明してください」 「トランスポート・プロトコル」、RFC5273、2008年6月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, July 2004.
[cm] Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、2004年7月。
[CMS-AES] Schaad, J., "Use of the Advanced Encryption
Standard (AES) Encryption Algorithm in
Cryptographic Message Syntax (CMS)", RFC 3565,
July 2003.
[cm-AES]Schaad、J.、「暗号のメッセージ構文(cm)におけるエー・イー・エス(AES)暗号化アルゴリズムの使用」、RFC3565(2003年7月)。
[CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002.
[cm-ALG] Housley、R.、「暗号のメッセージ構文(cm)アルゴリズム」、RFC3370、2002年8月。
[CMS-DH] Rescorla, E., "Diffie-Hellman Key Agreement
Method", RFC 2631, June 1999.
[cm-DH] レスコラ、E.、「ディフィー-ヘルマンの主要な協定方法」、RFC2631、1999年6月。
[CRMF] Schaad, J., "Internet X.509 Public Key
Infrastructure Certificate Request Message Format
(CRMF)", RFC 4211, September 2005.
J.、「インターネットX.509公開鍵暗号基盤証明書要求メッセージ形式(CRMF)」、RFC4211 2005年9月の[CRMF]Schaad。
[CMS-RSA-OAEP] Housley, R., "Use of the RSAES-OAEP Key Transport
Algorithm in the Cryptographic Message Syntax
(CMS)", RFC 3560, July 2003.
[cm-RSA-OAEP] Housley、R.、「暗号のメッセージ構文(cm)におけるRSAES-OAEPの主要な輸送アルゴリズムの使用」、RFC3560、2003年7月。
[CMS-RSA-PSS] Schaad, J., "Use of the RSASSA-PSS Signature
Algorithm in Cryptographic Message Syntax (CMS)",
RFC 4056, June 2005.
[cm-RSA-PSS]Schaad、J.、「暗号のメッセージ構文(cm)におけるRSASSA-PSS署名アルゴリズムの使用」、RFC4056、2005年6月。
[DH-POP] Prafullchandra, H. and J. Schaad, "Diffie-Hellman
Proof-of-Possession Algorithms", RFC 2875,
June 2000.
[DH大衆的な] PrafullchandraとH.とJ.Schaad、「ディフィー-ヘルマン所有物の証拠アルゴリズム」、RFC2875、2000年6月。
Schaad & Myers Standards Track [Page 10] RFC 5274 CMC: Compliance June 2008
Schaadとマイアーズ規格はRFC5274CMCを追跡します[10ページ]: 承諾2008年6月
[MUST] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", RFC 2119, BCP 14,
March 1997.
[MUST]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、BCP14、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、および「中のインターネットX.509公開鍵暗号基盤CertificateとCertificate Revocation List(CRL)が輪郭を描く使用のためのRSA Cryptographyのための追加AlgorithmsとIdentifiers」、RFC4055(2005年6月)
[PBKDF2] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898,
September 2000.
[PBKDF2]Kaliski、B.、「PKCS#5:」 パスワードベースの暗号仕様バージョン2インチ、RFC2898、2000年9月。
[AES-WRAP] Schaad, J. and R. Housley, "Advanced Encryption
Standard (AES) Key Wrap Algorithm", RFC 3394,
September 2002.
[AES-包装] SchaadとJ.とR.Housley、「エー・イー・エス(AES)の主要な包装アルゴリズム」、RFC3394、2002年9月。
11.2. Informative References
11.2. 有益な参照
[PKCS10] Nystrom, M. and B. Kaliski, "PKCS #10:
Certification Request Syntax Specification v1.7",
RFC 2986, November 2000.
[PKCS10] ニストロム、M.、およびB.Kaliski、「PKCS#10:」 証明Request Syntax Specification v1.7"、2000年11月の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,
March 2000.
[小さいサブグループ] Zuccherato、R.、「S/MIMEのためにディフィー-ヘルマンの主要な協定方法に対する「小さいサブグループ」攻撃を避けるための方法」、RFC2785(2000年3月)。
[HASH-ATTACKS] Hoffman, P. and B. Schneier, "Attacks on
Cryptographic Hashes in Internet Protocols",
RFC 4270, November 2005.
[細切れ肉料理攻撃] ホフマンとP.とB.シュナイアー、「暗号に対する攻撃はインターネットでプロトコルを論じ尽くす」RFC4270、2005年11月。
Schaad & Myers Standards Track [Page 11] RFC 5274 CMC: Compliance June 2008
Schaadとマイアーズ規格はRFC5274CMCを追跡します[11ページ]: 承諾2008年6月
Authors' Addresses
作者のアドレス
Jim Schaad Soaring Hawk Consulting PO Box 675 Gold Bar, WA 98251
ジムSchaad高く昇るタカのコンサルティング私書箱675金の延べ棒、ワシントン 98251
Phone: (425) 785-1031 EMail: jimsch@nwlink.com
以下に電話をしてください。 (425) 785-1031 メールしてください: jimsch@nwlink.com
Michael Myers TraceRoute Security, Inc.
マイケルマイアーズトレースルートセキュリティInc.
EMail: mmyers@fastq.com
メール: mmyers@fastq.com
Schaad & Myers Standards Track [Page 12] RFC 5274 CMC: Compliance June 2008
Schaadとマイアーズ規格はRFC5274CMCを追跡します[12ページ]: 承諾2008年6月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Schaad & Myers Standards Track [Page 13]
Schaadとマイアーズ標準化過程[13ページ]
一覧
スポンサーリンク
