RFC4210 日本語訳
4210 Internet X.509 Public Key Infrastructure Certificate ManagementProtocol (CMP). C. Adams, S. Farrell, T. Kause, T. Mononen. September 2005. (Format: TXT=212013 bytes) (Obsoletes RFC2510) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Adams
Request for Comments: 4210 University of Ottawa
Obsoletes: 2510 S. Farrell
Category: Standards Track Trinity College Dublin
T. Kause
SSH
T. Mononen
SafeNet
September 2005
コメントを求めるワーキンググループC.アダムスの要求をネットワークでつないでください: 4210年のオタワ大学は以下を時代遅れにします。 2510秒間ファレルCategory: 標準化過程トリニティー・カレッジダブリンT.Kauseセキュアシェル (SSH)T.Mononen SafeNet2005年9月
Internet X.509 Public Key Infrastructure
Certificate Management Protocol (CMP)
インターネットX.509公開鍵暗号基盤証明書管理プロトコル(Cmp)
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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides on-line interactions between PKI components, including an exchange between a Certification Authority (CA) and a client system.
このドキュメントはインターネットX.509公開鍵暗号基盤(PKI)証明書Managementプロトコル(CMP)について説明します。 プロトコルメッセージはX.509v3証明書作成と管理のために定義されます。 CMPは認証局(カリフォルニア)とクライアントシステムの間の交換を含むPKIの部品の間のオンライン相互作用を供給します。
Table of Contents
目次
1. Introduction ....................................................5
2. Requirements ....................................................5
3. PKI Management Overview .........................................5
3.1. PKI Management Model .......................................6
3.1.1. Definitions of PKI Entities .........................6
3.1.1.1. Subjects and End Entities ..................6
3.1.1.2. Certification Authority ....................7
3.1.1.3. Registration Authority .....................7
3.1.2. PKI Management Requirements .........................8
3.1.3. PKI Management Operations ..........................10
4. Assumptions and Restrictions ...................................14
4.1. End Entity Initialization .................................14
1. 序論…5 2. 要件…5 3. PKIマネジメントの展望…5 3.1. PKI管理はモデル化されます…6 3.1.1. PKI実体の定義…6 3.1.1.1. 対象と終わりの実体…6 3.1.1.2. 証明権威…7 3.1.1.3. 登録局…7 3.1.2. PKI管理要件…8 3.1.3. PKI管理操作…10 4. 仮定と制限…14 4.1. 実体初期設定を終わらせてください…14
Adams, et al. Standards Track [Page 1] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[1ページ]。
4.2. Initial Registration/Certification ........................14
4.2.1. Criteria Used ......................................15
4.2.1.1. Initiation of Registration/Certification ..15
4.2.1.2. End Entity Message Origin Authentication ..15
4.2.1.3. Location of Key Generation ................15
4.2.1.4. Confirmation of Successful Certification ..16
4.2.2. Mandatory Schemes ..................................16
4.2.2.1. Centralized Scheme ........................16
4.2.2.2. Basic Authenticated Scheme ................17
4.3. Proof-of-Possession (POP) of Private Key ..................17
4.3.1. Signature Keys .....................................18
4.3.2. Encryption Keys ....................................18
4.3.3. Key Agreement Keys .................................19
4.4. Root CA Key Update ........................................19
4.4.1. CA Operator Actions ................................20
4.4.2. Verifying Certificates .............................21
4.4.2.1. Verification in Cases 1, 4, 5, and 8 ......22
4.4.2.2. Verification in Case 2 ....................22
4.4.2.3. Verification in Case 3 ....................23
4.4.2.4. Failure of Verification in Case 6 .........23
4.4.2.5. Failure of Verification in Case 7 .........23
4.4.3. Revocation - Change of CA Key ......................23
5. Data Structures ................................................24
5.1. Overall PKI Message .......................................24
5.1.1. PKI Message Header .................................24
5.1.1.1. ImplicitConfirm ...........................27
5.1.1.2. ConfirmWaitTime ...........................27
5.1.2. PKI Message Body ...................................27
5.1.3. PKI Message Protection .............................28
5.1.3.1. Shared Secret Information .................29
5.1.3.2. DH Key Pairs ..............................30
5.1.3.3. Signature .................................30
5.1.3.4. Multiple Protection .......................30
5.2. Common Data Structures ....................................31
5.2.1. Requested Certificate Contents .....................31
5.2.2. Encrypted Values ...................................31
5.2.3. Status codes and Failure Information for
PKI Messages .......................................32
5.2.4. Certificate Identification .........................33
5.2.5. Out-of-band root CA Public Key .....................33
5.2.6. Archive Options ....................................34
5.2.7. Publication Information ............................34
5.2.8. Proof-of-Possession Structures .....................34
5.2.8.1. Inclusion of the Private Key ..............35
5.2.8.2. Indirect Method ...........................35
5.2.8.3. Challenge-Response Protocol ...............35
5.2.8.4. Summary of PoP Options ....................37
4.2. 登録/証明に頭文字をつけてください…14 4.2.1. 使用される評価基準…15 4.2.1.1. 登録/証明の開始。15 4.2.1.2. 実体メッセージ発生源認証を終わらせてください。15 4.2.1.3. キー生成の位置…15 4.2.1.4. うまくいっている証明の確認。16 4.2.2. 義務的な体系…16 4.2.2.1. 体系を集結します…16 4.2.2.2. 基本的な認証された体系…17 4.3. 秘密鍵所有物の証拠(飛び出します)…17 4.3.1. 署名キー…18 4.3.2. 暗号化キー…18 4.3.3. 主要な協定キー…19 4.4. カリフォルニアの主要なアップデートを根づかせてください…19 4.4.1. カリフォルニアのオペレータ動作…20 4.4.2. 証明書について確かめます…21 4.4.2.1. 場合1、4、5、および8における検証…22 4.4.2.2. 場合2における検証…22 4.4.2.3. 場合3における検証…23 4.4.2.4. 場合6における検証の失敗…23 4.4.2.5. 場合7における検証の失敗…23 4.4.3. 取消し--カリフォルニアキーの変化…23 5. データ構造…24 5.1. 総合的なPKIメッセージ…24 5.1.1. PKIメッセージヘッダー…24 5.1.1.1. ImplicitConfirm…27 5.1.1.2. ConfirmWaitTime…27 5.1.2. PKIメッセージボディー…27 5.1.3. PKIメッセージ保護…28 5.1.3.1. 共有秘密キー情報…29 5.1.3.2. DHの主要なペア…30 5.1.3.3. 署名…30 5.1.3.4. 多重防護…30 5.2. 一般的なデータ構造…31 5.2.1. 証明書コンテンツを要求します…31 5.2.2. 値を暗号化します…31 5.2.3. PKI MessagesのためのステータスコードとFailure情報…32 5.2.4. 識別を証明してください…33 5.2.5. バンドの外では、カリフォルニアPublic Keyは根づきます…33 5.2.6. オプションを格納してください…34 5.2.7. 公表情報…34 5.2.8. 所有物の証拠構造…34 5.2.8.1. 秘密鍵の包含…35 5.2.8.2. 間接的なメソッド…35 5.2.8.3. チャレンジレスポンスプロトコル…35 5.2.8.4. 大衆的なオプションの概要…37
Adams, et al. Standards Track [Page 2] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[2ページ]。
5.3. Operation-Specific Data Structures ........................38
5.3.1. Initialization Request .............................38
5.3.2. Initialization Response ............................39
5.3.3. Certification Request ..............................39
5.3.4. Certification Response .............................39
5.3.5. Key Update Request Content .........................40
5.3.6. Key Update Response Content ........................41
5.3.7. Key Recovery Request Content .......................41
5.3.8. Key Recovery Response Content ......................41
5.3.9. Revocation Request Content .........................41
5.3.10. Revocation Response Content .......................42
5.3.11. Cross Certification Request Content ...............42
5.3.12. Cross Certification Response Content ..............42
5.3.13. CA Key Update Announcement Content ................42
5.3.14. Certificate Announcement ..........................43
5.3.15. Revocation Announcement ...........................43
5.3.16. CRL Announcement ..................................43
5.3.17. PKI Confirmation Content ..........................43
5.3.18. Certificate Confirmation Content ..................44
5.3.19. PKI General Message Content .......................44
5.3.19.1. CA Protocol Encryption Certificate .......44
5.3.19.2. Signing Key Pair Types ...................45
5.3.19.3. Encryption/Key Agreement Key Pair Types ..45
5.3.19.4. Preferred Symmetric Algorithm ............45
5.3.19.5. Updated CA Key Pair ......................45
5.3.19.6. CRL ......................................46
5.3.19.7. Unsupported Object Identifiers ...........46
5.3.19.8. Key Pair Parameters ......................46
5.3.19.9. Revocation Passphrase ....................46
5.3.19.10. ImplicitConfirm .........................46
5.3.19.11. ConfirmWaitTime .........................47
5.3.19.12. Original PKIMessage .....................47
5.3.19.13. Supported Language Tags .................47
5.3.20. PKI General Response Content ......................47
5.3.21. Error Message Content .............................47
5.3.22. Polling Request and Response ......................48
6. Mandatory PKI Management Functions .............................51
6.1. Root CA Initialization ....................................51
6.2. Root CA Key Update ........................................51
6.3. Subordinate CA Initialization .............................51
6.4. CRL production ............................................52
6.5. PKI Information Request ...................................52
6.6. Cross Certification .......................................52
6.6.1. One-Way Request-Response Scheme: ...................52
6.7. End Entity Initialization .................................54
6.7.1. Acquisition of PKI Information .....................54
6.7.2. Out-of-Band Verification of Root-CA Key ............55
6.8. Certificate Request .......................................55
5.3. 操作特有のデータ構造…38 5.3.1. 初期設定要求…38 5.3.2. 初期設定応答…39 5.3.3. 証明要求…39 5.3.4. 証明応答…39 5.3.5. 主要な更新要求内容…40 5.3.6. 主要なアップデート応答内容…41 5.3.7. キーリカバリー要求内容…41 5.3.8. キーリカバリー応答内容…41 5.3.9. 取消し要求内容…41 5.3.10. 取消し応答内容…42 5.3.11. 相互認証要求内容…42 5.3.12. 相互認証応答内容…42 5.3.13. カリフォルニアの主要なアップデート発表内容…42 5.3.14. 発表を証明してください…43 5.3.15. 取消し発表…43 5.3.16. CRL発表…43 5.3.17. PKI確認内容…43 5.3.18. 確認内容を証明してください…44 5.3.19. PKI一般教書内容…44 5.3.19.1. カリフォルニアプロトコル暗号化証明書…44 5.3.19.2. 主要な組に署名するのはタイプされます…45 5.3.19.3. 暗号化/主要な協定主要な組はタイプします。45 5.3.19.4. 左右対称のアルゴリズムを好みます…45 5.3.19.5. カリフォルニア主要な組をアップデートします…45 5.3.19.6. CRL…46 5.3.19.7. サポートされないオブジェクト識別子…46 5.3.19.8. 主要な組パラメタ…46 5.3.19.9. 取消しパスフレーズ…46 5.3.19.10. ImplicitConfirm…46 5.3.19.11. ConfirmWaitTime…47 5.3.19.12. オリジナルのPKIMessage…47 5.3.19.13. 言語タグであるとサポートされます…47 5.3.20. PKI一般反応内容…47 5.3.21. エラーメッセージ内容…47 5.3.22. 要求と応答に投票します…48 6. 義務的なPKI管理は機能します…51 6.1. カリフォルニアの初期設定を根づかせてください…51 6.2. カリフォルニアの主要なアップデートを根づかせてください…51 6.3. カリフォルニアの初期設定を下位に置かせてください…51 6.4. CRL生産…52 6.5. PKI情報要求…52 6.6. 相互認証…52 6.6.1. 一方向要求応答体系: ...................52 6.7. 実体初期設定を終わらせてください…54 6.7.1. PKI情報の獲得…54 6.7.2. カリフォルニアを根づかせているキーのバンドで出ている検証…55 6.8. 要求を証明してください…55
Adams, et al. Standards Track [Page 3] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[3ページ]。
6.9. Key Update ................................................55
7. Version Negotiation ............................................56
7.1. Supporting RFC 2510 Implementations .......................56
7.1.1. Clients Talking to RFC 2510 Servers ................56
7.1.2. Servers Receiving Version cmp1999 PKIMessages ......57
8. Security Considerations ........................................57
8.1. Proof-Of-Possession with a Decryption Key .................57
8.2. Proof-Of-Possession by Exposing the Private Key ...........57
8.3. Attack Against Diffie-Hellman Key Exchange ................57
9. IANA Considerations ............................................58
Normative References ..............................................58
Informative References ............................................59
A. Reasons for the Presence of RAs ................................61
B. The Use of Revocation Passphrase ...............................61
C. Request Message Behavioral Clarifications ......................63
D. PKI Management Message Profiles (REQUIRED) .....................65
D.1. General Rules for Interpretation of These Profiles ........65
D.2. Algorithm Use Profile .....................................66
D.3. Proof-of-Possession Profile ...............................68
D.4. Initial Registration/Certification (Basic
Authenticated Scheme) .....................................68
D.5. Certificate Request .......................................74
D.6. Key Update Request ........................................75
E. PKI Management Message Profiles (OPTIONAL) .....................75
E.1. General Rules for Interpretation of These Profiles ........76
E.2. Algorithm Use Profile .....................................76
E.3. Self-Signed Certificates ..................................76
E.4. Root CA Key Update ........................................77
E.5. PKI Information Request/Response ..........................77
E.6. Cross Certification Request/Response (1-way) ..............79
E.7. In-Band Initialization Using External Identity
Certificate ..............................................82
F. Compilable ASN.1 Definitions ...................................83
G. Acknowledgements ...............................................93
6.9. 主要なアップデート…55 7. バージョン交渉…56 7.1. RFC2510に実装をサポートします…56 7.1.1. RFC2510サーバと話しているクライアント…56 7.1.2. サーバReceivingバージョンcmp1999 PKIMessages…57 8. セキュリティ問題…57 8.1. 復号化キーがある所有物の証拠…57 8.2. 秘密鍵を暴露するのによる所有物の証拠…57 8.3. ディフィー-ヘルマンの主要なExchangeに対して攻撃してください…57 9. IANA問題…58 標準の参照…58 有益な参照…59 A.はRAsの存在のために推論します…61 B. 取消しパスフレーズの使用…61 C. メッセージの行動の明確化を要求してください…63 D.PKI管理メッセージプロフィール(必要です)…65 D.1。 一般はこれらのプロフィールの解釈のために判決を下します…65 D.2。 アルゴリズムはプロフィールを使用します…66 D.3。 所有物の証拠プロフィール…68 D.4。 登録/証明(基本的な認証された体系)に頭文字をつけてください…68 D.5。 要求を証明してください…74 D.6。 主要な更新要求…75 E.PKI管理メッセージプロフィール(任意の)…75 E.1。 一般はこれらのプロフィールの解釈のために判決を下します…76 E.2。 アルゴリズムはプロフィールを使用します…76 E.3。 証明書であると自己に署名されました…76 E.4。 カリフォルニアの主要なアップデートを根づかせてください…77 E.5。 PKI情報要求/応答…77 E.6。 相互認証要求/応答(1ウェイ)…79 E.7。 バンドにおける外部のアイデンティティ証明書を使用する初期設定…82 F.Compilable ASN.1定義…83 G.承認…93
Adams, et al. Standards Track [Page 4] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[4ページ]。
1. Introduction
1. 序論
This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for certificate creation and management. The term "certificate" in this document refers to an X.509v3 Certificate as defined in [X509].
このドキュメントはインターネットX.509公開鍵暗号基盤(PKI)証明書Managementプロトコル(CMP)について説明します。 プロトコルメッセージは証明書作成と管理のために定義されます。 「証明書」という用語は本書では[X509]で定義されるX.509v3 Certificateについて言及します。
This specification obsoletes RFC 2510. This specification differs from RFC 2510 in the following areas:
この仕様はRFC2510を時代遅れにします。 この仕様は以下の領域でRFC2510と異なっています:
The PKI management message profile section is split to two
appendices: the required profile and the optional profile. Some
of the formerly mandatory functionality is moved to the optional
profile.
PKI管理メッセージプロフィール部分は2個の付録に分けられます: 必要なプロフィールと任意のプロフィール。 以前義務的な機能性のいくつかが任意のプロフィールに動かされます。
The message confirmation mechanism has changed substantially.
メッセージ確認メカニズムは実質的に変化しました。
A new polling mechanism is introduced, deprecating the old polling
method at the CMP transport level.
CMP輸送レベルで古いポーリング方式を非難して、新しい世論調査メカニズムは紹介されます。
The CMP transport protocol issues are handled in a separate
document [CMPtrans], thus the Transports section is removed.
別々のドキュメント[CMPtrans]でCMPトランスポート・プロトコル問題を扱います、その結果、Transports部を取り除きます。
A new implicit confirmation method is introduced to reduce the
number of protocol messages exchanged in a transaction.
トランザクションで交換されたプロトコルメッセージの数を減少させるために新しい暗黙の確認メソッドを導入します。
The new specification contains some less prominent protocol
enhancements and improved explanatory text on several issues.
新しい仕様はいくつかの問題に関する何らかのそれほど際立っていないプロトコル増進と改良された説明しているテキストを含んでいます。
2. Requirements
2. 要件
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHOULD"、「「推薦され」て、このドキュメント(中で大文字してください、示されるように)で「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように解釈されることであるべきですか?
3. PKI Management Overview
3. PKIマネジメントの展望
The PKI must be structured to be consistent with the types of individuals who must administer it. Providing such administrators with unbounded choices not only complicates the software required, but also increases the chances that a subtle mistake by an administrator or software developer will result in broader compromise. Similarly, restricting administrators with cumbersome mechanisms will cause them not to use the PKI.
それを管理しなければならない個人のタイプと一致しているようにPKIを構造化しなければなりません。 限りない選択をそのような管理者に提供すると、管理者かソフトウェア開発者による微妙な誤りが、より広い感染をもたらすという可能性は必要であるソフトウェアを複雑にするだけではなく、増強もされます。 同様に、扱いにくいメカニズムで管理者を制限するのに、それらはPKIを使用しないでしょう。
Adams, et al. Standards Track [Page 5] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[5ページ]。
Management protocols are REQUIRED to support on-line interactions between Public Key Infrastructure (PKI) components. For example, a management protocol might be used between a Certification Authority (CA) and a client system with which a key pair is associated, or between two CAs that issue cross-certificates for each other.
管理プロトコルは公開鍵暗号基盤(PKI)コンポーネントの間のオンライン相互作用をサポートするREQUIREDです。 例えば、管理プロトコルは認証局(カリフォルニア)と主要な組が関連しているクライアントシステムの間、または、互いのために交差している証明書を発行する2CAsの間で使用されるかもしれません。
3.1. PKI Management Model
3.1. PKIマネジメント・モデル
Before specifying particular message formats and procedures, we first define the entities involved in PKI management and their interactions (in terms of the PKI management functions required). We then group these functions in order to accommodate different identifiable types of end entities.
特定のメッセージ・フォーマットと手順を指定する前に、私たちは最初に、PKI管理にかかわる実体とそれらの相互作用(管理機能が必要としたPKIに関する)を定義します。 そして、私たちは、異なった身元保証可能なタイプの終わりの実体を収容するためにこれらの機能を分類します。
3.1.1. Definitions of PKI Entities
3.1.1. PKI実体の定義
The entities involved in PKI management include the end entity (i.e., the entity to whom the certificate is issued) and the certification authority (i.e., the entity that issues the certificate). A registration authority MAY also be involved in PKI management.
PKI管理にかかわる実体は終わりの実体(すなわち、証明書が発行される実体)と証明権威(すなわち、証明書を発行する実体)を含んでいます。 また、登録局はPKI管理にかかわるかもしれません。
3.1.1.1. Subjects and End Entities
3.1.1.1. 対象と終わりの実体
The term "subject" is used here to refer to the entity to whom the certificate is issued, typically named in the subject or subjectAltName field of a certificate. When we wish to distinguish the tools and/or software used by the subject (e.g., a local certificate management module), we will use the term "subject equipment". In general, the term "end entity" (EE), rather than "subject", is preferred in order to avoid confusion with the field name. It is important to note that the end entities here will include not only human users of applications, but also applications themselves (e.g., for IP security). This factor influences the protocols that the PKI management operations use; for example, application software is far more likely to know exactly which certificate extensions are required than are human users. PKI management entities are also end entities in the sense that they are sometimes named in the subject or subjectAltName field of a certificate or cross-certificate. Where appropriate, the term "end- entity" will be used to refer to end entities who are not PKI management entities.
「対象」という期間は、証明書が発行される実体について言及するのにおいてここで中古で、証明書の対象かsubjectAltName分野で通常命名されています。 対象(例えば、ローカルの証明書管理モジュール)によって使用されるツール、そして/または、ソフトウェアを区別したいと思うとき、私たちは「対象の設備」という用語を使用するつもりです。 一般に、用語「終わりの実体」(EE)は、フィールド名への混乱を避けるために「対象」よりむしろ好まれます。 ここの終わりの実体がアプリケーションの人間のユーザだけではなく、アプリケーション(例えば、IPセキュリティのための)自体も含むことに注意するのは重要です。 この要素はPKI管理操作が使用するプロトコルに影響を及ぼします。 例えば、アプリケーション・ソフトは人間のユーザよりはるかにどの証明書拡張子が必要であるかをまさに知っていそうです。 また、PKI経営体はそれらが証明書か交差している証明書の対象かsubjectAltName分野で時々命名されるという意味で終わりの実体です。 適切であることで、「終わりの実体」という用語がPKI経営体ではなく、そうする終わりの実体について言及するのに使用されるところ。
All end entities require secure local access to some information -- at a minimum, their own name and private key, the name of a CA that is directly trusted by this entity, and that CA's public key (or a fingerprint of the public key where a self-certified version is available elsewhere). Implementations MAY use secure local storage for more than this minimum (e.g., the end entity's own certificate or
すべての終わりの実体が最小限、それら自身の名前、秘密鍵、この実体によって直接信じられるカリフォルニアの名前、およびそのCAの公開鍵(または、自己に公認されたバージョンがほかの場所で入手できる公開鍵の指紋)で何らかの情報への安全な地方のアクセスを必要とします。 または実装がこの(例えば、終わりの実体最小の自身の証明書以上に安全な地方のストレージを使用するかもしれない。
Adams, et al. Standards Track [Page 6] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[6ページ]。
application-specific information). The form of storage will also vary -- from files to tamper-resistant cryptographic tokens. The information stored in such local, trusted storage is referred to here as the end entity's Personal Security Environment (PSE).
アプリケーション特有の情報) また、ストレージのフォームはファイルから暗号の耐タンパー性トークンに異なるでしょう。 あれほど地方の、そして、信じられたストレージで保存された情報は終わりの実体のパーソナルSecurity Environment(PSE)としてここと呼ばれます。
Though PSE formats are beyond the scope of this document (they are very dependent on equipment, et cetera), a generic interchange format for PSEs is defined here: a certification response message MAY be used.
PSE形式はこのドキュメントの範囲を超えていますが(それらは設備などに非常に依存しています)、PSEsのためのジェネリック置き換え書式はここで定義されます: 証明応答メッセージは使用されるかもしれません。
3.1.1.2. Certification Authority
3.1.1.2. 認証局
The certification authority (CA) may or may not actually be a real "third party" from the end entity's point of view. Quite often, the CA will actually belong to the same organization as the end entities it supports.
証明権威(カリフォルニア)は実際に終わりの実体の観点からの本当の「第三者」であるかもしれません。 かなりしばしば、カリフォルニアは実際にそれがサポートする終わりの実体と同じ組織に属すでしょう。
Again, we use the term "CA" to refer to the entity named in the issuer field of a certificate. When it is necessary to distinguish the software or hardware tools used by the CA, we use the term "CA equipment".
一方、私たちは、証明書の発行人分野で指定された実体について言及するのに「カリフォルニア」という用語を使用します。 カリフォルニアによって使用されたソフトウェアかハードウェアツールを区別するのが必要であるときに、私たちは「カリフォルニア設備」という用語を使用します。
The CA equipment will often include both an "off-line" component and an "on-line" component, with the CA private key only available to the "off-line" component. This is, however, a matter for implementers (though it is also relevant as a policy issue).
カリフォルニア設備はしばしば「オフライン」のコンポーネントと「オンライン」のコンポーネントの両方を含むでしょう、単に「オフライン」のコンポーネントに利用可能なカリフォルニア秘密鍵で。 しかしながら、これはimplementersのための問題(また、それも政策問題として関連していますが)です。
We use the term "root CA" to indicate a CA that is directly trusted by an end entity; that is, securely acquiring the value of a root CA public key requires some out-of-band step(s). This term is not meant to imply that a root CA is necessarily at the top of any hierarchy, simply that the CA in question is trusted directly.
私たちは終わりの実体によって直接信じられるカリフォルニアを示すために「カリフォルニアを根づく」という用語を使用します。 あって、しっかりと根のカリフォルニア公開鍵の値を取得するのがバンドの外でいくつかを必要とするのが(s)を踏みます。 今期は、根のカリフォルニアが必ずどんな階層構造の最上部にもあって、単に、問題のカリフォルニアが直接信じられるのを含意することになっていません。
A "subordinate CA" is one that is not a root CA for the end entity in question. Often, a subordinate CA will not be a root CA for any entity, but this is not mandatory.
「下位のカリフォルニア」は問題の終わりの実体のための根のカリフォルニアでないものです。 しばしば、下位のカリフォルニアはどんな実体のためにも根のカリフォルニアになるというわけではないでしょうが、これは義務的ではありません。
3.1.1.3. Registration Authority
3.1.1.3. 登録局
In addition to end-entities and CAs, many environments call for the existence of a Registration Authority (RA) separate from the Certification Authority. The functions that the registration authority may carry out will vary from case to case but MAY include personal authentication, token distribution, revocation reporting, name assignment, key generation, archival of key pairs, et cetera.
終わり実体とCAsに加えて、多くの環境が認証局から別々のRegistration Authority(RA)の存在を求めます。 登録局が行うかもしれない機能は、場合によって異なりますが、本人認証を含むかもしれません、トークン分配、取消しが報告して、名前課題、キー生成、主要な組などでは、記録保管所です。
Adams, et al. Standards Track [Page 7] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[7ページ]。
This document views the RA as an OPTIONAL component: when it is not present, the CA is assumed to be able to carry out the RA's functions so that the PKI management protocols are the same from the end- entity's point of view.
このドキュメントはOPTIONALの部品であるとRAをみなします: それが存在していないとき、カリフォルニアがRAの機能を行うことができると思われて、PKI管理プロトコルは終わりの実体の観点から同じです。
Again, we distinguish, where necessary, between the RA and the tools used (the "RA equipment").
一方、私たちはRAと使用される道具(「RA設備」)の間で必要であるところで区別します。
Note that an RA is itself an end entity. We further assume that all RAs are in fact certified end entities and that RAs have private keys that are usable for signing. How a particular CA equipment identifies some end entities as RAs is an implementation issue (i.e., this document specifies no special RA certification operation). We do not mandate that the RA is certified by the CA with which it is interacting at the moment (so one RA may work with more than one CA whilst only being certified once).
RAがそれ自体で終わりの実体であることに注意してください。 私たちは事実上、すべてのRAsが終わりの実体であることが公認されて、RAsには署名に、使用可能な秘密鍵があるとさらに思います。 特定のカリフォルニア設備が、いくつかの終わりの実体がRAsであるとどう認識するかは、導入問題(すなわち、このドキュメントはどんな特別なRA証明操作も指定しない)です。 私たちは、RAがそれが現在相互作用しているカリフォルニアによって公認されるのを強制しません(1RAが一度公認されているだけである間、1以上カリフォルニアと共に働くことができるように)。
In some circumstances, end entities will communicate directly with a CA even where an RA is present. For example, for initial registration and/or certification, the subject may use its RA, but communicate directly with the CA in order to refresh its certificate.
いくつかの事情では、終わりの実体は、RAがどこに存在してさえいるかを直接カリフォルニアと伝えるでしょう。 例えば、新規登録、そして/または、証明に、対象はRAを使用するかもしれませんが、証明書をリフレッシュするためにカリフォルニアと共に直接伝達してください。
3.1.2. PKI Management Requirements
3.1.2. PKI管理要件
The protocols given here meet the following requirements on PKI management
ここに与えられたプロトコルはPKI管理に関する以下の必要条件を満たします。
1. PKI management must conform to the ISO/IEC 9594-8/ITU-T X.509
standards.
1. PKI管理はISO/IEC ITU9594-8/T X.509規格に従わなければなりません。
2. It must be possible to regularly update any key pair without
affecting any other key pair.
2. 定期的にいかなる他の主要な組にも影響しないでどんな主要な組もアップデートするのは可能であるに違いありません。
3. The use of confidentiality in PKI management protocols must be
kept to a minimum in order to ease acceptance in environments
where strong confidentiality might cause regulatory problems.
3. 強い秘密性が規制問題を引き起こすかもしれない環境における承認を緩和するためにPKI管理プロトコルにおける秘密性の使用を最小限に保たなければなりません。
4. PKI management protocols must allow the use of different
industry-standard cryptographic algorithms (specifically
including RSA, DSA, MD5, and SHA-1). This means that any given
CA, RA, or end entity may, in principle, use whichever
algorithms suit it for its own key pair(s).
4. PKI管理プロトコルは異なった業界基準暗号アルゴリズムの使用を許さなければなりません(明確にRSA、DSA、MD5、およびSHA-1を含んでいて)。 これは、どんな与えられたカリフォルニア、RA、または終わりの実体も原則としてそれ自身の主要な組にそれに合うどのアルゴリズムを使用するかもしれないかを意味します。
5. PKI management protocols must not preclude the generation of key
pairs by the end-entity concerned, by an RA, or by a CA. Key
generation may also occur elsewhere, but for the purposes of PKI
management we can regard key generation as occurring wherever
the key is first present at an end entity, RA, or CA.
5. PKI管理プロトコルはRAによって関せられた終わり実体かカリフォルニアによる主要な組の世代を排除してはいけません。 また、キー生成はほかの場所に起こるかもしれなくて、PKI管理の目的がなければ、私たちは、キー生成をどこでも、キーが最初に終わっていた状態で存在しているところに起こると見なすことができます。実体、RA、またはカリフォルニア。
Adams, et al. Standards Track [Page 8] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[8ページ]。
6. PKI management protocols must support the publication of
certificates by the end-entity concerned, by an RA, or by a CA.
Different implementations and different environments may choose
any of the above approaches.
6. PKI管理プロトコルはRAによって関せられた終わり実体の近くかカリフォルニアのそばの証明書の公表をサポートしなければなりません。 異なった実装と異なった環境は上のアプローチのいずれも選ぶかもしれません。
7. PKI management protocols must support the production of
Certificate Revocation Lists (CRLs) by allowing certified end
entities to make requests for the revocation of certificates.
This must be done in such a way that the denial-of-service
attacks, which are possible, are not made simpler.
7. 公認された終わりの実体が証明書の取消しを求める要求をするのを許容することによって、PKI管理プロトコルはCertificate Revocation Lists(CRLs)の生産をサポートしなければなりません。 これはサービス不能攻撃(可能である)をより簡単にしないような方法で完了していなければなりません。
8. PKI management protocols must be usable over a variety of
"transport" mechanisms, specifically including mail, http,
TCP/IP and ftp.
8. PKI管理プロトコルは明確にメール、http、TCP/IP、およびftpを含むさまざまな「輸送」メカニズムの上で使用可能であるに違いありません。
9. Final authority for certification creation rests with the CA.
No RA or end-entity equipment can assume that any certificate
issued by a CA will contain what was requested; a CA may alter
certificate field values or may add, delete, or alter extensions
according to its operating policy. In other words, all PKI
entities (end-entities, RAs, and CAs) must be capable of
handling responses to requests for certificates in which the
actual certificate issued is different from that requested (for
example, a CA may shorten the validity period requested). Note
that policy may dictate that the CA must not publish or
otherwise distribute the certificate until the requesting entity
has reviewed and accepted the newly-created certificate
(typically through use of the certConf message).
9. 証明作成のための最終的な権威はカリフォルニアに責任があります。 どんなRAも終わり実体設備も、カリフォルニアによって発行されたどんな証明書も要求されたことを含むと仮定できません。 運営方針に従って、カリフォルニアは、拡大を証明書分野値を変更するか、加えるか、削除するか、または変更するかもしれません。 言い換えれば、すべてのPKI実体(終わり実体、RAs、およびCAs)は発行された実際の証明書が要求されたそれと異なっている証明書に関する要求への取り扱い応答ができなければなりません(例えば、カリフォルニアは要求された有効期間を短くするかもしれません)。 方針が、要求実体が新たに作成された証明書(通常certConfメッセージの使用による)を再検討して、受け入れるまで、カリフォルニアが証明書を発表してはいけませんし、またそうでなければ、配布してはいけないと決めるかもしれないことに注意してください。
10. A graceful, scheduled change-over from one non-compromised CA
key pair to the next (CA key update) must be supported (note
that if the CA key is compromised, re-initialization must be
performed for all entities in the domain of that CA). An end
entity whose PSE contains the new CA public key (following a CA
key update) must also be able to verify certificates verifiable
using the old public key. End entities who directly trust the
old CA key pair must also be able to verify certificates signed
using the new CA private key (required for situations where the
old CA public key is "hardwired" into the end entity's
cryptographic equipment).
10. 非感染している主要な1カリフォルニア組から次の組までオーバー優雅で、予定されている変化するのを(カリフォルニアの主要なアップデート)サポートしなければなりません(カリフォルニアキーが感染されるなら、そのカリフォルニアのドメインのすべての実体のために再初期化を実行しなければならないことに注意してください)。 また、PSEが新しいカリフォルニア公開鍵(カリフォルニアの主要なアップデートに続く)を含む終わりの実体は、古い公開鍵を使用することで証明可能な証明書について確かめることができなければなりません。 また、直接古いカリフォルニア主要な組を信じる終わりの実体は新しいカリフォルニア秘密鍵(古いカリフォルニア公開鍵が終わりの実体の暗号の設備に「配線される」状況のために、必要である)を使用することで署名される証明書について確かめることができなければなりません。
11. The functions of an RA may, in some implementations or
environments, be carried out by the CA itself. The protocols
must be designed so that end entities will use the same protocol
regardless of whether the communication is with an RA or CA.
Naturally, the end entity must use the correct RA of CA public
key to protect the communication.
11. いくつかの実装か環境で、RAの機能がカリフォルニア自体によって行われるかもしれません。 コミュニケーションがRAかカリフォルニアと共にあることにかかわらず終わりの実体が同じプロトコルを使用するように、プロトコルを設計しなければなりません。 当然、終わりの実体は、コミュニケーションを保護するのにカリフォルニア公開鍵の正しいRAを使用しなければなりません。
Adams, et al. Standards Track [Page 9] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[9ページ]。
12. Where an end entity requests a certificate containing a given
public key value, the end entity must be ready to demonstrate
possession of the corresponding private key value. This may be
accomplished in various ways, depending on the type of
certification request. See Section 4.3 for details of the in-
band methods defined for the PKIX-CMP (i.e., Certificate
Management Protocol) messages.
12. 終わりの実体が与えられた公開鍵値を含む証明書を要求するところでは、終わりの実体は対応する秘密鍵価値の所有物のデモをする準備ができているに違いありません。 証明要求のタイプに頼っていて、これはいろいろ達成されるかもしれません。 PKIX-CMP(すなわち、Certificate Managementプロトコル)メッセージのために定義されたコネバンドメソッドの詳細に関してセクション4.3を見てください。
3.1.3. PKI Management Operations
3.1.3. PKI管理操作
The following diagram shows the relationship between the entities defined above in terms of the PKI management operations. The letters in the diagram indicate "protocols" in the sense that a defined set of PKI management messages can be sent along each of the lettered lines.
以下のダイヤグラムは上でPKI管理操作で定義された実体の間の関係を示しています。 ダイヤグラムによる手紙はそれぞれの文字入りの系列に沿って定義されたセットのPKI管理メッセージを送ることができるという意味における「プロトコル」を示します。
Adams, et al. Standards Track [Page 10] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[10ページ]。
+---+ cert. publish +------------+ j
| | <--------------------- | End Entity | <-------
| C | g +------------+ "out-of-band"
| e | | ^ loading
| r | | | initial
| t | a | | b registration/
| | | | certification
| / | | | key pair recovery
| | | | key pair update
| C | | | certificate update
| R | PKI "USERS" V | revocation request
| L | -------------------+-+-----+-+------+-+-------------------
| | PKI MANAGEMENT | ^ | ^
| | ENTITIES a | | b a | | b
| R | V | | |
| e | g +------+ d | |
| p | <------------ | RA | <-----+ | |
| o | cert. | | ----+ | | |
| s | publish +------+ c | | | |
| i | | | | |
| t | V | V |
| o | g +------------+ i
| r | <------------------------| CA |------->
| y | h +------------+ "out-of-band"
| | cert. publish | ^ publication
| | CRL publish | |
+---+ | | cross-certification
e | | f cross-certificate
| | update
| |
V |
+------+
| CA-2 |
+------+
+---+本命+を発行してください。------------+ j| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| 終わりの実体| <、-、-、-、-、-、--、| C| g+------------+ 「バンドの外」| e| | ^荷重| r| | | 初期| t| a| | b登録/| | | | 証明| / | | | 主要な組回復| | | | 主要な組アップデート| C| | | 証明書最新版| R| PKI「ユーザ」V| 取消し要求| L| -------------------+-+-----+-+------+-+------------------- | | PKI管理| ^ | ^ | | 実体a| | b a| | b| R| V| | | | e| g+------+ d| | | p| <、-、-、-、-、-、-、-、-、-、-、--、| RA| <、-、-、-、--+ | | | o | 本命。 | | ----+ | | | | s| +を発行してください。------+ c| | | | | i| | | | | | t| V| V| | o | g+------------+ i| r| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| カリフォルニア|、-、-、-、-、-、--、>| y| h+------------+ 「バンドの外」| | 本命発行してください。| ^公表| | CRLは発行します。| | +---+ | | 相互認証e| | f交差している証明書| | アップデート| | V| +------+ | カリフォルニア-2| +------+
Figure 1 - PKI Entities
図1--PKI実体
At a high level, the set of operations for which management
messages are defined can be grouped as follows.
高いレベルでは、以下の通り管理メッセージが定義される操作のセットを分類できます。
1. CA establishment: When establishing a new CA, certain steps are
required (e.g., production of initial CRLs, export of CA public
key).
1. カリフォルニアの設立: 新しいカリフォルニアを設置するとき、ある一定のステップが必要です(例えば、初期のCRLsの生産、カリフォルニア公開鍵の輸出)。
2. End entity initialization: this includes importing a root CA
public key and requesting information about the options supported
by a PKI management entity.
2. 実体初期化を終わらせてください: これは、根のカリフォルニア公開鍵をインポートして、PKI経営体で後押しされているオプションの情報を要求するのを含んでいます。
Adams, et al. Standards Track [Page 11] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[11ページ]。
3. Certification: various operations result in the creation of new
certificates:
3. 証明: 様々な操作は新しい証明書の作成をもたらします:
1. initial registration/certification: This is the process
whereby an end entity first makes itself known to a CA or RA,
prior to the CA issuing a certificate or certificates for
that end entity. The end result of this process (when it is
successful) is that a CA issues a certificate for an end
entity's public key, and returns that certificate to the end
entity and/or posts that certificate in a public repository.
This process may, and typically will, involve multiple
"steps", possibly including an initialization of the end
entity's equipment. For example, the end entity's equipment
must be securely initialized with the public key of a CA, to
be used in validating certificate paths. Furthermore, an end
entity typically needs to be initialized with its own key
pair(s).
1. 登録/証明に頭文字をつけてください: これは終わりの実体が最初にカリフォルニアかRAにそれ自体を明らかにするプロセスです、その終わりの実体のための証明書か証明書を発行するカリフォルニアの前に。 このプロセス(それがうまくいっているとき)の結末は終わりの実体の公開鍵、およびリターンのための証明書に終わりの実体へのその証明書を発行する、そして/または、カリフォルニアが公共の倉庫でその証明書をポストに発行するということです。 ことによると終わりの実体の設備の初期化を含んでいて、このプロセスはかかわるかもしれなくて、通常望んでください、そして、複数の「ステップ」にかかわってください。 例えば、カリフォルニアの公開鍵でしっかりと終わりの実体の設備を初期化して、証明書経路を有効にする際に使用されなければなりません。 その上、終わりの実体は、通常それ自身の主要な組と共に初期化される必要があります。
2. key pair update: Every key pair needs to be updated regularly
(i.e., replaced with a new key pair), and a new certificate
needs to be issued.
2. 主要な組は以下をアップデートします。 すべての主要な組が、定期的(すなわち、新しい主要な組に、取って代わる)にアップデートする必要があります、そして、新しい証明書は発行される必要があります。
3. certificate update: As certificates expire, they may be
"refreshed" if nothing relevant in the environment has
changed.
3. アップデートを証明してください: 証明書が期限が切れて、環境で関連しているものは何も変化していないなら、それらは「リフレッシュされるかもしれません」。
4. CA key pair update: As with end entities, CA key pairs need
to be updated regularly; however, different mechanisms are
required.
4. カリフォルニアの主要な組アップデート: 終わりの実体のように、カリフォルニア主要な組は、定期的にアップデートする必要があります。 しかしながら、異なったメカニズムが必要です。
5. cross-certification request: One CA requests issuance of a
cross-certificate from another CA. For the purposes of this
standard, the following terms are defined. A "cross-
certificate" is a certificate in which the subject CA and the
issuer CA are distinct and SubjectPublicKeyInfo contains a
verification key (i.e., the certificate has been issued for
the subject CA's signing key pair). When it is necessary to
distinguish more finely, the following terms may be used: a
cross-certificate is called an "inter-domain cross-
certificate" if the subject and issuer CAs belong to
different administrative domains; it is called an "intra-
domain cross-certificate" otherwise.
5. 相互認証要求: 別のカリフォルニアからの交差している証明書の1つのカリフォルニアの要求発行。 この規格の目的のために、次の用語は定義されます。 「十字証明書」は対象のカリフォルニアと発行人カリフォルニアが異なっている証明書です、そして、SubjectPublicKeyInfoは検証キーを含んでいます(対象のCAの署名重要組のためにすなわち、証明書を発行しました)。 よりきめ細かく区別するのが必要であるときに、次の用語は使用されるかもしれません: 対象と発行人CAsが異なった管理ドメインに属すなら、交差している証明書は「相互ドメインの交差している証明書」と呼ばれます。 それは別の方法で「イントラのドメインの交差している証明書」と呼ばれます。
1. Note 1. The above definition of "cross-certificate"
aligns with the defined term "CA-certificate" in X.509.
Note that this term is not to be confused with the X.500
"cACertificate" attribute type, which is unrelated.
1. 1に注意してください。 「交差している証明書」の上の定義はX.509の「カリフォルニア-証明書」という定義された用語に並びます。 X.500"cACertificate"属性タイプに今期を混乱させてはいけないことに注意してください。(その属性タイプは、関係ありません)。
Adams, et al. Standards Track [Page 12] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[12ページ]。
2. Note 2. In many environments, the term "cross-
certificate", unless further qualified, will be
understood to be synonymous with "inter-domain cross-
certificate" as defined above.
2. 2に注意してください。 多くの環境で、さらに資格がないと、「証明書に交差している」という用語が上で定義されるように「相互ドメインの交差している証明書」と同義であることが理解されるでしょう。
3. Note 3. Issuance of cross-certificates may be, but is
not necessarily, mutual; that is, two CAs may issue
cross-certificates for each other.
3. 3に注意してください。 交差している証明書の発行があるかもしれませんが、必ずあるというわけではない、互い。 すなわち、2CAsが互いのために交差している証明書を発行するかもしれません。
6. cross-certificate update: Similar to a normal certificate
update, but involving a cross-certificate.
6. 交差している証明書最新版: 通常の証明書最新版と同様ですが、交差している証明書にかかわります。
4. Certificate/CRL discovery operations: some PKI management
operations result in the publication of certificates or CRLs:
4. 証明書/CRL発見操作: いくつかのPKI管理操作が証明書かCRLsの公表をもたらします:
1. certificate publication: Having gone to the trouble of
producing a certificate, some means for publishing it is
needed. The "means" defined in PKIX MAY involve the messages
specified in Sections 5.3.13 to 5.3.16, or MAY involve other
methods (LDAP, for example) as described in [RFC2559],
[RFC2585] (the "Operational Protocols" documents of the PKIX
series of specifications).
1. 公表を証明してください: わざわざ証明書を製作して、それを発行するためのいくつかの手段が必要です。 PKIX MAYで定義された「手段」は、メッセージ指定されたコネセクション5.3の.13〜5.3.16を伴うか、または[RFC2559]で説明されるように他のメソッド(例えば、LDAP)にかかわるかもしれません、[RFC2585。](「操作上のプロトコル」という仕様のPKIXシリーズのドキュメント)
2. CRL publication: As for certificate publication.
2. CRL公表: 証明書公表のように。
5. Recovery operations: some PKI management operations are used when
an end entity has "lost" its PSE:
5. 回復動作: 終わりの実体がPSEを「失った」とき、いくつかのPKI管理操作が使用されています:
1. key pair recovery: As an option, user client key materials
(e.g., a user's private key used for decryption purposes) MAY
be backed up by a CA, an RA, or a key backup system
associated with a CA or RA. If an entity needs to recover
these backed up key materials (e.g., as a result of a
forgotten password or a lost key chain file), a protocol
exchange may be needed to support such recovery.
1. 主要な組回復: オプションとして、ユーザクライアント主要資材(例えば復号化目的に使用されるユーザの秘密鍵)はカリフォルニアかRAに関連しているカリフォルニア、RA、または主要なバックアップ・システムによって支援されるかもしれません。 実体が、主要資材で支持されたこれら(例えば、忘れられたパスワードか無くなっているキーチェーンファイルの結果、)を回復する必要があるなら、プロトコル交換が、そのような回復をサポートするのに必要であるかもしれません。
6. Revocation operations: some PKI operations result in the creation
of new CRL entries and/or new CRLs:
6. 取消し操作: いくつかのPKI操作が新しいCRLエントリー、そして/または、新しいCRLsの作成をもたらします:
1. revocation request: An authorized person advises a CA of an
abnormal situation requiring certificate revocation.
1. 取消し要求: 権限保持者は証明書取消しを必要とする異常な状況をカリフォルニアに知らせます。
7. PSE operations: whilst the definition of PSE operations (e.g.,
moving a PSE, changing a PIN, etc.) are beyond the scope of this
specification, we do define a PKIMessage (CertRepMessage) that
can form the basis of such operations.
7. PSE操作: PSEの定義である間、操作(例えば、暗証番号を変えて、PSEを動かしますなど)はこの仕様の範囲を超えていて、私たちはそのような操作の基礎を形成できるPKIMessage(CertRepMessage)を定義します。
Adams, et al. Standards Track [Page 13] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[13ページ]。
Note that on-line protocols are not the only way of implementing the above operations. For all operations, there are off-line methods of achieving the same result, and this specification does not mandate use of on-line protocols. For example, when hardware tokens are used, many of the operations MAY be achieved as part of the physical token delivery.
オンラインプロトコルが唯一の道にどんな上の操作を実装しないものであることに注意してください。 すべての操作のために、同じ結果を獲得するメソッドがオフラインであります、そして、この仕様はオンラインプロトコルの使用を強制しません。 ハードウェアトークンが使用されているとき、例えば、操作の多くが物理的なトークン配送の一部として達成されるかもしれません。
Later sections define a set of standard messages supporting the above operations. Transport protocols for conveying these exchanges in different environments (file-based, on-line, E-mail, and WWW) are beyond the scope of this document and are specified separately.
後のセクションは上の操作をサポートする1セットの標準のメッセージを定義します。 異なった環境(ファイルベースの、そして、オンラインのメール、およびWWW)におけるこれらの交換を伝えるためのトランスポート・プロトコルは、このドキュメントの範囲を超えていて、別々に指定されます。
4. Assumptions and Restrictions
4. 仮定と制限
4.1. End Entity Initialization
4.1. 終わりの実体初期設定
The first step for an end entity in dealing with PKI management entities is to request information about the PKI functions supported and to securely acquire a copy of the relevant root CA public key(s).
PKI経営体に対処することにおける終わりの実体のための第一歩は、機能がサポートしたPKIの情報を要求して、しっかりと関連根のカリフォルニア公開鍵のコピーを入手することです。
4.2. Initial Registration/Certification
4.2. 新規登録/証明
There are many schemes that can be used to achieve initial registration and certification of end entities. No one method is suitable for all situations due to the range of policies that a CA may implement and the variation in the types of end entity which can occur.
終わりの実体の新規登録と証明を達成するのに使用できる多くの体系があります。 いいえ1、メソッドはカリフォルニアが実装するかもしれない方針の範囲と終わりの実体のタイプの起こることができる変化のためにすべての状況に適しています。
However, we can classify the initial registration/certification schemes that are supported by this specification. Note that the word "initial", above, is crucial: we are dealing with the situation where the end entity in question has had no previous contact with the PKI. Where the end entity already possesses certified keys, then some simplifications/alternatives are possible.
しかしながら、私たちはこの仕様でサポートされる新規登録/証明体系を分類できます。 「初期」という言葉が上で重要であることに注意してください: 私たちは問題の終わりの実体がPKIとの前の接触を全く持っていないところに時局に処しています。 終わりの実体が既に公認されたキーを所有するところでは、その時、いくつかの簡素化/選択肢が可能です。
Having classified the schemes that are supported by this specification we can then specify some as mandatory and some as optional. The goal is that the mandatory schemes cover a sufficient number of the cases that will arise in real use, whilst the optional schemes are available for special cases that arise less frequently. In this way, we achieve a balance between flexibility and ease of implementation.
この仕様でサポートされる体系を分類したので、そして、私たちは任意であるとして義務的であるとしてのいくつかといくつかを指定できます。 目標は義務的な体系が本当の使用で起こるケースの十分な数をカバーしているということです、任意の体系が、より頻繁でなく起こる特別なケースに利用可能ですが。 このように、私たちは柔軟性と実装の容易さの間のバランスを獲得します。
We will now describe the classification of initial registration/certification schemes.
私たちは現在、新規登録/証明体系の分類について説明するつもりです。
Adams, et al. Standards Track [Page 14] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[14ページ]。
4.2.1. Criteria Used
4.2.1. 使用される評価基準
4.2.1.1. Initiation of Registration/Certification
4.2.1.1. 登録/証明の開始
In terms of the PKI messages that are produced, we can regard the initiation of the initial registration/certification exchanges as occurring wherever the first PKI message relating to the end entity is produced. Note that the real-world initiation of the registration/certification procedure may occur elsewhere (e.g., a personnel department may telephone an RA operator).
出されるPKIメッセージに関して、私たちは、新規登録/証明交換の開始をどこでも、終わりの実体に関連する最初のPKIメッセージが出されるところに起こると見なすことができます。 登録/証明手順の本当の世界開始がほかの場所に起こるかもしれないことに注意してください(例えば、人事課はRAオペレータに電話をするかもしれません)。
The possible locations are at the end entity, an RA, or a CA.
可能な位置が終わりの実体、RA、またはカリフォルニアにあります。
4.2.1.2. End Entity Message Origin Authentication
4.2.1.2. 終わりの実体メッセージ発生源認証
The on-line messages produced by the end entity that requires a certificate may be authenticated or not. The requirement here is to authenticate the origin of any messages from the end entity to the PKI (CA/RA).
証明書を必要とする終わりの実体によって出されたオンラインメッセージは認証されるかもしれません。 ここの要件は終わりの実体からPKI(カリフォルニア/RA)までどんなメッセージの発生源も認証することです。
In this specification, such authentication is achieved by the PKI (CA/RA) issuing the end entity with a secret value (initial authentication key) and reference value (used to identify the secret value) via some out-of-band means. The initial authentication key can then be used to protect relevant PKI messages.
この仕様では、そのような認証はバンドの外でいくつかを通して秘密の値(初期の認証キー)と基準値(以前はよく秘密の値を特定していた)で終わりの実体を発行すると意味するPKI(カリフォルニア/RA)によって達成されます。 そして、関連PKIメッセージを保護するのに初期の認証キーを使用できます。
Thus, we can classify the initial registration/certification scheme according to whether or not the on-line end entity -> PKI messages are authenticated or not.
したがって、オンライン終わりの実体->PKIメッセージが認証されるかどうかに従って、私たちは新規登録/証明体系を分類できます。
Note 1: We do not discuss the authentication of the PKI -> end entity messages here, as this is always REQUIRED. In any case, it can be achieved simply once the root-CA public key has been installed at the end entity's equipment or it can be based on the initial authentication key.
注意1: 私たちは、いつもこれがREQUIREDであるので、ここでPKI->終わりの実体メッセージの認証について議論しません。 どのような場合でも、単にカリフォルニアを根づかせている公開鍵がいったん終わりの実体の設備にインストールされると、それを達成できますか、またはそれは初期の認証キーに基づくことができます。
Note 2: An initial registration/certification procedure can be secure where the messages from the end entity are authenticated via some out-of-band means (e.g., a subsequent visit).
注意2: 新規登録/証明手順はいくつかのバンドで出ている手段(例えば、その後の訪問)で終わりの実体からのメッセージが認証されるところで安全である場合があります。
4.2.1.3. Location of Key Generation
4.2.1.3. キー生成の位置
In this specification, "key generation" is regarded as occurring wherever either the public or private component of a key pair first occurs in a PKIMessage. Note that this does not preclude a centralized key generation service; the actual key pair MAY have been
この仕様では、「キー生成」はどこでも、主要な組の公共の、または、個人的なコンポーネントが最初にPKIMessageに起こるところに起こると見なされます。 これが集結されたキー生成サービスを排除しないことに注意してください。 実際のキー組があったかもしれません。
Adams, et al. Standards Track [Page 15] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[15ページ]。
generated elsewhere and transported to the end entity, RA, or CA using a (proprietary or standardized) key generation request/response protocol (outside the scope of this specification).
(独占であるか標準化された)キー生成要求/応答プロトコル(この仕様の範囲の外の)を使用することで終わりの実体、RA、またはカリフォルニアにほかの場所で生成されて、輸送されます。
Thus, there are three possibilities for the location of "key generation": the end entity, an RA, or a CA.
したがって、「キー生成」の位置への3つの可能性があります: 終わりの実体、RA、またはカリフォルニア。
4.2.1.4. Confirmation of Successful Certification
4.2.1.4. うまくいっている証明の確認
Following the creation of an initial certificate for an end entity, additional assurance can be gained by having the end entity explicitly confirm successful receipt of the message containing (or indicating the creation of) the certificate. Naturally, this confirmation message must be protected (based on the initial authentication key or other means).
または、終わりの実体のための初期の証明書の作成に続いて、終わりの実体にメッセージ含有のうまくいっている領収書を明らかに確認させることによって追加保証を獲得できる、(作成を示す、)、証明書。 当然、この確認メッセージを保護しなければなりません(初期の認証主要であるか他の手段に基づいています)。
This gives two further possibilities: confirmed or not.
これはさらなる2つの可能性を与えます: 確認にされる。
4.2.2. Mandatory Schemes
4.2.2. 義務的な体系
The criteria above allow for a large number of initial registration/certification schemes. This specification mandates that conforming CA equipment, RA equipment, and EE equipment MUST support the second scheme listed below (Section 4.2.2.2). Any entity MAY additionally support other schemes, if desired.
上の評価基準は多くの新規登録/証明体系を考慮します。 設備が2番目の体系をサポートしなければならないこの仕様の命令のそんなに従っているカリフォルニア設備、RA設備、およびEEが以下に記載した、(セクション4.2 .2 .2)。 望まれているなら、どんな実体もさらに、他の体系をサポートするかもしれません。
4.2.2.1. Centralized Scheme
4.2.2.1. 集結された体系
In terms of the classification above, this scheme is, in some ways, the simplest possible, where:
分類で、この体系はいくつかの道、可能な最も簡単の上では、どこです:
o initiation occurs at the certifying CA;
o 開始は公認カリフォルニアに起こります。
o no on-line message authentication is required;
o どんなオンライン通報認証も必要ではありません。
o "key generation" occurs at the certifying CA (see Section
4.2.1.3);
o 「キー生成」が公認カリフォルニアに起こる、(セクション4.2.1を見てください、.3)。
o no confirmation message is required.
o 確認メッセージは全く必要ではありません。
In terms of message flow, this scheme means that the only message required is sent from the CA to the end entity. The message must contain the entire PSE for the end entity. Some out-of-band means must be provided to allow the end entity to authenticate the message received and to decrypt any encrypted values.
メッセージ流動で、唯一のメッセージが必要としたこの体系手段をカリフォルニアから終わりの実体に送ります。 メッセージは終わりの実体のための全体のPSEを含まなければなりません。 終わりの実体が受け取られたメッセージを認証して、どんな暗号化された値も解読するのを許容するためにいくつかのバンドで出ている手段を提供しなければなりません。
Adams, et al. Standards Track [Page 16] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[16ページ]。
4.2.2.2. Basic Authenticated Scheme
4.2.2.2. 基本的な認証された体系
In terms of the classification above, this scheme is where:
分類で、この体系は上では、どこです:
o initiation occurs at the end entity;
o 開始は終わりの実体で起こります。
o message authentication is REQUIRED;
o 通報認証はREQUIREDです。
o "key generation" occurs at the end entity (see Section 4.2.1.3);
o 「キー生成」が終わりの実体で起こる、(セクション4.2.1を見てください、.3)。
o a confirmation message is REQUIRED.
o 確認メッセージはREQUIREDです。
In terms of message flow, the basic authenticated scheme is as follows:
メッセージ流動では、基本的な認証された体系は以下の通りです:
End entity RA/CA
========== =============
out-of-band distribution of Initial Authentication
Key (IAK) and reference value (RA/CA -> EE)
Key generation
Creation of certification request
Protect request with IAK
-->>-- certification request -->>--
verify request
process request
create response
--<<-- certification response --<<--
handle response
create confirmation
-->>-- cert conf message -->>--
verify confirmation
create response
--<<-- conf ack (optional) --<<--
handle response
終わりの実体RA/カリフォルニア========== ============= バンドの外に、Initial Authentication Key(IAK)とProtectがIAK-->>--証明要求(>>)で要求する証明要求のキー生成Creationがプロセス要求を要求することを確かめる基準値(RA/カリフォルニア->EE)の分配は応答を作成します--<<; 証明応答--<<--ハンドル応答は確認を作成します-->>--本命confメッセージ-->>--確認について確かめるのは応答--<<--conf ack(任意の)--<<--ハンドル応答を作成します。
(Where verification of the cert confirmation message fails, the RA/CA MUST revoke the newly issued certificate if it has been published or otherwise made available.)
(本命確認メッセージの検証が失敗するところでは、それを発行するか、または別の方法で利用可能にしたなら、RA/カリフォルニアは新譜の証明書を取り消さなければなりません。)
4.3. Proof-of-Possession (POP) of Private Key
4.3. 秘密鍵所有物の証拠(飛び出します)
In order to prevent certain attacks and to allow a CA/RA to properly check the validity of the binding between an end entity and a key pair, the PKI management operations specified here make it possible for an end entity to prove that it has possession of (i.e., is able to use) the private key corresponding to the public key for which a certificate is requested. A given CA/RA is free to choose how to enforce POP (e.g., out-of-band procedural means versus PKIX-CMP
ある攻撃を防いで、カリフォルニア/RAが適切に終わりの実体と主要な組の間の結合の正当性をチェックするのを許容するために、ここで指定されたPKI管理操作で、終わりの実体が、(すなわち、使用に、できます)秘密鍵の所有物を証明書が要求されている公開鍵に対応するようにすると立証するのが可能になります。 与えられたカリフォルニア/RAが自由にPOPを実施する方法を選ぶことができる、(例えば、外、-、-PKIX-CMPに対して手続き上の手段を括ってください。
Adams, et al. Standards Track [Page 17] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[17ページ]。
in-band messages) in its certification exchanges (i.e., this may be a policy issue). However, it is REQUIRED that CAs/RAs MUST enforce POP by some means because there are currently many non-PKIX operational protocols in use (various electronic mail protocols are one example) that do not explicitly check the binding between the end entity and the private key. Until operational protocols that do verify the binding (for signature, encryption, and key agreement key pairs) exist, and are ubiquitous, this binding can only be assumed to have been verified by the CA/RA. Therefore, if the binding is not verified by the CA/RA, certificates in the Internet Public-Key Infrastructure end up being somewhat less meaningful.
バンドにおけるメッセージ) 証明交換(すなわち、これは政策問題であるかもしれない)で。 しかしながら、現在、終わりの実体と秘密鍵の間には、明らかに結合をチェックしない使用中の多くの非PKIX操作上のプロトコル(様々な電子メールプロトコルは1つの例である)があるのでCAs/RAsがどうでもPOPを実施しなければならないのは、REQUIREDです。 結合(署名、暗号化、および主要な協定主要な組)について確かめる操作上のプロトコルが存在していて、遍在するまで、カリフォルニア/RAによって確かめられたとこの結合を思うことができるだけです。 したがって、結合がカリフォルニア/RAによって確かめられないなら、インターネット公開鍵暗号基盤の証明書は結局、いくらか重要ではありません。
POP is accomplished in different ways depending upon the type of key for which a certificate is requested. If a key can be used for multiple purposes (e.g., an RSA key) then any appropriate method MAY
POPは証明書が要求されているキーのタイプに頼る異なった方法で達成されます。 複数の目的(例えば、RSAキー)にキーを使用できるなら、どんな適切なメソッドもそうするかもしれません。
be used (e.g., a key that may be used for signing, as well as other purposes, SHOULD NOT be sent to the CA/RA in order to prove possession).
使用されてください、(例えば、それがキーであるかもしれない、他の目的と同様にSHOULD NOTに署名するのに使用されて、所有物を立証するためにカリフォルニア/RAに送ってください、)
This specification explicitly allows for cases where an end entity supplies the relevant proof to an RA and the RA subsequently attests to the CA that the required proof has been received (and validated!). For example, an end entity wishing to have a signing key certified could send the appropriate signature to the RA, which then simply notifies the relevant CA that the end entity has supplied the required proof. Of course, such a situation may be disallowed by some policies (e.g., CAs may be the only entities permitted to verify POP during certification).
この仕様は、終わりの実体が関連証拠をRAに供給して、RAが次にカリフォルニアを証明するケースのために必要な証拠が受け取られたのを(そして、有効にされます!)明らかに許容します。 例えば、署名キーを公認させる終わりの実体願望は適切な署名をRAに送るかもしれません。(次に、単に、RAは、終わりの実体が必要な証拠を供給したことを関連カリフォルニアに通知します)。 もちろん、そのような状況はいくつかの方針で禁じられるかもしれません(例えば、CAsは証明の間、POPについて確かめることが許可された唯一の実体であるかもしれません)。
4.3.1. Signature Keys
4.3.1. 署名キー
For signature keys, the end entity can sign a value to prove possession of the private key.
署名キーに関しては、終わりの実体は、秘密鍵の所有物を立証するために値に署名することができます。
4.3.2. Encryption Keys
4.3.2. 暗号化キー
For encryption keys, the end entity can provide the private key to the CA/RA, or can be required to decrypt a value in order to prove possession of the private key (see Section 5.2.8). Decrypting a value can be achieved either directly or indirectly.
暗号化キーに関しては、終わりの実体は、カリフォルニア/RAに秘密鍵を供給できるか、または秘密鍵の所有物を立証するために値を解読するために必要とすることができます(セクション5.2.8を見てください)。 直接か間接的に値を解読するのを達成できます。
The direct method is for the RA/CA to issue a random challenge to which an immediate response by the EE is required.
ダイレクトメソッドはRA/カリフォルニアがEEによる即時型反応が必要である無作為の挑戦を発行することです。
Adams, et al. Standards Track [Page 18] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[18ページ]。
The indirect method is to issue a certificate that is encrypted for the end entity (and have the end entity demonstrate its ability to decrypt this certificate in the confirmation message). This allows a CA to issue a certificate in a form that can only be used by the intended end entity.
間接的なメソッドは終わりの実体のために暗号化される証明書を発行する(終わりの実体に確認メッセージにこの証明書を解読する性能を示させてください)ことです。 これで、カリフォルニアは意図している終わりの実体で使用できるだけであるフォームで証明書を下付します。
This specification encourages use of the indirect method because it
requires no extra messages to be sent (i.e., the proof can be
demonstrated using the {request, response, confirmation} triple of
messages).
どんな送られるべき付加的なメッセージも必要としないのでこの仕様が間接的なメソッドの使用を奨励する、(すなわち、証拠が示された使用であることができる、要求、応答、確認がメッセージを3倍にする、)
4.3.3. Key Agreement Keys
4.3.3. 主要な協定キー
For key agreement keys, the end entity and the PKI management entity (i.e., CA or RA) must establish a shared secret key in order to prove that the end entity has possession of the private key.
主要な協定キーに関しては、終わりの実体とPKI経営体(すなわち、カリフォルニアかRA)は、終わりの実体には秘密鍵の所有物があると立証するために共有された秘密鍵を設立しなければなりません。
Note that this need not impose any restrictions on the keys that can be certified by a given CA. In particular, for Diffie-Hellman keys the end entity may freely choose its algorithm parameters provided that the CA can generate a short-term (or one-time) key pair with the appropriate parameters when necessary.
これが与えられたカリフォルニアが公認できるキーに少しの制限も課す必要はないことに注意してください。 必要であるときに、カリフォルニアが適切なパラメタで短期的で(1回)の主要な組を生成することができれば、ディフィー-ヘルマンキーのために、特に、終わりの実体は自由にアルゴリズムパラメタを選ぶかもしれません。
4.4. Root CA Key Update
4.4. 根のカリフォルニアキーアップデート
This discussion only applies to CAs that are directly trusted by some end entities. Self-signed CAs SHALL be considered as directly trusted CAs. Recognizing whether a non-self-signed CA is supposed to be directly trusted for some end entities is a matter of CA policy and is thus beyond the scope of this document.
この議論はいくつかの終わりの実体によって直接信じられるCAsに適用されるだけです。 CAs SHALLであると自己に署名されて、直接信じられたCAsであるとみなされてください。 その結果、いくつかの終わりの実体のために直接信じられると思われているのが、カリフォルニア方針の問題であるということであり、非自己が署名しているカリフォルニアが認識するか否かに関係なく、このドキュメントの範囲を超えて認識します。
The basis of the procedure described here is that the CA protects its new public key using its previous private key and vice versa. Thus, when a CA updates its key pair it must generate two extra cACertificate attribute values if certificates are made available using an X.500 directory (for a total of four: OldWithOld, OldWithNew, NewWithOld, and NewWithNew).
ここで説明された手順の基礎はカリフォルニアが逆もまた同様に前の秘密鍵を使用することで新しい公開鍵を保護するということです。 したがって、カリフォルニアが主要な組をアップデートすると、X.500ディレクトリ(4の合計: OldWithOld、OldWithNew、NewWithOld、およびNewWithNewのための)を使用することで証明書を利用可能にするなら、それは、2の付加的なcACertificate属性が値であると生成しなければなりません。
When a CA changes its key pair, those entities who have acquired the old CA public key via "out-of-band" means are most affected. It is these end entities who will need access to the new CA public key protected with the old CA private key. However, they will only require this for a limited period (until they have acquired the new CA public key via the "out-of-band" mechanism). This will typically be easily achieved when these end entities' certificates expire.
カリフォルニアが主要な組を変えるとき、「バンドの外」という手段で古いカリフォルニア公開鍵を取得したそれらの実体は最も影響を受けます。 それはなる古いカリフォルニア秘密鍵で保護された新しいカリフォルニア公開鍵へのアクセスが必要にこれらの終わりの実体です。 しかしながら、彼らは限定期間の間、これを必要とするだけでしょう(彼らが「バンドの外」というメカニズムで新しいカリフォルニア公開鍵を取得するまで)。 これらの終わりの実体の証明書が期限が切れるとき、これは容易に通常達成されるでしょう。
Adams, et al. Standards Track [Page 19] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[19ページ]。
The data structure used to protect the new and old CA public keys is a standard certificate (which may also contain extensions). There are no new data structures required.
新しくて古いカリフォルニア公開鍵を保護するのに使用されるデータ構造は標準の証明書(また、拡大を含むかもしれない)です。 必要であるどんな新しいデータ構造もありません。
Note 1. This scheme does not make use of any of the X.509 v3 extensions as it must be able to work even for version 1 certificates. The presence of the KeyIdentifier extension would make for efficiency improvements.
1に注意してください。 この体系は、バージョン1証明書のためにさえ働くことができなければならないので、X.509 v3拡張子のいずれも利用しません。 KeyIdentifier拡張子の存在は効率改良になるでしょう。
Note 2. While the scheme could be generalized to cover cases where the CA updates its key pair more than once during the validity period of one of its end entities' certificates, this generalization seems of dubious value. Not having this generalization simply means that the validity periods of certificates issued with the old CA key pair cannot exceed the end of the OldWithNew validity period.
2に注意してください。 カリフォルニアが終わりの実体の証明書の1つの有効期間の間の一度より多くの主要な組をアップデートするケースをカバーするために体系を一般化できましたが、この一般化は疑わしい価値について見えます。 単にこの一般化を持っていないのは、古いカリフォルニア主要な組と共に発行された証明書の有効期間がOldWithNew有効期間の終わりを超えることができないことを意味します。
Note 3. This scheme ensures that end entities will acquire the new CA public key, at the latest by the expiry of the last certificate they owned that was signed with the old CA private key (via the "out-of-band" means). Certificate and/or key update operations occurring at other times do not necessarily require this (depending on the end entity's equipment).
3に注意してください。 この体系は、終わりの実体が遅くともそれらが所有していた古いカリフォルニア秘密鍵(「バンドの外」という手段を通した)を契約された最後の証明書の満期で新しいカリフォルニア公開鍵を取得するのを確実にします。 証明書、そして/または、他の時に起こる主要なアップデート操作は必ずこれを必要とするというわけではありません(終わりの実体の設備によって)。
4.4.1. CA Operator Actions
4.4.1. カリフォルニアのオペレータ動作
To change the key of the CA, the CA operator does the following:
カリフォルニア(カリフォルニア)のオペレータのキーを変えるのは以下をします:
1. Generate a new key pair;
1. 新しい主要な組を生成してください。
2. Create a certificate containing the old CA public key signed with
the new private key (the "old with new" certificate);
2. 新しい秘密鍵(「新しいことで古い」証明書)を契約された古いカリフォルニア公開鍵を含む証明書を作成してください。
3. Create a certificate containing the new CA public key signed with
the old private key (the "new with old" certificate);
3. 古い秘密鍵(「古いことで新しい」証明書)を契約された新しいカリフォルニア公開鍵を含む証明書を作成してください。
4. Create a certificate containing the new CA public key signed with
the new private key (the "new with new" certificate);
4. 新しい秘密鍵(「新しいことで新しい」証明書)を契約された新しいカリフォルニア公開鍵を含む証明書を作成してください。
5. Publish these new certificates via the repository and/or other
means (perhaps using a CAKeyUpdAnn message);
5. 倉庫、そして/または、他の手段でこれらの新しい証明書を発表してください(恐らくCAKeyUpdAnnメッセージを使用して)。
6. Export the new CA public key so that end entities may acquire it
using the "out-of-band" mechanism (if required).
6. 終わりの実体が(必要なら、)「バンドの外」というメカニズムを使用することでそれを取得できるように、新しいカリフォルニア公開鍵をエクスポートしてください。
The old CA private key is then no longer required. However, the old CA public key will remain in use for some time. The old CA public key is no longer required (other than for non-repudiation) when all end entities of this CA have securely acquired the new CA public key.
そして、古いカリフォルニア秘密鍵はもう必要ではありません。 しかしながら、古いカリフォルニア公開鍵はしばらく使用中であり残るでしょう。 このカリフォルニアのすべての終わりの実体がしっかりと新しいカリフォルニア公開鍵を取得したとき、古いカリフォルニア公開鍵はもう必要ではありません(非拒否以外に)。
Adams, et al. Standards Track [Page 20] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[20ページ]。
The "old with new" certificate must have a validity period starting at the generation time of the old key pair and ending at the expiry date of the old public key.
「新しいことで古い」証明書には、古い公開鍵の有効期限日の古い主要な組と結末の時に世代のときに始まる有効期間がなければなりません。
The "new with old" certificate must have a validity period starting at the generation time of the new key pair and ending at the time by which all end entities of this CA will securely possess the new CA public key (at the latest, the expiry date of the old public key).
「古いことで新しい」証明書には、時間のこのカリフォルニアのすべての終わりの実体に新しいカリフォルニア公開鍵がしっかりとある新しい主要な組と結末の時に世代のときに始まる有効期間がなければなりません(遅くとも、満期は古い公開鍵とデートします)。
The "new with new" certificate must have a validity period starting at the generation time of the new key pair and ending at or before the time by which the CA will next update its key pair.
「新しいことで新しい」証明書で、カリフォルニアが次にそうする時間か時間の前の新しい主要な組と結末の時に世代のときに始まる有効期間は主要な組をアップデートしなければなりません。
4.4.2. Verifying Certificates
4.4.2. 証明書について確かめます。
Normally when verifying a signature, the verifier verifies (among other things) the certificate containing the public key of the signer. However, once a CA is allowed to update its key there are a range of new possibilities. These are shown in the table below.
署名について確かめるとき、通常、検証は(特に)署名者の公開鍵を含む証明書について確かめます。 しかしながら、カリフォルニアがいったんキーをアップデートできると、さまざまな新しい可能性があります。 これらは以下のテーブルに示されます。
Repository contains NEW Repository contains only OLD
and OLD public keys public key (due to, e.g.,
delay in publication)
倉庫が含んでいる、NEW RepositoryはOLDとOLD公開鍵公開鍵だけを含んでいます。(当然であることで、例えば、公表で延着してください)
PSE PSE Contains PSE Contains PSE Contains
Contains OLD public NEW public OLD public
NEW public key key key
key
公共の公共のPSE PSE Contains PSE Contains PSE Contains Contains OLDの公共のNEW公開鍵主要な主要なNEW OLDキー
Signer's Case 1: Case 3: Case 5: Case 7:
certifi- This is In this case Although the In this case
cate is the the verifier CA operator the CA
protected standard must access has not operator has
using NEW case where the updated the not updated
public the repository in repository the the repository
key verifier order to get verifier can and so the
can the value of verify the verification
directly the NEW certificate will FAIL
verify the public key directly -
certificate this is thus
without the same as
using the case 1.
repository
署名者のケース1: ケース3: ケース5: ケース7: その結果、これはそうです。直接検証について確かめてください。certifiこれがIn本件Althoughである、In本件美味がオペレータではなく、保護された標準の必須アクセスが持っている検証カリフォルニアのオペレータカリフォルニアが使用NEWにどこをケースに入れさせるかということである、アップデートされなかった公衆をアップデートする、倉庫の主要な検証が缶を検証に手に入れて、缶をそうに手に入れるのを注文する倉庫の倉庫、値、NEW証明書意志のFAILは直接公開鍵について確かめます--、証明書、ケース1を使用するのと同じくらいなしで倉庫
Adams, et al. Standards Track [Page 21] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[21ページ]。
Signer's Case 2: Case 4: Case 6: Case 8:
certifi- In this In this case The verifier Although the
cate is case the the verifier thinks this CA operator
protected verifier can directly is the has not
using OLD must verify the situation of updated the
public access the certificate case 2 and repository the
key repository without will access verifier can
in order using the the verify the
to get the repository repository; certificate
value of however, the directly -
the OLD verification this is thus
public key will FAIL the same as
case 4.
署名者のケース2: ケース4: ケース6: ケース8: certifiこのIn本件における検証Although、美味が検証がこのカリフォルニアのオペレータであると考えるケースが直接検証缶を保護したということである、どんな使用しているOLD必須にも状況について確かめさせない、アップデートされることでは、公衆が意志のアクセス検証のない主要な倉庫が中で使用を命令することができる証明書ケース2と倉庫にアクセスする、検証、倉庫倉庫を手に入れるために。 しかしながら、値を証明する、直接--、OLD検証、4をケースに入れるとき、これは同じようにその結果、公開鍵意志のFAILです。
4.4.2.1. Verification in Cases 1, 4, 5, and 8
4.4.2.1. 場合1、4、5、および8における検証
In these cases, the verifier has a local copy of the CA public key that can be used to verify the certificate directly. This is the same as the situation where no key change has occurred.
これらの場合では、検証は直接証明書について確かめるのに使用できるカリフォルニア公開鍵の地方のコピーを持っています。 これはキーチェンジが全く起こっていない状況と同じです。
Note that case 8 may arise between the time when the CA operator has generated the new key pair and the time when the CA operator stores the updated attributes in the repository. Case 5 can only arise if
ケース8がカリフォルニアのオペレータが新しい主要な組を生成した時、カリフォルニアのオペレータが倉庫にアップデートされた属性を保存する時の間に起こるかもしれないことに注意してください。 ケース5は起こることができるだけです。
the CA operator has issued both the signer's and verifier's certificates during this "gap" (the CA operator SHOULD avoid this as it leads to the failure cases described below)
カリフォルニアのオペレータはこの「ギャップ」の間、署名者と検証の両方の証明書を発行しています。(以下で説明された失敗事件に通じて、カリフォルニアのオペレータSHOULDはこれを避けます)
4.4.2.2. Verification in Case 2
4.4.2.2. 場合2における検証
In case 2, the verifier must get access to the old public key of the CA. The verifier does the following:
場合2では、検証はカリフォルニアの古い公開鍵に近づく手段を得なければなりません。 検証は以下をします:
1. Look up the caCertificate attribute in the repository and pick
the OldWithNew certificate (determined based on validity periods;
note that the subject and issuer fields must match);
1. 倉庫でcaCertificate属性を見上げてください、そして、OldWithNew証明書(有効期間; 対象と発行人分野が合わなければならないことに注意することに基づいて断固とした)を選んでください。
2. Verify that this is correct using the new CA key (which the
verifier has locally);
2. これが新しいカリフォルニアキー(検証が局所的に持っている)を使用することで正しいことを確かめてください。
3. If correct, check the signer's certificate using the old CA key.
3. 正しいなら、古いカリフォルニアキーを使用することで署名者の証明書をチェックしてください。
Case 2 will arise when the CA operator has issued the signer's certificate, then changed the key, and then issued the verifier's certificate; so it is quite a typical case.
カリフォルニアのオペレータが署名者の証明書を発行して、次に、キーを変えて、次に、検証の証明書を発行したとき、ケース2は起こるでしょう。 それで、それはかなり典型的なケースです。
Adams, et al. Standards Track [Page 22] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[22ページ]。
4.4.2.3. Verification in Case 3
4.4.2.3. 場合3における検証
In case 3, the verifier must get access to the new public key of the CA. The verifier does the following:
場合3では、検証はカリフォルニアの新しい公開鍵に近づく手段を得なければなりません。 検証は以下をします:
1. Look up the CACertificate attribute in the repository and pick
the NewWithOld certificate (determined based on validity periods;
note that the subject and issuer fields must match);
1. 倉庫でCACertificate属性を見上げてください、そして、NewWithOld証明書(有効期間; 対象と発行人分野が合わなければならないことに注意することに基づいて断固とした)を選んでください。
2. Verify that this is correct using the old CA key (which the
verifier has stored locally);
2. これが古いカリフォルニアキー(検証が局所的に保存した)を使用することで正しいことを確かめてください。
3. If correct, check the signer's certificate using the new CA key.
3. 正しいなら、新しいカリフォルニアキーを使用することで署名者の証明書をチェックしてください。
Case 3 will arise when the CA operator has issued the verifier's certificate, then changed the key, and then issued the signer's certificate; so it is also quite a typical case.
カリフォルニアのオペレータが検証の証明書を発行して、次に、キーを変えて、次に、署名者の証明書を発行したとき、ケース3は起こるでしょう。 それで、また、それはかなり典型的なケースです。
4.4.2.4. Failure of Verification in Case 6
4.4.2.4. 場合6における検証の失敗
In this case, the CA has issued the verifier's PSE, which contains the new key, without updating the repository attributes. This means that the verifier has no means to get a trustworthy version of the CA's old key and so verification fails.
この場合、倉庫属性をアップデートしないで、カリフォルニアは検証のPSEを発行しました。(PSEは新しいキーを含みます)。 これが、検証にはCAの古いキーの信頼できるバージョンを得る手段が全くないことを意味するので、検証は失敗します。
Note that the failure is the CA operator's fault.
失敗がカリフォルニアのオペレータのせいであることに注意してください。
4.4.2.5. Failure of Verification in Case 7
4.4.2.5. 場合7における検証の失敗
In this case, the CA has issued the signer's certificate protected with the new key without updating the repository attributes. This means that the verifier has no means to get a trustworthy version of the CA's new key and so verification fails.
この場合、カリフォルニアは新しいキーで倉庫属性をアップデートしないで保護された署名者の証明書を発行しました。 これが、検証にはCAの新しいキーの信頼できるバージョンを得る手段が全くないことを意味するので、検証は失敗します。
Note that the failure is again the CA operator's fault.
失敗が再びカリフォルニアのオペレータのせいであることに注意してください。
4.4.3. Revocation - Change of CA Key
4.4.3. 取消し--カリフォルニアキーの変化
As we saw above, the verification of a certificate becomes more complex once the CA is allowed to change its key. This is also true for revocation checks as the CA may have signed the CRL using a newer private key than the one within the user's PSE.
私たちが上を見たように、カリフォルニアがいったんキーを変えることができると、証明書の検証は、より複雑になります。 また、ユーザのPSEの中のものより新しい秘密鍵を使用することでカリフォルニアがCRLに署名したかもしれないので、取消しチェックに、これも本当です。
The analysis of the alternatives is the same as for certificate verification.
代替手段の分析は証明書検証のように同じです。
Adams, et al. Standards Track [Page 23] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[23ページ]。
5. Data Structures
5. データ構造
This section contains descriptions of the data structures required for PKI management messages. Section 6 describes constraints on their values and the sequence of events for each of the various PKI management operations.
このセクションはPKI管理メッセージに必要であるデータ構造の記述を含みます。 セクション6はそれぞれの様々なPKI管理操作のためにそれらの値とイベントの系列で規制について説明します。
5.1. Overall PKI Message
5.1. 総合的なPKIメッセージ
All of the messages used in this specification for the purposes of PKI management use the following structure:
PKI管理の目的にこの仕様で使用されるメッセージのすべてが以下の構造を使用します:
PKIMessage ::= SEQUENCE {
header PKIHeader,
body PKIBody,
protection [0] PKIProtection OPTIONAL,
extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate
OPTIONAL
}
PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage
PKIMessage:、:= SEQUENCE、ヘッダーPKIHeader、ボディーPKIBody、保護[0]PKIProtection OPTIONAL、extraCerts[1]SEQUENCE SIZE(1..MAX)OF CMPCertificate OPTIONAL、PKIMessages:、:= PKIMessageの系列サイズ(1..MAX)
The PKIHeader contains information that is common to many PKI messages.
PKIHeaderは多くのPKIメッセージに共通の情報を含んでいます。
The PKIBody contains message-specific information.
PKIBodyはメッセージ特殊情報を含んでいます。
The PKIProtection, when used, contains bits that protect the PKI message.
使用されると、PKIProtectionはPKIメッセージを保護するビットを含んでいます。
The extraCerts field can contain certificates that may be useful to the recipient. For example, this can be used by a CA or RA to present an end entity with certificates that it needs to verify its own new certificate (if, for example, the CA that issued the end entity's certificate is not a root CA for the end entity). Note that this field does not necessarily contain a certification path; the recipient may have to sort, select from, or otherwise process the extra certificates in order to use them.
extraCerts分野は受取人の役に立つかもしれない証明書を含むことができます。 例えば、カリフォルニアかRAが、証明書があるそれが確かめる必要がある終わりの実体にそれ自身の新しい証明書を提示するのにこれを使用できます(例えば、終わりの実体のために実体の証明書が根でない終わりにカリフォルニアを発行したカリフォルニアであるなら)。 この分野が必ず証明経路を含むというわけではないことに注意してください。 受取人は、それらを使用するために付加的な証明書を分類しなければならないか、選び抜かなければならないか、またはそうでなければ、処理しなければならないかもしれません。
5.1.1. PKI Message Header
5.1.1. PKIメッセージヘッダー
All PKI messages require some header information for addressing and transaction identification. Some of this information will also be present in a transport-specific envelope. However, if the PKI message is protected, then this information is also protected (i.e., we make no assumption about secure transport).
すべてのPKIメッセージがアドレシングとトランザクション識別のための何らかのヘッダー情報を必要とします。 また、この情報のいくつかも輸送特有の封筒に存在するでしょう。 しかしながら、PKIメッセージが保護されるなら、また、この情報は保護されます(すなわち、私たちは安全な輸送に関する仮定を全くしません)。
Adams, et al. Standards Track [Page 24] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[24ページ]。
The following data structure is used to contain this information:
以下のデータ構造はこの情報を含むのに使用されます:
PKIHeader ::= SEQUENCE {
pvno INTEGER { cmp1999(1), cmp2000(2) },
sender GeneralName,
recipient GeneralName,
messageTime [0] GeneralizedTime OPTIONAL,
protectionAlg [1] AlgorithmIdentifier OPTIONAL,
senderKID [2] KeyIdentifier OPTIONAL,
recipKID [3] KeyIdentifier OPTIONAL,
transactionID [4] OCTET STRING OPTIONAL,
senderNonce [5] OCTET STRING OPTIONAL,
recipNonce [6] OCTET STRING OPTIONAL,
freeText [7] PKIFreeText OPTIONAL,
generalInfo [8] SEQUENCE SIZE (1..MAX) OF
InfoTypeAndValue OPTIONAL
}
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
PKIHeader:、:= SEQUENCE、pvno INTEGER、cmp1999(1)、cmp2000(2)、送付者GeneralName、受取人GeneralName、messageTime[0]GeneralizedTime OPTIONAL、protectionAlg[1]AlgorithmIdentifier OPTIONAL、senderKID[2]KeyIdentifier OPTIONAL、recipKID[3]KeyIdentifier OPTIONAL、transactionID[4]OCTET STRING OPTIONAL、senderNonce[5]OCTET STRING OPTIONAL、recipNonce[6]OCTET STRING OPTIONAL、freeText[7]PKIFreeText OPTIONAL、generalInfo[8]SEQUENCE SIZE(1..MAX)OF InfoTypeAndValue OPTIONAL、PKIFreeText:、:= UTF8Stringの系列サイズ(1..MAX)
The pvno field is fixed (at 2) for this version of this specification.
pvno分野はこの仕様のこのバージョンのために修理されています(2時に)。
The sender field contains the name of the sender of the PKIMessage. This name (in conjunction with senderKID, if supplied) should be sufficient to indicate the key to use to verify the protection on the message. If nothing about the sender is known to the sending entity (e.g., in the init. req. message, where the end entity may not know its own Distinguished Name (DN), e-mail name, IP address, etc.), then the "sender" field MUST contain a "NULL" value; that is, the SEQUENCE OF relative distinguished names is of zero length. In such a case, the senderKID field MUST hold an identifier (i.e., a reference number) that indicates to the receiver the appropriate shared secret information to use to verify the message.
送付者分野はPKIMessageの送付者の名前を含んでいます。 この名前(senderKIDであって、供給にされるに関連した)は、メッセージで保護について確かめるのに使用するキーを示すために十分であるべきです。 送付者に関する何も送付実体に知られていないなら(例えば、イニットでは. reqメッセージは終わりの実体がそれ自身のDistinguished Name(DN)を知らないかもしれないところに名前、IPアドレスなどをメールします)、「送付者」分野は「ヌル」の値を含まなければなりません。 すなわち、SEQUENCE OFの相対的な分類名はゼロ・レングスのものです。 このような場合には、senderKID分野はメッセージについて確かめるのに使用するのが適切である共有秘密キー情報を受信機に示す識別子(すなわち、参照番号)を保持しなければなりません。
The recipient field contains the name of the recipient of the PKIMessage. This name (in conjunction with recipKID, if supplied) should be usable to verify the protection on the message.
受取人分野はPKIMessageの受取人の名前を含んでいます。 この名前(recipKIDであって、供給にされるに関連した)はメッセージで保護について確かめるのにおいて使用可能であるべきです。
The protectionAlg field specifies the algorithm used to protect the message. If no protection bits are supplied (note that PKIProtection is OPTIONAL) then this field MUST be omitted; if protection bits are supplied, then this field MUST be supplied.
protectionAlg分野はメッセージを保護するのに使用されるアルゴリズムを指定します。 ノー・プロテクションビットを供給するなら(PKIProtectionがOPTIONALであることに注意してください)、この分野を省略しなければなりません。 保護ビットを供給するなら、この野原を供給しなければなりません。
senderKID and recipKID are usable to indicate which keys have been used to protect the message (recipKID will normally only be required where protection of the message uses Diffie-Hellman (DH) keys).
どのキーがメッセージを保護するのに使用されたかを示すのにおいてsenderKIDとrecipKIDは使用可能です(通常、recipKIDがメッセージの保護がディフィー-ヘルマン(DH)キーを使用するところで必要であるだけでしょう)。
Adams, et al. Standards Track [Page 25] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[25ページ]。
These fields MUST be used if required to uniquely identify a key (e.g., if more than one key is associated with a given sender name) and SHOULD be omitted otherwise.
必要なら、唯一キー(例えば、1個以上のキーが与えられた送付者名に関連しているなら)とSHOULDを特定するのにこれらの分野を使用しなければなりません。別の方法で省略されます。
The transactionID field within the message header is to be used to allow the recipient of a message to correlate this with an ongoing transaction. This is needed for all transactions that consist of more than just a single request/response pair. For transactions that consist of a single request/response pair, the rules are as follows. A client MAY populate the transactionID field of the request. If a server receives such a request that has the transactionID field set, then it MUST set the transactionID field of the response to the same value. If a server receives such request with a missing transactionID field, then it MAY set transactionID field of the response.
メッセージヘッダーの中のtransactionID分野は進行中のトランザクションでこれを関連させるメッセージの受取人を許容するのに使用されることです。 これがちょうど1ただ一つの要求/応答組以上から成るすべてのトランザクションに必要です。 ただ一つの要求/応答組から成るトランザクションにおいて、規則は以下の通りです。 クライアントは要求のtransactionID分野に居住するかもしれません。 サーバがtransactionID分野を設定するそのような要求を受け取るなら、それは同じ値への応答のtransactionID分野を設定しなければなりません。 サーバがなくなったtransactionID分野でそのような要求を受け取るなら、それは応答のtransactionID分野を設定するかもしれません。
For transactions that consist of more than just a single
request/response pair, the rules are as follows. Clients SHOULD
generate a transactionID for the first request. If a server receives
such a request that has the transactionID field set, then it MUST set
the transactionID field of the response to the same value. If a
server receives such request with a missing transactionID field, then
it MUST populate the transactionID field of the response with a
server-generated ID. Subsequent requests and responses MUST all set
the transactionID field to the thus established value. In all cases
where a transactionID is being used, a given client MUST NOT have
more than one transaction with the same transactionID in progress at
any time (to a given server). Servers are free to require uniqueness
of the transactionID or not, as long as they are able to correctly
associate messages with the corresponding transaction. Typically,
this means that a server will require the {client, transactionID}
tuple to be unique, or even the transactionID alone to be unique, if
it cannot distinguish clients based on transport-level information.
A server receiving the first message of a transaction (which requires
more than a single request/response pair) that contains a
transactionID that does not allow it to meet the above constraints
(typically because the transactionID is already in use) MUST send
back an ErrorMsgContent with a PKIFailureInfo of transactionIdInUse.
It is RECOMMENDED that the clients fill the transactionID field with
128 bits of (pseudo-) random data for the start of a transaction to
reduce the probability of having the transactionID in use at the
server.
ちょうど1ただ一つの要求/応答組以上から成るトランザクションにおいて、規則は以下の通りです。 クライアントSHOULDは最初の要求のためにtransactionIDを生成します。 サーバがtransactionID分野を設定するそのような要求を受け取るなら、それは同じ値への応答のtransactionID分野を設定しなければなりません。 サーバがなくなったtransactionID分野でそのような要求を受け取るなら、それはサーバで発生しているIDとの応答のtransactionID分野に居住しなければなりません。 その後の要求と応答はすべて、このようにして設立された値にtransactionID分野を設定しなければなりません。 transactionIDが使用されているすべての場合では、同じtransactionIDが進行していた状態で、与えられたクライアントはいつでも(与えられたサーバに)、1つ以上のトランザクションを持ってはいけません。 サーバは無料でtransactionIDのユニークさを必要とすることができます、それらが対応するトランザクションで正しく副のメッセージにできる限り。 通常サーバが必要とするこの手段、クライアント、transactionIDの特有であるtuple、または輸送レベル情報に基づいたユニークです、それであるならクライアントを区別できないということになるように単独のtransactionIDさえ。 それに上の規制(transactionIDが通常既に使用中であるので)を満たさせないtransactionIDを含むトランザクション(1ただ一つの要求/応答組以上を必要とする)の最初のメッセージを受け取るサーバはtransactionIdInUseのPKIFailureInfoと共にErrorMsgContentを返送しなければなりません。 トランザクションの始まりがサーバで使用中のtransactionIDを持っているという確率を減少させるようにクライアントが128ビットの(疑似な)無作為のデータでtransactionID分野を満たすのは、RECOMMENDEDです。
The senderNonce and recipNonce fields protect the PKIMessage against replay attacks. The senderNonce will typically be 128 bits of (pseudo-) random data generated by the sender, whereas the recipNonce is copied from the senderNonce of the previous message in the transaction.
senderNonceとrecipNonce分野は反射攻撃に対してPKIMessageを保護します。 senderNonceは通常128ビットの(疑似な)無作為のデータに送付者によって生成されたなるでしょうが、recipNonceはトランザクションにおける前のメッセージのsenderNonceからコピーされます。
Adams, et al. Standards Track [Page 26] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[26ページ]。
The messageTime field contains the time at which the sender created the message. This may be useful to allow end entities to correct/check their local time for consistency with the time on a central system.
messageTime分野は送付者がメッセージを作成した時を含んでいます。 これは、終わりの実体が主要なシステムの上の時間に一貫性のための彼らの現地時間について修正するか、または問い合わせるのを許容するために役に立つかもしれません。
The freeText field may be used to send a human-readable message to the recipient (in any number of languages). The first language used in this sequence indicates the desired language for replies.
freeText分野は、受取人(いろいろな言語の)に人間読み込み可能なメッセージを送るのに使用されるかもしれません。 この系列に使用される母国語は回答のために必要な言語を示します。
The generalInfo field may be used to send machine-processable additional data to the recipient. The following generalInfo extensions are defined and MAY be supported.
generalInfo分野は、マシン-「プロセス-可能」の追加データを受取人に送るのに使用されるかもしれません。 以下のgeneralInfo拡張子は、定義されて、サポートされるかもしれません。
5.1.1.1. ImplicitConfirm
5.1.1.1. ImplicitConfirm
This is used by the EE to inform the CA that it does not wish to send a certificate confirmation for issued certificates.
これは、発行された証明書のための証明書確認を送りたがっていないことをカリフォルニアに知らせるのにEEによって使用されます。
implicitConfirm OBJECT IDENTIFIER ::= {id-it 13}
ImplicitConfirmValue ::= NULL
implicitConfirmオブジェクト識別子:、:= イド、-、それ、13、ImplicitConfirmValue:、:= ヌル
If the CA grants the request to the EE, it MUST put the same extension in the PKIHeader of the response. If the EE does not find the extension in the response, it MUST send the certificate confirmation.
カリフォルニアが要求をEEに承諾するなら、それは応答のPKIHeaderに同じ拡大を入れなければなりません。 EEが応答における拡大を見つけないなら、それは証明書確認を送らなければなりません。
5.1.1.2. ConfirmWaitTime
5.1.1.2. ConfirmWaitTime
This is used by the CA to inform the EE how long it intends to wait for the certificate confirmation before revoking the certificate and deleting the transaction.
これは、証明書を取り消して、トランザクションを削除する前にそれがどれくらい長い間証明書確認を待つつもりであるかをEEに知らせるのにカリフォルニアによって使用されます。
confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14}
ConfirmWaitTimeValue ::= GeneralizedTime
confirmWaitTimeオブジェクト識別子:、:= イド、-、それ、14、ConfirmWaitTimeValue:、:= GeneralizedTime
5.1.2. PKI Message Body
5.1.2. PKIメッセージボディー
PKIBody ::= CHOICE {
ir [0] CertReqMessages, --Initialization Req
ip [1] CertRepMessage, --Initialization Resp
cr [2] CertReqMessages, --Certification Req
cp [3] CertRepMessage, --Certification Resp
p10cr [4] CertificationRequest, --PKCS #10 Cert. Req.
popdecc [5] POPODecKeyChallContent --pop Challenge
popdecr [6] POPODecKeyRespContent, --pop Response
kur [7] CertReqMessages, --Key Update Request
kup [8] CertRepMessage, --Key Update Response
krr [9] CertReqMessages, --Key Recovery Req
PKIBody:、:= CHOICE、不-[0]CertReqMessages--初期設定Req ip[1]CertRepMessage--初期設定Resp cr[2]CertReqMessages--証明Req cp[3]CertRepMessage--証明Resp p10cr[4]CertificationRequest、--PKCS#10Cert. Req. popdecc[5]POPODecKeyChallContent--Challenge popdecr[6]POPODecKeyRespContent--大衆的なResponse kur[7]CertReqMessages--主要なUpdate Request kup[8]CertRepMessage--主要なUpdate Response krr[9]CertReqMessages--主要なRecovery Reqを飛び出させてください。
Adams, et al. Standards Track [Page 27] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[27ページ]。
krp [10] KeyRecRepContent, --Key Recovery Resp
rr [11] RevReqContent, --Revocation Request
rp [12] RevRepContent, --Revocation Response
ccr [13] CertReqMessages, --Cross-Cert. Request
ccp [14] CertRepMessage, --Cross-Cert. Resp
ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann.
cann [16] CertAnnContent, --Certificate Ann.
rann [17] RevAnnContent, --Revocation Ann.
crlann [18] CRLAnnContent, --CRL Announcement
pkiconf [19] PKIConfirmContent, --Confirmation
nested [20] NestedMessageContent, --Nested Message
genm [21] GenMsgContent, --General Message
genp [22] GenRepContent, --General Response
error [23] ErrorMsgContent, --Error Message
certConf [24] CertConfirmContent, --Certificate confirm
pollReq [25] PollReqContent, --Polling request
pollRep [26] PollRepContent --Polling response
}
krp[10]KeyRecRepContent--主要なRecovery Resp rr[11]RevReqContent--取消しRequest rp[12]RevRepContent--取消しResponse ccr[13]CertReqMessages--交差している本命です。 ccp[14]CertRepMessageを要求してください--交差している本命。 Resp ckuann15CAKeyUpdAnnContent--カリフォルニアKey Updateアンcann16CertAnnContent--アンrann17RevAnnContentを証明してください--Revocationアン; crlann18CRLAnnContent(--CRL Announcement pkiconf19PKIConfirmContent(確認の入れ子にされた20NestedMessageContent))はMessage genm21GenMsgContentを入れ子にしました--Message司令官は22GenRepContentをgenpします--23ErrorMsgContent(誤りMessage certConf24CertConfirmContent)が証明する一般Response誤りはpollReq25PollReqContentを確認します--投票して、応答に投票して、pollRep26PollRepContentを要求してください。
The specific types are described in Section 5.3 below.
特定のタイプは以下のセクション5.3で説明されます。
5.1.3. PKI Message Protection
5.1.3. PKIメッセージ保護
Some PKI messages will be protected for integrity. (Note that if an asymmetric algorithm is used to protect a message and the relevant public component has been certified already, then the origin of the message can also be authenticated. On the other hand, if the public component is uncertified, then the message origin cannot be automatically authenticated, but may be authenticated via out-of-band means.)
いくつかのPKIメッセージが保全のために保護されるでしょう。 (また、非対称のアルゴリズムがメッセージを保護するのに使用されて、関連公共のコンポーネントが既に公認されたならメッセージの発生源を認証できることに注意してください。 他方では、公共のコンポーネントが非公認されるなら、メッセージ発生源は、自動的に認証できませんが、バンドで出ている手段で認証されるかもしれません。)
When protection is applied, the following structure is used:
保護が適用されているとき、以下の構造は使用されています:
PKIProtection ::= BIT STRING
PKIProtection:、:= ビット列
The input to the calculation of PKIProtection is the DER encoding of the following data structure:
PKIProtectionの計算への入力は以下のデータ構造のDERコード化です:
ProtectedPart ::= SEQUENCE {
header PKIHeader,
body PKIBody
}
ProtectedPart:、:= 系列ヘッダーPKIHeader、ボディーPKIBody
There MAY be cases in which the PKIProtection BIT STRING is deliberately not used to protect a message (i.e., this OPTIONAL field is omitted) because other protection, external to PKIX, will be applied instead. Such a choice is explicitly allowed in this specification. Examples of such external protection include PKCS #7
PKIXに外部であることの他の保護が代わりに適用されるのでPKIProtection BIT STRINGがメッセージを保護するのに故意に使用されない(すなわち、このOPTIONAL分野は省略されます)場合があるかもしれません。 そのような選択はこの仕様で明らかに許されています。 そのような外部の保護に関する例はPKCS#7を含んでいます。
Adams, et al. Standards Track [Page 28] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[28ページ]。
[PKCS7] and Security Multiparts [RFC1847] encapsulation of the PKIMessage (or simply the PKIBody (omitting the CHOICE tag), if the relevant PKIHeader information is securely carried in the external mechanism). It is noted, however, that many such external mechanisms require that the end entity already possesses a public-key certificate, and/or a unique Distinguished Name, and/or other such infrastructure-related information. Thus, they may not be appropriate for initial registration, key-recovery, or any other process with "boot-strapping" characteristics. For those cases it may be necessary that the PKIProtection parameter be used. In the future, if/when external mechanisms are modified to accommodate boot-strapping scenarios, the use of PKIProtection may become rare or non-existent.
または、PKIMessageの[PKCS7]とSecurity Multiparts[RFC1847]カプセル化、(単にPKIBody(CHOICEタグを省略する)関連PKIHeader情報が外部のメカニズムでしっかりと運ばれるなら しかしながら、そのような多くの外部のメカニズムが、終わりの実体には公開鍵証明書、ユニークなDistinguished Name、そして/または、他のそのようなインフラストラクチャ関連の情報が既にあるのを必要とすることに注意されます。 したがって、新規登録、キーリカバリー、またはいかなる他のプロセスにも、それらは特性が「摘み皮」であるのに適切でないかもしれません。 それらのケースに、PKIProtectionパラメタが使用されるのが必要であるかもしれません。 将来、外部のメカニズムであるときに、/が変更されているなら、シナリオ、PKIProtectionの摘み皮の使用を収容するのはまれであるか実在しなくなるかもしれません。
Depending on the circumstances, the PKIProtection bits may contain a Message Authentication Code (MAC) or signature. Only the following cases can occur:
事情によって、PKIProtectionビットはメッセージ立証コード(MAC)か署名を含むかもしれません。 以下のケースしか現れることができません:
5.1.3.1. Shared Secret Information
5.1.3.1. 共有秘密キー情報
In this case, the sender and recipient share secret information (established via out-of-band means or from a previous PKI management operation). PKIProtection will contain a MAC value and the protectionAlg will be the following (see also Appendix D.2):
この場合、送付者と受取人は秘密の情報(バンドで出ている手段か前のPKI管理操作から設立される)を共有します。 PKIProtectionはMAC値を含むでしょう、そして、protectionAlgは以下(また、Appendix D.2を見る)でしょう:
id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13}
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
iterationCount INTEGER,
mac AlgorithmIdentifier
}
イド-PasswordBasedMacオブジェクト識別子:、:= 1 2、840、113533、7、66 13、PBMParameter:、:= 系列塩のOCTET STRING、owf AlgorithmIdentifier、iterationCount INTEGER、mac AlgorithmIdentifier
In the above protectionAlg, the salt value is appended to the shared
secret input. The OWF is then applied iterationCount times, where
the salted secret is the input to the first iteration and, for each
successive iteration, the input is set to be the output of the
previous iteration. The output of the final iteration (called
"BASEKEY" for ease of reference, with a size of "H") is what is used
to form the symmetric key. If the MAC algorithm requires a K-bit key
and K <= H, then the most significant K bits of BASEKEY are used. If
K > H, then all of BASEKEY is used for the most significant H bits of
the key, OWF("1" || BASEKEY) is used for the next most significant H
bits of the key, OWF("2" || BASEKEY) is used for the next most
significant H bits of the key, and so on, until all K bits have been
derived. [Here "N" is the ASCII byte encoding the number N and "||"
represents concatenation.]
上のprotectionAlgでは、塩の値を共有秘密キー入力に追加します。 次に、OWFは適用されたiterationCount回です、辛辣の秘密が最初の繰り返しへの入力であり、入力が前の繰り返しの出力であるようにそれぞれの連続した繰り返しにおいて設定されるところで。 最終的な繰り返し(参照する場合に便利なように「H」のサイズで"BASEKEY"と呼ばれる)の出力は対称鍵を形成するのに使用されることです。 MACアルゴリズムがK-ビットキーを必要として、K<がHと等しいなら、BASEKEYの最も重要なKビットは使用されています。 BASEKEYのすべてがK>Hであるならキーの最も重要なHビットに使用されます、OWF、(「1インチ| | BASEKEY) キーの次の最も重要なHビットに使用される、OWF、(「2インチ| | BASEKEY) すべてのKビットが引き出されるまでキーの次の最も重要なHビットなどに使用される、」 そして、「[「N」がここのNo.Nをコード化するASCIIバイトである、」 | | 」 連結を表す、]
Adams, et al. Standards Track [Page 29] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[29ページ]。
Note: it is RECOMMENDED that the fields of PBMParameter remain constant throughout the messages of a single transaction (e.g., ir/ip/certConf/pkiConf) in order to reduce the overhead associated with PasswordBasedMac computation).
以下に注意してください。 PBMParameterの分野が単一取引に関するメッセージ中で一定のままで残っているのは、RECOMMENDEDです。(例えば、不-/ip/certConf/pkiConf) 減少するために、オーバーヘッドはPasswordBasedMac計算と交際しました)。
5.1.3.2. DH Key Pairs
5.1.3.2. DHの主要なペア
Where the sender and receiver possess Diffie-Hellman certificates with compatible DH parameters, in order to protect the message the end entity must generate a symmetric key based on its private DH key value and the DH public key of the recipient of the PKI message. PKIProtection will contain a MAC value keyed with this derived symmetric key and the protectionAlg will be the following:
送付者と受信機にはコンパチブルDHパラメタがあるディフィー-ヘルマン証明書があるところでは、メッセージを保護するために、終わりの実体は個人的なDHキー値とPKIメッセージの受取人のDH公開鍵に基づく対称鍵を生成しなければなりません。 PKIProtectionはこの派生している対称鍵で合わせられたMAC値を含むでしょう、そして、protectionAlgは以下になるでしょう:
id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30}
イド-DHBasedMacオブジェクト識別子:、:= {1 2 840 113533 7 66 30}
DHBMParameter ::= SEQUENCE {
owf AlgorithmIdentifier,
-- AlgId for a One-Way Function (SHA-1 recommended)
mac AlgorithmIdentifier
-- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
} -- or HMAC [RFC2104, RFC2202])
DHBMParameter:、:= SEQUENCE、owf AlgorithmIdentifier--One-道のFunction(推薦されたSHA-1)mac AlgorithmIdentifierのためのAlgId--MAC AlgId(例えば、DES-MAC、デスMACを3倍にしてください、[PKCS11]HMAC[RFC2104、RFC2202)
In the above protectionAlg, OWF is applied to the result of the
Diffie-Hellman computation. The OWF output (called "BASEKEY" for
ease of reference, with a size of "H") is what is used to form the
symmetric key. If the MAC algorithm requires a K-bit key and K <= H,
then the most significant K bits of BASEKEY are used. If K > H, then
all of BASEKEY is used for the most significant H bits of the key,
OWF("1" || BASEKEY) is used for the next most significant H bits of
the key, OWF("2" || BASEKEY) is used for the next most significant H
bits of the key, and so on, until all K bits have been derived.
[Here "N" is the ASCII byte encoding the number N and "||" represents
concatenation.]
上のprotectionAlgでは、OWFはディフィー-ヘルマンの計算の結果に適用されます。 OWF出力(参照する場合に便利なように「H」のサイズで"BASEKEY"と呼ばれる)は対称鍵を形成するのに使用されることです。 MACアルゴリズムがK-ビットキーを必要として、K<がHと等しいなら、BASEKEYの最も重要なKビットは使用されています。 BASEKEYのすべてがK>Hであるならキーの最も重要なHビットに使用されます、OWF、(「1インチ| | BASEKEY) キーの次の最も重要なHビットに使用される、OWF、(「2インチ| | BASEKEY) すべてのKビットが引き出されるまでキーの次の最も重要なHビットなどに使用される、」 そして、「[「N」がここのNo.Nをコード化するASCIIバイトである、」 | | 」 連結を表す、]
5.1.3.3. Signature
5.1.3.3. 署名
In this case, the sender possesses a signature key pair and simply signs the PKI message. PKIProtection will contain the signature value and the protectionAlg will be an AlgorithmIdentifier for a digital signature (e.g., md5WithRSAEncryption or dsaWithSha-1).
この場合、送付者は、署名主要な組があって、単にPKIメッセージに署名します。 PKIProtectionは署名値を含むでしょう、そして、protectionAlgはデジタル署名(例えば、md5WithRSAEncryptionかdsaWithSha-1)のためにAlgorithmIdentifierになるでしょう。
5.1.3.4. Multiple Protection
5.1.3.4. 多重防護
In cases where an end entity sends a protected PKI message to an RA, the RA MAY forward that message to a CA, attaching its own protection (which MAY be a MAC or a signature, depending on the information and certificates shared between the RA and the CA). This is accomplished
終わりの実体が保護されたPKIメッセージをRAに送る場合では、RA MAYはそのメッセージをカリフォルニアに転送します、それ自身の保護(RAとカリフォルニアの間で共有された情報と証明書によって、MACか署名であるかもしれない)を付けて。 これは優れています。
Adams, et al. Standards Track [Page 30] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[30ページ]。
by nesting the entire message sent by the end entity within a new PKI message. The structure used is as follows.
新しいPKIメッセージの中で終わりの実体によって送られた全体のメッセージを入れ子にすることによって。 使用される構造は以下の通りです。
NestedMessageContent ::= PKIMessages
NestedMessageContent:、:= PKIMessages
(The use of PKIMessages, a SEQUENCE OF PKIMessage, lets the RA batch
the requests of several EEs in a single new message. For simplicity,
all messages in the batch MUST be of the same type (e.g., ir).) If
the RA wishes to modify the message(s) in some way (e.g., add
particular field values or new extensions), then it MAY create its
own desired PKIBody. The original PKIMessage from the EE MAY be
included in the generalInfo field of PKIHeader (to accommodate, for
example, cases in which the CA wishes to check POP or other
information on the original EE message). The infoType to be used in
this situation is {id-it 15} (see Section 5.3.19 for the value of
id-it) and the infoValue is PKIMessages (contents MUST be in the same
order as the requests in PKIBody).
(PKIMessagesの使用(SEQUENCE OF PKIMessage)はシングルで新しい数個のEEsの要求が通信させるRAバッチをさせます。 バッチにおけるすべてのメッセージが同じタイプへの簡単さのための、ものであるに違いない、(例えば、不-、)) RAが何らかの方法でメッセージを変更したいなら(例えば、特定の分野値か新しい拡大を加えてください)、それはそれ自身の必要なPKIBodyを作成するかもしれません。 オリジナルのPKIMessage、EE MAYから、PKIHeader(例えばカリフォルニアがオリジナルのEEメッセージでPOPか他の情報をチェックしたがっている場合を収容する)のgeneralInfo分野で含められてください。 この状況で使用されるべきinfoTypeがそうである、イド、-、それ、15、(値のためのセクション5.3.19を見る、イド、-、それ、)、infoValueはPKIMessages(同次にはPKIBodyでの要求としてコンテンツがあるに違いない)です。
5.2. Common Data Structures
5.2. 一般的なデータ構造
Before specifying the specific types that may be placed in a PKIBody, we define some data structures that are used in more than one case.
PKIBodyに置かれるかもしれない特定のタイプを指定する前に、私たちはより多くのある場合に使用されるいくつかのデータ構造を定義します。
5.2.1. Requested Certificate Contents
5.2.1. 要求された証明書コンテンツ
Various PKI management messages require that the originator of the message indicate some of the fields that are required to be present in a certificate. The CertTemplate structure allows an end entity or RA to specify as much as it wishes about the certificate it requires. CertTemplate is identical to a Certificate, but with all fields optional.
様々なPKI管理メッセージは、メッセージの創始者が証明書に存在しているのに必要である分野のいくつかを示すのを必要とします。 CertTemplate構造で、終わりの実体かRAがそれが必要とする証明書に関して願っているほど指定できます。 CertTemplateはCertificateと同じですが、すべての分野が任意の状態で同じです。
Note that even if the originator completely specifies the contents of a certificate it requires, a CA is free to modify fields within the certificate actually issued. If the modified certificate is unacceptable to the requester, the requester MUST send back a certConf message that either does not include this certificate (via a CertHash), or does include this certificate (via a CertHash) along with a status of "rejected". See Section 5.3.18 for the definition and use of CertHash and the certConf message.
創始者がそれが必要とする証明書のコンテンツを完全に指定しても、カリフォルニアが実際に発行された証明書の中に自由に分野を変更できることに注意してください。 変更された証明書がリクエスタに容認できないなら、リクエスタはどちらかがこの証明書を含んでいないか(CertHashを通して)、または「拒絶されること」の状態と共にこの証明書を含んでいるという(CertHashを通して)certConfメッセージを返送しなければなりません。 CertHashの定義と使用とcertConfメッセージに関してセクション5.3.18を見てください。
See Appendix C and [CRMF] for CertTemplate syntax.
CertTemplate構文に関してAppendix Cと[CRMF]を見てください。
5.2.2. Encrypted Values
5.2.2. 暗号化された値
Where encrypted values (restricted, in this specification, to be either private keys or certificates) are sent in PKI messages, the EncryptedValue data structure is used.
PKIメッセージで暗号化された値(この仕様では、秘密鍵か証明書のどちらかになるように、制限される)を送るところでは、EncryptedValueデータ構造は使用されています。
Adams, et al. Standards Track [Page 31] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[31ページ]。
See [CRMF] for EncryptedValue syntax.
EncryptedValue構文に関して[CRMF]を見てください。
Use of this data structure requires that the creator and intended recipient be able to encrypt and decrypt, respectively. Typically, this will mean that the sender and recipient have, or are able to generate, a shared secret key.
このデータ構造の使用は、クリエイターと意図している受取人ができるのを必要とします。それぞれ暗号化して、解読するために。 通常、これは送付者と受取人が持っているか、または生成することができる平均、共有された秘密鍵がそうするでしょう。
If the recipient of the PKIMessage already possesses a private key usable for decryption, then the encSymmKey field MAY contain a session key encrypted using the recipient's public key.
PKIMessageの受取人に復号化に、使用可能な秘密鍵が既にあるなら、encSymmKey分野は受取人の公開鍵を使用することで暗号化されたセッションキーを含むかもしれません。
5.2.3. Status codes and Failure Information for PKI Messages
5.2.3. PKI MessagesのためのステータスコードとFailure情報
All response messages will include some status information. The following values are defined.
すべての応答メッセージが何らかの状態情報を含むでしょう。 以下の値は定義されます。
PKIStatus ::= INTEGER {
accepted (0),
grantedWithMods (1),
rejection (2),
waiting (3),
revocationWarning (4),
revocationNotification (5),
keyUpdateWarning (6)
}
PKIStatus:、:= 整数(0)、grantedWithMods(1)、拒絶(2)を受け入れて、(3)を待つrevocationWarning(4)、revocationNotification(5)、keyUpdateWarning(6)
Responders may use the following syntax to provide more information about failure cases.
応答者は、失敗事件に関する詳しい情報を提供するのに以下の構文を使用するかもしれません。
PKIFailureInfo ::= BIT STRING {
badAlg (0),
badMessageCheck (1),
badRequest (2),
badTime (3),
badCertId (4),
badDataFormat (5),
wrongAuthority (6),
incorrectData (7),
missingTimeStamp (8),
badPOP (9),
certRevoked (10),
certConfirmed (11),
wrongIntegrity (12),
badRecipientNonce (13),
timeNotAvailable (14),
unacceptedPolicy (15),
unacceptedExtension (16),
addInfoNotAvailable (17),
PKIFailureInfo:、:= ビット列、badAlg(0)、badMessageCheck(1)、badRequest(2)、badTime(3)、badCertId(4)、badDataFormat(5)、wrongAuthority(6)、incorrectData(7)、missingTimeStamp(8)、badPOP(9)、certRevoked(10)、certConfirmed(11)、wrongIntegrity(12)、badRecipientNonce(13)、timeNotAvailable(14)、unacceptedPolicy(15)、unacceptedExtension(16)、addInfoNotAvailable(17)
Adams, et al. Standards Track [Page 32] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[32ページ]。
badSenderNonce (18),
badCertTemplate (19),
signerNotTrusted (20),
transactionIdInUse (21),
unsupportedVersion (22),
notAuthorized (23),
systemUnavail (24),
systemFailure (25),
duplicateCertReq (26)
}
badSenderNonce(18)、badCertTemplate(19)、signerNotTrusted(20)、transactionIdInUse(21)、unsupportedVersion(22)、notAuthorized(23)、systemUnavail(24)、systemFailure(25)、duplicateCertReq(26)
PKIStatusInfo ::= SEQUENCE {
status PKIStatus,
statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL
}
PKIStatusInfo:、:= 系列状態PKIStatus、statusString PKIFreeText OPTIONAL、failInfo PKIFailureInfo OPTIONAL
5.2.4. Certificate Identification
5.2.4. 証明書識別
In order to identify particular certificates, the CertId data structure is used.
特定の証明書を特定するために、CertIdデータ構造は使用されています。
See [CRMF] for CertId syntax.
CertId構文に関して[CRMF]を見てください。
5.2.5. Out-of-band root CA Public Key
5.2.5. バンドの外では、カリフォルニアPublic Keyは根づきます。
Each root CA must be able to publish its current public key via some "out-of-band" means. While such mechanisms are beyond the scope of this document, we define data structures that can support such mechanisms.
各根のカリフォルニアは「バンドの外」といういくつかの手段で現在の公開鍵を発行できなければなりません。 そのようなメカニズムがこのドキュメントの範囲を超えている間、私たちはそのようなメカニズムをサポートできるデータ構造を定義します。
There are generally two methods available: either the CA directly publishes its self-signed certificate, or this information is available via the Directory (or equivalent) and the CA publishes a hash of this value to allow verification of its integrity before use.
一般に、利用可能な2つのメソッドがあります: この情報は、ディレクトリを通して利用可能、そして、(同等)です、そして、カリフォルニアが直接自己署名入りの証書を発表するか、またはカリフォルニアは使用の前に保全の検証を許すためにこの価値のハッシュを発行します。
OOBCert ::= Certificate
OOBCert:、:= 証明書
The fields within this certificate are restricted as follows:
この証明書の中の分野は以下の通り制限されます:
o The certificate MUST be self-signed (i.e., the signature must be
verifiable using the SubjectPublicKeyInfo field);
o 自己に証明書に署名しなければなりません(すなわち、署名はSubjectPublicKeyInfo分野を使用することで証明可能であるに違いありません)。
o The subject and issuer fields MUST be identical;
o 対象と発行人分野は同じであるに違いありません。
o If the subject field is NULL, then both subjectAltNames and
issuerAltNames extensions MUST be present and have exactly the
same value;
o 対象の分野がNULLであるなら、subjectAltNamesとissuerAltNames拡張子の両方が、存在していて、まさに同じ値を持たなければなりません。
Adams, et al. Standards Track [Page 33] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[33ページ]。
o The values of all other extensions must be suitable for a self-
signed certificate (e.g., key identifiers for subject and issuer
must be the same).
o 他のすべての拡大の値は自己署名入りの証書に適しているに違いありません(例えば、対象と発行人に、主要な識別子は同じであるに違いありません)。
OOBCertHash ::= SEQUENCE {
hashAlg [0] AlgorithmIdentifier OPTIONAL,
certId [1] CertId OPTIONAL,
hashVal BIT STRING
}
OOBCertHash:、:= 系列hashAlg[0]AlgorithmIdentifierの任意の、そして、certId[1]CertId任意のhashValビット列
The intention of the hash value is that anyone who has securely received the hash value (via the out-of-band means) can verify a self-signed certificate for that CA.
ハッシュ値の意志はしっかりと、ハッシュ値(バンドで出ている手段を通した)を受けただれでもそのカリフォルニアのための自己署名入りの証書について確かめることができるということです。
5.2.6. Archive Options
5.2.6. アーカイブオプション
Requesters may indicate that they wish the PKI to archive a private key value using the PKIArchiveOptions structure.
リクエスタは、PKIに秘密鍵値を格納してPKIArchiveOptions構造を使用することで欲しいのを示すかもしれません。
See [CRMF] for PKIArchiveOptions syntax.
PKIArchiveOptions構文に関して[CRMF]を見てください。
5.2.7. Publication Information
5.2.7. 公表情報
Requesters may indicate that they wish the PKI to publish a certificate using the PKIPublicationInfo structure.
リクエスタは、PKIに証明書を発表してPKIPublicationInfo構造を使用することで欲しいのを示すかもしれません。
See [CRMF] for PKIPublicationInfo syntax.
PKIPublicationInfo構文に関して[CRMF]を見てください。
5.2.8. Proof-of-Possession Structures
5.2.8. 所有物の証拠構造
If the certification request is for a signing key pair (i.e., a request for a verification certificate), then the proof-of-possession of the private signing key is demonstrated through use of the POPOSigningKey structure.
証明要求が署名重要組(すなわち、検証証明書に関する要求)のためのものであるなら、個人的な署名キー所有物の証拠はPOPOSigningKey構造の使用で示されます。
See Appendix C and [CRMF] for POPOSigningKey syntax, but note that POPOSigningKeyInput has the following semantic stipulations in this specification.
POPOSigningKey構文に関してAppendix Cと[CRMF]を見なさい、ただし、POPOSigningKeyInputがこの仕様に以下の意味約款を持っていることに注意してください。
POPOSigningKeyInput ::= SEQUENCE {
authInfo CHOICE {
sender [0] GeneralName,
publicKeyMAC PKMACValue
},
publicKey SubjectPublicKeyInfo
}
POPOSigningKeyInput:、:= 系列authInfo CHOICE、送付者[0]GeneralName、publicKeyMAC PKMACValue、publicKey SubjectPublicKeyInfo
Adams, et al. Standards Track [Page 34] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[34ページ]。
On the other hand, if the certification request is for an encryption key pair (i.e., a request for an encryption certificate), then the proof-of-possession of the private decryption key may be demonstrated in one of three ways.
他方では、証明要求が暗号化主要な組(すなわち、暗号化証明書に関する要求)のためのものであるなら、個人的な復号化キー所有物の証拠は3つの方法の1つで示されるかもしれません。
5.2.8.1. Inclusion of the Private Key
5.2.8.1. 秘密鍵の包含
By the inclusion of the private key (encrypted) in the CertRequest (in the thisMessage field of POPOPrivKey (see Appendix C) or in the PKIArchiveOptions control structure, depending upon whether or not archival of the private key is also desired).
CertRequest(また、記録保管所であるか否かに関係なく、POPOPrivKey(Appendix Cを見る)かPKIArchiveOptionsの分野が構造、依存を制御するthisMessageでは、秘密鍵は望まれている)での秘密鍵(暗号化される)の包含で。
5.2.8.2. Indirect Method
5.2.8.2. 間接的なメソッド
By having the CA return not the certificate, but an encrypted certificate (i.e., the certificate encrypted under a randomly- generated symmetric key, and the symmetric key encrypted under the public key for which the certification request is being made) -- this is the "indirect" method mentioned previously in Section 4.3.2. The end entity proves knowledge of the private decryption key to the CA by providing the correct CertHash for this certificate in the certConf message. This demonstrates POP because the EE can only compute the correct CertHash if it is able to recover the certificate, and it can only recover the certificate if it is able to decrypt the symmetric key using the required private key. Clearly, for this to work, the CA MUST NOT publish the certificate until the certConf message arrives (when certHash is to be used to demonstrate POP). See Section 5.3.18 for further details.
カリフォルニアを持っていることによって、証明書ではなく、暗号化された証明書(すなわち、手当たりしだいに発生している対称鍵、および証明要求がされている公開鍵の下で暗号化された対称鍵の下で暗号化された証明書)を返してください--これは以前にセクション4.3.2で言及した「間接的な」メソッドです。 終わりの実体は、個人的な復号化に関する知識がcertConfメッセージのこの証明書に正しいCertHashを供給することによってカリフォルニアに主要であると立証します。 証明書を回収できる場合にだけEEが正しいCertHashを計算できるので、これはPOPのデモをします、そして、必要な秘密鍵を使用することで対称鍵を解読することができる場合にだけ、それは証明書を回収できます。 明確に、これが働くように、certConfメッセージが到着するまで(certHashがPOPのデモをするのに使用されることになっているとき)、カリフォルニアは証明書を発表してはいけません。 さらに詳しい明細についてはセクション5.3.18を見てください。
5.2.8.3. Challenge-Response Protocol
5.2.8.3. チャレンジレスポンスプロトコル
By having the end entity engage in a challenge-response protocol (using the messages POPODecKeyChall and POPODecKeyResp; see below) between CertReqMessages and CertRepMessage -- this is the "direct" method mentioned previously in Section 4.3.2. (This method would typically be used in an environment in which an RA verifies POP and then makes a certification request to the CA on behalf of the end entity. In such a scenario, the CA trusts the RA to have done POP correctly before the RA requests a certificate for the end entity.) The complete protocol then looks as follows (note that req' does not necessarily encapsulate req as a nested message):
終わりの実体を持っていることによって、CertReqMessagesとCertRepMessageの間のチャレンジレスポンスプロトコル(メッセージのPOPODecKeyChallとPOPODecKeyRespを使用します; 以下を見る)に従事してください--これは以前にセクション4.3.2で言及した「ダイレクトな」メソッドです。 (このメソッドはRAが終わりの実体を代表してカリフォルニアにPOPについて確かめて、次に証明要求をする環境で通常使用されるでしょう。 そのようなシナリオでは、RAが終わりの実体のための証明書を要求する前にカリフォルニアは、RAが正しくPOPをしたと信じます。) '次に、完全なプロトコルが以下の通りに見える、(そのreqに注意してください、'、必ず入れ子にされたメッセージとしてreqをカプセル化するというわけではない、)、:
Adams, et al. Standards Track [Page 35] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[35ページ]。
EE RA CA
---- req ---->
<--- chall ---
---- resp --->
---- req' --->
<--- rep -----
---- conf --->
<--- ack -----
<--- rep -----
---- conf --->
<--- ack -----
EE RAカリフォルニア---- req----><。--- chall--- ---- resp--->。---- 'req'---><。--- レップ----- ---- conf---><。--- ack----- <-- レップ----- ---- conf---><。--- ack-----
This protocol is obviously much longer than the 3-way exchange given in choice (2) above, but allows a local Registration Authority to be involved and has the property that the certificate itself is not actually created until the proof-of-possession is complete. In some environments, a different order of the above messages may be required, such as the following (this may be determined by policy):
このプロトコルは、3ウェイ交換より明らかにはるかに長い間、選択で(2) 上に与えますが、地方のRegistration Authorityがかかわるのを許容して、所有物の証拠が完全になるまで作成されて、証明書自体が実際にそうでない特性を持っています。 いくつかの環境で、上記のメッセージの異なった注文を必要とするかもしれません、以下などのように(これは方針で決定するかもしれません):
EE RA CA
---- req ---->
<--- chall ---
---- resp --->
---- req' --->
<--- rep -----
<--- rep -----
---- conf --->
---- conf --->
<--- ack -----
<--- ack -----
EE RAカリフォルニア---- req----><。--- chall--- ---- resp--->。---- 'req'---><。--- レップ----- <-- レップ----- ---- conf--->。---- conf---><。--- ack----- <-- ack-----
If the cert. request is for a key agreement key (KAK) pair, then the POP can use any of the 3 ways described above for enc. key pairs, with the following changes: (1) the parenthetical text of bullet 2) is replaced with "(i.e., the certificate encrypted under the symmetric key derived from the CA's private KAK and the public key for which the certification request is being made)"; (2) the first parenthetical text of the challenge field of "Challenge" below is replaced with "(using PreferredSymmAlg (see Section 5.3.19.4 and Appendix E.5) and a symmetric key derived from the CA's private KAK and the public key for which the certification request is being made)". Alternatively, the POP can use the POPOSigningKey structure given in [CRMF] (where the alg field is DHBasedMAC and the signature field is the MAC) as a fourth alternative for demonstrating POP if the CA already has a D-H certificate that is known to the EE.
本命であるなら. 要求は主要な協定主要な(KAK)組のためのものです、次に、POPは上にenc主要な組述べられた3つの方法のどれかを使用できます、以下の変化で: (1) 弾丸2)の挿入句のテキストを「(すなわち、CAの個人的なKAKから得られた対称鍵の下で暗号化された証明書と証明要求がされている公開鍵)」に取り替えます。 (2) 以下の「挑戦」の挑戦分野の最初の挿入句のテキストを「(PreferredSymmAlg(セクション5.3.19の.4とAppendix E.5を見る)を使用して、CAの個人的なKAKから得られた対称鍵と証明要求がされている公開鍵)」に取り替えます。 あるいはまた、POPは、カリフォルニアにEEにおいて知られているD-H証明書が既にあるならPOPのデモをするのに4分の1に代替として[CRMF](alg分野がDHBasedMACであり、署名分野がMACであるところ)で与えられたPOPOSigningKey構造を使用できます。
Adams, et al. Standards Track [Page 36] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[36ページ]。
The challenge-response messages for proof-of-possession of a private decryption key are specified as follows (see [MvOV97], p.404 for details). Note that this challenge-response exchange is associated with the preceding cert. request message (and subsequent cert. response and confirmation messages) by the transactionID used in the PKIHeader and by the protection (MACing or signing) applied to the PKIMessage.
個人的な復号化キー所有物の証拠へのチャレンジレスポンスメッセージは以下の通り指定されます(詳細に関して[MvOV97]、p.404を見てください)。 このチャレンジレスポンス交換が前の本命に関連していることに注意してください。PKIHeaderで使用されるtransactionIDと保護(MACingか署名)による要求メッセージ(そして、その後の本命応答と確認メッセージ)はPKIMessageに申し込まれました。
POPODecKeyChallContent ::= SEQUENCE OF Challenge
Challenge ::= SEQUENCE {
owf AlgorithmIdentifier OPTIONAL,
witness OCTET STRING,
challenge OCTET STRING
}
POPODecKeyChallContent:、:= 挑戦の系列は以下に挑戦します:= 系列owf AlgorithmIdentifier OPTIONAL(目撃者OCTET STRING)はOCTET STRINGに挑戦します。
Note that the size of Rand needs to be appropriate for encryption under the public key of the requester. Given that "int" will typically not be longer than 64 bits, this leaves well over 100 bytes of room for the "sender" field when the modulus is 1024 bits. If, in some environment, names are so long that they cannot fit (e.g., very long DNs), then whatever portion will fit should be used (as long as it includes at least the common name, and as long as the receiver is able to deal meaningfully with the abbreviation).
Randのサイズが、リクエスタの公開鍵の下で暗号化に適切である必要に注意してください。 係数が1024ビットであるときに、"int"が64ビットより通常長くなくなるなら、これは「送付者」分野の余地の100バイト以上をよく残します。 名前が非常に長いので、何らかの環境で、(例えば、非常に長いDNs)に合うことができないなら、合うどんな部分も使用されるべきです(少なくとも一般名を含んでいるのと同じくらい長い、受信機が意味深長に略語に対処できる限り)。
POPODecKeyRespContent ::= SEQUENCE OF INTEGER
POPODecKeyRespContent:、:= 整数の系列
5.2.8.4. Summary of PoP Options
5.2.8.4. 大衆的なオプションの概要
The text in this section provides several options with respect to POP techniques. Using "SK" for "signing key", "EK" for "encryption key", and "KAK" for "key agreement key", the techniques may be summarized as follows:
このセクションのテキストはPOPのテクニックに関していくつかのオプションを提供します。 「署名キー」のための"SK"、「暗号化キー」のための"EK"、および「主要な協定キー」のための「カク」を使用して、テクニックは以下の通りまとめられるかもしれません:
RAVerified;
SKPOP;
EKPOPThisMessage;
KAKPOPThisMessage;
KAKPOPThisMessageDHMAC;
EKPOPEncryptedCert;
KAKPOPEncryptedCert;
EKPOPChallengeResp; and
KAKPOPChallengeResp.
RAVerified。 SKPOP。 EKPOPThisMessage。 KAKPOPThisMessage。 KAKPOPThisMessageDHMAC。 EKPOPEncryptedCert。 KAKPOPEncryptedCert。 EKPOPChallengeResp。 そして、KAKPOPChallengeResp。
Given this array of options, it is natural to ask how an end entity can know what is supported by the CA/RA (i.e., which options it may use when requesting certificates). The following guidelines should clarify this situation for EE implementers.
オプションのこの勢ぞろいを考えて、終わりの実体が、何がカリフォルニア/RAによってサポートされるかを(証明書を要求するとき、すなわち、それはどのオプションを使用するかもしれませんか)どうしたら知ることができるかを尋ねるのは当然です。 以下のガイドラインはEE implementersのためにこの状況をはっきりさせるべきです。
Adams, et al. Standards Track [Page 37] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[37ページ]。
RAVerified. This is not an EE decision; the RA uses this if and only if it has verified POP before forwarding the request on to the CA, so it is not possible for the EE to choose this technique.
RAVerified。 これはEE決定ではありません。 RAがこれを使用する、単に、カリフォルニア(EEがこのテクニックを選ぶのが、可能でないそう)に要求を転送する前に、それはPOPについて確かめました。
SKPOP. If the EE has a signing key pair, this is the only POP method specified for use in the request for a corresponding certificate.
SKPOP。 EEに署名重要組があるなら、これは要求における、対応する証明書の使用に指定された唯一のPOPメソッドです。
EKPOPThisMessage and KAKPOPThisMessage. Whether or not to give up its private key to the CA/RA is an EE decision. If the EE decides to reveal its key, then these are the only POP methods available in this specification to achieve this (and the key pair type will determine which of these two methods to use).
EKPOPThisMessageとKAKPOPThisMessage。 カリフォルニア/RAに秘密鍵をあきらめるかどうかが、EE決定です。 EEが、キーを明らかにすると決めるなら、これらはこれを達成するこの仕様で利用可能な唯一のPOPメソッド(主要な組タイプは、これらの2つのメソッドのどれを使用するかを決心する)です。
KAKPOPThisMessageDHMAC. The EE can only use this method if (1) the CA has a DH certificate available for this purpose, and (2) the EE already has a copy of this certificate. If both these conditions hold, then this technique is clearly supported and may be used by the EE, if desired.
KAKPOPThisMessageDHMAC。 (2) (1) カリフォルニアにこの目的に利用可能なDH証明書がある場合にだけ、EEはこのメソッドを使用できます、そして、EEには、この証明書のコピーが既にあります。 これらの状態の両方が成立するなら、望まれているなら、このテクニックは、明確にサポートされて、EEによって使用されるかもしれません。
EKPOPEncryptedCert, KAKPOPEncryptedCert, EKPOPChallengeResp, KAKPOPChallengeResp. The EE picks one of these (in the subsequentMessage field) in the request message, depending upon preference and key pair type. The EE is not doing POP at this point; it is simply indicating which method it wants to use. Therefore, if the CA/RA replies with a "badPOP" error, the EE can re-request using the other POP method chosen in subsequentMessage. Note, however, that this specification encourages the use of the EncryptedCert choice and, furthermore, says that the challenge-response would typically be used when an RA is involved and doing POP verification. Thus, the EE should be able to make an intelligent decision regarding which of these POP methods to choose in the request message.
EKPOPEncryptedCert、KAKPOPEncryptedCert、EKPOPChallengeResp、KAKPOPChallengeResp。 EEは要求メッセージでこれら(subsequentMessage分野の)の1つを選びます、好みと主要な組タイプに頼っていて。 EEはここにPOPをしていません。 それは、どのメソッドを使用したいかを単に示しています。 したがって、再要求がsubsequentMessageで選ばれたもう片方のPOPメソッドを使用して、カリフォルニア/RAが"badPOP"誤りで返答するなら、EEは返答できます。 しかしながら、この仕様がEncryptedCert選択の使用を奨励して、その上、チャレンジレスポンスが通常、RAがかかわるとき、使用されて、POP検証をすることであると言うことに注意してください。 したがって、EEは要求メッセージでこれらのPOPメソッドのどれを選んだらよいかに関する知的な決定をするはずであることができます。
5.3. Operation-Specific Data Structures
5.3. 操作特有のデータ構造
5.3.1. Initialization Request
5.3.1. 初期設定要求
An Initialization request message contains as the PKIBody a CertReqMessages data structure, which specifies the requested certificate(s). Typically, SubjectPublicKeyInfo, KeyId, and Validity are the template fields which may be supplied for each certificate requested (see Appendix D profiles for further information). This message is intended to be used for entities when first initializing into the PKI.
初期設定要求メッセージはPKIBodyとしてCertReqMessagesデータ構造を含んでいます。(それは、要求された証明書を指定します)。 SubjectPublicKeyInfo、KeyId、およびValidityは通常、要求された各証明書に供給されるかもしれないテンプレート野原(詳細のためのAppendix Dプロフィールを見る)です。 最初にPKIに初期設定するとき、実体にこのメッセージが使用されることを意図します。
See Appendix C and [CRMF] for CertReqMessages syntax.
CertReqMessages構文に関してAppendix Cと[CRMF]を見てください。
Adams, et al. Standards Track [Page 38] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[38ページ]。
5.3.2. Initialization Response
5.3.2. 初期設定応答
An Initialization response message contains as the PKIBody an CertRepMessage data structure, which has for each certificate requested a PKIStatusInfo field, a subject certificate, and possibly a private key (normally encrypted with a session key, which is itself encrypted with the protocolEncrKey).
各証明書がPKIStatusInfo分野、対象の証明書、およびことによると秘密鍵(通常、protocolEncrKeyと共に暗号化されるセッションキーで暗号化される)を要求したので、初期設定応答メッセージはPKIBodyとしてそうしたCertRepMessageデータ構造を含んでいます。
See Section 5.3.4 for CertRepMessage syntax. Note that if the PKI Message Protection is "shared secret information" (see Section 5.1.3), then any certificate transported in the caPubs field may be directly trusted as a root CA certificate by the initiator.
CertRepMessage構文に関してセクション5.3.4を見てください。 caPubs分野で輸送されたどんな証明書もPKI Message Protectionが「共有秘密キー情報」(セクション5.1.3を見る)であるなら創始者による根のカリフォルニア証明書として直接信じられるかもしれないことに注意してください。
5.3.3. Certification Request
5.3.3. 証明要求
A Certification request message contains as the PKIBody a CertReqMessages data structure, which specifies the requested certificates. This message is intended to be used for existing PKI entities who wish to obtain additional certificates.
Certification要求メッセージはPKIBodyとしてCertReqMessagesデータ構造を含んでいます。(それは、要求された証明書を指定します)。 追加証明書を入手することを願っている既存のPKI実体にこのメッセージが使用されることを意図します。
See Appendix C and [CRMF] for CertReqMessages syntax.
CertReqMessages構文に関してAppendix Cと[CRMF]を見てください。
Alternatively, the PKIBody MAY be a CertificationRequest (this structure is fully specified by the ASN.1 structure CertificationRequest given in [PKCS10]). This structure may be required for certificate requests for signing key pairs when interoperation with legacy systems is desired, but its use is strongly discouraged whenever not absolutely necessary.
あるいはまた、PKIBodyはCertificationRequestであるかもしれません(この構造は[PKCS10]で与えられているASN.1構造CertificationRequestによって完全に指定されます)。 レガシーシステムがあるinteroperationが望まれているとき、この構造が主要な組に署名するのを求める証明書要求に必要であるかもしれませんが、絶対に必要でないときはいつも、使用は強くお勧めできないです。
5.3.4. Certification Response
5.3.4. 証明応答
A Certification response message contains as the PKIBody a CertRepMessage data structure, which has a status value for each certificate requested, and optionally has a CA public key, failure information, a subject certificate, and an encrypted private key.
Certification応答メッセージは、PKIBodyとしてCertRepMessageデータ構造を含んでいて、任意にカリフォルニア公開鍵、失敗情報、対象の証明書、および暗号化された秘密鍵を持っています。(データ構造は各証明書のための状態値を要求します)。
CertRepMessage ::= SEQUENCE {
caPubs [1] SEQUENCE SIZE (1..MAX) OF Certificate
OPTIONAL,
response SEQUENCE OF CertResponse
}
CertRepMessage:、:= 系列caPubs[1]SEQUENCE SIZE(1..MAX)OF Certificate OPTIONAL、応答SEQUENCE OF CertResponse
CertResponse ::= SEQUENCE {
certReqId INTEGER,
status PKIStatusInfo,
certifiedKeyPair CertifiedKeyPair OPTIONAL,
rspInfo OCTET STRING OPTIONAL
-- analogous to the id-regInfo-utf8Pairs string defined
CertResponse:、:= SEQUENCE、certReqId INTEGER、状態PKIStatusInfo、certifiedKeyPair CertifiedKeyPair OPTIONAL、定義されたイド-regInfo-utf8Pairsストリングへの類似のrspInfo OCTET STRING OPTIONAL
Adams, et al. Standards Track [Page 39] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[39ページ]。
-- for regInfo in CertReqMsg [CRMF]
}
-- CertReqMsg[CRMF]のregInfo
CertifiedKeyPair ::= SEQUENCE {
certOrEncCert CertOrEncCert,
privateKey [0] EncryptedValue OPTIONAL,
-- see [CRMF] for comment on encoding
publicationInfo [1] PKIPublicationInfo OPTIONAL
}
CertifiedKeyPair:、:= 系列certOrEncCert CertOrEncCert、privateKey[0]EncryptedValue OPTIONAL--publicationInfo[1]PKIPublicationInfo OPTIONALをコード化するコメントに関して[CRMF]を見てください。
CertOrEncCert ::= CHOICE {
certificate [0] Certificate,
encryptedCert [1] EncryptedValue
}
CertOrEncCert:、:= 選択証明書[0]証明書、encryptedCert[1]EncryptedValue
Only one of the failInfo (in PKIStatusInfo) and certificate (in CertifiedKeyPair) fields can be present in each CertResponse (depending on the status). For some status values (e.g., waiting), neither of the optional fields will be present.
failInfo(PKIStatusInfoの)と証明書(CertifiedKeyPairの)分野の1つだけが各CertResponseに存在している場合があります(状態によって)。 いくつかの状態値(例えば、待ち)のために、任意の分野のどちらも存在しないでしょう。
Given an EncryptedCert and the relevant decryption key, the certificate may be obtained. The purpose of this is to allow a CA to return the value of a certificate, but with the constraint that only the intended recipient can obtain the actual certificate. The benefit of this approach is that a CA may reply with a certificate even in the absence of a proof that the requester is the end entity that can use the relevant private key (note that the proof is not obtained until the certConf message is received by the CA). Thus, the CA will not have to revoke that certificate in the event that something goes wrong with the proof-of-possession (but MAY do so anyway, depending upon policy).
EncryptedCertと関連復号化キーを考えて、証明書を入手するかもしれません。 この目的はカリフォルニアが証明書の値を返しますが、意図している受取人だけがそうすることができるという規制で実際の証明書を入手するのを許容することです。 このアプローチの恩恵はカリフォルニアがリクエスタが関連秘密鍵を使用できる終わりの実体(certConfメッセージがカリフォルニアによって受け取られるまで証拠が得られないことに注意する)であるという証拠がないときでさえ証明書で返答するかもしれないということです。 したがって、何かが所有物の証拠(しかし、方針によって、そうとにかくするかもしれない)で支障をきたすと、カリフォルニアはその証明書を取り消す必要はないでしょう。
5.3.5. Key Update Request Content
5.3.5. 主要な更新要求内容
For key update requests the CertReqMessages syntax is used. Typically, SubjectPublicKeyInfo, KeyId, and Validity are the template fields that may be supplied for each key to be updated. This message is intended to be used to request updates to existing (non-revoked and non-expired) certificates (therefore, it is sometimes referred to as a "Certificate Update" operation). An update is a replacement certificate containing either a new subject public key or the current subject public key (although the latter practice may not be appropriate for some environments).
主要な更新要求において、CertReqMessages構文は使用されています。 SubjectPublicKeyInfo、KeyId、およびValidityは通常、各キーをアップデートするために供給されるかもしれないテンプレート野原です。 既存(非取り消されて非満期の)の証明書にアップデートを要求するのにこのメッセージが使用されることを意図します(したがって、それは時々「証明書最新版」操作と呼ばれます)。 アップデートは新しい対象の公開鍵か現在の対象の公開鍵のどちらかを含む交換証明書(いくつかの環境には、後者の習慣は適切でないかもしれませんが)です。
See Appendix C and [CRMF] for CertReqMessages syntax.
CertReqMessages構文に関してAppendix Cと[CRMF]を見てください。
Adams, et al. Standards Track [Page 40] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[40ページ]。
5.3.6. Key Update Response Content
5.3.6. 主要なアップデート応答内容
For key update responses, the CertRepMessage syntax is used. The response is identical to the initialization response.
主要なアップデート応答において、CertRepMessage構文は使用されています。 応答は初期化応答と同じです。
See Section 5.3.4 for CertRepMessage syntax.
CertRepMessage構文に関してセクション5.3.4を見てください。
5.3.7. Key Recovery Request Content
5.3.7. キーリカバリー要求内容
For key recovery requests the syntax used is identical to the initialization request CertReqMessages. Typically, SubjectPublicKeyInfo and KeyId are the template fields that may be used to supply a signature public key for which a certificate is required (see Appendix D profiles for further information).
キーリカバリー要求において、使用される構文は初期化要求CertReqMessagesと同じです。 SubjectPublicKeyInfoとKeyIdは通常、証明書が必要である署名公開鍵を供給するのに使用されるかもしれないテンプレート分野(詳細のためのAppendix Dプロフィールを見る)です。
See Appendix C and [CRMF] for CertReqMessages syntax. Note that if a key history is required, the requester must supply a Protocol Encryption Key control in the request message.
CertReqMessages構文に関してAppendix Cと[CRMF]を見てください。 主要な歴史が必要であるなら、リクエスタが要求メッセージにおけるプロトコルEncryption Keyコントロールを供給しなければならないことに注意してください。
5.3.8. Key Recovery Response Content
5.3.8. キーリカバリー応答内容
For key recovery responses, the following syntax is used. For some status values (e.g., waiting) none of the optional fields will be present.
キーリカバリー応答において、以下の構文は使用されています。 いくつかの状態値(例えば、待ち)のために、任意の分野のいずれも存在しないでしょう。
KeyRecRepContent ::= SEQUENCE {
status PKIStatusInfo,
newSigCert [0] Certificate OPTIONAL,
caCerts [1] SEQUENCE SIZE (1..MAX) OF
Certificate OPTIONAL,
keyPairHist [2] SEQUENCE SIZE (1..MAX) OF
CertifiedKeyPair OPTIONAL
}
KeyRecRepContent:、:= 系列状態PKIStatusInfo、newSigCert[0]はOPTIONALを証明します、caCerts[1]SEQUENCE SIZE(1..MAX)OF Certificate OPTIONAL、keyPairHist[2]SEQUENCE SIZE(1..MAX)OF CertifiedKeyPair OPTIONAL
5.3.9. Revocation Request Content
5.3.9. 取消し要求内容
When requesting revocation of a certificate (or several certificates), the following data structure is used. The name of the requester is present in the PKIHeader structure.
証明書(または、いくつかの証明書)の取消しを要求するとき、以下のデータ構造は使用されています。 リクエスタの名前はPKIHeader構造に存在しています。
RevReqContent ::= SEQUENCE OF RevDetails
RevReqContent:、:= RevDetailsの系列
RevDetails ::= SEQUENCE {
certDetails CertTemplate,
crlEntryDetails Extensions OPTIONAL
}
RevDetails:、:= 系列certDetails CertTemplate、crlEntryDetails拡張子、任意
Adams, et al. Standards Track [Page 41] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[41ページ]。
5.3.10. Revocation Response Content
5.3.10. 取消し応答内容
The revocation response is the response to the above message. If produced, this is sent to the requester of the revocation. (A separate revocation announcement message MAY be sent to the subject of the certificate for which revocation was requested.)
取消し応答は上記のメッセージへの応答です。 生産するなら、取消しのリクエスタにこれを送ります。 (別々の取消し発表メッセージを取消しが要求された証明書の対象に送るかもしれません。)
RevRepContent ::= SEQUENCE {
status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo,
revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL,
crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList
OPTIONAL
}
RevRepContent:、:= 系列状態SEQUENCE SIZE(1..MAX)OF PKIStatusInfo、revCerts[0]SEQUENCE SIZE(1..MAX)OF CertId OPTIONAL、crls[1]SEQUENCE SIZE(1..MAX)OF CertificateList OPTIONAL
5.3.11. Cross Certification Request Content
5.3.11. 相互認証要求内容
Cross certification requests use the same syntax (CertReqMessages) as normal certification requests, with the restriction that the key pair MUST have been generated by the requesting CA and the private key MUST NOT be sent to the responding CA. This request MAY also be used by subordinate CAs to get their certificates signed by the parent CA.
相互認証要求は通常の証明要求と同じ構文(CertReqMessages)を使用します、要求カリフォルニアが主要な組を発生させたに違いなくて、応じるカリフォルニアに秘密鍵を送ってはいけないという制限で。 また、親カリフォルニアを彼らの証明書にサインさせるのにこの要求は下位のCAsによって使用されるかもしれません。
See Appendix C and [CRMF] for CertReqMessages syntax.
CertReqMessages構文に関してAppendix Cと[CRMF]を見てください。
5.3.12. Cross Certification Response Content
5.3.12. 相互認証応答内容
Cross certification responses use the same syntax (CertRepMessage) as normal certification responses, with the restriction that no encrypted private key can be sent.
相互認証応答は通常の証明応答と同じ構文(CertRepMessage)を使用します、コード化された秘密鍵を全く送ることができないという制限で。
See Section 5.3.4 for CertRepMessage syntax.
CertRepMessage構文に関してセクション5.3.4を見てください。
5.3.13. CA Key Update Announcement Content
5.3.13. カリフォルニアの主要なアップデート発表内容
When a CA updates its own key pair, the following data structure MAY be used to announce this event.
カリフォルニアがそれ自身の主要な組をアップデートするとき、以下のデータ構造は、この出来事を発表するのに使用されるかもしれません。
CAKeyUpdAnnContent ::= SEQUENCE {
oldWithNew Certificate,
newWithOld Certificate,
newWithNew Certificate
}
CAKeyUpdAnnContent:、:= 系列newWithOldが、newWithNewが証明すると証明するoldWithNew証明書
Adams, et al. Standards Track [Page 42] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[42ページ]。
5.3.14. Certificate Announcement
5.3.14. 証明書発表
This structure MAY be used to announce the existence of certificates.
この構造は、証明書の存在を発表するのに使用されるかもしれません。
Note that this message is intended to be used for those cases (if any) where there is no pre-existing method for publication of certificates; it is not intended to be used where, for example, X.500 is the method for publication of certificates.
それらのケースに証明書の公表のための方法を先在させてはいけないところでこのメッセージが使用されることを(もしあれば)意図することに注意してください。 例えば、X.500が証明書の公表のための方法であるところでそれが使用されることを意図しません。
CertAnnContent ::= Certificate
CertAnnContent:、:= 証明書
5.3.15. Revocation Announcement
5.3.15. 取消し発表
When a CA has revoked, or is about to revoke, a particular certificate, it MAY issue an announcement of this (possibly upcoming) event.
カリフォルニアが特定の証明書を取り消して、取り消そうとしているとき、それはこの(ことによると今度)の出来事の発表を発行するかもしれません。
RevAnnContent ::= SEQUENCE {
status PKIStatus,
certId CertId,
willBeRevokedAt GeneralizedTime,
badSinceDate GeneralizedTime,
crlDetails Extensions OPTIONAL
}
RevAnnContent:、:= 系列状態PKIStatus、certId CertId、willBeRevokedAt GeneralizedTime、badSinceDate GeneralizedTime、crlDetails Extensions OPTIONAL
A CA MAY use such an announcement to warn (or notify) a subject that its certificate is about to be (or has been) revoked. This would typically be used where the request for revocation did not come from the subject concerned.
カリフォルニアは、証明書が取り消されようとしている(または、あった)と対象に警告すること(通知する)にそのような発表を使用するかもしれません。 これは取消しを求める要求が関する対象から来なかったところで通常使用されるでしょう。
The willBeRevokedAt field contains the time at which a new entry will be added to the relevant CRLs.
willBeRevokedAt分野は新しいエントリーが関連CRLsに加えられる時を含んでいます。
5.3.16. CRL Announcement
5.3.16. CRL発表
When a CA issues a new CRL (or set of CRLs) the following data structure MAY be used to announce this event.
カリフォルニアが新しいCRL(または、CRLsのセット)を発行するとき、以下のデータ構造は、この出来事を発表するのに使用されるかもしれません。
CRLAnnContent ::= SEQUENCE OF CertificateList
CRLAnnContent:、:= CertificateListの系列
5.3.17. PKI Confirmation Content
5.3.17. PKI確認内容
This data structure is used in the protocol exchange as the final PKIMessage. Its content is the same in all cases -- actually there is no content since the PKIHeader carries all the required information.
このデータ構造は最終的なPKIMessageとしてプロトコル交換に使用されます。 内容はすべての場合で同じです--PKIHeaderがすべての必須情報を運ぶので、内容が全く実際にありません。
PKIConfirmContent ::= NULL
PKIConfirmContent:、:= ヌル
Adams, et al. Standards Track [Page 43] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[43ページ]。
Use of this message for certificate confirmation is NOT RECOMMENDED; certConf SHOULD be used instead. Upon receiving a PKIConfirm for a certificate response, the recipient MAY treat it as a certConf with all certificates being accepted.
このメッセージの証明書確認の使用はNOT RECOMMENDEDです。 certConf SHOULD、代わりに使用されてください。 証明書応答のためにPKIConfirmを受けると、受取人はcertConfとしてすべての証明書を受け入れていてそれを扱うかもしれません。
5.3.18. Certificate Confirmation Content
5.3.18. 証明書確認内容
This data structure is used by the client to send a confirmation to the CA/RA to accept or reject certificates.
このデータ構造は、証明書を受け入れるか、または拒絶するためにカリフォルニア/RAに確認を送るのにクライアントによって使用されます。
CertConfirmContent ::= SEQUENCE OF CertStatus
CertConfirmContent:、:= CertStatusの系列
CertStatus ::= SEQUENCE {
certHash OCTET STRING,
certReqId INTEGER,
statusInfo PKIStatusInfo OPTIONAL
}
CertStatus:、:= 系列certReqId整数の、そして、statusInfo PKIStatusInfo任意のcertHash八重奏ストリング
For any particular CertStatus, omission of the statusInfo field indicates ACCEPTANCE of the specified certificate. Alternatively, explicit status details (with respect to acceptance or rejection) MAY be provided in the statusInfo field, perhaps for auditing purposes at the CA/RA.
どんな特定のCertStatusに関してはも、statusInfo分野の省略は指定された証明書のACCEPTANCEを示します。 あるいはまた、明白な状態詳細(承認か拒絶に関する)はstatusInfo分野に明らかにされるかもしれません、恐らくカリフォルニア/RAで目的を監査するために。
Within CertConfirmContent, omission of a CertStatus structure corresponding to a certificate supplied in the previous response message indicates REJECTION of the certificate. Thus, an empty CertConfirmContent (a zero-length SEQUENCE) MAY be used to indicate rejection of all supplied certificates. See Section 5.2.8, item (2), for a discussion of the certHash field with respect to proof-of- possession.
CertConfirmContentの中では、前の応答メッセージで提供された証明書に対応するCertStatus構造の省略は証明書のREJECTIONを示します。 したがって、空のCertConfirmContent(無の長さのSEQUENCE)は、すべての拒絶が証明書を提供したのを示すのに使用されるかもしれません。 certHash分野の議論に関して証拠に関してセクション5.2.8、項目(2)を見てください、-、所有物について。
5.3.19. PKI General Message Content
5.3.19. PKI一般教書内容
InfoTypeAndValue ::= SEQUENCE {
infoType OBJECT IDENTIFIER,
infoValue ANY DEFINED BY infoType OPTIONAL
}
-- where {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4}
GenMsgContent ::= SEQUENCE OF InfoTypeAndValue
InfoTypeAndValue:、:= SEQUENCE、infoType OBJECT IDENTIFIER、infoValue、どんなDEFINED BY infoType OPTIONAL、も--、どこ、イド、-、それ、= イド-pkix4は1 3 6 1 5 5 7 4GenMsgContentと等しいです:、:= InfoTypeAndValueの系列
5.3.19.1. CA Protocol Encryption Certificate
5.3.19.1. カリフォルニアプロトコル暗号化証明書
This MAY be used by the EE to get a certificate from the CA to use to protect sensitive information during the protocol.
これは、プロトコルの間、機密情報を保護するのにカリフォルニアから使用まで証明書を手に入れるEEによって使用されるかもしれません。
Adams, et al. Standards Track [Page 44] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[44ページ]。
GenMsg: {id-it 1}, < absent >
GenRep: {id-it 1}, Certificate | < absent >
GenMsg: イド、-、それ、1、>GenRepのない<: イド、-、それ、1、証明書| >のない<。
EEs MUST ensure that the correct certificate is used for this purpose.
EEsは、正しい証明書がこのために使用されるのを確実にしなければなりません。
5.3.19.2. Signing Key Pair Types
5.3.19.2. 主要な組タイプにサインします。
This MAY be used by the EE to get the list of signature algorithms (e.g., RSA, DSA) whose subject public key values the CA is willing to certify. Note that for the purposes of this exchange, rsaEncryption and rsaWithSHA1, for example, are considered to be equivalent; the question being asked is, "Is the CA willing to certify an RSA public key?"
これは、カリフォルニアが公認しても構わないと対象の公開鍵値を思っている署名アルゴリズム(例えば、RSA、DSA)のリストを得るのにEEによって使用されるかもしれません。 この交換の目的のために、例えば、rsaEncryptionとrsaWithSHA1を相当させていると考えられることに注意してください。 行われる質問は「カリフォルニアは、RSA公開鍵を公認しても構わないと思っていますか?」ということです。
GenMsg: {id-it 2}, < absent >
GenRep: {id-it 2}, SEQUENCE SIZE (1..MAX) OF
AlgorithmIdentifier
GenMsg: イド、-、それ、2、>GenRepのない<: イド、-、それ、2、AlgorithmIdentifierの系列サイズ(1..MAX)
5.3.19.3. Encryption/Key Agreement Key Pair Types
5.3.19.3. 暗号化/主要な協定主要な組タイプ
This MAY be used by the client to get the list of encryption/key agreement algorithms whose subject public key values the CA is willing to certify.
これは、カリフォルニアが公認しても構わないと対象の公開鍵値を思っている暗号化/主要な協定アルゴリズムのリストを得るのにクライアントによって使用されるかもしれません。
GenMsg: {id-it 3}, < absent >
GenRep: {id-it 3}, SEQUENCE SIZE (1..MAX) OF
AlgorithmIdentifier
GenMsg: イド、-、それ、3、>GenRepのない<: イド、-、それ、3、AlgorithmIdentifierの系列サイズ(1..MAX)
5.3.19.4. Preferred Symmetric Algorithm
5.3.19.4. 都合のよい左右対称のアルゴリズム
This MAY be used by the client to get the CA-preferred symmetric encryption algorithm for any confidential information that needs to be exchanged between the EE and the CA (for example, if the EE wants to send its private decryption key to the CA for archival purposes).
これは、EEとカリフォルニアの間で交換される必要があるどんな秘密情報のためにもカリフォルニアが都合のよい左右対称の暗号化アルゴリズムを得るのにクライアントによって使用されるかもしれません(EEが例えば保存目的に、カリフォルニアに主要な個人的な復号化を送りたいなら)。
GenMsg: {id-it 4}, < absent >
GenRep: {id-it 4}, AlgorithmIdentifier
GenMsg: イド、-、それ、4、>GenRepのない<: イド、-、それ、4、AlgorithmIdentifier
5.3.19.5. Updated CA Key Pair
5.3.19.5. アップデートされたカリフォルニア主要な組
This MAY be used by the CA to announce a CA key update event.
これは、カリフォルニアの主要なアップデート出来事を発表するのにカリフォルニアによって使用されるかもしれません。
GenMsg: {id-it 5}, CAKeyUpdAnnContent
GenMsg: イド、-、それ、5、CAKeyUpdAnnContent
Adams, et al. Standards Track [Page 45] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[45ページ]。
5.3.19.6. CRL
5.3.19.6. CRL
This MAY be used by the client to get a copy of the latest CRL.
これは、最新のCRLのコピーを手に入れるのにクライアントによって使用されるかもしれません。
GenMsg: {id-it 6}, < absent >
GenRep: {id-it 6}, CertificateList
GenMsg: イド、-、それ、6、>GenRepのない<: イド、-、それ、6、CertificateList
5.3.19.7. Unsupported Object Identifiers
5.3.19.7. サポートされない物の識別子
This is used by the server to return a list of object identifiers that it does not recognize or support from the list submitted by the client.
これはサーバによって使用されて、それがクライアントによって提出されたリストから認識もしませんし、支持もしない物の識別子のリストを返します。
GenRep: {id-it 7}, SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER
GenRep: イド、-、それ、7、物の識別子の系列サイズ(1..MAX)
5.3.19.8. Key Pair Parameters
5.3.19.8. 主要な組パラメタ
This MAY be used by the EE to request the domain parameters to use for generating the key pair for certain public-key algorithms. It can be used, for example, to request the appropriate P, Q, and G to generate the DH/DSA key, or to request a set of well-known elliptic curves.
EEは、キーを発生させるのに使用するドメインパラメタが、ある公開カギアルゴリズムのために対にされるよう要求するのにこれを使用するかもしれません。例えば、DH/DSAキーを発生させるか、または1セットの周知の楕円曲線を要求するよう適切なP、Q、およびGに要求するのにそれを使用できます。
GenMsg: {id-it 10}, OBJECT IDENTIFIER -- (Algorithm object-id)
GenRep: {id-it 11}, AlgorithmIdentifier | < absent >
GenMsg: イド、-、それ、10、OBJECT IDENTIFIER--(アルゴリズム物イド)GenRep: イド、-、それ、11、AlgorithmIdentifier| >のない<。
An absent infoValue in the GenRep indicates that the algorithm specified in GenMsg is not supported.
GenRepの欠けているinfoValueは、GenMsgで指定されたアルゴリズムが支持されないのを示します。
EEs MUST ensure that the parameters are acceptable to it and that the GenRep message is authenticated (to avoid substitution attacks).
EEsは、パラメタがそれに許容できて、GenRepメッセージが認証されるのを(代替攻撃を避ける)確実にしなければなりません。
5.3.19.9. Revocation Passphrase
5.3.19.9. 取消しパスフレーズ
This MAY be used by the EE to send a passphrase to a CA/RA for the purpose of authenticating a later revocation request (in the case that the appropriate signing private key is no longer available to authenticate the request). See Appendix B for further details on the use of this mechanism.
これは、後の取消し要求を認証する目的のためにカリフォルニア/RAにパスフレーズを送るのにEEによって使用されるかもしれません(適切な調印秘密鍵が要求を認証するためにもう利用可能でないことで)。 さらに詳しい明細についてはこのメカニズムの使用するのにAppendix Bを見てください。
GenMsg: {id-it 12}, EncryptedValue
GenRep: {id-it 12}, < absent >
GenMsg: イド、-、それ、12、EncryptedValue GenRep: イド、-、それ、12、>のない<。
5.3.19.10. ImplicitConfirm
5.3.19.10. ImplicitConfirm
See Section 5.1.1.1 for the definition and use of {id-it 13}.
セクション5.1.1を見てください、定義と使用のための.1、イド、-、それ、13
Adams, et al. Standards Track [Page 46] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[46ページ]。
5.3.19.11. ConfirmWaitTime
5.3.19.11. ConfirmWaitTime
See Section 5.1.1.2 for the definition and use of {id-it 14}.
セクション5.1.1を見てください、定義と使用のための.2、イド、-、それ、14
5.3.19.12 Original PKIMessage
5.3.19.12 オリジナルのPKIMessage
See Section 5.1.3 for the definition and use of {id-it 15}.
定義と使用のためのセクション5.1.3を見る、イド、-、それ、15
5.3.19.13. Supported Language Tags
5.3.19.13. サポートされた言語タグ
This MAY be used to determine the appropriate language tag to use in subsequent messages. The sender sends its list of supported languages (in order, most preferred to least); the receiver returns the one it wishes to use. (Note: each UTF8String MUST include a language tag.) If none of the offered tags are supported, an error MUST be returned.
適切な言語タグがその後のメッセージで使用することを決定するのにおいてこれは使用されているかもしれません。 送付者はサポートされた言語(最少より最も好まれたオーダーにおける)のリストを送ります。 受信機はそれが使用したがっているものを返します。 (注意: 各UTF8Stringは言語タグを含まなければなりません。) 提供されたタグのいずれも支えられないなら、誤りを返さなければなりません。
GenMsg: {id-it 16}, SEQUENCE SIZE (1..MAX) OF UTF8String
GenRep: {id-it 16}, SEQUENCE SIZE (1) OF UTF8String
GenMsg: イド、-、それ、16、UTF8String GenRepの系列サイズ(1..MAX): イド、-、それ、16、UTF8Stringの系列サイズ(1)
5.3.20. PKI General Response Content
5.3.20. PKI一般反応内容
GenRepContent ::= SEQUENCE OF InfoTypeAndValue
GenRepContent:、:= InfoTypeAndValueの系列
Examples of GenReps that MAY be supported include those listed in the subsections of Section 5.3.19.
支持されるかもしれないGenRepsに関する例はセクション5.3.19の小区分で記載されたものを含んでいます。
5.3.21. Error Message Content
5.3.21. エラーメッセージ内容
This data structure MAY be used by EE, CA, or RA to convey error info.
このデータ構造は、誤りインフォメーションを伝えるのにEE、カリフォルニアかRAによって使用されるかもしれません。
ErrorMsgContent ::= SEQUENCE {
pKIStatusInfo PKIStatusInfo,
errorCode INTEGER OPTIONAL,
errorDetails PKIFreeText OPTIONAL
}
ErrorMsgContent:、:= 系列errorCode整数任意の、そして、errorDetails PKIFreeText任意のpKIStatusInfo PKIStatusInfo
This message MAY be generated at any time during a PKI transaction. If the client sends this request, the server MUST respond with a PKIConfirm response, or another ErrorMsg if any part of the header is not valid. Both sides MUST treat this message as the end of the transaction (if a transaction is in progress).
このメッセージはいつでも、PKI取引の間、発生するかもしれません。 クライアントがこの要求を送るなら、サーバがPKIConfirm応答で反応しなければならない、さもなければ、もしあればErrorMsgが分けるヘッダーの別ののは有効ではありません。 両側は取引の終わりとしてこのメッセージを扱わなければなりません(取引が進行しているなら)。
If protection is desired on the message, the client MUST protect it using the same technique (i.e., signature or MAC) as the starting message of the transaction. The CA MUST always sign it with a signature key.
保護がメッセージで望まれているなら、取引の始めのメッセージと同じテクニック(すなわち、署名かMAC)を使用して、クライアントはそれを保護しなければなりません。 カリフォルニアはいつも署名キーでそれに署名しなければなりません。
Adams, et al. Standards Track [Page 47] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[47ページ]。
5.3.22. Polling Request and Response
5.3.22. 世論調査要求と応答
This pair of messages is intended to handle scenarios in which the client needs to poll the server in order to determine the status of an outstanding ir, cr, or kur transaction (i.e., when the "waiting" PKIStatus has been received).
クライアントが、どれが状態を決定するためにサーバに投票する必要があるかでメッセージのこの組がシナリオを扱うことを意図する、傑出、不-、cr、またはkur取引(すなわち、「待っている」PKIStatusを受け取ったとき)。
PollReqContent ::= SEQUENCE OF SEQUENCE {
certReqId INTEGER }
PollReqContent:、:= 系列の系列certReqId整数
PollRepContent ::= SEQUENCE OF SEQUENCE {
certReqId INTEGER,
checkAfter INTEGER, -- time in seconds
reason PKIFreeText OPTIONAL }
PollRepContent:、:= 系列の系列certReqId INTEGER、checkAfter INTEGER--秒の時にPKIFreeText OPTIONALを推論してください。
The following clauses describe when polling messages are used, and how they are used. It is assumed that multiple certConf messages can be sent during transactions. There will be one sent in response to each ip, cp, or kup that contains a CertStatus for an issued certificate.
以下の節は世論調査メッセージがいつ使用されているか、そして、それらがどのように使用されているかを説明します。 取引の間複数のcertConfメッセージを送ることができると思われます。 発行された証明書のためのCertStatusを含む各ip、cp、またはkupに対応して送られたのがあるでしょう。
1. In response to an ip, cp, or kup message, an EE will send a
certConf for all issued certificates and, following the ack, a
pollReq for all pending certificates.
1. ip、cp、またはkupメッセージに対応して、EEはすべての発行された証明書のためのcertConfとすべての未定の証明書のためのackに続くpollReqを送るでしょう。
2. In response to a pollReq, a CA/RA will return an ip, cp, or kup
if one or more of the pending certificates is ready; otherwise,
it will return a pollRep.
2. pollReqに対応して、未定の証明書の1つ以上が準備ができていると、カリフォルニア/RAはip、cp、またはkupを返すでしょう。 さもなければ、それはpollRepを返すでしょう。
3. If the EE receives a pollRep, it will wait for at least as long
as the checkAfter value before sending another pollReq.
3. EEがpollRepを受けるなら、別のpollReqを送る前に、それはcheckAfter値と少なくとも同じくらい長さ待っています。
4. If an ip, cp, or kup is received in response to a pollReq, then
it will be treated in the same way as the initial response.
4. pollReqに対応してip、cp、またはkupを受け取ると、同様に、初期の応答としてそれを扱うでしょう。
Adams, et al. Standards Track [Page 48] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[48ページ]。
START
|
v
Send ir
| ip
v
Check status
of returned <------------------------+
certs |
| |
+------------------------>|<------------------+ |
| | | |
| (issued) v (waiting) | |
Add to <----------- Check CertResponse ------> Add to |
conf list for each certificate pending list |
/ |
/ |
(conf list) / (empty conf list) |
/ ip |
/ +----------------+
(empty pending list) / | pRep
END <---- Send certConf Send pReq------------>Wait
| ^ ^ |
| | | |
+-----------------+ +---------------+
(pending list)
始め| v Send、不-| ip対返された<のCheck状態------------------------+ 本命| | | +------------------------>| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ | | | | | | (発行されます) (待ち)に対して| | <に加えてください。----------- CertResponseをチェックしてください。------>は加えます。| リストまで各証明書のためのconfリスト| / | / | (confリスト) /(空のconfリスト)| /ip| / +----------------+ (空の未定のリスト)/| 予習終わりの<。---- 発信、certConfはpReqを送ります。------------>待ち| ^ ^ | | | | | +-----------------+ +---------------+ (未定のリスト)
Adams, et al. Standards Track [Page 49] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[49ページ]。
In the following exchange, the end entity is enrolling for two certificates in one request.
以下の交換に、終わりの実体は1つの要求における2通の証明書のために登録されています。
Step End Entity PKI
--------------------------------------------------------------------
1 Format ir
2 -> ir ->
3 Handle ir
4 Manual intervention is
required for both certs.
5 <- ip <-
6 Process ip
7 Format pReq
8 -> pReq ->
9 Check status of cert requests
10 Certificates not ready
11 Format pRep
12 <- pRep <-
13 Wait
14 Format pReq
15 -> pReq ->
16 Check status of cert requests
17 One certificate is ready
18 Format ip
19 <- ip <-
20 Handle ip
21 Format certConf
22 -> certConf ->
23 Handle certConf
24 Format ack
25 <- pkiConf <-
26 Format pReq
27 -> pReq ->
28 Check status of certificate
29 Certificate is ready
30 Format ip
31 <- ip <-
31 Handle ip
32 Format certConf
33 -> certConf ->
34 Handle certConf
35 Format ack
36 <- pkiConf <-
ステップ終わりの実体PKI-------------------------------------------------------------------- 1 形式不-2->不->3Handle不-4Manual介入が両方の本命に必要です。 5 本命要求17One証明書の持ち合わせの11Format pRep12<pRep<13Wait14Format pReq15->pReq->16Check状態ではなく、本命要求10Certificatesの<ip<6Process ip7Format pReq8->pReq->9Check状態が持ち合わせの18Format ip19<ip<20Handle ip21Format certConfです; 22->certConf->23Handle certConf24Format ack25<pkiConf<26Format pReq27->pReq->28Check状態、証明書では、29Certificateは持ち合わせの30Format ip31<ip<31Handle ip32Format certConf33->certConf->34Handle certConf35Format ack36<pkiConf<です。
Adams, et al. Standards Track [Page 50] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[50ページ]。
6. Mandatory PKI Management Functions
6. 義務的なPKI管理機能
Some of the PKI management functions outlined in Section 3.1 above are described in this section.
上のセクション3.1に概説されたPKI管理機能のいくつかがこのセクションで説明されます。
This section deals with functions that are "mandatory" in the sense that all end entity and CA/RA implementations MUST be able to provide the functionality described. This part is effectively the profile of the PKI management functionality that MUST be supported. Note, however, that the management functions described in this section do not need to be accomplished using the PKI messages defined in Section 5 if alternate means are suitable for a given environment (see Appendix D for profiles of the PKIMessages that MUST be supported).
このセクションはすべての終わりの実体とカリフォルニア/RA実現が説明された機能性を提供できなければならないという意味で「義務的な」機能に対処します。 事実上、この部分は支持しなければならないPKI管理の機能性のプロフィールです。 しかしながら、交互の手段が与えられた環境に適しているなら(支持しなければならないPKIMessagesのプロフィールのためにAppendix Dを見てください)セクション5で定義されたPKIメッセージを使用することでこのセクションで説明された管理機能が達成される必要はないことに注意してください。
6.1. Root CA Initialization
6.1. 根のカリフォルニアの初期設定
[See Section 3.1.1.2 for this document's definition of "root CA".]
セクション3.1を見てください。[.1 .2 このドキュメントの「根のカリフォルニア」の定義のために]
A newly created root CA must produce a "self-certificate", which is a Certificate structure with the profile defined for the "newWithNew" certificate issued following a root CA key update.
新たに作成された根に、カリフォルニアは「自己証明書」を生産しなければなりません。(それは、プロフィールが"newWithNew"という根のカリフォルニアキーアップデートに続いて、発行された証明書のために定義されているCertificate構造です)。
In order to make the CA's self certificate useful to end entities that do not acquire the self certificate via "out-of-band" means, the CA must also produce a fingerprint for its certificate. End entities that acquire this fingerprint securely via some "out-of-band" means can then verify the CA's self-certificate and, hence, the other attributes contained therein.
CAの自己証明書を「バンドの外」という手段で自己証明書を入手しない実体を終わらせるために役に立つようにして、また、カリフォルニアは証明書のために指紋を作り出さなければなりません。 そして、「バンドの外」といういくつかの手段でしっかりとこの指紋を入手する終わりの実体はCAの自己証明書としたがって、そこに含まれた他の属性について確かめることができます。
The data structure used to carry the fingerprint is the OOBCertHash.
指紋を運ぶのに使用されるデータ構造はOOBCertHashです。
6.2. Root CA Key Update
6.2. 根のカリフォルニアキーアップデート
CA keys (as all other keys) have a finite lifetime and will have to be updated on a periodic basis. The certificates NewWithNew, NewWithOld, and OldWithNew (see Section 4.4.1) MAY be issued by the CA to aid existing end entities who hold the current self-signed CA certificate (OldWithOld) to transition securely to the new self- signed CA certificate (NewWithNew), and to aid new end entities who will hold NewWithNew to acquire OldWithOld securely for verification of existing data.
カリフォルニアキー(他のすべてのキーとしての)を有限生涯を持って、周期的ベースでアップデートしなければならないでしょう。 証明書のNewWithNew、NewWithOld、およびOldWithNew(セクション4.4.1を見る)は、しっかりと、現在の自己によってサインされたカリフォルニア証明書(OldWithOld)を変遷として保持する既存の終わりの実体を新しい自己のサインされたカリフォルニア証明書(NewWithNew)に支援して、なるNewWithNewを持っているのに新しい終わりの実体が既存のデータの検証のためにしっかりとOldWithOldを獲得するのを支援するためにカリフォルニアによって発行されるかもしれません。
6.3. Subordinate CA Initialization
6.3. 下位のカリフォルニアの初期設定
[See Section 3.1.1.2 for this document's definition of "subordinate CA".]
セクション3.1を見てください。[.1 .2 このドキュメントの「下位のカリフォルニア」の定義のために]
Adams, et al. Standards Track [Page 51] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[51ページ]。
From the perspective of PKI management protocols, the initialization of a subordinate CA is the same as the initialization of an end entity. The only difference is that the subordinate CA must also produce an initial revocation list.
PKI管理プロトコルの見解から、下位のカリフォルニアの初期化は終わりの実体の初期化と同じです。 唯一の違いはまた、下位のカリフォルニアが初期の取消しリストを作り出さなければならないということです。
6.4. CRL production
6.4. CRL生産
Before issuing any certificates, a newly established CA (which issues CRLs) must produce "empty" versions of each CRL which are to be periodically produced.
どんな証明書も発行する前に、新設されたカリフォルニア(CRLsを発行する)は定期的に生産されることになっているそれぞれのCRLの「空」のバージョンを生産しなければなりません。
6.5. PKI Information Request
6.5. PKI情報要求
When a PKI entity (CA, RA, or EE) wishes to acquire information about the current status of a CA, it MAY send that CA a request for such information.
PKI実体(カリフォルニア、RA、またはEE)願望であるときに、カリフォルニアの現在の状態の情報を取得するために、それはそのような情報のためにそのカリフォルニアに要求を送るかもしれません。
The CA MUST respond to the request by providing (at least) all of the information requested by the requester. If some of the information cannot be provided, then an error must be conveyed to the requester.
カリフォルニアは、(少なくとも)リクエスタによって要求された情報のすべてを提供することによって、要求に応じなければなりません。 何らかの情報を提供できないなら、誤りをリクエスタに伝えなければなりません。
If PKIMessages are used to request and supply this PKI information, then the request MUST be the GenMsg message, the response MUST be the GenRep message, and the error MUST be the Error message. These messages are protected using a MAC based on shared secret information (i.e., PasswordBasedMAC) or using any other authenticated means (if the end entity has an existing certificate).
PKIMessagesがこのPKI情報を要求して、提供するのに使用されるなら、要求はGenMsgメッセージであるに違いありません、そして、応答はGenRepメッセージであるに違いありません、そして、誤りはErrorメッセージであるに違いありません。 これらのメッセージは、共有秘密キー情報(すなわち、PasswordBasedMAC)に基づいているか、またはいかなる他の認証された手段も使用することで(終わりの実体に既存の証明書があるなら)MACを使用することで保護されます。
6.6. Cross Certification
6.6. 相互認証
The requester CA is the CA that will become the subject of the cross-certificate; the responder CA will become the issuer of the cross-certificate.
リクエスタカリフォルニアは交差している証明書の対象になるカリフォルニアです。 応答者カリフォルニアは交差している証明書の発行人になるでしょう。
The requester CA must be "up and running" before initiating the cross-certification operation.
相互認証操作を開始する前に、リクエスタカリフォルニアは「活動していなければなりません」。
6.6.1. One-Way Request-Response Scheme:
6.6.1. 片道要求応答計画:
The cross-certification scheme is essentially a one way operation; that is, when successful, this operation results in the creation of one new cross-certificate. If the requirement is that cross- certificates be created in "both directions", then each CA, in turn, must initiate a cross-certification operation (or use another scheme).
相互認証計画は本質的には一方通行の操作です。 すなわち、うまくいくとき、この操作は1通の新しい交差している証明書の創造をもたらします。 要件が十字証明書が「両方の指示」に作成されるということであるなら、各カリフォルニアは順番に相互認証操作を開始しなければなりません(別の計画を使用してください)。
Adams, et al. Standards Track [Page 52] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[52ページ]。
This scheme is suitable where the two CAs in question can already verify each other's signatures (they have some common points of trust) or where there is an out-of-band verification of the origin of the certification request.
問題の2CAsが既に互いの署名について確かめることができるか(それらには、一般的な数ポイントの信用があります)、または証明要求の起源のバンドで出ている検証があるところでこの計画は適当です。
Detailed Description:
詳述:
Cross certification is initiated at one CA known as the responder. The CA administrator for the responder identifies the CA it wants to cross certify and the responder CA equipment generates an authorization code. The responder CA administrator passes this authorization code by out-of-band means to the requester CA administrator. The requester CA administrator enters the authorization code at the requester CA in order to initiate the on- line exchange.
相互認証は応答者として知られている1カリフォルニアで開始されます。 そして、応答者のためのカリフォルニアの管理者がそれが交差したがっているカリフォルニアを特定する、公認、応答者カリフォルニア設備は許可コードを発生させます。 応答者カリフォルニアの管理者はバンドの外によるこの許可コード手段をリクエスタカリフォルニアの管理者に渡します。 リクエスタカリフォルニアの管理者は、線が交換するオンを開始するためにリクエスタカリフォルニアで許可コードを入れます。
The authorization code is used for authentication and integrity purposes. This is done by generating a symmetric key based on the authorization code and using the symmetric key for generating Message Authentication Codes (MACs) on all messages exchanged. (Authentication may alternatively be done using signatures instead of MACs, if the CAs are able to retrieve and validate the required public keys by some means, such as an out-of-band hash comparison.)
許可コードは認証と保全目的に使用されます。 すべてのメッセージの(MACs)が交換したメッセージ立証コードを発生させるのに許可コードに基づいていて、対称鍵を使用することで対称鍵を発生させることによって、これをします。 (あるいはまた、認証はMACsの代わりに署名を使用し終わるかもしれません、CAsがどうでも必要な公開鍵を検索して、有効にすることができるなら、バンドで出ている細切れ肉料理比較のように。)
The requester CA initiates the exchange by generating a cross- certification request (ccr) with a fresh random number (requester random number). The requester CA then sends the ccr message to the responder CA. The fields in this message are protected from modification with a MAC based on the authorization code.
リクエスタカリフォルニアが新鮮な乱数で十字証明要求(ccr)を発生させることによって交換を起こす、(リクエスタ、乱数) そして、リクエスタカリフォルニアはccrメッセージを応答者カリフォルニアに送ります。 このメッセージの分野は許可コードに基づくMACとの変更から保護されます。
Upon receipt of the ccr message, the responder CA validates the message and the MAC, saves the requester random number, and generates its own random number (responder random number). It then generates (and archives, if desired) a new requester certificate that contains the requester CA public key and is signed with the responder CA signature private key. The responder CA responds with the cross certification response (ccp) message. The fields in this message are protected from modification with a MAC based on the authorization code.
応答者カリフォルニアがccrメッセージを受け取り次第メッセージとMACを有効にして、リクエスタに乱数を保存して、それ自身の乱数を発生させる、(応答者、乱数) そして、次に、発生する、(アーカイブ、望まれているならリクエスタカリフォルニア公開鍵を含んでいて、応答者カリフォルニア署名秘密鍵を契約される新しいリクエスタ証明書。 応答者カリフォルニアは相互認証応答(ccp)メッセージで応じます。 このメッセージの分野は許可コードに基づくMACとの変更から保護されます。
Upon receipt of the ccp message, the requester CA validates the message (including the received random numbers) and the MAC. The requester CA responds with the certConf message. The fields in this message are protected from modification with a MAC based on the authorization code. The requester CA MAY write the requester certificate to the Repository as an aid to later certificate path construction.
ccpメッセージを受け取り次第、リクエスタカリフォルニアはメッセージ(容認された乱数を含んでいる)とMACを有効にします。 リクエスタカリフォルニアはcertConfメッセージで応じます。 このメッセージの分野は許可コードに基づくMACとの変更から保護されます。 リクエスタカリフォルニアは、後で経路工事を証明するために援助としてリクエスタ証明書をRepositoryに書くかもしれません。
Adams, et al. Standards Track [Page 53] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[53ページ]。
Upon receipt of the certConf message, the responder CA validates the message and the MAC, and sends back an acknowledgement using the PKIConfirm message. It MAY also publish the requester certificate as an aid to later path construction.
certConfメッセージを受け取り次第、応答者カリフォルニアは、メッセージとMACを有効にして、PKIConfirmメッセージを使用することで承認を返送します。 また、それは後の経路建築への援助としてリクエスタ証明書を発表するかもしれません。
Notes:
注意:
1. The ccr message must contain a "complete" certification request;
that is, all fields except the serial number (including, e.g., a
BasicConstraints extension) must be specified by the requester
CA.
1. ccrメッセージは「完全な」証明要求を含まなければなりません。 リクエスタカリフォルニアは通し番号(包含、例えば、BasicConstraints拡張子)以外のすなわちすべての分野を指定しなければなりません。
2. The ccp message SHOULD contain the verification certificate of
the responder CA; if present, the requester CA must then verify
this certificate (for example, via the "out-of-band" mechanism).
2. ccpメッセージSHOULDは応答者カリフォルニアの検証証明書を含んでいます。 存在しているなら、リクエスタカリフォルニアはこの証明書(例えば「バンドの外」というメカニズムで)について確かめなければなりません。
(A simpler, non-interactive model of cross-certification may also be envisioned, in which the issuing CA acquires the subject CA's public key from some repository, verifies it via some out-of-band mechanism, and creates and publishes the cross-certificate without the subject CA's explicit involvement. This model may be perfectly legitimate for many environments, but since it does not require any protocol message exchanges, its detailed description is outside the scope of this specification.)
(また、相互認証の、より簡単で、非対話的なモデル(発行カリフォルニアは、対象のCAの明白なかかわり合いなしで交差している証明書をある倉庫から対象のCAの公開鍵を取得して、何らかのバンドで出ているメカニズムでそれについて確かめて、作成して、発表する)は、思い描かれるかもしれません。 多くの環境に、このモデルは完全に正統であるかもしれませんが、どんなプロトコル交換処理も必要としないので、この仕様の範囲の外に詳述があります。)
6.7. End Entity Initialization
6.7. 終わりの実体初期設定
As with CAs, end entities must be initialized. Initialization of end entities requires at least two steps:
CAsなら、終わりの実体を初期化しなければなりません。 終わりの実体の初期設定は以下の少なくとも2ステップを必要とします:
o acquisition of PKI information
o PKI情報の獲得
o out-of-band verification of one root-CA public key
o あるカリフォルニアを根づかせている公開鍵のバンドで出ている検証
(other possible steps include the retrieval of trust condition information and/or out-of-band verification of other CA public keys).
(他の可能なステップは信頼状態情報の検索、そして/または、他のカリフォルニア公開鍵のバンドで出ている検証を含んでいます。)
6.7.1. Acquisition of PKI Information
6.7.1. PKI情報の獲得
The information REQUIRED is:
情報REQUIREDは以下の通りです。
o the current root-CA public key
o 現在のカリフォルニアを根づかせている公開鍵
o (if the certifying CA is not a root-CA) the certification path
from the root CA to the certifying CA together with appropriate
revocation lists
o (公認カリフォルニアが根カリフォルニアでないなら) 適切な取消しリストに伴う根のカリフォルニアから公認カリフォルニアまでの証明経路
Adams, et al. Standards Track [Page 54] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[54ページ]。
o the algorithms and algorithm parameters that the certifying CA
supports for each relevant usage
o 公認カリフォルニアがそれぞれの関連用法のためにサポートするアルゴリズムとアルゴリズムパラメタ
Additional information could be required (e.g., supported extensions or CA policy information) in order to produce a certification request that will be successful. However, for simplicity we do not mandate that the end entity acquires this information via the PKI messages. The end result is simply that some certification requests may fail (e.g., if the end entity wants to generate its own encryption key, but the CA doesn't allow that).
うまくいっている証明要求を作り出すために追加情報を必要とすることができました(例えば、拡大かカリフォルニア方針情報であるとサポートされます)。 しかしながら、簡単さのために、私たちは、終わりの実体がPKIメッセージでこの情報を取得するのを強制しません。 単に、結末はいくつかの証明要求が失敗するかもしれないという(例えば、終わりの実体必需品であるなら、しかし、それ自身の暗号化がキー、カリフォルニアであると生成するのがそれを許容しません)ことです。
The required information MAY be acquired as described in Section 6.5.
必須情報はセクション6.5で説明されるように後天的であるかもしれません。
6.7.2. Out-of-Band Verification of Root-CA Key
6.7.2. カリフォルニアを根づかせているキーのバンドで出ている検証
An end entity must securely possess the public key of its root CA. One method to achieve this is to provide the end entity with the CA's self-certificate fingerprint via some secure "out-of-band" means. The end entity can then securely use the CA's self-certificate.
終わりの実体には、根のカリフォルニアの公開鍵がしっかりとなければなりません。 これを達成する1つのメソッドは「バンドの外」といういくつかの安全な手段でCAの自己証明書指紋を終わりの実体に提供することです。 そして、終わりの実体はしっかりとCAの自己証明書を使用できます。
See Section 6.1 for further details.
さらに詳しい明細についてはセクション6.1を見てください。
6.8. Certificate Request
6.8. 証明書要求
An initialized end entity MAY request an additional certificate at any time (for any purpose). This request will be made using the certification request (cr) message. If the end entity already possesses a signing key pair (with a corresponding verification certificate), then this cr message will typically be protected by the entity's digital signature. The CA returns the new certificate (if the request is successful) in a CertRepMessage.
初期化している終わりの実体はいつでも(どんな目的のためにも)、追加証明書を要求するかもしれません。 証明要求(cr)メッセージを使用することでこの要求をするでしょう。 終わりの実体に署名重要組(対応する検証証明書がある)が既にあると、このcrメッセージは実体のデジタル署名で通常保護されるでしょう。 カリフォルニアはCertRepMessageで新しい証明書を返します(要求がうまくいくなら)。
6.9. Key Update
6.9. キーアップデート
When a key pair is due to expire, the relevant end entity MAY request a key update; that is, it MAY request that the CA issue a new certificate for a new key pair (or, in certain circumstances, a new certificate for the same key pair). The request is made using a key update request (kur) message (referred to, in some environments, as a "Certificate Update" operation). If the end entity already possesses a signing key pair (with a corresponding verification certificate), then this message will typically be protected by the entity's digital signature. The CA returns the new certificate (if the request is successful) in a key update response (kup) message, which is syntactically identical to a CertRepMessage.
主要な組が期限が切れることになっているとき、関連終わりの実体は主要なアップデートを要求するかもしれません。 すなわち、それは、カリフォルニアが新しい主要な組(ある特定の状況では同じ主要な組新しい証明書)のために新しい証明書を発行するよう要求するかもしれません。 主要な更新要求(kur)メッセージ(いくつかの環境で、「証明書最新版」操作に言及される)を使用することで要求をします。 終わりの実体に署名重要組(対応する検証証明書がある)が既にあると、このメッセージは実体のデジタル署名で通常保護されるでしょう。 カリフォルニアは主要なアップデート応答(kup)メッセージで新しい証明書を返します(要求がうまくいくなら)。(それは、シンタクス上CertRepMessageと同じです)。
Adams, et al. Standards Track [Page 55] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[55ページ]。
7. Version Negotiation
7. バージョン交渉
This section defines the version negotiation used to support older protocols between client and servers.
このセクションはクライアントとサーバの間の、より古いプロトコルをサポートするのに使用されるバージョン交渉を定義します。
If a client knows the protocol version(s) supported by the server (e.g., from a previous PKIMessage exchange or via some out-of-band means), then it MUST send a PKIMessage with the highest version supported by both it and the server. If a client does not know what version(s) the server supports, then it MUST send a PKIMessage using the highest version it supports.
クライアントがサーバ(例えば、前のPKIMessage交換かいくつかのバンドで出ている手段を通した)によってサポートされたプロトコルバージョンを知っているなら、最も高いバージョンがそれとサーバの両方によってサポートされている状態で、それはPKIMessageを送らなければなりません。クライアントが、サーバがどんなバージョンをサポートするかを知らないなら、サポートする中で最も高いバージョンを使用して、PKIMessageを送らなければなりません。
If a server receives a message with a version that it supports, then the version of the response message MUST be the same as the received version. If a server receives a message with a version higher or lower than it supports, then it MUST send back an ErrorMsg with the unsupportedVersion bit set (in the failureInfo field of the pKIStatusInfo). If the received version is higher than the highest supported version, then the version in the error message MUST be the highest version the server supports; if the received version is lower than the lowest supported version then the version in the error message MUST be the lowest version the server supports.
サーバがそれがサポートするバージョンでメッセージを受け取るなら、応答メッセージのバージョンは容認されたバージョンと同じであるに違いありません。 サーバがバージョンでサポートするよりさらに高いか低くメッセージを受け取るなら、unsupportedVersionビットがセットした状態で(pKIStatusInfoのfailureInfo分野で)、それはErrorMsgを返送しなければなりません。 容認されたバージョンが最も高いのがバージョンをサポートしたより高いなら、エラーメッセージのバージョンはサーバがサポートする中で最も高いバージョンであるに違いありません。 容認されたバージョンが最も低いのがバージョンをサポートしたより低いなら、エラーメッセージのバージョンはサーバがサポートする中で最も低いバージョンであるに違いありません。
If a client gets back an ErrorMsgContent with the unsupportedVersion bit set and a version it supports, then it MAY retry the request with that version.
クライアントがunsupportedVersionビットがセットしたことでのErrorMsgContentとそれがサポートするバージョンを取り戻すなら、それはそのバージョンで要求を再試行するかもしれません。
7.1. Supporting RFC 2510 Implementations
7.1. RFC2510に実装をサポートします。
RFC 2510 did not specify the behaviour of implementations receiving versions they did not understand since there was only one version in existence. With the introduction of the present revision of the specification, the following versioning behaviour is recommended.
RFC2510は現存する1つのバージョンしかなかったので、彼らが理解していなかったバージョンを受ける実装のふるまいを指定しませんでした。 仕様の現在の改正の導入によって、以下のversioningのふるまいはお勧めです。
7.1.1. Clients Talking to RFC 2510 Servers
7.1.1. RFC2510サーバと話しているクライアント
If, after sending a cmp2000 message, a client receives an ErrorMsgContent with a version of cmp1999, then it MUST abort the current transaction. It MAY subsequently retry the transaction using version cmp1999 messages.
cmp2000メッセージを送った後にクライアントがcmp1999のバージョンでErrorMsgContentを受け取るなら、それは経常取引を中止しなければなりません。 バージョンcmp1999メッセージを使用して、それは次に、トランザクションを再試行するかもしれません。
If a client receives a non-error PKIMessage with a version of cmp1999, then it MAY decide to continue the transaction (if the transaction hasn't finished) using RFC 2510 semantics. If it does not choose to do so and the transaction is not finished, then it MUST abort the transaction and send an ErrorMsgContent with a version of cmp1999.
クライアントがcmp1999のバージョンで非誤りPKIMessageを受け取るなら、それは、2510年のRFC意味論を使用することでトランザクション(トランザクションが終わっていないなら)を続けていると決めるかもしれません。 そうするのを選ばないで、またトランザクションが終わらないなら、それは、cmp1999のバージョンと共にトランザクションを中止して、ErrorMsgContentを送らなければなりません。
Adams, et al. Standards Track [Page 56] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[56ページ]。
7.1.2. Servers Receiving Version cmp1999 PKIMessages
7.1.2. サーバReceivingバージョンcmp1999 PKIMessages
If a server receives a version cmp1999 message it MAY revert to RFC 2510 behaviour and respond with version cmp1999 messages. If it does not choose to do so, then it MUST send back an ErrorMsgContent as described above in Section 7.
サーバがバージョンcmp1999メッセージを受け取るなら、それは、2510年のRFCふるまいに戻って、バージョンcmp1999メッセージで応じるかもしれません。 そうするのを選ばないなら、それはセクション7で上で説明されるようにErrorMsgContentを返送しなければなりません。
8. Security Considerations
8. セキュリティ問題
8.1. Proof-Of-Possession with a Decryption Key
8.1. 復号化キーがある所有物の証拠
Some cryptographic considerations are worth explicitly spelling out. In the protocols specified above, when an end entity is required to prove possession of a decryption key, it is effectively challenged to decrypt something (its own certificate). This scheme (and many others!) could be vulnerable to an attack if the possessor of the decryption key in question could be fooled into decrypting an arbitrary challenge and returning the cleartext to an attacker. Although in this specification a number of other failures in security are required in order for this attack to succeed, it is conceivable that some future services (e.g., notary, trusted time) could potentially be vulnerable to such attacks. For this reason, we re- iterate the general rule that implementations should be very careful about decrypting arbitrary "ciphertext" and revealing recovered "plaintext" since such a practice can lead to serious security vulnerabilities.
いくつかの暗号の問題は明らかに詳しく説明する価値があります。 終わりの実体が復号化の所有物が主要であると立証するのに必要であるときに上で指定されたプロトコルでは、事実上、何かが(それ自身の証明書)であると解読するように挑まれます。 任意の挑戦を解読して、cleartextを攻撃者に返すように問題の復号化キーの所有者をだますことができるなら、この体系(そして、多くの他のもの!)は攻撃に被害を受け易いかもしれないでしょうに。 この攻撃が引き継ぐのに他の多くの失敗がこの仕様で安全に必要ですが、いくつかの今後のサービス(例えば、公証人、信じられた時間)が潜在的にそのような攻撃に被害を受け易いかもしれないのが想像できます。 この理由で、私たちは実装がそのような習慣が重大なセキュリティの脆弱性に通じることができるので任意の「暗号文」と顕な回復している「平文」を解読することに関して非常に慎重であるはずであるという一般的な規則を再繰り返します。
8.2. Proof-Of-Possession by Exposing the Private Key
8.2. 秘密鍵を暴露するのによる所有物の証拠
Note also that exposing a private key to the CA/RA as a proof-of- possession technique can carry some security risks (depending upon whether or not the CA/RA can be trusted to handle such material appropriately). Implementers are advised to:
また、-所有物では、テクニックがいくつかのセキュリティ危険を運ぶことができるという(カリフォルニア/RAが適切にそのような材料を扱うと信じることができるかどうかによって)証拠としてカリフォルニア/RAに秘密鍵を暴露して、それに注意してください。 Implementersによる以下のことようにアドバイスされます。
Exercise caution in selecting and using this particular POP
mechanism
この特定のPOPメカニズムを選択して、使用することにおける運動警告
When appropriate, have the user of the application explicitly
state that they are willing to trust the CA/RA to have a copy of
their private key before proceeding to reveal the private key.
適切であるときには、アプリケーションのユーザに彼らが、秘密鍵を明らかにしかける前に、カリフォルニア/RAにはそれらの秘密鍵のコピーがあると信じても構わないと思っていると明らかに述べさせてください。
8.3. Attack Against Diffie-Hellman Key Exchange
8.3. ディフィー-ヘルマンの主要なExchangeに対する攻撃
A small subgroup attack during a Diffie-Hellman key exchange may be carried out as follows. A malicious end entity may deliberately choose D-H parameters that enable him/her to derive (a significant number of bits of) the D-H private key of the CA during a key archival or key recovery operation. Armed with this knowledge, the
ディフィー-ヘルマンの主要な交換の間の小さいサブグループ攻撃が以下の通り行われるかもしれません。 派生する、悪意がある終わりの実体が、故意にその人を可能にするD-Hパラメタを選ぶかもしれない(多くのビット、)、記録保管所かキーリカバリーの主要な操作の間のカリフォルニアのD-H秘密鍵。 この知識で、武装しています。
Adams, et al. Standards Track [Page 57] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[57ページ]。
EE would then be able to retrieve the decryption private key of another unsuspecting end entity, EE2, during EE2's legitimate key archival or key recovery operation with that CA. In order to avoid the possibility of such an attack, two courses of action are available. (1) The CA may generate a fresh D-H key pair to be used as a protocol encryption key pair for each EE with which it
EEはその時別の疑わない終わりの実体の復号化秘密鍵を検索できるでしょう、EE2、そのカリフォルニアとのEE2の記録保管所かキーリカバリーの正統の主要な操作の間。 そのような攻撃の可能性を避けるために、動作の2つの方針が利用可能です。 (1) カリフォルニアがキーが各EEのために対にするプロトコル暗号化として使用されるために新鮮なD-H主要な組を生成するかもしれない、どれ、それ
interacts. (2) The CA may enter into a key validation protocol (not specified in this document) with each requesting end entity to ensure that the EE's protocol encryption key pair will not facilitate this attack. Option (1) is clearly simpler (requiring no extra protocol exchanges from either party) and is therefore RECOMMENDED.
相互作用します。 (2) それぞれが、EEのプロトコル暗号化重要組がこの攻撃を容易にしないのを保証するよう終わりの実体に要求している状態で、カリフォルニアは主要な合法化プロトコル(本書では指定されない)に入るかもしれません。 オプション(1)は、明確に簡単であり(何れの当事者からのどんな付加的なプロトコル交換も必要としません)、したがって、RECOMMENDEDです。
9. IANA Considerations
9. IANA問題
The PKI General Message types are identified by object identifiers (OIDs). The OIDs for the PKI General Message types defined in this document were assigned from an arc delegated by the IANA to the PKIX Working Group.
オブジェクト識別子(OIDs)によってPKI一般教書タイプは特定されます。 本書では定義されたPKI一般教書タイプのためのOIDsはIANAによって代表として派遣されたアークからPKIX作業部会まで割り当てられました。
The cryptographic algorithms referred to in this document are identified by object identifiers (OIDs). The OIDs for cryptographic algorithms were assigned from several arcs owned by various organizations, including RSA Security, Entrust Technologies, IANA and IETF.
オブジェクト識別子(OIDs)によって示された暗号アルゴリズムは本書では特定されます。 暗号アルゴリズムのためのOIDsは様々な組織によって所有されていたいくつかのアークから割り当てられました、RSA Security、Entrust Technologies、IANA、およびIETFを含んでいて。
Should additional encryption algorithms be introduced, the advocates for such algorithms are expected to assign the necessary OIDs from their own arcs.
追加暗号化アルゴリズムを導入するなら、それら自身のアークから必要なOIDsを割り当てるとそのようなアルゴリズムのための支持者を予想します。
No further action by the IANA is necessary for this document or any anticipated updates.
IANAによるさらなるどんな動作もこのドキュメントかどんな予期されたアップデートにも必要ではありません。
Normative References
引用規格
[X509] International Organization for Standardization and
International Telecommunications Union, "Information
technology - Open Systems Interconnection - The
Directory: Public-key and attribute certificate
frameworks", ISO Standard 9594-8:2001, ITU-T
Recommendation X.509, March 2000.
[X509]国際標準化機構と国際Telecommunications Union、「情報技術--オープン・システム・インターコネクション--ディレクトリ:、」 「公開鍵と属性証明書フレームワーク」、ISO Standard9594-8:2001、ITU-T Recommendation X.509、2000年3月。
[MvOV97] Menezes, A., van Oorschot, P. and S. Vanstone, "Handbook
of Applied Cryptography", CRC Press ISBN 0-8493-8523-7,
1996.
[MvOV97] メネゼス、A.はOorschot、P.とS.Vanstone、「適用された暗号のハンドブック」CRC Press ISBN0-8493-8523-7、1996をバンに積みます。
Adams, et al. Standards Track [Page 58] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[58ページ]。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2104] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and
HMAC-SHA-1", RFC 2202, September 1997.
[RFC2202] チェンとP.とR.グレンと「HMAC-MD5のためのテストケースとHMAC-SHA-1インチ、RFC2202、1997年9月。」
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日
[RFC2482] Whistler, K. and G. Adams, "Language Tagging in Unicode
Plain Text", RFC 2482, January 1999.
[RFC2482] ウィスラーとK.とG.アダムス、「ユニコードでプレーンテキストにタグ付けをする言語」、RFC2482、1999年1月。
[CRMF] Schaad, J., "Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)", RFC 4211,
September 2005.
J.、「インターネットX.509公開鍵暗号基盤証明書要求メッセージ形式(CRMF)」、RFC4211 2005年9月の[CRMF]Schaad。
[RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
[RFC3066] Alvestrand、H.、「言語の識別のためのタグ」、BCP47、RFC3066、2001年1月。
Informative References
有益な参照
[CMPtrans] Kapoor, A., Tschalar, R. and T. Kause, "Internet X.509
Public Key Infrastructure -- Transport Protocols for
CMP", Work in Progress. 2004.
[CMPtrans] カプール、A.、Tschalar、R.、およびT.Kause、「インターネットX.509公開鍵基盤--CMPのためにプロトコルを輸送してください」、処理中の作業。 2004.
[PKCS7] RSA Laboratories, "The Public-Key Cryptography Standards
- Cryptographic Message Syntax Standard. Version 1.5",
PKCS 7, November 1993.
[PKCS7]RSA研究所、「公開鍵暗号化標準--暗号のメッセージ、構文規格、」 バージョン1.5インチ、PKCS7、1993年11月。
[PKCS10] Nystrom, M., and B. Kaliski, "The Public-Key
Cryptography Standards - Certification Request Syntax
Standard, Version 1.7", RFC 2986, May 2000.
[PKCS10] ニストロム、M.、およびB.Kaliski、「証明要求構文規格、バージョン1.7インチ、RFC2986、2000年公開鍵暗号化標準--5月。」
[PKCS11] RSA Laboratories, "The Public-Key Cryptography Standards
- Cryptographic Token Interface Standard. Version
2.10", PKCS 11, December 1999.
[PKCS11]RSA研究所、「公開鍵暗号化標準--暗号のトークンは規格を連結します」。 バージョン2.1インチ、PKCS11、1999年12月。
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, October 1995.
[RFC1847] ガルビン、J.、マーフィー、S.、クロッカー、S.、および解放されたN.、「MIMEのためのセキュリティMultiparts:」 「署名していて複合の/が暗号化した複合/」、RFC1847、1995年10月。
Adams, et al. Standards Track [Page 59] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[59ページ]。
[RFC2559] Boeyen, S., Howes, T. and P. Richard, "Internet X.509
Public Key Infrastructure Operational Protocols -
LDAPv2", RFC 2559, April 1999.
そして、[RFC2559]Boeyen、S.、ハウズ、T.、P.リチャード、「LDAPv2"、RFC2559、1999年インターネットのX.509の公開鍵暗号基盤の操作上のプロトコル--4月。」
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP", RFC
2585, May 1999.
[RFC2585] Housley、R.、およびP.ホフマン、「インターネットのX.509の公開鍵暗号基盤の操作上のプロトコル:」 「FTPとHTTP」(RFC2585)は1999がそうするかもしれません。
[FIPS-180] National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-1, May 1994.
[FIPS-180]米国商務省標準技術局(「安全なハッシュ規格」、FIPSパブ180-1)は1994がそうするかもしれません。
[FIPS-186] National Institute of Standards and Technology, "Digital
Signature Standard", FIPS PUB 186, May 1994.
[FIPS-186]米国商務省標準技術局(「デジタル署名基準」、FIPSパブ186)は1994がそうするかもしれません。
[ANSI-X9.42] American National Standards Institute, "Public Key
Cryptography for The Financial Services Industry:
Agreement of Symmetric Keys Using Discrete Logarithm
Cryptography", ANSI X9.42, February 2000.
[ANSI-X9.42]American National Standards Institut、「財政的のための公開鍵暗号は産業にサービスを提供します」。 「離散対数暗号を使用する対称鍵の協定」、ANSI X9.42、2000年2月。
Adams, et al. Standards Track [Page 60] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[60ページ]。
Appendix A. Reasons for the Presence of RAs
RAsの存在の付録A.理由
The reasons that justify the presence of an RA can be split into those that are due to technical factors and those which are organizational in nature. Technical reasons include the following.
RAの存在を正当化する理由は技術的な要素のためであるものと現実に組織的なものに分けることができます。 技術的な理由は以下を含んでいます。
o If hardware tokens are in use, then not all end entities will have
the equipment needed to initialize these; the RA equipment can
include the necessary functionality (this may also be a matter of
policy).
o ハードウェアトークンが使用中であるなら、すべての終わりの実体には、これらを初期化するのが必要である設備があるというわけではないでしょう。 RA設備は必要な機能性を含むことができます(また、これは方針の問題であるかもしれません)。
o Some end entities may not have the capability to publish
certificates; again, the RA may be suitably placed for this.
o いくつかの終わりの実体には、証明書を発表する能力がないかもしれません。 一方、RAはこれのために適当に置かれるかもしれません。
o The RA will be able to issue signed revocation requests on behalf
of end entities associated with it, whereas the end entity may not
be able to do this (if the key pair is completely lost).
o RAはそれに関連している終わりの実体を代表して署名している取消し要求を出すことができるでしょうが、終わりの実体はこれができないかもしれません(主要な組が完全に迷子になるなら)。
Some of the organizational reasons that argue for the presence of an RA are the following.
RAの存在について賛成の議論をする組織的な理由のいくつかが以下です。
o It may be more cost effective to concentrate functionality in the
RA equipment than to supply functionality to all end entities
(especially if special token initialization equipment is to be
used).
o RA設備の機能性を集結するのはすべての終わりの実体に機能性を供給するより(特別なトークン初期化設備が特に使用されていることであるなら)費用効率がよいかもしれません。
o Establishing RAs within an organization can reduce the number of
CAs required, which is sometimes desirable.
o 組織の中にRAsを設立するのは必要であるCAsの数を減少させることができます。(CAsは時々望ましいです)。
o RAs may be better placed to identify people with their
"electronic" names, especially if the CA is physically remote from
the end entity.
o RAsは彼らの「電子」の名前と人々を同一視するために置かれるほうがよいです、特にカリフォルニアが終わりの実体から物理的に遠く離れているなら。
o For many applications, there will already be in place some
administrative structure so that candidates for the role of RA are
easy to find (which may not be true of the CA).
o 多くのアプリケーションのために、何らかの運営機構が適所に既にあるので、RAの役割の候補は見つけやすいです(カリフォルニアに関して本当でないかもしれません)。
Appendix B. The Use of Revocation Passphrase
付録B.は取消しパスフレーズの使用です。
A revocation request must incorporate suitable security mechanisms, including proper authentication, in order to reduce the probability of successful denial-of-service attacks. A digital signature on the request -- MANDATORY to support within this specification if revocation requests are supported -- can provide the authentication required, but there are circumstances under which an alternative mechanism may be desirable (e.g., when the private key is no longer accessible and the entity wishes to request a revocation prior to re-certification of another key pair). In order to accommodate such
取消し要求は適当なセキュリティー対策を組み込まなければなりません、適切な認証を含んでいて、うまくいっているサービス不能攻撃の確率を減少させるために。 要求のデジタル署名--この仕様の中のサポートへのMANDATORYは取消し要求であるならサポートされます--必要である認証は提供できますが、代替のメカニズムが望ましいかもしれない事情があります(例えば、いつ秘密鍵はもうアクセスしやすくなく、別のキーの再証明の前に取消しを要求するという実体願望は対にされますか)。 そのようなものを収容します。
Adams, et al. Standards Track [Page 61] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[61ページ]。
circumstances, a PasswordBasedMAC on the request is also MANDATORY to support within this specification (subject to local security policy for a given environment) if revocation requests are supported and if shared secret information can be established between the requester and the responder prior to the need for revocation.
事情、また、取消し要求をサポートして、取消しの必要性の前にリクエスタと応答者の間で共有秘密キー情報を確立できるなら、要求でのPasswordBasedMACはこの仕様(与えられた環境のためのローカルの安全保障政策を条件とした)の中のサポートへのMANDATORYです。
A mechanism that has seen use in some environments is "revocation passphrase", in which a value of sufficient entropy (i.e., a relatively long passphrase rather than a short password) is shared between (only) the entity and the CA/RA at some point prior to revocation; this value is later used to authenticate the revocation request.
いくつかの環境における見られた使用を持っているメカニズムは取消しの前の何らかのポイントの「取消しパスフレーズ」です。(十分なエントロピー(すなわち、短いパスワードよりむしろ比較的長いパスフレーズ)の値は実体と(単に)カリフォルニア/RAの間でそれで共有されます)。 この値は、後で取消し要求を認証するのに使用されます。
In this specification, the following technique to establish shared secret information (i.e., a revocation passphrase) is OPTIONAL to support. Its precise use in CMP messages is as follows.
この仕様では、確立する以下のテクニックは(すなわち、取消しパスフレーズ)がOPTIONALであるというサポートする秘密の情報を共有しました。 CMPメッセージにおける正確な使用は以下の通りです。
o The OID and value specified in Section 5.3.19.9 MAY be sent in a
GenMsg message at any time, or MAY be sent in the generalInfo
field of the PKIHeader of any PKIMessage at any time. (In
particular, the EncryptedValue may be sent in the header of the
certConf message that confirms acceptance of certificates
requested in an initialization request or certificate request
message.) This conveys a revocation passphrase chosen by the
entity (i.e., the decrypted bytes of the encValue field) to the
relevant CA/RA; furthermore, the transfer is accomplished with
appropriate confidentiality characteristics (because the
passphrase is encrypted under the CA/RA's protocolEncryptionKey).
o OIDと値は.9をいつでもGenMsgメッセージで送るか、またはいつでもどんなPKIMessageのPKIHeaderのgeneralInfo分野でも送るかもしれないセクション5.3.19で指定しました。 (特に、初期化要求か証明書要求メッセージで要求された証明書の承認を確認するcertConfメッセージのヘッダーでEncryptedValueを送るかもしれません。) これは実体(すなわち、encValue分野の解読されたバイト)によって関連カリフォルニア/RAに選ばれた取消しパスフレーズを伝えます。 その上、転送は適切な秘密性の特性で実行されます(パスフレーズがカリフォルニア/RAのprotocolEncryptionKeyの下で暗号化されるので)。
o If a CA/RA receives the revocation passphrase (OID and value
specified in Section 5.3.19.9) in a GenMsg, it MUST construct and
send a GenRep message that includes the OID (with absent value)
specified in Section 5.3.19.9. If the CA/RA receives the
revocation passphrase in the generalInfo field of a PKIHeader of
any PKIMessage, it MUST include the OID (with absent value) in the
generalInfo field of the PKIHeader of the corresponding response
PKIMessage. If the CA/RA is unable to return the appropriate
response message for any reason, it MUST send an error message
with a status of "rejection" and, optionally, a failInfo reason
set.
o カリフォルニア/RAがGenMsgに取消しパスフレーズを受け取るなら(OIDと値はセクション5.3.19で.9を指定しました)、それを組み立てなければなりません、そして、セクション5.3.19で指定されたOID(欠けている値がある)を含んでいるGenRepメッセージに.9を送ってください。 カリフォルニア/RAがどんなPKIMessageのPKIHeaderのgeneralInfo分野にも取消しパスフレーズを受け取るなら、それは対応する応答PKIMessageのPKIHeaderのgeneralInfo分野にOID(欠けている値がある)を含まなければなりません。 カリフォルニア/RAがどんな理由でも適切な応答メッセージを返すことができないなら、それは「拒絶」の状態があるエラーメッセージを送らなければなりません、そして、任意に、failInfo理由はセットしました。
o The valueHint field of EncryptedValue MAY contain a key identifier
(chosen by the entity, along with the passphrase itself) to assist
in later retrieval of the correct passphrase (e.g., when the
revocation request is constructed by the entity and received by
the CA/RA).
o EncryptedValueのvalueHint分野は正しいパスフレーズの後の検索を助ける主要な識別子(パスフレーズ自体に伴う実体によって選ばれている)を含むかもしれません(例えば、取消し要求は、いつ実体によって構成されて、カリフォルニア/RAが受け取られますか)。
Adams, et al. Standards Track [Page 62] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[62ページ]。
o The revocation request message is protected by a PasswordBasedMAC,
with the revocation passphrase as the key. If appropriate, the
senderKID field in the PKIHeader MAY contain the value previously
transmitted in valueHint.
o 取消し要求メッセージはキーとして取消しパスフレーズでPasswordBasedMACによって保護されます。 適切であるなら、PKIHeaderのsenderKID分野は以前にvalueHintで送られた値を含むかもしれません。
Using the technique specified above, the revocation passphrase may be initially established and updated at any time without requiring extra messages or out-of-band exchanges. For example, the revocation request message itself (protected and authenticated through a MAC that uses the revocation passphrase as a key) may contain, in the PKIHeader, a new revocation passphrase to be used for authenticating future revocation requests for any of the entity's other certificates. In some environments this may be preferable to mechanisms that reveal the passphrase in the revocation request message, since this can allow a denial-of-service attack in which the revealed passphrase is used by an unauthorized third party to authenticate revocation requests on the entity's other certificates. However, because the passphrase is not revealed in the request message, there is no requirement that the passphrase must always be updated when a revocation request is made (that is, the same passphrase MAY be used by an entity to authenticate revocation requests for different certificates at different times).
上で指定されたテクニックを使用して、取消しパスフレーズは、初めは、設立されたかもしれなくて、いつでもであること付加的なメッセージが必要であるのなしでにおいてバンドの外で交換をアップデートしました。 例えば、取消し要求メッセージ(キーとして取消しパスフレーズを使用するMACを通して保護されて、認証される)自体はPKIHeaderに実体の他の証明書のどれかに関する今後の取消し要求を認証するのに使用されるべき新しい取消しパスフレーズを含むかもしれません。 いくつかの環境で、これは取消し要求メッセージのパスフレーズを明らかにするメカニズムより望ましいかもしれません、明らかにされたパスフレーズが権限のない第三者によって使用されるサービス不能攻撃がこれで実体の他の証明書に関する取消し要求を認証できるので。 しかしながら、パスフレーズが要求メッセージで明らかにされないので、取消し要求をするとき(すなわち、同じパスフレーズは実体によって使用されて、いろいろな時間に異なった証明書に関する取消し要求を認証するかもしれません)、いつもパスフレーズをアップデートしなければならないという要件が全くありません。
Furthermore, the above technique can provide strong cryptographic protection over the entire revocation request message even when a digital signature is not used. Techniques that do authentication of the revocation request by simply revealing the revocation passphrase typically do not provide cryptographic protection over the fields of the request message (so that a request for revocation of one certificate may be modified by an unauthorized third party to a request for revocation of another certificate for that entity).
デジタル署名が使用されてさえいないとき、その上、上のテクニックは全体の取消し要求メッセージの上に強い暗号の保護を提供できます。 単に取消しパスフレーズを明らかにすることによって取消し要求の認証をするテクニックが要求メッセージの分野の上に暗号の保護を通常提供しません(その実体のための別の証明書の取消しを求める要求への権限のない第三者が1通の証明書の取消しを求める要求を変更できるように)。
Appendix C. Request Message Behavioral Clarifications
付録のC.の要求メッセージの行動の明確化
In the case of updates to [CRMF], which cause interpretation or interoperability issues, [CRMF] SHALL be the normative document.
解釈か相互運用性問題、[CRMF]SHALLを引き起こす[CRMF]へのアップデートの場合では、標準のドキュメントになってください。
The following definitions are from [CRMF]. They are included here in order to codify behavioral clarifications to that request message; otherwise, all syntax and semantics are identical to [CRMF].
以下の定義は[CRMF]から来ています。 それらはその要求メッセージに行動の明確化を成文化するためにここに含まれています。 さもなければ、すべての構文と意味論は[CRMF]と同じです。
CertRequest ::= SEQUENCE {
certReqId INTEGER,
certTemplate CertTemplate,
controls Controls OPTIONAL }
CertRequest:、:= 系列certReqId INTEGER(certTemplate CertTemplate)はControls OPTIONALを制御します。
-- If certTemplate is an empty SEQUENCE (i.e., all fields -- omitted), then controls MAY contain the
-- certTemplateは空のSEQUENCE(すなわちすべての分野--省略される)、5月が含む当時のコントロールです。
Adams, et al. Standards Track [Page 63] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[63ページ]。
-- id-regCtrl-altCertTemplate control, specifying a template -- for a certificate other than an X.509v3 public-key -- certificate. Conversely, if certTemplate is not empty -- (i.e., at least one field is present), then controls MUST -- NOT contain id-regCtrl- altCertTemplate. The new control is -- defined as follows:
-- X.509v3公開鍵以外の証明書にテンプレートを指定して、イド-regCtrl-altCertTemplateは制御します--証明書。 逆に、certTemplateがそうでないなら空になってください。--(すなわち、少なくとも1つの分野が存在しています、)、次に、コントロールはそうしなければなりません--NOTはイド-regCtrl- altCertTemplateを含んでいます。 新しいコントロールはそうです--以下の通り定義されます:
id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= {id-regCtrl 7}
AltCertTemplate ::= AttributeTypeAndValue
イド-regCtrl-altCertTemplateオブジェクト識別子:、:= イド-regCtrl7、AltCertTemplate:、:= AttributeTypeAndValue
POPOSigningKey ::= SEQUENCE {
poposkInput [0] POPOSigningKeyInput OPTIONAL,
algorithmIdentifier AlgorithmIdentifier,
signature BIT STRING }
POPOSigningKey:、:= 系列poposkInput[0]POPOSigningKeyInput OPTIONAL、algorithmIdentifier AlgorithmIdentifier、署名BIT STRING
-- ********** -- * For the purposes of this specification, the ASN.1 comment -- * given in [CRMF] pertains not only to certTemplate, but -- * also to the altCertTemplate control. That is, -- ********** -- * The signature (using "algorithmIdentifier") is on the -- * DER-encoded value of poposkInput (i.e., the "value" OCTETs -- * of the POPOSigningKeyInput DER). NOTE: If CertReqMsg -- * certReq certTemplate (or the altCertTemplate control) -- * contains the subject and publicKey values, then poposkInput -- * MUST be omitted and the signature MUST be computed on the -- * DER-encoded value of CertReqMsg certReq (or the DER- -- * encoded value of AltCertTemplate). If -- * certTemplate/altCertTemplate does not contain both the -- * subject and public key values (i.e., if it contains only -- * one of these, or neither), then poposkInput MUST be present -- * and MUST be signed. -- **********
-- **********--*この仕様の目的のために、ASN.1はコメントします--しかし、[CRMF]で与えられた*はcertTemplateだけでないのに関係します--altCertTemplateコントロールにも*。 *すなわち(**********)、署名("algorithmIdentifier"を使用する)が進行中、--poposkInput(すなわち、「値」OCTETs--POPOSigningKeyInput DERの*)の*DERによってコード化された値。 以下に注意してください。 または、CertReqMsg--*certReq certTemplate(または、altCertTemplateコントロール)--*は対象とpublicKey値、当時のpoposkInputを含んでいます--*を省略しなければならなくて、署名のときに計算しなければならない、--、*がCertReqMsg certReqの値をDERコード化した(DER--、AltCertTemplateの*コード化された値) --、*certTemplate/altCertTemplateが両方を含んでいない--、*対象と公開鍵値、(すなわち、それである、含有、単に--、これら、またはどちらもの*1、)、次に、poposkInputをプレゼント--*でなければならなく、署名しなければなりません。 -- **********
POPOPrivKey ::= CHOICE {
thisMessage [0] BIT STRING,
POPOPrivKey:、:= 特選、thisMessage[0]ビット列
-- ********** -- * the type of "thisMessage" is given as BIT STRING in -- * [CRMF]; it should be "EncryptedValue" (in accordance -- * with Section 5.2.2, "Encrypted Values", of this specification). -- * Therefore, this document makes the behavioral clarification -- * of specifying that the contents of "thisMessage" MUST be encoded -- * as an EncryptedValue and then wrapped in a BIT STRING. This -- * allows the necessary conveyance and protection of the -- * private key while maintaining bits-on-the-wire compatibility -- * with [CRMF]. -- **********
-- **********--*BIT STRINGとして"thisMessage"のタイプを中に与えます--*[CRMF] それが"EncryptedValue"であるべきである、(一致で--、セクション5.2.2、この仕様の「暗号化された値」がある*) -- * したがって、このドキュメントは行動の明確化("thisMessage"のコンテンツをコード化しなければならないと指定する*)をBIT STRINGのEncryptedValueであって次に、包装されているとしての*にします。 これ--*は[CRMF]との--ワイヤのビットの互換性を維持する秘密鍵がゆったり過ごす*--*の必要な運送と保護を許します。 -- **********
Adams, et al. Standards Track [Page 64] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[64ページ]。
subsequentMessage [1] SubsequentMessage,
dhMAC [2] BIT STRING }
subsequentMessage[1]SubsequentMessage、dhMAC[2]ビット列
Appendix D. PKI Management Message Profiles (REQUIRED).
付録D.PKI管理メッセージプロフィール(必要です)。
This appendix contains detailed profiles for those PKIMessages that MUST be supported by conforming implementations (see Section 6).
この付録は実装を従わせることによってサポートしなければならないそれらのPKIMessagesのための詳細なプロフィールを含んでいます(セクション6を見てください)。
Profiles for the PKIMessages used in the following PKI management operations are provided:
以下のPKI管理操作に使用されるPKIMessagesのためのプロフィールを提供します:
o initial registration/certification
o 新規登録/証明
o basic authenticated scheme
o 基本的な認証された体系
o certificate request
o 証明書要求
o key update
o キーアップデート
D.1. General Rules for Interpretation of These Profiles.
D.1。 一般はこれらのプロフィールの解釈のために判決を下します。
1. Where OPTIONAL or DEFAULT fields are not mentioned in individual
profiles, they SHOULD be absent from the relevant message (i.e.,
a receiver can validly reject a message containing such fields as
being syntactically incorrect). Mandatory fields are not
mentioned if they have an obvious value (e.g., in this version of
the specification, pvno is always 2).
1. どこOPTIONALかDEFAULT分野が個々のプロフィールで言及されないで、それらはSHOULDです。関連メッセージを休んでください(シンタクス上不正確であるような分野を含んでいて、すなわち、受信機は確実にメッセージを拒絶できます)。 それらに明白な値があるなら(例えば、仕様のこのバージョンでは、いつもpvnoは2です)、義務的な分野は言及されません。
2. Where structures occur in more than one message, they are
separately profiled as appropriate.
2. 構造が1つ以上のメッセージに現れるところでは、それらは別々に適宜輪郭を描かれます。
3. The algorithmIdentifiers from PKIMessage structures are profiled
separately.
3. PKIMessage構造からのalgorithmIdentifiersは別々に輪郭を描かれます。
4. A "special" X.500 DN is called the "NULL-DN"; this means a DN
containing a zero-length SEQUENCE OF RelativeDistinguishedNames
(its DER encoding is then '3000'H).
4. 「特別な」X.500 DNは「ヌルDN」と呼ばれます。 これは無の長さのSEQUENCE OF RelativeDistinguishedNamesを含むDNを意味します(次に、DERコード化は'3000'Hです)。
5. Where a GeneralName is required for a field, but no suitable
value is available (e.g., an end entity produces a request before
knowing its name), then the GeneralName is to be an X.500 NULL-DN
(i.e., the Name field of the CHOICE is to contain a NULL-DN).
This special value can be called a "NULL-GeneralName".
5. GeneralNameは分野にもかかわらず、どんな適当な値にもどこで必要でないかが、利用可能である(名前を知る前に、例えば、終わりの実体は要求を作り出します)、そして、GeneralNameによるX.500 NULL-DNであることになっています(すなわち、CHOICEのName分野はNULL-DNを含むことです)。 この特別な値を「ヌルGeneralName」と呼ぶことができます。
6. Where a profile omits to specify the value for a GeneralName,
then the NULL-GeneralName value is to be present in the relevant
PKIMessage field. This occurs with the sender field of the
PKIHeader for some messages.
6. プロフィールが、GeneralNameに値を指定するのを忘れるところでは、その時、NULL-GeneralName値は関連PKIMessage分野に存在していることです。 これはいくつかのメッセージのためのPKIHeaderの送付者分野で起こります。
Adams, et al. Standards Track [Page 65] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[65ページ]。
7. Where any ambiguity arises due to naming of fields, the profile
names these using a "dot" notation (e.g., "certTemplate.subject"
means the subject field within a field called certTemplate).
7. どんなあいまいさも分野の命名のため起こるところでは、プロフィールは、「ドット」記法を使用するとこれらを命名します(例えば、"certTemplate.subject"はcertTemplateと呼ばれる分野の中で対象の分野を意味します)。
8. Where a "SEQUENCE OF types" is part of a message, a zero-based
array notation is used to describe fields within the SEQUENCE OF
(e.g., crm[0].certReq.certTemplate.subject refers to a subfield
of the first CertReqMsg contained in a request message).
8. 「SEQUENCE OFタイプ」がメッセージの一部であるところでは、無ベースの配列記法は、SEQUENCE OFの中で分野について説明するのに使用されます(例えば、crm[0].certReq.certTemplate.subjectは要求メッセージに含まれた最初のCertReqMsgの部分体について言及します)。
9. All PKI message exchanges in Appendix D.4 to D.6 require a
certConf message to be sent by the initiating entity and a
PKIConfirm to be sent by the responding entity. The PKIConfirm
is not included in some of the profiles given since its body is
NULL and its header contents are clear from the context. Any
authenticated means can be used for the protectionAlg (e.g.,
password-based MAC, if shared secret information is known, or
signature).
9. D.6へのAppendix D.4のすべてのPKI交換処理が、開始実体によって送られるべきcertConfメッセージとPKIConfirmが応じる実体によって送られるのを必要とします。 PKIConfirmはボディーがNULLであり、ヘッダー含有量が文脈から明確であるので与えられたプロフィールのいくつかに含まれていません。 protectionAlg(例えば、パスワードベースのMAC、共有秘密キー情報が知られているか、そして、または署名)にどんな認証された手段も使用できます。
D.2. Algorithm Use Profile
D.2。 使用が輪郭を描くアルゴリズム
The following table contains definitions of algorithm uses within PKI management protocols. The columns in the table are:
以下のテーブルはPKI管理プロトコルの中にアルゴリズム用途の定義を含んでいます。 テーブルのコラムは以下の通りです。
Name: an identifier used for message profiles
以下を命名してください。 メッセージプロフィールに使用される識別子
Use: description of where and for what the algorithm is used
使用: どこに関する記述とアルゴリズムがことのためのものであるか、中古
Mandatory: an AlgorithmIdentifier which MUST be supported by
conforming implementations
義務的: 実装を従わせることによってサポートしなければならないAlgorithmIdentifier
Others: alternatives to the mandatory AlgorithmIdentifier
他のもの: 義務的なAlgorithmIdentifierへの代替手段
Name Use Mandatory Others
義務的な他のものと使用を命名してください。
MSG_SIG_ALG Protection of PKI DSA/SHA-1 RSA/MD5,
messages using signature ECDSA, ...
MSG_MAC_ALG protection of PKI PasswordBasedMac HMAC,
messages using MACing X9.9...
SYM_PENC_ALG symmetric encryption of 3-DES (3-key- AES,RC5,
an end entity's private EDE, CBC mode) CAST-128...
key where symmetric
key is distributed
out-of-band
PROT_ENC_ALG asymmetric algorithm D-H RSA,
used for encryption of ECDH, ...
(symmetric keys for
encryption of) private
keys transported in
_メッセージが署名ECDSAを使用することでのPKI DSA/SHA-1 RSA/MD5のMSG_SIG ALG Protection PKI PasswordBasedMac HMAC、MACing X9.9を使用するメッセージのMSG_MAC_ALG保護… 3-DES(3主要なAES、RC5、終わりの実体の個人的なEDE、CBCモード)キャスト-128(対称鍵がバンドの外でPROT_ENCの_のALGの非対称のアルゴリズムD-H RSAで、ECDHの暗号化において使用されていた状態で分配されるキー)のSYM_PENCの_のALGの左右対称の暗号化 (暗号化のための対称鍵、) 中に輸送された秘密鍵
Adams, et al. Standards Track [Page 66] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[66ページ]。
PKIMessages
PROT_SYM_ALG symmetric encryption 3-DES (3-key- AES,RC5,
algorithm used for EDE, CBC mode) CAST-128...
encryption of private
key bits (a key of this
type is encrypted using
PROT_ENC_ALG)
PKIMessages PROT_SYMの_のALGの左右対称の暗号化3-DES(3主要なAES、アルゴリズムがEDE、CBCモードに使用したRC5)キャスト-128… 秘密鍵ビットの暗号化(このタイプのキーはPROT_ENC_ALGを使用することで暗号化されています)
Mandatory AlgorithmIdentifiers and Specifications:
義務的なAlgorithmIdentifiersと仕様:
DSA/SHA-1:
AlgId: {1 2 840 10040 4 3};
DSA/SHA-1: 寒けがする: {1 2 840 10040 4 3};
Digital Signature Standard [FIPS-186]
デジタル署名基準[FIPS-186]
Public Modulus size: 1024 bits.
公共のModulusサイズ: 1024ビット。
PasswordBasedMac:
PasswordBasedMac:
AlgId: {1 2 840 113533 7 66 13}, with SHA-1 {1 3 14 3 2 26} as the
owf parameter and HMAC-SHA1 {1 3 6 1 5 5 8 1 2} as the mac
parameter;
寒けがする: 1 2、840、113533、7、66 13、SHA-1、1 3、14、3 2、26、macパラメタとしてのowfパラメタとHMAC-SHA1 1 3 6 1 5 5 8 1 2として。
(this specification), along with
(この仕様)
Secure Hash Standard [FIPS-180] and [RFC2104]
そしてハッシュ規格[FIPS-180]を保証してください。[RFC2104]
HMAC key size: 160 bits (i.e., "K" = "H" in Section 5.1.3.1,
"Shared secret information")
HMACの主要なサイズ: 160ビット(すなわち、「K」=、「H」コネセクション5.1.3.1、「共有秘密キー情報」)
3-DES:
3デス:
AlgId: {1 2 840 113549 3 7};
(used in RSA's BSAFE and in S/MIME).
寒けがする: {1 2 840 113549 3 7}; (RSAのBSAFEとS/MIMEでは、使用されます。)
D-H:
D-H:
AlgId: {1 2 840 10046 2 1};
寒けがする: {1 2 840 10046 2 1};
[ANSI-X9.42]
[ANSI-X9.42]
Public Modulus Size: 1024 bits.
DomainParameters ::= SEQUENCE {
p INTEGER, -- odd prime, p=jq +1
g INTEGER, -- generator, g^q = 1 mod p
q INTEGER, -- prime factor of p-1
j INTEGER OPTIONAL, -- cofactor, j>=2
validationParms ValidationParms OPTIONAL
公共の係数サイズ: 1024ビット。 DomainParameters:、:= SEQUENCE、p INTEGER--奇素数、p=jqの+1gのINTEGER--ジェネレータ、g^qは1モッズp q INTEGER--p-1j INTEGER OPTIONALに関する主要因--補助因子と等しいです、2j>=validationParms ValidationParms OPTIONAL
Adams, et al. Standards Track [Page 67] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[67ページ]。
}
ValidationParms ::= SEQUENCE {
seed BIT STRING, -- seed for prime generation
pGenCounter INTEGER -- parameter verification
}
} ValidationParms:、:= 系列種子BIT STRING--主要な世代pGenCounter INTEGER種子--パラメタ検証
D.3. Proof-of-Possession Profile
D.3。 所有物の証拠プロフィール
POP fields for use (in signature field of pop field of ProofOfPossession structure) when proving possession of a private signing key that corresponds to a public verification key for which a certificate has been requested.
個人的な署名の所有物が主要であると立証するときの証明書が要求されている公共の検証キーに対応する使用(ProofOfPossession構造の大衆的な分野の署名分野の)のためのPOP分野。
Field Value Comment
分野値のコメント
algorithmIdentifier MSG_SIG_ALG only signature protection is
allowed for this proof
algorithmIdentifier MSG、_署名保護だけがこの証拠のために許されているSIG_ALG
signature present bits calculated using MSG_SIG_ALG
MSG_SIG_ALGを使用することで計算された署名現在のビット
Proof-of-possession of a private decryption key that corresponds to a public encryption key for which a certificate has been requested does not use this profile; the CertHash field of the certConf message is used instead.
証明書が要求されている公共の暗号化キーに対応する個人的な復号化キー所有物の証拠はこのプロフィールを使用しません。 certConfメッセージのCertHash分野は代わりに使用されます。
Not every CA/RA will do Proof-of-Possession (of signing key, decryption key, or key agreement key) in the PKIX-CMP in-band certification request protocol (how POP is done MAY ultimately be a policy issue that is made explicit for any given CA in its publicized Policy OID and Certification Practice Statement). However, this specification MANDATES that CA/RA entities MUST do POP (by some means) as part of the certification process. All end entities MUST be prepared to provide POP (i.e., these components of the PKIX-CMP protocol MUST be supported).
あらゆるカリフォルニア/RAがバンドにおけるPKIX-CMP証明要求プロトコルで所有物のProof(署名キーの復号化の主要であるか、主要な協定キー)をするというわけではないでしょう(結局、POPがどう完了しているかは、そのピーアールされたPolicy OIDとCertification Practice Statementのカリフォルニアを考えて、いずれにも明白にされる政策問題であるかもしれません)。 しかしながら、カリフォルニア/RA実体が証明の一部としてPOP(どうでも)をしなければならないこの仕様MANDATESは処理します。 POPを提供するようにすべての終わりの実体を準備しなければなりません(すなわち、PKIX-CMPプロトコルのこれらの成分をサポートしなければなりません)。
D.4. Initial Registration/Certification (Basic Authenticated Scheme)
D.4。 新規登録/証明(基本的な認証された体系)
An (uninitialized) end entity requests a (first) certificate from a CA. When the CA responds with a message containing a certificate, the end entity replies with a certificate confirmation. The CA sends a PKIConfirm back, closing the transaction. All messages are authenticated.
(非初期化しました)終わりの実体はカリフォルニアから(1番目)の証明書を要求します。 メッセージが証明書を含んでいてカリフォルニアが応じると、終わりの実体は証明書確認で返答します。 トランザクションを閉じて、カリフォルニアはPKIConfirmを返送します。 すべてのメッセージが認証されます。
This scheme allows the end entity to request certification of a locally-generated public key (typically a signature key). The end entity MAY also choose to request the centralized generation and certification of another key pair (typically an encryption key pair).
この体系で、終わりの実体は局所的に発生している公開鍵(通常署名キー)の証明を要求できます。 また、終わりの実体は、主要なもう1組(通常暗号化主要な組)の集結された世代と証明を要求するのを選ぶかもしれません。
Adams, et al. Standards Track [Page 68] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[68ページ]。
Certification may only be requested for one locally generated public key (for more, use separate PKIMessages).
証明は1つの局所的に生成している公開鍵のために要求されているだけであるかもしれません(以上には、別々のPKIMessagesを使用してください)。
The end entity MUST support proof-of-possession of the private key associated with the locally-generated public key.
終わりの実体は局所的に発生している公開鍵に関連している秘密鍵所有物の証拠をサポートしなければなりません。
Preconditions:
前提条件:
1. The end entity can authenticate the CA's signature based on out-
of-band means
1. 終わりの実体はバンドの出ている手段に基づくCAの署名を認証できます。
2. The end entity and the CA share a symmetric MACing key
2. 終わりの実体とカリフォルニアは左右対称のMACingキーを共有します。
Message flow:
メッセージ流動:
Step# End entity PKI
1 format ir
2 -> ir ->
3 handle ir
4 format ip
5 <- ip <-
6 handle ip
7 format certConf
8 -> certConf ->
9 handle certConf
10 format PKIConf
11 <- PKIConf <-
12 handle PKIConf
ステップ#End実体PKI1形式不-2->不->3ハンドル不-4形式ip5<ip<6ハンドルip7形式certConf8->certConf->9ハンドルcertConf10形式PKIConf11<PKIConf<12PKIConfを扱ってください。
For this profile, we mandate that the end entity MUST include all (i.e., one or two) CertReqMsg in a single PKIMessage, and that the PKI (CA) MUST produce a single response PKIMessage that contains the complete response (i.e., including the OPTIONAL second key pair, if it was requested and if centralized key generation is supported). For simplicity, we also mandate that this message MUST be the final one (i.e., no use of "waiting" status value).
このプロフィールに関しては、私たちは、終わりの実体が独身のPKIMessageのすべての(すなわち、1か2)CertReqMsgを含まなければならなくて、PKI(カリフォルニア)が完全な応答(すなわち、それが要求されて、集結されたキー生成がサポートされるなら、OPTIONAL2番目の主要な組を含んでいる)を含むただ一つの応答PKIMessageを生産しなければならないのを強制します。 また、簡単さのために、私たちは、このメッセージが最終的なものであるに違いないことを強制します(すなわち、状態値の「待ち」である無駄)。
The end entity has an out-of-band interaction with the CA/RA. This transaction established the shared secret, the referenceNumber and OPTIONALLY the distinguished name used for both sender and subject name in the certificate template. It is RECOMMENDED that the shared secret be at least 12 characters long.
終わりの実体には、カリフォルニア/RAとのバンドで出かけている相互作用があります。 このトランザクションは分類名が送付者と対象の名前の両方に証明書テンプレートで使用した共有秘密キー、referenceNumber、およびOPTIONALLYを確立しました。 共有秘密キーが長い間少なくとも12のキャラクタであることがRECOMMENDEDです。
Initialization Request -- ir
初期設定Request--、不-
Field Value
分野値
recipient CA name
受取人カリフォルニア名
Adams, et al. Standards Track [Page 69] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[69ページ]。
-- the name of the CA who is being asked to produce a certificate
protectionAlg MSG_MAC_ALG
-- only MAC protection is allowed for this request, based
-- on initial authentication key
senderKID referenceNum
-- the reference number which the CA has previously issued
-- to the end entity (together with the MACing key)
transactionID present
-- implementation-specific value, meaningful to end
-- entity.
-- [If already in use at the CA, then a rejection message MUST
-- be produced by the CA]
-- 証明書protectionAlg MSG_MAC_ALGを生産するように頼まれているカリフォルニアの名前--MAC保護だけがこの要求のために許されています、初期の認証の主要なsenderKID referenceNum--終わりの実体(MACingキーに伴う)transactionID現在へのカリフォルニアが以前に発行した参照番号--実装特有の値に基づきます、終わるには、重要です--実体。 -- [カリフォルニアで既に使用中であるなら、拒絶メッセージはそうしなければなりません--カリフォルニアによって生産されてください]
senderNonce present
-- 128 (pseudo-)random bits
freeText any valid value
body ir (CertReqMessages)
only one or two CertReqMsg
are allowed
-- if more certificates are required, requests MUST be
-- packaged in separate PKIMessages
senderNonceプレゼント--より多くの証明書が必要であるなら、要求が必要とされるに違いないというどんな有効値本体不-の(CertReqMessages)唯一のものかtwo CertReqMsgも許容されているfreeTextが別々のPKIMessagesでパッケージした無作為の128(疑似な)ビット
CertReqMsg one or two present
-- see below for details, note: crm[0] means the first
-- (which MUST be present), crm[1] means the second (which
-- is OPTIONAL, and used to ask for a centrally-generated key)
CertReqMsg1かtwoプレゼント--詳細に関して以下を見てください、そして、以下に注意してください。 crm[0]が意味する、1番目--(存在していなければなりません)、crm[1]は2番目を意味します。(どれ、中心で発生しているキーを求めるのにOPTIONALであり、使用されるか、)
crm[0].certReq. fixed value of zero
certReqId
-- this is the index of the template within the message
crm[0].certReq present
certTemplate
-- MUST include subject public key value, otherwise unconstrained
crm[0].pop... optionally present if public key
POPOSigningKey from crm[0].certReq.certTemplate is
a signing key
-- proof-of-possession MAY be required in this exchange
-- (see Appendix D.3 for details)
crm[0].certReq. optionally present
controls.archiveOptions
-- the end entity MAY request that the locally-generated
-- private key be archived
crm0.certReqこれがメッセージのcrm0.certReqの現在のcertTemplateの中のテンプレートのインデックスであるというcertReqIdがない一定の価値はcrm0.certReq.certTemplateからの公開鍵POPOSigningKeyが署名キーであるなら対象の公開鍵値、そうでなければ任意に現在の自由なcrm0.popを…含まなければなりません; 所有物の証拠はこれが交換する必要なコネ--(詳細に関してAppendix D.3を見ます)crm0.certReq任意に現在のcontrols.archiveOptions--実体がそれを要求するかもしれない終わりが局所的に発生であったならそうするかもしれません--、秘密鍵、格納されてください。
crm[0].certReq. optionally present
controls.publicationInfo
-- the end entity MAY ask for publication of resulting cert.
crm[0].certReq任意に現在のcontrols.publicationInfo--終わりの実体は結果として起こる本命の公表を求めるかもしれません。
crm[1].certReq fixed value of one
1のcrm[1].certReq一定の価値
Adams, et al. Standards Track [Page 70] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[70ページ]。
certReqId
-- the index of the template within the message
crm[1].certReq present
certTemplate
-- MUST NOT include actual public key bits, otherwise
-- unconstrained (e.g., the names need not be the same as in
-- crm[0]). Note that subjectPublicKeyInfo MAY be present
-- and contain an AlgorithmIdentifier followed by a
-- zero-length BIT STRING for the subjectPublicKey if it is
-- desired to inform the CA/RA of algorithm and parameter
-- preferences regarding the to-be-generated key pair.
certReqId--メッセージのcrm[1].certReqの現在のcertTemplateの中のテンプレートのインデックス(そうでなければ、実際の公開鍵ビットを含んではいけない)自由である、(例えば、名前はコネと同じである必要はありません--crm[0])。 プレゼント(AlgorithmIdentifierを含んで、続いてaを含んでください--subjectPublicKeyのためのゼロ・レングスBIT STRINGがそれであるならあります--アルゴリズムとパラメタについてカリフォルニア/RAに知らせることを望んでいる)が主要な生成している組に関する好みであったかもしれないならそのsubjectPublicKeyInfoに注意してください。
crm[1].certReq. present [object identifier MUST be PROT_ENC_ALG]
crm[1].certReqプレゼント[オブジェクト識別子はPROT_ENC_ALGであるに違いありません]
controls.protocolEncrKey
-- if centralized key generation is supported by this CA,
-- this short-term asymmetric encryption key (generated by
-- the end entity) will be used by the CA to encrypt (a
-- symmetric key used to encrypt) a private key generated by
-- the CA on behalf of the end entity
controls.protocolEncrKey、短期的な非対称の暗号化これほど主要である、集結されたキー生成がこのカリフォルニアによってサポートされるなら(生成される、--終わりの実体) 使用されているために生成された秘密鍵を暗号化する(a--暗号化するのにおいて中古の対称鍵)カリフォルニアのそばで望んでください--、終わりの実体を代表したカリフォルニア
crm[1].certReq. optionally present
controls.archiveOptions
crm[1].certReq. optionally present
controls.publicationInfo
protection present
-- bits calculated using MSG_MAC_ALG
crm[1].certReq MSG_MAC_ALGを使用することでcontrols.archiveOptions crm[1].certReq任意に現在のcontrols.publicationInfo保護に計算されたプレゼント--ビットを任意に寄贈してください。
Initialization Response -- ip
初期設定Response--ip
Field Value
分野値
sender CA name
-- the name of the CA who produced the message
messageTime present
-- time at which CA produced message
protectionAlg MS_MAC_ALG
-- only MAC protection is allowed for this response
senderKID referenceNum
-- the reference number that the CA has previously issued to the
-- end entity (together with the MACing key)
transactionID present
-- value from corresponding ir message
senderNonce present
-- 128 (pseudo-)random bits
recipNonce present
-- value from senderNonce in corresponding ir message
freeText any valid value
カリフォルニアが_メッセージprotectionAlg MS MAC_ALG--保護がこの応答senderKID referenceNumのために許されているMACだけ--カリフォルニアが以前に発行した参照番号をどれに生産したかで送付者カリフォルニア名(メッセージmessageTimeプレゼントを生産したカリフォルニアの名前)は調節されます; 終わりの実体(MACingキーに伴う)transactionIDプレゼント--現在の対応する不-メッセージsenderNonceからの値(recipNonceが寄贈する無作為の128(疑似な)ビット)は対応する不-メッセージfreeTextでsenderNonceからどんな有効値も評価します。
Adams, et al. Standards Track [Page 71] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[71ページ]。
body ip (CertRepMessage)
contains exactly one response
for each request
ボディーip(CertRepMessage)はまさに各要求あたり1つの応答を含んでいます。
-- The PKI (CA) responds to either one or two requests as
-- appropriate. crc[0] denotes the first (always present);
-- crc[1] denotes the second (only present if the ir message
-- contained two requests and if the CA supports centralized
-- key generation).
crc[0]. fixed value of zero
certReqId
-- MUST contain the response to the first request in the
-- corresponding ir message
-- (カリフォルニア)がどちらかか2つの要求まで応じるPKI--. crc[0]を当てるのは1番目を指示します(いつも現在の)。 -- crc[1]が2番目を指示する、(不-メッセージである場合にだけ提示する、--、2つの含まれた要求とサポートが集結したカリフォルニア(キー生成) . crc[0]certReqIdがない一定の価値)が中に最初の要求への応答を含まなければならないかどうか、--対応する、不-通信してください
crc[0].status. present, positive values allowed:
status "accepted", "grantedWithMods"
negative values allowed:
"rejection"
crc[0].status. present if and only if
failInfo crc[0].status.status is "rejection"
crc[0]. present if and only if
certifiedKeyPair crc[0].status.status is
"accepted" or "grantedWithMods"
certificate present unless end entity's public
key is an encryption key and POP
is done in this in-band exchange
encryptedCert present if and only if end entity's
public key is an encryption key and
POP done in this in-band exchange
publicationInfo optionally present
crc[0].status現在の、そして、上向きの値は許容しました: 「grantedWithMods」負の数は、状態が「受け入れたこと」を許容しました: 「拒絶」crc[0].statusプレゼント、crc[0]failInfo crc[0].status.statusである場合にだけ「拒絶」がプレゼントである、単にcertifiedKeyPair crc[0].status.statusを「受け入れる」か、または終わりの実体の公開鍵が暗号化キーとPOPでないならバンドにおけるこの交換encryptedCertプレゼントで「grantedWithMods」証明書プレゼントをする、終わりの実体の公開鍵は、バンドのpublicationInfoが任意に提示するこの交換で行われた暗号化キーとPOPにすぎません。
-- indicates where certificate has been published (present
-- at discretion of CA)
-- 証明書がどこで発表されたかを示します。(カリフォルニアの裁量で現在)です。
crc[1]. fixed value of one
certReqId
-- MUST contain the response to the second request in the
-- corresponding ir message
crc[1].status. present, positive values allowed:
status "accepted", "grantedWithMods"
negative values allowed:
"rejection"
crc[1].status. present if and only if
failInfo crc[0].status.status is "rejection"
crc[1]. present if and only if
certifiedKeyPair crc[0].status.status is "accepted"
or "grantedWithMods"
certificate present
crc[1]あるcertReqIdの一定の価値--中に2番目の要求への応答を含まなければならない、--対応する不-メッセージcrc[1].status現在の、そして、上向きの値は許容しました: 「grantedWithMods」負の数は、状態が「受け入れたこと」を許容しました: 「拒絶」crc[1].statusプレゼント、crc[1]failInfo crc[0].status.statusである場合にだけ「拒絶」がプレゼントである、certifiedKeyPair crc[0].status.statusが「受け入れられるだけであるか」、そして、「grantedWithMods」証明書プレゼント
Adams, et al. Standards Track [Page 72] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[72ページ]。
privateKey present
-- see Appendix C, Request Message Behavioral Clarifications
publicationInfo optionally present
-- indicates where certificate has been published (present
-- at discretion of CA)
privateKeyプレゼント--Appendix C、Request Message Behavioral Clarifications publicationInfoが任意に存在しているのを見てください--、証明書がどこで発表されたかを示します。(カリフォルニアの裁量で現在)です。
protection present
-- bits calculated using MSG_MAC_ALG
extraCerts optionally present
-- the CA MAY provide additional certificates to the end
-- entity
カリフォルニアが追加終わりまでの証明書を供給するかもしれない保護プレゼント(ALG extraCertsが任意に寄贈するMSG_MAC_を使用することで計算されたビット)--実体
Certificate confirm; certConf
証明書、確認します。 certConf
Field Value
分野値
sender present
-- same as in ir
recipient CA name
-- the name of the CA who was asked to produce a certificate
transactionID present
-- value from corresponding ir and ip messages
senderNonce present
-- 128 (pseudo-) random bits
recipNonce present
-- value from senderNonce in corresponding ip message
protectionAlg MSG_MAC_ALG
-- only MAC protection is allowed for this message. The
-- MAC is based on the initial authentication key shared
-- between the EE and the CA.
そして、出席している対応するのから不-受取人カリフォルニア名--証明書transactionIDプレゼントを生産するように頼まれたカリフォルニアの名前--値と同じ送付者、不-、senderNonceが提示するipメッセージ--128 (疑似な) recipNonceが寄贈する無作為のビット--対応するipメッセージprotectionAlg MSG_MAC_ALGのsenderNonceからの値--MAC保護だけがこのメッセージのために許されています。 --MACは初期の認証キーにEEとカリフォルニアの間で共有されていた状態で基づいています。
senderKID referenceNum
-- the reference number which the CA has previously issued
-- to the end entity (together with the MACing key)
senderKID referenceNum--終わりの実体へのカリフォルニアが以前に発行した参照番号(MACingキーに伴う)
body certConf
-- see Section 5.3.18, "PKI Confirmation Content", for the
-- contents of the certConf fields.
-- Note: two CertStatus structures are required if both an
-- encryption and a signing certificate were sent.
ボディーcertConf--セクション5.3.18、「PKI確認内容」を見てください、--certConf分野のコンテンツ。 -- 以下に注意してください。 2つのCertStatus構造が両方であるなら必要である、--暗号化と署名証明書を送りました。
protection present
-- bits calculated using MSG_MAC_ALG
保護プレゼント--MSG_MAC_ALGを使用することで計算されたビット
Confirmation; PKIConf
確認。 PKIConf
Field Value
分野値
Adams, et al. Standards Track [Page 73] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[73ページ]。
sender present
-- same as in ip
recipient present
-- sender name from certConf
transactionID present
-- value from certConf message
senderNonce present
-- 128 (pseudo-) random bits
recipNonce present
-- value from senderNonce from certConf message
protectionAlg MSG_MAC_ALG
-- only MAC protection is allowed for this message.
senderKID referenceNum
body PKIConf
protection present
-- bits calculated using MSG_MAC_ALG
出席しているcertConfメッセージsenderNonceプレゼントから出席しているip受取人--certConf transactionIDプレゼントからの送付者名--値と同じ送付者--recipNonceが寄贈する無作為の128(疑似な)ビット--senderNonceからのcertConfメッセージprotectionAlg MSG_MAC_ALG--保護が. ボディーPKIConf保護現在のこのメッセージsenderKID referenceNumのために許されているMACだけ--MSG_MAC_ALGを使用することで計算されたビットからの値
D.5. Certificate Request
D.5。 証明書要求
An (initialized) end entity requests a certificate from a CA (for any reason). When the CA responds with a message containing a certificate, the end entity replies with a certificate confirmation. The CA replies with a PKIConfirm, to close the transaction. All messages are authenticated.
(初期化されます)終わりの実体はカリフォルニア(どんな理由によるも)から証明書を要求します。 メッセージが証明書を含んでいてカリフォルニアが応じると、終わりの実体は証明書確認で返答します。 カリフォルニアは、トランザクションを閉じるためにPKIConfirmと共に返答します。 すべてのメッセージが認証されます。
The profile for this exchange is identical to that given in Appendix D.4, with the following exceptions:
この交換のためのプロフィールは以下の例外でAppendix D.4で与えられたそれと同じです:
o sender name SHOULD be present
o 送付者名前SHOULD、存在してください。
o protectionAlg of MSG_SIG_ALG MUST be supported (MSG_MAC_ALG MAY
also be supported) in request, response, certConfirm, and
PKIConfirm messages;
o protectionAlg、_エムエスジーSIG_ALG MUSTでは、サポートされてください、(MSG_MAC_ALG MAY、もサポートされてください、)、要求、応答、certConfirm、およびPKIConfirmメッセージで。
o senderKID and recipKID are only present if required for message
verification;
o senderKIDとrecipKIDは必要なら単にメッセージ検証のために存在しています。
o body is cr or cp;
o ボディーは、crかcpです。
o body may contain one or two CertReqMsg structures, but either
CertReqMsg may be used to request certification of a locally-
generated public key or a centrally-generated public key (i.e.,
the position-dependence requirement of Appendix D.4 is removed);
o ボディーは1か2つのCertReqMsg構造を含むかもしれませんが、CertReqMsgは局所的に生成している公開鍵か中心で発生している公開鍵の証明を要求するのに使用されるかもしれません(すなわち、Appendix D.4の位置依存要件は取り除かれます)。
o protection bits are calculated according to the protectionAlg
field.
o protectionAlg分野に従って、保護ビットは計算されます。
Adams, et al. Standards Track [Page 74] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[74ページ]。
D.6. Key Update Request
D.6。 主要な更新要求
An (initialized) end entity requests a certificate from a CA (to update the key pair and/or corresponding certificate that it already possesses). When the CA responds with a message containing a certificate, the end entity replies with a certificate confirmation. The CA replies with a PKIConfirm, to close the transaction. All messages are authenticated.
(初期化されます)終わりの実体はカリフォルニア(それが既に持っている主要な組、そして/または、対応する証明書をアップデートする)から証明書を要求します。 メッセージが証明書を含んでいてカリフォルニアが応じると、終わりの実体は証明書確認で返答します。 カリフォルニアは、トランザクションを閉じるためにPKIConfirmと共に返答します。 すべてのメッセージが認証されます。
The profile for this exchange is identical to that given in Appendix D.4, with the following exceptions:
この交換のためのプロフィールは以下の例外でAppendix D.4で与えられたそれと同じです:
1. sender name SHOULD be present
1. 送付者名前SHOULD、存在してください。
2. protectionAlg of MSG_SIG_ALG MUST be supported (MSG_MAC_ALG MAY
also be supported) in request, response, certConfirm, and
PKIConfirm messages;
2. protectionAlg、_エムエスジーSIG_ALG MUSTでは、サポートされてください、(MSG_MAC_ALG MAY、もサポートされてください、)、要求、応答、certConfirm、およびPKIConfirmメッセージで。
3. senderKID and recipKID are only present if required for message
verification;
3. senderKIDとrecipKIDは必要なら単にメッセージ検証のために存在しています。
4. body is kur or kup;
4. ボディーは、kurかkupです。
5. body may contain one or two CertReqMsg structures, but either
CertReqMsg may be used to request certification of a locally-
generated public key or a centrally-generated public key (i.e.,
the position-dependence requirement of Appendix D.4 is removed);
5. ボディーは1か2つのCertReqMsg構造を含むかもしれませんが、CertReqMsgは局所的に生成している公開鍵か中心で発生している公開鍵の証明を要求するのに使用されるかもしれません(すなわち、Appendix D.4の位置依存要件は取り除かれます)。
6. protection bits are calculated according to the protectionAlg
field;
6. protectionAlg分野に従って、保護ビットは計算されます。
7. regCtrl OldCertId SHOULD be used (unless it is clear to both
sender and receiver -- by means not specified in this document --
that it is not needed).
7. regCtrl OldCertId SHOULD、使用されてください(それは必要でないのが、本書では指定されなかった手段による送付者と受信機の両方に明確でない場合)。
Appendix E. PKI Management Message Profiles (OPTIONAL).
付録E.PKI管理メッセージプロフィール(任意の)。
This appendix contains detailed profiles for those PKIMessages that MAY be supported by implementations (in addition to the messages which MUST be supported; see Section 6 and Appendix D).
この付録は実装によってサポートされるかもしれないそれらのPKIMessagesのための詳細なプロフィールを含んでいます(サポートしなければならないメッセージに加えて; セクション6とAppendix Dを見てください)。
Profiles for the PKIMessages used in the following PKI management operations are provided:
以下のPKI管理操作に使用されるPKIMessagesのためのプロフィールを提供します:
o root CA key update
o 根のカリフォルニアキーアップデート
o information request/response
o 情報要求/応答
Adams, et al. Standards Track [Page 75] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[75ページ]。
o cross-certification request/response (1-way)
o 相互認証要求/応答(1ウェイ)
o in-band initialization using external identity certificate
o バンドにおける外部のアイデンティティ証明書を使用する初期化
Later versions of this document may extend the above to include profiles for the operations listed below (along with other operations, if desired).
このドキュメントの後のバージョンは、以下に記載された操作のためのプロフィールを含むように上記を広げるかもしれません(他の操作望まれているなら)。
o revocation request
o 取消し要求
o certificate publication
o 証明書公表
o CRL publication
o CRL公表
E.1. General Rules for Interpretation of These Profiles.
E.1。 一般はこれらのプロフィールの解釈のために判決を下します。
Identical to Appendix D.1.
付録D.1と同じです。
E.2. Algorithm Use Profile
E.2。 使用が輪郭を描くアルゴリズム
Identical to Appendix D.2.
付録D.2と同じです。
E.3. Self-Signed Certificates
E.3。 自己署名入りの証書
Profile of how a Certificate structure may be "self-signed". These structures are used for distribution of CA public keys. This can occur in one of three ways (see Section 4.4 above for a description of the use of these structures):
Certificate構造がどう「自己に署名されるかもしれないか」に関するプロフィール。 これらの構造はカリフォルニア公開鍵の分配に使用されます。 これは3つの方法の1つで起こることができます(これらの構造の使用の記述において、セクション4.4が上であることを見てください):
Type Function
-----------------------------------------------------------------
newWithNew a true "self-signed" certificate; the contained
public key MUST be usable to verify the signature
(though this provides only integrity and no
authentication whatsoever)
oldWithNew previous root CA public key signed with new private key
newWithOld new root CA public key signed with previous private key
タイプ機能----------------------------------------------------------------- newWithNew本当の「自己によって署名される」証明書。 含まれた公開鍵は新しい秘密鍵newWithOld新しい根のカリフォルニア公開鍵が前の秘密鍵を契約されている状態で前の根のカリフォルニア公開鍵が署名した署名(保全だけを提供しますが、これはどんな認証も全く提供しませんが)oldWithNewについて確かめるのにおいて使用可能であるに違いありません。
Such certificates (including relevant extensions) must contain "sensible" values for all fields. For example, when present, subjectAltName MUST be identical to issuerAltName, and, when present, keyIdentifiers must contain appropriate values, et cetera.
そのような証明書(関連拡大を含んでいる)はすべての分野への「分別がある」値を含まなければなりません。 存在しているとき、例えば、subjectAltNameはissuerAltNameと同じであるに違いありません、そして、存在しているとき、keyIdentifiersは適切な値などを含まなければなりません。
Adams, et al. Standards Track [Page 76] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[76ページ]。
E.4. Root CA Key Update
E.4。 根のカリフォルニアキーアップデート
A root CA updates its key pair. It then produces a CA key update announcement message that can be made available (via some transport mechanism) to the relevant end entities. A confirmation message is NOT REQUIRED from the end entities.
根のカリフォルニアは主要な組をアップデートします。 そして、それは関連終わりの実体に利用可能に(何らかの移送機構を通した)することができるカリフォルニアの主要なアップデート発表メッセージを出します。 確認メッセージは終わりの実体からのNOT REQUIREDです。
ckuann message:
ckuannメッセージ:
Field Value Comment
--------------------------------------------------------------
sender CA name CA name
body ckuann(CAKeyUpdAnnContent)
oldWithNew present see Appendix E.3 above
newWithOld present see Appendix E.3 above
newWithNew present see Appendix E.3 above
extraCerts optionally present can be used to "publish"
certificates (e.g.,
certificates signed using
the new private key)
分野値のコメント-------------------------------------------------------------- oldWithNewが提示する送付者カリフォルニア名前カリフォルニア名前ボディーckuann(CAKeyUpdAnnContent)は、newWithOldプレゼントの上のAppendix E.3が、newWithNewプレゼントの上のAppendix E.3が、証明書を「発行すること」に任意に現在のextraCertsの上のAppendix E.3を使用できるのを見るのを見るのを見ます。(例えば新しい秘密鍵を使用することでサインされた証明書)
E.5. PKI Information Request/Response
E.5。 PKI情報要求/応答
The end entity sends a general message to the PKI requesting details that will be required for later PKI management operations. RA/CA responds with a general response. If an RA generates the response, then it will simply forward the equivalent message that it previously received from the CA, with the possible addition of certificates to the extraCerts fields of the PKIMessage. A confirmation message is NOT REQUIRED from the end entity.
終わりの実体は後のPKI管理操作に必要である詳細を要求するPKIに一般的なメッセージを送ります。 RA/カリフォルニアは一般反応で応じます。 RAが応答を発生させると、単に、以前にカリフォルニアから受信したという同等なメッセージを転送するでしょう、PKIMessageのextraCerts分野への証明書の可能な添加で。 確認メッセージは終わりの実体からのNOT REQUIREDです。
Message Flows:
メッセージは流れます:
Step# End entity PKI
ステップ#End実体PKI
1 format genm
2 -> genm ->
3 handle genm
4 produce genp
5 <- genp <-
6 handle genp
1 形式genm2->genm->3ハンドルgenm4はgenp5<genp<6ハンドルgenpを生産します。
genM:
genM:
Field Value
分野値
recipient CA name
-- the name of the CA as contained in issuerAltName
受取人カリフォルニア名--issuerAltNameの含まれるとしてのカリフォルニアの名前
Adams, et al. Standards Track [Page 77] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[77ページ]。
-- extensions or issuer fields within certificates
protectionAlg MSG_MAC_ALG or MSG_SIG_ALG
-- any authenticated protection alg.
SenderKID present if required
-- must be present if required for verification of message
-- protection
freeText any valid value
body genr (GenReqContent)
GenMsgContent empty SEQUENCE
-- all relevant information requested
protection present
-- bits calculated using MSG_MAC_ALG or MSG_SIG_ALG
-- 証明書protectionAlg MSG_MAC_ALGかMSG_SIG_ALGの中の拡大か発行人分野--いずれも保護algを認証しました。 必要なら、SenderKIDが提示する、--、必要ならメッセージ--保護の検証のためにMSG_MAC_ALGかMSG_SIG_ALGを使用するどんな有効値本体のgenr(GenReqContent)GenMsgContent空のSEQUENCEも--すべての関連情報要求された保護プレゼント--ビットが計算したfreeTextを寄贈することでなければなりません。
genP:
genP:
Field Value
分野値
sender CA name
-- name of the CA which produced the message
protectionAlg MSG_MAC_ALG or MSG_SIG_ALG
-- any authenticated protection alg.
senderKID present if required
-- must be present if required for verification of message
-- protection
body genp (GenRepContent)
CAProtEncCert present (object identifier one
of PROT_ENC_ALG), with relevant
value
-- to be used if end entity needs to encrypt information for
-- the CA (e.g., private key for recovery purposes)
送付者カリフォルニア名--メッセージのprotectionAlg MSG_MAC_ALGかMSG_SIG_ALGを生産したカリフォルニアの名前--必要なら、alg. senderKIDが提示するどんな認証された保護--なる情報をコード化する終わりの実体の必要性であるなら必要なら使用されるべきメッセージ(関連値がある保護ボディーgenp(GenRepContent)CAProtEncCertプレゼント(PROT_ENC_ALGに関する物の識別子1))の検証のために存在していなければなりません--カリフォルニア(例えば、回復目的のための秘密鍵)
SignKeyPairTypes present, with relevant value
-- the set of signature algorithm identifiers that this CA will
-- certify for subject public keys
EncKeyPairTypes present, with relevant value
-- the set of encryption/key agreement algorithm identifiers that
-- this CA will certify for subject public keys
PreferredSymmAlg present (object identifier one
of PROT_SYM_ALG) , with relevant
value
-- the symmetric algorithm that this CA expects to be used
-- in later PKI messages (for encryption)
CAKeyUpdateInfo optionally present, with
relevant value
-- the CA MAY provide information about a relevant root CA
-- key pair using this field (note that this does not imply
-- that the responding CA is the root CA in question)
CurrentCRL optionally present, with relevant value
SignKeyPairTypesは関連値--このカリフォルニアがそうする署名アルゴリズム識別子のセット--対象の公開鍵のために、EncKeyPairTypesが関連値について存在しているのを公認します--暗号化/主要な協定アルゴリズム識別子のセットでそれを提示します--このカリフォルニアは、対象の公開鍵のためにPreferredSymmAlgが存在しているのを(PROT_SYM_ALGに関する物の識別子1)公認するでしょう、関連値で; このカリフォルニアがCAKeyUpdateInfoがカリフォルニアが関連根のカリフォルニアの情報を提供するかもしれないという関連値で任意に任意に関連値の現在のこの分野(応じるカリフォルニアがカリフォルニア問題の根であるというこれが含意しないメモ)CurrentCRLを使用している主要な組を紹介する後のPKIメッセージ(暗号化のための)で使用されると予想する左右対称のアルゴリズム
Adams, et al. Standards Track [Page 78] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[78ページ]。
-- the CA MAY provide a copy of a complete CRL (i.e.,
-- fullest possible one)
protection present
-- bits calculated using MSG_MAC_ALG or MSG_SIG_ALG
extraCerts optionally present
-- can be used to send some certificates to the end
-- entity. An RA MAY add its certificate here.
-- カリフォルニアは完全なCRLのコピーを提供するかもしれません。(すなわち(可能な限りふくよかな1つ) 証明書を終わりにいくつか送ることにおけるMAC_ALGかMSG_SIG_ALG extraCertsが任意に寄贈するMSG_--あることができるのを使用することで計算された中古さビットの保護プレゼント)、実体。 RA MAYはここで証明書を加えます。
E.6. Cross Certification Request/Response (1-way)
E.6。 相互認証要求/応答(1ウェイ)
Creation of a single cross-certificate (i.e., not two at once). The requesting CA MAY choose who is responsible for publication of the cross-certificate created by the responding CA through use of the PKIPublicationInfo control.
ただ一つの交差している証明書の創造、(すなわち、2でない、すぐに) 要求カリフォルニアは、だれがPKIPublicationInfoコントロールの使用で応じるカリフォルニアによって作成された交差している証明書の公表に責任があるかを選ぶかもしれません。
Preconditions:
前提条件:
1. Responding CA can verify the origin of the request (possibly
requiring out-of-band means) before processing the request.
1. カリフォルニアを反応させると、要求を処理する前に、要求(ことによると、バンドの外では、手段を必要とする)の起源について確かめることができます。
2. Requesting CA can authenticate the authenticity of the origin of
the response (possibly requiring out-of-band means) before
processing the response
2. 応答を処理する前にカリフォルニアが応答(ことによると、バンドの外では、手段を必要とする)の起源の信憑性を認証できるよう要求します。
The use of certificate confirmation and the corresponding server confirmation is determined by the generalInfo field in the PKIHeader (see Section 5.1.1). The following profile does not mandate support for either confirmation.
証明書確認と対応するサーバ確認の使用はPKIHeaderのgeneralInfo分野のそばで決定しています(セクション5.1.1を見てください)。 以下のプロフィールは確認のサポートを強制しません。
Message Flows:
メッセージは流れます:
Step# Requesting CA Responding CA
1 format ccr
2 -> ccr ->
3 handle ccr
4 produce ccp
5 <- ccp <-
6 handle ccp
1つの形式のステップ#RequestingカリフォルニアRespondingカリフォルニアccr2->ccr->3ハンドルccr4はccp5<ccp<6ハンドルccpを生産します。
ccr:
ccr:
Field Value
分野値
sender Requesting CA name
-- the name of the CA who produced the message
recipient Responding CA name
-- the name of the CA who is being asked to produce a certificate
messageTime time of production of message
送付者Requestingカリフォルニア名--メッセージ受取人Respondingカリフォルニア名を作成したカリフォルニアの名前--メッセージの生産の証明書messageTime時間を生産するように頼まれているカリフォルニアの名前
Adams, et al. Standards Track [Page 79] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[79ページ]。
-- current time at requesting CA
protectionAlg MSG_SIG_ALG
-- only signature protection is allowed for this request
senderKID present if required
-- must be present if required for verification of message
-- protection
recipKID present if required
-- must be present if required for verification of message
-- protection
transactionID present
-- implementation-specific value, meaningful to requesting CA.
-- [If already in use at responding CA then a rejection message
-- MUST be produced by responding CA]
senderNonce present
-- 128 (pseudo-)random bits
freeText any valid value
body ccr (CertReqMessages)
only one CertReqMsg
allowed
-- if multiple cross certificates are required, they MUST be
-- packaged in separate PKIMessages
certTemplate present
-- details follow
version v1 or v3
-- v3 STRONGLY RECOMMENDED
signingAlg present
-- the requesting CA must know in advance with which algorithm it
-- wishes the certificate to be signed
-- _カリフォルニアprotectionAlg MSG_SIG ALG(必要なら、保護がこの要求senderKIDプレゼントのために許されている署名だけ)が必要ならメッセージの検証のために存在していなければならないよう要求するところの現在の時間(必要なら、recipKIDが提示する保護)は必要ならメッセージ--transactionIDが提示する保護--実現特有の価値の検証のために存在していなければなりません、カリフォルニアを要求するのに、重要です。 -- 既に中なら、その時カリフォルニアを反応させるのに拒絶メッセージを使用してください--カリフォルニアsenderNonceプレゼントを反応させることによって、生産しなければなりません--複数の交差している証明書が必要であるならどんな有効値ボディーccr(CertReqMessages)唯一の1CertReqMsgも許容した128(疑似な)の無作為のビットfreeText、それらはそうであるに違いありません; 詳細がバージョンv1かv3に続くという要求カリフォルニアがあらかじめどのアルゴリズムでそれを知らなければならないかという現在のv3 STRONGLY RECOMMENDED signingAlgがサインされるために証明書であることを願っている別々のPKIMessages certTemplateプレゼントでは、パッケージされます。
subject present
-- may be NULL-DN only if subjectAltNames extension value proposed
validity present
-- MUST be completely specified (i.e., both fields present)
issuer present
-- may be NULL-DN only if issuerAltNames extension value proposed
publicKey present
-- the key to be certified (which must be for a signing algorithm)
extensions optionally present
-- a requesting CA must propose values for all extensions
-- that it requires to be in the cross-certificate
POPOSigningKey present
-- see Section D3: Proof-of-possession profile
protection present
-- bits calculated using MSG_SIG_ALG
extraCerts optionally present
-- MAY contain any additional certificates that requester wishes
-- to include
提案されたpublicKeyが提示するissuerAltNames拡大価値((調印アルゴリズムのためのものであるに違いありません) 要求カリフォルニアがすべての拡大のために値を提案しなければならないというそれが交差している証明書POPOSigningKey現在にあるのを必要とする任意に現在の拡大であることが公認されるべきキー)がセクションD3を見る場合にだけ、対象のプレゼント--subjectAltNames拡大価値が完全に指定された(現在のすなわち両方の分野)発行人がプレゼントであったに違いないなら正当性プレゼントを提案した場合にだけNULL-DNであるかもしれないことはNULL-DNであるかもしれません: プロフィール保護プレゼント(SIG_ALG extraCertsが任意に寄贈するMSG_を使用することで計算されたビット)がリクエスタが願っているどんな追加証明書も含むかもしれないという所有物の証拠--含むように
Adams, et al. Standards Track [Page 80] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[80ページ]。
ccp:
ccp:
Field Value
分野値
sender Responding CA name
-- the name of the CA who produced the message
recipient Requesting CA name
-- the name of the CA who asked for production of a certificate
messageTime time of production of message
-- current time at responding CA
protectionAlg MSG_SIG_ALG
-- only signature protection is allowed for this message
senderKID present if required
-- must be present if required for verification of message
-- protection
recipKID present if required
transactionID present
-- value from corresponding ccr message
senderNonce present
-- 128 (pseudo-)random bits
recipNonce present
-- senderNonce from corresponding ccr message
freeText any valid value
body ccp (CertRepMessage)
only one CertResponse allowed
-- if multiple cross certificates are required they MUST be
-- packaged in separate PKIMessages
response present
status present
送付者Respondingカリフォルニア名--メッセージ受取人Requestingカリフォルニア名--メッセージの生産の証明書messageTime時間の生産を求めたカリフォルニアの名前--現在の時間を_必要なら、署名保護だけがこのメッセージsenderKIDプレゼントのために許されているというカリフォルニアprotectionAlg MSG_SIG ALGを反応させるのに生産したカリフォルニアの名前は必要ならメッセージの検証のために存在していなければなりません; 保護recipKIDは対応するccrメッセージsenderNonceプレゼント--recipNonceが寄贈する無作為の128(疑似な)ビット--senderNonceから複数の交差している証明書が必要であるならそれらがそうであるに違いないという1CertResponseだけが許容したどんな有効値本体ccp(CertRepMessage)も現在の別々のPKIMessages応答で状態プレゼントをパッケージしたという対応するccrメッセージfreeTextから必要ならtransactionIDにプレゼント--値を提示します。
PKIStatusInfo.status present
-- if PKIStatusInfo.status is one of:
-- accepted, or
-- grantedWithMods,
-- then certifiedKeyPair MUST be present and failInfo MUST
-- be absent
PKIStatusInfo.statusはPKIStatusInfo.statusが1歳であるなら以下を提示します。 -- 受諾、failInfoはそうしなければなりません----grantedWithMods--当時のcertifiedKeyPairは存在していなければならなくて、欠けてください。
failInfo present depending on
PKIStatusInfo.status
-- if PKIStatusInfo.status is:
-- rejection
-- then certifiedKeyPair MUST be absent and failInfo MUST be
-- present and contain appropriate bit settings
PKIStatusInfo.statusがよるならPKIStatusInfo.statusによるfailInfoプレゼント: -- 拒絶--failInfoはそうであるに違いありません--次に、certifiedKeyPairが欠けるに違いなくて、適切な噛み付いている設定を提示して、含んでください。
certifiedKeyPair present depending on
PKIStatusInfo.status
certificate present depending on
certifiedKeyPair
certifiedKeyPairによるPKIStatusInfo.status証明書プレゼントによるcertifiedKeyPairプレゼント
Adams, et al. Standards Track [Page 81] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[81ページ]。
-- content of actual certificate must be examined by requesting CA
-- before publication
protection present
-- bits calculated using MSG_SIG_ALG
extraCerts optionally present
-- MAY contain any additional certificates that responder wishes
-- to include
-- 公表保護プレゼント(SIG_ALG extraCertsが任意に寄贈するMSG_を使用することで計算されたビット)が応答者が願っているどんな追加証明書も含むかもしれない前にカリフォルニアを要求することによって、実際の証明書の中身を調べなければなりません--含むように
E.7. In-Band Initialization Using External Identity Certificate
E.7。 バンドにおける外部のアイデンティティ証明書を使用する初期設定
An (uninitialized) end entity wishes to initialize into the PKI with a CA, CA-1. It uses, for authentication purposes, a pre-existing identity certificate issued by another (external) CA, CA-X. A trust relationship must already have been established between CA-1 and CA-X so that CA-1 can validate the EE identity certificate signed by CA-X. Furthermore, some mechanism must already have been established within the Personal Security Environment (PSE) of the EE that would allow it to authenticate and verify PKIMessages signed by CA-1 (as one example, the PSE may contain a certificate issued for the public key of CA-1, signed by another CA that the EE trusts on the basis of out-of-band authentication techniques).
カリフォルニア、カリフォルニア-1でPKIに初期化する(非初期化しました)終わりの実体願望。 それは認証目的、別の(外部)のカリフォルニアによって発行された先在のアイデンティティ証明書にカリフォルニア-Xを使用します。 信用関係は、カリフォルニア-1がカリフォルニア-XによってサインされたEEアイデンティティ証明書を有効にすることができるように、カリフォルニア-1とカリフォルニア-Xの間で既に確立されたに違いありません。 その上、何らかのメカニズムがそれにカリフォルニア-1つサインされたPKIMessagesについて認証して、確かめさせるEEのパーソナルSecurity Environment(PSE)の中で既に確立されたに違いありません(1つの例として、PSEはバンドの外のEEがベースで信じる別のカリフォルニアによってサインされたカリフォルニア-1認証のテクニックの公開鍵のために発行された証明書を含むかもしれません)。
The EE sends an initialization request to start the transaction. When CA-1 responds with a message containing the new certificate, the end entity replies with a certificate confirmation. CA-1 replies with a PKIConfirm to close the transaction. All messages are signed (the EE messages are signed using the private key that corresponds to the public key in its external identity certificate; the CA-1 messages are signed using the private key that corresponds to the public key in a
EEは取引を始めるという初期化要求を送ります。 メッセージが新しい証明書を含んでいてカリフォルニア-1が応じると、終わりの実体は証明書確認で返答します。 カリフォルニア-1は、取引を終えるためにPKIConfirmと共に返答します。 すべてのメッセージがサインされる、(外部のアイデンティティ証明書で公開鍵に対応する秘密鍵を使用することでEEメッセージはサインされます; aで公開鍵に対応する秘密鍵を使用することでカリフォルニア-1メッセージはサインされます。
certificate that can be chained to a trust anchor in the EE's PSE).
EEのPSEの信用アンカーにチェーニングできる証明書)
The profile for this exchange is identical to that given in Appendix D.4, with the following exceptions:
この交換のためのプロフィールは以下の例外でAppendix D.4で与えられたそれと同じです:
o the EE and CA-1 do not share a symmetric MACing key (i.e., there
is no out-of-band shared secret information between these
entities);
o EEとカリフォルニア-1は左右対称のMACingキーを共有しません(すなわち、バンドのすぎ外に、これらの実体の間には、共有秘密キー情報があります)。
o sender name in ir MUST be present (and identical to the subject
name present in the external identity certificate);
o 中の送付者名、不-、現在と(外部のアイデンティティ証明書の現在の対象の名前と同じ)になってください;でなければならない
o protectionAlg of MSG_SIG_ALG MUST be used in all messages;
o protectionAlg、_エムエスジーSIG_ALG MUSTにおいて、すべてが通信させる中古のコネはそうです。
o external identity cert. MUST be carried in ir extraCerts field
o 外部のアイデンティティ本命。 不-extraCerts分野で運ばなければなりません。
o senderKID and recipKID are not used;
o senderKIDとrecipKIDは使用されていません。
Adams, et al. Standards Track [Page 82] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[82ページ]。
o body is ir or ip;
o または、ボディーがそうである、不-、ip。
o protection bits are calculated according to the protectionAlg
field.
o protectionAlg分野に従って、保護ビットは計算されます。
Appendix F. Compilable ASN.1 Definitions
付録F.Compilable ASN.1定義
PKIXCMP {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-mod-cmp2000(16)}
PKIXCMPiso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イドモッズcmp2000(16)
DEFINITIONS EXPLICIT TAGS ::=
定義、明白なタグ:、:=
BEGIN
始まってください。
-- EXPORTS ALL --
-- すべてを輸出します--
IMPORTS
輸入
Certificate, CertificateList, Extensions, AlgorithmIdentifier,
UTF8String -- if required; otherwise, comment out
FROM PKIX1Explicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit-88(1)}
証明書、CertificateList、Extensions、AlgorithmIdentifier、UTF8String--必要なら。 さもなければ、出ているFROM PKIX1Explicit88について論評してください。iso(1)の特定された組織(3)のdod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)のイドのpkix1の明白な88(1)
GeneralName, KeyIdentifier
FROM PKIX1Implicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-implicit-88(2)}
PKIX1Implicit88からのGeneralName、KeyIdentifieriso(1)の特定された組織(3)のdod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)のイドのpkix1の内在している88(2)
CertTemplate, PKIPublicationInfo, EncryptedValue, CertId,
CertReqMessages
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)}
PKIXCRMF-2005からのCertTemplate、PKIPublicationInfo、EncryptedValue、CertId、CertReqMessagesiso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イドモッズcrmf2005(36)
-- see also the behavioral clarifications to CRMF codified in
-- Appendix C of this specification
-- また、中で成文化されたCRMFにおいて行動の明確化を見てください--、この仕様の付録C
CertificationRequest
FROM PKCS-10 {iso(1) member-body(2)
us(840) rsadsi(113549)
pkcs(1) pkcs-10(10) modules(1) pkcs-10(1)}
PKCS-10からのCertificationRequestiso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-10(10)モジュール(1)pkcs-10(1)
-- (specified in RFC 2986 with 1993 ASN.1 syntax and IMPLICIT
-- tags). Alternatively, implementers may directly include
-- the [PKCS10] syntax in this module
-- (1993のASN.1構文とIMPLICITとの指定されたコネRFC2986--タグ)。 あるいはまた、implementersが直接含むかもしれない、--、このモジュールによる[PKCS10]構文
Adams, et al. Standards Track [Page 83] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[83ページ]。
;
;
-- the rest of the module contains locally-defined OIDs and -- constructs
-- そして、モジュールの残りが局所的に定義されたOIDsを含んでいる、--、構造物
CMPCertificate ::= CHOICE {
x509v3PKCert Certificate
}
-- This syntax, while bits-on-the-wire compatible with the
-- standard X.509 definition of "Certificate", allows the
-- possibility of future certificate types (such as X.509
-- attribute certificates, WAP WTLS certificates, or other kinds
-- of certificates) within this certificate management protocol,
-- should a need ever arise to support such generality. Those
-- implementations that do not foresee a need to ever support
-- other certificate types MAY, if they wish, comment out the
-- above structure and "un-comment" the following one prior to
-- compiling this ASN.1 module. (Note that interoperability
-- with implementations that don't do this will be unaffected by
-- this change.)
CMPCertificate:、:= CHOICE x509v3PKCert Certificate--この構文、ワイヤのコンパチブルビットをゆったり過ごす、--「証明書」の標準のX.509定義、許容、--必要性がそのような一般性を支持するために起こるなら経営者側が議定書の中で述べるこの証明書の中の将来の証明書タイプ(証明書のX.509(属性証明書、WAP WTLS証明書、または他の種類)などの)の可能性。 彼らが願うならそれら--支持する必要性について見通さない実現--他の証明書タイプがコメントとして除くかもしれない、上、このASN.1モジュールをコンパイルして、以下の1つについて構造化して、「不-論評します」。 (この意志をしない実現がある相互運用性が影響を受けないことに注意してください--この変化)
-- CMPCertificate ::= Certificate
-- CMPCertificate:、:= 証明書
PKIMessage ::= SEQUENCE {
header PKIHeader,
body PKIBody,
protection [0] PKIProtection OPTIONAL,
extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate
OPTIONAL
}
PKIMessage:、:= 系列ヘッダーPKIHeader、ボディーPKIBody、保護[0]PKIProtection OPTIONAL、extraCerts[1]SEQUENCE SIZE(1..MAX)OF CMPCertificate OPTIONAL
PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage
PKIMessages:、:= PKIMessageの系列サイズ(1..MAX)
PKIHeader ::= SEQUENCE {
pvno INTEGER { cmp1999(1), cmp2000(2) },
sender GeneralName,
-- identifies the sender
recipient GeneralName,
-- identifies the intended recipient
messageTime [0] GeneralizedTime OPTIONAL,
-- time of production of this message (used when sender
-- believes that the transport will be "suitable"; i.e.,
-- that the time will still be meaningful upon receipt)
protectionAlg [1] AlgorithmIdentifier OPTIONAL,
-- algorithm used for calculation of protection bits
senderKID [2] KeyIdentifier OPTIONAL,
recipKID [3] KeyIdentifier OPTIONAL,
-- to identify specific keys used for protection
PKIHeader:、:= SEQUENCE、pvno INTEGER、cmp1999(1)、cmp2000(2)、送付者GeneralName--、特定、送付者受取人GeneralName--意図している受取人messageTime0GeneralizedTime OPTIONALを特定します; このメッセージの生産の時間、(送付者であるときに、使用されます--、「適当」すなわちそれでも時間がある領収書で重要な) protectionAlgが保護に使用される特定のキーを特定する1AlgorithmIdentifier OPTIONALであるつもりであった(アルゴリズムは保護ビットの計算にsenderKID2KeyIdentifier OPTIONALを使用しました、recipKID3KeyIdentifier OPTIONAL)ならそれが輸送であると信じています。
Adams, et al. Standards Track [Page 84] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[84ページ]。
transactionID [4] OCTET STRING OPTIONAL,
-- identifies the transaction; i.e., this will be the same in
-- corresponding request, response, certConf, and PKIConf
-- messages
senderNonce [5] OCTET STRING OPTIONAL,
recipNonce [6] OCTET STRING OPTIONAL,
-- nonces used to provide replay protection, senderNonce
-- is inserted by the creator of this message; recipNonce
-- is a nonce previously inserted in a related message by
-- the intended recipient of this message
freeText [7] PKIFreeText OPTIONAL,
-- this may be used to indicate context-specific instructions
-- (this field is intended for human consumption)
generalInfo [8] SEQUENCE SIZE (1..MAX) OF
InfoTypeAndValue OPTIONAL
-- this may be used to convey context-specific information
-- (this field not primarily intended for human consumption)
}
transactionID[4]OCTET STRING OPTIONAL--取引を特定します。 すなわち、これは--対応する要求、応答、certConf、およびPKIConf--メッセージsenderNonce[5]OCTET STRING OPTIONALで同じになるでしょう、recipNonce[6]OCTET STRING OPTIONAL--一回だけは以前はよく反復操作による保護を提供していました、senderNonce--このメッセージの創造者によって挿入されます。 recipNonceに、この意図している受取人はfreeText[7]PKIFreeText OPTIONALを通信させます--これが文脈特有の指示を示すのに使用されるかもしれないという以前に関連するメッセージに挿入された一回だけ(この分野は人間の消費で意図する)はgeneralInfo[8]SEQUENCE SIZE(1..MAX)OF InfoTypeAndValue OPTIONAL(これは文脈特殊情報を伝えるのに使用されるかもしれません)(人間の消費で主として意図しないこの分野)です。
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
-- text encoded as UTF-8 String [RFC3629] (note: each
-- UTF8String MAY include an [RFC3066] language tag
-- to indicate the language of the contained text
-- see [RFC2482] for details)
PKIFreeText:、:= SEQUENCE SIZE(1..MAX)OF UTF8String--UTF-8 String[RFC3629]としてコード化されたテキスト(注意: 含まれているテキストの言語--詳細に関して見るように[RFC2482]示すUTF8Stringが[RFC3066]言語タグを含むかもしれないというそれぞれ)
PKIBody ::= CHOICE { -- message-specific body elements
ir [0] CertReqMessages, --Initialization Request
ip [1] CertRepMessage, --Initialization Response
cr [2] CertReqMessages, --Certification Request
cp [3] CertRepMessage, --Certification Response
p10cr [4] CertificationRequest, --imported from [PKCS10]
popdecc [5] POPODecKeyChallContent, --pop Challenge
popdecr [6] POPODecKeyRespContent, --pop Response
kur [7] CertReqMessages, --Key Update Request
kup [8] CertRepMessage, --Key Update Response
krr [9] CertReqMessages, --Key Recovery Request
krp [10] KeyRecRepContent, --Key Recovery Response
rr [11] RevReqContent, --Revocation Request
rp [12] RevRepContent, --Revocation Response
ccr [13] CertReqMessages, --Cross-Cert. Request
ccp [14] CertRepMessage, --Cross-Cert. Response
ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann.
cann [16] CertAnnContent, --Certificate Ann.
rann [17] RevAnnContent, --Revocation Ann.
crlann [18] CRLAnnContent, --CRL Announcement
pkiconf [19] PKIConfirmContent, --Confirmation
nested [20] NestedMessageContent, --Nested Message
genm [21] GenMsgContent, --General Message
PKIBody:、:= 特選 メッセージ特有のボディー要素不-0CertReqMessages--1CertRepMessage(初期設定Response cr2CertReqMessages)の初期設定Request ip証明Request cp3CertRepMessage--証明Response p10cr4CertificationRequest(PKCS10 popdecc5POPODecKeyChallContentから、輸入している)はChallenge popdecr6POPODecKeyRespContentを飛び出させます; --Response kur7CertReqMessagesを飛び出させてください--主要なUpdate Request kup8CertRepMessage--主要なUpdate Response krr9CertReqMessages--主要なRecovery Request krp10KeyRecRepContent--主要なRecovery Response rr11RevReqContent--取消しRequest rp12RevRepContent--取消しResponse ccr13CertReqMessages--交差している本命; ccp14CertRepMessage--交差している本命応答ckuann15CAKeyUpdAnnContent--カリフォルニアKey Updateアンcann16CertAnnContent--Certificateアンrann17RevAnnContent--Revocationアンcrlann18CRLAnnContentを要求してください、--CRL Announcement pkiconf19PKIConfirmContent--確認は20Nestedを入れ子にしました。MessageContent--入れ子にされたMessage genm[21]GenMsgContent--一般教書
Adams, et al. Standards Track [Page 85] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[85ページ]。
genp [22] GenRepContent, --General Response
error [23] ErrorMsgContent, --Error Message
certConf [24] CertConfirmContent, --Certificate confirm
pollReq [25] PollReqContent, --Polling request
pollRep [26] PollRepContent --Polling response
}
ErrorMsgContent(誤りMessage certConf[24]CertConfirmContent)が証明する一般Response誤り[23]がpollReq[25]PollReqContentを確認するという応答に投票して、要求pollRep[26]PollRepContentに投票するgenp[22]GenRepContent
PKIProtection ::= BIT STRING
PKIProtection:、:= ビット列
ProtectedPart ::= SEQUENCE {
header PKIHeader,
body PKIBody
}
ProtectedPart:、:= 系列ヘッダーPKIHeader、ボディーPKIBody
id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13}
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
-- note: implementations MAY wish to limit acceptable sizes
-- of this string to values appropriate for their environment
-- in order to reduce the risk of denial-of-service attacks
owf AlgorithmIdentifier,
-- AlgId for a One-Way Function (SHA-1 recommended)
iterationCount INTEGER,
-- number of times the OWF is applied
-- note: implementations MAY wish to limit acceptable sizes
-- of this integer to values appropriate for their environment
-- in order to reduce the risk of denial-of-service attacks
mac AlgorithmIdentifier
-- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
} -- or HMAC [RFC2104, RFC2202])
イド-PasswordBasedMac物の識別子:、:= 1 2、840、113533、7、66 13、PBMParameter:、:= SEQUENCE、OCTET STRING、One-道のFunction(推薦されたSHA-1)iterationCount INTEGERのための--: 実現がサービス不能攻撃owf AlgorithmIdentifierの危険を減少させるためにこのストリングの許容できるサイズを彼らの環境に、適切な値に制限したがっているかもしれない注意--AlgIdに塩味を付けさせてください; OWFが適用されているという回の数--注意: 実現は許容できるサイズを制限したがっているかもしれません--値へのこの整数では、サービス不能攻撃mac AlgorithmIdentifierの危険を減少させる彼らの環境には、MAC AlgIdを当ててください。(例えば、DES-MAC、デスMACを3倍にしてください、[PKCS11]HMAC[RFC2104、RFC2202)
id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30}
DHBMParameter ::= SEQUENCE {
owf AlgorithmIdentifier,
-- AlgId for a One-Way Function (SHA-1 recommended)
mac AlgorithmIdentifier
-- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
} -- or HMAC [RFC2104, RFC2202])
イド-DHBasedMac物の識別子:、:= 1 2、840、113533、7、66 30、DHBMParameter:、:= SEQUENCE、owf AlgorithmIdentifier--One-道のFunction(推薦されたSHA-1)mac AlgorithmIdentifierのためのAlgId--MAC AlgId(例えば、DES-MAC、デスMACを3倍にしてください、[PKCS11]HMAC[RFC2104、RFC2202)
NestedMessageContent ::= PKIMessages
NestedMessageContent:、:= PKIMessages
PKIStatus ::= INTEGER {
accepted (0),
-- you got exactly what you asked for
grantedWithMods (1),
-- you got something like what you asked for; the
-- requester is responsible for ascertaining the differences
PKIStatus:、:= INTEGER、あなたはまさにgrantedWithMods(1)のために尋ねたものを得ました--あなたが何かあなたが求めたもののようなものを得たという(0)を受け入れる、--リクエスタが違いを確かめるのに原因となる
Adams, et al. Standards Track [Page 86] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[86ページ]。
rejection (2),
-- you don't get it, more information elsewhere in the message
waiting (3),
-- the request body part has not yet been processed; expect to
-- hear more later (note: proper handling of this status
-- response MAY use the polling req/rep PKIMessages specified
-- in Section 5.3.22; alternatively, polling in the underlying
-- transport layer MAY have some utility in this regard)
revocationWarning (4),
-- this message contains a warning that a revocation is
-- imminent
revocationNotification (5),
-- notification that a revocation has occurred
keyUpdateWarning (6)
-- update already done for the oldCertId specified in
-- CertReqMsg
}
拒絶(2)--あなたはそれを得ません、メッセージ待ち(3)のほかの場所の詳しい情報--要求身体の部分はまだ処理されていません。 予想してください--後で、(注意: この状態の適切な取り扱い--あるいはまた基本的さで投票して、世論調査req/レップPKIMessagesがセクション5.3.22で指定した応答5月の使用--トランスポート層には、この関係) revocationWarningのこのメッセージが取消しがそうであるという警告を含んでいるというoldCertIdのためにして、差し迫っているrevocationNotification(5)(取消しに起こったkeyUpdateWarning(6)があるという通知)が既にアップデートする(4)が指定した何らかのユーティリティがあるかもしれません--CertReqMsg}ともう少し聞いてください。
PKIFailureInfo ::= BIT STRING {
-- since we can fail in more than one way!
-- More codes may be added in the future if/when required.
badAlg (0),
-- unrecognized or unsupported Algorithm Identifier
badMessageCheck (1),
-- integrity check failed (e.g., signature did not verify)
badRequest (2),
-- transaction not permitted or supported
badTime (3),
-- messageTime was not sufficiently close to the system time,
-- as defined by local policy
badCertId (4),
-- no certificate could be found matching the provided criteria
badDataFormat (5),
-- the data submitted has the wrong format
wrongAuthority (6),
-- the authority indicated in the request is different from the
-- one creating the response token
incorrectData (7),
-- the requester's data is incorrect (for notary services)
missingTimeStamp (8),
-- when the timestamp is missing but should be there
-- (by policy)
badPOP (9),
-- the proof-of-possession failed
certRevoked (10),
-- the certificate has already been revoked
certConfirmed (11),
-- the certificate has already been confirmed
PKIFailureInfo:、:= より多くのコードが/であるなら必要であると将来、加えられるかもしれません。BIT STRING、--私たちが1つ以上の方法に失敗できるので!--、badAlg(0)--認識されていないかサポートされないAlgorithm Identifier badMessageCheck(1)--保全チェックが失敗した(例えば、署名が確かめなかった、)、badRequest(2); 取引は、badTime(3)を可能にもしませんでしたし、支持もしませんでした--messageTimeが地方の方針badCertId(4)によって定義されるようにシステム時間の十分近くにありませんでした--提供された評価基準badDataFormat(5)を合わせているのを証明書を全く見つけることができませんでした; 提出されたデータは間違った形式wrongAuthority(6)を持っています--要求で示された権威は--リクエスタのデータが不正確な(公証人サービスのための)missingTimeStamp(8)であるというタイムスタンプがなくなりますが、そこにあるべきである応答象徴incorrectData(7)を作成する1つ--(方針による)badPOP(9)と異なっています--所有物の証拠はcertRevoked(10)に失敗しました--証明書は既に取り消されたcertConfirmed(11)です--証明書は既に確認されました。
Adams, et al. Standards Track [Page 87] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[87ページ]。
wrongIntegrity (12),
-- invalid integrity, password based instead of signature or
-- vice versa
badRecipientNonce (13),
-- invalid recipient nonce, either missing or wrong value
timeNotAvailable (14),
-- the TSA's time source is not available
unacceptedPolicy (15),
-- the requested TSA policy is not supported by the TSA.
unacceptedExtension (16),
-- the requested extension is not supported by the TSA.
addInfoNotAvailable (17),
-- the additional information requested could not be
-- understood or is not available
badSenderNonce (18),
-- invalid sender nonce, either missing or wrong size
badCertTemplate (19),
-- invalid cert. template or missing mandatory information
signerNotTrusted (20),
-- signer of the message unknown or not trusted
transactionIdInUse (21),
-- the transaction identifier is already in use
unsupportedVersion (22),
-- the version of the message is not supported
notAuthorized (23),
-- the sender was not authorized to make the preceding
-- request or perform the preceding action
systemUnavail (24),
-- the request cannot be handled due to system unavailability
systemFailure (25),
-- the request cannot be handled due to system failure
duplicateCertReq (26)
-- certificate cannot be issued because a duplicate
-- certificate already exists
}
wrongIntegrity(12)--無効の保全、パスワードは署名か--逆もまた同様です、badRecipientNonce(13)--無効の受取人の一回だけの、そして、なくなったか間違った値の代わりにtimeNotAvailable(14)を基礎づけました--TSAの時間ソースは利用可能なunacceptedPolicy(15)ではありません; 要求されたTSA方針はTSA. unacceptedExtension(16)によって支持されません--要求された拡大はTSA. addInfoNotAvailable(17)によって支持されません--要求された追加情報はそうであることができませんでした--分かるか、利用可能なbadSenderNonce(18)ではありません; 無効の送付者一回だけの、そして、なくなったか間違ったサイズbadCertTemplate(19)(無効の本命既に中に取引識別子があるという情報signerNotTrusted(20)(メッセージの未知の信じられたtransactionIdInUse(21)の署名者)はunsupportedVersion(22)を使用します--メッセージのバージョンは支持されたnotAuthorized(23)ではありません--送付者が先行を作るのに権限を与えられなかったのが義務的なテンプレートか取り逃がす)は前の動作systemUnaを要求するか、または実行します。(24)を脱いでください--システム使用不能systemFailure(25)のため要求を扱うことができません--システム障害duplicateCertReq(26)のため要求を扱うことができません--証明書を発行できない、写し--証明書は既に存在しています。
PKIStatusInfo ::= SEQUENCE {
status PKIStatus,
statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL
}
PKIStatusInfo:、:= 系列状態PKIStatus、statusString PKIFreeText OPTIONAL、failInfo PKIFailureInfo OPTIONAL
OOBCert ::= CMPCertificate
OOBCert:、:= CMPCertificate
OOBCertHash ::= SEQUENCE {
hashAlg [0] AlgorithmIdentifier OPTIONAL,
certId [1] CertId OPTIONAL,
hashVal BIT STRING
OOBCertHash:、:= 系列、hashAlg[0]AlgorithmIdentifierの任意の、そして、certId[1]CertId任意のhashValビット列
Adams, et al. Standards Track [Page 88] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[88ページ]。
-- hashVal is calculated over the DER encoding of the
-- self-signed certificate with the identifier certID.
}
-- hashValがDERコード化に関して計算される、--識別子certIDがある自己署名入りの証書。 }
POPODecKeyChallContent ::= SEQUENCE OF Challenge
-- One Challenge per encryption key certification request (in the
-- same order as these requests appear in CertReqMessages).
POPODecKeyChallContent:、:= 中、SEQUENCE OF Challenge、暗号化の主要な証明要求あたりの1つのChallenge、(--、これらの要求としてのオーダーがCertReqMessagesで見える同じこと)
Challenge ::= SEQUENCE {
owf AlgorithmIdentifier OPTIONAL,
以下に挑戦してください:= SEQUENCE、owf AlgorithmIdentifier OPTIONAL
-- MUST be present in the first Challenge; MAY be omitted in
-- any subsequent Challenge in POPODecKeyChallContent (if
-- omitted, then the owf used in the immediately preceding
-- Challenge is to be used).
-- 最初のChallengeに存在していなければなりません。 中でいくらか省略されるかもしれない、POPODecKeyChallContentのその後のChallenge、(--、省略されています、次にすぐに前で使用されるowf--挑戦するのが使用されていることになっている)
witness OCTET STRING,
-- the result of applying the one-way function (owf) to a
-- randomly-generated INTEGER, A. [Note that a different
-- INTEGER MUST be used for each Challenge.]
challenge OCTET STRING
-- the encryption (under the public key for which the cert.
-- request is being made) of Rand, where Rand is specified as
-- Rand ::= SEQUENCE {
-- int INTEGER,
-- - the randomly-generated INTEGER A (above)
-- sender GeneralName
-- - the sender's name (as included in PKIHeader)
-- }
}
目撃者OCTET STRING(一方向関数(owf)をaに適用するという結果)はINTEGERを手当たりしだいに発生させました、A.、[注意、aそんなに異なる--、INTEGER MUST、各Challenge] 挑戦OCTET STRINGには、使用されてください--、暗号化(公開鍵、どれ、本命。 -- 要求をしています。) Randが指定されるRandについて--、底ならし革:、:= SEQUENCE、--int INTEGER----手当たりしだいに発生しているINTEGER A(above)(送付者GeneralName)--送付者の名前(PKIHeaderに含まれているように)--
POPODecKeyRespContent ::= SEQUENCE OF INTEGER
-- One INTEGER per encryption key certification request (in the
-- same order as these requests appear in CertReqMessages). The
-- retrieved INTEGER A (above) is returned to the sender of the
-- corresponding Challenge.
POPODecKeyRespContent:、:= 中、SEQUENCE OF INTEGER、暗号化の主要な証明要求あたりの1つのINTEGER、(--、これらの要求としてのオーダーがCertReqMessagesで見える同じこと) --、(above)が送付者に返されるINTEGER Aを検索する、--対応するChallenge。
CertRepMessage ::= SEQUENCE {
caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate
OPTIONAL,
response SEQUENCE OF CertResponse
}
CertRepMessage:、:= 系列caPubs[1]SEQUENCE SIZE(1..MAX)OF CMPCertificate OPTIONAL、応答SEQUENCE OF CertResponse
CertResponse ::= SEQUENCE {
certReqId INTEGER,
-- to match this response with corresponding request (a value
-- of -1 is to be used if certReqId is not specified in the
-- corresponding request)
CertResponse:、:= SEQUENCE、対応するこの応答が要求するマッチへのcertReqId INTEGER(値--certReqIdが中で指定されないなら-1に、使用されることになっていてください、--、対応する要求)
Adams, et al. Standards Track [Page 89] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[89ページ]。
status PKIStatusInfo,
certifiedKeyPair CertifiedKeyPair OPTIONAL,
rspInfo OCTET STRING OPTIONAL
-- analogous to the id-regInfo-utf8Pairs string defined
-- for regInfo in CertReqMsg [CRMF]
}
状態PKIStatusInfo、certifiedKeyPair CertifiedKeyPair OPTIONAL、CertReqMsg[CRMF]のregInfoのための定義されたイド-regInfo-utf8Pairsストリングへの類似のrspInfo OCTET STRING OPTIONAL
CertifiedKeyPair ::= SEQUENCE {
certOrEncCert CertOrEncCert,
privateKey [0] EncryptedValue OPTIONAL,
-- see [CRMF] for comment on encoding
publicationInfo [1] PKIPublicationInfo OPTIONAL
}
CertifiedKeyPair:、:= 系列certOrEncCert CertOrEncCert、privateKey[0]EncryptedValue OPTIONAL--publicationInfo[1]PKIPublicationInfo OPTIONALをコード化するコメントに関して[CRMF]を見てください。
CertOrEncCert ::= CHOICE {
certificate [0] CMPCertificate,
encryptedCert [1] EncryptedValue
}
CertOrEncCert:、:= 選択証明書[0]CMPCertificate、encryptedCert[1]EncryptedValue
KeyRecRepContent ::= SEQUENCE {
status PKIStatusInfo,
newSigCert [0] CMPCertificate OPTIONAL,
caCerts [1] SEQUENCE SIZE (1..MAX) OF
CMPCertificate OPTIONAL,
keyPairHist [2] SEQUENCE SIZE (1..MAX) OF
CertifiedKeyPair OPTIONAL
}
KeyRecRepContent:、:= 系列状態PKIStatusInfo、newSigCert[0]CMPCertificate OPTIONAL、caCerts[1]SEQUENCE SIZE(1..MAX)OF CMPCertificate OPTIONAL、keyPairHist[2]SEQUENCE SIZE(1..MAX)OF CertifiedKeyPair OPTIONAL
RevReqContent ::= SEQUENCE OF RevDetails
RevReqContent:、:= RevDetailsの系列
RevDetails ::= SEQUENCE {
certDetails CertTemplate,
-- allows requester to specify as much as they can about
-- the cert. for which revocation is requested
-- (e.g., for cases in which serialNumber is not available)
crlEntryDetails Extensions OPTIONAL
-- requested crlEntryExtensions
}
RevDetails:、:= 系列certDetails CertTemplate--、リクエスタを許容する、周囲で指定できるくらい指定してください--本命、要求された((例えば、serialNumberが利用可能でない場合のための)crlEntryDetails Extensions OPTIONAL)要求されたcrlEntryExtensionsはどの取消しのためのものであるか。
RevRepContent ::= SEQUENCE {
status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo,
-- in same order as was sent in RevReqContent
revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId
OPTIONAL,
-- IDs for which revocation was requested
-- (same order as status)
crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList
OPTIONAL
RevRepContent:、:= SEQUENCE、RevReqContent revCerts[0]SEQUENCE SIZE(1..MAX)OF CertId OPTIONALで送られた同じ注文における状態SEQUENCE SIZE(1..MAX)OF PKIStatusInfo--取消しが要求されたID--(状態と同じオーダー)crls[1]SEQUENCE SIZE(1..MAX)OF CertificateList OPTIONAL
Adams, et al. Standards Track [Page 90] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[90ページ]。
-- the resulting CRLs (there may be more than one)
}
-- 結果として起こるCRLs(1つ以上があるかもしれません)
CAKeyUpdAnnContent ::= SEQUENCE {
oldWithNew CMPCertificate, -- old pub signed with new priv
newWithOld CMPCertificate, -- new pub signed with old priv
newWithNew CMPCertificate -- new pub signed with new priv
}
CAKeyUpdAnnContent:、:= 系列{oldWithNew CMPCertificate--新しいpriv newWithOld CMPCertificateを契約された古いパブ--新しいパブは古いpriv newWithNew CMPCertificateと契約しました--新しいprivを契約された新しいパブ}
CertAnnContent ::= CMPCertificate
CertAnnContent:、:= CMPCertificate
RevAnnContent ::= SEQUENCE {
status PKIStatus,
certId CertId,
willBeRevokedAt GeneralizedTime,
badSinceDate GeneralizedTime,
crlDetails Extensions OPTIONAL
-- extra CRL details (e.g., crl number, reason, location, etc.)
}
RevAnnContent:、:= 系列状態PKIStatus、certId CertId、willBeRevokedAt GeneralizedTime、badSinceDate GeneralizedTime、crlDetails Extensions OPTIONAL、--余分なCRLが(例えば、crl番号、理由、位置など)を詳しく述べる
CRLAnnContent ::= SEQUENCE OF CertificateList
CRLAnnContent:、:= CertificateListの系列
CertConfirmContent ::= SEQUENCE OF CertStatus
CertConfirmContent:、:= CertStatusの系列
CertStatus ::= SEQUENCE {
certHash OCTET STRING,
-- the hash of the certificate, using the same hash algorithm
-- as is used to create and verify the certificate signature
certReqId INTEGER,
-- to match this confirmation with the corresponding req/rep
statusInfo PKIStatusInfo OPTIONAL
}
CertStatus:、:= 系列対応するreq/レップstatusInfo PKIStatusInfo OPTIONALにこの確認に合うcertHash OCTET STRING(証明書署名certReqId INTEGERを作成して、確かめるのに使用されるように同じ細切れ肉料理アルゴリズムを使用する証明書の細切れ肉料理)
PKIConfirmContent ::= NULL
PKIConfirmContent:、:= ヌル
InfoTypeAndValue ::= SEQUENCE {
infoType OBJECT IDENTIFIER,
infoValue ANY DEFINED BY infoType OPTIONAL
}
-- Example InfoTypeAndValue contents include, but are not limited
-- to, the following (un-comment in this ASN.1 module and use as
-- appropriate for a given environment):
--
-- id-it-caProtEncCert OBJECT IDENTIFIER ::= {id-it 1}
-- CAProtEncCertValue ::= CMPCertificate
-- id-it-signKeyPairTypes OBJECT IDENTIFIER ::= {id-it 2}
-- SignKeyPairTypesValue ::= SEQUENCE OF AlgorithmIdentifier
-- id-it-encKeyPairTypes OBJECT IDENTIFIER ::= {id-it 3}
InfoTypeAndValue:、:= SEQUENCE、infoType OBJECT IDENTIFIER、infoValue、どんなDEFINED BY infoType OPTIONAL、も--例のInfoTypeAndValueはインクルードを満足させますが、限られていません--、以下、(不-このASN.1モジュールと使用でコメントする、--、与えられた環境による当て、)、: -- -- イド、それ、caProtEncCert、物の識別子:、:= イド、-、それ、1、--、CAProtEncCertValue:、:= CMPCertificate--、イド、それ、signKeyPairTypes、物の識別子:、:= イド、-、それ、2、--、SignKeyPairTypesValue:、:= AlgorithmIdentifierの系列--、イド、それ、encKeyPairTypes、物の識別子:、:= イド、-、それ、3
Adams, et al. Standards Track [Page 91] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[91ページ]。
-- EncKeyPairTypesValue ::= SEQUENCE OF AlgorithmIdentifier
-- id-it-preferredSymmAlg OBJECT IDENTIFIER ::= {id-it 4}
-- PreferredSymmAlgValue ::= AlgorithmIdentifier
-- id-it-caKeyUpdateInfo OBJECT IDENTIFIER ::= {id-it 5}
-- CAKeyUpdateInfoValue ::= CAKeyUpdAnnContent
-- id-it-currentCRL OBJECT IDENTIFIER ::= {id-it 6}
-- CurrentCRLValue ::= CertificateList
-- id-it-unsupportedOIDs OBJECT IDENTIFIER ::= {id-it 7}
-- UnsupportedOIDsValue ::= SEQUENCE OF OBJECT IDENTIFIER
-- id-it-keyPairParamReq OBJECT IDENTIFIER ::= {id-it 10}
-- KeyPairParamReqValue ::= OBJECT IDENTIFIER
-- id-it-keyPairParamRep OBJECT IDENTIFIER ::= {id-it 11}
-- KeyPairParamRepValue ::= AlgorithmIdentifer
-- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12}
-- RevPassphraseValue ::= EncryptedValue
-- id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13}
-- ImplicitConfirmValue ::= NULL
-- id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14}
-- ConfirmWaitTimeValue ::= GeneralizedTime
-- id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15}
-- OrigPKIMessageValue ::= PKIMessages
-- id-it-suppLangTags OBJECT IDENTIFIER ::= {id-it 16}
-- SuppLangTagsValue ::= SEQUENCE OF UTF8String
--
-- where
--
-- id-pkix OBJECT IDENTIFIER ::= {
-- iso(1) identified-organization(3)
-- dod(6) internet(1) security(5) mechanisms(5) pkix(7)}
-- and
-- id-it OBJECT IDENTIFIER ::= {id-pkix 4}
--
--
-- This construct MAY also be used to define new PKIX Certificate
-- Management Protocol request and response messages, or general-
-- purpose (e.g., announcement) messages for future needs or for
-- specific environments.
-- EncKeyPairTypesValue:、:= AlgorithmIdentifierの系列--、イド、それ、preferredSymmAlg、物の識別子:、:= イド、-、それ、4、--、PreferredSymmAlgValue:、:= AlgorithmIdentifier--、イド、それ、caKeyUpdateInfo、物の識別子:、:= イド、-、それ、5、--、CAKeyUpdateInfoValue:、:= CAKeyUpdAnnContent--、イド、それ、currentCRL、物の識別子:、:= イド、-、それ、6、--、CurrentCRLValue:、:= CertificateList--、イド、それ、unsupportedOIDs、物の識別子:、:= イド、-、それ、7、--、UnsupportedOIDsValue:、:= 物の識別子の系列--、イド、それ、keyPairParamReq、物の識別子:、:= イド、-、それ、10、--、KeyPairParamReqValue:、:= 物の識別子--、イド、それ、keyPairParamRep、物の識別子:、:= イド、-、それ、11、--、KeyPairParamRepValue:、:= AlgorithmIdentifer--、イド、それ、revPassphrase、物の識別子:、:= イド、-、それ、12、--、RevPassphraseValue:、:= EncryptedValue--、イド、それ、implicitConfirm、物の識別子:、:= イド、-、それ、13、--、ImplicitConfirmValue:、:= ヌル--、イド、それ、confirmWaitTime、物の識別子:、:= イド、-、それ、14、--、ConfirmWaitTimeValue:、:= GeneralizedTime--、イド、それ、origPKIMessage、物の識別子:、:= イド、-、それ、15、--、OrigPKIMessageValue:、:= PKIMessages--、イド、それ、suppLangTags、物の識別子:、:= イド、-、それ、16、--、SuppLangTagsValue:、:= SEQUENCE OF UTF8String----どこ----イド-pkix OBJECT IDENTIFIER、:、:= --iso(1)の特定された組織(3)--dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)--、--、イド、-、それ、OBJECT IDENTIFIER:、:= または、イド-pkix4--、--、--、また、この構造物が新しいPKIX Certificate--管理プロトコル要求と応答メッセージか、一般--将来の必要性への目的(例えば、発表)メッセージを定義するのに使用されるかもしれない--特定の環境。
GenMsgContent ::= SEQUENCE OF InfoTypeAndValue
GenMsgContent:、:= InfoTypeAndValueの系列
-- May be sent by EE, RA, or CA (depending on message content).
-- The OPTIONAL infoValue parameter of InfoTypeAndValue will
-- typically be omitted for some of the examples given above.
-- The receiver is free to ignore any contained OBJ. IDs that it
-- does not recognize. If sent from EE to CA, the empty set
-- indicates that the CA may send
-- any/all information that it wishes.
-- EE、RA、またはカリフォルニアによって送られるかもしれません(メッセージ内容によって)。 -- InfoTypeAndValueのOPTIONAL infoValueパラメタはそうするでしょう--上に出された例のいくつかのために通常省略されてください。 -- 受信機は無料でどんな含まれたOBJも無視できます。 ID、それ、それ--認識しないでください。 EEからカリフォルニアに送るなら、空はセットしました--カリフォルニアがいくらか発信するかもしれないのを示す、/、願っているというすべての情報。
Adams, et al. Standards Track [Page 92] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[92ページ]。
GenRepContent ::= SEQUENCE OF InfoTypeAndValue
-- Receiver MAY ignore any contained OIDs that it does not
-- recognize.
GenRepContent:、:= 受信機がそれが無視しないどんな含まれたOIDsも無視するかもしれないというSEQUENCE OF InfoTypeAndValueは認識します。
ErrorMsgContent ::= SEQUENCE {
pKIStatusInfo PKIStatusInfo,
errorCode INTEGER OPTIONAL,
-- implementation-specific error codes
errorDetails PKIFreeText OPTIONAL
-- implementation-specific error details
}
ErrorMsgContent:、:= 系列pKIStatusInfo PKIStatusInfo、errorCode INTEGER OPTIONAL--実現特有のエラーコードerrorDetails PKIFreeText OPTIONAL--実現特有の誤りの詳細
PollReqContent ::= SEQUENCE OF SEQUENCE {
certReqId INTEGER
}
PollReqContent:、:= 系列の系列certReqId整数
PollRepContent ::= SEQUENCE OF SEQUENCE {
certReqId INTEGER,
checkAfter INTEGER, -- time in seconds
reason PKIFreeText OPTIONAL
}
PollRepContent:、:= 系列の系列certReqId INTEGER、checkAfter INTEGER--秒の時にPKIFreeText OPTIONALを推論してください。
END -- of CMP module
END--CMPモジュールについて
Appendix G. Acknowledgements
付録G.承認
The authors gratefully acknowledge the contributions of various members of the IETF PKIX Working Group and the ICSA CA-talk mailing list (a list solely devoted to discussing CMP interoperability efforts). Many of these contributions significantly clarified and improved the utility of this specification. Tomi Kause thanks Vesa Suontama and Toni Tammisalo for review and comments.
作者は感謝して、IETF PKIX作業部会の様々なメンバーの貢献とICSA CA-話のメーリングリスト(唯一CMP相互運用性の努力について議論するのにささげられたリスト)を承諾します。 これらの貢献の多くが、この仕様に関するユーティリティをかなりはっきりさせて、改良しました。 トミーKauseはレビューとコメントについてVesa SuontamaとトニーTammisaloに感謝します。
Adams, et al. Standards Track [Page 93] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[93ページ]。
Authors' Addresses
作者のアドレス
Carlisle Adams University of Ottawa 800 King Edward Avenue P.O.Box 450, Station A Ottawa, Ontario K1N 6N5 CA
カーライルアダムスオタワ大学800キング・エドワードアベニュー私書箱450、駅のオタワ、オンタリオK1N 6N5カリフォルニア
Phone: (613) 562-5800 ext. 2345 Fax: (613) 562-5664 EMail: cadams@site.uottawa.ca
以下に電話をしてください。 (613) 562-5800 ext。 2345 Fax: (613) 562-5664 メールしてください: cadams@site.uottawa.ca
Stephen Farrell Trinity College Dublin Distributed Systems Group Computer Science Department Dublin IE
スティーブンファレルトリニティー・カレッジダブリン分散システムはコンピュータサイエンス部のダブリンIEを分類します。
Phone: +353-1-608-2945 EMail: stephen.farrell@cs.tcd.ie
以下に電話をしてください。 +353-1-608-2945 メールしてください: stephen.farrell@cs.tcd.ie
Tomi Kause SSH Communications Security Corp Valimotie 17 Helsinki 00380 FI
トミーKauseセキュアシェル (SSH)通信秘密保全Corp Valimotie17ヘルシンキ00380FI
Phone: +358 20 500 7415 EMail: toka@ssh.com
以下に電話をしてください。 +358 20 500 7415はメールされます: toka@ssh.com
Tero Mononen SafeNet, Inc. Fredrikinkatu 47 Helsinki 00100 FI
Tero Mononen SafeNet Inc.Fredrikinkatu47ヘルシンキ00100FI
Phone: +358 20 500 7814 EMail: tmononen@safenet-inc.com
以下に電話をしてください。 +358 20 500 7814はメールされます: tmononen@safenet-inc.com
Adams, et al. Standards Track [Page 94] RFC 4210 CMP September 2005
アダムス、他 規格はCMP2005年9月にRFC4210を追跡します[94ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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に情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Adams, et al. Standards Track [Page 95]
アダムス、他 標準化過程[95ページ]
一覧
スポンサーリンク
