RFC5272 日本語訳
5272 Certificate Management over CMS (CMC). J. Schaad, M. Myers. June 2008. (Format: TXT=167138 bytes) (Obsoletes RFC2797) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Schaad
Request for Comments: 5272 Soaring Hawk Consulting
Obsoletes: 2797 M. Myers
Category: Standards Track TraceRoute Security, Inc.
June 2008
Schaadがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 5272年の高く昇っているタカのコンサルティングは以下を時代遅れにします。 2797年のM.マイアーズカテゴリ: 標準化過程トレースルートセキュリティInc.2008年6月
Certificate Management over CMS (CMC)
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 defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community:
このドキュメントはCMC、Cryptographic Message Syntax(CMS)を使用するCertificate Managementプロトコルのためにベース構文を定義します。 このプロトコルはインターネット公開鍵暗号基盤(PKI)共同体の中の2つの即座の必要性を記述します:
1. The need for an interface to public key certification products
and services based on CMS and PKCS #10 (Public Key Cryptography
Standard), and
1. そして公開鍵証明製品とサービスへのインタフェースの必要性が#10(公開鍵暗号化標準)をCMSとPKCSに基づかせた。
2. The need for a PKI enrollment protocol for encryption only keys
due to algorithm or hardware design.
2. アルゴリズムかハードウェアによるキーだけが設計する暗号化のためのPKI登録プロトコルの必要性。
CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition.
また、CMCはこのドキュメントに伴う運送書類と要件用法ドキュメントの完全な定義の使用を必要とします。
Schaad & Myers Standards Track [Page 1] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[1ページ]: 2008年6月を構造化します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Terminology . . . . . . . . . . . . . . . . . 5
1.3. Changes since RFC 2797 . . . . . . . . . . . . . . . . . . 5
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Protocol Requests/Responses . . . . . . . . . . . . . . . 9
3. PKI Requests . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Simple PKI Request . . . . . . . . . . . . . . . . . . . . 10
3.2. Full PKI Request . . . . . . . . . . . . . . . . . . . . . 12
3.2.1. PKIData Content Type . . . . . . . . . . . . . . . . . 13
3.2.1.1. Control Syntax . . . . . . . . . . . . . . . . . . 14
3.2.1.2. Certification Request Formats . . . . . . . . . . 15
3.2.1.2.1. PKCS #10 Certification Syntax . . . . . . . . 16
3.2.1.2.2. CRMF Certification Syntax . . . . . . . . . . 17
3.2.1.2.3. Other Certification Request . . . . . . . . . 18
3.2.1.3. Content Info Objects . . . . . . . . . . . . . . . 19
3.2.1.3.1. Authenticated Data . . . . . . . . . . . . . . 19
3.2.1.3.2. Data . . . . . . . . . . . . . . . . . . . . . 20
3.2.1.3.3. Enveloped Data . . . . . . . . . . . . . . . . 20
3.2.1.3.4. Signed Data . . . . . . . . . . . . . . . . . 20
3.2.1.4. Other Message Bodies . . . . . . . . . . . . . . . 21
3.2.2. Body Part Identification . . . . . . . . . . . . . . . 21
3.2.3. CMC Unsigned Data Attribute . . . . . . . . . . . . . 22
4. PKI Responses . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1. Simple PKI Response . . . . . . . . . . . . . . . . . . . 23
4.2. Full PKI Response . . . . . . . . . . . . . . . . . . . . 24
4.2.1. PKIResponse Content Type . . . . . . . . . . . . . . . 24
5. Application of Encryption to a PKI Request/Response . . . . . 25
6. Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1. CMC Status Info Controls . . . . . . . . . . . . . . . . . 28
6.1.1. Extended CMC Status Info Control . . . . . . . . . . . 28
6.1.2. CMC Status Info Control . . . . . . . . . . . . . . . 30
6.1.3. CMCStatus Values . . . . . . . . . . . . . . . . . . . 31
6.1.4. CMCFailInfo . . . . . . . . . . . . . . . . . . . . . 32
6.2. Identification and Identity Proof Controls . . . . . . . . 33
6.2.1. Identity Proof Version 2 Control . . . . . . . . . . . 33
6.2.2. Identity Proof Control . . . . . . . . . . . . . . . . 35
6.2.3. Identification Control . . . . . . . . . . . . . . . . 35
6.2.4. Hardware Shared-Secret Token Generation . . . . . . . 36
6.3. Linking Identity and POP Information . . . . . . . . . . . 36
6.3.1. Cryptographic Linkage . . . . . . . . . . . . . . . . 37
6.3.1.1. POP Link Witness Version 2 Controls . . . . . . . 37
6.3.1.2. POP Link Witness Control . . . . . . . . . . . . . 38
6.3.1.3. POP Link Random Control . . . . . . . . . . . . . 38
6.3.2. Shared-Secret/Subject DN Linking . . . . . . . . . . . 39
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1。 要件. . . . . . . . . . . . . . . . . . 4 1.2について議定書の中で述べてください。 要件用語. . . . . . . . . . . . . . . . . 5 1.3 RFC2797.5 2以来の変化。 概観. . . . . . . . . . . . . . . . . . . . . . 5 2.1について議定書の中で述べてください。 用語. . . . . . . . . . . . . . . . . . . . . . . 7 2.2。 要求/応答. . . . . . . . . . . . . . . 9 3について議定書の中で述べてください。 PKIは.103.1を要求します。 簡単なPKIは.103.2を要求します。 完全なPKI要求. . . . . . . . . . . . . . . . . . . . . 12 3.2.1。 PKIData満足しているタイプ. . . . . . . . . . . . . . . . . 13 3.2.1.1。 コントロール構文. . . . . . . . . . . . . . . . . . 14 3.2.1.2。 証明は書式. . . . . . . . . . 15 3.2を要求します。.1 .2 .1。 PKCS#10証明構文. . . . . . . . 16 3.2.1.2.2。 CRMF証明構文. . . . . . . . . . 17 3.2.1.2.3。 他の証明要求. . . . . . . . . 18 3.2.1.3。 内容インフォメーションは反対します。.193.2 .1 .3 .1。 データを認証する、.193.2 .1 .3 .2。 データ、.203.2 .1 .3 .3。 データをおおう、.203.2 .1 .3 .4。 .4にデータ. . . . . . . . . . . . . . . . . 20 3.2.1にサインします。 他のメッセージ本体. . . . . . . . . . . . . . . 21 3.2.2。 ボディー部分識別. . . . . . . . . . . . . . . 21 3.2.3。 CMCの無記名のデータ属性. . . . . . . . . . . . . 22 4。 PKI応答. . . . . . . . . . . . . . . . . . . . . . . . 23 4.1。 簡単なPKI応答. . . . . . . . . . . . . . . . . . . 23 4.2。 完全なPKI応答. . . . . . . . . . . . . . . . . . . . 24 4.2.1。 PKIResponseの満足しているタイプ. . . . . . . . . . . . . . . 24 5。 PKI要求/応答. . . . . 25 6への暗号化の応用。 コントロール. . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.1。 CMC状態インフォメーションコントロール. . . . . . . . . . . . . . . . . 28 6.1.1。 拡張CMC状態インフォメーションコントロール. . . . . . . . . . . 28 6.1.2。 CMC状態インフォメーションコントロール. . . . . . . . . . . . . . . 30 6.1.3。 CMCStatusは.4に.316.1を評価します。 CMCFailInfo. . . . . . . . . . . . . . . . . . . . . 32 6.2。 識別とアイデンティティ証拠コントロール. . . . . . . . 33 6.2.1。 アイデンティティ証拠バージョン2コントロール. . . . . . . . . . . 33 6.2.2。 アイデンティティ証拠コントロール. . . . . . . . . . . . . . . . 35 6.2.3。 識別コントロール. . . . . . . . . . . . . . . . 35 6.2.4。 ハードウェア共有秘密キー象徴世代. . . . . . . 36 6.3。 アイデンティティと大衆的な情報. . . . . . . . . . . 36 6.3.1をリンクします。 暗号のリンケージ、.376.3 .1 .1。 リンク目撃者バージョン2コントロール. . . . . . . 37 6.3.1を.2に飛び出させてください。 リンク目撃者コントロール. . . . . . . . . . . . . 38 6.3.1.3を飛び出させてください。 リンクの無作為のコントロール. . . . . . . . . . . . . 38 6.3.2を飛び出させてください。 共有秘密キー/対象DNリンク. . . . . . . . . . . 39
Schaad & Myers Standards Track [Page 2] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[2ページ]: 2008年6月を構造化します。
6.3.3. Renewal and Rekey Messages . . . . . . . . . . . . . . 39
6.4. Data Return Control . . . . . . . . . . . . . . . . . . . 40
6.5. RA Certificate Modification Controls . . . . . . . . . . . 40
6.5.1. Modify Certification Request Control . . . . . . . . . 41
6.5.2. Add Extensions Control . . . . . . . . . . . . . . . . 42
6.6. Transaction Identifier Control and Sender and
Recipient Nonce Controls . . . . . . . . . . . . . . . . . 44
6.7. Encrypted and Decrypted POP Controls . . . . . . . . . . . 45
6.8. RA POP Witness Control . . . . . . . . . . . . . . . . . . 48
6.9. Get Certificate Control . . . . . . . . . . . . . . . . . 49
6.10. Get CRL Control . . . . . . . . . . . . . . . . . . . . . 49
6.11. Revocation Request Control . . . . . . . . . . . . . . . . 50
6.12. Registration and Response Information Controls . . . . . . 52
6.13. Query Pending Control . . . . . . . . . . . . . . . . . . 53
6.14. Confirm Certificate Acceptance Control . . . . . . . . . . 53
6.15. Publish Trust Anchors Control . . . . . . . . . . . . . . 54
6.16. Authenticated Data Control . . . . . . . . . . . . . . . . 55
6.17. Batch Request and Response Controls . . . . . . . . . . . 56
6.18. Publication Information Control . . . . . . . . . . . . . 57
6.19. Control Processed Control . . . . . . . . . . . . . . . . 58
7. Registration Authorities . . . . . . . . . . . . . . . . . . . 59
7.1. Encryption Removal . . . . . . . . . . . . . . . . . . . . 60
7.2. Signature Layer Removal . . . . . . . . . . . . . . . . . 61
8. Security Considerations . . . . . . . . . . . . . . . . . . . 61
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 63
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63
11.1. Normative References . . . . . . . . . . . . . . . . . . . 63
11.2. Informative References . . . . . . . . . . . . . . . . . . 63
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 65
Appendix B. Enrollment Message Flows . . . . . . . . . . . . . . 74
B.1. Request of a Signing Certificate . . . . . . . . . . . . . 74
B.2. Single Certification Request, But Modified by RA . . . . . 75
B.3. Direct POP for an RSA Certificate . . . . . . . . . . . . 78
Appendix C. Production of Diffie-Hellman Public Key
Certification Requests . . . . . . . . . . . . . . . 81
C.1. No-Signature Signature Mechanism . . . . . . . . . . . . . 81
6.3.3. 更新とRekeyメッセージ. . . . . . . . . . . . . . 39 6.4。 データはコントロール. . . . . . . . . . . . . . . . . . . 40 6.5を返します。 RAは変更コントロール. . . . . . . . . . . 40 6.5.1を証明します。 証明要求コントロール. . . . . . . . . 41 6.5.2を変更してください。 拡大が.426.6を制御すると言い足してください。 取引識別子コントロール、送付者、および受取人の一回だけのコントロール. . . . . . . . . . . . . . . . . 44 6.7。 大衆的なコントロール. . . . . . . . . . . 45 6.8であるとコード化されて、解読されます。 RAは目撃者コントロール. . . . . . . . . . . . . . . . . . 48 6.9を飛び出させます。 証明書コントロール. . . . . . . . . . . . . . . . . 49 6.10を手に入れてください。 CRLコントロール. . . . . . . . . . . . . . . . . . . . . 49 6.11を手に入れてください。 取消し要求コントロール. . . . . . . . . . . . . . . . 50 6.12。 登録と応答情報は.52 6.13を制御します。 未定のコントロール. . . . . . . . . . . . . . . . . . 53 6.14について質問してください。 証明書承認コントロール. . . . . . . . . . 53 6.15を確認してください。 アンカーが.54 6.16に制御する信用を発行してください。 認証されたデータは.55 6.17を制御します。 バッチ要求と応答制御. . . . . . . . . . . 56 6.18。 公表情報管理. . . . . . . . . . . . . 57 6.19。 コントロールはコントロール. . . . . . . . . . . . . . . . 58 7を加工処理しました。 登録局. . . . . . . . . . . . . . . . . . . 59 7.1。 暗号化取り外し. . . . . . . . . . . . . . . . . . . . 60 7.2。 署名層の除去. . . . . . . . . . . . . . . . . 61 8。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 61 9。 IANA問題. . . . . . . . . . . . . . . . . . . . . 62 10。 承認. . . . . . . . . . . . . . . . . . . . . . . 63 11。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 63 11.1。 引用規格. . . . . . . . . . . . . . . . . . . 63 11.2。 有益な参照. . . . . . . . . . . . . . . . . . 63付録A.ASN.1モジュール. . . . . . . . . . . . . . . . . . . . 65付録B.登録メッセージは.74に流れます。B.1。 署名証明書. . . . . . . . . . . . . 74B.2の要求。 ただ一つの証明要求にもかかわらず、RA. . . . . 75B.3によって変更されています。 ディフィー-ヘルマンの公開鍵証明要求のRSA証明書. . . . . . . . . . . . 78付録C.生産のために.81C.1を大衆的に指示してください。 署名がない署名メカニズム. . . . . . . . . . . . . 81
Schaad & Myers Standards Track [Page 3] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[3ページ]: 2008年6月を構造化します。
1. Introduction
1. 序論
This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet PKI community:
このドキュメントはCMC、Cryptographic Message Syntax(CMS)を使用するCertificate Managementプロトコルのためにベース構文を定義します。 このプロトコルはインターネットPKI共同体の中の2つの即座の必要性を記述します:
1. The need for an interface to public key certification products
and services based on CMS and PKCS #10, and
1. そして公開鍵証明製品とサービスへのインタフェースの必要性がCMSとPKCSに#10、を基づかせた。
2. The need for a PKI enrollment protocol for encryption only keys
due to algorithm or hardware design.
2. アルゴリズムかハードウェアによるキーだけが設計する暗号化のためのPKI登録プロトコルの必要性。
A small number of additional services are defined to supplement the core certification request service.
少ない数の追加サービスが、コア証明要求サービスを補うために定義されます。
1.1. Protocol Requirements
1.1. プロトコル要件
The protocol must be based as much as possible on the existing CMS, PKCS #10 [PKCS10] and CRMF (Certificate Request Message Format) [CRMF] specifications.
プロトコルを既存のCMS(PKCS#10の[PKCS10]とCRMF(証明書Request Message Format)[CRMF]仕様)にできるだけ基礎づけなければなりません。
The protocol must support the current industry practice of a PKCS #10 certification request followed by a PKCS#7 "certs-only" response as a subset of the protocol.
プロトコルはPKCS#7「本命専用」の応答がプロトコルの部分集合としてあとに続いたPKCS#10証明要求の現在の産業習慣を支持しなければなりません。
The protocol must easily support the multi-key enrollment protocols required by S/MIME and other groups.
プロトコルは容易にS/MIMEと他のグループによって必要とされたマルチ主要な登録プロトコルをサポートしなければなりません。
The protocol must supply a way of doing all enrollment operations in a single round-trip. When this is not possible the number of round-trips is to be minimized.
プロトコルはただ一つの丸い旅行におけるすべての登録操作をする方法を供給しなければなりません。 これが可能でないときに、周遊旅行の数は最小にされることです。
The protocol must be designed such that all key generation can occur on the client.
すべてのキー生成がクライアントの上に起こることができるように、プロトコルを設計しなければなりません。
Support must exist for the mandatory algorithms used by S/MIME. Support should exist for all other algorithms cited by the S/MIME core documents.
サポートはS/MIMEによって使用される義務的なアルゴリズムのために存在しなければなりません。 サポートはS/MIMEコアドキュメントによって引用された他のすべてのアルゴリズムのために存在するべきです。
The protocol must contain Proof-of-Possession (POP) methods. Optional provisions for multiple-round-trip POP will be made if necessary.
プロトコルは所有物のProof(POP)方法を含まなければなりません。 必要なら、複数往復のPOPのための任意の条項は作られるでしょう。
The protocol must support deferred and pending responses to enrollment requests for cases where external procedures are required to issue a certificate.
プロトコルは外部手続きが証明書を下付するのに必要であるケースを求める登録要求への延期されて未定の応答を支持しなければなりません。
Schaad & Myers Standards Track [Page 4] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[4ページ]: 2008年6月を構造化します。
The protocol must support arbitrary chains of Registration Authorities (RAs) as intermediaries between certification requesters and Certification Authorities (CAs).
プロトコルは証明リクエスタとCertification Authorities(CAs)の間の仲介者としてRegistration Authorities(RAs)の任意のチェーンを支えなければなりません。
1.2. Requirements Terminology
1.2. 要件用語
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.3. Changes since RFC 2797
1.3. RFC2797以来の変化
We have done a major overhaul on the layout of the document. This included two different steps. Firstly we removed some sections from the document and moved them to two other documents. Information on how to transport our messages are now found in [CMC-TRANS]. Information on which controls and sections of this document must be implemented along with which algorithms are required can now be found in [CMC-COMPL].
私たちはドキュメントのレイアウトのときに主要なオーバーホールをしました。 これは異なった2ステップを含んでいました。 まず第一に、私たちは、ドキュメントから数人のセクションを取り外して、それらを他の2通のドキュメントに動かしました。 私たちのメッセージが今[CMC-TRANS]で見つけられる輸送へのどのようにに関する情報。 今、[CMC-COMPL]でどのアルゴリズムが必要であるかと共にこのドキュメントのコントロールとセクションを実行しなければならない情報を見つけることができます。
A number of new controls have been added in this version:
多くの新しいコントロールがこのバージョンで加えられます:
Extended CMC Status Info Section 6.1.1
拡張CMC状態インフォメーション部6.1 .1
Publish Trust Anchors Section 6.15
6.15に信用アンカー部を発行してください。
Authenticate Data Section 6.16
資料課6.16を認証してください。
Batch Request and Response Processing Section 6.17
バッチ要求と応答処理部6.17
Publication Information Section 6.18
公表情報収集部門6.18
Modify Certification Request Section 6.5.1
証明要求部6.5の.1を変更してください。
Control Processed Section 6.19
コントロールはセクション6.19を処理しました。
Identity Proof Section 6.2.2
アイデンティティ証拠部6.2 .2
Identity POP Link Witness V2 Section 6.3.1.1
アイデンティティの大衆的なリンク目撃者V2セクション6.3.1.1
2. Protocol Overview
2. プロトコル概観
A PKI enrollment transaction in this specification is generally composed of a single round-trip of messages. In the simplest case a PKI enrollment request, henceforth referred to as a PKI Request, is sent from the client to the server and a PKI enrollment response, henceforth referred to as a PKI Response, is then returned from the
一般に、この仕様に基づくPKI登録取引はメッセージのただ一つの丸い旅行で構成されます。 今後はPKI Requestと呼ばれたPKI登録要求が今後はPKI Responseと呼ばれたサーバとクライアントからPKI登録応答に送られて、次に返される最も簡単なケース
Schaad & Myers Standards Track [Page 5] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[5ページ]: 2008年6月を構造化します。
server to the client. In more complicated cases, such as delayed certificate issuance, more than one round-trip is required.
クライアントへのサーバ。 より複雑な場合では、証明書発行、1以上遅らせられる往復としてのそのようなものが必要です。
This specification defines two PKI Request types and two PKI Response types.
この仕様は2つのPKI Requestタイプを定義します、そして、2PKI Responseはタイプします。
PKI Requests are formed using either the PKCS #10 or CRMF structure. The two PKI Requests are:
PKI Requestsは、PKCS#10かCRMF構造のどちらかを使用することで形成されます。 2PKI Requestsは以下の通りです。
Simple PKI Request: the bare PKCS #10 (in the event that no other
services are needed), and
簡単なPKIは以下を要求します。 そしてむき出しのPKCS#10(他のサービスは全く必要でない場合)。
Full PKI Request: one or more PKCS #10, CRMF or Other Request
Messages structures wrapped in a CMS encapsulation as part of a
PKIData.
完全なPKIは以下を要求します。 1つ以上のPKCS#10、CRMFまたはOther Request Messages構造がPKIDataの一部としてCMSでカプセル化を包装しました。
PKI Responses are based on SignedData or AuthenticatedData [CMS]. The two PKI Responses are
PKI ResponsesはSignedDataかAuthenticatedData[CMS]に基づいています。 2PKI Responsesがそうです。
Simple PKI Response: a "certs-only" SignedData (in the event no
other services are needed), or
簡単なPKI応答: または「本命専用」SignedData(出来事では、他のサービスは全く必要でない)。
Full PKI Response: a PKIResponse content type wrapped in a
SignedData.
完全なPKI応答: SignedDataで包装されたPKIResponseの満足しているタイプ。
No special services are provided for either renewal (i.e., a new certificate with the same key) or rekey (i.e., a new certificate with a new key) of client certificates. Instead renewal and rekey requests look the same as any certification request, except that the identity proof is supplied by existing certificates from a trusted CA. (This is usually the same CA, but could be a different CA in the same organization where naming is shared.)
クライアント証明書の更新(すなわち、同じキーがある新しい証明書)かrekey(すなわち、新しいキーがある新しい証明書)のどちらかに特殊業務を全く提供しません。 代わりに、更新とrekey要求はどんな証明要求とも同じに見えます、既存の証明書から信じられたカリフォルニアからアイデンティティ証拠を供給するのを除いて。 (これは、通常同じカリフォルニアですが、命名が共有される同じ組織で異なったカリフォルニアであるかもしれません。)
No special services are provided to distinguish between a rekey request and a new certification request (generally for a new purpose). A control to unpublish a certificate would normally be included in a rekey request, and be omitted in a new certification request. CAs or other publishing agents are also expected to have policies for removing certificates from publication either based on new certificates being added or the expiration or revocation of a certificate.
rekey要求と新しい証明要求(一般に新しい目的のための)を見分けるために特殊業務を全く提供しません。 証明書を非発行するコントロールは、通常、rekey要求に含まれていて、新しい証明要求で省略されるでしょう。 また、CAsか他の出版エージェントには証明書の加えられる、新しい証明書、満了または取消しに基づいて公表から証明書を取り外すための方針があると予想されます。
A provision exists for RAs to participate in the protocol by taking PKI Requests, wrapping them in a second layer of PKI Request with additional requirements or statements from the RA and then passing this new expanded PKI Request on to the CA.
PKI Requestsを取ることによってRAsがプロトコルに参加するように、支給は存在しています、PKI Requestの2番目の層の中でRAからの追加要件か声明で彼らを包装して、次に、この新しい拡張PKI Requestをカリフォルニアに渡して。
Schaad & Myers Standards Track [Page 6] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[6ページ]: 2008年6月を構造化します。
This specification makes no assumptions about the underlying transport mechanism. The use of CMS does not imply an email-based transport. Several different possible transport methods are defined in [CMC-TRANS].
この仕様は基本的な移送機構に関する仮定を全くしません。 CMSの使用はメールベースの輸送を含意しません。 いくつかの異なった可能な輸送方法が[CMC-TRANS]で定義されます。
Optional services available through this specification are transaction management, replay detection (through nonces), deferred certificate issuance, certificate revocation requests and certificate/certificate revocation list (CRL) retrieval.
この仕様で利用可能な任意のサービスはトランザクション管理、再生検出(一回だけを通した)、延期された証明書発行、証明書取消し要求、および証明書/証明書失効リスト(CRL)検索です。
2.1. Terminology
2.1. 用語
There are several different terms, abbreviations, and acronyms used in this document. These are defined here, in no particular order, 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が終わり実体と認証局の間に存在できます。 RAsは記録保管所でキー生成かキーなどの追加サービスを実行するかもしれません。 このドキュメントはRAとLRAの両方にRAという用語を使用します。
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]について言及します。 このドキュメントはかぎ管理のあるなしにかかわらず暗号化と調印を含む基本的な暗号のサービスに備えます。
Schaad & Myers Standards Track [Page 7] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[7ページ]: 2008年6月を構造化します。
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.
身元の証拠は彼らが言うだれかであると立証するサーバには彼らがいるクライアントについて言及します。
Enrollment or certification request refers to the process of a
client requesting a certificate. A certification request is a
subset of the PKI Requests.
登録か証明要求がクライアントが証明書を要求する過程を示します。 証明要求はPKI Requestsの部分集合です。
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. The different types
of POP are:
所有物の証拠(POP)は公開鍵に対応する秘密鍵が所有物にあると立証するのに使用できて、終わり実体で使用できる値について言及します。 POPの異なったタイプは以下の通りです。
Signature provides the required POP by a signature operation over
some data.
署名は署名操作でいくつかのデータの上に必要なPOPを提供します。
Direct provides the required POP operation by an encrypted
challenge/response mechanism.
ダイレクトである、コード化された挑戦/反応機構は必要なPOP操作を提供します。
Indirect provides the required POP operation by returning the
issued certificate in an encrypted state. (This method is not
used by CMC.)
間接的である、コード化された状態で発行された証明書を返すことによって、必要なPOP操作を提供します。 (この方法はCMCによって使用されません。)
Publish provides the required POP operation by providing the
private key to the certificate issuer. (This method is not
currently used by CMC. It would be used by Key Generation or
Key Escrow extensions.)
発行してください。証明書発行人に秘密鍵を提供することによって、必要なPOP操作を提供します。 (この方法は現在、CMCによって使用されません。 それはKey GenerationかKey Escrow拡張子で使用されるでしょう。)
Attested provides the required POP operation by allowing a
trusted entity to assert that the POP has been proven by one of
the above methods.
証明されました。信じられた実体が、POPが上の方法の1つで立証されたと断言するのを許容することによって、必要なPOP操作を提供します。
Object IDentifier (OID) is a primitive type in Abstract Syntax
Notation One (ASN.1).
物のIDentifier(OID)は抽象的なSyntax Notation One(ASN.1)のプリミティブ型です。
Schaad & Myers Standards Track [Page 8] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[8ページ]: 2008年6月を構造化します。
2.2. Protocol Requests/Responses
2.2. プロトコル要求/応答
Figure 1 shows the Simple PKI Requests and Responses. The contents of Simple PKI Request and Response are detailed in Sections 3.1 and 4.1.
図1はSimple PKI RequestsとResponsesを示しています。 Simple PKI RequestとResponseの内容はセクション3.1と4.1で詳細です。
Simple PKI Request Simple PKI Response ------------------------- --------------------------
簡単なPKIは簡単なPKI応答を要求します。------------------------- --------------------------
+----------+ +------------------+
| PKCS #10 | | CMS ContentInfo |
+----------+--------------+ +------------------+------+
| Certification Request | | CMS Signed Data, |
| | | no SignerInfo |
| Subject Name | |
| Subject Public Key Info | | SignedData contains one |
| (K_PUB) | | or more certificates in |
| Attributes | | the certificates field |
| | | Relevant CA certs and |
+-----------+-------------+ | CRLs can be included |
| signed with | | as well. |
| matching | | |
| K_PRIV | | encapsulatedContentInfo |
+-------------+ | is absent. |
+--------------+----------+
| unsigned |
+----------+
+----------+ +------------------+ | PKCS#10| | cm ContentInfo| +----------+--------------+ +------------------+------+ | 証明要求| | cmはデータにサインしました。| | | | SignerInfoがありません。| | 対象の名前| | | 対象の公開鍵インフォメーション| | SignedDataは1つを含んでいます。| | (K_パブ) | | または、以上はコネを証明します。| | 属性| | 証明書分野| | | | そして関連カリフォルニア本命。| +-----------+-------------+ | CRLsを含むことができます。| | 契約されます。| | また。 | | マッチング| | | | K_PRIV| | encapsulatedContentInfo| +-------------+ | 休む。 | +--------------+----------+ | 無記名| +----------+
Figure 1: Simple PKI Requests and Responses
図1: 簡単なPKI要求と応答
Schaad & Myers Standards Track [Page 9] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[9ページ]: 2008年6月を構造化します。
Figure 2 shows the Full PKI Requests and Responses. The contents of the Full PKI Request and Response are detailed in Sections 3.2 and 4.2.
図2はFull PKI RequestsとResponsesを示しています。 Full PKI RequestとResponseの内容はセクション3.2と4.2で詳細です。
Full PKI Request Full PKI Response
----------------------- ------------------------
+----------------+ +----------------+
| CMS ContentInfo| | CMS ContentInfo|
| CMS SignedData | | CMS SignedData |
| or Auth Data | | or Auth Data |
| object | | object |
+----------------+--------+ +----------------+--------+
| | | |
| PKIData | | PKIResponseBody |
| | | |
| Sequence of: | | Sequence of: |
| <enrollment control>* | | <enrollment control>* |
| <certification request>*| | <CMS object>* |
| <CMS object>* | | <other message>* |
| <other message>* | | |
| | | where * == zero or more |
| where * == zero or more | | |
| | | All certificates issued |
| Certification requests | | as part of the response |
| are CRMF, PKCS #10, or | | are included in the |
| Other. | | "certificates" field |
| | | of the SignedData. |
+-------+-----------------+ | Relevant CA certs and |
| signed (keypair | | CRLs can be included as |
| used may be pre-| | well. |
| existing or | | |
| identified in | +---------+---------------+
| the request) | | signed by the |
+-----------------+ | CA or an LRA |
+---------------+
完全なPKIは完全なPKI応答を要求します。----------------------- ------------------------ +----------------+ +----------------+ | cm ContentInfo| | cm ContentInfo| | cm SignedData| | cm SignedData| | または、Authデータ| | または、Authデータ| | 物| | 物| +----------------+--------+ +----------------+--------+ | | | | | PKIData| | PKIResponseBody| | | | | | 以下の系列 | | 以下の系列 | | <登録コントロール>*| | <登録コントロール>*| | <証明要求>*| | <CMS物の>*| | <CMS物の>*| | <他のメッセージ>*| | <他のメッセージ>*| | | | | | どこ、ゼロか*=以上| | どこ、ゼロか*=以上| | | | | | 証明書が発行したすべて| | 証明要求| | 応答の一部として| | またはCRMF、PKCSが#10である。| | 含まれています。| | 他。 | | 「証明書」分野| | | | SignedDataについて。 | +-------+-----------------+ | そして関連カリフォルニア本命。| | サインされます。(keypair| | CRLsを含むことができます。| | 使用されて、あるかもしれない、プレ| | さて。 | | または既存である。| | | | 中では、特定されます。| +---------+---------------+ | 要求) | | サインします。| +-----------------+ | カリフォルニアかLRA| +---------------+
Figure 2: Full PKI Requests and Responses
図2: 完全なPKI要求と応答
3. PKI Requests
3. PKI要求
Two types of PKI Requests exist. This section gives the details for both types.
PKI Requestsの2つのタイプが存在しています。 このセクションは両方のタイプのために詳細を述べます。
3.1. Simple PKI Request
3.1. 簡単なPKI要求
A Simple PKI Request uses the PKCS #10 syntax CertificationRequest [PKCS10].
Simple PKI RequestはPKCS#10構文CertificationRequest[PKCS10]を使用します。
Schaad & Myers Standards Track [Page 10] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[10ページ]: 2008年6月を構造化します。
When a server processes a Simple PKI Request, the PKI Response returned is:
サーバがSimple PKI Requestを処理するとき、返されたPKI Responseは以下の通りです。
Simple PKI Response on success.
成功の簡単なPKI Response。
Full PKI Response on failure. The server MAY choose not to return a
PKI Response in this case.
失敗の完全なPKI Response。 サーバは、この場合PKI Responseを返さないのを選ぶかもしれません。
The Simple PKI Request MUST NOT be used if a proof-of-identity needs to be included.
身元の証拠が、含まれる必要があるなら、Simple PKI Requestを使用してはいけません。
The Simple PKI Request cannot be used if the private key is not capable of producing some type of signature (i.e., Diffie-Hellman (DH) keys can use the signature algorithms in [DH-POP] for production of the signature).
秘密鍵がタイプの署名を起こすことができないなら(すなわち、ディフィーヘルマン(DH)キーは署名の生産に[DH-POP]で署名アルゴリズムを使用できます)、Simple PKI Requestを使用できません。
The Simple PKI Request cannot be used for any of the advanced services specified in this document.
本書では指定された高度なサービスのいずれにもSimple PKI Requestを使用できません。
The client MAY incorporate one or more X.509v3 extensions in any certification request based on PKCS #10 as an ExtensionReq attribute. The ExtensionReq attribute is defined as:
クライアントはExtensionReq属性としてPKCS#10、に基づくどんな証明要求でも1つ以上のX.509v3拡張子を取り入れるかもしれません。 ExtensionReq属性は以下と定義されます。
ExtensionReq ::= SEQUENCE SIZE (1..MAX) OF Extension
ExtensionReq:、:= 拡大の系列サイズ(1..MAX)
where Extension is imported from [PKIXCERT] and ExtensionReq is identified by:
どこで[PKIXCERT]とExtensionReqからExtensionを輸入するかは以下によって特定されます。
id-ExtensionReq OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) 14}
イド-ExtensionReq物の識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9)14をメンバーと同じくらい具体化させます。
Servers MUST be able to process all extensions defined, but not prohibited, in [PKIXCERT]. Servers are not required to be able to process other X.509v3 extensions transmitted using this protocol, nor are they required to be able to process private extensions. Servers are not required to put all client-requested extensions into a certificate. Servers are permitted to modify client-requested extensions. Servers MUST NOT alter an extension so as to invalidate the original intent of a client-requested extension. (For example, changing key usage from keyAgreement to digitalSignature.) If a certification request is denied due to the inability to handle a requested extension and a PKI Response is returned, the server MUST return a PKI Response with a CMCFailInfo value with the value unsupportedExt.
サーバは定義されますが、[PKIXCERT]で禁止されなかったすべての拡大を処理できなければなりません。 サーバはこのプロトコルを使用することで伝えられた他のX.509v3拡張子を処理できるように必要ではありません、そして、それらは個人的な拡大を処理する必要はないことができます。 サーバは、すべてのクライアントによって要求された拡大を証明書に入れるのに必要ではありません。 サーバがクライアントによって要求された拡大を変更することが許可されています。 サーバは、クライアントによって要求された拡大の当初の意図を無効にするために拡大を変更してはいけません。 (例えば、主要な用法をkeyAgreementからdigitalSignatureに変えます。) 要求された拡大を扱うことができないことのため証明要求を否定して、PKI Responseを返すなら、サーバは値のunsupportedExtがあるCMCFailInfo値があるPKI Responseを返さなければなりません。
Schaad & Myers Standards Track [Page 11] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[11ページ]: 2008年6月を構造化します。
3.2. Full PKI Request
3.2. 完全なPKI要求
The Full PKI Request provides the most functionality and flexibility.
Full PKI Requestは最も多くの機能性と柔軟性を提供します。
The Full PKI Request is encapsulated in either a SignedData or an AuthenticatedData with an encapsulated content type of id-cct-PKIData (Section 3.2.1).
Full PKI RequestはSignedDataかAuthenticatedDataのどちらかでイド-cct-PKIData(セクション3.2.1)のカプセル化されたcontent typeでカプセル化されます。
When a server processes a Full PKI Request, a PKI Response MUST be returned. The PKI Response returned is:
サーバがFull PKI Requestを処理すると、PKI Responseを返さなければなりません。 返されたPKI Responseは以下の通りです。
Simple PKI Response if the enrollment was successful and only
certificates are returned. (A CMCStatusInfoV2 control with
success is implied.)
簡単なPKI Responseは登録であるならうまくいきました、そして、証明書だけを返します。 (成功があるCMCStatusInfoV2コントロールは含意されます。)
Full PKI Response if the enrollment was successful and information
is returned in addition to certificates, if the enrollment is
pending, or if the enrollment failed.
完全なPKI Responseは登録であるならうまくいきました、そして、証明書に加えて情報を返します、登録が未定であるか、または登録が失敗したなら。
If SignedData is used, the signature can be generated using either the private key material of an embedded signature certification request (i.e., included in the TaggedRequest tcr or crm fields) or a previously certified signature key. If the private key of a signature certification request is used, then:
SignedDataが使用されているなら、埋め込まれた署名証明要求(すなわち、TaggedRequest tcrかcrmでは、分野を含んでいる)の秘密鍵の材料か以前に公認された署名キーのどちらかを使用することで署名を生成することができます。 次に、署名証明要求の秘密鍵が使用されるなら:
a. The certification request containing the corresponding public key
MUST include a Subject Key Identifier extension.
a。 対応する公開鍵を含む証明要求はSubject Key Identifier拡張子を含まなければなりません。
b. The subjectKeyIdentifier form of the signerIdentifier in
SignerInfo MUST be used.
b。 SignerInfoのsignerIdentifierのsubjectKeyIdentifierフォームを使用しなければなりません。
c. The value of the subjectKeyIdentifier form of SignerInfo MUST be
the Subject Key Identifier specified in the corresponding
certification request. (The subjectKeyIdentifier form of
SignerInfo is used here because no certificates have yet been
issued for the signing key.) If the request key is used for
signing, there MUST be only one SignerInfo in the SignedData.
c。 SignerInfoのsubjectKeyIdentifierフォームの値は対応する証明要求で指定されたSubject Key Identifierでなければなりません。 (SignerInfoのsubjectKeyIdentifierフォームは署名キーのためにまだ証明書を全く発行していないので、ここで使用されます。) 要求キーが署名に使用されるなら、1SignerInfoしかSignedDataにないに違いありません。
If AuthenticatedData is used, then:
次に、AuthenticatedDataが使用されるなら:
a. The Password Recipient Info option of RecipientInfo MUST be used.
a。 RecipientInfoのPassword Recipient Infoオプションを使用しなければなりません。
b. A randomly generated key is used to compute the Message
Authentication Code (MAC) value on the encapsulated content.
b。 手当たりしだいに発生しているキーは、カプセル化された内容のメッセージ立証コード(MAC)値を計算するのに使用されます。
c. The input for the key derivation algorithm is a concatenation of
the identifier (encoded as UTF8) and the shared-secret.
c。 主要な誘導アルゴリズムのための入力は識別子(UTF8として、コード化される)と共有秘密キーの連結です。
Schaad & Myers Standards Track [Page 12] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[12ページ]: 2008年6月を構造化します。
When creating a PKI Request to renew or rekey a certificate:
aを更新するか、またはrekeyするようにPKI Requestを作成するときには以下を証明してください。
a. The Identification and Identity Proof controls are absent. The
same information is provided by the use of an existing
certificate from a CA when signing the PKI Request. In this
case, the CA that issued the original certificate and the CA the
request is made to will usually be the same, but could have a
common operator.
a。 IdentificationとIdentity Proofコントロールは欠けています。 PKI Requestに署名するとき、カリフォルニアから既存の証明書の使用で同じ情報を提供します。 この場合、オリジナルの証明書を発行したカリフォルニアと要求がされるカリフォルニアは、通常同じですが、一般的なオペレータを持つことができました。
b. CAs and RAs can impose additional restrictions on the signing
certificate used. They may require that the most recently issued
signing certificate for a client be used.
b。 CAsとRAsは追加制限を使用される署名証明書に課すことができます。 彼らは、クライアントへの最も最近発行された署名証明書が使用されるのを必要とするかもしれません。
c. Some CAs may prevent renewal operations (i.e., reuse of the same
keys). In this case the CA MUST return a PKI Response with
noKeyReuse as the CMCFailInfo failure code.
c。 いくつかのCAsが更新操作(すなわち、同じキーの再利用)を防ぐかもしれません。 この場合、カリフォルニアはCMCFailInfo失敗コードとしてnoKeyReuseとPKI Responseを返さなければなりません。
3.2.1. PKIData Content Type
3.2.1. PKIData content type
The PKIData content type is used for the Full PKI Request. A PKIData content type is identified by:
PKIData content typeはFull PKI Requestに使用されます。 PKIData content typeは以下によって特定されます。
id-cct-PKIData ::= {id-pkix id-cct(12) 2 }
イド-cct-PKIData:、:= イド-pkixイド-cct(12)2
The ASN.1 structure corresponding to the PKIData content type is:
PKIData content typeに対応するASN.1構造は以下の通りです。
PKIData ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
PKIData:、:= 系列TaggedAttributeのcontrolSequence系列サイズ(0..MAX)、TaggedRequestのreqSequence系列サイズ(0..MAX)、TaggedContentInfoのcmsSequence系列サイズ(0..MAX)、OtherMsgのotherMsgSequence系列サイズ(0..MAX)
The fields in PKIData have the following meaning:
PKIDataの分野には、以下の意味があります:
controlSequence is a sequence of controls. The controls defined in
this document are found in Section 6. Controls can be defined by
other parties. Details on the TaggedAttribute structure can be
found in Section 3.2.1.1.
controlSequenceはコントロールの系列です。 本書では定義されたコントロールはセクション6で見つけられます。 相手はコントロールを定義できます。 セクション3.2.1で.1にTaggedAttribute構造に関する詳細を見つけることができます。
reqSequence is a sequence of certification requests. The
certification requests can be a CertificationRequest (PKCS #10), a
CertReqMsg (CRMF), or an externally defined PKI request. Full
details are found in Section 3.2.1.2. If an externally defined
certification request is present, but the server does not
understand the certification request (or will not process it), a
CMCStatus of noSupport MUST be returned for the certification
request item and no other certification requests are processed.
reqSequenceは証明要求の系列です。 証明要求は、CertificationRequest(PKCS#10)、CertReqMsg(CRMF)、または外部的に定義されたPKI要求であるかもしれません。 一部始終はセクション3.2.1で.2に見つけられます。 外部的に定義された証明要求が存在していますが、サーバが証明要求(または、それを処理しない)を理解していないなら、証明要求項目のためにnoSupportのCMCStatusを返さなければなりません、そして、他の証明要求を全く処理しません。
Schaad & Myers Standards Track [Page 13] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[13ページ]: 2008年6月を構造化します。
cmsSequence is a sequence of [CMS] message objects. See
Section 3.2.1.3 for more details.
cmsSequenceは[CMS]メッセージオブジェクトの系列です。 セクション3.2を見てください。.1 .3 その他の詳細のために。
otherMsgSequence is a sequence of arbitrary data objects. Data
objects placed here are referred to by one or more controls. This
allows for controls to use large amounts of data without the data
being embedded in the control. See Section 3.2.1.4 for more
details.
otherMsgSequenceは任意のデータ・オブジェクトの系列です。 1つ以上のコントロールでここに置かれたデータ・オブジェクトは言及されます。 これは、コントロールがコントロールに埋め込まれているデータなしで多量のデータを使用するのを許容します。 セクション3.2を見てください。.1 .4 その他の詳細のために。
All certification requests encoded into a single PKIData SHOULD be for the same identity. RAs that batch process (see Section 6.17) are expected to place the PKI Requests received into the cmsSequence of a PKIData.
独身のPKIData SHOULDにコード化されたすべての証明要求が同じアイデンティティのためのそうです。 バッチ処理する(セクション6.17を見ます)RAsがPKIDataのcmsSequenceに受け取られたPKI Requestsを置くと予想されます。
Processing of the PKIData by a recipient is as follows:
受取人によるPKIDataの処理は以下の通りです:
1. All controls should be examined and processed in an appropriate
manner. The appropriate processing is to complete processing at
this time, to ignore the control, or to place the control on a
to-do list for later processing. Controls can be processed in
any order; the order in the sequence is not significant.
1. すべてのコントロールが、適切な方法で調べられて、加工処理されるべきです。 適切な処理は、このとき処理するのを完了するか、コントロールを無視するか、または後で処理するためのトゥドゥリストにコントロールを置くことです。 順不同にコントロールを加工処理できます。 系列におけるオーダーは重要ではありません。
2. Items in the reqSequence are not referenced by a control. These
items, which are certification requests, also need to be
processed. As with controls, the appropriate processing can be
either immediate processing or addition to a to-do list for later
processing.
2. コントロールでreqSequenceの項目は参照をつけられません。 また、これらの項目(証明要求である)は、処理される必要があります。 コントロールなら、適切な処理は、後で処理するためのトゥドゥリストへの即時処理か追加のどちらかであるかもしれません。
3. Finally, the to-do list is processed. In many cases, the to-do
list will be ordered by grouping specific tasks together.
3. 最終的に、トゥドゥリストは処理されます。 多くの場合、トゥドゥリストは、特定のタスクを分類することによって、注文されるでしょう。
No processing is required for cmsSequence or otherMsgSequence members of PKIData if they are present and are not referenced by a control. In this case, the cmsSequence and otherMsgSequence members are ignored.
彼らが存在していて、コントロールで参照をつけられないなら、処理はPKIDataのcmsSequenceかotherMsgSequenceメンバーに必要ではありません。 この場合、cmsSequenceとotherMsgSequenceメンバーは無視されます。
3.2.1.1. Control Syntax
3.2.1.1. 規制構文
The actions to be performed for a PKI Request/Response are based on the included controls. Each control consists of an object identifier and a value based on the object identifier.
PKI Request/応答のために実行されるべき動作は含まれているコントロールに基づいています。 各コントロールはオブジェクト識別子に基づくオブジェクト識別子と価値から成ります。
Schaad & Myers Standards Track [Page 14] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[14ページ]: 2008年6月を構造化します。
The syntax of a control is:
コントロールの構文は以下の通りです。
TaggedAttribute ::= SEQUENCE {
bodyPartID BodyPartID,
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue
}
TaggedAttribute:、:= 系列bodyPartID BodyPartID、attrTypeオブジェクト識別子、AttributeValueのattrValuesセット
AttributeValue ::= ANY
AttributeValue:、:= 少しも
The fields in TaggedAttribute have the following meaning:
TaggedAttributeの分野には、以下の意味があります:
bodyPartID is a unique integer that identifies this control.
bodyPartIDはこのコントロールを特定するユニークな整数です。
attrType is the OID that identifies the control.
attrTypeはコントロールを特定するOIDです。
attrValues is the data values used in processing the control. The
structure of the data is dependent on the specific
control.
attrValuesはコントロールを加工処理する際に使用されるデータ値です。 データの構造は特定のコントロールに依存しています。
The final server MUST fail the processing of an entire PKIData if any included control is not recognized, that control is not already marked as processed by a Control Processed control (see Section 6.19) and no other error is generated. The PKI Response MUST include a CMCFailInfo value with the value badRequest and the bodyList MUST contain the bodyPartID of the invalid or unrecognized control(s). A server is the final server if and only if it is not passing the PKI Request on to another server. A server is not considered to be the final server if the server would have passed the PKI Request on, but instead it returned a processing error.
含まれているコントロールが少しの認識されないなら、最終的なサーバは全体のPKIDataの処理に失敗しなければなりません、そして、そのコントロールはControl Processedコントロールで処理されるように既にマークされません、そして、(セクション6.19を見てください)他のどんな誤りも発生していません。 PKI Responseは値のbadRequestがあるCMCFailInfo値を含まなければなりません、そして、bodyListは無効の、または、認識されていないコントロールのbodyPartIDを含まなければなりません。 それは別のサーバにPKI Requestを渡していません。そして、サーバが最終的なサーバである、サーバがPKI Requestを伝えたならサーバが最終的なサーバであることは考えられませんでしたが、代わりに整理過程の誤差を返した場合にだけ。
The controls defined by this document are found in Section 6.
このドキュメントによって定義されたコントロールはセクション6で見つけられます。
3.2.1.2. Certification Request Formats
3.2.1.2. 証明要求形式
Certification Requests are based on PKCS #10, CRMF, or Other Request formats. Section 3.2.1.2.1 specifies the requirements for clients and servers dealing with PKCS #10. Section 3.2.1.2.2 specifies the requirements for clients and servers dealing with CRMF. Section 3.2.1.2.3 specifies the requirements for clients and servers dealing with Other Request.
証明Requestsは10、CRMF、またはOther RequestがフォーマットするPKCS#に基づいています。 セクション3.2 .1 .2 .1 PKCS#10に対処するクライアントとサーバのための要件を指定します。 セクション3.2 .1 .2 .2 CRMFに対処するクライアントとサーバのための要件を指定します。 セクション3.2 .1 .2 .3 Other Requestに対処するクライアントとサーバのための要件を指定します。
Schaad & Myers Standards Track [Page 15] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[15ページ]: 2008年6月を構造化します。
TaggedRequest ::= CHOICE {
tcr [0] TaggedCertificationRequest,
crm [1] CertReqMsg,
orm [2] SEQUENCE {
bodyPartID BodyPartID,
requestMessageType OBJECT IDENTIFIER,
requestMessageValue ANY DEFINED BY requestMessageType
}
}
TaggedRequest:、:= 選択tcr[0]TaggedCertificationRequest、crm[1]CertReqMsg、orm[2]SEQUENCE、bodyPartID BodyPartID、requestMessageType OBJECT IDENTIFIER、requestMessageValue、どんなDEFINED BY requestMessageType
The fields in TaggedRequest have the following meaning:
TaggedRequestの分野には、以下の意味があります:
tcr is a certification request that uses the PKCS #10 syntax.
Details on PKCS #10 are found in Section 3.2.1.2.1.
tcrはPKCS#10構文を使用する証明要求です。 #10があるというPKCSに関する詳細はセクション3.2.1で.1に.2を設立します。
crm is a certification request that uses the CRMF syntax. Details
on CRMF are found in Section 3.2.1.2.2.
crmはCRMF構文を使用する証明要求です。 CRMFに関する詳細はセクション3.2で見つけられます。.1 .2 .2。
orm is an externally defined certification request. One example is
an attribute certification request. The fields of this structure
are:
ormは外部的に定義された証明要求です。 1つの例は属性証明要求です。 この構造の分野は以下の通りです。
bodyPartID is the identifier number for this certification
request. Details on body part identifiers are found in
Section 3.2.2.
bodyPartIDはこの証明要求の識別子番号です。 ボディー部分識別子に関する詳細はセクション3.2.2で見つけられます。
requestMessageType identifies the other request type. These
values are defined outside of this document.
requestMessageTypeはもう片方の要求タイプを特定します。 これらの値はこのドキュメントの外で定義されます。
requestMessageValue is the data associated with the other request
type.
requestMessageValueはもう片方の要求タイプに関連しているデータです。
3.2.1.2.1. PKCS #10 Certification Syntax
3.2.1.2.1. PKCS#10証明構文
A certification request based on PKCS #10 uses the following ASN.1 structure:
PKCS#10、に基づく証明要求は以下のASN.1構造を使用します:
TaggedCertificationRequest ::= SEQUENCE {
bodyPartID BodyPartID,
certificationRequest CertificationRequest
}
TaggedCertificationRequest:、:= 系列bodyPartID BodyPartID、certificationRequest CertificationRequest
The fields in TaggedCertificationRequest have the following meaning:
TaggedCertificationRequestの分野には、以下の意味があります:
bodyPartID is the identifier number for this certification request.
Details on body part identifiers are found in Section 3.2.2.
bodyPartIDはこの証明要求の識別子番号です。 ボディー部分識別子に関する詳細はセクション3.2.2で見つけられます。
Schaad & Myers Standards Track [Page 16] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[16ページ]: 2008年6月を構造化します。
certificationRequest contains the PKCS-#10-based certification
request. Its fields are described in [PKCS10].
最もcertificationRequestに、10ベースの証明が要求するPKCS-#、を含んでいます。 分野は[PKCS10]で説明されます。
When producing a certification request based on PKCS #10, clients MUST produce the certification request with a subject name and public key. Some PKI products are operated using a central repository of information to assign subject names upon receipt of a certification request. To accommodate this mode of operation, the subject field in a CertificationRequest MAY be NULL, but MUST be present. CAs that receive a CertificationRequest with a NULL subject field MAY reject such certification requests. If rejected and a PKI Response is returned, the CA MUST return a PKI Response with the CMCFailInfo value with the value badRequest.
PKCS#10、に基づく証明要求を作り出すとき、クライアントは対象の名前と公開鍵で証明要求を作り出さなければなりません。 いくつかのPKI製品が、証明要求を受け取り次第対象の名前を割り当てるのに情報の中央倉庫を使用することで操作されます。 この運転モードに対応するために、CertificationRequestの対象の分野は、NULLであるかもしれませんが、存在していなければなりません。 NULLの対象の分野があるCertificationRequestを受けるCAsはそのような証明要求を拒絶するかもしれません。 拒絶されるのとa PKI Responseを返すなら、カリフォルニアは値のbadRequestがあるCMCFailInfo値があるPKI Responseを返さなければなりません。
3.2.1.2.2. CRMF Certification Syntax
3.2.1.2.2. CRMF証明構文
A CRMF message uses the following ASN.1 structure (defined in [CRMF] and included here for convenience):
CRMFメッセージは以下のASN.1構造([CRMF]で定義されて、便宜のためにここに含まれている)を使用します:
CertReqMsg ::= SEQUENCE {
certReq CertRequest,
popo ProofOfPossession OPTIONAL,
-- content depends upon key type
regInfo SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue OPTIONAL }
CertReqMsg:、:= 系列certReq CertRequest、popo ProofOfPossession OPTIONAL、--内容が主要なタイプregInfo SEQUENCE SIZE(1..MAX)OF AttributeTypeAndValue OPTIONALによる
CertRequest ::= SEQUENCE {
certReqId INTEGER, -- ID for matching request and reply
certTemplate CertTemplate, --Selected fields of cert to be issued
controls Controls OPTIONAL } -- Attributes affecting issuance
CertRequest:、:= SEQUENCE、certReqId INTEGER(合っている要求と回答certTemplate CertTemplateのためのID)は、コントロールControls OPTIONALが本命の分野に発行されるのを選択しました--感激的な発行を結果と考えます。
CertTemplate ::= SEQUENCE {
version [0] Version OPTIONAL,
serialNumber [1] INTEGER OPTIONAL,
signingAlg [2] AlgorithmIdentifier OPTIONAL,
issuer [3] Name OPTIONAL,
validity [4] OptionalValidity OPTIONAL,
subject [5] Name OPTIONAL,
publicKey [6] SubjectPublicKeyInfo OPTIONAL,
issuerUID [7] UniqueIdentifier OPTIONAL,
subjectUID [8] UniqueIdentifier OPTIONAL,
extensions [9] Extensions OPTIONAL }
CertTemplate:、:= 系列バージョン[0]バージョンOPTIONAL、serialNumber[1]INTEGER OPTIONAL、signingAlg[2]AlgorithmIdentifier OPTIONAL、発行人[3]名前OPTIONAL(正当性[4]OptionalValidity OPTIONAL)は[5] 名前OPTIONALをかけます、publicKey[6]SubjectPublicKeyInfo OPTIONAL、issuerUID[7]UniqueIdentifier OPTIONAL、subjectUID[8]UniqueIdentifier OPTIONAL、拡大[9]拡大OPTIONAL
The fields in CertReqMsg are explained in [CRMF].
CertReqMsgの分野は[CRMF]で説明されます。
Schaad & Myers Standards Track [Page 17] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[17ページ]: 2008年6月を構造化します。
This document imposes the following additional restrictions on the construction and processing of CRMF certification requests:
このドキュメントはCRMF証明要求の工事と処理に以下の追加制限を課します:
When a Full PKI Request includes a CRMF certification request,
both the subject and publicKey fields in the CertTemplate MUST be
defined. The subject field can be encoded as NULL, but MUST be
present.
Full PKI RequestがCRMF証明要求を含んでいるとき、CertTemplateの対象とpublicKey分野の両方を定義しなければなりません。 対象の分野は、NULLとしてコード化できますが、存在していなければなりません。
When both CRMF and CMC controls exist with equivalent
functionality, the CMC control SHOULD be used. The CMC control
MUST override the CRMF control.
CRMFとCMCの両方であるときに、コントロールは同等な機能性、CMCコントロールSHOULDで存在しています。使用されます。 CMCコントロールはCRMFコントロールをくつがえさなければなりません。
The regInfo field MUST NOT be used on a CRMF certification
request. Equivalent functionality is provided in the CMC regInfo
control (Section 6.12).
CRMF証明要求のときにregInfo分野を使用してはいけません。 CMC regInfoコントロール(セクション6.12)に同等な機能性を提供します。
The indirect method of proving POP is not supported in this
protocol. One of the other methods (including the direct method
described in this document) MUST be used. The value of encrCert
in SubsequentMessage MUST NOT be used.
POPを立証する間接的なメソッドはこのプロトコルでサポートされません。 他のメソッド(本書では説明されたダイレクトメソッドを含んでいる)の1つを使用しなければなりません。 SubsequentMessageのencrCertの値を使用してはいけません。
Since the subject and publicKeyValues are always present, the
POPOSigningKeyInput MUST NOT be used when computing the value for
POPSigningKey.
対象とpublicKeyValuesがいつも存在しているので、POPSigningKeyのために値を計算するとき、POPOSigningKeyInputを使用してはいけません。
A server is not required to use all of the values suggested by the client in the CRMF certification request. Servers MUST be able to process all extensions defined, but not prohibited in [PKIXCERT]. Servers are not required to be able to process other X.509v3 extensions transmitted using this protocol, nor are they required to be able to process private extensions. Servers are permitted to modify client-requested extensions. Servers MUST NOT alter an extension so as to invalidate the original intent of a client- requested extension. (For example, change key usage from keyAgreement to digitalSignature.) If a certification request is denied due to the inability to handle a requested extension, the server MUST respond with a Full PKI Response with a CMCFailInfo value with the value of unsupportedExt.
サーバは、CRMF証明要求でクライアントによって提案された値のすべてを使用するのに必要ではありません。 サーバは定義されますが、[PKIXCERT]で禁止されなかったすべての拡大を処理できなければなりません。 サーバはこのプロトコルを使用することで伝えられた他のX.509v3拡張子を処理できるように必要ではありません、そして、それらは個人的な拡大を処理する必要はないことができます。 サーバがクライアントによって要求された拡大を変更することが許可されています。 サーバは、クライアントの要求された拡大の当初の意図を無効にするために拡大を変更してはいけません。 (例えば、主要な用法をkeyAgreementからdigitalSignatureに変えてください。) 証明要求が要求された拡大を扱うことができないことのため否定されるなら、サーバはFull PKI Responseと共にunsupportedExtの値があるCMCFailInfo値で反応しなければなりません。
3.2.1.2.3. Other Certification Request
3.2.1.2.3. 他の証明要求
This document allows for other certification request formats to be defined and used as well. An example of an other certification request format is one for Attribute Certificates. These other certification request formats are defined by specifying an OID for identification and the structure to contain the data to be passed.
このドキュメントは、他の証明のためにまた、要求書式が定義されて、使用されるのを許容します。 他の証明要求形式に関する例はAttribute Certificatesのためのものです。 これらの他の証明要求書式は、識別と構造が通過されるデータを含むようにOIDを指定することによって、定義されます。
Schaad & Myers Standards Track [Page 18] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[18ページ]: 2008年6月を構造化します。
3.2.1.3. Content Info Objects
3.2.1.3. 満足しているインフォメーションオブジェクト
The cmsSequence field of the PKIData and PKIResponse messages contains zero or more tagged content info objects. The syntax for this structure is:
PKIDataとPKIResponseメッセージのcmsSequence分野はゼロか、よりタグ付けをされた満足しているインフォメーションオブジェクトを含んでいます。 この構造への構文は以下の通りです。
TaggedContentInfo ::= SEQUENCE {
bodyPartID BodyPartID,
contentInfo ContentInfo
}
TaggedContentInfo:、:= 系列bodyPartID BodyPartID、contentInfo ContentInfo
The fields in TaggedContentInfo have the following meaning:
TaggedContentInfoの分野には、以下の意味があります:
bodyPartID is a unique integer that identifies this content info
object.
bodyPartIDはこの満足しているインフォメーションオブジェクトを特定するユニークな整数です。
contentInfo is a ContentInfo object (defined in [CMS]).
contentInfoはContentInfoオブジェクト([CMS]では、定義される)です。
The four content types used in cmsSequence are AuthenticatedData, Data, EnvelopedData, and SignedData. All of these content types are defined in [CMS].
cmsSequenceで使用される4つのcontent typeが、AuthenticatedDataと、Dataと、EnvelopedDataと、SignedDataです。 これらのcontent typeのすべてが[CMS]で定義されます。
3.2.1.3.1. Authenticated Data
3.2.1.3.1. 認証されたデータ
The AuthenticatedData content type provides a method of doing pre- shared-secret-based validation of data being sent between two parties. Unlike SignedData, it does not specify which party actually generated the information.
AuthenticatedData content typeは2回のパーティーの間に送られるデータのあらかじめ共有された秘密ベースの合法化をするメソッドを提供します。 SignedDataと異なって、それは実際に情報であると生成されたどのパーティーを指定しないか。
AuthenticatedData provides origination authentication in those circumstances where a shared-secret exists, but a PKI-based trust has not yet been established. No PKI-based trust may have been established because a trust anchor has not been installed on the client or no certificate exists for a signing key.
AuthenticatedDataは共有秘密キーが存在していますが、PKIベースの信頼がまだ確立されていないそれらの事情に創作認証を提供します。 信頼アンカーがクライアントの上にインストールされていないか、または証明書が全く署名キーのために存在していないので、どんなPKIベースの信頼も確立されていないかもしれません。
AuthenticatedData content type is used by this document for:
AuthenticatedData content typeは以下にこのドキュメントによって使用されます。
The id-cmc-authData control (Section 6.16), and
そしてイド-cmc-authDataコントロール(セクション6.16)。
The top-level wrapper in environments where an encryption-only key
is being certified.
暗号化だけキーが公認されている環境におけるトップレベルラッパー。
This content type can include both PKIData and PKIResponse as the encapsulated content types. These embedded content types can contain additional controls that need to be processed.
このcontent typeはカプセル化されたcontent typeとしてPKIDataとPKIResponseの両方を含むことができます。 これらの埋め込まれたcontent typeは処理される必要がある追加コントロールを含むことができます。
Schaad & Myers Standards Track [Page 19] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[19ページ]: 2008年6月を構造化します。
3.2.1.3.2. Data
3.2.1.3.2. データ
The Data content type allows for general transport of unstructured data.
Data content typeは不統一なデータの一般的な輸送を考慮します。
The Data content type is used by this document for:
Data content typeは以下にこのドキュメントによって使用されます。
Holding the encrypted random value y for POP proof in the
encrypted POP control (see Section 6.7).
暗号化されたPOPコントロール(セクション6.7を見る)におけるPOP証拠のための暗号化された無作為の値yを保持します。
3.2.1.3.3. Enveloped Data
3.2.1.3.3. おおわれたデータ
The EnvelopedData content type provides for shrouding of data.
EnvelopedData content typeはデータを覆い隠すことに備えます。
The EnvelopedData content type is the primary confidentiality method for sensitive information in this protocol. EnvelopedData can provide encryption of an entire PKI Request (see Section 5). EnvelopedData can also be used to wrap private key material for key archival. If the decryption on an EnvelopedData fails, a Full PKI Response is returned with a CMCFailInfo value of badMessageCheck and a bodyPartID of 0.
EnvelopedData content typeはこのプロトコルの機密情報のためのプライマリ秘密性メソッドです。 EnvelopedDataは全体のPKI Requestの暗号化を提供できます(セクション5を見てください)。 また、キーのために記録保管所で秘密鍵の材料を包装するのにEnvelopedDataを使用できます。 EnvelopedDataの上の復号化が失敗するなら、badMessageCheckのCMCFailInfo値と0のbodyPartIDと共にFull PKI Responseを返します。
3.2.1.3.4. Signed Data
3.2.1.3.4. データであると署名されます。
The SignedData content type provides for authentication and integrity.
SignedData content typeは認証と保全に備えます。
The SignedData content type is used by this document for:
SignedData content typeは以下にこのドキュメントによって使用されます。
The outer wrapper for a PKI Request.
PKI Requestのための外側のラッパー。
The outer wrapper for a PKI Response.
PKI Responseのための外側のラッパー。
As part of processing a PKI Request/Response, the signature(s) MUST be verified. If the signature does not verify and the PKI Request/ Response contains anything other than a CMC Status Info control, a Full PKI Response containing a CMC Status Info control MUST be returned using a CMCFailInfo with a value of badMessageCheck and a bodyPartID of 0.
PKI Request/応答を処理する一部として、署名について確かめなければなりません。 署名が確かめないで、PKI Request/応答がCMC Status Infoコントロール、badMessageCheckとbodyPartIDの値があるCMCFailInfoを使用することでコントロールを返さなければならないCMC Status Infoを含むa Full PKI Response以外の何でも含んでいる、0
For the PKI Response, SignedData allows the server to sign the returning data, if any exists, and to carry the certificates and CRLs corresponding to the PKI Request. If no data is being returned beyond the certificates and CRLs, the EncapsulatedInfo and SignerInfo fields are not populated.
PKI Responseに関しては、SignedDataはサーバにいずれか存在しているなら戻っているデータに署名して、PKI Requestに対応する証明書とCRLsを運ばせます。 証明書とCRLsを超えてデータを全く返していないなら、EncapsulatedInfoとSignerInfo分野に居住しません。
Schaad & Myers Standards Track [Page 20] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[20ページ]: 2008年6月を構造化します。
3.2.1.4. Other Message Bodies
3.2.1.4. 他のメッセージ本体
The otherMsgSequence field of the PKI Request/Response allows for arbitrary data objects to be carried as part of a PKI Request/ Response. This is intended to contain a data object that is not already wrapped in a cmsSequence field (Section 3.2.1.3). The data object is ignored unless a control references the data object by bodyPartID.
PKI Request/応答のotherMsgSequence分野は、任意のデータ・オブジェクトがPKI Request/応答の一部として運ばれるのを許容します。 これがcmsSequence分野で既に包装されないデータ・オブジェクトを含むことを意図する、(セクション3.2 .1 .3)。 コントロールがbodyPartIDでデータ・オブジェクトに参照をつけない場合、データ・オブジェクトは無視されます。
OtherMsg ::= SEQUENCE {
bodyPartID BodyPartID,
otherMsgType OBJECT IDENTIFIER,
otherMsgValue ANY DEFINED BY otherMsgType }
OtherMsg:、:= 系列bodyPartID BodyPartID、otherMsgValueがotherMsgTypeで少しも定義したotherMsgTypeオブジェクト識別子
The fields in OtherMsg have the following meaning:
OtherMsgの分野には、以下の意味があります:
bodyPartID is the unique id identifying this data object.
bodyPartIDはこのデータ・オブジェクトを特定するユニークなイドです。
otherMsgType is the OID that defines the type of message body.
otherMsgTypeはメッセージ本体のタイプを定義するOIDです。
otherMsgValue is the data.
otherMsgValueはデータです。
3.2.2. Body Part Identification
3.2.2. ボディー部分識別
Each element of a PKIData or PKIResponse has an associated body part identifier. The body part identifier is a 4-octet integer using the ASN.1 of:
PKIDataかPKIResponseの各要素には、関連ボディー部分識別子があります。 ボディー部分識別子は以下のASN.1を使用する4八重奏の整数です。
bodyIdMax INTEGER ::= 4294967295
bodyIdMax整数:、:= 4294967295
BodyPartID ::= INTEGER(0..bodyIdMax)
BodyPartID:、:= 整数(0..bodyIdMax)
Body part identifiers are encoded in the certReqIds field for CertReqMsg objects (in a TaggedRequest) or in the bodyPartID field of the other objects. The body part identifier MUST be unique within a single PKIData or PKIResponse. Body part identifiers can be duplicated in different layers (for example, a PKIData embedded within another).
ボディー部分識別子はCertReqMsgオブジェクト(TaggedRequestの)のためのcertReqIds分野か他のオブジェクトのbodyPartID分野でコード化されます。 ボディー部分識別子は独身のPKIDataかPKIResponseの中でユニークであるに違いありません。 異なった層(例えば別のものの中で埋め込まれたPKIData)でボディー部分識別子をコピーできます。
The bodyPartID value of 0 is reserved for use as the reference to the current PKIData object.
0のbodyPartID値は使用のために現在のPKIDataオブジェクトの参照として予約されます。
Some controls, such as the Add Extensions control (Section 6.5.2), use the body part identifier in the pkiDataReference field to refer to a PKI Request in the current PKIData. Some controls, such as the Extended CMC Status Info control (Section 6.1.1), will also use body part identifiers to refer to elements in the previous PKI Request/
Add Extensionsコントロールなどのいくつかのコントロール(セクション6.5.2)が、現在のPKIDataのPKI Requestについて言及するのにpkiDataReference分野でボディー部分識別子を使用します。 また、Extended CMC Status Infoコントロールなどのいくつかのコントロール(セクション6.1.1)が、前のPKI Request/の要素を示すのにボディー部分識別子を使用するでしょう。
Schaad & Myers Standards Track [Page 21] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[21ページ]: 2008年6月を構造化します。
Response. This allows an error to be explicit about the control or PKI Request to which the error applies.
応答。 これはコントロールに関して明白である誤りか誤りが適用されるPKI Requestを許容します。
A BodyPartList contains a list of body parts in a PKI Request/ Response (i.e., the Batch Request control in Section 6.17). The ASN.1 type BodyPartList is defined as:
BodyPartListはPKI Request/応答(すなわち、セクション6.17におけるBatch Requestコントロール)で身体の部分のリストを含んでいます。 ASN.1タイプBodyPartListは以下と定義されます。
BodyPartList ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
BodyPartList:、:= BodyPartIDの系列サイズ(1..MAX)
A BodyPartPath contains a path of body part identifiers moving through nesting (i.e., the Modify Certification Request control in Section 6.5.1). The ASN.1 type BodyPartPath is defined as:
BodyPartPathは(すなわち、セクション6.5.1におけるModify Certification Requestコントロール)を入れ子にしながら進むボディー部分識別子の経路を含んでいます。 ASN.1タイプBodyPartPathは以下と定義されます。
BodyPartPath ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
BodyPartPath:、:= BodyPartIDの系列サイズ(1..MAX)
3.2.3. CMC Unsigned Data Attribute
3.2.3. CMCの未署名のデータ属性
There is sometimes a need to include data in a PKI Request designed to be removed by an RA during processing. An example of this is the inclusion of an encrypted private key, where a Key Archive Agent removes the encrypted private key before sending it on to the CA. One side effect of this desire is that every RA that encapsulates this information needs to move the data so that it is not covered by that RA's signature. (A client PKI Request encapsulated by an RA cannot have a signed control removed by the Key Archive Agent without breaking the RA's signature.) The CMC Unsigned Data attribute addresses this problem.
データを含む必要が処理の間、RAによって取り除かれるように設計されたPKI Requestに時々あります。 この例は暗号化された秘密鍵の包含です、それをカリフォルニアに送る前にKeyアーカイブのエージェントが暗号化された秘密鍵を取り除くところで。 この願望の半面効果はこの情報をカプセル化するあらゆるRAが、データを動かす必要があるのでそれがそのRAの署名でカバーされていないということです。 (RAの署名を壊さないで、RAによってカプセル化されたクライアントPKI RequestはKeyアーカイブのエージェントに署名しているコントロールを取り除かせることができません。) CMC Unsigned Data属性はこのその問題を訴えます。
The CMC Unsigned Data attribute contains information that is not directly signed by a client. When an RA encounters this attribute in the unsigned or unauthenticated attribute field of a request it is aggregating, the CMC Unsigned Data attribute is removed from the request prior to placing the request in a cmsSequence and placed in the unsigned or unauthenticated attributes of the RA's signed or authenticated data wrapper.
CMC Unsigned Data属性はクライアントによって直接署名されない情報を含んでいます。 RAがそれが集めている要求の未署名の、または、非認証された属性分野でこの属性に遭遇するとき、CMC Unsigned Data属性は、要求を置く前に、cmsSequenceで要求から移されて、RAの署名しているか認証されたデータラッパーの未署名の、または、非認証された属性に置かれます。
The CMC Unsigned Data attribute is identified by:
CMC Unsigned Data属性は以下によって特定されます。
id-aa-cmc-unsignedData OBJECT IDENTIFIER ::= {id-aa 34}
イド-aa-cmc-unsignedDataオブジェクト識別子:、:= イド-aa34
The CMC Unsigned Data attribute has the ASN.1 definition:
CMC Unsigned Data属性に、ASN.1定義があります:
CMCUnsignedData ::= SEQUENCE {
bodyPartPath BodyPartPath,
identifier OBJECT IDENTIFIER,
content ANY DEFINED BY identifier
}
CMCUnsignedData:、:= 系列bodyPartPath BodyPartPath、識別子OBJECT IDENTIFIER、満足しているANY DEFINED BY識別子
Schaad & Myers Standards Track [Page 22] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[22ページ]: 2008年6月を構造化します。
The fields in CMCUnsignedData have the following meaning:
CMCUnsignedDataの分野には、以下の意味があります:
bodyPartPath is the path pointing to the control associated with
this data. When an RA moves the control in an unsigned or
unauthenticated attribute up one level as part of wrapping the
data in a new SignedData or AuthenticatedData, the body part
identifier of the embedded item in the PKIData is prepended to the
bodyPartPath sequence.
bodyPartPathはこのデータに関連しているコントロールを示す経路です。 RAが新しいSignedDataかAuthenticatedDataのデータを包装する一部として1つのレベルで未署名の、または、非認証された属性におけるコントロールを動かすとき、PKIDataの埋め込まれた項目に関するボディー部分識別子はbodyPartPath系列にprependedされます。
identifier is the OID that defines the associated data.
識別子は関連データを定義するOIDです。
content is the data.
内容はデータです。
There MUST be at most one CMC Unsigned Data attribute in the UnsignedAttribute sequence of a SignerInfo or in the UnauthenticatedAttribute sequence of an AuthenticatedData. UnsignedAttribute consists of a set of values; the attribute can have any number of values greater than zero in that set. If the CMC Unsigned Data attribute is in one SignerInfo or AuthenticatedData, it MUST appear with the same values(s) in all SignerInfo and AuthenticatedData items.
SignerInfoのUnsignedAttribute系列かAuthenticatedDataのUnauthenticatedAttribute系列にはCMC Unsigned Data属性が最も1つにあるに違いありません。 UnsignedAttributeは1セットの値から成ります。 属性で、いろいろな値がそれのゼロがセットしたよりすばらしくなる場合があります。 CMC Unsigned Data属性が1SignerInfoかAuthenticatedDataにあるなら、同じ値がすべてのSignerInfoとAuthenticatedDataの品目にある状態で、それは現れなければなりません。
4. PKI Responses
4. PKI応答
Two types of PKI Responses exist. This section gives the details on both types.
PKI Responsesの2つのタイプが存在しています。 このセクションは両方のタイプに関する詳細を述べます。
4.1. Simple PKI Response
4.1. 簡単なPKI応答
Clients MUST be able to process the Simple PKI Response. The Simple PKI Response consists of a SignedData with no EncapsulatedContentInfo and no SignerInfo. The certificates requested in the PKI Response are returned in the certificate field of the SignedData.
クライアントはSimple PKI Responseを処理できなければなりません。 Simple PKI ResponseはEncapsulatedContentInfoにもかかわらず、どんなSignerInfoなしでもSignedDataから成りません。 SignedDataの証明書分野でPKI Responseで要求された証明書を返します。
Clients MUST NOT assume the certificates are in any order. Servers SHOULD include all intermediate certificates needed to form complete certification paths to one or more trust anchors, not just the newly issued certificate(s). The server MAY additionally return CRLs in the CRL bag. Servers MAY include the self-signed certificates. Clients MUST NOT implicitly trust included self-signed certificate(s) merely due to its presence in the certificate bag. In the event clients receive a new self-signed certificate from the server, clients SHOULD provide a mechanism to enable the user to use the certificate as a trust anchor. (The Publish Trust Anchors control (Section 6.15) should be used in the event that the server intends the client to accept one or more certificates as trust anchors. This requires the use of the Full PKI Response message.)
クライアントは、証明書が順不同であると仮定してはいけません。 サーバSHOULDは新譜の証明書だけではなく、完全な証明経路を1人以上の信頼アンカーに形成するのに必要であるすべての中間的証明書を含んでいます。 サーバはCRLバッグでさらに、CRLsを返すかもしれません。 サーバは自己署名入りの証書を含むかもしれません。 クライアントは単に存在のため証明書バッグでそれとなく含まれている自己署名入りの証書を信じてはいけません。 イベントクライアントでは、サーバから新しい自己署名入りの証書を受け取ってください、とクライアントSHOULDはユーザが信頼アンカーとして証明書を使用するのを可能にするためにメカニズムを前提とします。 (信頼が投錨されるときクライアントがサーバが1通以上の証明書を受け入れるつもりであるなら、Publish Trust Anchorsコントロール(セクション6.15)は使用されるべきです。 これはFull PKI Responseメッセージの使用を必要とします。)
Schaad & Myers Standards Track [Page 23] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[23ページ]: 2008年6月を構造化します。
4.2. Full PKI Response
4.2. 完全なPKI応答
Clients MUST be able to process a Full PKI Response.
クライアントはFull PKI Responseを処理できなければなりません。
The Full PKI Response consists of a SignedData or AuthenticatedData encapsulating a PKIResponse content type. The certificates issued in a PKI Response are returned in the certificates field of the immediately encapsulating SignedData.
Full PKI ResponseはPKIResponse content typeをカプセル化するSignedDataかAuthenticatedDataから成ります。 すぐに要約のSignedDataの証明書分野でPKI Responseで発行された証明書を返します。
Clients MUST NOT assume the certificates are in any order. Servers SHOULD include all intermediate certificates needed to form complete chains to one or more trust anchors, not just the newly issued certificate(s). The server MAY additionally return CRLs in the CRL bag. Servers MAY include self-signed certificates. Clients MUST NOT implicitly trust included self-signed certificate(s) merely due to its presence in the certificate bag. In the event clients receive a new self-signed certificate from the server, clients MAY provide a mechanism to enable the user to explicitly use the certificate as a trust anchor. (The Publish Trust Anchors control (Section 6.15) exists for the purpose of allowing for distribution of trust anchor certificates. If a trusted anchor publishes a new trusted anchor, this is one case where automated trust of the new trust anchor could be allowed.)
クライアントは、証明書が順不同であると仮定してはいけません。 サーバSHOULDは新譜の証明書だけではなく、1人以上の信頼アンカーに完全なチェーンを形成するのに必要であるすべての中間的証明書を含んでいます。 サーバはCRLバッグでさらに、CRLsを返すかもしれません。 サーバは自己署名入りの証書を含むかもしれません。 クライアントは単に存在のため証明書バッグでそれとなく含まれている自己署名入りの証書を信じてはいけません。 イベントクライアントでは、サーバから新しい自己署名入りの証書を受け取ってください、とクライアントはユーザが信頼アンカーとして明らかに証明書を使用するのを可能にするためにメカニズムを前提とするかもしれません。 (Publish Trust Anchorsコントロール(セクション6.15)は信頼アンカー証明書の分配を考慮する目的のために存在しています。 信じられたアンカーが新しい信じられたアンカーを発行するなら、これは新しい信頼アンカーの自動化された信頼を許容できた1つのそうです。)
4.2.1. PKIResponse Content Type
4.2.1. PKIResponse content type
The PKIResponse content type is used for the Full PKI Response. The PKIResponse content type is identified by:
PKIResponse content typeはFull PKI Responseに使用されます。 PKIResponse content typeは以下によって特定されます。
id-cct-PKIResponse ::= {id-pkix id-cct(12) 3 }
イド-cct-PKIResponse:、:= イド-pkixイド-cct(12)3
The ASN.1 structure corresponding to the PKIResponse content type is:
PKIResponse content typeに対応するASN.1構造は以下の通りです。
PKIResponse ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
PKIResponse:、:= 系列TaggedAttributeのcontrolSequence系列サイズ(0..MAX)、TaggedContentInfoのcmsSequence系列サイズ(0..MAX)、OtherMsgのotherMsgSequence系列サイズ(0..MAX)
ReponseBody ::= PKIResponse
ReponseBody:、:= PKIResponse
Note: In [RFC2797], this ASN.1 type was named ResponseBody. It has been renamed to PKIResponse for clarity and the old name kept as a synonym.
以下に注意してください。 [RFC2797]では、このASN.1タイプはResponseBodyと命名されました。 それは明快と同義語として保たれた旧名のためにPKIResponseに改名されました。
Schaad & Myers Standards Track [Page 24] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[24ページ]: 2008年6月を構造化します。
The fields in PKIResponse have the following meaning:
PKIResponseの分野には、以下の意味があります:
controlSequence is a sequence of controls. The controls defined in
this document are found in Section 6. Controls can be defined by
other parties. Details on the TaggedAttribute structure are found
in Section 3.2.1.1.
controlSequenceはコントロールの系列です。 本書では定義されたコントロールはセクション6で見つけられます。 相手はコントロールを定義できます。 TaggedAttribute構造に関する詳細はセクション3.2.1で.1に見つけられます。
cmsSequence is a sequence of [CMS] message objects. See
Section 3.2.1.3 for more details.
cmsSequenceは[CMS]メッセージオブジェクトの系列です。 セクション3.2を見てください。.1 .3 その他の詳細のために。
otherMsgSequence is a sequence of arbitrary data objects. Data
objects placed here are referred to by one or more controls. This
allows for controls to use large amounts of data without the data
being embedded in the control. See Section 3.2.1.4 for more
details.
otherMsgSequenceは任意のデータ・オブジェクトの系列です。 1つ以上のコントロールでここに置かれたデータ・オブジェクトは言及されます。 これは、コントロールがコントロールに埋め込まれているデータなしで多量のデータを使用するのを許容します。 セクション3.2を見てください。.1 .4 その他の詳細のために。
Processing of PKIResponse by a recipient is as follows:
受取人によるPKIResponseの処理は以下の通りです:
1. All controls should be examined and processed in an appropriate
manner. The appropriate processing is to complete processing at
this time, to ignore the control, or to place the control on a
to-do list for later processing.
1. すべてのコントロールが、適切な方法で調べられて、加工処理されるべきです。 適切な処理は、このとき処理するのを完了するか、コントロールを無視するか、または後で処理するためのトゥドゥリストにコントロールを置くことです。
2. Additional processing of non-element items includes the saving of
certificates and CRLs present in wrapping layers. This type of
processing is based on the consumer of the element and should not
be relied on by generators.
2. 非要素の品目の追加処理はラッピング層の現在の証明書とCRLsの節約を含んでいます。 このタイプの処理を要素の消費者に基礎づけて、ジェネレータは依存するはずがありません。
No processing is required for cmsSequence or otherMsgSequence members of the PKIResponse, if items are present and are not referenced by a control. In this case, the cmsSequence and otherMsgSequence members are to be ignored.
処理でないのがPKIResponseのcmsSequenceかotherMsgSequenceメンバーに必要です、項目が存在していて、コントロールで参照をつけられないなら。 この場合、cmsSequenceとotherMsgSequenceメンバーは無視されることになっています。
5. Application of Encryption to a PKI Request/Response
5. PKI要求/応答への暗号化の応用
There are occasions when a PKI Request or Response must be encrypted in order to prevent disclosure of information in the PKI Request/ Response from being accessible to unauthorized entities. This section describes the means to encrypt Full PKI Requests and Responses (Simple PKI Requests cannot be encrypted). Data portions of PKI Requests and Responses that are placed in the cmsSequence field can be encrypted separately.
PKI Request/応答における、情報の公開が権限のない実体にアクセスしやすいのを防ぐためにPKI RequestかResponseを暗号化しなければならない時があります。 このセクションはFull PKI RequestsとResponsesを暗号化する手段を説明します(簡単なPKI Requestsを暗号化できません)。 別々にcmsSequence分野に置かれるPKI RequestsとResponsesのデータ部を暗号化できます。
Confidentiality is provided by wrapping the PKI Request/Response (a SignedData) in an EnvelopedData. The nested content type in the EnvelopedData is id-SignedData. Note that this is different from S/MIME where there is a MIME layer placed between the encrypted and signed data. It is recommended that if an EnvelopedData layer is
EnvelopedDataでPKI Request/応答(SignedData)を包装することによって、秘密性を提供します。 EnvelopedDataの入れ子にされたcontent typeはイド-SignedDataです。 これが暗号化されて署名しているデータの間に置かれたMIME層があるS/MIMEと異なっていることに注意してください。 EnvelopedData層が推薦されるなら、それはそれに推薦されます。
Schaad & Myers Standards Track [Page 25] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[25ページ]: 2008年6月を構造化します。
applied to a PKI Request/Response, a second signature layer be placed outside of the EnvelopedData layer. The following figure shows how this nesting would be done:
PKI Request/応答に適用されていて、2番目の署名はEnvelopedDataの置かれた外部が層であったなら層にされます。 以下の図は、この巣篭もりがどのように完了しているかを示します:
Normal Option 1 Option 2
------ -------- --------
SignedData EnvelopedData SignedData
PKIData SignedData EnvelopedData
PKIData SignedData
PKIData
通常のオプション1オプション2------ -------- -------- SignedData EnvelopedData SignedData PKIData SignedData EnvelopedData PKIData SignedData PKIData
Note: PKIResponse can be substituted for PKIData in the above figure.
以下に注意してください。 上図のPKIDataにPKIResponseを代入できます。
Options 1 and 2 prevent leakage of sensitive data by encrypting the Full PKI Request/Response. An RA that receives a PKI Request that it cannot decrypt MAY reject the PKI Request unless it can process the PKI Request without knowledge of the contents (i.e., all it does is amalgamate multiple PKI Requests and forward them to a server).
オプション1と2は、Full PKI Request/応答を暗号化することによって、極秘データの漏出を防ぎます。 コンテンツに関する知識なしでPKI Requestを処理できないなら、それが解読することができないPKI Requestを受けるRAはPKI Requestを拒絶するかもしれません(すなわち、するのは、複数のPKI Requestsを合併して、彼らをサーバに送ることです)。
After the RA removes the envelope and completes processing, it may then apply a new EnvelopedData layer to protect PKI Requests for transmission to the next processing agent. Section 7 contains more information about RA processing.
そして、RAが、封筒を取り外して、処理するのを完了した後に、それは、次期処理エージェントへの伝送のためPKI Requestsを保護するために新しいEnvelopedData層を適用するかもしれません。 セクション7はRA処理に関する詳しい情報を含みます。
Full PKI Requests/Responses can be encrypted or transmitted in the clear. Servers MUST provide support for all three options.
明確で完全なPKI Requests/応答を暗号化するか、または伝えることができます。 サーバはすべての3つのオプションのサポートを提供しなければなりません。
Alternatively, an authenticated, secure channel could exist between the parties that require confidentiality. Clients and servers MAY use such channels instead of the technique described above to provide secure, private communication of Simple and Full PKI Requests/ Responses.
あるいはまた、認証されて、安全なチャンネルは秘密性を必要とするパーティーの間に存在できました。 クライアントとサーバはSimpleの安全で、個人的なコミュニケーションを提供するために上で説明されたテクニックの代わりにそのようなチャンネルとFull PKI Requests/応答を使用するかもしれません。
6. Controls
6. コントロール
Controls are carried as part of both Full PKI Requests and Responses. Each control is encoded as a unique OID followed by the data for the control (see syntax in Section 3.2.1.1. The encoding of the data is based on the control. Processing systems would first detect the OID (TaggedAttribute attrType) and process the corresponding control value (TaggedAttribute attrValues) prior to processing the message body.
コントロールはFull PKI RequestsとResponsesの両方の一部として運ばれます。 ユニークなOIDがコントロールのためのデータで続いて、各コントロールはコード化されます。.1にセクション3.2.1における構文を見てください。データのコード化はコントロールに基づいています。(処理システムは、最初に、OID(TaggedAttribute attrType)を検出して、メッセージ本体を処理する前に、対応するコントロール値(TaggedAttribute attrValues)を処理するでしょう。
Schaad & Myers Standards Track [Page 26] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[26ページ]: 2008年6月を構造化します。
The OIDs are all defined under the following arc:
OIDsは以下のアークの下ですべて定義されます:
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
イド-pkix OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)
id-cmc OBJECT IDENTIFIER ::= { id-pkix 7 }
イド-cmc OBJECT IDENTIFIER:、:= イド-pkix7
The following table lists the names, OID, and syntactic structure for each of the controls described in this document.
以下のテーブルは本書では説明されたそれぞれのコントロールのために名前、OID、および統語構造を記載します。
Identifier Description OID ASN.1 Structure Section
--------------------------------------------------------------------
id-cmc-statusInfo id-cmc 1 CMCStatusInfo 6.1.2
id-cmc-identification id-cmc 2 UTF8String 6.2.3
id-cmc-identityProof id-cmc 3 OCTET STRING 6.2.2
id-cmc-dataReturn id-cmc 4 OCTET STRING 6.4
id-cmc-transactionId id-cmc 5 INTEGER 6.6
id-cmc-senderNonce id-cmc 6 OCTET STRING 6.6
id-cmc-recipientNonce id-cmc 7 OCTET STRING 6.6
id-cmc-addExtensions id-cmc 8 AddExtensions 6.5.2
id-cmc-encryptedPOP id-cmc 9 EncryptedPOP 6.7
id-cmc-decryptedPOP id-cmc 10 DecryptedPOP 6.7
id-cmc-lraPOPWitness id-cmc 11 LraPOPWitness 6.8
id-cmc-getCert id-cmc 15 GetCert 6.9
id-cmc-getCRL id-cmc 16 GetCRL 6.10
id-cmc-revokeRequest id-cmc 17 RevokeRequest 6.11
id-cmc-regInfo id-cmc 18 OCTET STRING 6.12
id-cmc-responseInfo id-cmc 19 OCTET STRING 6.12
id-cmc-queryPending id-cmc 21 OCTET STRING 6.13
id-cmc-popLinkRandom id-cmc 22 OCTET STRING 6.3.1
id-cmc-popLinkWitness id-cmc 23 OCTET STRING 6.3.1
id-cmc-popLinkWitnessV2 id-cmc 33 OCTET STRING 6.3.1.1
id-cmc-confirmCertAcceptance id-cmc 24 CMCCertId 6.14
id-cmc-statusInfoV2 id-cmc 25 CMCStatusInfoV2 6.1.1
id-cmc-trustedAnchors id-cmc 26 PublishTrustAnchors 6.15
id-cmc-authData id-cmc 27 AuthPublish 6.16
id-cmc-batchRequests id-cmc 28 BodyPartList 6.17
id-cmc-batchResponses id-cmc 29 BodyPartList 6.17
id-cmc-publishCert id-cmc 30 CMCPublicationInfo 6.18
id-cmc-modCertTemplate id-cmc 31 ModCertTemplate 6.5.1
id-cmc-controlProcessed id-cmc 32 ControlsProcessed 6.19
id-cmc-identityProofV2 id-cmc 34 IdentityProofV2 6.2.1
識別子記述OID ASN.1構造部分-------------------------------------------------------------------- イド-cmc1イド-cmc-statusInfo CMCStatusInfo6.1.2イドcmc識別イド-cmc2UTF8String6.2.3イド-cmc-identityProofイド-cmc3OCTET STRING6.2.2イド-cmc-dataReturnイド-cmc4OCTET STRING6.4イド-cmc-transactionIdイド-cmc5INTEGER6.6イド-cmc-senderNonceイド-cmc6OCTET STRING6; 6 イド-cmc11イド-cmc8イド-cmc-recipientNonceイド-cmc7OCTET STRING6.6イド-cmc-addExtensions AddExtensions6.5.2イド-cmc-encryptedPOPイド-cmc9EncryptedPOP6.7イド-cmc-decryptedPOPイド-cmc10DecryptedPOP6.7イド-cmc-lraPOPWitness LraPOPWitness6; 8 イド-cmc-getCertイド-cmc15GetCert6.9イド-cmc-getCRLイド-cmc16GetCRL6.10イド-cmc-revokeRequestイド-cmc17RevokeRequest6.11イド-cmc-regInfoイド-cmc18OCTET STRING6.12イド-cmc-responseInfoイド-cmc19OCTET STRING6.12イド-cmc-queryPendingイド-cmc21OCTET STRING6.13イド-cmc-popLinkRandomイド-cmc22OCTET STRING6.3.1イド-cmc-popLinkWitnessイド-cmc23OCTET STRING6.3.1イド-cmc-popLinkWitnessV2イド-cmc33OCTET STRING6.3.1.1イド-cmc-confirmCertAcceptanceイド-cmc24CMCCertId6.14イド-cmc-statusInfoV2イド-cmc25CMCStatusInfoV2 6.1.1イド-cmc26イド-cmc-trustedAnchors PublishTrustAnchors6.15イド-cmc-authDataイド-cmc27AuthPublish6.16イド-cmc-batchRequestsイド-cmc28BodyPartList6.17イド-cmc-batchResponsesイド-cmc29BodyPartList6.17イド-cmc-publishCertイド-cmc30CMCPublicationInfo6.18イド-cmc-modCertTemplateイド-cmc31ModCertTemplate6.5.1イド-cmc-controlProcessedイド-cmc32ControlsProcessed6.19イド-cmc-identityProofV2イド-cmc34IdentityProofV2 6.2.1
Table 1: CMC Control Attributes
テーブル1: CMCコントロール属性
Schaad & Myers Standards Track [Page 27] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[27ページ]: 2008年6月を構造化します。
6.1. CMC Status Info Controls
6.1. CMC状態インフォメーションコントロール
The CMC Status Info controls return information about the status of a client/server request/response. Two controls are described in this section. The Extended CMC Status Info control is the preferred control; the CMC Status Info control is included for backwards compatibility with RFC 2797.
CMC Status Infoコントロールはクライアント/サーバ要求/応答の状態の情報を返します。 2つのコントロールがこのセクションで説明されます。 Extended CMC Status Infoコントロールは都合のよいコントロールです。 CMC Status InfoコントロールはRFC2797との遅れている互換性のために含まれています。
Servers MAY emit multiple CMC status info controls referring to a single body part. Clients MUST be able to deal with multiple CMC status info controls in a PKI Response. Servers MUST use the Extended CMC Status Info control, but MAY additionally use the CMC Status Info control. Clients MUST be able to process the Extended
サーバはただ一つの身体の部分について言及する複数のCMC状態インフォメーションコントロールを放つかもしれません。 クライアントはPKI Responseでの複数のCMC状態インフォメーションコントロールに対処できなければなりません。 サーバは、Extended CMC Status Infoコントロールを使用しなければなりませんが、さらに、CMC Status Infoコントロールを使用するかもしれません。 クライアントはExtendedを処理できなければなりません。
CMC Status Info control.
CMC Status Infoは制御します。
6.1.1. Extended CMC Status Info Control
6.1.1. 拡張CMC状態インフォメーションコントロール
The Extended CMC Status Info control is identified by the OID:
Extended CMC Status InfoコントロールはOIDによって特定されます:
id-cmc-statusInfoV2 ::= { id-cmc 25 }
イド-cmc-statusInfoV2:、:= イド-cmc25
The Extended CMC Status Info control has the ASN.1 definition:
Extended CMC Status Infoコントロールには、ASN.1定義があります:
CMCStatusInfoV2 ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF BodyPartReference,
statusString UTF8String OPTIONAL,
otherInfo OtherStatusInfo OPTIONAL
}
CMCStatusInfoV2:、:= 系列cMCStatus CMCStatus、statusString UTF8String任意の、そして、otherInfo OtherStatusInfo任意のBodyPartReferenceのbodyList系列サイズ(1..MAX)
OtherStatusInfo ::= CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo,
extendedFailInfo ExtendedFailInfo
}
OtherStatusInfo:、:= 選択failInfo CMCFailInfo、pendInfo PendInfo、extendedFailInfo ExtendedFailInfo
PendInfo ::= SEQUENCE {
pendToken OCTET STRING,
pendTime GeneralizedTime
}
PendInfo:、:= 系列pendToken八重奏ストリング、pendTime GeneralizedTime
ExtendedFailInfo ::= SEQUENCE {
failInfoOID OBJECT IDENTIFIER,
failInfoValue ANY DEFINED BY failInfoOID
}
ExtendedFailInfo:、:= 系列failInfoOIDオブジェクト識別子、failInfoOIDによって少しも定義されたfailInfoValue
Schaad & Myers Standards Track [Page 28] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[28ページ]: 2008年6月を構造化します。
BodyPartReference ::= CHOICE {
bodyPartID BodyPartID,
bodyPartPath BodyPartPath
}
BodyPartReference:、:= 選択bodyPartID BodyPartID、bodyPartPath BodyPartPath
The fields in CMCStatusInfoV2 have the following meaning:
CMCStatusInfoV2の分野には、以下の意味があります:
cMCStatus contains the returned status value. Details are in
Section 6.1.3.
cMCStatusは返された状態値を含んでいます。 セクション6.1.3には詳細があります。
bodyList identifies the controls or other elements to which the
status value applies. If an error is returned for a Simple PKI
Request, this field is the bodyPartID choice of BodyPartReference
with the single integer of value 1.
bodyListは状態値が適用されるコントロールか他の要素を特定します。 誤りがSimple PKI Requestのために返されるなら、この分野は価値1のただ一つの整数があるBodyPartReferenceのbodyPartID選択です。
statusString contains additional description information. This
string is human readable.
statusStringは追加記述情報を含んでいます。 このストリングは読み込み可能な状態で人間です。
otherInfo contains additional information that expands on the CMC
status code returned in the cMCStatus field.
otherInfoはcMCStatus分野で返されたCMCステータスコードについて詳述する追加情報を含んでいます。
The fields in OtherStatusInfo have the following meaning:
OtherStatusInfoの分野には、以下の意味があります:
failInfo is described in Section 6.1.4. It provides an error code
that details what failure occurred. This choice is present only
if cMCStatus contains the value failed.
failInfoはセクション6.1.4で説明されます。 それはどんな失敗が起こったかを詳しく述べるエラーコードを提供します。 cMCStatusが失敗された値を含んでいる場合にだけ、この選択は存在しています。
pendInfo contains information about when and how the client should
request the result of this request. It is present when the
cMCStatus is either pending or partial. pendInfo uses the
structure PendInfo, which has the fields:
pendInfoはいつ、クライアントがどうこの要求の結果を要求するべきであるかの情報を含んでいます。 cMCStatusが未定であるか、または部分的であるときに、それは存在しています。(PendInfoは分野を持っています)。pendInfoは構造PendInfoを使用します:
pendToken is the token used in the Query Pending control
(Section 6.13).
pendTokenはQuery Pendingコントロール(セクション6.13)に使用されるトークンです。
pendTime contains the suggested time the server wants to be
queried about the status of the certification request.
pendTimeはサーバを証明要求の状態に関して質問されたい提案された時を含んでいます。
extendedFailInfo includes application-dependent detailed error
information. This choice is present only if cMCStatus contains
the value failed. Caution should be used when defining new values
as they may not be correctly recognized by all clients and
servers. The CMCFailInfo value of internalCAError may be assumed
if the extended error is not recognized. This field uses the type
ExtendedFailInfo. ExtendedFailInfo has the fields:
extendedFailInfoはアプリケーション依存する詳細なエラー情報を含んでいます。 cMCStatusが失敗された値を含んでいる場合にだけ、この選択は存在しています。 新しい値を定義するとき、それらがすべてのクライアントとサーバによって正しく認められないとき、警告は使用されるべきです。 拡張誤りが認識されないなら、internalCAErrorのCMCFailInfo値は想定されるかもしれません。 この分野はタイプExtendedFailInfoを使用します。 ExtendedFailInfoには、分野があります:
failInfoOID contains an OID that is associated with a set of
extended error values.
failInfoOIDは1セットの拡張誤り値に関連しているOIDを含んでいます。
Schaad & Myers Standards Track [Page 29] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[29ページ]: 2008年6月を構造化します。
failInfoValue contains an extended error code from the defined
set of extended error codes.
failInfoValueは定義されたセットの拡張エラーコードからの拡張エラーコードを含んでいます。
If the cMCStatus field is success, the Extended CMC Status Info control MAY be omitted unless it is the only item in the response.
Extended CMC Status InfoコントロールはcMCStatus分野が成功であり、それが応答で唯一の項目でないなら省略されるかもしれません。
6.1.2. CMC Status Info Control
6.1.2. CMC状態インフォメーションコントロール
The CMC Status Info control is identified by the OID:
CMC Status InfoコントロールはOIDによって特定されます:
id-cmc-statusInfo ::= { id-cmc 1 }
イド-cmc-statusInfo:、:= イド-cmc1
The CMC Status Info control has the ASN.1 definition:
CMC Status Infoコントロールには、ASN.1定義があります:
CMCStatusInfo ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList BodyPartList,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo } OPTIONAL
}
CMCStatusInfo:、:= 系列cMCStatus CMCStatus、bodyList BodyPartList、任意のstatusString UTF8String otherInfo選択、failInfo CMCFailInfo、pendInfo PendInfo、任意
The fields in CMCStatusInfo have the following meaning:
CMCStatusInfoの分野には、以下の意味があります:
cMCStatus contains the returned status value. Details are in
Section 6.1.3.
cMCStatusは返された状態値を含んでいます。 セクション6.1.3には詳細があります。
bodyList contains the list of controls or other elements to which
the status value applies. If an error is being returned for a
Simple PKI Request, this field contains a single integer of value
1.
bodyListは状態値が適用されるコントロールか他の要素のリストを含んでいます。 誤りがSimple PKI Requestのために返されるなら、この分野は価値1のただ一つの整数を含んでいます。
statusString contains additional description information. This
string is human readable.
statusStringは追加記述情報を含んでいます。 このストリングは読み込み可能な状態で人間です。
otherInfo provides additional information that expands on the CMC
status code returned in the cMCStatus field.
otherInfoはcMCStatus分野で返されたCMCステータスコードについて詳述する追加情報を提供します。
failInfo is described in Section 6.1.4. It provides an error
code that details what failure occurred. This choice is
present only if cMCStatus is failed.
failInfoはセクション6.1.4で説明されます。 それはどんな失敗が起こったかを詳しく述べるエラーコードを提供します。 cMCStatusが失敗されている場合にだけ、この選択は存在しています。
pendInfo uses the PendInfo ASN.1 structure in Section 6.1.1. It
contains information about when and how the client should
request results of this request. The pendInfo field MUST be
populated for a cMCStatus value of pending or partial. Further
pendInfoはセクション6.1.1にPendInfo ASN.1構造を使用します。 それはいつ、クライアントがどうこの要求の結果を要求するべきであるかの情報を含んでいます。 未定であるか部分的のcMCStatus値のためにpendInfo分野に居住しなければなりません。 一層
Schaad & Myers Standards Track [Page 30] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[30ページ]: 2008年6月を構造化します。
details can be found in Section 6.1.1 (Extended CMC Status Info
Control) and Section 6.13 (Query Pending Control ).
セクション6.1.1(拡張CMC Status Info Control)とセクション6.13で詳細を見つけることができます(Pending Controlについて質問してください)。
If the cMCStatus field is success, the CMC Status Info control MAY be omitted unless it is the only item in the response. If no status exists for a Simple or Full PKI Request, then the value of success is assumed.
CMC Status InfoコントロールはcMCStatus分野が成功であり、それが応答で唯一の項目でないなら省略されるかもしれません。 状態が全くSimpleかFull PKI Requestのために存在していないなら、成功の値は想定されます。
6.1.3. CMCStatus Values
6.1.3. CMCStatus値
CMCStatus is a field in the Extended CMC Status Info and CMC Status Info controls. This field contains a code representing the success or failure of a specific operation. CMCStatus has the ASN.1 structure:
CMCStatusはExtended CMC Status InfoとCMC Status Infoコントロールで分野です。 この分野は特定の操作の成否を表すコードを含んでいます。 CMCStatusには、ASN.1構造があります:
CMCStatus ::= INTEGER {
success (0),
-- reserved (1),
failed (2),
pending (3),
noSupport (4),
confirmRequired (5),
popRequired (6),
partial (7)
}
CMCStatus:、:= 整数成功(0)--(3)、noSupport(4)、confirmRequired(5)、popRequired(6)、部分的な(7)まで(1)を予約して、(2)に失敗します。
The values of CMCStatus have the following meaning:
CMCStatusの値には、以下の意味があります:
success indicates the request was granted or the action was
completed.
成功は、要求が承諾されたか、または操作が完了したのを示します。
failed indicates the request was not granted or the action was not
completed. More information is included elsewhere in the
response.
失敗、要求が承諾されなかったか、または操作が完了しなかったのを示します。 詳しい情報は応答におけるほかの場所に含まれています。
pending indicates the PKI Request has yet to be processed. The
requester is responsible to poll back on this Full PKI request.
pending may only be returned for certification request operations.
未定である、PKI Requestがまだ処理されていないのを示します。 リクエスタがこのFull PKI要求のときに投票するのにおいて原因となる、未定である、証明要求操作のために返すだけであるかもしれません。
noSupport indicates the requested operation is not supported.
noSupportは、要求された操作がサポートされないのを示します。
confirmRequired indicates a Confirm Certificate Acceptance control
(Section 6.14) must be returned before the certificate can be
used.
confirmRequiredされました。証明書を使用できる前にConfirm Certificate Acceptanceコントロール(セクション6.14)を返さなければならないのを示します。
popRequired indicates a direct POP operation is required
(Section 6.3.1.3).
popRequiredする、ダイレクトPOP操作が必要であることを示す、(セクション6.3 .1 .3)。
Schaad & Myers Standards Track [Page 31] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[31ページ]: 2008年6月を構造化します。
partial indicates a partial PKI Response is returned. The requester
is responsible to poll back for the unfulfilled portions of the
Full PKI Request.
部分的である、部分的なPKI Responseが返されるのを示します。 リクエスタはFull PKI Requestの満たされていない部分に投票して戻すのにおいて原因となります。
6.1.4. CMCFailInfo
6.1.4. CMCFailInfo
CMCFailInfo is a field in the Extended CMC Status Info and CMC Status Info controls. CMCFailInfo conveys more detailed information relevant to the interpretation of a failure condition. The CMCFailInfo has the following ASN.1 structure:
CMCFailInfoはExtended CMC Status InfoとCMC Status Infoコントロールで分野です。 CMCFailInfoは失敗状態の解釈に関連しているより詳細な情報を伝えます。 CMCFailInfoには、以下のASN.1構造があります:
CMCFailInfo ::= INTEGER {
badAlg (0),
badMessageCheck (1),
badRequest (2),
badTime (3),
badCertId (4),
unsupportedExt (5),
mustArchiveKeys (6),
badIdentity (7),
popRequired (8),
popFailed (9),
noKeyReuse (10),
internalCAError (11),
tryLater (12),
authDataFail (13)
}
CMCFailInfo:、:= 整数badAlg(0)、badMessageCheck(1)、badRequest(2)、badTime(3)、badCertId(4)、unsupportedExt(5)、mustArchiveKeys(6)、badIdentity(7)、popRequired(8)popFailed(9)、noKeyReuse(10)、internalCAError(11)、tryLater(12)、authDataFail(13)
The values of CMCFailInfo have the following meanings:
CMCFailInfoの値には、以下の意味があります:
badAlg indicates unrecognized or unsupported algorithm.
badAlgは認識されていないかサポートされないアルゴリズムを示します。
badMessageCheck indicates integrity check failed.
badMessageCheckは、保全チェックが失敗したのを示します。
badRequest indicates transaction was not permitted or supported.
最もbadRequestに、トランザクションが受入れられもしませんでしたし、サポートもされなかったのを示します。
badTime indicates message time field was not sufficiently close to
the system time.
badTimeは、メッセージ時間分野がシステム時間の十分近くになかったのを示します。
badCertId indicates no certificate could be identified matching the
provided criteria.
badCertIdは、提供された評価基準を合わせながら証明書を全く特定できなかったのを示します。
unsupportedExt indicates a requested X.509 extension is not
supported by the recipient CA.
unsupportedExtは、要求されたX.509拡張子が受取人カリフォルニアによってサポートされないのを示します。
mustArchiveKeys indicates private key material must be supplied.
mustArchiveKeysは、秘密鍵の材料を供給しなければならないのを示します。
badIdentity indicates identification control failed to verify.
badIdentityはコントロールが確かめなかった識別を示します。
Schaad & Myers Standards Track [Page 32] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[32ページ]: 2008年6月を構造化します。
popRequired indicates server requires a POP proof before issuing
certificate.
popRequiredされました。サーバが発行証明書の前でPOP証拠を必要とするのを示します。
popFailed indicates POP processing failed.
popFailedされました。POP処理が失敗したのを示します。
noKeyReuse indicates server policy does not allow key reuse.
noKeyReuseは、サーバ方針が主要な再利用を許さないのを示します。
internalCAError indicates that the CA had an unknown internal
failure.
internalCAErrorは、カリフォルニアには未知の内部の失敗があったのを示します。
tryLater indicates that the server is not accepting requests at this
time and the client should try at a later time.
tryLaterは、サーバがこのとき要求を受け入れていないのを示します、そして、クライアントは後で試みるべきです。
authDataFail indicates failure occurred during processing of
authenticated data.
authDataFailは、失敗が認証されたデータの処理の間起こったのを示します。
If additional failure reasons are needed, they SHOULD use the ExtendedFailureInfo item in the Extended CMC Status Info control. However, for closed environments they can be defined using this type. Such codes MUST be in the range from 1000 to 1999.
追加失敗であるなら、理由が必要であり、それらはExtended CMC Status InfoのExtendedFailureInfoの品目が制御するSHOULD使用です。 しかしながら、閉じている環境において、このタイプを使用することでそれらを定義できます。 そのようなコードが1000年から1999年までの範囲にあるに違いありません。
6.2. Identification and Identity Proof Controls
6.2. 識別とアイデンティティ証拠コントロール
Some CAs and RAs require that a proof-of-identity be included in a certification request. Many different ways of doing this exist with different degrees of security and reliability. Most are familiar with a bank's request to provide your mother's maiden name as a form of identity proof. The reasoning behind requiring a proof-of- identity can be found in Appendix C of [CRMF].
いくつかのCAsとRAsが、身元の証拠が証明要求に含まれているのを必要とします。 これをする多くの異なった方法が異なった度合いのセキュリティと信頼性で存在しています。 大部分はアイデンティティ証拠のフォームとしてあなたの母親の旧姓を提供するという銀行の要求になじみ深いです。 -証拠を必要とする後ろで推論して、アイデンティティ缶では、[CRMF]のAppendix Cで見つけられてください。
CMC provides a method to prove the client's identity based on a client/server shared-secret. If clients support the Full PKI Request, clients MUST implement this method of identity proof (Section 6.2.2). Servers MUST provide this method, but MAY additionally support bilateral methods of similar strength.
CMCはクライアントのアイデンティティがクライアント/サーバに基づいた共有秘密キーであると立証するメソッドを提供します。 クライアントがFull PKI Requestをサポートするなら、クライアントはアイデンティティ証拠(セクション6.2.2)のこのメソッドを実装しなければなりません。 サーバは、このメソッドを提供しなければなりませんが、さらに、同様の強さの双方のメソッドをサポートするかもしれません。
This document also provides an Identification control (Section 6.2.3). This control is a simple method to allow a client to state who they are to the server. Generally, a shared-secret AND an identifier of that shared-secret are passed from the server to the client. The identifier is placed in the Identification control, and the shared-secret is used to compute the Identity Proof control.
また、このドキュメントはIdentificationコントロール(セクション6.2.3)を提供します。 このコントロールはクライアントが、彼らがサーバへのだれであるかを述べるのを許容する簡単なメソッドです。一般に、共有秘密キーとその共有秘密キーに関する識別子はサーバからクライアントまで通過されます。 識別子はIdentificationコントロールに置かれます、そして、共有秘密キーは、Identity Proofコントロールを計算するのに使用されます。
6.2.1. Identity Proof Version 2 Control
6.2.1. アイデンティティ証拠バージョン2コントロール
The Identity Proof Version 2 control is identified by the OID:
Identity Proofバージョン2コントロールはOIDによって特定されます:
id-cmc-identityProofV2 ::= { id-cmc 34 }
イド-cmc-identityProofV2:、:= イド-cmc34
Schaad & Myers Standards Track [Page 33] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[33ページ]: 2008年6月を構造化します。
The Identity Proof Version 2 control has the ASN.1 definition:
Identity Proofバージョン2コントロールには、ASN.1定義があります:
IdentifyProofV2 ::= SEQUENCE {
hashAlgID AlgorithmIdentifier,
macAlgID AlgorithmIdentifier,
witness OCTET STRING
IdentifyProofV2:、:= SEQUENCE、hashAlgID AlgorithmIdentifier(macAlgID AlgorithmIdentifier)はOCTET STRINGを目撃します。
}
}
The fields of IdentityProofV2 have the following meaning:
IdentityProofV2の分野には、以下の意味があります:
hashAlgID is the identifier and parameters for the hash algorithm
used to convert the shared-secret into a key for the MAC
algorithm.
hashAlgIDは識別子です、そして、ハッシュアルゴリズムのためのパラメタはMACアルゴリズムのために以前はよく共有秘密キーをキーに変換していました。
macAlgID is the identifier and the parameters for the message
authentication code algorithm used to compute the value of the
witness field.
macAlgIDは識別子です、そして、メッセージ確認コードアルゴリズムのためのパラメタは以前はよく目撃者分野の値を計算していました。
witness is the identity proof.
目撃者はアイデンティティ証拠です。
The required method starts with an out-of-band transfer of a token (the shared-secret). The shared-secret should be generated in a random manner. The distribution of this token is beyond the scope of this document. The client then uses this token for an identity proof as follows:
必要なメソッドはトークン(共有秘密キー)のバンドで出かけている転送から始まります。 共有秘密キーは無作為の方法で生成されるべきです。 このトークンの分配はこのドキュメントの範囲を超えています。 次に、クライアントは以下のアイデンティティ証拠にこのトークンを使用します:
1. The PKIData reqSequence field (encoded exactly as it appears in
the Full PKI Request including the sequence type and length) is
the value to be validated.
1. PKIData reqSequence分野(ちょうど系列タイプと長さを含んでいて、Full PKI Requestに現れるように、コード化される)は有効にされるべき値です。
2. A hash of the shared-secret as a UTF8 string is computed using
hashAlgID.
2. UTF8ストリングとしての共有秘密キーのハッシュは、hashAlgIDを使用することで計算されます。
3. A MAC is then computed using the value produced in Step 1 as the
message and the value from Step 2 as the key.
3. そして、MACは、メッセージと値としてStep1でキーとしてのStep2から生産物価値を使用することで計算されます。
4. The result from Step 3 is then encoded as the witness value in
the Identity Proof Version 2 control.
4. そして、Step3からの結果はIdentity Proofバージョン2コントロールにおける目撃者値としてコード化されます。
When the server verifies the Identity Proof Version 2 control, it computes the MAC value in the same way and compares it to the witness value contained in the PKI Request.
サーバがIdentity Proofバージョン2コントロールについて確かめるとき、それは、同様に、MAC値を計算して、PKI Requestに含まれた目撃者値とそれを比較します。
If a server fails the verification of an Identity Proof Version 2 control, the CMCFailInfo value MUST be present in the Full PKI Response and MUST have a value of badIdentity.
サーバがIdentity Proofバージョン2コントロールの検証に失敗するなら、CMCFailInfo値は、Full PKI Responseに存在していなければならなくて、badIdentityの値を持たなければなりません。
Schaad & Myers Standards Track [Page 34] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[34ページ]: 2008年6月を構造化します。
Reuse of the shared-secret on certification request retries allows the client and server to maintain the same view of acceptable identity proof values. However, reuse of the shared-secret can potentially open the door for some types of attacks.
証明要求再試行の共有秘密キーの再利用で、クライアントとサーバは許容できるアイデンティティ証拠値の同じ視点を維持できます。 しかしながら、共有秘密キーの再利用は何人かのタイプの攻撃のために潜在的にドアを開けることができます。
Implementations MUST be able to support tokens at least 16 characters long. Guidance on the amount of entropy actually obtained from a given length token based on character sets can be found in Appendix A of [PASSWORD].
実装は、長い間、トークンが少なくとも16のキャラクタであるとサポートすることができなければなりません。 [PASSWORD]のAppendix Aで実際に文字集合に基づく与えられた長さのトークンから得られたエントロピーの量における指導を見つけることができます。
6.2.2. Identity Proof Control
6.2.2. アイデンティティ証拠コントロール
The Identity Proof control is identified by the OID:
Identity ProofコントロールはOIDによって特定されます:
id-cmc-identityProof ::= { id-cmc 3 }
イド-cmc-identityProof:、:= イド-cmc3
The Identity Proof control has the ASN.1 definition:
Identity Proofコントロールには、ASN.1定義があります:
IdentifyProof ::= OCTET STRING
IdentifyProof:、:= 八重奏ストリング
This control is processed in the same way as the Identity Proof Version 2 control. In this case, the hash algorithm is fixed to SHA-1 and the MAC algorithm is fixed to HMAC-SHA1.
Identity Proofバージョン2が制御されるとき、同様に、このコントロールは加工処理されます。 この場合、ハッシュアルゴリズムはSHA-1に固定されています、そして、MACアルゴリズムはHMAC-SHA1に固定されています。
6.2.3. Identification Control
6.2.3. 識別コントロール
Optionally, servers MAY require the inclusion of the unprotected Identification control with an Identification Proof control. The Identification control is intended to contain a text string that assists the server in locating the shared-secret needed to validate the contents of the Identity Proof control. If the Identification control is included in the Full PKI Request, the derivation of the key in Step 2 (from Section 6.2.1) is altered so that the hash of the concatenation of the shared-secret and the UTF8 identity value (without the type and length bytes) are hashed rather than just the shared-secret.
任意に、サーバはIdentification Proofコントロールによる保護のないIdentificationコントロールの包含を必要とするかもしれません。 IdentificationコントロールがIdentity Proofコントロールのコンテンツを有効にするのに必要である共有秘密キーの場所を見つけるのにサーバを助けるテキスト文字列を含むことを意図します。 IdentificationコントロールがFull PKI Requestに含まれているなら、Step2(セクション6.2.1からの)でのキーの派生が変更されるので、共有秘密キーの連結のハッシュとUTF8アイデンティティ価値(タイプと長さのバイトのない)はまさしく共有秘密キーよりむしろ論じ尽くされます。
The Identification control is identified by the OID:
IdentificationコントロールはOIDによって特定されます:
id-cmc-identification ::= { id-cmc 2 }
イドcmc識別:、:= イド-cmc2
The Identification control has the ASN.1 definition:
Identificationコントロールには、ASN.1定義があります:
Identification ::= UTF8String
識別:、:= UTF8String
Schaad & Myers Standards Track [Page 35] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[35ページ]: 2008年6月を構造化します。
6.2.4. Hardware Shared-Secret Token Generation
6.2.4. ハードウェア共有秘密キートークン世代
The shared-secret between the EE and the server is sometimes computed using a hardware device that generates a series of tokens. The EE can therefore prove its identity by transferring this token in plain text along with a name string. The above protocol can be used with a hardware shared-secret token generation device by the following modifications:
EEとサーバの間の共有秘密キーは、一連のトークンを生成するハードウェアデバイスを使用することで時々計算されます。 したがって、EEは、名前ストリングに伴うプレーンテキストのこのトークンを移すことによって、アイデンティティを立証できます。 ハードウェア共有秘密キートークン世代デバイスと共に以下の変更で上のプロトコルを使用できます:
1. The Identification control MUST be included and MUST contain the
hardware-generated token.
1. Identificationコントロールは、含まなければならなくて、ハードウェアで発生しているトークンを含まなければなりません。
2. The shared-secret value used above is the same hardware-generated
token.
2. 上で使用された共有秘密キー値は同じハードウェアで発生しているトークンです。
3. All certification requests MUST have a subject name, and the
subject name MUST contain the fields required to identify the
holder of the hardware token device.
3. すべての証明要求には、対象の名前がなければなりません、そして、対象の名前はハードウェアトークンデバイスの所有者を特定するのに必要である分野を含まなければなりません。
4. The entire certification request MUST be shrouded in some fashion
to prevent eavesdropping. Although the token is time critical,
an active eavesdropper cannot be permitted to extract the token
and submit a different certification request with the same token
value.
4. 盗み聞くのを防ぐために何らかのファッションで全体の証明要求を覆い隠さなければなりません。 トークンは時間重要ですが、同じトークン値でトークンを抽出して、活発な立ち聞きする者が異なった証明要求を提出することを許可できません。
6.3. Linking Identity and POP Information
6.3. アイデンティティと大衆的な情報をリンクします。
In a Full PKI Request, identity information about the client is carried in the signature of the SignedData containing all of the certification requests. Proof-of-possession information for key pairs, however, is carried separately for each PKCS #10 or CRMF certification request. (For keys capable of generating a digital signature, the POP is provided by the signature on the PKCS #10 or CRMF request. For encryption-only keys, the controls described in Section 6.7 are used.) In order to prevent substitution-style attacks, the protocol must guarantee that the same entity generated both the POP and proof-of-identity information.
Full PKI Requestでは、クライアントのアイデンティティ情報は証明要求のすべてを含むSignedDataの署名で運ばれます。 しかしながら、主要な組所有物の証拠情報はそれぞれのPKCS#10かCRMF証明要求のために別々に運ばれます。 (デジタル署名を生成することができるキーにおいて、10かCRMFが要求するPKCS#における署名でPOPを提供します。 暗号化だけキーに関しては、セクション6.7で説明されたコントロールは使用されています。) 代替スタイル攻撃を防ぐために、プロトコルは、同じ実体が、両方がPOPと身元の証拠情報であると生成したのを保証しなければなりません。
This section describes two mechanisms for linking identity and POP information: witness values cryptographically derived from the shared-secret (Section 6.3.1.3) and shared-secret/subject distinguished name (DN) matching (Section 6.3.2). Clients and servers MUST support the witness value technique. Clients and servers MAY support shared-secret/subject DN matching or other bilateral techniques of similar strength. The idea behind both mechanisms is to force the client to sign some data into each certification request that can be directly associated with the
このセクションはアイデンティティとPOP情報をリンクするために2つのメカニズムについて説明します: 共有秘密キーから暗号で得られた値を目撃してください、(セクション6.3 .1 .3) そして、(セクション6.3.2)に合っている共有秘密キー/対象分類名(DN)。 クライアントとサーバは、目撃者値がテクニックであるとサポートしなければなりません。 クライアントとサーバは、共有秘密キー/対象が同様の強さのDNの合わせているか他の双方のテクニックであるとサポートするかもしれません。 両方のメカニズムの後ろの考えはクライアントをそれが直接関連している場合があるそれぞれの証明要求にいくつかのデータを署名させることです。
Schaad & Myers Standards Track [Page 36] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[36ページ]: 2008年6月を構造化します。
shared-secret; this will defeat attempts to include certification requests from different entities in a single Full PKI Request.
共有秘密キー。 これは独身のFull PKI Requestで異なった実体からの証明要求を含む試みを破るでしょう。
6.3.1. Cryptographic Linkage
6.3.1. 暗号のリンケージ
The first technique that links identity and POP information forces the client to include a piece of information cryptographically derived from the shared-secret as a signed extension within each certification request (PKCS #10 or CRMF).
アイデンティティとPOP情報をリンクする最初のテクニックによって、クライアントはやむを得ず署名している拡大としてそれぞれの証明要求(PKCS#の10かCRMF)の中で共有秘密キーから暗号で得られた1つの情報を入れます。
6.3.1.1. POP Link Witness Version 2 Controls
6.3.1.1. リンク目撃者バージョン2コントロールを飛び出させてください。
The POP Link Witness Version 2 control is identified by the OID:
POP Link Witnessバージョン2コントロールはOIDによって特定されます:
id-cmc-popLinkWitnessV2 ::= { id-cmc 33 }
イド-cmc-popLinkWitnessV2:、:= イド-cmc33
The POP Link Witness Version 2 control has the ASN.1 definition:
POP Link Witnessバージョン2コントロールには、ASN.1定義があります:
PopLinkWitnessV2 ::= SEQUENCE {
keyGenAlgorithm AlgorithmIdentifier,
macAlgorithm AlgorithmIdentifier,
witness OCTET STRING
}
PopLinkWitnessV2:、:= 系列keyGenAlgorithm AlgorithmIdentifier(macAlgorithm AlgorithmIdentifier)はOCTET STRINGを目撃します。
The fields of PopLinkWitnessV2 have the following meanings:
PopLinkWitnessV2の分野には、以下の意味があります:
keyGenAlgorithm contains the algorithm used to generate the key for
the MAC algorithm. This will generally be a hash algorithm, but
could be a more complex algorithm.
keyGenAlgorithmはMACアルゴリズムのためにキーを生成するのに使用されるアルゴリズムを含んでいます。 これは、一般にハッシュアルゴリズムですが、より複雑なアルゴリズムであるかもしれません。
macAlgorithm contains the algorithm used to create the witness
value.
macAlgorithmは目撃者値を作成するのに使用されるアルゴリズムを含んでいます。
witness contains the computed witness value.
目撃者は計算された目撃者値を含みます。
This technique is useful if null subject DNs are used (because, for example, the server can generate the subject DN for the certificate based only on the shared-secret). Processing begins when the client receives the shared-secret out-of-band from the server. The client then computes the following values:
ヌル対象のDNsが使用されているなら(例えば、サーバが証明書のためのDNが共有秘密キーだけに基礎づけた対象を生成することができるので)、このテクニックは役に立ちます。 クライアントがバンドの外にサーバから共有秘密キーを受け取るとき、処理は始まります。次に、クライアントは以下の値を計算します:
1. The client generates a random byte-string, R, which SHOULD be at
least 512 bits in length.
1. クライアントは、中の少なくとも512ビットが長さであったなら無作為のバイトストリング、RがどのSHOULDであるかと生成します。
2. The key is computed from the shared-secret using the algorithm in
keyGenAlgorithm.
2. キーは、共有秘密キーからkeyGenAlgorithmのアルゴリズムを使用することで計算されます。
Schaad & Myers Standards Track [Page 37] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[37ページ]: 2008年6月を構造化します。
3. A MAC is then computed over the random value produced in Step 1,
using the key computed in Step 2.
3. そして、Step2で計算されたキーを使用して、MACはStep1の無作為の生産物価値に関して計算されます。
4. The random value produced in Step 1 is encoded as the value of a
POP Link Random control. This control MUST be included in the
Full PKI Request.
4. Step1の無作為の生産物価値はPOP Link Randomコントロールの価値としてコード化されます。 Full PKI Requestにこのコントロールを含まなければなりません。
5. The MAC value produced in Step 3 is placed in either the POP Link
Witness control or the witness field of the POP Link Witness V2
control.
5. Step3のMAC生産物価値はPOP Link Witness V2コントロールのPOP Link Witnessコントロールか目撃者分野のどちらかに置かれます。
* For CRMF, the POP Link Witness/POP Link Witness V2 control is
included in the controls field of the CertRequest structure.
* CRMFに関しては、POP Link Witness/POP Link Witness V2コントロールはCertRequest構造のコントロール分野に含まれています。
* For PKCS #10, the POP Link Witness/POP Link Witness V2 control
is included in the attributes field of the
CertificationRequestInfo structure.
* PKCS#10において、POP Link Witness/POP Link Witness V2コントロールはCertificationRequestInfo構造の属性分野に含まれています。
Upon receipt, servers MUST verify that each certification request contains a copy of the POP Link Witness/POP Link Witness V2 control and that its value was derived using the above method from the shared-secret and the random string included in the POP Link Random control.
領収書では、サーバはそれぞれの証明要求がPOP Link Witness/POP Link Witness V2コントロールのコピーを含んでいて、共有秘密キーから上のメソッドを使用して、POP Link Randomコントロールに無作為のストリングを含んでいて、値が引き出されたことを確かめなければなりません。
The Identification control (see Section 6.2.3) or the subject DN of a certification request can be used to help identify which shared- secret was used.
どの共有された秘密が使用されたかを特定するのを助けるのにIdentificationコントロール(セクション6.2.3を見る)か証明要求の対象のDNを使用できます。
6.3.1.2. POP Link Witness Control
6.3.1.2. リンク目撃者コントロールを飛び出させてください。
The POP Link Witness control is identified by the OID:
POP Link WitnessコントロールはOIDによって特定されます:
id-cmc-popLinkWitness ::= { id-cmc 23 }
イド-cmc-popLinkWitness:、:= イド-cmc23
The POP Link Witness control has the ASN.1 definition:
POP Link Witnessコントロールには、ASN.1定義があります:
PopLinkWitness ::= OCTET STRING
PopLinkWitness:、:= 八重奏ストリング
For this control, SHA-1 is used as the key generation algorithm. HMAC-SHA1 is used as the mac algorithm.
このコントロールのために、SHA-1はキー生成アルゴリズムとして使用されます。 HMAC-SHA1はmacアルゴリズムとして使用されます。
6.3.1.3. POP Link Random Control
6.3.1.3. リンクの無作為のコントロールを飛び出させてください。
The POP Link Random control is identified by the OID:
POP Link RandomコントロールはOIDによって特定されます:
id-cmc-popLinkRandom ::= { id-cmc 22 }
イド-cmc-popLinkRandom:、:= イド-cmc22
Schaad & Myers Standards Track [Page 38] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[38ページ]: 2008年6月を構造化します。
The POP Link Random control has the ASN.1 definition:
POP Link Randomコントロールには、ASN.1定義があります:
PopLinkRandom ::= OCTET STRING
PopLinkRandom:、:= 八重奏ストリング
6.3.2. Shared-Secret/Subject DN Linking
6.3.2. 共有秘密キー/対象DNリンク
The second technique to link identity and POP information is to link a particular subject distinguished name (subject DN) to the shared- secrets that are distributed out-of-band and to require that clients using the shared-secret to prove identity include that exact subject DN in every certification request. It is expected that many client- server connections that use shared-secret-based proof-of-identity will use this mechanism. (It is common not to omit the subject DN information from the certification request.)
アイデンティティとPOP情報をリンクする2番目のテクニックは、特定の対象の分類名(対象のDN)をバンドの外で分配される共有された秘密にリンクして、アイデンティティを立証するのに共有秘密キーを使用しているクライアントがあらゆる証明要求でその正確な対象DNを入れるのが必要であることです。 身元の共有された秘密ベースの証拠を使用する多くのクライアントサーバ接続がこのメカニズムを使用すると予想されます。 (証明要求から対象のDN情報を省略しないのは一般的です。)
When the shared-secret is generated and transferred out-of-band to initiate the registration process (Section 6.2), a particular subject DN is also associated with the shared-secret and communicated to the client. (The subject DN generated MUST be unique per entity in accordance with the CA policy; a null subject DN cannot be used. A common practice could be to place the identification value as part of the subject DN.) When the client generates the Full PKI Request, it MUST use these two pieces of information as follows:
登録手続(セクション6.2)に着手するためにバンドの外に共有秘密キーを生成して、移すとき、特定の対象のDNをまた、共有秘密キーに関連づけて、クライアントに伝えます。 (カリフォルニア方針によると、DNが生成した対象は実体単位でユニークであるに違いありません。 ヌル対象のDNを使用できません。 一般的な習慣は対象のDNの一部として識別値を置くことになっているかもしれません。) クライアントがFull PKI Requestを生成すると、以下の2つの情報を使用しなければなりません:
1. The client MUST include the specific subject DN that it received
along with the shared-secret as the subject name in every
certification request (PKCS #10 and/or CRMF) in the Full PKI
Request. The subject names in the certification requests MUST
NOT be null.
1. クライアントはFull PKI Requestでのあらゆる証明要求(PKCS#の10、そして/または、CRMF)でそれが共有されて対象として秘密の名前と共に受けた特定の対象のDNを入れなければなりません。 証明要求における対象の名前はヌルであるはずがありません。
2. The client MUST include an Identity Proof control (Section 6.2.2)
or Identity Proof Version 2 control (Section 6.2.1), derived from
the shared-secret, in the Full PKI Request.
2. クライアントはFull PKI Requestで共有秘密キーから得られたIdentity Proofコントロール(セクション6.2.2)かIdentity Proofバージョン2コントロール(セクション6.2.1)を入れなければなりません。
The server receiving this message MUST (a) validate the Identity Proof control and then, (b) check that the subject DN included in each certification request matches that associated with the shared- secret. If either of these checks fails, the certification request MUST be rejected.
このメッセージを受け取るサーバはチェックしなければなりません。(a) Identity Proofコントロールを有効にしてください、そして、次に、(b) 各証明にDNを含んでいる対象が共有された秘密と交際したマッチを要求するのをチェックしてください。 これらのチェックのどちらかが失敗するなら、証明要求を拒絶しなければなりません。
6.3.3. Renewal and Rekey Messages
6.3.3. 更新とRekeyメッセージ
When doing a renewal or rekey certification request, linking identity and POP information is simple. The client copies the subject DN for a current signing certificate into the subject name field of each certification request that is made. The POP for each certification request will now cover that information. The outermost signature layer is created using the current signing certificate, which allows
更新かrekey証明要求をするとき、アイデンティティとPOP情報をリンクするのは簡単です。 クライアントは現在の署名証明書のためにされるそれぞれの証明要求の対象の名前欄に対象のDNをコピーします。 それぞれの証明要求のためのPOPは現在、その情報をカバーするでしょう。 一番はずれの署名層が現在の署名証明書を使用することで作成される、どれ、許容
Schaad & Myers Standards Track [Page 39] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[39ページ]: 2008年6月を構造化します。
the original identity to be associated with the certification request. Since the name in the current signing certificate and the names in the certification requests match, the necessary linking has been achieved.
証明要求に関連しているオリジナルのアイデンティティ。 現在の署名証明書の名前と証明要求における名前が合っているので、必要なリンクは達成されました。
6.4. Data Return Control
6.4. データリターンコントロール
The Data Return control allows clients to send arbitrary data (usually some type of internal state information) to the server and to have the data returned as part of the Full PKI Response. Data placed in a Data Return control is considered to be opaque to the server. The same control is used for both Full PKI Requests and Responses. If the Data Return control appears in a Full PKI Request, the server MUST return it as part of the PKI Response.
Data Returnコントロールで、クライアントに任意のデータ(通常タイプの内部の州の情報)をサーバに送って、Full PKI Responseの一部としてデータを返させます。 Data Returnコントロールに置かれたデータがサーバに不伝導性であると考えられます。同じコントロールはFull PKI RequestsとResponsesの両方に使用されます。 Data ReturnコントロールがFull PKI Requestに現れるなら、サーバはPKI Responseの一部としてそれを返さなければなりません。
In the event that the information in the Data Return control needs to be confidential, it is expected that the client would apply some type of encryption to the contained data, but the details of this are outside the scope of this specification.
Data Returnコントロールにおける情報が、秘密である必要がある場合、クライアントがタイプの暗号化を含まれたデータに適用すると予想されますが、この仕様の範囲の外にこの詳細があります。
The Data Return control is identified by the OID:
Data ReturnコントロールはOIDによって特定されます:
id-cmc-dataReturn ::= { id-cmc 4 }
イド-cmc-dataReturn:、:= イド-cmc4
The Data Return control has the ASN.1 definition:
Data Returnコントロールには、ASN.1定義があります:
DataReturn ::= OCTET STRING
DataReturn:、:= 八重奏ストリング
A client could use this control to place an identifier marking the exact source of the private key material. This might be the identifier of a hardware device containing the private key.
クライアントは、秘密鍵の材料の正確な源を示しながら識別子を置くのにこのコントロールを使用できました。 これは秘密鍵を含むハードウェアデバイスに関する識別子であるかもしれません。
6.5. RA Certificate Modification Controls
6.5. RA証明書変更コントロール
These controls exist for RAs to be able to modify the contents of a certification request. Modifications might be necessary for various reasons. These include addition of certificate extensions or modification of subject and/or subject alternative names.
RAsが証明要求のコンテンツを変更できるように、これらのコントロールは存在しています。 変更が様々な理由に必要であるかもしれません。 これらは証明書拡張子の追加か受けることがあるそして/または、対象の代替名の変更を含んでいます。
Two controls exist for this purpose. The first control, Modify Certification Request (Section 6.5.1), allows the RA to replace or remove any field in the certificate. The second control, Add Extensions (Section 6.5.2), only allows for the addition of extensions.
2つのコントロールがこのために存在しています。 最初のコントロール(Modify Certification Request(セクション6.5.1))で、RAは証明書のどんな野原も取り替えるか、または取り除きます。 2番目のコントロール(Add Extensions(セクション6.5.2))は拡大の追加を考慮するだけです。
Schaad & Myers Standards Track [Page 40] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[40ページ]: 2008年6月を構造化します。
6.5.1. Modify Certification Request Control
6.5.1. 証明要求コントロールを変更してください。
The Modify Certification Request control is used by RAs to change fields in a requested certificate.
Modify Certification Requestコントロールは、要求された証明書で職業を替えるのにRAsによって使用されます。
The Modify Certification Request control is identified by the OID:
Modify Certification RequestコントロールはOIDによって特定されます:
id-cmc-modCertTemplate ::= { id-cmc 31 }
イド-cmc-modCertTemplate:、:= イド-cmc31
The Modify Certification Request has the ASN.1 definition:
Modify Certification Requestには、ASN.1定義があります:
ModCertTemplate ::= SEQUENCE {
pkiDataReference BodyPartPath,
certReferences BodyPartList,
replace BOOLEAN DEFAULT TRUE,
certTemplate CertTemplate
}
ModCertTemplate:、:= 系列pkiDataReference BodyPartPath(certReferences BodyPartList)はBOOLEAN DEFAULT TRUE、certTemplate CertTemplateを取り替えます。
The fields in ModCertTemplate have the following meaning:
ModCertTemplateの分野には、以下の意味があります:
pkiDataReference is the path to the PKI Request containing
certification request(s) to be modified.
pkiDataReferenceは変更されるという証明要求を含むPKI Requestへの経路です。
certReferences refers to one or more certification requests in the
PKI Request referenced by pkiDataReference to be modified. Each
BodyPartID of the certReferences sequence MUST be equal to either
the bodyPartID of a TaggedCertificationRequest (PKCS #10) or the
certReqId of the CertRequest within a CertReqMsg (CRMF). By
definition, the certificate extensions included in the
certTemplate field are applied to every certification request
referenced in the certReferences sequence. If a request
corresponding to bodyPartID cannot be found, the CMCFailInfo with
a value of badRequest is returned that references this control.
certReferencesは変更されるためにpkiDataReferenceによって参照をつけられたPKI Requestでの1つ以上の証明要求を示します。 certReferences系列のそれぞれのBodyPartIDはCertReqMsg(CRMF)の中でTaggedCertificationRequest(PKCS#10)のbodyPartIDかCertRequestのcertReqIdのどちらかと等しいに違いありません。 定義上、certTemplate分野に含まれていた証明書拡張子はcertReferences系列で参照をつけられるあらゆる証明要求に適用されます。 bodyPartIDに対応する要求を見つけることができないなら、これが制御するその参照をbadRequestの値があるCMCFailInfoに返します。
replace specifies if the target certification request is to be
modified by replacing or deleting fields. If the value is TRUE,
the data in this control replaces the data in the target
certification request. If the value is FALSE, the data in the
target certification request is deleted. The action is slightly
different for the extensions field of certTemplate; each extension
is treated individually rather than as a single unit.
目標証明要求が取り替えることによって変更されるかどうかことであると指定するか、または分野を削除しながら、取り替えます。 値がTRUEであるなら、このコントロールにおけるデータは目標証明要求におけるデータを置き換えます。 値がFALSEであるなら、目標証明要求におけるデータは削除されます。 certTemplateの拡大分野において、動作はわずかに異なっています。 各拡大は単一の単位より個別にむしろ扱われます。
certTemplate is a certificate template object [CRMF]. If a field is
present and replace is TRUE, it replaces that field in the
certification request. If the field is present and replace is
FALSE, the field in the certification request is removed. If the
field is absent, no action is performed. Each extension is
treated as a single field.
certTemplateは証明書テンプレートオブジェクト[CRMF]です。 分野が存在している、取り替え、TRUE、それは証明要求におけるその野原を取り替えます。 分野が存在している、取り替え、FALSEであり、取り除かれます証明における分野が、要求する。 分野が欠けるなら、動作は全く実行されません。 各拡大はただ一つの分野として扱われます。
Schaad & Myers Standards Track [Page 41] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[41ページ]: 2008年6月を構造化します。
Servers MUST be able to process all extensions defined, but not prohibited, in [PKIXCERT]. Servers are not required to be able to process every X.509v3 extension transmitted using this protocol, nor are they required to be able to process other, private extensions. Servers are not required to put all RA-requested extensions into a certificate. Servers are permitted to modify RA-requested extensions. Servers MUST NOT alter an extension so as to reverse the meaning of a client-requested extension. If a certification request is denied due to the inability to handle a requested extension and a Full PKI Response is returned, the server MUST return a CMCFailInfo value with the value of unsupportedExt.
サーバは定義されますが、[PKIXCERT]で禁止されなかったすべての拡大を処理できなければなりません。 サーバはこのプロトコルを使用することで伝えられたあらゆるX.509v3拡張子を処理できるように必要ではありません、そして、それらは他の、そして、個人的な拡大を処理する必要はないことができます。 サーバは、すべてのRAによって要求された拡大を証明書に入れるのに必要ではありません。 サーバがRAによって要求された拡大を変更することが許可されています。 サーバは、クライアントによって要求された拡大の意味を逆にするために拡大を変更してはいけません。 要求された拡大を扱うことができないことのため証明要求を否定して、Full PKI Responseを返すなら、サーバはunsupportedExtの値があるCMCFailInfo値を返さなければなりません。
If a certification request is the target of multiple Modify Certification Request controls, the behavior is:
証明要求が複数のModify Certification Requestコントロールの目標であるなら、振舞いは以下の通りです。
o If control A exists in a layer that contains the layer of control
B, control A MUST override control B. In other words, controls
should be applied from the innermost layer to the outermost layer.
o コントロールAがコントロールBの層を含む層の中に存在しているなら、コントロールAはコントロールB.In他の単語に優越しなければならなくて、コントロールは最内の層から最外の層に適用されるべきです。
o If control A and control B are in the same PKIData (i.e., the same
wrapping layer), the order of application is non-determinate.
o コントロールAとコントロールBが同じPKIData(すなわち、同じラッピング層)にあるなら、適用の順序は非確定的です。
The same order of application is used if a certification request is the target of both a Modify Certification Request control and an Add Extensions control.
同じ適用の順序は証明要求がModify Certification RequestコントロールとAdd Extensionsコントロールの両方の目標であるなら使用されています。
6.5.2. Add Extensions Control
6.5.2. 拡大コントロールを加えてください。
The Add Extensions control has been deprecated in favor of the Modify Certification Request control. It was replaced so that fields in the certification request other than extensions could be modified.
Add ExtensionsコントロールはModify Certification Requestコントロールを支持して推奨しないです。 拡大以外の証明要求における分野を変更できるようにそれを取り替えました。
The Add Extensions control is used by RAs to specify additional extensions that are to be included in certificates.
Add Extensionsコントロールは、証明書に含まれることになっている追加拡大を指定するのにRAsによって使用されます。
The Add Extensions control is identified by the OID:
Add ExtensionsコントロールはOIDによって特定されます:
id-cmc-addExtensions ::= { id-cmc 8 }
イド-cmc-addExtensions:、:= イド-cmc8
The Add Extensions control has the ASN.1 definition:
Add Extensionsコントロールには、ASN.1定義があります:
AddExtensions ::= SEQUENCE {
pkiDataReference BodyPartID,
certReferences SEQUENCE OF BodyPartID,
extensions SEQUENCE OF Extension
}
AddExtensions:、:= 系列pkiDataReference BodyPartID、certReferences SEQUENCE OF BodyPartID、拡大SEQUENCE OF Extension
Schaad & Myers Standards Track [Page 42] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[42ページ]: 2008年6月を構造化します。
The fields in AddExtensions have the following meaning:
AddExtensionsの分野には、以下の意味があります:
pkiDataReference contains the body part identity of the embedded
certification request.
pkiDataReferenceは埋め込まれた証明要求のボディー部分のアイデンティティを含んでいます。
certReferences is a list of references to one or more of the
certification requests contained within a PKIData. Each body part
identifier of the certReferences sequence MUST be equal to either
the bodyPartID of a TaggedCertificationRequest (PKCS #10) or the
certReqId of the CertRequest within a CertReqMsg (CRMF). By
definition, the listed extensions are to be applied to every
certification request referenced in the certReferences sequence.
If a certification request corresponding to bodyPartID cannot be
found, the CMCFailInfo with a value of badRequest is returned
referencing this control.
certReferencesはPKIDataの中に含まれた証明要求の1つ以上への参考文献一覧です。 certReferences系列のそれぞれのボディー部分識別子はCertReqMsg(CRMF)の中でTaggedCertificationRequest(PKCS#10)のbodyPartIDかCertRequestのcertReqIdのどちらかと等しいに違いありません。 定義上、記載された拡大はcertReferences系列で参照をつけられるあらゆる証明要求に適用されることです。 bodyPartIDに対応する証明要求を見つけることができないなら、このコントロールに参照をつけながら、badRequestの値があるCMCFailInfoを返します。
extensions is a sequence of extensions to be applied to the
referenced certification requests.
拡大は参照をつけられた証明要求に適用されるべき拡大の系列です。
Servers MUST be able to process all extensions defined, but not prohibited, in [PKIXCERT]. Servers are not required to be able to process every X.509v3 extension transmitted using this protocol, nor are they required to be able to process other, private extensions. Servers are not required to put all RA-requested extensions into a certificate. Servers are permitted to modify RA-requested extensions. Servers MUST NOT alter an extension so as to reverse the meaning of a client-requested extension. If a certification request is denied due to the inability to handle a requested extension and a response is returned, the server MUST return a CMCFailInfo with the value of unsupportedExt.
サーバは定義されますが、[PKIXCERT]で禁止されなかったすべての拡大を処理できなければなりません。 サーバはこのプロトコルを使用することで伝えられたあらゆるX.509v3拡張子を処理できるように必要ではありません、そして、それらは他の、そして、個人的な拡大を処理する必要はないことができます。 サーバは、すべてのRAによって要求された拡大を証明書に入れるのに必要ではありません。 サーバがRAによって要求された拡大を変更することが許可されています。 サーバは、クライアントによって要求された拡大の意味を逆にするために拡大を変更してはいけません。 要求された拡大を扱うことができないことのため証明要求を否定して、応答を返すなら、サーバはunsupportedExtの値があるCMCFailInfoを返さなければなりません。
If multiple Add Extensions controls exist in a Full PKI Request, the exact behavior is left up to the CA policy. However, it is recommended that the following policy be used. These rules would be applied to individual extensions within an Add Extensions control (as opposed to an "all or nothing" approach).
複数のAdd ExtensionsコントロールがFull PKI Requestに存在しているなら、正確な振舞いはカリフォルニア方針に任せられます。 しかしながら、以下の方針が使用されるのは、お勧めです。 これらの規則はAdd Extensionsコントロール(「すべてか何でもない」アプローチと対照的に)の中の個々の拡大に適用されるでしょう。
1. If the conflict is within a single PKIData, the certification
request would be rejected with a CMCFailInfo value of badRequest.
1. 独身のPKIDataの中に闘争があるなら、証明要求はbadRequestのCMCFailInfo値で拒絶されるでしょう。
2. If the conflict is between different PKIData, the outermost
version of the extension would be used (allowing an RA to
override the requested extension).
2. 異なったPKIDataの間には、闘争があるなら、拡大の一番はずれのバージョンは使用されるでしょう(RAが要求された拡大をくつがえすのを許容して)。
Schaad & Myers Standards Track [Page 43] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[43ページ]: 2008年6月を構造化します。
6.6. Transaction Identifier Control and Sender and Recipient Nonce
Controls
6.6. トランザクション識別子コントロール、送付者、および受取人一回だけコントロール
Transactions are identified and tracked with a transaction identifier. If used, clients generate transaction identifiers and retain their value until the server responds with a Full PKI Response that completes the transaction. Servers correspondingly include received transaction identifiers in the Full PKI Response.
トランザクションは、トランザクション識別子で特定されて、追跡されます。 使用されるなら、サーバが取引を完了するFull PKI Responseと共に反応するまで、クライアントは、トランザクション識別子を生成して、それらの値を保有します。 サーバはFull PKI Responseの受信されたトランザクション識別子を対応する含んでいます。
The Transaction Identifier control is identified by the OID:
Transaction IdentifierコントロールはOIDによって特定されます:
id-cmc-transactionId ::= { id-cmc 5 }
イド-cmc-transactionId:、:= イド-cmc5
The Transaction Identifier control has the ASN.1 definition:
Transaction Identifierコントロールには、ASN.1定義があります:
TransactionId ::= INTEGER
TransactionId:、:= 整数
The Transaction Identifier control identifies a given transaction. It is used by client and server to manage the state of an operation. Clients MAY include a Transaction Identifier control in a request. If the original request contains a Transaction Identifier control, all subsequent requests and responses MUST include the same Transaction Identifier control.
Transaction Identifierコントロールは与えられたトランザクションを特定します。 それはクライアントとサーバによって使用されて、操作の状態を経営します。 クライアントは要求におけるTransaction Identifierコントロールを入れるかもしれません。 オリジナルの要求がTransaction Identifierコントロールを含んでいるなら、すべてのその後の要求と応答は同じTransaction Identifierコントロールを含まなければなりません。
Replay protection is supported through the use of the Sender and Recipient Nonce controls. If nonces are used, in the first message of a transaction, a Recipient Nonce control is not transmitted; a Sender Nonce control is included by the transaction originator and retained for later reference. The recipient of a Sender Nonce control reflects this value back to the originator as a Recipient Nonce control and includes its own Sender Nonce control. Upon receipt by the transaction originator of this response, the transaction originator compares the value of Recipient Nonce control to its retained value. If the values match, the message can be accepted for further security processing. The received value for a Sender Nonce control is also retained for inclusion in the next message associated with the same transaction.
反復操作による保護はSenderとRecipient Nonceコントロールの使用でサポートされます。 一回だけがトランザクションの最初のメッセージで使用されるなら、Recipient Nonceコントロールは送られません。 Sender Nonceコントロールは、トランザクション創始者によって入れられていて、後の参照のために保有されます。 Sender Nonceコントロールの受取人は、Recipient Nonceコントロールとしてこの値を創始者に映し出して、それ自身のSender Nonceコントロールを入れます。 この応答のトランザクション創始者による領収書では、トランザクション創始者はRecipient Nonceコントロールの価値を保有された値と比較します。 値が合っているなら、さらなるセキュリティ処理のためにメッセージを受け入れることができます。 また、Sender Nonceコントロールのための容認された値は同じトランザクションに関連している次のメッセージでの包含のために保有されます。
The Sender Nonce and Recipient Nonce controls are identified by the OIDs:
Sender NonceとRecipient NonceコントロールはOIDsによって特定されます:
id-cmc-senderNonce ::= { id-cmc 6 }
id-cmc-recipientNonce ::= { id-cmc 7 }
イド-cmc-senderNonce:、:= イド-cmc6、イド-cmc-recipientNonce:、:= イド-cmc7
The Sender Nonce control has the ASN.1 definition:
Sender Nonceコントロールには、ASN.1定義があります:
SenderNonce ::= OCTET STRING
SenderNonce:、:= 八重奏ストリング
Schaad & Myers Standards Track [Page 44] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[44ページ]: 2008年6月を構造化します。
The Recipient Nonce control has the ASN.1 definition:
Recipient Nonceコントロールには、ASN.1定義があります:
RecipientNonce ::= OCTET STRING
RecipientNonce:、:= 八重奏ストリング
Clients MAY include a Sender Nonce control in the initial PKI Request. If a message includes a Sender Nonce control, the response MUST include the transmitted value of the previously received Sender Nonce control as a Recipient Nonce control and include a new value as its Sender Nonce control.
クライアントは初期のPKI RequestでSender Nonceコントロールを入れるかもしれません。 メッセージがSender Nonceコントロールを含んでいるなら、Sender Nonceが制御するとき、応答は、Recipient Nonceコントロールとして以前に容認されたSender Nonceコントロールの伝えられた価値を含んでいて、新しい値を含まなければなりません。
6.7. Encrypted and Decrypted POP Controls
6.7. 大衆的なコントロールであると暗号化されて、解読されます。
Servers MAY require that this POP method be used only if another POP method is unavailable. Servers SHOULD reject all certification requests contained within a PKIData if any required POP is missing for any element within the PKIData.
サーバは、別のPOPメソッドが入手できない場合にだけこのPOPメソッドが使用されるのを必要とするかもしれません。 サーバSHOULDはPKIDataの中のどんな要素においても、どれか必要なPOPがなくなるならPKIDataの中に含まれたすべての証明要求を拒絶します。
Many servers require proof that the entity that generated the certification request actually possesses the corresponding private component of the key pair. For keys that can be used as signature keys, signing the certification request with the private key serves as a POP on that key pair. With keys that can only be used for encryption operations, POP MUST be performed by forcing the client to decrypt a value. See Section 5 of [CRMF] for a detailed discussion of POP.
多くのサーバが証明要求を生成した実体が実際に主要な組の対応する個人的なコンポーネントを持っているという証拠を必要とします。 署名キーとして使用できるキーに関しては、証明要求と秘密鍵を契約するのはその主要な組のPOPとして機能します。 暗号化操作に使用できるだけであるキーで、クライアントに値を解読させることによって、POPを実行しなければなりません。 POPの詳細な論議に関して[CRMF]のセクション5を見てください。
By necessity, POP for encryption-only keys cannot be done in one round-trip, since there are four distinct steps:
4つの明確に区分された段階があるので、必要に迫られて、1で往復であることで暗号化だけキーのためのPOPができません:
1. Client tells the server about the public component of a new
encryption key pair.
1. クライアントは新しい暗号化主要な組の公共のコンポーネントに関するサーバを言います。
2. Server sends the client a POP challenge, encrypted with the
presented public encryption key.
2. サーバは提示された公共の暗号化キーで暗号化されたPOP挑戦をクライアントに送ります。
3. Client decrypts the POP challenge using the private key that
corresponds to the presented public key and sends the plaintext
back to the server.
3. クライアントは、提示された公開鍵に対応する秘密鍵を使用することでPOPに挑戦を解読して、平文をサーバに送り返します。
4. Server validates the decrypted POP challenge and continues
processing the certification request.
4. サーバは、解読されたPOP挑戦を有効にして、証明要求を処理し続けています。
CMC defines two different controls. The first deals with the encrypted challenge sent from the server to the user in Step 2. The second deals with the decrypted challenge sent from the client to the server in Step 3.
CMCは2つの異なったコントロールを定義します。 暗号化された挑戦との最初の取引はStep2でサーバからユーザまで発信しました。 秒はStep3でクライアントからサーバに送られた解読された挑戦に対処します。
Schaad & Myers Standards Track [Page 45] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[45ページ]: 2008年6月を構造化します。
The Encrypted POP control is used to send the encrypted challenge from the server to the client as part of the PKIResponse. (Note that it is assumed that the message sent in Step 1 above is a Full PKI Request and that the response in Step 2 is a Full PKI Response including a CMCFailInfo specifying that a POP is explicitly required, and providing the POP challenge in the encryptedPOP control.)
Encrypted POPコントロールは、PKIResponseの一部として暗号化された挑戦をサーバからクライアントに送るのに使用されます。 (Step1で上に送られたメッセージがFull PKI Requestであり、Step2の応答がPOPが明らかに必要であると指定するCMCFailInfoを含んで、encryptedPOPコントロールにおけるPOP挑戦を提供するFull PKI Responseであると思われることに注意してください。)
The Encrypted POP control is identified by the OID:
Encrypted POPコントロールはOIDによって特定されます:
id-cmc-encryptedPOP ::= { id-cmc 9 }
イド-cmc-encryptedPOP:、:= イド-cmc9
The Encrypted POP control has the ASN.1 definition:
Encrypted POPコントロールには、ASN.1定義があります:
EncryptedPOP ::= SEQUENCE {
request TaggedRequest,
cms ContentInfo,
thePOPAlgID AlgorithmIdentifier,
witnessAlgID AlgorithmIdentifier,
witness OCTET STRING
}
EncryptedPOP:、:= 系列TaggedRequest(cm ContentInfo、thePOPAlgID AlgorithmIdentifier、witnessAlgID AlgorithmIdentifier)がOCTET STRINGを目撃するよう要求してください。
The Decrypted POP control is identified by the OID:
Decrypted POPコントロールはOIDによって特定されます:
id-cmc-decryptedPOP ::= { id-cmc 10 }
イド-cmc-decryptedPOP:、:= イド-cmc10
The Decrypted POP control has the ASN.1 definition:
Decrypted POPコントロールには、ASN.1定義があります:
DecryptedPOP ::= SEQUENCE {
bodyPartID BodyPartID,
thePOPAlgID AlgorithmIdentifier,
thePOP OCTET STRING
}
DecryptedPOP:、:= 系列bodyPartID BodyPartID、thePOPAlgID AlgorithmIdentifier、thePOP八重奏ストリング
The encrypted POP algorithm works as follows:
暗号化されたPOPアルゴリズムは以下の通り利きます:
1. The server randomly generates the POP Proof Value and associates
it with the request.
1. サーバは、手当たりしだいにPOP Proof Valueを生成して、それを要求に関連づけます。
2. The server returns the Encrypted POP control with the following
fields set:
2. サーバは以下の分野があるコントロールが設定したEncrypted POPを返します:
request is the original certification request (it is included
here so the client need not keep a copy of the request).
要求はオリジナルの証明要求(それがここで入れられているので、クライアントは要求の写しを取っておく必要はありません、)です。
cms is an EnvelopedData, the encapsulated content type being id-
data and the content being the POP Proof Value; this value
needs to be long enough that one cannot reverse the value from
the witness hash. If the certification request contains a
cmによるEnvelopedDataと、イドデータであるカプセル化されたcontent typeとPOP Proof Valueである内容です。 この値は、1つが目撃者ハッシュから値を逆にすることができないくらい長い必要があります。 証明要求がaを含んでいるなら
Schaad & Myers Standards Track [Page 46] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[46ページ]: 2008年6月を構造化します。
Subject Key Identifier (SKI) extension, then the recipient
identifier SHOULD be the SKI. If the issuerAndSerialNumber
form is used, the IssuerName MUST be encoded as NULL and the
SerialNumber as the bodyPartID of the certification request.
Key Identifier(SKI)拡張子、次に、受取人識別子SHOULDをかけてください。SKIになってください。 issuerAndSerialNumberフォームが使用されているなら、証明要求のbodyPartIDとしてのNULLとSerialNumberとしてIssuerNameをコード化しなければなりません。
thePOPAlgID identifies the algorithm to be used in computing the
return POP value.
thePOPAlgIDは、リターンPOP価値を計算する際に使用されるためにアルゴリズムを特定します。
witnessAlgID identifies the hash algorithm used on the POP Proof
Value to create the field witness.
witnessAlgIDは分野目撃者を創造するのにPOP Proof Valueで使用されるハッシュアルゴリズムを特定します。
witness is the hashed value of the POP Proof Value.
目撃者はPOP Proof Valueの論じ尽くされた値です。
3. The client decrypts the cms field to obtain the POP Proof Value.
The client computes H(POP Proof Value) using the witnessAlgID and
compares to the value of witness. If the values do not compare
or the decryption is not successful, the client MUST abort the
enrollment process. The client aborts the process by sending a
request containing a CMC Status Info control with CMCFailInfo
value of popFailed.
3. クライアントは、cmがPOP Proof Valueを入手する分野であると解読します。 クライアントは、witnessAlgIDを使用することでH(POP Proof Value)を計算して、目撃者の値と比較します。 値が比較されないか、または復号化がうまくいかないなら、クライアントは登録プロセスを中止しなければなりません。 クライアントは、popFailedのCMCFailInfo値でCMC Status Infoコントロールを含む要求を送ることによって、プロセスを中止します。
4. The client creates the Decrypted POP control as part of a new
PKIData. The fields in the DecryptedPOP are:
4. クライアントは新しいPKIDataの一部としてDecrypted POPコントロールを作成します。 DecryptedPOPの分野は以下の通りです。
bodyPartID refers to the certification request in the new PKI
Request.
bodyPartIDは新しいPKI Requestでの証明要求を示します。
thePOPAlgID is copied from the encryptedPOP.
thePOPAlgIDはencryptedPOPからコピーされます。
thePOP contains the possession proof. This value is computed by
thePOPAlgID using the POP Proof Value and the request.
thePOPは所有物証拠を含んでいます。 この値は、POP Proof Valueと要求を使用することでthePOPAlgIDによって計算されます。
5. The server then re-computes the value of thePOP from its cached
value and the request and compares to the value of thePOP. If
the values do not match, the server MUST NOT issue the
certificate. The server MAY re-issue a new challenge or MAY fail
the request altogether.
5. サーバは、次に、キャッシュされた値と要求からthePOPの値を再計算して、thePOPの値と比較されます。 値が合っていないなら、サーバは証明書を発行してはいけません。 サーバは、新しい挑戦を再発行するか、または全体で要求に失敗するかもしれません。
When defining the algorithms for thePOPAlgID and witnessAlgID, care must be taken to ensure that the result of witnessAlgID is not a useful value to shortcut the computation with thePOPAlgID. The POP Proof Value is used as the secret value in the HMAC algorithm and the request is used as the data. If the POP Proof Value is greater than 64 bytes, only the first 64 bytes of the POP Proof Value is used as the secret.
thePOPAlgIDとwitnessAlgID、注意がそうであるに違いないのでアルゴリズムを定義するときには、witnessAlgIDの結果がa役に立たないのを保証するために取って、thePOPAlgIDとの計算を近道に評価してください。 HMACアルゴリズムと要求における秘密の値がデータとして使用されるとき、POP Proof Valueは使用されています。 POP Proof Valueが64バイト以上であるなら、POP Proof Valueの最初の64バイトだけが秘密として使用されます。
Schaad & Myers Standards Track [Page 47] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[47ページ]: 2008年6月を構造化します。
One potential problem with the algorithm above is the amount of state that a CA needs to keep in order to verify the returned POP value. The following describes one of many possible ways of addressing the problem by reducing the amount of state kept on the CA to a single (or small set) of values.
上であることのアルゴリズムの1つの潜在的な問題がカリフォルニアが返されたPOP値について確かめるために維持する必要がある状態の量です。 以下はカリフォルニアに値のシングル(または、小さいセット)まで維持された状態の量を減少させることによって問題と取り組む多くの可能な方法の1つについて説明します。
1. Server generates random seed x, constant across all requests.
(The value of x would normally be altered on a regular basis and
kept for a short time afterwards.)
1. サーバはすべての要求の向こう側に一定の無作為の種子xを生成します。 (通常、xの値は、定期的に変更されて、その後、短い間保たれるでしょう。)
2. For certification request R, server computes y = F(x,R). F can
be, for example, HMAC-SHA1(x,R). All that's important for
statelessness is that y be consistently computable with only
known state constant x and function F, other inputs coming from
the certification request structure. y should not be predictable
based on knowledge of R, thus the use of a one-way function like
HMAC-SHA1.
2. 証明要求Rのために、サーバはy=F(x、R)を計算します。 例えば、FはHMAC-SHA1であるかもしれません(x、R)。 国がないことに、重要なすべてがyが知られている州の定数xと機能Fだけで一貫して計算できるということである、証明から来る他の入力は構造を要求します。yはその結果、Rに関する知識、HMAC-SHA1のような一方向関数の使用に基づいて予測できるべきではありません。
6.8. RA POP Witness Control
6.8. RAは目撃者コントロールを飛び出させます。
In a certification request scenario that involves an RA, the CA may allow (or require) that the RA perform the POP protocol with the entity that generated the certification request. In this case, the RA needs a way to inform the CA that it has done the POP. The RA POP Witness control addresses this issue.
証明要求シナリオに、それはRAにかかわります、とカリフォルニアが許容するかもしれない、(必要である、)、RAが証明要求を生成した実体でPOPプロトコルを実行します。 この場合、RAはPOPをしたことをカリフォルニアに知らせる方法を必要とします。 RA POP Witnessコントロールはこの問題を扱います。
The RA POP Witness control is identified by the OID:
RA POP WitnessコントロールはOIDによって特定されます:
id-cmc-lraPOPWitness ::= { id-cmc 11 }
イド-cmc-lraPOPWitness:、:= イド-cmc11
The RA POP Witness control has the ASN.1 definition:
RA POP Witnessコントロールには、ASN.1定義があります:
LraPopWitness ::= SEQUENCE {
pkiDataBodyid BodyPartID,
bodyIds SEQUENCE of BodyPartID
}
LraPopWitness:、:= 系列pkiDataBodyid BodyPartID、BodyPartIDのbodyIds系列
The fields in LraPOPWitness have the following meaning:
LraPOPWitnessの分野には、以下の意味があります:
pkiDataBodyid contains the body part identifier of the nested
TaggedContentInfo containing the client's Full PKI Request.
pkiDataBodyid is set to 0 if the request is in the current
PKIData.
クライアントのFull PKI Request. pkiDataBodyidを含んでいて、pkiDataBodyidは入れ子にされたTaggedContentInfoに関するボディー部分識別子を含んでいます。要求が現在のPKIDataにあるなら、0に設定されます。
bodyIds is a list of certification requests for which the RA has
performed an out-of-band authentication. The method of
authentication could be archival of private key material,
challenge-response, or other means.
bodyIdsはRAがバンドで出ている認証を実行した証明要求のリストです。 認証のメソッドは秘密鍵の材料、チャレンジレスポンス、または他の手段で記録保管所であるかもしれません。
Schaad & Myers Standards Track [Page 48] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[48ページ]: 2008年6月を構造化します。
If a certification server does not allow an RA to do the POP verification, it returns a CMCFailInfo with the value of popFailed. The CA MUST NOT start a challenge-response to re-verify the POP itself.
RAが証明サーバでPOP検証ができないなら、それはpopFailedの値があるCMCFailInfoを返します。 カリフォルニアは、POP自体について再確かめるためにチャレンジレスポンスを始めてはいけません。
6.9. Get Certificate Control
6.9. 証明書コントロールを手に入れてください。
Everything described in this section is optional to implement.
このセクションで説明されたすべてが、実装するために任意です。
The Get Certificate control is used to retrieve a previously issued certificate from a certificate repository. A CA, an RA, or an independent service may provide this repository. The clients expected to use this facility are those where a fully deployed directory is either infeasible or undesirable.
Get Certificateコントロールは、証明書倉庫からの以前に発行された証明書を検索するのに使用されます。 カリフォルニア、RA、または独立しているサービスがこの倉庫を提供するかもしれません。 この施設を使用すると予想されたクライアントは完全に配布しているディレクトリが実行不可能であるか、または望ましくないところのそれらです。
The Get Certificate control is identified by the OID:
Get CertificateコントロールはOIDによって特定されます:
id-cmc-getCert ::= { id-cmc 15 }
イド-cmc-getCert:、:= イド-cmc15
The Get Certificate control has the ASN.1 definition:
Get Certificateコントロールには、ASN.1定義があります:
GetCert ::= SEQUENCE {
issuerName GeneralName,
serialNumber INTEGER }
GetCert:、:= 系列issuerName GeneralName、serialNumber整数
The fields in GetCert have the following meaning:
GetCertの分野には、以下の意味があります:
issuerName is the name of the certificate issuer.
issuerNameは証明書発行人の名前です。
serialNumber identifies the certificate to be retrieved.
serialNumberは、検索されるために証明書を特定します。
The server that responds to this request places the requested certificate in the certificates field of a SignedData. If the Get Certificate control is the only control in a Full PKI Request, the response should be a Simple PKI Response.
この要求に応じるサーバはSignedDataの証明書分野に要求された証明書を置きます。 Get CertificateコントロールがFull PKI Requestで唯一のコントロールであるなら、応答はSimple PKI Responseであるべきです。
6.10. Get CRL Control
6.10. CRLコントロールを手に入れてください。
Everything described in this section is optional to implement.
このセクションで説明されたすべてが、実装するために任意です。
The Get CRL control is used to retrieve CRLs from a repository of CRLs. A CA, an RA, or an independent service may provide this repository. The clients expected to use this facility are those where a fully deployed directory is either infeasible or undesirable.
Get CRLコントロールは、CRLsの倉庫からCRLsを検索するのに使用されます。 カリフォルニア、RA、または独立しているサービスがこの倉庫を提供するかもしれません。 この施設を使用すると予想されたクライアントは完全に配布しているディレクトリが実行不可能であるか、または望ましくないところのそれらです。
The Get CRL control is identified by the OID:
Get CRLコントロールはOIDによって特定されます:
id-cmc-getCRL ::= { id-cmc 16 }
イド-cmc-getCRL:、:= イド-cmc16
Schaad & Myers Standards Track [Page 49] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[49ページ]: 2008年6月を構造化します。
The Get CRL control has the ASN.1 definition:
Get CRLコントロールには、ASN.1定義があります:
GetCRL ::= SEQUENCE {
issuerName Name,
cRLName GeneralName OPTIONAL,
time GeneralizedTime OPTIONAL,
reasons ReasonFlags OPTIONAL }
GetCRL:、:= 系列issuerName Name(cRLName GeneralName OPTIONAL、時間GeneralizedTime OPTIONAL)はReasonFlags OPTIONALを推論します。
The fields in a GetCRL have the following meanings:
GetCRLの分野には、以下の意味があります:
issuerName is the name of the CRL issuer.
issuerNameはCRL発行人の名前です。
cRLName may be the value of CRLDistributionPoints in the subject
certificate or equivalent value in the event the certificate does
not contain such a value.
cRLNameは対象の証明書か同等な値における、証明書が含まないイベントにおける、CRLDistributionPointsの値がそのような値であったならそうするかもしれません。
time is used by the client to specify from among potentially several
issues of CRL that one whose thisUpdate value is less than but
nearest to the specified time. In the absence of a time
component, the CA always returns with the most recent CRL.
時間は、潜在的にCRLのいくつかの問題から指定された時間により少ないのですが、thisUpdate値が最も近いそのものを指定するためにクライアントによって費やされます。 時間コンポーネントがないとき、カリフォルニアはいつも最新のCRLとともに帰ります。
reasons is used to specify from among CRLs partitioned by revocation
reason. Implementers should bear in mind that while a specific
revocation request has a single CRLReason code -- and consequently
entries in the CRL would have a single CRLReason code value -- a
single CRL can aggregate information for one or more reasonFlags.
理由は、取消し理由によって仕切られたCRLsから指定するのに使用されます。 Implementersは、特定の取消し要求にはただ一つのCRLReasonコードがある間(そして、その結果、CRLのエントリーでは、ただ一つのCRLReasonコード値があるでしょう)独身のCRLが1reasonFlagsのための情報に集めることができるのを覚えておくはずです。
A server responding to this request places the requested CRL in the crls field of a SignedData. If the Get CRL control is the only control in a Full PKI Request, the response should be a Simple PKI Response.
この要求に応じるサーバはSignedDataのcrls分野に要求されたCRLを置きます。 Get CRLコントロールがFull PKI Requestで唯一のコントロールであるなら、応答はSimple PKI Responseであるべきです。
6.11. Revocation Request Control
6.11. 取消し要求コントロール
The Revocation Request control is used to request that a certificate be revoked.
Revocation Requestコントロールは、証明書が取り消されるよう要求するのに使用されます。
The Revocation Request control is identified by the OID:
Revocation RequestコントロールはOIDによって特定されます:
id-cmc-revokeRequest ::= { id-cmc 17 }
イド-cmc-revokeRequest:、:= イド-cmc17
Schaad & Myers Standards Track [Page 50] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[50ページ]: 2008年6月を構造化します。
The Revocation Request control has the ASN.1 definition:
Revocation Requestコントロールには、ASN.1定義があります:
RevokeRequest ::= SEQUENCE {
issuerName Name,
serialNumber INTEGER,
reason CRLReason,
invalidityDate GeneralizedTime OPTIONAL,
sharedSecret OCTET STRING OPTIONAL,
comment UTF8string OPTIONAL }
RevokeRequest:、:= 系列issuerName Name(serialNumber INTEGER)はCRLReasonを推論して、invalidityDate GeneralizedTime OPTIONAL(sharedSecret OCTET STRING OPTIONAL)はUTF8string OPTIONALについて論評します。
The fields of RevokeRequest have the following meaning:
RevokeRequestの分野には、以下の意味があります:
issuerName is the issuerName of the certificate to be revoked.
issuerNameは取り消されるべき証明書のissuerNameです。
serialNumber is the serial number of the certificate to be revoked.
serialNumberは取り消されるべき証明書の通し番号です。
reason is the suggested CRLReason code for why the certificate is
being revoked. The CA can use this value at its discretion in
building the CRL.
理由は証明書が取り消されている理由の提案されたCRLReasonコードです。 カリフォルニアは自己判断でCRLを造る際にこの値を使用できます。
invalidityDate is the suggested value for the Invalidity Date CRL
Extension. The CA can use this value at its discretion in
building the CRL.
invalidityDateはInvalidity Date CRL Extensionのための提案された値です。 カリフォルニアは自己判断でCRLを造る際にこの値を使用できます。
sharedSecret is a secret value registered by the EE when the
certificate was obtained to allow for revocation of a certificate
in the event of key loss.
sharedSecretは主要な損失の場合、証明書の取消しを考慮するために証明書を入手したときEEが示した秘密の値です。
comment is a human-readable comment.
コメントは人間読み込み可能なコメントです。
For a revocation request to be reliable in the event of a dispute, a strong proof-of-origin is required. However, in the instance when an EE has lost use of its signature private key, it is impossible for the EE to produce a digital signature (prior to the certification of a new signature key pair). The Revoke Request control allows the EE to send the CA a shared-secret that may be used as an alternative authenticator in the instance of loss of use of the EE's signature private key. The acceptability of this practice is a matter of local security policy.
異義が生じた場合には信頼できるという取消し要求において、発生源の強い証拠が必要です。 しかしながら、インスタンスでは、EEが署名秘密鍵の使用を失ったとき、EEがデジタル署名(新しい署名主要な組の証明の前の)を起こすのは、不可能です。 Revoke Requestコントロールで、EEは代替の固有識別文字としてEEの署名秘密鍵で役に立つ損失のインスタンスに使用されるかもしれない共有秘密キーをカリフォルニアに送ることができます。 この習慣の受容性はローカルの安全保障政策の問題です。
It is possible to sign the revocation for the lost certificate with a different certificate in some circumstances. A client can sign a revocation for an encryption key with a signing certificate if the name information matches. Similarly, an administrator or RA can be assigned the ability to revoke the certificate of a third party. Acceptance of the revocation by the server depends on local policy in these cases.
いくつかの事情の異なった証明書を無くなっている証明書のための取消しと契約するのは可能です。 名前情報が合っているなら、クライアントは署名証明書によって主要な暗号化のための取消しに署名することができます。 同様に、第三者の証明書を取り消す能力を管理者かRAに割り当てることができます。 サーバによる取消しの承認はこれらの場合におけるローカルの方針によります。
Schaad & Myers Standards Track [Page 51] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[51ページ]: 2008年6月を構造化します。
Clients MUST provide the capability to produce a digitally signed Revocation Request control. Clients SHOULD be capable of producing an unsigned Revocation Request control containing the EE shared- secret (the unsigned message consisting of a SignedData with no signatures). If a client provides shared-secret-based self- revocation, the client MUST be capable of producing a Revocation Request control containing the shared-secret. Servers MUST be capable of accepting both forms of revocation requests.
クライアントはデジタルに署名しているRevocation Requestコントロールを起こす能力を提供しなければなりません。 クライアントSHOULD、秘密の状態で(署名なしでSignedDataから成る未署名のメッセージ)共有されたEEを含む未署名のRevocation Requestコントロールは起こすことができてください。 クライアントが共有された秘密ベースの自己取消しを提供するなら、クライアントは共有秘密キーを含むRevocation Requestコントロールを起こすことができなければなりません。 サーバは両方の形式の取消し要求を受け入れることができなければなりません。
The structure of an unsigned, shared-secret-based revocation request is a matter of local implementation. The shared-secret does not need to be encrypted when sent in a Revocation Request control. The shared-secret has a one-time use (i.e., it is used to request revocation of the certificate), and public knowledge of the shared- secret after the certificate has been revoked is not a problem. Clients need to inform users that the same shared-secret SHOULD NOT be used for multiple certificates.
未署名の、そして、共有された秘密ベースの取消し要求の構造は地方の実装の問題です。 Revocation Requestコントロールで送ると、共有秘密キーは暗号化する必要はありません。 共有秘密キーには、1回の使用があります、そして、(すなわち、それは証明書の取消しを要求するのに使用されます)証明書が取り消された後に共有された秘密に関する公知は問題ではありません。 クライアントは、同じ共有秘密キーSHOULD NOTが複数の証明書に使用されることをユーザに知らせる必要があります。
A Full PKI Response MUST be returned for a revocation request.
取消し要求のためにFull PKI Responseを返さなければなりません。
6.12. Registration and Response Information Controls
6.12. 登録と応答情報管理
The Registration Information control allows for clients to pass additional information as part of a Full PKI Request.
Registration情報コントロールは、クライアントがFull PKI Requestの一部として追加情報を通過するのを許容します。
The Registration Information control is identified by the OID:
Registration情報コントロールはOIDによって特定されます:
id-cmc-regInfo ::= { id-cmc 18 }
イド-cmc-regInfo:、:= イド-cmc18
The Registration Information control has the ASN.1 definition:
Registration情報コントロールには、ASN.1定義があります:
RegInfo ::= OCTET STRING
RegInfo:、:= 八重奏ストリング
The content of this data is based on bilateral agreement between the client and server.
このデータの内容はクライアントとサーバの間の二国間条約に基づいています。
The Response Information control allows a server to return additional information as part of a Full PKI Response.
Response情報コントロールで、サーバはFull PKI Responseの一部として追加情報を返すことができます。
The Response Information control is identified by the OID:
Response情報コントロールはOIDによって特定されます:
id-cmc-responseInfo ::= { id-cmc 19 }
イド-cmc-responseInfo:、:= イド-cmc19
The Response Information control has the ASN.1 definition:
Response情報コントロールには、ASN.1定義があります:
ResponseInfo ::= OCTET STRING
ResponseInfo:、:= 八重奏ストリング
Schaad & Myers Standards Track [Page 52] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[52ページ]: 2008年6月を構造化します。
The content of this data is based on bilateral agreement between the client and server.
このデータの内容はクライアントとサーバの間の二国間条約に基づいています。
6.13. Query Pending Control
6.13. 未定のコントロールについて質問してください。
In some environments, process requirements for manual intervention or other identity checks can delay the return of the certificate. The Query Pending control allows clients to query a server about the state of a pending certification request. The server returns a pendToken as part of the Extended CMC Status Info and the CMC Status Info controls (in the otherInfo field). The client copies the pendToken into the Query Pending control to identify the correct certification request to the server. The server returns a suggested time for the client to query for the state of a pending certification request.
いくつかの環境で、手動の介入か他の身元確認のためのプロセス要件は証明書の復帰を遅らせることができます。 Query Pendingコントロールで、クライアントは未定の証明要求の状態に関するサーバについて質問できます。 Extended CMC Status InfoとCMC Status Infoの一部が制御されるとき(otherInfo分野で)、サーバはpendTokenを返します。 クライアントは、正しい証明要求をサーバに特定するためにQuery PendingコントロールにpendTokenをコピーします。サーバはクライアントが未定の証明要求の状態に質問する提案された時間を返します。
The Query Pending control is identified by the OID:
Query PendingコントロールはOIDによって特定されます:
id-cmc-queryPending ::= { id-cmc 21 }
イド-cmc-queryPending:、:= イド-cmc21
The Query Pending control has the ASN.1 definition:
Query Pendingコントロールには、ASN.1定義があります:
QueryPending ::= OCTET STRING
QueryPending:、:= 八重奏ストリング
If a server returns a pending or partial CMCStatusInfo (the transaction is still pending), the otherInfo MAY be omitted. If the otherInfo is not omitted, the value of 'pendInfo' MUST be the same as the original pendInfo value.
サーバが未定の、または、部分的なCMCStatusInfoを返すなら(トランザクションはまだ未定です)、otherInfoは省略されるかもしれません。 otherInfoが省略されないなら、'pendInfo'の値はオリジナルのpendInfoが評価するのと同じであるに違いありません。
6.14. Confirm Certificate Acceptance Control
6.14. 証明書承認コントロールを確認してください。
Some CAs require that clients give a positive confirmation that the certificates issued to the EE are acceptable. The Confirm Certificate Acceptance control is used for that purpose. If the CMC Status Info on a PKI Response is confirmRequired, then the client MUST return a Confirm Certificate Acceptance control contained in a Full PKI Request.
クライアントが証明書がEEに発行した積極的確認を与えるCAsが必要とする或るものは許容できます。 Confirm Certificate Acceptanceコントロールはそのために使用されます。 PKI Responseの上のCMC Status InfoがconfirmRequiredであるなら、クライアントはFull PKI Requestに含まれたConfirm Certificate Acceptanceコントロールを返さなければなりません。
Clients SHOULD wait for the PKI Response from the server that the confirmation has been received before using the certificate for any purpose.
クライアントSHOULDは確認が受け取られたサーバからのどんな目的にも証明書を使用するPKI Responseを待っています。
The Confirm Certificate Acceptance control is identified by the OID:
Confirm Certificate AcceptanceコントロールはOIDによって特定されます:
id-cmc-confirmCertAcceptance ::= { id-cmc 24 }
イド-cmc-confirmCertAcceptance:、:= イド-cmc24
Schaad & Myers Standards Track [Page 53] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[53ページ]: 2008年6月を構造化します。
The Confirm Certificate Acceptance control has the ASN.1 definition:
Confirm Certificate Acceptanceコントロールには、ASN.1定義があります:
CMCCertId ::= IssuerAndSerialNumber
CMCCertId:、:= IssuerAndSerialNumber
CMCCertId contains the issuer and serial number of the certificate being accepted.
CMCCertIdは受け入れられる証明書の発行人と通し番号を含んでいます。
Servers MUST return a Full PKI Response for a Confirm Certificate Acceptance control.
サーバはConfirm Certificate AcceptanceコントロールのためにFull PKI Responseを返さなければなりません。
Note that if the CA includes this control, there will be two full round-trips of messages.
カリフォルニアがこのコントロールを含んでいると、メッセージの2つの完全な周遊旅行があることに注意してください。
1. The client sends the certification request to the CA.
1. クライアントは証明要求をカリフォルニアに送ります。
2. The CA returns a Full PKI Response with the certificate and this
control.
2. カリフォルニアは証明書とこのコントロールでFull PKI Responseを返します。
3. The client sends a Full PKI Request to the CA with an Extended
CMC Status Info control accepting and a Confirm Certificate
Acceptance control or an Extended CMC Status Info control
rejecting the certificate.
3. クライアントはExtended CMC Status Infoコントロールが受け入れていて、Confirm Certificate AcceptanceコントロールかExtended CMC Status Infoコントロールが証明書を拒絶しているカリフォルニアにFull PKI Requestを送ります。
4. The CA sends a Full PKI Response to the client with an Extended
CMC Status Info of success.
4. カリフォルニアは成功のExtended CMC Status InfoをもっているクライアントにFull PKI Responseを送ります。
6.15. Publish Trust Anchors Control
6.15. アンカーが制御する信頼を発行してください。
The Publish Trust Anchors control allows for the distribution of set trust anchors from a central authority to an EE. The same control is also used to update the set of trust anchors. Trust anchors are distributed in the form of certificates. These are expected, but not required, to be self-signed certificates. Information is extracted from these certificates to set the inputs to the certificates validation algorithm in Section 6.1.1 of [PKIXCERT].
Publish Trust Anchorsコントロールはセット信頼アンカーの主要な権威からEEまでの分配を考慮します。 また、同じコントロールは、信頼アンカーのセットをアップデートするのに使用されます。 信頼アンカーは証明書の形で分配されます。 これらは、予想されますが、自己署名入りの証書になるのに必要ではありません。 情報は、.1セクション6.1[PKIXCERT]の証明書合法化アルゴリズムに入力を設定するためにこれらの証明書から抜粋されます。
The Publish Trust Anchors control is identified by the OID:
Publish Trust AnchorsコントロールはOIDによって特定されます:
id-cmc-trustedAnchors ::= { id-cmc 26 }
イド-cmc-trustedAnchors:、:= イド-cmc26
The Publish Trust Anchors control has the ASN.1 definition:
Publish Trust Anchorsコントロールには、ASN.1定義があります:
PublishTrustAnchors ::= SEQUENCE {
seqNumber INTEGER,
hashAlgorithm AlgorithmIdentifier,
anchorHashes SEQUENCE OF OCTET STRING
}
PublishTrustAnchors:、:= 系列seqNumber整数、hashAlgorithm AlgorithmIdentifier、八重奏ストリングのanchorHashes系列
Schaad & Myers Standards Track [Page 54] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[54ページ]: 2008年6月を構造化します。
The fields in PublishTrustAnchors have the following meaning:
PublishTrustAnchorsの分野には、以下の意味があります:
seqNumber is an integer indicating the location within a sequence of
updates.
seqNumberはアップデートの系列の中に位置を示す整数です。
hashAlgorithm is the identifier and parameters for the hash
algorithm that is used in computing the values of the anchorHashes
field. All implementations MUST implement SHA-1 for this field.
hashAlgorithmはanchorHashes分野の値を計算する際に使用されるハッシュアルゴリズムのための識別子とパラメタです。 すべての実装がこの分野にSHA-1を実装しなければなりません。
anchorHashes are the hashes for the certificates that are to be
treated as trust anchors by the client. The actual certificates
are transported in the certificate bag of the containing
SignedData structure.
anchorHashesはクライアントによって信頼アンカーとして扱われることになっている証明書のためのハッシュです。 実際の証明書はSignedDataが構造化する含有の証明書バッグで輸送されます。
While it is recommended that the sender place the certificates that are to be trusted in the PKI Response, it is not required as the certificates should be obtainable using normal discovery techniques.
送付者がPKI Responseで信じられることになっている証明書を置くのが、お勧めですが、証明書が正常な発見のテクニックを使用することで入手可能であるべきであるようにそれは必要ではありません。
Prior to accepting the trust anchors changes, a client MUST at least do the following: validate the signature on the PKI Response to a current trusted anchor, check with policy to ensure that the signer is permitted to use the control, validate that the authenticated publish time in the signature is near to the current time, and validate that the sequence number is greater than the previously used one.
受諾の前に、信頼は変化を据えつけて、クライアントは少なくとも以下をしなければなりません: 信じられたアンカー、署名者がコントロールを使用することが許可されている確実にする方針があるチェックが有効にする電流への認証が発行するPKI Responseにおける署名は、現在の時間まで署名があるコネを調節して、それを有効にします。有効にする、一連番号は以前中古のものより大きいです。
In the event that multiple agents publish a set of trust anchors, it is up to local policy to determine how the different trust anchors should be combined. Clients SHOULD be able to handle the update of multiple trust anchors independently.
複数のエージェントが1セットの信頼アンカーを発行する場合、異なった信頼アンカーがどのように結合されるべきであるかを決定するのがローカルの方針まで達しています。 クライアントSHOULD、独自に複数の信頼アンカーのアップデートを扱うことができてください。
Note: Clients that handle this control must use extreme care in validating that the operation is permissible. Incorrect handling of this control allows for an attacker to change the set of trust anchors on the client.
以下に注意してください。 このコントロールを扱うクライアントは許された状態で操作がある有効にすることにおける極端な注意を働かせなければなりません。 このコントロールの不正確な取り扱いは、攻撃者がクライアントで信頼アンカーのセットを変えるのを許容します。
6.16. Authenticated Data Control
6.16. 認証されたデータコントロール
The Authenticated Data control allows a server to provide data back to the client in an authenticated manner. This control uses the Authenticated Data structure to allow for validation of the data. This control is used where the client has a shared-secret and a secret identifier with the server, but where a trust anchor has not yet been downloaded onto the client so that a signing certificate for the server cannot be validated. The specific case that this control was created for use with is the Publish Trust Anchors control (Section 6.15), but it may be used in other cases as well.
Authenticated Dataコントロールで、サーバは認証された方法でデータをクライアントに提供であって戻しできます。 このコントロールは、データの合法化を考慮するのにAuthenticated Data構造を使用します。 サーバと共にクライアントが共有秘密キーと秘密の識別子を持っているところで使用されますが、このコントロールは、サーバのための署名証明書を有効にすることができないように信頼アンカーがまだクライアントにダウンロードされていないところで使用されます。 これが制御する特定のケースが使用のために引き起こされた、Publish Trust Anchorsはコントロール(セクション6.15)ですが、それはまた、他の場合に使用されるかもしれません。
Schaad & Myers Standards Track [Page 55] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[55ページ]: 2008年6月を構造化します。
The Authenticated Data control is identified by the OID:
Authenticated DataコントロールはOIDによって特定されます:
id-cmc-authData ::= { id-cmc 27 }
イド-cmc-authData:、:= イド-cmc27
The Authenticated Data control has the ASN.1 definition:
Authenticated Dataコントロールには、ASN.1定義があります:
AuthPublish ::= BodyPartID
AuthPublish:、:= BodyPartID
AuthPublish is a body part identifier that refers to a member of the cmsSequence element for the current PKI Response or PKI Data. The cmsSequence element is AuthenticatedData. The encapsulated content is an id-cct-PKIData. The controls in the controlSequence need to be processed if the authentication succeeds. (One example is the Publish Trust Anchors control in Section 6.15.)
AuthPublishは現在のPKI ResponseかPKI DataについてcmsSequence要素のメンバーについて言及するボディー部分識別子です。 cmsSequence要素はAuthenticatedDataです。 カプセル化された内容はイド-cct-PKIDataです。 認証が成功するなら、controlSequenceでのコントロールは、処理される必要があります。 (1つの例がセクション6.15でPublish Trust Anchorsコントロールです。)
If the authentication operation fails, the CMCFailInfo authDataFail is returned.
認証操作が失敗するなら、CMCFailInfo authDataFailを返します。
6.17. Batch Request and Response Controls
6.17. バッチ要求と応答制御
These controls allow for an RA to collect multiple requests together into a single Full PKI Request and forward it to a CA. The server would then process the requests and return the results in a Full PKI Response.
これらのコントロールは、RAが複数の要求を独身のFull PKI Requestに一緒に集めて、それをカリフォルニアに送るのを許容します。 サーバは、次に、要求を処理して、Full PKI Responseで結果を返すでしょう。
The Batch Request control is identified by the OID:
Batch RequestコントロールはOIDによって特定されます:
id-cmc-batchRequests ::= {id-cmc 28}
イド-cmc-batchRequests:、:= イド-cmc28
The Batch Response control is identified by the OID:
Batch ResponseコントロールはOIDによって特定されます:
id-cmc-batchResponses ::= {id-cmc 29}
イド-cmc-batchResponses:、:= イド-cmc29
Both the Batch Request and Batch Response controls have the ASN.1 definition:
Batch RequestとBatch Responseコントロールの両方には、ASN.1定義があります:
BodyPartList ::= SEQUENCE of BodyPartID
BodyPartList:、:= BodyPartIDの系列
The data associated with these controls is a set of body part identifiers. Each request/response is placed as an individual entry in the cmcSequence of the new PKIData/PKIResponse. The body part identifiers of these entries are then placed in the body part list associated with the control.
これらのコントロールに関連しているデータは1セットのボディー部分識別子です。 各要求/応答は個人出場者として新しいPKIData/PKIResponseのcmcSequenceに置かれます。 そして、これらのエントリーに関するボディー部分識別子はコントロールに関連しているボディー部分リストに置かれます。
When a server processes a Batch Request control, it MAY return the responses in one or more PKI Responses. A CMCStatus value of partial is returned on all but the last PKI Response. The CMCStatus would be success if the Batch Requests control was processed; the responses
サーバがBatch Requestコントロールを加工処理するとき、それは1PKI Responsesで応答を返すかもしれません。 最後のPKI Response以外のすべてで部分的のCMCStatus値を返します。 Batch Requestsコントロールが加工処理されるなら、CMCStatusは成功でしょうに。 応答
Schaad & Myers Standards Track [Page 56] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[56ページ]: 2008年6月を構造化します。
are created with their own CMCStatus code. Errors on individual requests are not propagated up to the top level.
それら自身のCMCStatusコードで、作成されます。 個々の要求の誤りはトップレベルまで伝播されません。
When a PKI Response with a CMCStatus value of partial is returned, the Query Pending control (Section 6.13) is used to retrieve additional results. The returned status includes a suggested time after which the client should ask for the additional results.
部分的のCMCStatus値があるPKI Responseを返すとき、追加結果を検索するのに、Query Pendingコントロール(セクション6.13)を使用します。 返された状態はクライアントが追加結果を求めるべきである提案された時を含んでいます。
6.18. Publication Information Control
6.18. 公表情報管理
The Publication Information control allows for modifying publication of already issued certificates, both for publishing and removal from publication. A common usage for this control is to remove an existing certificate from publication during a rekey operation. This control should always be processed after the issuance of new certificates and revocation requests. This control should not be processed if a certificate failed to be issued.
Publication情報コントロールは、公表から出版と取り外しのための証明書が発行された既にの公表を変更すると考慮します。 このコントロールのための一般的な用法はrekey操作の間、公表から既存の証明書を取り外すことです。 このコントロールは新しい証明書と取消し要求の発行の後にいつも加工処理されるべきです。 証明書が発行しないなら、このコントロールを加工処理しないでしょうに。
The Publication Information control is identified by the OID:
Publication情報コントロールはOIDによって特定されます:
id-cmc-publishCert ::= { id-cmc 30 }
イド-cmc-publishCert:、:= イド-cmc30
The Publication Information control has the ASN.1 definition:
Publication情報コントロールには、ASN.1定義があります:
CMCPublicationInfo ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
certHashes SEQUENCE of OCTET STRING,
pubInfo PKIPublicationInfo
CMCPublicationInfo:、:= 系列、hashAlg AlgorithmIdentifier、八重奏ストリング、pubInfo PKIPublicationInfoのcertHashes系列
PKIPublicationInfo ::= SEQUENCE {
action INTEGER {
dontPublish (0),
pleasePublish (1) },
pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }
PKIPublicationInfo:、:= 系列動作INTEGER、dontPublish(0)、pleasePublish(1)、pubInfos SEQUENCE SIZE(1..MAX)OF SinglePubInfo OPTIONAL
-- pubInfos MUST NOT be present if action is "dontPublish"
-- (if action is "pleasePublish" and pubInfos is omitted,
-- "dontCare" is assumed)
-- pubInfosは動作が"dontPublish"であるなら存在しているはずがありません--(pubInfosは省略されます--動作が"pleasePublish"であり、"dontCare"が想定されるなら)
SinglePubInfo ::= SEQUENCE {
pubMethod INTEGER {
dontCare (0),
x500 (1),
web (2),
ldap (3) },
pubLocation GeneralName OPTIONAL }
}
SinglePubInfo:、:= SEQUENCE、pubMethod INTEGER、pubLocation GeneralName OPTIONAL、dontCare(0)(x500(1)、ウェブ(2))は(3)をldapします。
Schaad & Myers Standards Track [Page 57] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[57ページ]: 2008年6月を構造化します。
The fields in CMCPublicationInfo have the following meaning:
CMCPublicationInfoの分野には、以下の意味があります:
hashAlg is the algorithm identifier of the hash algorithm used to
compute the values in certHashes.
hashAlgはcertHashesで値を計算するのに使用されるハッシュアルゴリズムに関するアルゴリズム識別子です。
certHashes are the hashes of the certificates for which publication
is to change.
certHashesは公表が変化することになっている証明書のハッシュです。
pubInfo is the information where and how the certificates should be
published. The fields in pubInfo (taken from [CRMF]) have the
following meanings:
pubInfoは証明書がどこでどのように発表されるべきであるかという情報です。 pubInfo([CRMF]から、取る)の分野には、以下の意味があります:
action indicates the action the service should take. It has two
values:
動作はサービスが取るべきである行動を示します。 それには、2つの値があります:
dontPublish indicates that the PKI should not publish the
certificate (this may indicate that the requester intends to
publish the certificate him/herself). dontPublish has the
added connotation of removing from publication the
certificate if it is already published.
dontPublishは、PKIが証明書を発表するはずがないのを示します(これは、リクエスタが自己に証明書を発表するつもりであるのを示すかもしれません)。dontPublishには、それが既に発行されるなら公表から証明書を取り外す加えられた含蓄があります。
pleasePublish indicates that the PKI MAY publish the
certificate using whatever means it chooses unless pubInfos
is present. Omission of the CMC Publication Info control
results in the same behavior.
pleasePublishは、PKI MAYがpubInfosが存在していない場合それが選ばれることを意味するものなら何でも使用することで証明書を発表するのを示します。 CMC Publication Infoコントロールの省略は同じ振舞いをもたらします。
pubInfos pubInfos indicates how (e.g., X500, Web, IP Address) the
PKI SHOULD publish the certificate.
pubInfos pubInfosは(例えば、X500、ウェブ、IP Address)PKI SHOULDがどう証明書を発表するかを示します。
A single certificate SHOULD NOT appear in more than one Publication Information control. The behavior is undefined in the event that it does.
SHOULD NOTが1つ以上のPublication情報コントロールで見えるただ一つの証明書。 未定義である場合、振舞いは未定義です。
6.19. Control Processed Control
6.19. コントロールはコントロールを加工処理しました。
The Control Processed control allows an RA to indicate to subsequent control processors that a specific control has already been processed. This permits an RA in the middle of a processing stream to process a control defined either in a local context or in a subsequent document.
Control Processedコントロールで、RAは、既に特定のコントロールを加工処理してあるのをその後の制御プロセッサに示すことができます。 これは、処理ストリームの中央のRAがローカルの関係かその後のドキュメントで定義されたコントロールを加工処理することを許可します。
The Control Processed control is identified by the OID:
Control ProcessedコントロールはOIDによって特定されます:
id-cmc-controlProcessed ::= { id-cmc 32 }
イド-cmc-controlProcessed:、:= イド-cmc32
Schaad & Myers Standards Track [Page 58] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[58ページ]: 2008年6月を構造化します。
The Control Processed control has the ASN.1 definition:
Control Processedコントロールには、ASN.1定義があります:
ControlList ::= SEQUENCE {
bodyList SEQUENCE SIZE (1..MAX) OF BodyPartReference
}
ControlList:、:= 系列BodyPartReferenceのbodyList系列サイズ(1..MAX)
bodyList is a series of body part identifiers that form a path to
each of the controls that were processed by the RA. This control
is only needed for those controls that are not part of this
standard and thus would cause an error condition of a server
attempting to deal with a control not defined in this document.
No error status is needed since an error causes the RA to return
the request to the client with the error rather than passing the
request on to the next server in the processing list.
bodyListはRAによって加工処理されたそれぞれのコントロールに経路を形成する一連のボディー部分識別子です。 このコントロールは、この規格の一部でないそれらのコントロールに必要であるだけであり、その結果、本書では定義されなかったコントロールに対処するのを試みるサーバのエラー条件を引き起こすでしょう。 RAが誤りと共に処理リストの次のサーバに要求に合格するより誤りで要求をクライアントにむしろ返すので、エラー状況は全く必要ではありません。
7. Registration Authorities
7. 登録局
This specification permits the use of RAs. An RA sits between the EE and the CA. From the EE's perspective, the RA appears to be the CA, and from the server, the RA appears to be a client. RAs receive the PKI Requests, perform local processing and then forward them onto CAs. Some of the types of local processing that an RA can perform include:
この仕様はRAsの使用を可能にします。 RAはEEとカリフォルニアの間に座っています。 EEの見解から、RAは、カリフォルニアであるように見えます、そして、サーバから、RAはクライアントであるように見えます。 RAsはPKI Requestsを受けて、ローカル処理を実行して、次に、彼らをCAsに送ります。 RAが実行できるローカル処理の何人かのタイプは:
o Batching multiple PKI Requests together,
o 一緒に複数のバッチングPKI Requests
o Performing challenge/response POP proofs,
o 挑戦/応答POP証拠を実行します。
o Adding private or standardized certificate extensions to all
certification requests,
o 個人的であるか標準化された証明書拡張子をすべての証明要求に追加します。
o Archiving private key material,
o 秘密鍵の材料を格納します。
o Routing requests to different CAs.
o 異なったCAsに要求を発送します。
When an RA receives a PKI Request, it has three options: it may forward the PKI Request without modification, it may add a new wrapping layer to the PKI Request, or it may remove one or more existing layers and add a new wrapping layer.
RAがPKI Requestを受けるとき、それには、3つのオプションがあります: 変更なしでPKI Requestを進めるかもしれなくて、新しいラッピング層をPKI Requestに加えるかもしれないか、それは、1つ以上の既存の層を取り除いて、新しいラッピング層を加えるかもしれません。
When an RA adds a new wrapping layer to a PKI Request, it creates a new PKIData. The new layer contains any controls required (for example, if the RA does the POP proof for an encryption key or the Add Extension control to modify a PKI Request) and the client PKI Request. The client PKI Request is placed in the cmsSequence if it is a Full PKI Request and in the reqSequence if it is a Simple PKI Request. If an RA is batching multiple client PKI Requests together,
RAが新しいラッピング層をPKI Requestに加えるとき、それは新しいPKIDataを作成します。 新しい層は必要である(暗号化キーかAdd ExtensionコントロールがPKI Requestを変更するようにRAが例えばPOP証拠をするなら)コントロールとクライアントPKI Requestを含んでいます。 それがSimple PKI RequestであるならFull PKI RequestとreqSequenceにあるなら、クライアントPKI RequestはcmsSequenceに置かれます。 RAが一緒にバッチング倍数クライアントPKI Requestsであるなら
Schaad & Myers Standards Track [Page 59] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[59ページ]: 2008年6月を構造化します。
then each client PKI Request is placed into the appropriate location in the RA's PKIData object along with all relevant controls.
そして、それぞれのクライアントPKI Requestはすべての関連コントロールに伴うRAのPKIDataオブジェクトの適切な位置に置かれます。
If multiple RAs are in the path between the EE and the CA, this will lead to multiple wrapping layers on the request.
複数のRAsがEEとカリフォルニアの間の経路にあると、これは要求での複数のラッピング層に通じるでしょう。
In processing a PKI Request, an RA MUST NOT alter any certification requests (PKCS #10 or CRMF) as any alteration would invalidate the signature on the certification request and thus the POP for the private key.
処理では、どんな変更も秘密鍵のためにその結果、証明要求とPOPの上で署名を無効にするようにPKI Request、RA MUST NOTはどんな証明要求(PKCS#の10かCRMF)も変更します。
An example of how this would look is illustrated by the following figure:
これがどう見えるだろうかに関する例は以下の図によって例証されます:
SignedData (by RA)
PKIData
controlSequence
RA added control statements
reqSequence
Zero or more Simple PKI Requests from clients
cmsSequence
Zero or more Full PKI Requests from clients
SignedData (signed by client)
PKIData
SignedData(RAによる)PKIData controlSequence RAはクライアントcmsSequence Zeroか、より多くのFull PKI RequestsからクライアントSignedData(クライアントによって署名される)PKIDataからコントロール声明reqSequence Zeroか、より多くのSimple PKI Requestsを加えました。
Under some circumstances, an RA is required to remove wrapping layers. The following sections look at the processing required if encryption layers and signing layers need to be removed.
いくつかの状況で、RAが、取り外すのに層を包装しながら、必要です。 以下のセクションは暗号化層と署名層が、取り除かれる必要があるなら必要である処理を見ます。
7.1. Encryption Removal
7.1. 暗号化取り外し
There are two cases that require an RA to remove or change encryption in a PKI Request. In the first case, the encryption was applied for the purposes of protecting the entire PKI Request from unauthorized entities. If the CA does not have a Recipient Info entry in the encryption layer, the RA MUST remove the encryption layer. The RA MAY add a new encryption layer with or without adding a new signing layer.
RAがPKI Requestで暗号化を取り除くか、または変えるのを必要とする2つのケースがあります。 前者の場合、暗号化は権限のない実体から全体のPKI Requestを保護する目的のために適用されました。 カリフォルニアが暗号化層の中にRecipient Infoエントリーを持っていないなら、RA MUSTは暗号化層を取り除きます。 新しい署名層を加えることのあるなしにかかわらずRA MAYは新しい暗号化層を加えます。
The second change of encryption that may be required is to change the encryption inside of a signing layer. In this case, the RA MUST remove all signing layers containing the encryption. All control statements MUST be merged according to local policy rules as each signing layer is removed and the resulting merged controls MUST be placed in a new signing layer provided by the RA. If the signing layer provided by the EE needs to also be removed, the RA can also remove this layer.
必要であるかもしれない暗号化の2番目の変化は署名層の暗号化内部を変えることになっています。 この場合、RA MUSTは暗号化を含むすべての署名層を取り除きます。 それぞれの署名層が移されて、RAによって提供された新しい署名層に結果として起こる合併しているコントロールを置かなければならないようなローカルの政策ルールによると、すべての規制声明を合併しなければなりません。 また、EEによって提供された署名層が、また、取り除かれる必要があるなら、RAはこの層を取り除くことができます。
Schaad & Myers Standards Track [Page 60] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[60ページ]: 2008年6月を構造化します。
7.2. Signature Layer Removal
7.2. 署名層の除去
Only two instances exist where an RA should remove a signature layer on a Full PKI Request: if an encryption layer needs to be modified within the request, or if a CA will not accept secondary delegation (i.e., multiple RA signatures). In all other situations, RAs SHOULD NOT remove a signing layer from a PKI Request.
2つのインスタンスだけがRAがFull PKI Requestで署名層を移すはずであるところに存在しています: 暗号化層が、要求の中で変更される必要があるか、またはカリフォルニアがセカンダリ委譲(すなわち、倍数RA署名)を受け入れないなら。 他のすべての状況で、RAs SHOULDはPKI Requestから署名層を取り除きません。
If an RA removes a signing layer from a PKI Request, all control statements MUST be merged according to local policy rules. The resulting merged control statements MUST be placed in a new signing layer provided by the RA.
RAがPKI Requestから署名層を取り除くなら、ローカルの政策ルールによると、すべての規制声明を合併しなければなりません。 RAによって提供された新しい署名層に結果として起こる合併している規制声明を置かなければなりません。
8. Security Considerations
8. セキュリティ問題
Mechanisms for thwarting replay attacks may be required in particular implementations of this protocol depending on the operational environment. In cases where the CA maintains significant state information, replay attacks may be detectable without the inclusion of the optional nonce mechanisms. Implementers of this protocol need to carefully consider environmental conditions before choosing whether or not to implement the senderNonce and recipientNonce controls described in Section 6.6. Developers of state-constrained PKI clients are strongly encouraged to incorporate the use of these controls.
反射攻撃を阻むためのメカニズムが運用環境に依存するこのプロトコルの特定の実装で必要であるかもしれません。 カリフォルニアが重要な州の情報を保守する場合では、反射攻撃は任意の一回だけのメカニズムの包含なしで検出可能であるかもしれません。このプロトコルのImplementersは、senderNonceとrecipientNonceがセクション6.6で説明されたコントロールであると実装するかどうかを選ぶ前に慎重に環境条件を考える必要があります。 状態が強制的なPKIクライアントの開発者がこれらのコントロールの使用を取り入れるよう強く奨励されます。
Extreme care needs to be taken when archiving a signing key. The holder of the archived key may have the ability to use the key to generate forged signatures. There are however reasons why a signing key should be archived. An archived CA signing key can be recovered in the event of failure to continue to produced CRLs following a disaster.
極端な注意は、署名キーを格納するとき、取られる必要があります。 格納されたキーの所有者には、偽の署名を生成するのにキーを使用する能力があるかもしれません。 しかしながら、署名キーが格納されるべきである理由があります。 災害に続いて、生産されたCRLsに続かないことの場合、格納されたカリフォルニア署名キーを回収できます。
Due care must be taken prior to archiving keys. Once a key is given to an archiving entity, the archiving entity could use the keys in a way not conducive to the archiving entity. Users should be made especially aware that proper verification is made of the certificate used to encrypt the private key material.
キーを格納する前に、相当な注意を取らなければなりません。 いったん格納実体にキーを与えると、格納実体はある意味で格納実体に役に立たないキーを使用するかもしれません。 ユーザを秘密鍵の材料を暗号化するのに使用される証明書で適切な検証をするのを特に意識するようにするべきです。
Clients and servers need to do some checks on cryptographic parameters prior to issuing certificates to make sure that weak parameters are not used. A description of the small subgroup attack is provided in [X942]. Methods of avoiding the small subgroup attack can be found in [SMALL-GROUP]. CMC implementations ought to be aware of this attack when doing parameter validations.
クライアントとサーバは、弱いパラメタが使用されていないのを確実にするために証明書を発行する前に暗号のパラメタのいくつかのチェックをする必要があります。 小さいサブグループ攻撃の記述を[X942]に提供します。 [SMALL-GROUP]で小さいサブグループ攻撃を避けるメソッドを見つけることができます。 パラメタ合法化をするとき、CMC実装はこの攻撃を意識しているべきです。
Schaad & Myers Standards Track [Page 61] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[61ページ]: 2008年6月を構造化します。
When using a shared-secret for authentication purposes, the shared- secret should be generated using good random number techniques [RANDOM]. User selection of the secret allows for dictionary attacks to be mounted.
認証目的に共有秘密キーを使用するとき、共有された秘密は、良い乱数のテクニック[RANDOM]を使用することで生成されるべきです。 秘密のユーザ選択は、辞書攻撃が仕掛けられるのを許容します。
Extreme care must be used when processing the Publish Trust Anchors control. Incorrect processing can lead to the practice of slamming where an attacker changes the set of trusted anchors in order to weaken security.
Publish Trust Anchorsコントロールを加工処理するとき、極端な注意は働かなければなりません。 不正確な処理はセキュリティを弱めるために攻撃者が信じられたアンカーのセットを変えるところにぶつかる習慣に通じることができます。
One method of controlling the use of the Publish Trust Anchors control is as follows. The client needs to associate with each trust anchor accepted by the client the source of the trust anchor. Additionally, the client should associate with each trust anchor the types of messages for which the trust anchor is valid (i.e., is the trust anchor used for validating S/MIME messages, TLS, or CMC enrollment messages?).
Publish Trust Anchorsコントロールの使用を制御する1つのメソッドは以下の通りです。 クライアントは、クライアントによって受け入れられるそれぞれの信頼アンカーに信頼アンカーの源を関連づける必要があります。 さらに、クライアントは信頼アンカーが有効であるメッセージのタイプをそれぞれの信頼アンカーに関連づけるべきです(すなわち、信頼アンカーはS/MIMEメッセージ、TLS、またはCMC登録メッセージを有効にするのに使用されますか?)。
When a new message is received with a Publish Trust Anchors control, the client would accept the set of new trust anchors for specific applications only if the signature validates, the signer of the message has the required policy approval for updating the trust anchors, and local policy also would allow updating the trust anchors.
Publish Trust Anchorsコントロールで新しいメッセージを受け取るとき、クライアントが署名である場合にだけ特定のアプリケーションのために新しい信頼アンカーのセットを受け入れるだろう、有効にする、メッセージの署名者には、信頼アンカーをアップデートすることへの必要な方針承認があって、ローカルの方針も、信頼アンカーをアップデートするのを許容するでしょう。
The CMS AuthenticatedData structure provides message integrity, it does not provide message authentication in all cases. When using MACs in this document the following restrictions need to be observed. All messages should be for a single entity. If two entities are placed in a single message, the entities can generate new messages that have a valid MAC and might be assumed to be from the original message sender. All entities that have access to the shared-secret can generate messages that will have a successful MAC validation. This means that care must be taken to keep this value secret. Whenever possible, the SignedData structure should be used in preference to the AuthenticatedData structure.
CMS AuthenticatedData構造はメッセージの保全を供給して、それはすべてのケースに通報認証を供給しません。 本書ではMACsを使用するとき、以下の制限は、観測される必要があります。 すべてのメッセージが単一体のためのものであるべきです。 2つの実体がただ一つのメッセージに置かれるなら、実体は、有効なMACを持っている新しいメッセージを生成することができて、オリジナルのメッセージ送付者からあると思われるかもしれません。 共有秘密キーに近づく手段を持っているすべての実体がうまくいっているMAC合法化を持っているメッセージを生成することができます。 これは、この値を秘密にするために注意しなければならないことを意味します。 可能であるときはいつも、SignedData構造はAuthenticatedData構造に優先して使用されるべきです。
9. IANA Considerations
9. IANA問題
This document defines a number of control objects. These are identified by Object Identifiers (OIDs). The objects are defined from an arc delegated by IANA to the PKIX Working Group. No further action by IANA is necessary for this document or any anticipated updates.
このドキュメントは多くのコントロールオブジェクトを定義します。 これらはObject Identifiers(OIDs)によって特定されます。 オブジェクトはIANAによって代表として派遣されたアークからPKIX作業部会まで定義されます。 IANAによるさらなるどんな動作もこのドキュメントかどんな予期されたアップデートにも必要ではありません。
Schaad & Myers Standards Track [Page 62] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[62ページ]: 2008年6月を構造化します。
10. Acknowledgments
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リュウとジェフ・ワインスタインの参加に感謝しています。
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. 引用規格
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, July 2004.
[cm] Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、2004年7月。
[CRMF] Schaad, J., "Internet X.509 Certification Request
Message Format", RFC 4211, January 2005.
[CRMF] Schaad、J.、「インターネットX.509証明要求メッセージ形式」、RFC4211、2005年1月。
[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月。
[PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax
v1.5", RFC 2314, October 1997.
[PKCS10]Kaliski、B.、「PKCS#10:」 証明Request Syntax v1.5"、1997年10月のRFC2314。
Note that this version of PKCS #10 is used for
compatibility with the use of 1988 ASN.1 syntax. An
effort is currently underway in the PKIX working group
to update to use 2003 ASN.1 syntax.
PKCS#10のこのバージョンが1988年のASN.1構文の使用との互換性に使用されることに注意してください。 取り組みは現在、2003ASN.1構文を使用するためにアップデートするPKIXワーキンググループで進行中です。
[PKIXCERT] Housley, R., Ford, W., Polk, W., and D. Solo,
"Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile",
RFC 3280, April 2002.
[PKIXCERT] Housley、R.、フォード、W.、ポーク、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、BCP14、1997年3月。
11.2. Informative References
11.2. 有益な参照
[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月。
[CMC-COMPL] Schaad, J. and M. Myers, "Certificate Management
Messages over CMS (CMC): Compliance Requirements",
RFC 5274, June 2008.
[CMC-COMPL] Schaad、J.、およびM.マイアーズ、「cm(CMC)の上で管理メッセージを証明してください」 「承諾要件」、RFC5274、2008年6月。
Schaad & Myers Standards Track [Page 63] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[63ページ]: 2008年6月を構造化します。
[PASSWORD] Burr, W., Dodson, D., and W. Polk, "Electronic
Authentication Guideline", NIST SP 800-63, April 2006.
[パスワード]ばりとW.とダドソン、D.とW.ポーク、「電子認証ガイドライン」、NIST SP800-63、2006年4月。
[RANDOM] Eastlake, 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106,
RFC 4086, June 2005.
[無作為]のイーストレークと3番目、D.、シラー、J.とS.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。
[SMALL-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月)。
[X942] Rescorla, E., "Diffie-Hellman Key Agreement Method",
RFC 2631, June 1999.
[X942] レスコラ、E.、「ディフィー-ヘルマンの主要な協定メソッド」、RFC2631、1999年6月。
[RFC2797] Myers, M., Liu, X., Schaad, J., and J. Weinstein,
"Certificate Management Messages over CMS", RFC 2797,
April 2000.
2000年4月の[RFC2797]マイアーズとM.とリュウとX.とSchaad、J.とJ.ワインスタイン、「cmの上の証明書管理メッセージ」RFC2797。
Schaad & Myers Standards Track [Page 64] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[64ページ]: 2008年6月を構造化します。
Appendix A. ASN.1 Module
付録A.ASN.1モジュール
EnrollmentMessageSyntax
{ iso(1) identified-organization(3) dod(4) internet(1)
security(5) mechansims(5) pkix(7) id-mod(0) id-mod-cmc2002(23) }
EnrollmentMessageSyntaxiso(1)の特定された組織(3)dod(4)インターネット(1)セキュリティ(5)mechansims(5) pkix(7)イドモッズ(0)イドモッズcmc2002(23)
DEFINITIONS IMPLICIT TAGS ::= BEGIN
定義、内在しているタグ:、:= 始まってください。
-- EXPORTS All -- -- The types and values defined in this module are exported for use -- in the other ASN.1 modules. Other applications may use them for -- their own purposes.
-- EXPORTS All----このモジュールで定義されたタイプと値は他のASN.1モジュールにおける使用のためにエクスポートされます。 アプリケーションがそれらを使用するかもしれないもう一方--それら自身の目的。
IMPORTS
輸入
-- PKIX Part 1 - Implicit From [PKIXCERT]
GeneralName, CRLReason, ReasonFlags
FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit(19)}
-- PKIX1Implicit88からの[PKIXCERT]GeneralName、CRLReason、ReasonFlagsからの暗黙のPKIX第1部iso(1)の特定されて組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イド-pkix1暗黙の(19)
-- PKIX Part 1 - Explicit From [PKIXCERT]
AlgorithmIdentifier, Extension, Name, CertificateSerialNumber
FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18)}
-- PKIX1Explicit88からの[PKIXCERT]AlgorithmIdentifier、拡大、名前、CertificateSerialNumberから明白なPKIX第1部iso(1)の特定されて組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イド-pkix1明白な(18)
-- Cryptographic Message Syntax FROM [CMS]
ContentInfo, Attribute, IssuerAndSerialNumber
FROM CryptographicMessageSyntax2004 { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
modules(0) cms-2004(24)}
-- CryptographicMessageSyntax2004からの[cm]ContentInfo、属性、IssuerAndSerialNumberからの暗号のメッセージ構文iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)cm-2004(24)
-- CRMF FROM [CRMF]
CertReqMsg, PKIPublicationInfo, CertTemplate
FROM PKIXCRMF-2005 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-crmf2005(36)};
-- CRMF FROM[CRMF]CertReqMsg、PKIPublicationInfo、CertTemplate FROM PKIXCRMF-2005、iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イドモッズcrmf2005(36)。
-- Global Types
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The content of this type conforms to RFC 2279.
-- グローバルなタイプUTF8String:、:= [UNIVERSAL12] IMPLICIT OCTET STRING--このタイプの内容はRFC2279に従います。
Schaad & Myers Standards Track [Page 65] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[65ページ]: 2008年6月を構造化します。
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
イド-pkix OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)
id-cmc OBJECT IDENTIFIER ::= {id-pkix 7} -- CMC controls
id-cct OBJECT IDENTIFIER ::= {id-pkix 12} -- CMC content types
イド-cmc OBJECT IDENTIFIER:、:= イド-pkix7--CMCはイド-cct OBJECT IDENTIFIERを制御します:、:= イド-pkix12--CMC content type
-- The following controls have the type OCTET STRING
-- 以下のコントロールには、タイプOCTET STRINGがあります。
id-cmc-identityProof OBJECT IDENTIFIER ::= {id-cmc 3}
id-cmc-dataReturn OBJECT IDENTIFIER ::= {id-cmc 4}
id-cmc-regInfo OBJECT IDENTIFIER ::= {id-cmc 18}
id-cmc-responseInfo OBJECT IDENTIFIER ::= {id-cmc 19}
id-cmc-queryPending OBJECT IDENTIFIER ::= {id-cmc 21}
id-cmc-popLinkRandom OBJECT IDENTIFIER ::= {id-cmc 22}
id-cmc-popLinkWitness OBJECT IDENTIFIER ::= {id-cmc 23}
イド-cmc-identityProofオブジェクト識別子:、:= イド-cmc3イド-cmc-dataReturnオブジェクト識別子:、:= イド-cmc4イド-cmc-regInfoオブジェクト識別子:、:= イド-cmc18イド-cmc-responseInfoオブジェクト識別子:、:= イド-cmc19イド-cmc-queryPendingオブジェクト識別子:、:= イド-cmc21イド-cmc-popLinkRandomオブジェクト識別子:、:= イド-cmc22イド-cmc-popLinkWitnessオブジェクト識別子:、:= イド-cmc23
-- The following controls have the type UTF8String
-- 以下のコントロールには、タイプUTF8Stringがあります。
id-cmc-identification OBJECT IDENTIFIER ::= {id-cmc 2}
イドcmc識別OBJECT IDENTIFIER:、:= イド-cmc2
-- The following controls have the type INTEGER
-- 以下のコントロールには、タイプINTEGERがあります。
id-cmc-transactionId OBJECT IDENTIFIER ::= {id-cmc 5}
イド-cmc-transactionIdオブジェクト識別子:、:= イド-cmc5
-- The following controls have the type OCTET STRING
-- 以下のコントロールには、タイプOCTET STRINGがあります。
id-cmc-senderNonce OBJECT IDENTIFIER ::= {id-cmc 6}
id-cmc-recipientNonce OBJECT IDENTIFIER ::= {id-cmc 7}
イド-cmc-senderNonceオブジェクト識別子:、:= イド-cmc6イド-cmc-recipientNonceオブジェクト識別子:、:= イド-cmc7
-- This is the content type used for a request message in the protocol
-- これはプロトコルの要求メッセージに使用されるcontent typeです。
id-cct-PKIData OBJECT IDENTIFIER ::= { id-cct 2 }
イド-cct-PKIDataオブジェクト識別子:、:= イド-cct2
PKIData ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
PKIData:、:= 系列TaggedAttributeのcontrolSequence系列サイズ(0..MAX)、TaggedRequestのreqSequence系列サイズ(0..MAX)、TaggedContentInfoのcmsSequence系列サイズ(0..MAX)、OtherMsgのotherMsgSequence系列サイズ(0..MAX)
bodyIdMax INTEGER ::= 4294967295
bodyIdMax整数:、:= 4294967295
BodyPartID ::= INTEGER(0..bodyIdMax)
BodyPartID:、:= 整数(0..bodyIdMax)
Schaad & Myers Standards Track [Page 66] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[66ページ]: 2008年6月を構造化します。
TaggedAttribute ::= SEQUENCE {
bodyPartID BodyPartID,
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue
}
TaggedAttribute:、:= 系列bodyPartID BodyPartID、attrTypeオブジェクト識別子、AttributeValueのattrValuesセット
AttributeValue ::= ANY
AttributeValue:、:= 少しも
TaggedRequest ::= CHOICE {
tcr [0] TaggedCertificationRequest,
crm [1] CertReqMsg,
orm [2] SEQUENCE {
bodyPartID BodyPartID,
requestMessageType OBJECT IDENTIFIER,
requestMessageValue ANY DEFINED BY requestMessageType
}
}
TaggedRequest:、:= 選択tcr[0]TaggedCertificationRequest、crm[1]CertReqMsg、orm[2]SEQUENCE、bodyPartID BodyPartID、requestMessageType OBJECT IDENTIFIER、requestMessageValue、どんなDEFINED BY requestMessageType
TaggedCertificationRequest ::= SEQUENCE {
bodyPartID BodyPartID,
certificationRequest CertificationRequest
}
TaggedCertificationRequest:、:= 系列bodyPartID BodyPartID、certificationRequest CertificationRequest
CertificationRequest ::= SEQUENCE {
certificationRequestInfo SEQUENCE {
version INTEGER,
subject Name,
subjectPublicKeyInfo SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING },
attributes [0] IMPLICIT SET OF Attribute },
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING
}
CertificationRequest:、:= 系列certificationRequestInfo SEQUENCE、バージョンINTEGER、Nameをかけてください、subjectPublicKeyInfo SEQUENCE、アルゴリズムAlgorithmIdentifier、subjectPublicKey BIT STRINGが[0] IMPLICIT SET OF Attributeを結果と考える、signatureAlgorithm AlgorithmIdentifier、署名BIT STRING
TaggedContentInfo ::= SEQUENCE {
bodyPartID BodyPartID,
contentInfo ContentInfo
}
TaggedContentInfo:、:= 系列bodyPartID BodyPartID、contentInfo ContentInfo
OtherMsg ::= SEQUENCE {
bodyPartID BodyPartID,
otherMsgType OBJECT IDENTIFIER,
otherMsgValue ANY DEFINED BY otherMsgType }
OtherMsg:、:= 系列bodyPartID BodyPartID、otherMsgValueがotherMsgTypeで少しも定義したotherMsgTypeオブジェクト識別子
Schaad & Myers Standards Track [Page 67] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[67ページ]: 2008年6月を構造化します。
-- This defines the response message in the protocol
id-cct-PKIResponse OBJECT IDENTIFIER ::= { id-cct 3 }
-- これはプロトコルイド-cct-PKIResponse OBJECT IDENTIFIERの応答メッセージを定義します:、:= イド-cct3
ResponseBody ::= PKIResponse
ResponseBody:、:= PKIResponse
PKIResponse ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
PKIResponse:、:= 系列、TaggedAttributeのcontrolSequence系列サイズ(0..MAX)、TaggedContentInfoのcmsSequence系列サイズ(0..MAX)、OtherMsgのotherMsgSequence系列サイズ(0..MAX)
}
}
-- Used to return status state in a response
-- 応答で状態状態を返すために、使用されます。
id-cmc-statusInfo OBJECT IDENTIFIER ::= {id-cmc 1}
イド-cmc-statusInfoオブジェクト識別子:、:= イド-cmc1
CMCStatusInfo ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF BodyPartID,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo } OPTIONAL
}
CMCStatusInfo:、:= 系列cMCStatus CMCStatus、BodyPartIDのbodyList系列サイズ(1..MAX)、任意のstatusString UTF8String otherInfo選択、failInfo CMCFailInfo、pendInfo PendInfo、任意
PendInfo ::= SEQUENCE {
pendToken OCTET STRING,
pendTime GeneralizedTime
}
PendInfo:、:= 系列pendToken八重奏ストリング、pendTime GeneralizedTime
CMCStatus ::= INTEGER {
success (0),
failed (2),
pending (3),
noSupport (4),
confirmRequired (5),
popRequired (6),
partial (7)
}
CMCStatus:、:= 整数成功(0)、(3)、noSupport(4)、confirmRequired(5)、popRequired(6)、部分的な(7)まで(2)に失敗します。
-- Note: -- The spelling of unsupportedExt is corrected in this version. -- In RFC 2797, it was unsuportedExt.
-- 以下に注意してください。 -- unsupportedExtのスペルはこのバージョンで修正されます。 -- RFC2797では、それはunsuportedExtでした。
Schaad & Myers Standards Track [Page 68] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[68ページ]: 2008年6月を構造化します。
CMCFailInfo ::= INTEGER {
badAlg (0),
badMessageCheck (1),
badRequest (2),
badTime (3),
badCertId (4),
unsupportedExt (5),
mustArchiveKeys (6),
badIdentity (7),
popRequired (8),
popFailed (9),
noKeyReuse (10),
internalCAError (11),
tryLater (12),
authDataFail (13)
}
CMCFailInfo:、:= 整数badAlg(0)、badMessageCheck(1)、badRequest(2)、badTime(3)、badCertId(4)、unsupportedExt(5)、mustArchiveKeys(6)、badIdentity(7)、popRequired(8)popFailed(9)、noKeyReuse(10)、internalCAError(11)、tryLater(12)、authDataFail(13)
-- Used for RAs to add extensions to certification requests
id-cmc-addExtensions OBJECT IDENTIFIER ::= {id-cmc 8}
-- 使用されて、RAsが証明に拡大を加えるのがイド-cmc-addExtensions OBJECT IDENTIFIERを要求します:、:= イド-cmc8
AddExtensions ::= SEQUENCE {
pkiDataReference BodyPartID,
certReferences SEQUENCE OF BodyPartID,
extensions SEQUENCE OF Extension
}
AddExtensions:、:= 系列pkiDataReference BodyPartID、certReferences SEQUENCE OF BodyPartID、拡大SEQUENCE OF Extension
id-cmc-encryptedPOP OBJECT IDENTIFIER ::= {id-cmc 9}
id-cmc-decryptedPOP OBJECT IDENTIFIER ::= {id-cmc 10}
イド-cmc-encryptedPOPオブジェクト識別子:、:= イド-cmc9イド-cmc-decryptedPOPオブジェクト識別子:、:= イド-cmc10
EncryptedPOP ::= SEQUENCE {
request TaggedRequest,
cms ContentInfo,
thePOPAlgID AlgorithmIdentifier,
witnessAlgID AlgorithmIdentifier,
witness OCTET STRING
}
EncryptedPOP:、:= 系列TaggedRequest(cm ContentInfo、thePOPAlgID AlgorithmIdentifier、witnessAlgID AlgorithmIdentifier)がOCTET STRINGを目撃するよう要求してください。
DecryptedPOP ::= SEQUENCE {
bodyPartID BodyPartID,
thePOPAlgID AlgorithmIdentifier,
thePOP OCTET STRING
}
DecryptedPOP:、:= 系列bodyPartID BodyPartID、thePOPAlgID AlgorithmIdentifier、thePOP八重奏ストリング
id-cmc-lraPOPWitness OBJECT IDENTIFIER ::= {id-cmc 11}
イド-cmc-lraPOPWitnessオブジェクト識別子:、:= イド-cmc11
Schaad & Myers Standards Track [Page 69] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[69ページ]: 2008年6月を構造化します。
LraPopWitness ::= SEQUENCE {
pkiDataBodyid BodyPartID,
bodyIds SEQUENCE OF BodyPartID
}
LraPopWitness:、:= 系列pkiDataBodyid BodyPartID、BodyPartIDのbodyIds系列
--
id-cmc-getCert OBJECT IDENTIFIER ::= {id-cmc 15}
-- イド-cmc-getCertオブジェクト識別子:、:= イド-cmc15
GetCert ::= SEQUENCE {
issuerName GeneralName,
serialNumber INTEGER }
GetCert:、:= 系列issuerName GeneralName、serialNumber整数
id-cmc-getCRL OBJECT IDENTIFIER ::= {id-cmc 16}
イド-cmc-getCRLオブジェクト識別子:、:= イド-cmc16
GetCRL ::= SEQUENCE {
issuerName Name,
cRLName GeneralName OPTIONAL,
time GeneralizedTime OPTIONAL,
reasons ReasonFlags OPTIONAL }
GetCRL:、:= 系列issuerName Name(cRLName GeneralName OPTIONAL、時間GeneralizedTime OPTIONAL)はReasonFlags OPTIONALを推論します。
id-cmc-revokeRequest OBJECT IDENTIFIER ::= {id-cmc 17}
イド-cmc-revokeRequestオブジェクト識別子:、:= イド-cmc17
RevokeRequest ::= SEQUENCE {
issuerName Name,
serialNumber INTEGER,
reason CRLReason,
invalidityDate GeneralizedTime OPTIONAL,
passphrase OCTET STRING OPTIONAL,
comment UTF8String OPTIONAL }
RevokeRequest:、:= 系列issuerName Name(serialNumber INTEGER)はCRLReasonを推論して、invalidityDate GeneralizedTime OPTIONAL(パスフレーズOCTET STRING OPTIONAL)はUTF8String OPTIONALについて論評します。
id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= {id-cmc 24}
イド-cmc-confirmCertAcceptanceオブジェクト識別子:、:= イド-cmc24
CMCCertId ::= IssuerAndSerialNumber
CMCCertId:、:= IssuerAndSerialNumber
-- The following is used to request V3 extensions be added to a -- certificate
-- 以下はV3拡張子がaに加えられるよう要求するのに使用されます--、証明書
id-ExtensionReq OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) 14}
イド-ExtensionReqオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9)14をメンバーと同じくらい具体化させます。
ExtensionReq ::= SEQUENCE SIZE (1..MAX) OF Extension
ExtensionReq:、:= 拡大の系列サイズ(1..MAX)
-- The following exists to allow Diffie-Hellman Certification Requests -- Messages to be well-formed
-- 以下はディフィー-ヘルマンCertification Requestsを許容するために存在しています--整形式であるために、通信します。
id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2}
イド-alg-noSignatureオブジェクト識別子:、:= イド-pkixイド-alg(6)2
NoSignatureValue ::= OCTET STRING
NoSignatureValue:、:= 八重奏ストリング
Schaad & Myers Standards Track [Page 70] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[70ページ]: 2008年6月を構造化します。
-- Unauthenticated attribute to carry removable data. -- This could be used in an update of "CMC Extensions: Server Side -- Key Generation and Key Escrow" (February 2005) and in other -- documents.
-- 移動可能なデータを運ぶために属性をUnauthenticatedしました。 -- アップデートにこれを使用できた、「CMC拡張子:」 (2005年2月)ともう一方における「サーバSide--GenerationとKey Escrowを合わせてください」--ドキュメント。
id-aa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2)}
id-aa-cmc-unsignedData OBJECT IDENTIFIER ::= {id-aa 34}
イド-aa OBJECT IDENTIFIER:、:= iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)、イド-aa-cmc-unsignedData OBJECT IDENTIFIER:、:= イド-aa34
CMCUnsignedData ::= SEQUENCE {
bodyPartPath BodyPartPath,
identifier OBJECT IDENTIFIER,
content ANY DEFINED BY identifier
}
CMCUnsignedData:、:= 系列bodyPartPath BodyPartPath、識別子OBJECT IDENTIFIER、満足しているANY DEFINED BY識別子
-- Replaces CMC Status Info --
-- CMC状態インフォメーションを置き換えます--
id-cmc-statusInfoV2 OBJECT IDENTIFIER ::= {id-cmc 25}
イド-cmc-statusInfoV2物の識別子:、:= イド-cmc25
CMCStatusInfoV2 ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF
BodyPartReference,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo,
extendedFailInfo SEQUENCE {
failInfoOID OBJECT IDENTIFIER,
failInfoValue AttributeValue
}
} OPTIONAL
}
CMCStatusInfoV2:、:= 系列cMCStatus CMCStatus、BodyPartReferenceのbodyList系列サイズ(1..MAX)、任意のstatusString UTF8String otherInfo選択、failInfo CMCFailInfo、pendInfo PendInfo、extendedFailInfoがfailInfoOID物の識別子、failInfoValue AttributeValueを配列する、任意
BodyPartReference ::= CHOICE {
bodyPartID BodyPartID,
bodyPartPath BodyPartPath
}
BodyPartReference:、:= 選択bodyPartID BodyPartID、bodyPartPath BodyPartPath
BodyPartPath ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
BodyPartPath:、:= BodyPartIDの系列サイズ(1..MAX)
Schaad & Myers Standards Track [Page 71] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[71ページ]: 2008年6月を構造化します。
-- Allow for distribution of trust anchors --
-- 信用アンカーの分配を考慮してください--
id-cmc-trustedAnchors OBJECT IDENTIFIER ::= {id-cmc 26}
イド-cmc-trustedAnchors物の識別子:、:= イド-cmc26
PublishTrustAnchors ::= SEQUENCE {
seqNumber INTEGER,
hashAlgorithm AlgorithmIdentifier,
anchorHashes SEQUENCE OF OCTET STRING
}
PublishTrustAnchors:、:= 系列seqNumber整数、hashAlgorithm AlgorithmIdentifier、八重奏ストリングのanchorHashes系列
id-cmc-authData OBJECT IDENTIFIER ::= {id-cmc 27}
イド-cmc-authData物の識別子:、:= イド-cmc27
AuthPublish ::= BodyPartID
AuthPublish:、:= BodyPartID
-- These two items use BodyPartList
id-cmc-batchRequests OBJECT IDENTIFIER ::= {id-cmc 28}
id-cmc-batchResponses OBJECT IDENTIFIER ::= {id-cmc 29}
-- これらの2つの項目がBodyPartListイド-cmc-batchRequests OBJECT IDENTIFIERを使用します:、:= イド-cmc28イド-cmc-batchResponses物の識別子:、:= イド-cmc29
BodyPartList ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
BodyPartList:、:= BodyPartIDの系列サイズ(1..MAX)
--
id-cmc-publishCert OBJECT IDENTIFIER ::= {id-cmc 30}
-- イド-cmc-publishCert物の識別子:、:= イド-cmc30
CMCPublicationInfo ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
certHashes SEQUENCE OF OCTET STRING,
pubInfo PKIPublicationInfo
}
CMCPublicationInfo:、:= 系列hashAlg AlgorithmIdentifier、八重奏ストリング、pubInfo PKIPublicationInfoのcertHashes系列
id-cmc-modCertTemplate OBJECT IDENTIFIER ::= {id-cmc 31}
イド-cmc-modCertTemplate物の識別子:、:= イド-cmc31
ModCertTemplate ::= SEQUENCE {
pkiDataReference BodyPartPath,
certReferences BodyPartList,
replace BOOLEAN DEFAULT TRUE,
certTemplate CertTemplate
}
ModCertTemplate:、:= 系列pkiDataReference BodyPartPath(certReferences BodyPartList)はBOOLEAN DEFAULT TRUE、certTemplate CertTemplateを取り替えます。
-- Inform follow on servers that one or more controls have already been -- processed
-- サーバに関して1つ以上のコントロールが既にありました--処理されることを尾行に知らせてください。
id-cmc-controlProcessed OBJECT IDENTIFIER ::= {id-cmc 32}
イド-cmc-controlProcessed物の識別子:、:= イド-cmc32
ControlsProcessed ::= SEQUENCE {
bodyList SEQUENCE SIZE(1..MAX) OF BodyPartReference
}
ControlsProcessed:、:= 系列BodyPartReferenceのbodyList系列サイズ(1..MAX)
Schaad & Myers Standards Track [Page 72] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[72ページ]: 2008年6月を構造化します。
-- Identity Proof control w/ algorithm agility
-- アルゴリズムの機敏さがあるアイデンティティProofコントロール
id-cmc-identityProofV2 OBJECT IDENTIFIER ::= { id-cmc 34 }
イド-cmc-identityProofV2物の識別子:、:= イド-cmc34
IdentifyProofV2 ::= SEQUENCE {
proofAlgID AlgorithmIdentifier,
macAlgId AlgorithmIdentifier,
witness OCTET STRING
}
IdentifyProofV2:、:= 系列proofAlgID AlgorithmIdentifier(macAlgId AlgorithmIdentifier)はOCTET STRINGを目撃します。
id-cmc-popLinkWitnessV2 OBJECT IDENTIFIER ::= { id-cmc 33 }
PopLinkWitnessV2 ::= SEQUENCE {
keyGenAlgorithm AlgorithmIdentifier,
macAlgorithm AlgorithmIdentifier,
witness OCTET STRING
}
イド-cmc-popLinkWitnessV2物の識別子:、:= イド-cmc33、PopLinkWitnessV2:、:= 系列keyGenAlgorithm AlgorithmIdentifier(macAlgorithm AlgorithmIdentifier)はOCTET STRINGを目撃します。
END
終わり
Schaad & Myers Standards Track [Page 73] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[73ページ]: 2008年6月を構造化します。
Appendix B. Enrollment Message Flows
付録B.登録メッセージ流れ
This section is informational. The purpose of this section is to present, in an abstracted version, the messages that would flow between the client and server for several different common cases.
このセクションは情報です。 このセクションの目的は放心しているバージョンに数回の異なったよくある例のためのクライアントとサーバの間を流れるメッセージを提示することです。
B.1. Request of a Signing Certificate
B.1。 署名証明書の要求
This section looks at the messages that would flow in the event that an enrollment is occurring for a signing-only key. If the certificate was designed for both signing and encryption, the only difference would be the key usage extension in the certification request.
このセクションは登録が調印だけキーのために起こっている場合流れるメッセージを見ます。 証明書が調印と暗号化の両方のために設計されるなら、唯一の違いは証明要求で主要な用法拡大でしょうに。
Message #2 from client to server:
クライアントからサーバまでのメッセージ#2:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIData
eContent
controlSequence
{102, id-cmc-identityProof, computed value}
{103, id-cmc-senderNonce, 10001}
reqSequence
certRequest
certReqId = 201
certTemplate
subject = My Proposed DN
publicKey = My Public Key
extensions
{id-ce-subjectPublicKeyIdentifier, 1000}
{id-ce-keyUsage, digitalSignature}
SignedData.SignerInfos
SignerInfo
sid.subjectKeyIdentifier = 1000
ContentInfo.contentTypeがイド-signedData ContentInfo.content SignedData.encapContentInfo eContentType=と等しい、イドct PKIData eContent controlSequence、102(イド-cmc-identityProof)が値を計算した、103、イド-cmc-senderNonce、10001、私の201certTemplate reqSequence certRequest certReqId=対象=Proposed DN publicKeyが私のPublic Key拡張子と等しい、イドCe subjectPublicKeyIdentifier、1000、イドCe keyUsage、digitalSignature、SignedData.SignerInfos SignerInfo sid.subjectKeyIdentifier=1000
Schaad & Myers Standards Track [Page 74] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[74ページ]: 2008年6月を構造化します。
Response from server to client:
サーバからクライアントまでの応答:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{102, id-cmc-statusInfoV2, {success, 201}}
{103, id-cmc-senderNonce, 10005}
{104, id-cmc-recipientNonce, 10001}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
ContentInfo.contentTypeがイド-signedData ContentInfo.content SignedData.encapContentInfo eContentType=と等しい、イドct PKIResponse eContent controlSequence、102、イド-cmc-statusInfoV2、成功、201、103、イド-cmc-senderNonce、10005、104、イド-cmc-recipientNonce、10001、証明書Newlyはカリフォルニアのそばで証明書Other証明書SignedData.SignerInfos Signedを発行しました。
B.2. Single Certification Request, But Modified by RA
B.2。 RAによって要求ですが、変更されたただ一つの証明
This section looks at the messages that would flow in the event that an enrollment has one RA in the middle of the data flow. That RA will modify the certification request before passing it on to the CA.
このセクションは登録がデータフローの中央に1RAを持っている場合流れるメッセージを見ます。 カリフォルニアにそれを向かわせる前に、そのRAは証明要求を変更するでしょう。
Message from client to RA:
クライアントからRAまでのメッセージ:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIData
eContent
controlSequence
{102, id-cmc-identityProof, computed value}
{103, id-cmc-senderNonce, 10001}
reqSequence
certRequest
certReqId = 201
certTemplate
subject = My Proposed DN
publicKey = My Public Key
extensions
{id-ce-subjectPublicKeyIdentifier, 1000}
{id-ce-keyUsage, digitalSignature}
SignedData.SignerInfos
SignerInfo
sid.subjectKeyIdentifier = 1000
ContentInfo.contentTypeがイド-signedData ContentInfo.content SignedData.encapContentInfo eContentType=と等しい、イドct PKIData eContent controlSequence、102(イド-cmc-identityProof)が値を計算した、103、イド-cmc-senderNonce、10001、私の201certTemplate reqSequence certRequest certReqId=対象=Proposed DN publicKeyが私のPublic Key拡張子と等しい、イドCe subjectPublicKeyIdentifier、1000、イドCe keyUsage、digitalSignature、SignedData.SignerInfos SignerInfo sid.subjectKeyIdentifier=1000
Schaad & Myers Standards Track [Page 75] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[75ページ]: 2008年6月を構造化します。
Message from RA to CA:
RAからカリフォルニアまでのメッセージ:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIData
eContent
controlSequence
{ 102, id-cmc-batchRequests, { 1, 2} }
{ 103, id-cmc-addExtensions,
{ {1, 201, {id-ce-certificatePolicies, anyPolicy}}
{1, 201, {id-ce-subjectAltName, {extension data}}
{2, XXX, {id-ce-subjectAltName, {extension data}}}
The Value XXX is not known here; it would
reference into the second client request,
which is not displayed above.
cmsSequence
{ 1, <Message from client to RA #1> }
{ 2, <Message from client to RA #2> }
SignedData.SignerInfos
SignerInfo
sid = RA key.
2番目のクライアント要求にそれに参照をつけて、どれがあるかが1、クライアントからRA#1>までの<Messageを. cmsSequenceの上に表示しなかった、2、クライアントからRA#2>までの<Message、SignedData.SignerInfos SignerInfo sid=RAキー。
Schaad & Myers Standards Track [Page 76] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[76ページ]: 2008年6月を構造化します。
Response from CA to RA:
カリフォルニアからRAまでの応答:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{102, id-cmc-BatchResponse, {999, 998}}
ContentInfo.contentTypeがイド-signedData ContentInfo.content SignedData.encapContentInfo eContentType=と等しい、イドct PKIResponse eContent controlSequence102、イド-cmc-BatchResponse、999、998
{103, id-cmc-statusInfoV2, {failed, 2, badIdentity}}
cmsSequence
{ bodyPartID = 999
contentInfo
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{102, id-cmc-statusInfoV2, {success, 201}}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
}
{ bodyPartID = 998,
contentInfo
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{102, id-cmc-statusInfoV2, {failure, badAlg}}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
}
SignedData.SignerInfos
Signed by CA
103、イド-cmc-statusInfoV2、失敗、2、badIdentity、cmsSequence、999bodyPartID=contentInfo ContentInfo.contentTypeがイド-signedData ContentInfo.content SignedData.encapContentInfo eContentType=と等しい、イドct PKIResponse eContent controlSequence、102、イド-cmc-statusInfoV2、成功、201、証明書Newlyはカリフォルニアのそばで証明書Other証明書SignedData.SignerInfos Signedを発行しました; bodyPartID=998、contentInfo ContentInfo.contentTypeがイド-signedData ContentInfo.content SignedData.encapContentInfo eContentType=と等しい、イドct PKIResponse eContent controlSequence、102、イド-cmc-statusInfoV2、失敗、証明書Newlyがカリフォルニアで証明書Other証明書SignedData.SignerInfos Signedを発行したbadAlg、SignedData; カリフォルニアによってサインされたSignerInfos
Schaad & Myers Standards Track [Page 77] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[77ページ]: 2008年6月を構造化します。
Response from RA to client:
RAからクライアントまでの応答:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{102, id-cmc-statusInfoV2, {success, 201}}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
ContentInfo.contentTypeがイド-signedData ContentInfo.content SignedData.encapContentInfo eContentType=と等しい、イドct PKIResponse eContent controlSequence、102、イド-cmc-statusInfoV2、成功、201、証明書Newlyはカリフォルニアのそばで証明書Other証明書SignedData.SignerInfos Signedを発行しました。
B.3. Direct POP for an RSA Certificate
B.3。 RSA証明書のためのダイレクトPOP
This section looks at the messages that would flow in the event that an enrollment is done for an encryption only certificate using an direct POP method. For simplicity, it is assumed that the certification requester already has a signing-only certificate.
このセクションは、暗号化のために登録する場合流れるメッセージがダイレクトPOP方法を使用することで証明するだけであるのを見ます。 簡単さにおいて、証明リクエスタには調印だけ証明書が既にあると思われます。
The fact that a second round-trip is required is implicit rather than explicit. The server determines this based on the fact that no other POP exists for the certification request.
aが後援する事実、往復、必要である、明白であるというよりむしろ、暗黙です。 サーバは他のPOPが全く証明要求のために存在していないという事実に基づくこれを決定します。
Schaad & Myers Standards Track [Page 78] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[78ページ]: 2008年6月を構造化します。
Message #1 from client to server:
クライアントからサーバまでのメッセージ#1:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIData
eContent
controlSequence
{102, id-cmc-transactionId, 10132985123483401}
{103, id-cmc-senderNonce, 10001}
{104, id-cmc-dataReturn, <packet of binary data identifying
where the key in question is.>}
reqSequence
certRequest
certReqId = 201
certTemplate
subject = <My DN from my signing cert>
publicKey = My Public Key
extensions
{id-ce-keyUsage, keyEncipherment}
popo
keyEncipherment
subsequentMessage
SignedData.SignerInfos
SignerInfo
Signed by requester's signing cert
ContentInfo.contentTypeはイド-signedData ContentInfo.content SignedDataと等しいです; encapContentInfo eContentTypeが等しい、イドct PKIData eContent controlSequence、102、イド-cmc-transactionId、10132985123483401、103、イド-cmc-senderNonce、10001、104、イド-cmc-dataReturn(問題のキーがどこにあるかを特定する2進のデータの<パケット)、>、私がPublic Key本命>publicKey=拡張子に調印するのでreqSequence certRequest certReqIdが<201certTemplate対象=My DNと等しい、イドCe keyUsage、keyEncipherment、popo keyEncipherment subsequentMessage SignedData; リクエスタの調印本命によるSignerInfos SignerInfo Signed
Response #1 from server to client:
サーバからクライアントまでの応答#1:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{101, id-cmc-statusInfoV2, {failed, 201, popRequired}}
{102, id-cmc-transactionId, 10132985123483401}
{103, id-cmc-senderNonce, 10005}
{104, id-cmc-recipientNonce, 10001}
{105, id-cmc-encryptedPOP, {
request {
certRequest
certReqId = 201
certTemplate
subject = <My DN from my signing cert>
publicKey = My Public Key
extensions
{id-ce-keyUsage, keyEncipherment}
ContentInfo.contentTypeがイド-signedData ContentInfo.content SignedData.encapContentInfo eContentType=と等しい、イドct PKIResponse eContent controlSequence、101、イド-cmc-statusInfoV2、失敗、201、popRequired、102、イド-cmc-transactionId、10132985123483401、103、イド-cmc-senderNonce、10005、104、イド-cmc-recipientNonce、10001、105、イド-cmc-encryptedPOP、要求、私がPublic Key本命>publicKey=拡張子に調印するので、certRequest certReqIdは<201certTemplate対象=My DNと等しいです。イドCe keyUsage、keyEncipherment
Schaad & Myers Standards Track [Page 79] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[79ページ]: 2008年6月を構造化します。
popo
keyEncipherment
subsequentMessage
}
cms
contentType = id-envelopedData
content
recipientInfos.riid.issuerSerialNumber = <NULL, 201>
encryptedContentInfo
eContentType = id-data
eContent = <Encrypted value of 'y'>
thePOPAlgID = HMAC-SHA1
witnessAlgID = SHA-1
witness <hashed value of 'y'>}}
{106, id-cmc-dataReturn, <packet of binary data identifying
where the key in question is.>}
certificates
Other certificates (optional)
SignedData.SignerInfos
Signed by CA
popo keyEncipherment subsequentMessage、<イド-envelopedData cm contentType=内容recipientInfos.riid.issuerSerialNumber=NULL、SHA-1目撃者'y'>thePOPAlgID=HMAC-SHA1 witnessAlgID=<の<Encryptedイドデータ201>encryptedContentInfo eContentType=eContent=価値が'y'>の値を論じ尽くした、' 106、イド-cmc-dataReturn(問題のキーがどこにあるかを特定する2進のデータの<パケット)、>、カリフォルニアのそばの証明書Other証明書(任意の)SignedData.SignerInfos Signed
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIData
eContent
controlSequence
{102, id-cmc-transactionId, 10132985123483401}
{103, id-cmc-senderNonce, 100101}
{104, id-cmc-dataReturn, <packet of binary data identifying
where the key in question is.>}
{105, id-cmc-recipientNonce, 10005}
{107, id-cmc-decryptedPOP, {
bodyPartID 201,
thePOPAlgID HMAC-SHA1,
thePOP <HMAC computed value goes here>}}
reqSequence
certRequest
certReqId = 201
certTemplate
subject = <My DN from my signing cert>
publicKey = My Public Key
extensions
{id-ce-keyUsage, keyEncipherment}
popo
keyEncipherment
subsequentMessage
ContentInfo.contentTypeはイド-signedData ContentInfo.content SignedDataと等しいです; encapContentInfo eContentTypeが等しい、イドct PKIData eContent controlSequence、102、イド-cmc-transactionId、10132985123483401、103、イド-cmc-senderNonce、100101、104、イド-cmc-dataReturn(問題のキーがどこにあるかを特定する2進のデータの<パケット)、>、105、イド-cmc-recipientNonce、10005; 107、イド-cmc-decryptedPOP、bodyPartID201、thePOPAlgID HMAC-SHA1、HMACが計算した<がここに行くのを評価するthePOP、>、私がPublic Key本命>publicKey=拡張子に調印するのでreqSequence certRequest certReqIdが<201certTemplate対象=My DNと等しい、イドCe keyUsage、keyEncipherment、popo keyEncipherment subsequentMessage
Schaad & Myers Standards Track [Page 80] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[80ページ]: 2008年6月を構造化します。
SignedData.SignerInfos
SignerInfo
Signed by requester's signing cert
リクエスタの調印本命によるSignedData.SignerInfos SignerInfo Signed
Response #2 from server to client:
サーバからクライアントまでの応答#2:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{101, id-cmc-transactionId, 10132985123483401}
{102, id-cmc-statusInfoV2, {success, 201}}
{103, id-cmc-senderNonce, 10019}
{104, id-cmc-recipientNonce, 100101}
{105, id-cmc-dataReturn, <packet of binary data identifying
where the key in question is.>}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
ContentInfo.contentTypeがイド-signedData ContentInfo.content SignedData.encapContentInfo eContentType=と等しい、イドct PKIResponse eContent controlSequence、101、イド-cmc-transactionId、10132985123483401、102、イド-cmc-statusInfoV2、成功、201、103、イド-cmc-senderNonce、10019、104、イド-cmc-recipientNonce、100101、105、イド-cmc-dataReturn(問題のキーがどこにあるかを特定する2進のデータの<パケット)、>、証明書Newlyはカリフォルニアのそばで証明書Other証明書SignedData.SignerInfos Signedを発行しました。
Appendix C. Production of Diffie-Hellman Public Key Certification
Requests
ディフィー-ヘルマンの公開鍵証明要求の付録C.生産
Part of a certification request is a signature over the request; Diffie-Hellman is a key agreement algorithm and cannot be used to directly produce the required signature object. [DH-POP] provides two ways to produce the necessary signature value. This document also defines a signature algorithm that does not provide a POP value, but can be used to produce the necessary signature value.
証明要求の一部が要求の上の署名です。 ディフィー-ヘルマンは、主要な協定アルゴリズムであり、直接必要な署名物を作り出すのに使用できません。 [DH-POP]は必要な署名値を生産する2つの方法を提供します。 また、このドキュメントはPOP値を提供しませんが、必要な署名値を生産するのに使用できる署名アルゴリズムを定義します。
C.1. No-Signature Signature Mechanism
C.1。 署名がない署名メカニズム
Key management (encryption/decryption) private keys cannot always be used to produce some type of signature value as they can be in a decrypt-only device. Certification requests require that the signature field be populated. This section provides a signature algorithm specifically for that purposes. The following object identifier and signature value are used to identify this signature type:
それらがaにあることができてタイプの署名価値を生産するのにいつもかぎ管理(暗号化/復号化)秘密鍵を使用できるというわけではない、解読する、-単に、装置。 証明要求は、署名分野が居住されるのを必要とします。 このセクションは特にその目的に署名アルゴリズムを提供します。 以下の物の識別子と署名値はこの署名タイプを特定するのに使用されます:
id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2}
イド-alg-noSignature物の識別子:、:= イド-pkixイド-alg(6)2
NoSignatureValue ::= OCTET STRING
NoSignatureValue:、:= 八重奏ストリング
Schaad & Myers Standards Track [Page 81] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[81ページ]: 2008年6月を構造化します。
The parameters for id-alg-noSignature MUST be present and MUST be encoded as NULL. NoSignatureValue contains the hash of the certification request. It is important to realize that there is no security associated with this signature type. If this signature type is on a certification request and the Certification Authority policy requires proof-of-possession of the private key, the POP mechanism defined in Section 6.7 MUST be used.
イド-alg-noSignatureのためのパラメタを存在していなければならなくて、NULLとしてコード化しなければなりません。 NoSignatureValueは証明要求の細切れ肉料理を含んでいます。 この署名タイプに関連しているどんなセキュリティもないとわかるのは重要です。 証明要求にはこの署名タイプがあって、認証局方針が秘密鍵所有物の証拠を必要とするなら、セクション6.7で定義されたPOPメカニズムを使用しなければなりません。
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 82] RFC 5272 CMC: Structures June 2008
Schaadとマイアーズ規格はRFC5272CMCを追跡します[82ページ]: 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 83]
Schaadとマイアーズ標準化過程[83ページ]
一覧
スポンサーリンク
