[要約] RFC 5272は、CMS（CMC）を介した証明書管理に関する規格であり、証明書の要求、更新、取り消し、再発行などの操作を効率的に行うための手法を提供します。目的は、セキュリティ証明書の管理プロセスを簡素化し、信頼性と効率性を向上させることです。
Network Working Group J. Schaad
Request for Comments: 5272 Soaring Hawk Consulting
Obsoletes: 2797 M. Myers
Category: Standards Track TraceRoute Security, Inc.
June 2008
Certificate Management over CMS (CMC)
CMS（CMC）の証明書管理
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community:
このドキュメントでは、暗号化メッセージ構文（CMS）を使用した証明書管理プロトコルであるCMCのベース構文を定義します。このプロトコルは、インターネット公開キーインフラストラクチャ（PKI）コミュニティ内の2つの直接的なニーズに対応しています。
1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Cryptography Standard), and
1. CMSおよびPKCS＃10（公開キー暗号化標準）に基づく公開キー認定製品とサービスへのインターフェイスの必要性、および
2. The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design.
2. 暗号化用のPKI登録プロトコルの必要性は、アルゴリズムまたはハードウェア設計によるキーのみです。
CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition.
CMCでは、完全な定義のためにこのドキュメントとともに、輸送文書と要件使用文書の使用も必要です。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Terminology . . . . . . . . . . . . . . . . . 5
1.3. Changes since RFC 2797 . . . . . . . . . . . . . . . . . . 5
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Protocol Requests/Responses . . . . . . . . . . . . . . . 9
3. PKI Requests . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Simple PKI Request . . . . . . . . . . . . . . . . . . . . 10
3.2. Full PKI Request . . . . . . . . . . . . . . . . . . . . . 12
3.2.1. PKIData Content Type . . . . . . . . . . . . . . . . . 13
3.2.1.1. Control Syntax . . . . . . . . . . . . . . . . . . 14
3.2.1.2. Certification Request Formats . . . . . . . . . . 15
3.2.1.2.1. PKCS #10 Certification Syntax . . . . . . . . 16
3.2.1.2.2. CRMF Certification Syntax . . . . . . . . . . 17
3.2.1.2.3. Other Certification Request . . . . . . . . . 18
3.2.1.3. Content Info Objects . . . . . . . . . . . . . . . 19
3.2.1.3.1. Authenticated Data . . . . . . . . . . . . . . 19
3.2.1.3.2. Data . . . . . . . . . . . . . . . . . . . . . 20
3.2.1.3.3. Enveloped Data . . . . . . . . . . . . . . . . 20
3.2.1.3.4. Signed Data . . . . . . . . . . . . . . . . . 20
3.2.1.4. Other Message Bodies . . . . . . . . . . . . . . . 21
3.2.2. Body Part Identification . . . . . . . . . . . . . . . 21
3.2.3. CMC Unsigned Data Attribute . . . . . . . . . . . . . 22
4. PKI Responses . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1. Simple PKI Response . . . . . . . . . . . . . . . . . . . 23
4.2. Full PKI Response . . . . . . . . . . . . . . . . . . . . 24
4.2.1. PKIResponse Content Type . . . . . . . . . . . . . . . 24
5. Application of Encryption to a PKI Request/Response . . . . . 25
6. Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1. CMC Status Info Controls . . . . . . . . . . . . . . . . . 28
6.1.1. Extended CMC Status Info Control . . . . . . . . . . . 28
6.1.2. CMC Status Info Control . . . . . . . . . . . . . . . 30
6.1.3. CMCStatus Values . . . . . . . . . . . . . . . . . . . 31
6.1.4. CMCFailInfo . . . . . . . . . . . . . . . . . . . . . 32
6.2. Identification and Identity Proof Controls . . . . . . . . 33
6.2.1. Identity Proof Version 2 Control . . . . . . . . . . . 33
6.2.2. Identity Proof Control . . . . . . . . . . . . . . . . 35
6.2.3. Identification Control . . . . . . . . . . . . . . . . 35
6.2.4. Hardware Shared-Secret Token Generation . . . . . . . 36
6.3. Linking Identity and POP Information . . . . . . . . . . . 36
6.3.1. Cryptographic Linkage . . . . . . . . . . . . . . . . 37
6.3.1.1. POP Link Witness Version 2 Controls . . . . . . . 37
6.3.1.2. POP Link Witness Control . . . . . . . . . . . . . 38
6.3.1.3. POP Link Random Control . . . . . . . . . . . . . 38
6.3.2. Shared-Secret/Subject DN Linking . . . . . . . . . . . 39
6.3.3. Renewal and Rekey Messages . . . . . . . . . . . . . . 39
6.4. Data Return Control . . . . . . . . . . . . . . . . . . . 40
6.5. RA Certificate Modification Controls . . . . . . . . . . . 40
6.5.1. Modify Certification Request Control . . . . . . . . . 41
6.5.2. Add Extensions Control . . . . . . . . . . . . . . . . 42
6.6. Transaction Identifier Control and Sender and
Recipient Nonce Controls . . . . . . . . . . . . . . . . . 44
6.7. Encrypted and Decrypted POP Controls . . . . . . . . . . . 45
6.8. RA POP Witness Control . . . . . . . . . . . . . . . . . . 48
6.9. Get Certificate Control . . . . . . . . . . . . . . . . . 49
6.10. Get CRL Control . . . . . . . . . . . . . . . . . . . . . 49
6.11. Revocation Request Control . . . . . . . . . . . . . . . . 50
6.12. Registration and Response Information Controls . . . . . . 52
6.13. Query Pending Control . . . . . . . . . . . . . . . . . . 53
6.14. Confirm Certificate Acceptance Control . . . . . . . . . . 53
6.15. Publish Trust Anchors Control . . . . . . . . . . . . . . 54
6.16. Authenticated Data Control . . . . . . . . . . . . . . . . 55
6.17. Batch Request and Response Controls . . . . . . . . . . . 56
6.18. Publication Information Control . . . . . . . . . . . . . 57
6.19. Control Processed Control . . . . . . . . . . . . . . . . 58
7. Registration Authorities . . . . . . . . . . . . . . . . . . . 59
7.1. Encryption Removal . . . . . . . . . . . . . . . . . . . . 60
7.2. Signature Layer Removal . . . . . . . . . . . . . . . . . 61
8. Security Considerations . . . . . . . . . . . . . . . . . . . 61
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 63
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63
11.1. Normative References . . . . . . . . . . . . . . . . . . . 63
11.2. Informative References . . . . . . . . . . . . . . . . . . 63
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 65
Appendix B. Enrollment Message Flows . . . . . . . . . . . . . . 74
B.1. Request of a Signing Certificate . . . . . . . . . . . . . 74
B.2. Single Certification Request, But Modified by RA . . . . . 75
B.3. Direct POP for an RSA Certificate . . . . . . . . . . . . 78
Appendix C. Production of Diffie-Hellman Public Key
Certification Requests . . . . . . . . . . . . . . . 81
C.1. No-Signature Signature Mechanism . . . . . . . . . . . . . 81
This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet PKI community:
このドキュメントでは、暗号化メッセージ構文（CMS）を使用した証明書管理プロトコルであるCMCのベース構文を定義します。このプロトコルは、インターネットPKIコミュニティ内の2つの直接的なニーズに対応しています。
1. The need for an interface to public key certification products and services based on CMS and PKCS #10, and
1. CMSおよびPKCS＃10に基づいた公開キー認定製品とサービスへのインターフェイスの必要性
2. The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design.
2. 暗号化用のPKI登録プロトコルの必要性は、アルゴリズムまたはハードウェア設計によるキーのみです。
A small number of additional services are defined to supplement the core certification request service.
コア認証要求サービスを補完するために、少数の追加サービスが定義されています。
The protocol must be based as much as possible on the existing CMS, PKCS #10 [PKCS10] and CRMF (Certificate Request Message Format) [CRMF] specifications.
プロトコルは、既存のCMS、PKCS＃10 [PKCS10]、およびCRMF（証明書要求メッセージ形式）[CRMF]仕様に可能な限り基づいている必要があります。
The protocol must support the current industry practice of a PKCS #10 certification request followed by a PKCS#7 "certs-only" response as a subset of the protocol.
このプロトコルは、PKCS＃10認定要求の現在の業界慣行をサポートする必要があります。その後、プロトコルのサブセットとしてPKCS＃7「CERTSのみの」応答が続きます。
The protocol must easily support the multi-key enrollment protocols required by S/MIME and other groups.
プロトコルは、S/MIMEおよび他のグループが必要とするマルチキー登録プロトコルを簡単にサポートする必要があります。
The protocol must supply a way of doing all enrollment operations in a single round-trip. When this is not possible the number of round-trips is to be minimized.
プロトコルは、すべての登録操作を1回の往復で行う方法を提供する必要があります。これが不可能な場合、ラウンドトリップの数を最小限に抑える必要があります。
The protocol must be designed such that all key generation can occur on the client.
プロトコルは、すべてのキー生成がクライアントで発生するように設計する必要があります。
Support must exist for the mandatory algorithms used by S/MIME. Support should exist for all other algorithms cited by the S/MIME core documents.
S/MIMEで使用される必須アルゴリズムのサポートが存在する必要があります。S/MIMEコアドキュメントで引用された他のすべてのアルゴリズムについてサポートが存在する必要があります。
The protocol must contain Proof-of-Possession (POP) methods. Optional provisions for multiple-round-trip POP will be made if necessary.
プロトコルには、プルーフオブポッセッション（POP）メソッドを含める必要があります。必要に応じて、複数ラウンドトリップポップのオプションの規定が作成されます。
The protocol must support deferred and pending responses to enrollment requests for cases where external procedures are required to issue a certificate.
プロトコルは、証明書を発行するために外部手順が必要な場合の登録要求に対する延期および保留中の応答をサポートする必要があります。
The protocol must support arbitrary chains of Registration Authorities (RAs) as intermediaries between certification requesters and Certification Authorities (CAs).
このプロトコルは、認証要求者と認証当局（CAS）の間の仲介者として、登録当局（RAS）の任意のチェーンをサポートする必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
We have done a major overhaul on the layout of the document. This included two different steps. Firstly we removed some sections from the document and moved them to two other documents. Information on how to transport our messages are now found in [CMC-TRANS]. Information on which controls and sections of this document must be implemented along with which algorithms are required can now be found in [CMC-COMPL].
ドキュメントのレイアウトに関する大規模なオーバーホールを行いました。これには、2つの異なる手順が含まれていました。まず、ドキュメントからいくつかのセクションを削除し、それらを他の2つのドキュメントに移動しました。メッセージの輸送方法に関する情報は、[CMC-Trans]にあるようになりました。このドキュメントのコントロールとセクションを実装する必要がある情報は、[CMC-Compl]にアルゴリズムが必要なアルゴリズムが必要になるようになりました。
A number of new controls have been added in this version:
このバージョンには、多くの新しいコントロールが追加されています。
Extended CMC Status Info Section 6.1.1
拡張CMCステータス情報セクション6.1.1
Publish Trust Anchors Section 6.15
トラストアンカーセクション6.15を公開します
Authenticate Data Section 6.16
データの認証セクション6.16
Batch Request and Response Processing Section 6.17
バッチリクエストと応答処理セクション6.17
Publication Information Section 6.18
出版情報セクション6.18
Modify Certification Request Section 6.5.1
認定リクエストセクション6.5.1を変更します
Control Processed Section 6.19
制御処理済みセクション6.19
Identity Proof Section 6.2.2
ID証明セクション6.2.2
Identity POP Link Witness V2 Section 6.3.1.1
IDポップリンク証人V2セクション6.3.1.1
A PKI enrollment transaction in this specification is generally composed of a single round-trip of messages. In the simplest case a PKI enrollment request, henceforth referred to as a PKI Request, is sent from the client to the server and a PKI enrollment response, henceforth referred to as a PKI Response, is then returned from the server to the client. In more complicated cases, such as delayed certificate issuance, more than one round-trip is required.
この仕様のPKI登録トランザクションは、通常、メッセージの単一の往復で構成されています。最も単純な場合、PKI登録要求は、以降PKI要求と呼ばれ、クライアントからサーバーに送信され、以降はPKI応答と呼ばれるPKI登録応答がサーバーからクライアントに返されます。遅延証明書発行などのより複雑な場合、複数の往復が必要です。
This specification defines two PKI Request types and two PKI Response types.
この仕様では、2つのPKI要求タイプと2つのPKI応答タイプを定義します。
PKI Requests are formed using either the PKCS #10 or CRMF structure. The two PKI Requests are:
PKI要求は、PKCS＃10またはCRMF構造のいずれかを使用して形成されます。2つのPKIリクエストは次のとおりです。
Simple PKI Request: the bare PKCS #10 (in the event that no other services are needed), and
簡単なPKIリクエスト：裸のPKCS＃10（他のサービスが必要ない場合）、および
Full PKI Request: one or more PKCS #10, CRMF or Other Request Messages structures wrapped in a CMS encapsulation as part of a PKIData.
完全なPKIリクエスト：PKIDATAの一部としてCMSカプセル化に包まれた1つ以上のPKCS＃10、CRMFまたはその他の要求メッセージ構造。
PKI Responses are based on SignedData or AuthenticatedData [CMS]. The two PKI Responses are
PKI応答は、SignedDataまたはAuthenticatedData [CMS]に基づいています。2つのPKI応答はです
Simple PKI Response: a "certs-only" SignedData (in the event no other services are needed), or
単純なPKI応答：「証明書のみ」SignedData（他のサービスが必要ない場合）、または
Full PKI Response: a PKIResponse content type wrapped in a SignedData.
完全なPKI応答：signedDataに包まれたpkiresponseコンテンツタイプ。
No special services are provided for either renewal (i.e., a new certificate with the same key) or rekey (i.e., a new certificate with a new key) of client certificates. Instead renewal and rekey requests look the same as any certification request, except that the identity proof is supplied by existing certificates from a trusted CA. (This is usually the same CA, but could be a different CA in the same organization where naming is shared.)
クライアント証明書の更新（つまり、同じキーを含む新しい証明書）またはRekey（つまり、新しいキーを含む新しい証明書）のいずれにも特別なサービスは提供されていません。代わりに、IDの既存の証明が信頼できるCAからの既存の証明書によって提供されることを除いて、更新とRekeyのリクエストは認定要求と同じように見えます。（これは通常同じCAですが、命名が共有されているのと同じ組織では別のCAである可能性があります。）
No special services are provided to distinguish between a rekey request and a new certification request (generally for a new purpose). A control to unpublish a certificate would normally be included in a rekey request, and be omitted in a new certification request. CAs or other publishing agents are also expected to have policies for removing certificates from publication either based on new certificates being added or the expiration or revocation of a certificate.
Rekeyリクエストと新しい認証要求を区別するための特別なサービスは提供されていません（通常、新しい目的のため）。証明書を未発表のコントロールは通常、REKEYリクエストに含まれ、新しい認定リクエストで省略されます。また、CASまたはその他の出版エージェントには、追加されている新しい証明書または証明書の有効期限または取り消しに基づいて、公開から証明書を削除するためのポリシーがあることも期待されています。
A provision exists for RAs to participate in the protocol by taking PKI Requests, wrapping them in a second layer of PKI Request with additional requirements or statements from the RA and then passing this new expanded PKI Request on to the CA.
RASがPKI要求を実行し、RAからの追加要件またはステートメントを使用してPKI要求の2番目のレイヤーにラッピングし、この新しい拡張されたPKIリクエストをCAに渡すことにより、RASがプロトコルに参加するための規定が存在します。
This specification makes no assumptions about the underlying transport mechanism. The use of CMS does not imply an email-based transport. Several different possible transport methods are defined in [CMC-TRANS].
この仕様は、基礎となる輸送メカニズムについての仮定を行いません。CMSの使用は、電子メールベースのトランスポートを意味するものではありません。[CMC-Trans]では、いくつかの異なる可能な輸送方法が定義されています。
Optional services available through this specification are transaction management, replay detection (through nonces), deferred certificate issuance, certificate revocation requests and certificate/certificate revocation list (CRL) retrieval.
この仕様を通じて利用可能なオプションのサービスは、トランザクション管理、リプレイ検出（NONCES）、繰延証明書発行、証明書の取り消し要求、証明書/証明書の取り消しリスト（CRL）の取得です。
There are several different terms, abbreviations, and acronyms used in this document. These are defined here, in no particular order, for convenience and consistency of usage:
このドキュメントで使用されているいくつかの異なる用語、略語、頭字語があります。これらは、使用率の便利さと一貫性のために、順不同でここで定義されています。
End-Entity (EE) refers to the entity that owns a key pair and for whom a certificate is issued.
エンドエンティティ（EE）とは、重要なペアを所有し、証明書が発行されるエンティティを指します。
Registration Authority (RA) or Local RA (LRA) refers to an entity that acts as an intermediary between the EE and the CA. Multiple RAs can exist between the end-entity and the Certification Authority. RAs may perform additional services such as key generation or key archival. This document uses the term RA for both RA and LRA.
登録機関（RA）またはローカルRA（LRA）は、EEとCAの間の仲介者として機能するエンティティを指します。エンドエンティティと認証機関の間に複数のRAが存在する可能性があります。RASは、キージェネレーションやキーアーカイブなどの追加サービスを実行する場合があります。このドキュメントでは、RAとLRAの両方にRAという用語を使用しています。
Certification Authority (CA) refers to the entity that issues certificates.
認証機関（CA）とは、証明書を発行するエンティティを指します。
Client refers to an entity that creates a PKI Request. In this document, both RAs and EEs can be clients.
クライアントは、PKIリクエストを作成するエンティティを指します。このドキュメントでは、RASとEEの両方がクライアントになる可能性があります。
Server refers to the entities that process PKI Requests and create PKI Responses. In this document, both CAs and RAs can be servers.
サーバーは、PKI要求を処理してPKI応答を作成するエンティティを指します。このドキュメントでは、CASとRASの両方がサーバーになります。
PKCS #10 refers to the Public Key Cryptography Standard #10 [PKCS10], which defines a certification request syntax.
PKCS＃10は、公開キー暗号標準＃10 [PKCS10]を指します。これは、認証要求の構文を定義しています。
CRMF refers to the Certificate Request Message Format RFC [CRMF]. CMC uses this certification request syntax defined in this document as part of the protocol.
CRMFは、証明書リクエストメッセージフォーマットRFC [CRMF]を指します。CMCは、このドキュメントで定義されているこの認証要求の構文をプロトコルの一部として使用します。
CMS refers to the Cryptographic Message Syntax RFC [CMS]. This document provides for basic cryptographic services including encryption and signing with and without key management.
CMSは、暗号化メッセージの構文RFC [CMS]を指します。このドキュメントは、重要な管理の有無にかかわらず、暗号化や署名などの基本的な暗号化サービスを提供します。
PKI Request/Response refers to the requests/responses described in this document. PKI Requests include certification requests, revocation requests, etc. PKI Responses include certs-only messages, failure messages, etc.
PKIリクエスト/応答とは、このドキュメントで説明されているリクエスト/応答を指します。PKIリクエストには、認定リクエスト、取り消しリクエストなどが含まれます。PKI応答には、証明書のみのメッセージ、失敗メッセージなどが含まれます。
Proof-of-Identity refers to the client proving they are who they say that they are to the server.
アイデンティティの証明とは、クライアントが彼らがサーバーにいると言う人であることを証明することを指します。
Enrollment or certification request refers to the process of a client requesting a certificate. A certification request is a subset of the PKI Requests.
登録または認定リクエストとは、クライアントが証明書を要求するプロセスを指します。認証要求は、PKIリクエストのサブセットです。
Proof-of-Possession (POP) refers to a value that can be used to prove that the private key corresponding to a public key is in the possession and can be used by an end-entity. The different types of POP are:
Proof-of-Possession（POP）とは、公開鍵に対応する秘密鍵が所有されており、エンドエンティティによって使用できることを証明するために使用できる値を指します。さまざまなタイプのポップは次のとおりです。
Signature provides the required POP by a signature operation over some data.
署名は、一部のデータ上の署名操作によって必要なPOPを提供します。
Direct provides the required POP operation by an encrypted challenge/response mechanism.
Directは、暗号化されたチャレンジ/応答メカニズムによって必要なPOP操作を提供します。
Indirect provides the required POP operation by returning the issued certificate in an encrypted state. (This method is not used by CMC.)
間接は、暗号化された状態で発行された証明書を返すことにより、必要なポップ操作を提供します。（この方法はCMCでは使用されません。）
Publish provides the required POP operation by providing the private key to the certificate issuer. (This method is not currently used by CMC. It would be used by Key Generation or Key Escrow extensions.)
パブリッシュは、証明書発行者に秘密鍵を提供することにより、必要なポップ操作を提供します。（この方法は現在CMCで使用されていません。キー生成またはキーエスクロー拡張機能によって使用されます。）
Attested provides the required POP operation by allowing a trusted entity to assert that the POP has been proven by one of the above methods.
ATTESTEDは、信頼できるエンティティがPOPが上記の方法の1つによって証明されたことを主張できるようにすることにより、必要なポップ操作を提供します。
Object IDentifier (OID) is a primitive type in Abstract Syntax Notation One (ASN.1).
オブジェクト識別子（OID）は、抽象的な構文表記1（asn.1）のプリミティブタイプです。
Figure 1 shows the Simple PKI Requests and Responses. The contents of Simple PKI Request and Response are detailed in Sections 3.1 and 4.1.
図1は、単純なPKIリクエストと応答を示しています。単純なPKIリクエストと応答の内容については、セクション3.1および4.1で詳しく説明しています。
Simple PKI Request Simple PKI Response
------------------------- --------------------------
+----------+ +------------------+
| PKCS #10 | | CMS ContentInfo |
+----------+--------------+ +------------------+------+
| Certification Request | | CMS Signed Data, |
| | | no SignerInfo |
| Subject Name | |
| Subject Public Key Info | | SignedData contains one |
| (K_PUB) | | or more certificates in |
| Attributes | | the certificates field |
| | | Relevant CA certs and |
+-----------+-------------+ | CRLs can be included |
| signed with | | as well. |
| matching | | |
| K_PRIV | | encapsulatedContentInfo |
+-------------+ | is absent. |
+--------------+----------+
| unsigned |
+----------+
Figure 1: Simple PKI Requests and Responses
図1：単純なPKIリクエストと応答
Figure 2 shows the Full PKI Requests and Responses. The contents of the Full PKI Request and Response are detailed in Sections 3.2 and 4.2.
図2は、完全なPKIリクエストと応答を示しています。完全なPKIリクエストと応答の内容については、セクション3.2および4.2で詳しく説明しています。
Full PKI Request Full PKI Response
----------------------- ------------------------
+----------------+ +----------------+
| CMS ContentInfo| | CMS ContentInfo|
| CMS SignedData | | CMS SignedData |
| or Auth Data | | or Auth Data |
| object | | object |
+----------------+--------+ +----------------+--------+
| | | |
| PKIData | | PKIResponseBody |
| | | |
| Sequence of: | | Sequence of: |
| <enrollment control>* | | <enrollment control>* |
| <certification request>*| | <CMS object>* |
| <CMS object>* | | <other message>* |
| <other message>* | | |
| | | where * == zero or more |
| where * == zero or more | | |
| | | All certificates issued |
| Certification requests | | as part of the response |
| are CRMF, PKCS #10, or | | are included in the |
| Other. | | "certificates" field |
| | | of the SignedData. |
+-------+-----------------+ | Relevant CA certs and |
| signed (keypair | | CRLs can be included as |
| used may be pre-| | well. |
| existing or | | |
| identified in | +---------+---------------+
| the request) | | signed by the |
+-----------------+ | CA or an LRA |
+---------------+
Figure 2: Full PKI Requests and Responses
図2：完全なPKIリクエストと応答
Two types of PKI Requests exist. This section gives the details for both types.
2種類のPKIリクエストが存在します。このセクションでは、両方のタイプの詳細を示します。
A Simple PKI Request uses the PKCS #10 syntax CertificationRequest [PKCS10].
単純なPKIリクエストでは、PKCS＃10 Syntax認定Request [PKCS10]を使用します。
When a server processes a Simple PKI Request, the PKI Response returned is:
サーバーが単純なPKI要求を処理する場合、返されるPKI応答は次のとおりです。
Simple PKI Response on success.
成功に関する単純なPKI応答。
Full PKI Response on failure. The server MAY choose not to return a PKI Response in this case.
障害時の完全なPKI応答。この場合、サーバーはPKI応答を返さないことを選択できます。
The Simple PKI Request MUST NOT be used if a proof-of-identity needs to be included.
証明の証明を含める必要がある場合は、単純なPKI要求を使用しないでください。
The Simple PKI Request cannot be used if the private key is not capable of producing some type of signature (i.e., Diffie-Hellman (DH) keys can use the signature algorithms in [DH-POP] for production of the signature).
秘密キーが何らかのタイプの署名（つまり、Diffie-Hellman（DH）キーが[DH-POP]の署名アルゴリズムを使用して署名の生産）を使用できない場合、単純なPKI要求を使用できません。
The Simple PKI Request cannot be used for any of the advanced services specified in this document.
このドキュメントで指定された高度なサービスのいずれにも、単純なPKI要求を使用することはできません。
The client MAY incorporate one or more X.509v3 extensions in any certification request based on PKCS #10 as an ExtensionReq attribute. The ExtensionReq attribute is defined as:
クライアントは、PKCS＃10に基づいてextensionRreq属性として1つ以上のx.509v3拡張機能を任意の認証要求に組み込むことができます。extensionReq属性は次のように定義されます。
ExtensionReq ::= SEQUENCE SIZE (1..MAX) OF Extension
where Extension is imported from [PKIXCERT] and ExtensionReq is identified by:
[pkixcert]から拡張機能がインポートされ、extensionreqが識別されます。
id-ExtensionReq OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) 14}
Servers MUST be able to process all extensions defined, but not prohibited, in [PKIXCERT]. Servers are not required to be able to process other X.509v3 extensions transmitted using this protocol, nor are they required to be able to process private extensions. Servers are not required to put all client-requested extensions into a certificate. Servers are permitted to modify client-requested extensions. Servers MUST NOT alter an extension so as to invalidate the original intent of a client-requested extension. (For example, changing key usage from keyAgreement to digitalSignature.) If a certification request is denied due to the inability to handle a requested extension and a PKI Response is returned, the server MUST return a PKI Response with a CMCFailInfo value with the value unsupportedExt.
サーバーは、[pkixcert]で定義されているが禁止されていないすべての拡張機能を処理できる必要があります。サーバーは、このプロトコルを使用して送信される他のX.509V3拡張機能を処理できる必要はありません。また、プライベートエクステンションを処理できるようにする必要もありません。サーバーは、すべてのクライアント要求された拡張機能を証明書に配置する必要はありません。サーバーは、クライアント要求の拡張機能を変更することができます。サーバーは、クライアントが要求された拡張機能の元の意図を無効にするために拡張機能を変更してはなりません。（たとえば、KeyAgheementからDigitalSignatureにキーの使用法を変更します。）要求された拡張機能を処理できないため認定要求が拒否され、PKI応答が返された場合、サーバーはcmcfailinfo値を使用してpki応答を返す必要があります。。
The Full PKI Request provides the most functionality and flexibility.
完全なPKIリクエストは、最も機能と柔軟性を提供します。
The Full PKI Request is encapsulated in either a SignedData or an AuthenticatedData with an encapsulated content type of id-cct-PKIData (Section 3.2.1).
完全なPKIリクエストは、ID-CCT-PKIDATAのカプセル化されたコンテンツタイプのsignedDataまたは認証されたDataのいずれかにカプセル化されています（セクション3.2.1）。
When a server processes a Full PKI Request, a PKI Response MUST be returned. The PKI Response returned is:
サーバーが完全なPKI要求を処理する場合、PKI応答を返す必要があります。返されるPKI応答は次のとおりです。
Simple PKI Response if the enrollment was successful and only certificates are returned. (A CMCStatusInfoV2 control with success is implied.)
登録が成功し、証明書のみが返された場合、単純なPKI応答。（成功したCMCSTATUSINFOV2コントロールが暗示されています。）
Full PKI Response if the enrollment was successful and information is returned in addition to certificates, if the enrollment is pending, or if the enrollment failed.
完全なPKI応答登録が成功し、証明書に加えて情報が返された場合、登録が保留中の場合、または登録が失敗した場合。
If SignedData is used, the signature can be generated using either the private key material of an embedded signature certification request (i.e., included in the TaggedRequest tcr or crm fields) or a previously certified signature key. If the private key of a signature certification request is used, then:
SignedDataを使用する場合、署名は、組み込み署名認証リクエストの秘密キー資料（つまり、TaggedRequest TCRまたはCRMフィールドに含まれる）または以前に認定された署名キーのいずれかを使用して生成できます。署名認証リクエストの秘密鍵が使用されている場合は、次のとおりです。
a. The certification request containing the corresponding public key MUST include a Subject Key Identifier extension.
a. 対応する公開キーを含む認証要求には、サブジェクトキー識別子拡張機能を含める必要があります。
b. The subjectKeyIdentifier form of the signerIdentifier in SignerInfo MUST be used.
b. SignerInfoのSigneridentifierの件名KeyIdentifierフォームを使用する必要があります。
c. The value of the subjectKeyIdentifier form of SignerInfo MUST be the Subject Key Identifier specified in the corresponding certification request. (The subjectKeyIdentifier form of SignerInfo is used here because no certificates have yet been issued for the signing key.) If the request key is used for signing, there MUST be only one SignerInfo in the SignedData.
c. SignerInfoのsubjectKeyidentifier形式の値は、対応する認証要求で指定されたサブジェクトキー識別子でなければなりません。（SignerInfoのsubjecteyidentifierフォームは、署名キーの証明書がまだ発行されていないため、ここで使用されます。）リクエストキーが署名に使用されている場合、signeddataには1つのSignerinfoだけが必要です。
If AuthenticatedData is used, then:
AuthenticatedDataが使用されている場合、次のとおりです。
a. The Password Recipient Info option of RecipientInfo MUST be used.
a. RecipientInfoのパスワード受信者情報オプションを使用する必要があります。
b. A randomly generated key is used to compute the Message Authentication Code (MAC) value on the encapsulated content.
b. ランダムに生成されたキーは、カプセル化されたコンテンツのメッセージ認証コード（MAC）値を計算するために使用されます。
c. The input for the key derivation algorithm is a concatenation of the identifier (encoded as UTF8) and the shared-secret.
c. キー派生アルゴリズムの入力は、識別子（UTF8としてエンコード）と共有分泌範囲の連結です。
When creating a PKI Request to renew or rekey a certificate:
証明書を更新または再キーするためのPKIリクエストを作成するとき：
a. The Identification and Identity Proof controls are absent. The same information is provided by the use of an existing certificate from a CA when signing the PKI Request. In this case, the CA that issued the original certificate and the CA the request is made to will usually be the same, but could have a common operator.
a. 識別と身元証明のコントロールはありません。PKIリクエストに署名する際に、CAから既存の証明書を使用することにより、同じ情報が提供されます。この場合、元の証明書とCAを発行したCAとリクエストは通常同じですが、共通のオペレーターを持つことができます。
b. CAs and RAs can impose additional restrictions on the signing certificate used. They may require that the most recently issued signing certificate for a client be used.
b. CASとRASは、使用された署名証明書に追加の制限を課すことができます。クライアントの最近発行された署名証明書を使用することを要求する場合があります。
c. Some CAs may prevent renewal operations (i.e., reuse of the same keys). In this case the CA MUST return a PKI Response with noKeyReuse as the CMCFailInfo failure code.
c. 一部のCAは、更新操作を防ぐ場合があります（つまり、同じキーの再利用）。この場合、CAはCMCFailInfo障害コードとしてNoKeyReuseを使用してPKI応答を返す必要があります。
The PKIData content type is used for the Full PKI Request. A PKIData content type is identified by:
PKIDATAコンテンツタイプは、完全なPKIリクエストに使用されます。pkidataコンテンツタイプは、次のように識別されます。
id-cct-PKIData ::= {id-pkix id-cct(12) 2 }
The ASN.1 structure corresponding to the PKIData content type is:
pkidataコンテンツタイプに対応するASN.1構造は次のとおりです。
PKIData ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
The fields in PKIData have the following meaning:
Pkidataのフィールドには次の意味があります。
controlSequence is a sequence of controls. The controls defined in this document are found in Section 6. Controls can be defined by other parties. Details on the TaggedAttribute structure can be found in Section 3.2.1.1.
制御シーケンスは、コントロールのシーケンスです。このドキュメントで定義されているコントロールは、セクション6にあります。コントロールは、他の関係者によって定義できます。TaggedAttribute構造の詳細は、セクション3.2.1.1にあります。
reqSequence is a sequence of certification requests. The certification requests can be a CertificationRequest (PKCS #10), a CertReqMsg (CRMF), or an externally defined PKI request. Full details are found in Section 3.2.1.2. If an externally defined certification request is present, but the server does not understand the certification request (or will not process it), a CMCStatus of noSupport MUST be returned for the certification request item and no other certification requests are processed.
reqsequenceは、一連の認証要求です。認証要求は、認定リケスト（PKCS＃10）、CertreQMSG（CRMF）、または外部から定義されたPKIリクエストです。詳細については、セクション3.2.1.2に記載されています。外部から定義された認証要求が存在するが、サーバーが認証リクエストを理解していない（または処理しない）場合、認証リクエストアイテムのためにNoSupportのCMCstatusを返品する必要があり、他の認定リクエストは処理されません。
cmsSequence is a sequence of [CMS] message objects. See Section 3.2.1.3 for more details.
CMSシーケンスは[CMS]メッセージオブジェクトのシーケンスです。詳細については、セクション3.2.1.3を参照してください。
otherMsgSequence is a sequence of arbitrary data objects. Data objects placed here are referred to by one or more controls. This allows for controls to use large amounts of data without the data being embedded in the control. See Section 3.2.1.4 for more details.
othermsg sequenceは、任意のデータオブジェクトのシーケンスです。ここに配置されたデータオブジェクトは、1つ以上のコントロールによって言及されています。これにより、コントロールは、データがコントロールに埋め込まれることなく、大量のデータを使用できます。詳細については、セクション3.2.1.4を参照してください。
All certification requests encoded into a single PKIData SHOULD be for the same identity. RAs that batch process (see Section 6.17) are expected to place the PKI Requests received into the cmsSequence of a PKIData.
単一のpkidataにエンコードされたすべての認証要求は、同じIDのためである必要があります。バッチプロセス（セクション6.17を参照）がPKIリクエストをPKIDATAのCMSシーケンスに配置することが期待されるRAS。
Processing of the PKIData by a recipient is as follows:
受信者によるpkidataの処理は次のとおりです。
1. All controls should be examined and processed in an appropriate manner. The appropriate processing is to complete processing at this time, to ignore the control, or to place the control on a to-do list for later processing. Controls can be processed in any order; the order in the sequence is not significant.
1. すべてのコントロールは、適切な方法で検査および処理する必要があります。適切な処理は、現時点で処理を完了し、コントロールを無視するか、後で処理するためにTo Doリストにコントロールを配置することです。コントロールは任意の順序で処理できます。シーケンスの順序は重要ではありません。
2. Items in the reqSequence are not referenced by a control. These items, which are certification requests, also need to be processed. As with controls, the appropriate processing can be either immediate processing or addition to a to-do list for later processing.
2. reqsequenceの項目は、コントロールによって参照されません。認定要求であるこれらの項目も処理する必要があります。コントロールと同様に、適切な処理は、即時処理または後で処理するためのTo Doリストに追加することができます。
3. Finally, the to-do list is processed. In many cases, the to-do list will be ordered by grouping specific tasks together.
3. 最後に、to-doリストが処理されます。多くの場合、特定のタスクをグループ化することにより、to-doリストは注文されます。
No processing is required for cmsSequence or otherMsgSequence members of PKIData if they are present and are not referenced by a control. In this case, the cmsSequence and otherMsgSequence members are ignored.
PKidataのCMSシーケンスまたはその他のムズグシーケンスメンバーには、コントロールが参照されていない場合、処理は必要ありません。この場合、CMSシーケンスおよびその他のムシングシーケンスメンバーは無視されます。
The actions to be performed for a PKI Request/Response are based on the included controls. Each control consists of an object identifier and a value based on the object identifier.
PKIリクエスト/応答に対して実行されるアクションは、含まれているコントロールに基づいています。各コントロールは、オブジェクト識別子とオブジェクト識別子に基づく値で構成されています。
The syntax of a control is:
コントロールの構文は次のとおりです。
TaggedAttribute ::= SEQUENCE {
bodyPartID BodyPartID,
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue
}
AttributeValue ::= ANY
The fields in TaggedAttribute have the following meaning:
taggedattributeのフィールドには次の意味があります。
bodyPartID is a unique integer that identifies this control.
BodyPartidは、このコントロールを識別するユニークな整数です。
attrType is the OID that identifies the control.
attrTypeは、コントロールを識別するOIDです。
attrValues is the data values used in processing the control. The structure of the data is dependent on the specific control.
アトラッチは、コントロールの処理に使用されるデータ値です。データの構造は、特定の制御に依存します。
The final server MUST fail the processing of an entire PKIData if any included control is not recognized, that control is not already marked as processed by a Control Processed control (see Section 6.19) and no other error is generated. The PKI Response MUST include a CMCFailInfo value with the value badRequest and the bodyList MUST contain the bodyPartID of the invalid or unrecognized control(s). A server is the final server if and only if it is not passing the PKI Request on to another server. A server is not considered to be the final server if the server would have passed the PKI Request on, but instead it returned a processing error.
最終的なサーバーは、含まれている制御が認識されない場合、PKIDATA全体の処理に失敗する必要があります。そのコントロールは、制御プロセス制御によって処理されているものとしてマークされていません（セクション6.19を参照）、他のエラーは生成されません。PKI応答には、値BADREQUESTを使用してCMCFailInfo値を含める必要があり、ボディリストには無効または認識されていないコントロールのボディパルティッドが含まれている必要があります。サーバーは、PKI要求を別のサーバーに渡さない場合にのみ最終的なサーバーです。サーバーがPKI要求を渡した場合、サーバーは最終サーバーとは見なされませんが、代わりに処理エラーを返しました。
The controls defined by this document are found in Section 6.
このドキュメントで定義されたコントロールは、セクション6にあります。
Certification Requests are based on PKCS #10, CRMF, or Other Request formats. Section 3.2.1.2.1 specifies the requirements for clients and servers dealing with PKCS #10. Section 3.2.1.2.2 specifies the requirements for clients and servers dealing with CRMF. Section 3.2.1.2.3 specifies the requirements for clients and servers dealing with Other Request.
認証要求は、PKCS＃10、CRMF、またはその他のリクエスト形式に基づいています。セクション3.2.1.2.1は、PKCS＃10を扱うクライアントとサーバーの要件を指定します。セクション3.2.1.2.2は、CRMFを扱うクライアントとサーバーの要件を指定します。セクション3.2.1.2.3は、他のリクエストを扱うクライアントとサーバーの要件を指定します。
TaggedRequest ::= CHOICE {
tcr [0] TaggedCertificationRequest,
crm [1] CertReqMsg,
orm [2] SEQUENCE {
bodyPartID BodyPartID,
requestMessageType OBJECT IDENTIFIER,
requestMessageValue ANY DEFINED BY requestMessageType
}
}
The fields in TaggedRequest have the following meaning:
TaggedRequestのフィールドには、次の意味があります。
tcr is a certification request that uses the PKCS #10 syntax. Details on PKCS #10 are found in Section 3.2.1.2.1.
TCRは、PKCS＃10構文を使用する認定要求です。PKCS＃10の詳細は、セクション3.2.1.2.1にあります。
crm is a certification request that uses the CRMF syntax. Details on CRMF are found in Section 3.2.1.2.2.
CRMは、CRMF構文を使用する認証要求です。CRMFの詳細は、セクション3.2.1.2.2にあります。
orm is an externally defined certification request. One example is an attribute certification request. The fields of this structure are:
ORMは、外部から定義された認定リクエストです。1つの例は、属性認証リクエストです。この構造のフィールドは次のとおりです。
bodyPartID is the identifier number for this certification request. Details on body part identifiers are found in Section 3.2.2.
BodyPartidは、この認証要求の識別子番号です。ボディパーツ識別子の詳細は、セクション3.2.2にあります。
requestMessageType identifies the other request type. These values are defined outside of this document.
RequestMessageType他のリクエストタイプを識別します。これらの値は、このドキュメントの外部で定義されています。
requestMessageValue is the data associated with the other request type.
RequestMessageValueは、他の要求タイプに関連付けられたデータです。
A certification request based on PKCS #10 uses the following ASN.1 structure:
PKCS＃10に基づく認証要求は、次のASN.1構造を使用します。
TaggedCertificationRequest ::= SEQUENCE {
bodyPartID BodyPartID,
certificationRequest CertificationRequest
}
The fields in TaggedCertificationRequest have the following meaning:
TaggedCertificationRequestのフィールドには、次の意味があります。
bodyPartID is the identifier number for this certification request. Details on body part identifiers are found in Section 3.2.2.
BodyPartidは、この認証要求の識別子番号です。ボディパーツ識別子の詳細は、セクション3.2.2にあります。
certificationRequest contains the PKCS-#10-based certification request. Its fields are described in [PKCS10].
CertificationRequestには、PKCS-＃10ベースの認定リクエストが含まれています。そのフィールドは[PKCS10]で説明されています。
When producing a certification request based on PKCS #10, clients MUST produce the certification request with a subject name and public key. Some PKI products are operated using a central repository of information to assign subject names upon receipt of a certification request. To accommodate this mode of operation, the subject field in a CertificationRequest MAY be NULL, but MUST be present. CAs that receive a CertificationRequest with a NULL subject field MAY reject such certification requests. If rejected and a PKI Response is returned, the CA MUST return a PKI Response with the CMCFailInfo value with the value badRequest.
PKCS＃10に基づいて認定リクエストを作成する場合、クライアントは件名と公開キーを使用して認定リクエストを作成する必要があります。一部のPKI製品は、情報の中央リポジトリを使用して運用されており、認定リクエストの受領時にサブジェクト名を割り当てます。この動作モードに対応するには、認定リケストのサブジェクトフィールドはnullである場合がありますが、存在する必要があります。nullサブジェクトフィールドで認定リケストを受け取ったCASは、そのような認証リクエストを拒否する場合があります。拒否され、PKI応答が返された場合、CAは値BADREQUESTを使用してCMCFailInfo値を使用してPKI応答を返す必要があります。
A CRMF message uses the following ASN.1 structure (defined in [CRMF] and included here for convenience):
CRMFメッセージは、次のASN.1構造を使用します（[CRMF]で定義され、便利なためにここに含まれています）：
CertReqMsg ::= SEQUENCE {
certReq CertRequest,
popo ProofOfPossession OPTIONAL,
-- content depends upon key type
regInfo SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue OPTIONAL }
CertRequest ::= SEQUENCE {
certReqId INTEGER, -- ID for matching request and reply
certTemplate CertTemplate, --Selected fields of cert to be issued
controls Controls OPTIONAL } -- Attributes affecting issuance
CertTemplate ::= SEQUENCE {
version [0] Version OPTIONAL,
serialNumber [1] INTEGER OPTIONAL,
signingAlg [2] AlgorithmIdentifier OPTIONAL,
issuer [3] Name OPTIONAL,
validity [4] OptionalValidity OPTIONAL,
subject [5] Name OPTIONAL,
publicKey [6] SubjectPublicKeyInfo OPTIONAL,
issuerUID [7] UniqueIdentifier OPTIONAL,
subjectUID [8] UniqueIdentifier OPTIONAL,
extensions [9] Extensions OPTIONAL }
The fields in CertReqMsg are explained in [CRMF].
certreqmsgのフィールドは[CRMF]で説明されています。
This document imposes the following additional restrictions on the construction and processing of CRMF certification requests:
このドキュメントでは、CRMF認証リクエストの構築と処理に次の追加の制限を課しています。
When a Full PKI Request includes a CRMF certification request, both the subject and publicKey fields in the CertTemplate MUST be defined. The subject field can be encoded as NULL, but MUST be present.
完全なPKIリクエストにCRMF認定要求が含まれている場合、CERTTEMPLATE内のサブジェクトフィールドとPublicKeyフィールドの両方を定義する必要があります。サブジェクトフィールドはnullとしてエンコードできますが、存在する必要があります。
When both CRMF and CMC controls exist with equivalent functionality, the CMC control SHOULD be used. The CMC control MUST override the CRMF control.
CRMFコントロールとCMCコントロールの両方が同等の機能で存在する場合、CMCコントロールを使用する必要があります。CMC制御は、CRMFコントロールをオーバーライドする必要があります。
The regInfo field MUST NOT be used on a CRMF certification request. Equivalent functionality is provided in the CMC regInfo control (Section 6.12).
RegINFOフィールドは、CRMF認定リクエストで使用してはなりません。同等の機能は、CMC RegINFOコントロール（セクション6.12）で提供されます。
The indirect method of proving POP is not supported in this protocol. One of the other methods (including the direct method described in this document) MUST be used. The value of encrCert in SubsequentMessage MUST NOT be used.
POPを証明する間接的な方法は、このプロトコルではサポートされていません。他の方法の1つ（このドキュメントで説明されている直接的な方法を含む）を使用する必要があります。後続のメッサージにおけるencrcertの値を使用してはなりません。
Since the subject and publicKeyValues are always present, the POPOSigningKeyInput MUST NOT be used when computing the value for POPSigningKey.
件名とpublicKeyValuesは常に存在するため、PopSigingKeyの値を計算するときにPopoSigingKeyInputを使用する必要はありません。
A server is not required to use all of the values suggested by the client in the CRMF certification request. Servers MUST be able to process all extensions defined, but not prohibited in [PKIXCERT]. Servers are not required to be able to process other X.509v3 extensions transmitted using this protocol, nor are they required to be able to process private extensions. Servers are permitted to modify client-requested extensions. Servers MUST NOT alter an extension so as to invalidate the original intent of a client-requested extension. (For example, change key usage from keyAgreement to digitalSignature.) If a certification request is denied due to the inability to handle a requested extension, the server MUST respond with a Full PKI Response with a CMCFailInfo value with the value of unsupportedExt.
サーバーは、CRMF認定リクエストでクライアントが提案したすべての値を使用する必要はありません。サーバーは、[pkixcert]では禁止されていないすべての拡張機能を処理できる必要があります。サーバーは、このプロトコルを使用して送信される他のX.509V3拡張機能を処理できる必要はありません。また、プライベートエクステンションを処理できるようにする必要もありません。サーバーは、クライアント要求の拡張機能を変更することができます。サーバーは、クライアントが要求された拡張機能の元の意図を無効にするために拡張機能を変更してはなりません。（たとえば、KeyAgreementからDigitalSignatureにキーの使用法を変更します。）要求された拡張機能を処理できないため、認証要求が拒否された場合、サーバーは、サポートされていない値でCMCFailInfo値を持つ完全なPKI応答で応答する必要があります。
This document allows for other certification request formats to be defined and used as well. An example of an other certification request format is one for Attribute Certificates. These other certification request formats are defined by specifying an OID for identification and the structure to contain the data to be passed.
このドキュメントにより、他の認定要求形式を定義および使用することもできます。他の認定要求形式の例は、属性証明書のものです。これらの他の認証要求形式は、識別用のOIDを指定し、渡されるデータを含む構造を指定することにより定義されます。
The cmsSequence field of the PKIData and PKIResponse messages contains zero or more tagged content info objects. The syntax for this structure is:
PkidataおよびPkiresponseメッセージのCMS順序フィールドには、ゼロ以上のタグ付きコンテンツ情報オブジェクトが含まれています。この構造の構文は次のとおりです。
TaggedContentInfo ::= SEQUENCE {
bodyPartID BodyPartID,
contentInfo ContentInfo
}
The fields in TaggedContentInfo have the following meaning:
TaggedContentInfoのフィールドには、次の意味があります。
bodyPartID is a unique integer that identifies this content info object.
BodyPartidは、このコンテンツ情報オブジェクトを識別するユニークな整数です。
contentInfo is a ContentInfo object (defined in [CMS]).
contentinfoはcontentinfoオブジェクト（[cms]で定義）です。
The four content types used in cmsSequence are AuthenticatedData, Data, EnvelopedData, and SignedData. All of these content types are defined in [CMS].
CMSシーケンスで使用される4つのコンテンツタイプは、AuthenticatedData、Data、EnvelopedData、およびSignedDataです。これらのコンテンツタイプはすべて[CMS]で定義されています。
The AuthenticatedData content type provides a method of doing pre-shared-secret-based validation of data being sent between two parties. Unlike SignedData, it does not specify which party actually generated the information.
AuthenticatedDataコンテンツタイプは、2つの当事者間で送信されるデータの事前共有秘密ベースの検証を行う方法を提供します。SignedDataとは異なり、実際に情報を生成した当事者は指定されていません。
AuthenticatedData provides origination authentication in those circumstances where a shared-secret exists, but a PKI-based trust has not yet been established. No PKI-based trust may have been established because a trust anchor has not been installed on the client or no certificate exists for a signing key.
AuthenticatedDataは、共有部門が存在するが、PKIベースの信頼がまだ確立されていない状況では、発信認証を提供します。クライアントにトラストアンカーがインストールされていないか、署名キーの証明書が存在しないため、PKIベースの信頼が確立されていない可能性があります。
AuthenticatedData content type is used by this document for:
AuthenticatedDataコンテンツタイプは、このドキュメントで使用されます。
The id-cmc-authData control (Section 6.16), and
ID-CMC-AuthDataコントロール（セクション6.16）、および
The top-level wrapper in environments where an encryption-only key is being certified.
暗号化のみのキーが認定されている環境のトップレベルのラッパー。
This content type can include both PKIData and PKIResponse as the encapsulated content types. These embedded content types can contain additional controls that need to be processed.
このコンテンツタイプには、カプセル化されたコンテンツタイプとしてpkidataとpkiresponseの両方を含めることができます。これらの埋め込まれたコンテンツタイプには、処理する必要がある追加のコントロールを含めることができます。
The Data content type allows for general transport of unstructured data.
データコンテンツタイプにより、非構造化データの一般的な輸送が可能になります。
The Data content type is used by this document for:
データコンテンツタイプは、このドキュメントで使用されます。
Holding the encrypted random value y for POP proof in the encrypted POP control (see Section 6.7).
暗号化されたポップコントロールのポッププルーフの暗号化されたランダム値yを保持します（セクション6.7を参照）。
The EnvelopedData content type provides for shrouding of data.
EnvelopedDataコンテンツタイプは、データの覆いを提供します。
The EnvelopedData content type is the primary confidentiality method for sensitive information in this protocol. EnvelopedData can provide encryption of an entire PKI Request (see Section 5). EnvelopedData can also be used to wrap private key material for key archival. If the decryption on an EnvelopedData fails, a Full PKI Response is returned with a CMCFailInfo value of badMessageCheck and a bodyPartID of 0.
EnvelopedDataコンテンツタイプは、このプロトコルの機密情報の主要な機密性方法です。EnvelopedDataは、PKI要求全体の暗号化を提供できます（セクション5を参照）。EnvelopedDataは、キーアーカイブのために秘密のキー資料をラップするためにも使用できます。EnvelopedDataの復号化が失敗した場合、BadmessagecheckのCMCFailinfo値と0のBody -Partidで完全なPKI応答が返されます。
The SignedData content type provides for authentication and integrity.
SignedDataコンテンツタイプは、認証と整合性を提供します。
The SignedData content type is used by this document for:
SignedDataコンテンツタイプは、このドキュメントで使用されます。
The outer wrapper for a PKI Request.
PKIリクエストの外側ラッパー。
The outer wrapper for a PKI Response.
PKI応答の外側ラッパー。
As part of processing a PKI Request/Response, the signature(s) MUST be verified. If the signature does not verify and the PKI Request/ Response contains anything other than a CMC Status Info control, a Full PKI Response containing a CMC Status Info control MUST be returned using a CMCFailInfo with a value of badMessageCheck and a bodyPartID of 0.
PKIリクエスト/応答の処理の一環として、署名を検証する必要があります。署名が検証せず、PKIリクエスト/応答にCMCステータス情報コントロール以外のものが含まれている場合、CMCステータス情報コントロールを含む完全なPKI応答を、badmessagecheckの値と0のボディパルティッドを持つCMCFailinfoを使用して返品する必要があります。
For the PKI Response, SignedData allows the server to sign the returning data, if any exists, and to carry the certificates and CRLs corresponding to the PKI Request. If no data is being returned beyond the certificates and CRLs, the EncapsulatedInfo and SignerInfo fields are not populated.
PKI応答の場合、SignedDataを使用すると、サーバーが存在する場合は返されるデータに署名し、PKI要求に対応する証明書とCRLを携帯できます。証明書とCRLを超えてデータが返されていない場合、EncapsulatedInfoおよびSignerinfoフィールドには存在しません。
The otherMsgSequence field of the PKI Request/Response allows for arbitrary data objects to be carried as part of a PKI Request/ Response. This is intended to contain a data object that is not already wrapped in a cmsSequence field (Section 3.2.1.3). The data object is ignored unless a control references the data object by bodyPartID.
PKIリクエスト/応答のothermsg sequenceフィールドにより、任意のデータオブジェクトをPKIリクエスト/応答の一部として実行できます。これは、CMSシーケンスフィールドにまだラップされていないデータオブジェクトを含めることを目的としています（セクション3.2.1.3）。コントロールがBodyPartidによってデータオブジェクトを参照しない限り、データオブジェクトは無視されます。
OtherMsg ::= SEQUENCE {
bodyPartID BodyPartID,
otherMsgType OBJECT IDENTIFIER,
otherMsgValue ANY DEFINED BY otherMsgType }
The fields in OtherMsg have the following meaning:
othermsgのフィールドには次の意味があります。
bodyPartID is the unique id identifying this data object.
BodyPartidは、このデータオブジェクトを識別する一意のIDです。
otherMsgType is the OID that defines the type of message body.
othermsgtypeは、メッセージ本文のタイプを定義するOIDです。
otherMsgValue is the data.
othermsgvalueはデータです。
Each element of a PKIData or PKIResponse has an associated body part identifier. The body part identifier is a 4-octet integer using the ASN.1 of:
pkidataまたはpkiresponseの各要素には、関連する身体部分識別子があります。ボディパーツ識別子は、次のasn.1を使用して4オクテットの整数です。
bodyIdMax INTEGER ::= 4294967295
BodyPartID ::= INTEGER(0..bodyIdMax)
Body part identifiers are encoded in the certReqIds field for CertReqMsg objects (in a TaggedRequest) or in the bodyPartID field of the other objects. The body part identifier MUST be unique within a single PKIData or PKIResponse. Body part identifiers can be duplicated in different layers (for example, a PKIData embedded within another).
ボディパーツ識別子は、CertreQMSGオブジェクトのCertreQIDSフィールド（タグ付きRequest）または他のオブジェクトのボディパルティッドフィールドでエンコードされます。ボディ部分識別子は、単一のpkidataまたはpkiresponse内で一意でなければなりません。体の識別子は、異なる層（たとえば、別の層に埋め込まれたpkidata）で複製できます。
The bodyPartID value of 0 is reserved for use as the reference to the current PKIData object.
0のBody -Partid値は、現在のpkidataオブジェクトへの参照として使用するために予約されています。
Some controls, such as the Add Extensions control (Section 6.5.2), use the body part identifier in the pkiDataReference field to refer to a PKI Request in the current PKIData. Some controls, such as the Extended CMC Status Info control (Section 6.1.1), will also use body part identifiers to refer to elements in the previous PKI Request/ Response. This allows an error to be explicit about the control or PKI Request to which the error applies.
Add Extensionsコントロール（セクション6.5.2）などの一部のコントロールは、PKIDATAREFERENTフィールドのボディパーツ識別子を使用して、現在のPKIDATAのPKI要求を参照しています。拡張されたCMCステータス情報コントロール（セクション6.1.1）などの一部のコントロールは、ボディパーツ識別子を使用して、以前のPKI要求/応答の要素を参照します。これにより、エラーが適用されるコントロールまたはPKI要求についてエラーを明示することができます。
A BodyPartList contains a list of body parts in a PKI Request/ Response (i.e., the Batch Request control in Section 6.17). The ASN.1 type BodyPartList is defined as:
BodyPartListには、PKIリクエスト/応答（つまり、セクション6.17のバッチ要求コントロール）にボディ部分のリストが含まれています。ASN.1タイプのボディパートリストは次のように定義されています。
BodyPartList ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
A BodyPartPath contains a path of body part identifiers moving through nesting (i.e., the Modify Certification Request control in Section 6.5.1). The ASN.1 type BodyPartPath is defined as:
BodyPartPathには、ネストを通過する体のパート識別子の経路が含まれています（つまり、セクション6.5.1の修正認定要求コントロール）。ASN.1タイプのBodyPartPathは、次のように定義されます。
BodyPartPath ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
There is sometimes a need to include data in a PKI Request designed to be removed by an RA during processing. An example of this is the inclusion of an encrypted private key, where a Key Archive Agent removes the encrypted private key before sending it on to the CA. One side effect of this desire is that every RA that encapsulates this information needs to move the data so that it is not covered by that RA's signature. (A client PKI Request encapsulated by an RA cannot have a signed control removed by the Key Archive Agent without breaking the RA's signature.) The CMC Unsigned Data attribute addresses this problem.
処理中にRAによって削除されるように設計されたPKIリクエストにデータを含める必要がある場合があります。この例は、暗号化された秘密鍵を含めることです。ここでは、キーアーカイブエージェントが暗号化された秘密鍵を削除してからCAに送信します。この欲求の副作用の1つは、この情報をカプセル化するすべてのRAがデータを移動して、そのRAの署名でカバーされないようにする必要があることです。（RAによってカプセル化されたクライアントPKI要求は、RAの署名を破ることなく、キーアーカイブエージェントによって署名されたコントロールを削除することはできません。）CMC Unsigned Data属性は、この問題に対処します。
The CMC Unsigned Data attribute contains information that is not directly signed by a client. When an RA encounters this attribute in the unsigned or unauthenticated attribute field of a request it is aggregating, the CMC Unsigned Data attribute is removed from the request prior to placing the request in a cmsSequence and placed in the unsigned or unauthenticated attributes of the RA's signed or authenticated data wrapper.
CMC Unsigned Data属性には、クライアントが直接署名しない情報が含まれています。RAがリクエストの署名されていないまたは認証されていない属性フィールドでこの属性に遭遇すると、CMSはCMSシーケンスにリクエストを配置する前にリクエストから削除され、RAの署名されたRAの署名されていない属性または無慈悲な属性に配置されます。または認証されたデータラッパー。
The CMC Unsigned Data attribute is identified by:
CMC unsigned Data属性は、次のように識別されます。
id-aa-cmc-unsignedData OBJECT IDENTIFIER ::= {id-aa 34}
The CMC Unsigned Data attribute has the ASN.1 definition:
CMC unsigned Data属性にはASN.1定義があります。
CMCUnsignedData ::= SEQUENCE {
bodyPartPath BodyPartPath,
identifier OBJECT IDENTIFIER,
content ANY DEFINED BY identifier
}
The fields in CMCUnsignedData have the following meaning:
cmcunsigneddataのフィールドには、次の意味があります。
bodyPartPath is the path pointing to the control associated with this data. When an RA moves the control in an unsigned or unauthenticated attribute up one level as part of wrapping the data in a new SignedData or AuthenticatedData, the body part identifier of the embedded item in the PKIData is prepended to the bodyPartPath sequence.
BodyPartPathは、このデータに関連するコントロールを指すパスです。RAが新しいSignedDataまたはAuthentivedDataでデータをラッピングすることの一部として1つのレベルに制御を移動すると、Pkidataの埋め込まれたアイテムの身体部分識別子はBodyPartPathシーケンスに加えられます。
identifier is the OID that defines the associated data.
識別子は、関連するデータを定義するOIDです。
content is the data.
コンテンツはデータです。
There MUST be at most one CMC Unsigned Data attribute in the UnsignedAttribute sequence of a SignerInfo or in the UnauthenticatedAttribute sequence of an AuthenticatedData. UnsignedAttribute consists of a set of values; the attribute can have any number of values greater than zero in that set. If the CMC Unsigned Data attribute is in one SignerInfo or AuthenticatedData, it MUST appear with the same values(s) in all SignerInfo and AuthenticatedData items.
せいぜい1つのCMC Unsigned Data属性が、SignerInfoの符号なしの誘導シーケンスまたは認証されたDataの認証されていないAttributeシーケンスに存在する必要があります。sutsignedattributeは、値のセットで構成されています。属性は、そのセットでゼロを超える任意の数の値を持つことができます。CMC unsigned Data属性が1つのSignerinfoまたはAuthenticatedDataにある場合、すべてのSignerInfoおよびAuthenticatedDataアイテムで同じ値で表示する必要があります。
Two types of PKI Responses exist. This section gives the details on both types.
2種類のPKI応答が存在します。このセクションでは、両方のタイプの詳細を示します。
Clients MUST be able to process the Simple PKI Response. The Simple PKI Response consists of a SignedData with no EncapsulatedContentInfo and no SignerInfo. The certificates requested in the PKI Response are returned in the certificate field of the SignedData.
クライアントは、単純なPKI応答を処理できる必要があります。単純なPKI応答は、contulatedContentInfoとSignerinfoがないSignedDataで構成されています。PKI応答で要求された証明書は、SignedDataの証明書フィールドに返されます。
Clients MUST NOT assume the certificates are in any order. Servers SHOULD include all intermediate certificates needed to form complete certification paths to one or more trust anchors, not just the newly issued certificate(s). The server MAY additionally return CRLs in the CRL bag. Servers MAY include the self-signed certificates. Clients MUST NOT implicitly trust included self-signed certificate(s) merely due to its presence in the certificate bag. In the event clients receive a new self-signed certificate from the server, clients SHOULD provide a mechanism to enable the user to use the certificate as a trust anchor. (The Publish Trust Anchors control (Section 6.15) should be used in the event that the server intends the client to accept one or more certificates as trust anchors. This requires the use of the Full PKI Response message.)
クライアントは、証明書がいかなる順序であると仮定してはなりません。サーバーには、新しく発行された証明書だけでなく、1つ以上の信頼できるアンカーへの完全な認定パスを形成するために必要なすべての中間証明書を含める必要があります。サーバーはさらに、CRLバッグにCRLを返す場合があります。サーバーには、自己署名証明書が含まれる場合があります。クライアントは、単に証明書バッグに存在するため、自己署名証明書を含むことを暗黙的に信頼してはなりません。クライアントがサーバーから新しい自己署名証明書を受け取った場合、クライアントはユーザーが信頼のアンカーとして証明書を使用できるようにするメカニズムを提供する必要があります。（パブリッシュトラストアンカーコントロール（セクション6.15）は、サーバーがクライアントに1つ以上の証明書を信頼アンカーとして受け入れるように意図した場合に使用する必要があります。これには、完全なPKI応答メッセージの使用が必要です。）
Clients MUST be able to process a Full PKI Response.
クライアントは、完全なPKI応答を処理できる必要があります。
The Full PKI Response consists of a SignedData or AuthenticatedData encapsulating a PKIResponse content type. The certificates issued in a PKI Response are returned in the certificates field of the immediately encapsulating SignedData.
完全なPKI応答は、signedDataまたはpkiresponseコンテンツタイプをカプセル化する認証されたDataで構成されています。PKI応答で発行された証明書は、すぐにカプセル化されたSignedDataの証明書フィールドに返されます。
Clients MUST NOT assume the certificates are in any order. Servers SHOULD include all intermediate certificates needed to form complete chains to one or more trust anchors, not just the newly issued certificate(s). The server MAY additionally return CRLs in the CRL bag. Servers MAY include self-signed certificates. Clients MUST NOT implicitly trust included self-signed certificate(s) merely due to its presence in the certificate bag. In the event clients receive a new self-signed certificate from the server, clients MAY provide a mechanism to enable the user to explicitly use the certificate as a trust anchor. (The Publish Trust Anchors control (Section 6.15) exists for the purpose of allowing for distribution of trust anchor certificates. If a trusted anchor publishes a new trusted anchor, this is one case where automated trust of the new trust anchor could be allowed.)
クライアントは、証明書がいかなる順序であると仮定してはなりません。サーバーには、新しく発行された証明書だけでなく、1つ以上の信頼できるアンカーに完全なチェーンを形成するために必要なすべての中間証明書を含める必要があります。サーバーはさらに、CRLバッグにCRLを返す場合があります。サーバーには、自己署名証明書が含まれる場合があります。クライアントは、単に証明書バッグに存在するため、自己署名証明書を含むことを暗黙的に信頼してはなりません。クライアントがサーバーから新しい自己署名証明書を受け取った場合、クライアントは、ユーザーが証明書を信頼のアンカーとして明示的に使用できるようにするメカニズムを提供する場合があります。（Publish Trust Anchors Control（セクション6.15）は、信頼アンカー証明書の配布を許可する目的で存在します。信頼できるアンカーが新しい信頼できるアンカーを公開する場合、これは新しい信頼アンカーの自動信頼が許可される可能性がある1つのケースです。）
The PKIResponse content type is used for the Full PKI Response. The PKIResponse content type is identified by:
PKiresponseコンテンツタイプは、完全なPKI応答に使用されます。pkiresponseコンテンツタイプは、次のように識別されます。
id-cct-PKIResponse ::= {id-pkix id-cct(12) 3 }
The ASN.1 structure corresponding to the PKIResponse content type is:
pkiresponseコンテンツタイプに対応するASN.1構造は次のとおりです。
PKIResponse ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
ReponseBody ::= PKIResponse
Note: In [RFC2797], this ASN.1 type was named ResponseBody. It has been renamed to PKIResponse for clarity and the old name kept as a synonym.
注：[RFC2797]では、このASN.1タイプはResponseBodyと名付けられました。明確にするためにPkiresponseに改名され、古い名前は同義語として保持されています。
The fields in PKIResponse have the following meaning:
pkiresponseのフィールドには次の意味があります。
controlSequence is a sequence of controls. The controls defined in this document are found in Section 6. Controls can be defined by other parties. Details on the TaggedAttribute structure are found in Section 3.2.1.1.
制御シーケンスは、コントロールのシーケンスです。このドキュメントで定義されているコントロールは、セクション6にあります。コントロールは、他の関係者によって定義できます。TaggedAttribute構造の詳細は、セクション3.2.1.1にあります。
cmsSequence is a sequence of [CMS] message objects. See Section 3.2.1.3 for more details.
CMSシーケンスは[CMS]メッセージオブジェクトのシーケンスです。詳細については、セクション3.2.1.3を参照してください。
otherMsgSequence is a sequence of arbitrary data objects. Data objects placed here are referred to by one or more controls. This allows for controls to use large amounts of data without the data being embedded in the control. See Section 3.2.1.4 for more details.
othermsg sequenceは、任意のデータオブジェクトのシーケンスです。ここに配置されたデータオブジェクトは、1つ以上のコントロールによって言及されています。これにより、コントロールは、データがコントロールに埋め込まれることなく、大量のデータを使用できます。詳細については、セクション3.2.1.4を参照してください。
Processing of PKIResponse by a recipient is as follows:
受信者によるpkiresponseの処理は次のとおりです。
1. All controls should be examined and processed in an appropriate manner. The appropriate processing is to complete processing at this time, to ignore the control, or to place the control on a to-do list for later processing.
1. すべてのコントロールは、適切な方法で検査および処理する必要があります。適切な処理は、現時点で処理を完了し、コントロールを無視するか、後で処理するためにTo Doリストにコントロールを配置することです。
2. Additional processing of non-element items includes the saving of certificates and CRLs present in wrapping layers. This type of processing is based on the consumer of the element and should not be relied on by generators.
2. 非エレメントアイテムの追加処理には、ラッピングレイヤーに存在する証明書とCRLの保存が含まれます。このタイプの処理は、要素の消費者に基づいており、ジェネレーターに依存するべきではありません。
No processing is required for cmsSequence or otherMsgSequence members of the PKIResponse, if items are present and are not referenced by a control. In this case, the cmsSequence and otherMsgSequence members are to be ignored.
アイテムが存在し、コントロールによって参照されていない場合、pkiresponseのcms sequenceまたはothermsg sequenceメンバーには処理は必要ありません。この場合、CMSシーケンスおよびその他のsgementメンバーは無視されます。
There are occasions when a PKI Request or Response must be encrypted in order to prevent disclosure of information in the PKI Request/ Response from being accessible to unauthorized entities. This section describes the means to encrypt Full PKI Requests and Responses (Simple PKI Requests cannot be encrypted). Data portions of PKI Requests and Responses that are placed in the cmsSequence field can be encrypted separately.
PKIリクエスト/応答の情報の開示を許可されていないエンティティがアクセスできるようにするために、PKIリクエストまたは応答を暗号化する必要があります。このセクションでは、完全なPKIリクエストと応答を暗号化する手段について説明します（単純なPKIリクエストは暗号化できません）。CMSシーケンスフィールドに配置されたPKIリクエストと応答のデータ部分は、個別に暗号化できます。
Confidentiality is provided by wrapping the PKI Request/Response (a SignedData) in an EnvelopedData. The nested content type in the EnvelopedData is id-SignedData. Note that this is different from S/MIME where there is a MIME layer placed between the encrypted and signed data. It is recommended that if an EnvelopedData layer is applied to a PKI Request/Response, a second signature layer be placed outside of the EnvelopedData layer. The following figure shows how this nesting would be done:
機密性は、PKIリクエスト/応答（SignedData）を封筒に包むことにより提供されます。EnvelopedDataのネストされたコンテンツタイプはID-SignedDataです。これは、暗号化されたデータと署名されたデータの間にMIME層が配置されているS/MIMEとは異なることに注意してください。EnvelopedDataレイヤーがPKIリクエスト/応答に適用される場合、2番目の署名レイヤーを封筒レイヤーの外側に配置することをお勧めします。次の図は、このネストがどのように行われるかを示しています。
Normal Option 1 Option 2
------ -------- --------
SignedData EnvelopedData SignedData
PKIData SignedData EnvelopedData
PKIData SignedData
PKIData
Note: PKIResponse can be substituted for PKIData in the above figure.
注：上記の図には、Pkiresponseをpkidataに置き換えることができます。
Options 1 and 2 prevent leakage of sensitive data by encrypting the Full PKI Request/Response. An RA that receives a PKI Request that it cannot decrypt MAY reject the PKI Request unless it can process the PKI Request without knowledge of the contents (i.e., all it does is amalgamate multiple PKI Requests and forward them to a server).
オプション1と2は、完全なPKIリクエスト/応答を暗号化することにより、機密データの漏れを防ぎます。復号化できないというPKI要求を受信するRAは、コンテンツの知識なしにPKI要求を処理できない限り、PKI要求を拒否する可能性があります（つまり、複数のPKIリクエストをアマルガメートしてサーバーに転送することだけです）。
After the RA removes the envelope and completes processing, it may then apply a new EnvelopedData layer to protect PKI Requests for transmission to the next processing agent. Section 7 contains more information about RA processing.
RAがエンベロープを削除して処理を完了した後、新しいエンベロープドタ層を適用して、次の処理エージェントへの送信のPKI要求を保護することができます。セクション7には、RA処理に関する詳細情報が含まれています。
Full PKI Requests/Responses can be encrypted or transmitted in the clear. Servers MUST provide support for all three options.
完全なPKIリクエスト/応答は、明確に暗号化または送信できます。サーバーは、3つのオプションすべてをサポートする必要があります。
Alternatively, an authenticated, secure channel could exist between the parties that require confidentiality. Clients and servers MAY use such channels instead of the technique described above to provide secure, private communication of Simple and Full PKI Requests/ Responses.
あるいは、機密性を必要とする当事者間に認証された安全なチャネルが存在する可能性があります。クライアントとサーバーは、上記の手法の代わりにそのようなチャネルを使用して、シンプルで完全なPKIリクエスト/応答の安全でプライベートなコミュニケーションを提供する場合があります。
Controls are carried as part of both Full PKI Requests and Responses. Each control is encoded as a unique OID followed by the data for the control (see syntax in Section 3.2.1.1. The encoding of the data is based on the control. Processing systems would first detect the OID (TaggedAttribute attrType) and process the corresponding control value (TaggedAttribute attrValues) prior to processing the message body.
コントロールは、完全なPKIリクエストと応答の両方の一部として運ばれます。各コントロールは一意のOIDとしてエンコードされ、その後のコントロールのデータが続きます（セクション3.2.1.1の構文を参照してください。データのエンコードはコントロールに基づいています。処理システムは最初にOID（TaggedAttribute attrtype）を検出し、対応するものを処理しますメッセージ本文を処理する前に、コントロール値（TaggedAttribute Attralues）。
The OIDs are all defined under the following arc:
OIDはすべて、次のアークの下で定義されています。
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-cmc OBJECT IDENTIFIER ::= { id-pkix 7 }
The following table lists the names, OID, and syntactic structure for each of the controls described in this document.
次の表には、このドキュメントで説明されている各コントロールの名前、OID、および構文構造を示します。
Identifier Description OID ASN.1 Structure Section
--------------------------------------------------------------------
id-cmc-statusInfo id-cmc 1 CMCStatusInfo 6.1.2
id-cmc-identification id-cmc 2 UTF8String 6.2.3
id-cmc-identityProof id-cmc 3 OCTET STRING 6.2.2
id-cmc-dataReturn id-cmc 4 OCTET STRING 6.4
id-cmc-transactionId id-cmc 5 INTEGER 6.6
id-cmc-senderNonce id-cmc 6 OCTET STRING 6.6
id-cmc-recipientNonce id-cmc 7 OCTET STRING 6.6
id-cmc-addExtensions id-cmc 8 AddExtensions 6.5.2
id-cmc-encryptedPOP id-cmc 9 EncryptedPOP 6.7
id-cmc-decryptedPOP id-cmc 10 DecryptedPOP 6.7
id-cmc-lraPOPWitness id-cmc 11 LraPOPWitness 6.8
id-cmc-getCert id-cmc 15 GetCert 6.9
id-cmc-getCRL id-cmc 16 GetCRL 6.10
id-cmc-revokeRequest id-cmc 17 RevokeRequest 6.11
id-cmc-regInfo id-cmc 18 OCTET STRING 6.12
id-cmc-responseInfo id-cmc 19 OCTET STRING 6.12
id-cmc-queryPending id-cmc 21 OCTET STRING 6.13
id-cmc-popLinkRandom id-cmc 22 OCTET STRING 6.3.1
id-cmc-popLinkWitness id-cmc 23 OCTET STRING 6.3.1
id-cmc-popLinkWitnessV2 id-cmc 33 OCTET STRING 6.3.1.1
id-cmc-confirmCertAcceptance id-cmc 24 CMCCertId 6.14
id-cmc-statusInfoV2 id-cmc 25 CMCStatusInfoV2 6.1.1
id-cmc-trustedAnchors id-cmc 26 PublishTrustAnchors 6.15
id-cmc-authData id-cmc 27 AuthPublish 6.16
id-cmc-batchRequests id-cmc 28 BodyPartList 6.17
id-cmc-batchResponses id-cmc 29 BodyPartList 6.17
id-cmc-publishCert id-cmc 30 CMCPublicationInfo 6.18
id-cmc-modCertTemplate id-cmc 31 ModCertTemplate 6.5.1
id-cmc-controlProcessed id-cmc 32 ControlsProcessed 6.19
id-cmc-identityProofV2 id-cmc 34 IdentityProofV2 6.2.1
Table 1: CMC Control Attributes
表1：CMC制御属性
The CMC Status Info controls return information about the status of a client/server request/response. Two controls are described in this section. The Extended CMC Status Info control is the preferred control; the CMC Status Info control is included for backwards compatibility with RFC 2797.
CMCステータス情報は、クライアント/サーバーリクエスト/応答のステータスに関する返品情報を制御します。このセクションでは、2つのコントロールについて説明します。拡張されたCMCステータス情報コントロールが優先制御です。CMCステータス情報コントロールは、RFC 2797との逆方向の互換性のために含まれています。
Servers MAY emit multiple CMC status info controls referring to a single body part. Clients MUST be able to deal with multiple CMC status info controls in a PKI Response. Servers MUST use the Extended CMC Status Info control, but MAY additionally use the CMC Status Info control. Clients MUST be able to process the Extended
サーバーは、単一のボディパーツを参照する複数のCMCステータス情報コントロールを発する場合があります。クライアントは、PKI応答で複数のCMCステータス情報コントロールに対処できる必要があります。サーバーは、拡張されたCMCステータス情報コントロールを使用する必要がありますが、さらにCMCステータス情報コントロールを使用する場合があります。クライアントは拡張を処理できる必要があります
CMC Status Info control.
CMCステータス情報コントロール。
The Extended CMC Status Info control is identified by the OID:
拡張されたCMCステータス情報コントロールは、OIDによって識別されます。
id-cmc-statusInfoV2 ::= { id-cmc 25 }
The Extended CMC Status Info control has the ASN.1 definition:
拡張されたCMCステータス情報コントロールには、ASN.1定義があります。
CMCStatusInfoV2 ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF BodyPartReference,
statusString UTF8String OPTIONAL,
otherInfo OtherStatusInfo OPTIONAL
}
OtherStatusInfo ::= CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo,
extendedFailInfo ExtendedFailInfo
}
PendInfo ::= SEQUENCE {
pendToken OCTET STRING,
pendTime GeneralizedTime
}
ExtendedFailInfo ::= SEQUENCE {
failInfoOID OBJECT IDENTIFIER,
failInfoValue ANY DEFINED BY failInfoOID
}
BodyPartReference ::= CHOICE {
bodyPartID BodyPartID,
bodyPartPath BodyPartPath
}
The fields in CMCStatusInfoV2 have the following meaning:
CMCSTATUSINFOV2のフィールドには、次の意味があります。
cMCStatus contains the returned status value. Details are in Section 6.1.3.
CMCSTATUSには、返されたステータス値が含まれています。詳細はセクション6.1.3にあります。
bodyList identifies the controls or other elements to which the status value applies. If an error is returned for a Simple PKI Request, this field is the bodyPartID choice of BodyPartReference with the single integer of value 1.
ボディリストは、ステータス値が適用されるコントロールまたはその他の要素を識別します。単純なPKI要求に対してエラーが返された場合、このフィールドは、値1の単一整数を使用したボディパルタレファレンスのボディパルティッドの選択です。
statusString contains additional description information. This string is human readable.
Statusstringには追加の説明情報が含まれています。この文字列は人間が読みやすいです。
otherInfo contains additional information that expands on the CMC status code returned in the cMCStatus field.
その他のINFOには、CMCSTATUSフィールドで返されるCMCステータスコードを拡張する追加情報が含まれています。
The fields in OtherStatusInfo have the following meaning:
他の人のフィールドには、次の意味があります。
failInfo is described in Section 6.1.4. It provides an error code that details what failure occurred. This choice is present only if cMCStatus contains the value failed.
FailInfoはセクション6.1.4で説明されています。障害が発生したことを詳述するエラーコードが提供されます。この選択は、CMCSTATUSが故障した値を含む場合にのみ存在します。
pendInfo contains information about when and how the client should request the result of this request. It is present when the cMCStatus is either pending or partial. pendInfo uses the structure PendInfo, which has the fields:
Pendinfoには、クライアントがこのリクエストの結果をいつどのようにリクエストするかについての情報が含まれています。CMCStatusが保留中または部分的なものである場合に存在します。Pendinfoは、フィールドを備えた構造Pendinfoを使用しています。
pendToken is the token used in the Query Pending control (Section 6.13).
Pendtokenは、保留中のクエリで使用されるトークンです（セクション6.13）。
pendTime contains the suggested time the server wants to be queried about the status of the certification request.
PENDTIMEには、サーバーが認証リクエストのステータスについて照会したい推奨時間が含まれています。
extendedFailInfo includes application-dependent detailed error information. This choice is present only if cMCStatus contains the value failed. Caution should be used when defining new values as they may not be correctly recognized by all clients and servers. The CMCFailInfo value of internalCAError may be assumed if the extended error is not recognized. This field uses the type ExtendedFailInfo. ExtendedFailInfo has the fields:
ExtendedFailinfoには、アプリケーション依存の詳細なエラー情報が含まれています。この選択は、CMCSTATUSが故障した値を含む場合にのみ存在します。すべてのクライアントとサーバーによって正しく認識されない可能性があるため、新しい値を定義する場合は注意が必要です。拡張エラーが認識されていない場合、internalcaerrorのcmcfailinfo値が想定される場合があります。このフィールドでは、拡張型FailInfoを使用します。extendedfailinfoにはフィールドがあります。
failInfoOID contains an OID that is associated with a set of extended error values.
FailInfooidには、拡張エラー値のセットに関連付けられているOIDが含まれています。
failInfoValue contains an extended error code from the defined set of extended error codes.
FailInfoValueには、定義された拡張エラーコードセットからの拡張エラーコードが含まれています。
If the cMCStatus field is success, the Extended CMC Status Info control MAY be omitted unless it is the only item in the response.
CMCSTATUSフィールドが成功した場合、応答の唯一の項目でない限り、拡張CMCステータス情報コントロールが省略される場合があります。
The CMC Status Info control is identified by the OID:
CMCステータス情報コントロールは、OIDによって識別されます。
id-cmc-statusInfo ::= { id-cmc 1 }
The CMC Status Info control has the ASN.1 definition:
CMCステータス情報コントロールにはasn.1定義があります。
CMCStatusInfo ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList BodyPartList,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo } OPTIONAL
}
The fields in CMCStatusInfo have the following meaning:
CMCSTATUSINFOのフィールドには、次の意味があります。
cMCStatus contains the returned status value. Details are in Section 6.1.3.
CMCSTATUSには、返されたステータス値が含まれています。詳細はセクション6.1.3にあります。
bodyList contains the list of controls or other elements to which the status value applies. If an error is being returned for a Simple PKI Request, this field contains a single integer of value 1.
ボディリストには、ステータス値が適用されるコントロールまたはその他の要素のリストが含まれています。単純なPKI要求に対してエラーが返されている場合、このフィールドには値1の単一の整数が含まれています。
statusString contains additional description information. This string is human readable.
Statusstringには追加の説明情報が含まれています。この文字列は人間が読みやすいです。
otherInfo provides additional information that expands on the CMC status code returned in the cMCStatus field.
otherInfoは、CMCSTATUSフィールドで返されたCMCステータスコードを拡張する追加情報を提供します。
failInfo is described in Section 6.1.4. It provides an error code that details what failure occurred. This choice is present only if cMCStatus is failed.
FailInfoはセクション6.1.4で説明されています。障害が発生したことを詳述するエラーコードが提供されます。この選択は、CMCStatusが失敗した場合にのみ存在します。
pendInfo uses the PendInfo ASN.1 structure in Section 6.1.1. It contains information about when and how the client should request results of this request. The pendInfo field MUST be populated for a cMCStatus value of pending or partial. Further details can be found in Section 6.1.1 (Extended CMC Status Info Control) and Section 6.13 (Query Pending Control ).
Pendinfoは、セクション6.1.1のPendinfo asn.1構造を使用しています。クライアントがこのリクエストの結果をいつどのようにリクエストするかについての情報が含まれています。Pendinfoフィールドは、保留中または部分的なCMCstatus値のために入力する必要があります。詳細については、セクション6.1.1（拡張CMCステータス情報コントロール）とセクション6.13（クエリ保留中のコントロール）をご覧ください。
If the cMCStatus field is success, the CMC Status Info control MAY be omitted unless it is the only item in the response. If no status exists for a Simple or Full PKI Request, then the value of success is assumed.
CMCSTATUSフィールドが成功した場合、応答の唯一の項目でない限り、CMCステータス情報コントロールは省略される場合があります。単純または完全なPKI要求に対してステータスが存在しない場合、成功の価値が想定されます。
CMCStatus is a field in the Extended CMC Status Info and CMC Status Info controls. This field contains a code representing the success or failure of a specific operation. CMCStatus has the ASN.1 structure:
CMCStatusは、拡張されたCMCステータス情報とCMCステータス情報コントロールのフィールドです。このフィールドには、特定の操作の成功または失敗を表すコードが含まれています。cmcstatusにはasn.1構造があります。
CMCStatus ::= INTEGER {
success (0),
-- reserved (1),
failed (2),
pending (3),
noSupport (4),
confirmRequired (5),
popRequired (6),
partial (7)
}
The values of CMCStatus have the following meaning:
cmcstatusの値には次の意味があります。
success indicates the request was granted or the action was completed.
成功は、リクエストが許可されたか、措置が完了したことを示します。
failed indicates the request was not granted or the action was not completed. More information is included elsewhere in the response.
失敗は、リクエストが許可されていないか、訴訟が完了しなかったことを示します。より多くの情報は、応答の他の場所に含まれています。
pending indicates the PKI Request has yet to be processed. The requester is responsible to poll back on this Full PKI request. pending may only be returned for certification request operations.
保留中は、PKIリクエストがまだ処理されていないことを示しています。リクエスターは、この完全なPKIリクエストで投票する責任があります。保留中は、認証要求操作のためにのみ返品される場合があります。
noSupport indicates the requested operation is not supported.
NoSupportは、要求された操作がサポートされていないことを示します。
confirmRequired indicates a Confirm Certificate Acceptance control (Section 6.14) must be returned before the certificate can be used.
確認済みは、証明書を使用する前に、確認証明書の受け入れ制御（セクション6.14）を返送する必要があることを示しています。
popRequired indicates a direct POP operation is required (Section 6.3.1.3).
PopRequiredは、直接POP操作が必要であることを示しています（セクション6.3.1.3）。
partial indicates a partial PKI Response is returned. The requester is responsible to poll back for the unfulfilled portions of the Full PKI Request.
部分的な部分的なPKI応答が返されることを示します。要求者は、完全なPKIリクエストの満たされていない部分を投票する責任があります。
CMCFailInfo is a field in the Extended CMC Status Info and CMC Status Info controls. CMCFailInfo conveys more detailed information relevant to the interpretation of a failure condition. The CMCFailInfo has the following ASN.1 structure:
CMCFailinfoは、拡張されたCMCステータス情報とCMCステータス情報コントロールのフィールドです。CMCFailinfoは、障害条件の解釈に関連するより詳細な情報を伝えます。CMCFailinfoには次のASN.1構造があります。
CMCFailInfo ::= INTEGER {
badAlg (0),
badMessageCheck (1),
badRequest (2),
badTime (3),
badCertId (4),
unsupportedExt (5),
mustArchiveKeys (6),
badIdentity (7),
popRequired (8),
popFailed (9),
noKeyReuse (10),
internalCAError (11),
tryLater (12),
authDataFail (13)
}
The values of CMCFailInfo have the following meanings:
cmcfailinfoの値には次の意味があります。
badAlg indicates unrecognized or unsupported algorithm.
バダルグは、認識されていないまたはサポートされていないアルゴリズムを示します。
badMessageCheck indicates integrity check failed.
Badmessagecheckは、整合性チェックが失敗したことを示しています。
badRequest indicates transaction was not permitted or supported.
BadRequestは、トランザクションが許可またはサポートされていないことを示しています。
badTime indicates message time field was not sufficiently close to the system time.
悪い時間は、メッセージ時間フィールドがシステム時間に十分に近いことを示しています。
badCertId indicates no certificate could be identified matching the provided criteria.
Badcertidは、提供された基準に一致する証明書を特定できないことを示します。
unsupportedExt indicates a requested X.509 extension is not supported by the recipient CA.
Unsupportedextは、要求されたX.509拡張機能が受信者CAによってサポートされていないことを示します。
mustArchiveKeys indicates private key material must be supplied.
MustarchiveKeysは、秘密のキー資料を供給する必要があることを示しています。
badIdentity indicates identification control failed to verify.
不良は、識別制御が検証に失敗したことを示しています。
popRequired indicates server requires a POP proof before issuing certificate.
PopRequiredは、証明書を発行する前にサーバーがポッププルーフを必要とすることを示しています。
popFailed indicates POP processing failed.
Popfailedは、ポップ処理に失敗したことを示しています。
noKeyReuse indicates server policy does not allow key reuse.
NoKeyReuseは、サーバーポリシーがキーの再利用を許可しないことを示しています。
internalCAError indicates that the CA had an unknown internal failure.
内部caerrorは、CAに内部障害が不明であることを示しています。
tryLater indicates that the server is not accepting requests at this time and the client should try at a later time.
TryLaterは、この時点でサーバーがリクエストを受け入れておらず、クライアントが後で試す必要があることを示します。
authDataFail indicates failure occurred during processing of authenticated data.
AuthDataFailは、認証されたデータの処理中に障害が発生したことを示しています。
If additional failure reasons are needed, they SHOULD use the ExtendedFailureInfo item in the Extended CMC Status Info control. However, for closed environments they can be defined using this type. Such codes MUST be in the range from 1000 to 1999.
追加の障害の理由が必要な場合は、拡張CMCステータス情報コントロールで拡張FailureInfoアイテムを使用する必要があります。ただし、閉じた環境では、このタイプを使用して定義できます。このようなコードは、1000から1999年までの範囲でなければなりません。
Some CAs and RAs require that a proof-of-identity be included in a certification request. Many different ways of doing this exist with different degrees of security and reliability. Most are familiar with a bank's request to provide your mother's maiden name as a form of identity proof. The reasoning behind requiring a proof-of-identity can be found in Appendix C of [CRMF].
一部のCASとRASは、証明の証明を認証リクエストに含める必要があります。これを行う多くの異なる方法は、さまざまな程度のセキュリティと信頼性で存在します。ほとんどは、あなたの母親の旧姓を身元証明の形として提供するという銀行の要求に精通しています。アイデンティティの証明を必要とする背後にある理由は、[CRMF]の付録Cに記載されています。
CMC provides a method to prove the client's identity based on a client/server shared-secret. If clients support the Full PKI Request, clients MUST implement this method of identity proof (Section 6.2.2). Servers MUST provide this method, but MAY additionally support bilateral methods of similar strength.
CMCは、クライアント/サーバー共有秘密に基づいてクライアントのIDを証明する方法を提供します。クライアントが完全なPKIリクエストをサポートする場合、クライアントはこの身分証明書の方法を実装する必要があります（セクション6.2.2）。サーバーはこの方法を提供する必要がありますが、同様の強度の両側の方法をさらにサポートする場合があります。
This document also provides an Identification control (Section 6.2.3). This control is a simple method to allow a client to state who they are to the server. Generally, a shared-secret AND an identifier of that shared-secret are passed from the server to the client. The identifier is placed in the Identification control, and the shared-secret is used to compute the Identity Proof control.
このドキュメントは、識別制御も提供します（セクション6.2.3）。このコントロールは、クライアントがサーバーに誰であるかを述べることができる簡単な方法です。一般的に、共有分泌とその共有秘密の識別子がサーバーからクライアントに渡されます。識別子は識別コントロールに配置され、共有分泌範囲を使用してIDプルーフコントロールを計算します。
The Identity Proof Version 2 control is identified by the OID:
IDプルーフバージョン2コントロールは、OIDによって識別されます。
id-cmc-identityProofV2 ::= { id-cmc 34 }
The Identity Proof Version 2 control has the ASN.1 definition:
Identity Proofバージョン2コントロールには、asn.1定義があります。
IdentifyProofV2 ::= SEQUENCE {
hashAlgID AlgorithmIdentifier,
macAlgID AlgorithmIdentifier,
witness OCTET STRING
}
}
The fields of IdentityProofV2 have the following meaning:
IDPROOFV2のフィールドには次の意味があります。
hashAlgID is the identifier and parameters for the hash algorithm used to convert the shared-secret into a key for the MAC algorithm.
Hashalgidは、共有分泌をMACアルゴリズムのキーに変換するために使用されるハッシュアルゴリズムの識別子とパラメーターです。
macAlgID is the identifier and the parameters for the message authentication code algorithm used to compute the value of the witness field.
MacalGIDは、証人フィールドの値を計算するために使用されるメッセージ認証コードアルゴリズムの識別子とパラメーターです。
witness is the identity proof.
証人は身元証明です。
The required method starts with an out-of-band transfer of a token (the shared-secret). The shared-secret should be generated in a random manner. The distribution of this token is beyond the scope of this document. The client then uses this token for an identity proof as follows:
必要な方法は、トークン（共有分泌範囲）の帯域外転送から始まります。共有分泌は、ランダムな方法で生成する必要があります。このトークンの分布は、このドキュメントの範囲を超えています。次に、クライアントはこのトークンを次のようにアイデンティティの証明に使用します。
1. The PKIData reqSequence field (encoded exactly as it appears in the Full PKI Request including the sequence type and length) is the value to be validated.
1. Pkidata reqsequenceフィールド（シーケンスタイプと長さを含む完全なPKI要求に表示されるとまったく同じエンコード）は、検証される値です。
2. A hash of the shared-secret as a UTF8 string is computed using hashAlgID.
2. UTF8文字列としての共有分泌のハッシュは、Hashalgidを使用して計算されます。
3. A MAC is then computed using the value produced in Step 1 as the message and the value from Step 2 as the key.
3. 次に、マックは、ステップ1で生成された値をメッセージとして、ステップ2からの値をキーとして使用して計算されます。
4. The result from Step 3 is then encoded as the witness value in the Identity Proof Version 2 control.
4. 次に、ステップ3の結果は、IDプルーフバージョン2コントロールの証人値としてエンコードされます。
When the server verifies the Identity Proof Version 2 control, it computes the MAC value in the same way and compares it to the witness value contained in the PKI Request.
サーバーがIdentity Proofバージョン2コントロールを検証すると、同じ方法でMac値を計算し、PKIリクエストに含まれる証人値と比較します。
If a server fails the verification of an Identity Proof Version 2 control, the CMCFailInfo value MUST be present in the Full PKI Response and MUST have a value of badIdentity.
サーバーがIdentity Proofバージョン2コントロールの検証に失敗した場合、CMCFailInfo値は完全なPKI応答に存在する必要があり、不良の値が必要です。
Reuse of the shared-secret on certification request retries allows the client and server to maintain the same view of acceptable identity proof values. However, reuse of the shared-secret can potentially open the door for some types of attacks.
認証要求の共有秘密度の再利用により、クライアントとサーバーが許容可能なID証明値の同じビューを維持することができます。ただし、共有秘密の再利用は、いくつかの種類の攻撃のためにドアを開ける可能性があります。
Implementations MUST be able to support tokens at least 16 characters long. Guidance on the amount of entropy actually obtained from a given length token based on character sets can be found in Appendix A of [PASSWORD].
実装は、少なくとも16文字の長さのトークンをサポートできる必要があります。文字セットに基づいて特定の長さトークンから実際に得られたエントロピーの量に関するガイダンスは、[パスワード]の付録Aにあります。
The Identity Proof control is identified by the OID:
IDプルーフコントロールは、OIDによって識別されます。
id-cmc-identityProof ::= { id-cmc 3 }
The Identity Proof control has the ASN.1 definition:
IDプルーフコントロールにはASN.1定義があります。
IdentifyProof ::= OCTET STRING
This control is processed in the same way as the Identity Proof Version 2 control. In this case, the hash algorithm is fixed to SHA-1 and the MAC algorithm is fixed to HMAC-SHA1.
このコントロールは、Identity Proofバージョン2コントロールと同じ方法で処理されます。この場合、ハッシュアルゴリズムはSHA-1に固定され、MACアルゴリズムはHMAC-SHA1に固定されています。
Optionally, servers MAY require the inclusion of the unprotected Identification control with an Identification Proof control. The Identification control is intended to contain a text string that assists the server in locating the shared-secret needed to validate the contents of the Identity Proof control. If the Identification control is included in the Full PKI Request, the derivation of the key in Step 2 (from Section 6.2.1) is altered so that the hash of the concatenation of the shared-secret and the UTF8 identity value (without the type and length bytes) are hashed rather than just the shared-secret.
オプションで、サーバーは、保護されていない識別制御を識別証明制御に含める必要がある場合があります。識別コントロールは、IDプルーフコントロールの内容を検証するために必要な共有分泌範囲を見つけるのにサーバーを支援するテキスト文字列を含めることを目的としています。識別コントロールが完全なPKI要求に含まれている場合、ステップ2（セクション6.2.1から）のキーの導出が変更され、共有分泌範囲とUTF8 ID値の連結のハッシュが変更されます（タイプなしでおよび長さのバイト）は、単なる共有秘密ではなくハッシュされます。
The Identification control is identified by the OID:
識別コントロールはOIDによって識別されます。
id-cmc-identification ::= { id-cmc 2 }
The Identification control has the ASN.1 definition:
識別コントロールにはasn.1定義があります。
Identification ::= UTF8String
The shared-secret between the EE and the server is sometimes computed using a hardware device that generates a series of tokens. The EE can therefore prove its identity by transferring this token in plain text along with a name string. The above protocol can be used with a hardware shared-secret token generation device by the following modifications:
EEとサーバーの間の共有秘密は、一連のトークンを生成するハードウェアデバイスを使用して計算されることがあります。したがって、EEは、名前の文字列とともにこのトークンをプレーンテキストで転送することにより、そのアイデンティティを証明できます。上記のプロトコルは、次の変更により、ハードウェア共有秘密のトークン生成デバイスで使用できます。
1. The Identification control MUST be included and MUST contain the hardware-generated token.
1. 識別コントロールを含める必要があり、ハードウェア生成トークンを含める必要があります。
2. The shared-secret value used above is the same hardware-generated token.
2. 上記で使用されている共有秘密値は、同じハードウェア生成トークンです。
3. All certification requests MUST have a subject name, and the subject name MUST contain the fields required to identify the holder of the hardware token device.
3. すべての認定要求には件名が付いている必要があり、サブジェクト名にはハードウェアトークンデバイスの保有者を識別するために必要なフィールドを含める必要があります。
4. The entire certification request MUST be shrouded in some fashion to prevent eavesdropping. Although the token is time critical, an active eavesdropper cannot be permitted to extract the token and submit a different certification request with the same token value.
4. 盗聴を防ぐために、認定要求全体を何らかの形で覆う必要があります。トークンは時間が重要ですが、アクティブな盗聴者はトークンを抽出し、同じトークン値で異なる認証要求を送信することは許可できません。
In a Full PKI Request, identity information about the client is carried in the signature of the SignedData containing all of the certification requests. Proof-of-possession information for key pairs, however, is carried separately for each PKCS #10 or CRMF certification request. (For keys capable of generating a digital signature, the POP is provided by the signature on the PKCS #10 or CRMF request. For encryption-only keys, the controls described in Section 6.7 are used.) In order to prevent substitution-style attacks, the protocol must guarantee that the same entity generated both the POP and proof-of-identity information.
完全なPKIリクエストでは、クライアントに関する身元情報は、すべての認証要求を含むsignedDataの署名に掲載されます。ただし、キーペアの所有証明情報は、PKCS＃10またはCRMF認定リクエストごとに個別に実施されます。（デジタル署名を生成できるキーの場合、POPはPKCS＃10またはCRMFリクエストの署名によって提供されます。暗号化のみのキーの場合、セクション6.7で説明したコントロールが使用されます。）、プロトコルは、同じエンティティがPOPと証明の情報の両方を生成したことを保証する必要があります。
This section describes two mechanisms for linking identity and POP information: witness values cryptographically derived from the shared-secret (Section 6.3.1.3) and shared-secret/subject distinguished name (DN) matching (Section 6.3.2). Clients and servers MUST support the witness value technique. Clients and servers MAY support shared-secret/subject DN matching or other bilateral techniques of similar strength. The idea behind both mechanisms is to force the client to sign some data into each certification request that can be directly associated with the shared-secret; this will defeat attempts to include certification requests from different entities in a single Full PKI Request.
このセクションでは、アイデンティティとポップ情報をリンクするための2つのメカニズムについて説明します。証人値は、共有秘密（セクション6.3.1.3）と共有秘密/被験者の識別名（DN）のマッチング（セクション6.3.2）から暗号化されました。クライアントとサーバーは、証人価値のテクニックをサポートする必要があります。クライアントとサーバーは、共有秘密/被験者のDNマッチングまたは同様の強度のその他の二国間技術をサポートする場合があります。両方のメカニズムの背後にあるアイデアは、クライアントが共有分泌に直接関連付けることができる各認証要求にいくつかのデータに署名するように強制することです。これにより、単一の完全なPKIリクエストにさまざまなエンティティからの認証要求を含める試みを打ち負かします。
The first technique that links identity and POP information forces the client to include a piece of information cryptographically derived from the shared-secret as a signed extension within each certification request (PKCS #10 or CRMF).
アイデンティティとポップ情報をリンクする最初の手法は、クライアントに、各認証要求（PKCS＃10またはCRMF）内の署名された拡張機能として共有分泌範囲から暗号化された情報を含めるように強制します。
The POP Link Witness Version 2 control is identified by the OID:
Pop Link Witnessバージョン2コントロールは、OIDによって識別されます。
id-cmc-popLinkWitnessV2 ::= { id-cmc 33 }
The POP Link Witness Version 2 control has the ASN.1 definition:
ポップリンク証言バージョン2コントロールには、asn.1定義があります。
PopLinkWitnessV2 ::= SEQUENCE {
keyGenAlgorithm AlgorithmIdentifier,
macAlgorithm AlgorithmIdentifier,
witness OCTET STRING
}
The fields of PopLinkWitnessV2 have the following meanings:
poplinkwitnessv2のフィールドには、次の意味があります。
keyGenAlgorithm contains the algorithm used to generate the key for the MAC algorithm. This will generally be a hash algorithm, but could be a more complex algorithm.
keygenalgorithmには、Macアルゴリズムのキーを生成するために使用されるアルゴリズムが含まれています。これは通常、ハッシュアルゴリズムになりますが、より複雑なアルゴリズムになる可能性があります。
macAlgorithm contains the algorithm used to create the witness value.
Macalgorithmには、証人価値の作成に使用されるアルゴリズムが含まれています。
witness contains the computed witness value.
証人には計算された証人価値が含まれています。
This technique is useful if null subject DNs are used (because, for example, the server can generate the subject DN for the certificate based only on the shared-secret). Processing begins when the client receives the shared-secret out-of-band from the server. The client then computes the following values:
この手法は、NULLの被験者DNSが使用される場合に役立ちます（たとえば、サーバーは共有分泌範囲に基づいて証明書のサブジェクトDNを生成できるため）。処理は、クライアントがサーバーから共有セクレットの帯域外の外れを受信するときに始まります。クライアントは次の値を計算します。
1. The client generates a random byte-string, R, which SHOULD be at least 512 bits in length.
1. クライアントは、ランダムなバイトストリングrを生成します。これは、少なくとも512ビットの長さである必要があります。
2. The key is computed from the shared-secret using the algorithm in keyGenAlgorithm.
2. キーは、keygenalgorithmのアルゴリズムを使用して共有分泌物から計算されます。
3. A MAC is then computed over the random value produced in Step 1, using the key computed in Step 2.
3. マックは、ステップ2で計算されたキーを使用して、ステップ1で生成されたランダム値で計算されます。
4. The random value produced in Step 1 is encoded as the value of a POP Link Random control. This control MUST be included in the Full PKI Request.
4. ステップ1で生成されたランダム値は、ポップリンクランダムコントロールの値としてエンコードされます。このコントロールは、完全なPKIリクエストに含める必要があります。
5. The MAC value produced in Step 3 is placed in either the POP Link Witness control or the witness field of the POP Link Witness V2 control.
5. ステップ3で生成されたMAC値は、ポップリンクの証人コントロールまたはポップリンクの証人V2コントロールの証人フィールドのいずれかに配置されます。
* For CRMF, the POP Link Witness/POP Link Witness V2 control is included in the controls field of the CertRequest structure.
* CRMFの場合、POP Link Witness/Pop Link Witness V2コントロールは、Certrequest構造のコントロールフィールドに含まれています。
* For PKCS #10, the POP Link Witness/POP Link Witness V2 control is included in the attributes field of the CertificationRequestInfo structure.
* PKCS＃10の場合、Pop Link Witness/Pop Link Witness V2コントロールは、認定RequestInfo構造の属性フィールドに含まれています。
Upon receipt, servers MUST verify that each certification request contains a copy of the POP Link Witness/POP Link Witness V2 control and that its value was derived using the above method from the shared-secret and the random string included in the POP Link Random control.
受領時に、サーバーは、各認定リクエストにポップリンクの証人/ポップリンク証人V2コントロールのコピーが含まれていることを確認する必要があり、その値は共有セクレットの上記の方法とポップリンクランダムコントロールに含まれるランダム文字列を使用して導出されたことを確認する必要があります。。
The Identification control (see Section 6.2.3) or the subject DN of a certification request can be used to help identify which shared-secret was used.
識別コントロール（セクション6.2.3を参照）または認証要求の被験者DNを使用して、どの共有秘密を使用したかを特定することができます。
The POP Link Witness control is identified by the OID:
ポップリンクの証人コントロールは、OIDによって識別されます。
id-cmc-popLinkWitness ::= { id-cmc 23 }
The POP Link Witness control has the ASN.1 definition:
ポップリンクの証人コントロールにはasn.1定義があります。
PopLinkWitness ::= OCTET STRING
For this control, SHA-1 is used as the key generation algorithm. HMAC-SHA1 is used as the mac algorithm.
このコントロールでは、SHA-1はキー生成アルゴリズムとして使用されます。HMAC-SHA1はMACアルゴリズムとして使用されます。
The POP Link Random control is identified by the OID:
ポップリンクランダムコントロールは、OIDによって識別されます。
id-cmc-popLinkRandom ::= { id-cmc 22 }
The POP Link Random control has the ASN.1 definition:
ポップリンクランダムコントロールには、asn.1定義があります。
PopLinkRandom ::= OCTET STRING
The second technique to link identity and POP information is to link a particular subject distinguished name (subject DN) to the shared-secrets that are distributed out-of-band and to require that clients using the shared-secret to prove identity include that exact subject DN in every certification request. It is expected that many client-server connections that use shared-secret-based proof-of-identity will use this mechanism. (It is common not to omit the subject DN information from the certification request.)
アイデンティティとポップ情報をリンクする2番目の手法は、特定の主題の識別名（サブジェクトDN）を帯域外に分配されている共有分泌株式にリンクし、共有秘密を使用してアイデンティティを証明するクライアントがその正確なものを含めることを要求することです。すべての認証リクエストのサブジェクトDN。共有秘密ベースの証明のアイデンティティを使用する多くのクライアントサーバー接続がこのメカニズムを使用することが期待されています。（認定リクエストから対象のDN情報を省略しないことが一般的です。）
When the shared-secret is generated and transferred out-of-band to initiate the registration process (Section 6.2), a particular subject DN is also associated with the shared-secret and communicated to the client. (The subject DN generated MUST be unique per entity in accordance with the CA policy; a null subject DN cannot be used. A common practice could be to place the identification value as part of the subject DN.) When the client generates the Full PKI Request, it MUST use these two pieces of information as follows:
共有秘密が生成され、帯域外に転送されて登録プロセスを開始すると（セクション6.2）、特定の被験者DNも共有秘密に関連付けられ、クライアントに通信されます。（生成された対象DNは、CAポリシーに従ってエンティティごとに一意でなければなりません。ヌルの主題DNを使用できません。一般的な慣行は、被験者DNの一部として識別値を配置することです。）クライアントが完全なPKIを生成したときリクエスト、次のようにこれらの2つの情報を使用する必要があります。
1. The client MUST include the specific subject DN that it received along with the shared-secret as the subject name in every certification request (PKCS #10 and/or CRMF) in the Full PKI Request. The subject names in the certification requests MUST NOT be null.
1. クライアントは、完全なPKIリクエストに、すべての認証要求（PKCS＃10および/またはCRMF）のサブジェクト名として共有秘密とともに受け取った特定のサブジェクトDNを含める必要があります。認証要求のサブジェクト名はnullであってはなりません。
2. The client MUST include an Identity Proof control (Section 6.2.2) or Identity Proof Version 2 control (Section 6.2.1), derived from the shared-secret, in the Full PKI Request.
2. クライアントは、完全なPKIリクエストに、共有分泌範囲から派生した身元証明制御（セクション6.2.2）またはIDの証明バージョン2コントロール（セクション6.2.1）を含める必要があります。
The server receiving this message MUST (a) validate the Identity Proof control and then, (b) check that the subject DN included in each certification request matches that associated with the shared-secret. If either of these checks fails, the certification request MUST be rejected.
このメッセージを受信するサーバーは、（a）身元証明制御を検証し、次に、（b）各認証要求に含まれるサブジェクトDNが共有秘密に関連付けられているものと一致することを確認する必要があります。これらのチェックのいずれかが失敗した場合、認証要求を拒否する必要があります。
When doing a renewal or rekey certification request, linking identity and POP information is simple. The client copies the subject DN for a current signing certificate into the subject name field of each certification request that is made. The POP for each certification request will now cover that information. The outermost signature layer is created using the current signing certificate, which allows the original identity to be associated with the certification request. Since the name in the current signing certificate and the names in the certification requests match, the necessary linking has been achieved.
更新またはRekey認定リクエストを実行する場合、IDとPOP情報のリンクは簡単です。クライアントは、行われた各認証要求の件名名フィールドに現在の署名証明書についてサブジェクトDNをコピーします。各認定リクエストのPOPは、その情報をカバーします。最も外側の署名レイヤーは、現在の署名証明書を使用して作成されます。これにより、元のIDを認定リクエストに関連付けることができます。現在の署名証明書の名前と認定リクエストの名前は一致しているため、必要なリンクが達成されました。
The Data Return control allows clients to send arbitrary data (usually some type of internal state information) to the server and to have the data returned as part of the Full PKI Response. Data placed in a Data Return control is considered to be opaque to the server. The same control is used for both Full PKI Requests and Responses. If the Data Return control appears in a Full PKI Request, the server MUST return it as part of the PKI Response.
データリターンコントロールにより、クライアントはサーバーに任意のデータ（通常、何らかのタイプの内部状態情報）を送信し、完全なPKI応答の一部としてデータを返すことができます。データリターンコントロールに配置されたデータは、サーバーにとって不透明であると見なされます。完全なPKIリクエストと応答の両方に同じコントロールが使用されます。データ戻り制御が完全なPKI要求に表示される場合、サーバーはPKI応答の一部としてそれを返す必要があります。
In the event that the information in the Data Return control needs to be confidential, it is expected that the client would apply some type of encryption to the contained data, but the details of this are outside the scope of this specification.
データリターンコントロールの情報が機密である必要がある場合、クライアントは含まれるデータに何らかのタイプの暗号化を適用することが予想されますが、この詳細はこの仕様の範囲外です。
The Data Return control is identified by the OID:
データリターンコントロールはOIDによって識別されます。
id-cmc-dataReturn ::= { id-cmc 4 }
The Data Return control has the ASN.1 definition:
データリターンコントロールにはasn.1定義があります。
DataReturn ::= OCTET STRING
A client could use this control to place an identifier marking the exact source of the private key material. This might be the identifier of a hardware device containing the private key.
クライアントは、このコントロールを使用して、秘密キー資料の正確なソースをマークする識別子を配置できます。これは、秘密鍵を含むハードウェアデバイスの識別子かもしれません。
These controls exist for RAs to be able to modify the contents of a certification request. Modifications might be necessary for various reasons. These include addition of certificate extensions or modification of subject and/or subject alternative names.
これらのコントロールは、RASが認証リクエストの内容を変更できるようにするために存在します。さまざまな理由で変更が必要になる場合があります。これらには、証明書の拡張機能の追加または主題および/または対象の代替名の変更が含まれます。
Two controls exist for this purpose. The first control, Modify Certification Request (Section 6.5.1), allows the RA to replace or remove any field in the certificate. The second control, Add Extensions (Section 6.5.2), only allows for the addition of extensions.
この目的のために2つのコントロールが存在します。最初のコントロールである認証要求（セクション6.5.1）を変更すると、RAは証明書のフィールドを交換または削除できます。2番目のコントロールは、拡張機能（セクション6.5.2）を追加し、拡張機能のみを追加できます。
The Modify Certification Request control is used by RAs to change fields in a requested certificate.
Modify Certification Request Controlは、RASが要求された証明書でフィールドを変更するために使用されます。
The Modify Certification Request control is identified by the OID:
修正認定要求コントロールは、OIDによって識別されます。
id-cmc-modCertTemplate ::= { id-cmc 31 }
The Modify Certification Request has the ASN.1 definition:
修正認定要求には、asn.1定義があります。
ModCertTemplate ::= SEQUENCE {
pkiDataReference BodyPartPath,
certReferences BodyPartList,
replace BOOLEAN DEFAULT TRUE,
certTemplate CertTemplate
}
The fields in ModCertTemplate have the following meaning:
ModCertTemplateのフィールドには、次の意味があります。
pkiDataReference is the path to the PKI Request containing certification request(s) to be modified.
PKidatareferenceは、修正する認証要求を含むPKIリクエストへのパスです。
certReferences refers to one or more certification requests in the PKI Request referenced by pkiDataReference to be modified. Each BodyPartID of the certReferences sequence MUST be equal to either the bodyPartID of a TaggedCertificationRequest (PKCS #10) or the certReqId of the CertRequest within a CertReqMsg (CRMF). By definition, the certificate extensions included in the certTemplate field are applied to every certification request referenced in the certReferences sequence. If a request corresponding to bodyPartID cannot be found, the CMCFailInfo with a value of badRequest is returned that references this control.
Certreferencesとは、PKIDatareferenceが参照するPKIリクエストの1つ以上の認証要求を指します。Certreferencesシーケンスの各ボディパルティドは、タグ付きCertificationRequest（PKCS＃10）のボディパルティッドまたはCertreQMSG（CRMF）内のcertreqidのcertreqidのいずれかに等しくなければなりません。定義上、CertTemplateフィールドに含まれる証明書拡張機能は、Certreferencesシーケンスで参照されているすべての認定要求に適用されます。BodyPartidに対応するリクエストが見つからない場合、このコントロールを参照するBadRequestの値を持つCMCFailinfoが返されます。
replace specifies if the target certification request is to be modified by replacing or deleting fields. If the value is TRUE, the data in this control replaces the data in the target certification request. If the value is FALSE, the data in the target certification request is deleted. The action is slightly different for the extensions field of certTemplate; each extension is treated individually rather than as a single unit.
ターゲット認証要求がフィールドを交換または削除することにより変更されるかどうかを指定します。値が真の場合、このコントロールのデータはターゲット認証要求のデータを置き換えます。値が偽の場合、ターゲット認証要求のデータが削除されます。アクションは、certTemplateの拡張フィールドではわずかに異なります。各拡張機能は、単一のユニットとしてではなく、個別に扱われます。
certTemplate is a certificate template object [CRMF]. If a field is present and replace is TRUE, it replaces that field in the certification request. If the field is present and replace is FALSE, the field in the certification request is removed. If the field is absent, no action is performed. Each extension is treated as a single field.
CertTemplateは、証明書テンプレートオブジェクト[CRMF]です。フィールドが存在し、交換が真である場合、認証リクエストでそのフィールドを置き換えます。フィールドが存在し、交換が誤っている場合、認定リクエストのフィールドが削除されます。フィールドがない場合、アクションは実行されません。各拡張機能は単一のフィールドとして扱われます。
Servers MUST be able to process all extensions defined, but not prohibited, in [PKIXCERT]. Servers are not required to be able to process every X.509v3 extension transmitted using this protocol, nor are they required to be able to process other, private extensions. Servers are not required to put all RA-requested extensions into a certificate. Servers are permitted to modify RA-requested extensions. Servers MUST NOT alter an extension so as to reverse the meaning of a client-requested extension. If a certification request is denied due to the inability to handle a requested extension and a Full PKI Response is returned, the server MUST return a CMCFailInfo value with the value of unsupportedExt.
サーバーは、[pkixcert]で定義されているが禁止されていないすべての拡張機能を処理できる必要があります。サーバーは、このプロトコルを使用して送信されるすべてのX.509V3拡張を処理できるようにする必要はありません。また、他のプライベートエクステンションを処理できるようにする必要もありません。サーバーは、すべてのra-requested拡張機能を証明書に入れる必要はありません。サーバーは、RA-Requested Extensionsを変更することができます。サーバーは、クライアントが要求された拡張機能の意味を逆転させるように、拡張機能を変更してはなりません。要求された拡張機能と完全なPKI応答を処理できないために認証要求が拒否された場合、サーバーはUnsupportedextの値でCMCFailinfo値を返す必要があります。
If a certification request is the target of multiple Modify Certification Request controls, the behavior is:
認定要求が複数の修正認定要求コントロールのターゲットである場合、動作は次のとおりです。
o If control A exists in a layer that contains the layer of control B, control A MUST override control B. In other words, controls should be applied from the innermost layer to the outermost layer.
o 制御aがコントロールBの層を含む層に存在する場合、制御aがコントロールBをオーバーライドする必要があります。つまり、コントロールは最も内側の層から最も外側の層に適用する必要があります。
o If control A and control B are in the same PKIData (i.e., the same wrapping layer), the order of application is non-determinate.
o コントロールAとコントロールBが同じPkidata（つまり、同じラッピング層）にある場合、適用の順序は非決定的です。
The same order of application is used if a certification request is the target of both a Modify Certification Request control and an Add Extensions control.
認証要求が修正認定要求コントロールと追加拡張機能制御の両方のターゲットである場合、同じアプリケーションが使用されます。
The Add Extensions control has been deprecated in favor of the Modify Certification Request control. It was replaced so that fields in the certification request other than extensions could be modified.
Add Extensionsコントロールは、Modify Certification Request Controlを支持して非推奨されています。拡張機能以外の認証要求のフィールドを変更できるように交換されました。
The Add Extensions control is used by RAs to specify additional extensions that are to be included in certificates.
ADD拡張機能は、RASが証明書に含める追加の拡張機能を指定するために使用されます。
The Add Extensions control is identified by the OID:
ADD拡張コントロールはOIDによって識別されます。
id-cmc-addExtensions ::= { id-cmc 8 }
The Add Extensions control has the ASN.1 definition:
ADD拡張機能のコントロールには、asn.1定義があります。
AddExtensions ::= SEQUENCE {
pkiDataReference BodyPartID,
certReferences SEQUENCE OF BodyPartID,
extensions SEQUENCE OF Extension
}
The fields in AddExtensions have the following meaning:
addextensionsのフィールドには、次の意味があります。
pkiDataReference contains the body part identity of the embedded certification request.
pkidatareferenceには、組み込み認証要求のボディパーツアイデンティティが含まれています。
certReferences is a list of references to one or more of the certification requests contained within a PKIData. Each body part identifier of the certReferences sequence MUST be equal to either the bodyPartID of a TaggedCertificationRequest (PKCS #10) or the certReqId of the CertRequest within a CertReqMsg (CRMF). By definition, the listed extensions are to be applied to every certification request referenced in the certReferences sequence. If a certification request corresponding to bodyPartID cannot be found, the CMCFailInfo with a value of badRequest is returned referencing this control.
Certreferencesは、Pkidata内に含まれる認定要求の1つ以上への参照のリストです。Certreferencesシーケンスの各身体部分識別子は、TaggedCertificationRequest（PKCS＃10）のボディパルティドまたはCertreqMSG内のCertreqidのCertreqid（CRMF）のいずれかに等しくなければなりません。定義上、リストされている拡張機能は、Certreferencesシーケンスで参照されるすべての認証要求に適用されます。BodyPartidに対応する認定要求が見つからない場合、BadRequestの値を持つCMCFailinfoがこのコントロールを参照する返されます。
extensions is a sequence of extensions to be applied to the referenced certification requests.
拡張機能は、参照された認証要求に適用される一連の拡張機能です。
Servers MUST be able to process all extensions defined, but not prohibited, in [PKIXCERT]. Servers are not required to be able to process every X.509v3 extension transmitted using this protocol, nor are they required to be able to process other, private extensions. Servers are not required to put all RA-requested extensions into a certificate. Servers are permitted to modify RA-requested extensions. Servers MUST NOT alter an extension so as to reverse the meaning of a client-requested extension. If a certification request is denied due to the inability to handle a requested extension and a response is returned, the server MUST return a CMCFailInfo with the value of unsupportedExt.
サーバーは、[pkixcert]で定義されているが禁止されていないすべての拡張機能を処理できる必要があります。サーバーは、このプロトコルを使用して送信されるすべてのX.509V3拡張を処理できるようにする必要はありません。また、他のプライベートエクステンションを処理できるようにする必要もありません。サーバーは、すべてのra-requested拡張機能を証明書に入れる必要はありません。サーバーは、RA-Requested Extensionsを変更することができます。サーバーは、クライアントが要求された拡張機能の意味を逆転させるように、拡張機能を変更してはなりません。要求された拡張機能を処理できないために認証要求が拒否され、応答が返された場合、サーバーはunsupportedextの値でCMCFailinfoを返す必要があります。
If multiple Add Extensions controls exist in a Full PKI Request, the exact behavior is left up to the CA policy. However, it is recommended that the following policy be used. These rules would be applied to individual extensions within an Add Extensions control (as opposed to an "all or nothing" approach).
完全なPKIリクエストに複数の追加拡張機能コントロールが存在する場合、正確な動作はCAポリシーに任されます。ただし、次のポリシーを使用することをお勧めします。これらのルールは、ADD拡張コントロール内の個々の拡張機能に適用されます（「すべてまたは何も」アプローチとは対照的に）。
1. If the conflict is within a single PKIData, the certification request would be rejected with a CMCFailInfo value of badRequest.
1. 競合が単一のPKIDATA内にある場合、認証要求はBADREQUESTのCMCFailInfo値で拒否されます。
2. If the conflict is between different PKIData, the outermost version of the extension would be used (allowing an RA to override the requested extension).
2. 競合が異なるPkidataの間にある場合、拡張の最も外側のバージョンが使用されます（RAが要求された拡張機能をオーバーライドできるようにします）。
Transactions are identified and tracked with a transaction identifier. If used, clients generate transaction identifiers and retain their value until the server responds with a Full PKI Response that completes the transaction. Servers correspondingly include received transaction identifiers in the Full PKI Response.
トランザクションが識別され、トランザクション識別子で追跡されます。使用すると、クライアントはトランザクション識別子を生成し、サーバーがトランザクションを完了する完全なPKI応答で応答するまで値を保持します。サーバーには、それに応じて、完全なPKI応答の受信トランザクション識別子が含まれます。
The Transaction Identifier control is identified by the OID:
トランザクション識別子制御は、OIDによって識別されます。
id-cmc-transactionId ::= { id-cmc 5 }
The Transaction Identifier control has the ASN.1 definition:
トランザクション識別子制御にはasn.1定義があります。
TransactionId ::= INTEGER
The Transaction Identifier control identifies a given transaction. It is used by client and server to manage the state of an operation. Clients MAY include a Transaction Identifier control in a request. If the original request contains a Transaction Identifier control, all subsequent requests and responses MUST include the same Transaction Identifier control.
トランザクション識別子制御は、特定のトランザクションを識別します。操作の状態を管理するために、クライアントとサーバーによって使用されます。クライアントは、リクエストにトランザクション識別子制御を含めることができます。元の要求にトランザクション識別子制御が含まれている場合、後続のリクエストと応答にはすべて同じトランザクション識別子制御を含める必要があります。
Replay protection is supported through the use of the Sender and Recipient Nonce controls. If nonces are used, in the first message of a transaction, a Recipient Nonce control is not transmitted; a Sender Nonce control is included by the transaction originator and retained for later reference. The recipient of a Sender Nonce control reflects this value back to the originator as a Recipient Nonce control and includes its own Sender Nonce control. Upon receipt by the transaction originator of this response, the transaction originator compares the value of Recipient Nonce control to its retained value. If the values match, the message can be accepted for further security processing. The received value for a Sender Nonce control is also retained for inclusion in the next message associated with the same transaction.
リプレイ保護は、送信者と受信者のノンセコントロールを使用することによりサポートされます。Noncesが使用されている場合、トランザクションの最初のメッセージで、受信者の非CEコントロールは送信されません。送信者のノンセコントロールは、トランザクションオリジネーターに含まれ、後で参照するために保持されます。送信者のノンセコントロールの受信者は、この値を受信者のノンセコントロールとして元のオリジネーターに反映し、独自の送信者NonCeコントロールを含みます。この応答のトランザクションオリジネーターが受領すると、トランザクションオリジネーターは、受信者のNonCEコントロールの値を保持値と比較します。値が一致する場合、さらなるセキュリティ処理のためにメッセージを受け入れることができます。Sender NonCeコントロールの受信価値も、同じトランザクションに関連付けられた次のメッセージに含めるために保持されます。
The Sender Nonce and Recipient Nonce controls are identified by the OIDs:
Sender NonceおよびRecipient NonCeコントロールは、OIDによって識別されます。
id-cmc-senderNonce ::= { id-cmc 6 }
id-cmc-recipientNonce ::= { id-cmc 7 }
The Sender Nonce control has the ASN.1 definition:
Sender Nonce ControlにはASN.1定義があります。
SenderNonce ::= OCTET STRING
The Recipient Nonce control has the ASN.1 definition:
受信者のノンセコントロールにはASN.1定義があります。
RecipientNonce ::= OCTET STRING
Clients MAY include a Sender Nonce control in the initial PKI Request. If a message includes a Sender Nonce control, the response MUST include the transmitted value of the previously received Sender Nonce control as a Recipient Nonce control and include a new value as its Sender Nonce control.
クライアントには、最初のPKIリクエストに送信者Nonceコントロールが含まれる場合があります。メッセージに送信者NonCEコントロールが含まれている場合、応答は、以前に受信した送信者NonCe Controlの送信値を受信者NonCeコントロールとして含める必要があり、送信者NonCeコントロールとして新しい値を含める必要があります。
Servers MAY require that this POP method be used only if another POP method is unavailable. Servers SHOULD reject all certification requests contained within a PKIData if any required POP is missing for any element within the PKIData.
サーバーは、別のPOPメソッドが利用できない場合にのみ、このPOPメソッドを使用する必要があります。サーバーは、pkidata内の要素に対して必要なPOPが欠落している場合、pkidata内に含まれるすべての認証要求を拒否する必要があります。
Many servers require proof that the entity that generated the certification request actually possesses the corresponding private component of the key pair. For keys that can be used as signature keys, signing the certification request with the private key serves as a POP on that key pair. With keys that can only be used for encryption operations, POP MUST be performed by forcing the client to decrypt a value. See Section 5 of [CRMF] for a detailed discussion of POP.
多くのサーバーは、認証要求を生成したエンティティが実際にキーペアの対応するプライベートコンポーネントを持っていることを証明する必要があります。署名キーとして使用できるキーの場合、秘密キーで認定リクエストに署名すると、そのキーペアのポップとして機能します。暗号化操作にのみ使用できるキーでは、クライアントに値を復号化するように強制することにより、POPを実行する必要があります。POPの詳細については、[CRMF]のセクション5を参照してください。
By necessity, POP for encryption-only keys cannot be done in one round-trip, since there are four distinct steps:
必然的に、4つの異なる手順があるため、暗号化のみのキーのPOPを1回の往復で実行することはできません。
1. Client tells the server about the public component of a new encryption key pair.
1. クライアントは、新しい暗号化キーペアのパブリックコンポーネントについてサーバーに伝えます。
2. Server sends the client a POP challenge, encrypted with the presented public encryption key.
2. サーバーは、提示されたパブリック暗号化キーで暗号化されたポップチャレンジをクライアントに送信します。
3. Client decrypts the POP challenge using the private key that corresponds to the presented public key and sends the plaintext back to the server.
3. クライアントは、提示された公開キーに対応する秘密鍵を使用して、POPチャレンジを復号化し、プレーンテキストをサーバーに送り返します。
4. Server validates the decrypted POP challenge and continues processing the certification request.
4. サーバーは、復号化されたPOPチャレンジを検証し、認証要求の処理を継続します。
CMC defines two different controls. The first deals with the encrypted challenge sent from the server to the user in Step 2. The second deals with the decrypted challenge sent from the client to the server in Step 3.
CMCは2つの異なるコントロールを定義します。1つ目は、ステップ2でサーバーからユーザーに送信された暗号化された課題を扱います。2番目の課題は、ステップ3でクライアントからサーバーに送信された復号化された課題を扱います。
The Encrypted POP control is used to send the encrypted challenge from the server to the client as part of the PKIResponse. (Note that it is assumed that the message sent in Step 1 above is a Full PKI Request and that the response in Step 2 is a Full PKI Response including a CMCFailInfo specifying that a POP is explicitly required, and providing the POP challenge in the encryptedPOP control.)
暗号化されたポップコントロールは、PKiresponseの一部として暗号化されたチャレンジをサーバーからクライアントに送信するために使用されます。（上記のステップ1で送信されたメッセージは完全なPKIリクエストであり、ステップ2の応答は、POPが明示的に必要であることを指定し、EncryptedPopでPOPチャレンジを提供するCMCFailInfoを含む完全なPKI応答であると想定されていることに注意してください。コントロール。）
The Encrypted POP control is identified by the OID:
暗号化されたポップコントロールは、OIDによって識別されます。
id-cmc-encryptedPOP ::= { id-cmc 9 }
The Encrypted POP control has the ASN.1 definition:
暗号化されたポップコントロールには、asn.1定義があります。
EncryptedPOP ::= SEQUENCE {
request TaggedRequest,
cms ContentInfo,
thePOPAlgID AlgorithmIdentifier,
witnessAlgID AlgorithmIdentifier,
witness OCTET STRING
}
The Decrypted POP control is identified by the OID:
復号化されたポップコントロールは、OIDによって識別されます。
id-cmc-decryptedPOP ::= { id-cmc 10 }
The Decrypted POP control has the ASN.1 definition:
復号化されたポップコントロールには、asn.1定義があります。
DecryptedPOP ::= SEQUENCE {
bodyPartID BodyPartID,
thePOPAlgID AlgorithmIdentifier,
thePOP OCTET STRING
}
The encrypted POP algorithm works as follows:
暗号化されたポップアルゴリズムは次のように機能します。
1. The server randomly generates the POP Proof Value and associates it with the request.
1. サーバーはポッププルーフ値をランダムに生成し、リクエストに関連付けます。
2. The server returns the Encrypted POP control with the following fields set:
2. サーバーは、次のフィールドセットで暗号化されたポップコントロールを返します。
request is the original certification request (it is included here so the client need not keep a copy of the request).
リクエストは元の認定リクエストです（クライアントがリクエストのコピーを保持する必要がないため、ここに含まれています）。
cms is an EnvelopedData, the encapsulated content type being id-data and the content being the POP Proof Value; this value needs to be long enough that one cannot reverse the value from the witness hash. If the certification request contains a Subject Key Identifier (SKI) extension, then the recipient identifier SHOULD be the SKI. If the issuerAndSerialNumber form is used, the IssuerName MUST be encoded as NULL and the SerialNumber as the bodyPartID of the certification request.
CMSは封筒であり、カプセル化されたコンテンツタイプはid-dataであり、コンテンツはポッププルーフ値です。この値は、証人のハッシュから値を逆転させることができないほど十分に長くする必要があります。認証要求にサブジェクトキー識別子（SKI）拡張機能が含まれている場合、受信者識別子はスキーである必要があります。発行済みのフォームが使用されている場合、発行者名は、認定要求のボディパルティッドとしてnullおよびserialnumberとしてエンコードする必要があります。
thePOPAlgID identifies the algorithm to be used in computing the return POP value.
Popalgidは、リターンポップ値の計算に使用されるアルゴリズムを特定します。
witnessAlgID identifies the hash algorithm used on the POP Proof Value to create the field witness.
WithingalGidは、ポッププルーフ値で使用されるハッシュアルゴリズムを特定して、フィールド証人を作成します。
witness is the hashed value of the POP Proof Value.
証人は、ポッププルーフ値のハッシュ値です。
3. The client decrypts the cms field to obtain the POP Proof Value. The client computes H(POP Proof Value) using the witnessAlgID and compares to the value of witness. If the values do not compare or the decryption is not successful, the client MUST abort the enrollment process. The client aborts the process by sending a request containing a CMC Status Info control with CMCFailInfo value of popFailed.
3. クライアントは、CMSフィールドを復号化してポッププルーフ値を取得します。クライアントは、証人を使用してH（ポッププルーフ値）を計算し、証人の価値と比較します。値が比較されない場合、または復号化が成功しない場合、クライアントは登録プロセスを中止する必要があります。クライアントは、PopFailedのCMCFailInfo値を使用してCMCステータス情報コントロールを含むリクエストを送信することにより、プロセスを中止します。
4. The client creates the Decrypted POP control as part of a new PKIData. The fields in the DecryptedPOP are:
4. クライアントは、新しいpkidataの一部として復号化されたポップコントロールを作成します。DecryptedPopのフィールドは次のとおりです。
bodyPartID refers to the certification request in the new PKI Request.
BodyPartidは、新しいPKIリクエストの認証要求を指します。
thePOPAlgID is copied from the encryptedPOP.
Popalgidは、暗号化されたPopからコピーされます。
thePOP contains the possession proof. This value is computed by thePOPAlgID using the POP Proof Value and the request.
ThePopには所有証明が含まれています。この値は、ポッププルーフ値とリクエストを使用して、Popalgidによって計算されます。
5. The server then re-computes the value of thePOP from its cached value and the request and compares to the value of thePOP. If the values do not match, the server MUST NOT issue the certificate. The server MAY re-issue a new challenge or MAY fail the request altogether.
5. サーバーは、キャッシュされた値とリクエストからThePopの値を再計算し、ThePopの値と比較します。値が一致しない場合、サーバーは証明書を発行してはなりません。サーバーは、新しい課題を再発行するか、要求に完全に失敗する場合があります。
When defining the algorithms for thePOPAlgID and witnessAlgID, care must be taken to ensure that the result of witnessAlgID is not a useful value to shortcut the computation with thePOPAlgID. The POP Proof Value is used as the secret value in the HMAC algorithm and the request is used as the data. If the POP Proof Value is greater than 64 bytes, only the first 64 bytes of the POP Proof Value is used as the secret.
Popalgid and WitnessalGidのアルゴリズムを定義する場合、WitnessalGidの結果がポパルジドとの計算のショートカットに有用な価値ではないことを確認するために注意する必要があります。ポッププルーフ値はHMACアルゴリズムの秘密値として使用され、リクエストはデータとして使用されます。ポッププルーフ値が64バイトを超える場合、ポッププルーフ値の最初の64バイトのみがシークレットとして使用されます。
One potential problem with the algorithm above is the amount of state that a CA needs to keep in order to verify the returned POP value. The following describes one of many possible ways of addressing the problem by reducing the amount of state kept on the CA to a single (or small set) of values.
上記のアルゴリズムの潜在的な問題の1つは、CAが返されたPOP値を検証するために必要な状態の量です。以下は、CAに保管されている状態の量を単一の（または小さなセット）値に減らすことにより、問題に対処する多くの考えられる方法の1つについて説明します。
1. Server generates random seed x, constant across all requests. (The value of x would normally be altered on a regular basis and kept for a short time afterwards.)
1. サーバーは、すべての要求にわたって定数ランダムシードXを生成します。（通常、Xの値は定期的に変更され、その後しばらく保持されます。）
2. For certification request R, server computes y = F(x,R). F can be, for example, HMAC-SHA1(x,R). All that's important for statelessness is that y be consistently computable with only known state constant x and function F, other inputs coming from the certification request structure. y should not be predictable based on knowledge of R, thus the use of a one-way function like HMAC-SHA1.
2. 認証要求rの場合、サーバーはy = f（x、r）を計算します。fは、たとえば、hmac-sha1（x、r）です。ステートレスの重要なのは、Yが認定要求要求構造から来る他の入力のみが既知の状態定数xと関数Fのみで一貫して計算できることです。yはRの知識に基づいて予測可能であるべきではないため、HMAC-SHA1のような一方向関数の使用。
In a certification request scenario that involves an RA, the CA may allow (or require) that the RA perform the POP protocol with the entity that generated the certification request. In this case, the RA needs a way to inform the CA that it has done the POP. The RA POP Witness control addresses this issue.
RAを含む認証要求シナリオでは、CAは、RAが認証要求を生成したエンティティでPOPプロトコルを実行することを許可（または要求する）場合があります。この場合、RAはCAにポップを行ったことを通知する方法が必要です。RAポップ証人のコントロールは、この問題に対処しています。
The RA POP Witness control is identified by the OID:
RAポップ証人のコントロールは、OIDによって識別されます。
id-cmc-lraPOPWitness ::= { id-cmc 11 }
The RA POP Witness control has the ASN.1 definition:
RAポップ証人のコントロールにはASN.1定義があります。
LraPopWitness ::= SEQUENCE {
pkiDataBodyid BodyPartID,
bodyIds SEQUENCE of BodyPartID
}
The fields in LraPOPWitness have the following meaning:
lrapopwitnessのフィールドには、次の意味があります。
pkiDataBodyid contains the body part identifier of the nested TaggedContentInfo containing the client's Full PKI Request. pkiDataBodyid is set to 0 if the request is in the current PKIData.
pkidatabodyidには、クライアントの完全なPKIリクエストを含むネストされたタグGedContentInfoの身体部分識別子が含まれています。リクエストが現在のpkidataにある場合、pkidatabodyidは0に設定されます。
bodyIds is a list of certification requests for which the RA has performed an out-of-band authentication. The method of authentication could be archival of private key material, challenge-response, or other means.
BodyIDSは、RAが帯域外認証を実行した認証要求のリストです。認証の方法は、秘密のキー資料、課題反応、またはその他の手段のアーカイブである可能性があります。
If a certification server does not allow an RA to do the POP verification, it returns a CMCFailInfo with the value of popFailed. The CA MUST NOT start a challenge-response to re-verify the POP itself.
認定サーバーがRAがポップ検証を行うことを許可しない場合、PopFailedの値でCMCFailinfoを返します。CAは、ポップ自体を再確認するためにチャレンジ応答を開始してはなりません。
Everything described in this section is optional to implement.
このセクションで説明するすべては、実装するためにオプションです。
The Get Certificate control is used to retrieve a previously issued certificate from a certificate repository. A CA, an RA, or an independent service may provide this repository. The clients expected to use this facility are those where a fully deployed directory is either infeasible or undesirable.
GET証明書制御は、証明書リポジトリから以前に発行された証明書を取得するために使用されます。CA、RA、または独立したサービスは、このリポジトリを提供する場合があります。この施設を使用することを期待しているクライアントは、完全に展開されたディレクトリが実行不可または望ましくないもののいずれかであるクライアントです。
The Get Certificate control is identified by the OID:
GET証明書制御はOIDによって識別されます。
id-cmc-getCert ::= { id-cmc 15 }
The Get Certificate control has the ASN.1 definition:
GET証明書制御にはasn.1定義があります。
GetCert ::= SEQUENCE {
issuerName GeneralName,
serialNumber INTEGER }
The fields in GetCert have the following meaning:
GetCertのフィールドには次の意味があります。
issuerName is the name of the certificate issuer.
ISSUENMAMEは、証明書発行者の名前です。
serialNumber identifies the certificate to be retrieved.
SerialNumberは、取得する証明書を識別します。
The server that responds to this request places the requested certificate in the certificates field of a SignedData. If the Get Certificate control is the only control in a Full PKI Request, the response should be a Simple PKI Response.
この要求に応答するサーバーは、signedDataの証明書フィールドに要求された証明書を配置します。GET証明書制御が完全なPKIリクエストの唯一のコントロールである場合、応答は単純なPKI応答である必要があります。
Everything described in this section is optional to implement.
このセクションで説明するすべては、実装するためにオプションです。
The Get CRL control is used to retrieve CRLs from a repository of CRLs. A CA, an RA, or an independent service may provide this repository. The clients expected to use this facility are those where a fully deployed directory is either infeasible or undesirable.
GET CRLコントロールは、CRLのリポジトリからCRLを取得するために使用されます。CA、RA、または独立したサービスは、このリポジトリを提供する場合があります。この施設を使用することを期待しているクライアントは、完全に展開されたディレクトリが実行不可または望ましくないもののいずれかであるクライアントです。
The Get CRL control is identified by the OID:
GET CRLコントロールはOIDによって識別されます。
id-cmc-getCRL ::= { id-cmc 16 }
The Get CRL control has the ASN.1 definition:
GET CRLコントロールにはASN.1定義があります。
GetCRL ::= SEQUENCE {
issuerName Name,
cRLName GeneralName OPTIONAL,
time GeneralizedTime OPTIONAL,
reasons ReasonFlags OPTIONAL }
The fields in a GetCRL have the following meanings:
getcrlのフィールドには次の意味があります。
issuerName is the name of the CRL issuer.
ISSUENMAMEはCRL発行者の名前です。
cRLName may be the value of CRLDistributionPoints in the subject certificate or equivalent value in the event the certificate does not contain such a value.
CRLNAMEは、件名証明書のCRLDISTRIBUTIONPOINSの値または同等の値の値である場合があります。証明書にはそのような値が含まれていない場合です。
time is used by the client to specify from among potentially several issues of CRL that one whose thisUpdate value is less than but nearest to the specified time. In the absence of a time component, the CA always returns with the most recent CRL.
クライアントが時間を使用して、CRLの潜在的にいくつかの問題の中から指定するために、この値が指定された時間に近いほうが少ないものです。時間コンポーネントがない場合、CAは常に最新のCRLで戻ります。
reasons is used to specify from among CRLs partitioned by revocation reason. Implementers should bear in mind that while a specific revocation request has a single CRLReason code -- and consequently entries in the CRL would have a single CRLReason code value -- a single CRL can aggregate information for one or more reasonFlags.
理由によって分割されたCRLの間で指定するために理由が使用されます。実装者は、特定の取り消しリクエストには単一のCRLREASOONコードがあるが、その結果、CRLのエントリには単一のCRLREASORONコード値があるが、単一のCRLが1つ以上のReasonFlagsの情報を集約できることを覚えておく必要があります。
A server responding to this request places the requested CRL in the crls field of a SignedData. If the Get CRL control is the only control in a Full PKI Request, the response should be a Simple PKI Response.
この要求に応答するサーバーは、signedDataのCRLSフィールドに要求されたCRLを配置します。Get CRLコントロールが完全なPKIリクエストの唯一のコントロールである場合、応答は単純なPKI応答である必要があります。
The Revocation Request control is used to request that a certificate be revoked.
取り消し要求制御は、証明書を取り消すように要求するために使用されます。
The Revocation Request control is identified by the OID:
取り消し要求コントロールは、OIDによって識別されます。
id-cmc-revokeRequest ::= { id-cmc 17 }
The Revocation Request control has the ASN.1 definition:
取り消しリクエストコントロールにはasn.1定義があります。
RevokeRequest ::= SEQUENCE {
issuerName Name,
serialNumber INTEGER,
reason CRLReason,
invalidityDate GeneralizedTime OPTIONAL,
sharedSecret OCTET STRING OPTIONAL,
comment UTF8string OPTIONAL }
The fields of RevokeRequest have the following meaning:
Revokerequestの分野には次の意味があります。
issuerName is the issuerName of the certificate to be revoked.
ISSUENMAMEは、取り消される証明書の発行名です。
serialNumber is the serial number of the certificate to be revoked.
SerialNumberは、取り消される証明書のシリアル番号です。
reason is the suggested CRLReason code for why the certificate is being revoked. The CA can use this value at its discretion in building the CRL.
理由とは、証明書が取り消されている理由についての推奨されるCRLREASONコードです。CAは、CRLを構築する際にその裁量でこの値を使用できます。
invalidityDate is the suggested value for the Invalidity Date CRL Extension. The CA can use this value at its discretion in building the CRL.
InvalidityDateは、無効な日付CRL拡張の推奨値です。CAは、CRLを構築する際にその裁量でこの値を使用できます。
sharedSecret is a secret value registered by the EE when the certificate was obtained to allow for revocation of a certificate in the event of key loss.
SharedSecretは、重要な損失が発生した場合に証明書の取り消しを可能にするために証明書が取得されたときにEEによって登録された秘密の値です。
comment is a human-readable comment.
コメントは人間の読み取り可能なコメントです。
For a revocation request to be reliable in the event of a dispute, a strong proof-of-origin is required. However, in the instance when an EE has lost use of its signature private key, it is impossible for the EE to produce a digital signature (prior to the certification of a new signature key pair). The Revoke Request control allows the EE to send the CA a shared-secret that may be used as an alternative authenticator in the instance of loss of use of the EE's signature private key. The acceptability of this practice is a matter of local security policy.
紛争が発生した場合に信頼できる取り消し要求には、強力なオリジンの証明が必要です。ただし、EEが署名の秘密鍵の使用を失った場合、EEがデジタル署名を作成することは不可能です（新しい署名キーペアの認証の前）。Recoke Request Controlにより、EEは、EEの署名秘密鍵の使用の喪失の例では、代替の認証者として使用できる共有分泌範囲をCAに送信できます。この慣行の受け入れは、現地のセキュリティポリシーの問題です。
It is possible to sign the revocation for the lost certificate with a different certificate in some circumstances. A client can sign a revocation for an encryption key with a signing certificate if the name information matches. Similarly, an administrator or RA can be assigned the ability to revoke the certificate of a third party. Acceptance of the revocation by the server depends on local policy in these cases.
一部の状況では、異なる証明書で失われた証明書の取り消しに署名することができます。クライアントは、名前情報が一致する場合、署名証明書を使用して暗号化キーの取り消しに署名できます。同様に、管理者またはRAに、第三者の証明書を取り消す機能を割り当てることができます。サーバーによる失効の受け入れは、これらの場合のローカルポリシーに依存します。
Clients MUST provide the capability to produce a digitally signed Revocation Request control. Clients SHOULD be capable of producing an unsigned Revocation Request control containing the EE shared-secret (the unsigned message consisting of a SignedData with no signatures). If a client provides shared-secret-based self-revocation, the client MUST be capable of producing a Revocation Request control containing the shared-secret. Servers MUST be capable of accepting both forms of revocation requests.
クライアントは、デジタルで署名された失効リクエストコントロールを作成する機能を提供する必要があります。クライアントは、EEの共有秘密を含む署名のない取り消し要求コントロールを作成できる必要があります（署名のない署名dataで構成される署名のないメッセージ）。クライアントが共有秘密ベースの自己反射を提供する場合、クライアントは共有分泌範囲を含む取り消し要求コントロールを作成できる必要があります。サーバーは、両方のフォームの取り消し要求を受け入れることができる必要があります。
The structure of an unsigned, shared-secret-based revocation request is a matter of local implementation. The shared-secret does not need to be encrypted when sent in a Revocation Request control. The shared-secret has a one-time use (i.e., it is used to request revocation of the certificate), and public knowledge of the shared-secret after the certificate has been revoked is not a problem. Clients need to inform users that the same shared-secret SHOULD NOT be used for multiple certificates.
署名されていない共有秘密ベースの取り消し要求の構造は、ローカルの実装の問題です。共有秘密は、取り消しリクエストコントロールで送信されたときに暗号化する必要はありません。共有秘密には、1回限りの使用があり（つまり、証明書の取り消しを要求するために使用されます）、証明書が取り消された後の共有秘密の一般知識は問題ではありません。クライアントは、複数の証明書に同じ共有秘密を使用すべきではないことをユーザーに通知する必要があります。
A Full PKI Response MUST be returned for a revocation request.
取り消しリクエストのために、完全なPKI応答を返す必要があります。
The Registration Information control allows for clients to pass additional information as part of a Full PKI Request.
登録情報制御により、クライアントは完全なPKIリクエストの一部として追加情報を渡すことができます。
The Registration Information control is identified by the OID:
登録情報管理はOIDによって識別されます。
id-cmc-regInfo ::= { id-cmc 18 }
The Registration Information control has the ASN.1 definition:
登録情報制御にはasn.1定義があります。
RegInfo ::= OCTET STRING
The content of this data is based on bilateral agreement between the client and server.
このデータの内容は、クライアントとサーバー間の二国間契約に基づいています。
The Response Information control allows a server to return additional information as part of a Full PKI Response.
応答情報制御により、サーバーは完全なPKI応答の一部として追加情報を返すことができます。
The Response Information control is identified by the OID:
応答情報コントロールは、OIDによって識別されます。
id-cmc-responseInfo ::= { id-cmc 19 }
The Response Information control has the ASN.1 definition:
応答情報制御にはasn.1定義があります。
ResponseInfo ::= OCTET STRING
The content of this data is based on bilateral agreement between the client and server.
このデータの内容は、クライアントとサーバー間の二国間契約に基づいています。
In some environments, process requirements for manual intervention or other identity checks can delay the return of the certificate. The Query Pending control allows clients to query a server about the state of a pending certification request. The server returns a pendToken as part of the Extended CMC Status Info and the CMC Status Info controls (in the otherInfo field). The client copies the pendToken into the Query Pending control to identify the correct certification request to the server. The server returns a suggested time for the client to query for the state of a pending certification request.
一部の環境では、手動介入またはその他のIDチェックのプロセス要件は、証明書の返品を遅らせる可能性があります。保留中のクエリ制御により、クライアントは保留中の認定リクエストの状態についてサーバーに照会することができます。サーバーは、拡張されたCMCステータス情報とCMCステータス情報コントロールの一部としてペントンを返します（他のINFOフィールド）。クライアントは、サーバーへの正しい認証要求を識別するために、保留中のクエリにペントKOKNをクエリにコピーします。サーバーは、クライアントが保留中の認定リクエストの状態をクライアントに照会するための推奨時間を返します。
The Query Pending control is identified by the OID:
保留中のクエリ制御は、OIDによって識別されます。
id-cmc-queryPending ::= { id-cmc 21 }
The Query Pending control has the ASN.1 definition:
保留中のクエリの制御には、asn.1定義があります。
QueryPending ::= OCTET STRING
If a server returns a pending or partial CMCStatusInfo (the transaction is still pending), the otherInfo MAY be omitted. If the otherInfo is not omitted, the value of 'pendInfo' MUST be the same as the original pendInfo value.
サーバーが保留中または部分的なCMCSTATUSINFOを返す場合（トランザクションはまだ保留中です）、他のINFOは省略される場合があります。otherInfoが省略されていない場合、「Pendinfo」の値は元のPendinfo値と同じでなければなりません。
Some CAs require that clients give a positive confirmation that the certificates issued to the EE are acceptable. The Confirm Certificate Acceptance control is used for that purpose. If the CMC Status Info on a PKI Response is confirmRequired, then the client MUST return a Confirm Certificate Acceptance control contained in a Full PKI Request.
一部のCAは、EEに発行された証明書が許容できることをクライアントが肯定的な確認を与えることを要求しています。確認証明書の受け入れ制御は、その目的のために使用されます。PKI応答に関するCMCステータス情報が確認されている場合、クライアントは完全なPKIリクエストに含まれる確認証明書の受け入れコントロールを返す必要があります。
Clients SHOULD wait for the PKI Response from the server that the confirmation has been received before using the certificate for any purpose.
クライアントは、どの目的でも証明書を使用する前に確認が受信されたことをサーバーからのPKI応答を待つ必要があります。
The Confirm Certificate Acceptance control is identified by the OID:
確認証明書の受け入れ制御は、OIDによって識別されます。
id-cmc-confirmCertAcceptance ::= { id-cmc 24 }
The Confirm Certificate Acceptance control has the ASN.1 definition:
確認証明書の受け入れ制御には、asn.1定義があります。
CMCCertId ::= IssuerAndSerialNumber
CMCCertId contains the issuer and serial number of the certificate being accepted.
CMCCERTIDには、認定されている証明書の発行者とシリアル番号が含まれています。
Servers MUST return a Full PKI Response for a Confirm Certificate Acceptance control.
サーバーは、確認証明書の受け入れ制御のために完全なPKI応答を返す必要があります。
Note that if the CA includes this control, there will be two full round-trips of messages.
CAにこのコントロールが含まれている場合、2つの完全な往復のメッセージがあることに注意してください。
1. The client sends the certification request to the CA.
1. クライアントはCAに認定リクエストを送信します。
2. The CA returns a Full PKI Response with the certificate and this control.
2. CAは、証明書とこのコントロールで完全なPKI応答を返します。
3. The client sends a Full PKI Request to the CA with an Extended CMC Status Info control accepting and a Confirm Certificate Acceptance control or an Extended CMC Status Info control rejecting the certificate.
3. クライアントは、拡張されたCMCステータス情報コントロールの受け入れと証明書の受け入れコントロールの確認または証明書を拒否する拡張CMCステータス情報コントロールを使用して、CAに完全なPKIリクエストを送信します。
4. The CA sends a Full PKI Response to the client with an Extended CMC Status Info of success.
4. CAは、成功のCMCステータス情報を拡張して、クライアントに完全なPKI応答を送信します。
The Publish Trust Anchors control allows for the distribution of set trust anchors from a central authority to an EE. The same control is also used to update the set of trust anchors. Trust anchors are distributed in the form of certificates. These are expected, but not required, to be self-signed certificates. Information is extracted from these certificates to set the inputs to the certificates validation algorithm in Section 6.1.1 of [PKIXCERT].
Publish Trust Anchors Controlは、中央当局からEEへのセットトラストアンカーの配布を可能にします。同じコントロールも、信頼のアンカーのセットを更新するために使用されます。トラストアンカーは、証明書の形式で配布されます。これらは、自己署名証明書であることが予想されますが、必須ではありません。これらの証明書から情報が抽出され、[PKIXCERT]のセクション6.1.1の証明書検証アルゴリズムに入力を設定します。
The Publish Trust Anchors control is identified by the OID:
パブリッシュトラストアンカーコントロールは、OIDによって識別されます。
id-cmc-trustedAnchors ::= { id-cmc 26 }
The Publish Trust Anchors control has the ASN.1 definition:
Publish Trust Anchors ControlにはASN.1定義があります。
PublishTrustAnchors ::= SEQUENCE {
seqNumber INTEGER,
hashAlgorithm AlgorithmIdentifier,
anchorHashes SEQUENCE OF OCTET STRING
}
The fields in PublishTrustAnchors have the following meaning:
Publishtrustanchorsのフィールドには次の意味があります。
seqNumber is an integer indicating the location within a sequence of updates.
SeqNumberは、一連の更新内の位置を示す整数です。
hashAlgorithm is the identifier and parameters for the hash algorithm that is used in computing the values of the anchorHashes field. All implementations MUST implement SHA-1 for this field.
Hashalgorithmは、Anchorhashesフィールドの値の計算に使用されるハッシュアルゴリズムの識別子とパラメーターです。すべての実装は、このフィールドにSHA-1を実装する必要があります。
anchorHashes are the hashes for the certificates that are to be treated as trust anchors by the client. The actual certificates are transported in the certificate bag of the containing SignedData structure.
アンコラシュは、クライアントによって信頼のアンカーとして扱われる証明書のハッシュです。実際の証明書は、SignedData構造を含む証明書袋に輸送されます。
While it is recommended that the sender place the certificates that are to be trusted in the PKI Response, it is not required as the certificates should be obtainable using normal discovery techniques.
送信者は、PKI応答に信頼される証明書を配置することをお勧めしますが、通常の発見技術を使用して証明書を取得できるため、必要ではありません。
Prior to accepting the trust anchors changes, a client MUST at least do the following: validate the signature on the PKI Response to a current trusted anchor, check with policy to ensure that the signer is permitted to use the control, validate that the authenticated publish time in the signature is near to the current time, and validate that the sequence number is greater than the previously used one.
トラストアンカーの変更を受け入れる前に、クライアントは少なくとも次のことを行う必要があります：現在の信頼できるアンカーに対するPKI応答の署名を検証するには、署名者がコントロールを使用することを許可されていることを確認するためにポリシーを確認し、認証された公開を検証します署名の時間は現在の時刻に近く、シーケンス番号が以前に使用されたものよりも大きいことを検証します。
In the event that multiple agents publish a set of trust anchors, it is up to local policy to determine how the different trust anchors should be combined. Clients SHOULD be able to handle the update of multiple trust anchors independently.
複数のエージェントが一連の信頼アンカーを公開した場合、さまざまな信頼アンカーをどのように組み合わせるかを決定するのはローカルポリシー次第です。クライアントは、複数のトラストアンカーの更新を個別に処理できる必要があります。
Note: Clients that handle this control must use extreme care in validating that the operation is permissible. Incorrect handling of this control allows for an attacker to change the set of trust anchors on the client.
注：このコントロールを処理するクライアントは、操作が許容されることを検証する際に極端な注意を払う必要があります。このコントロールの処理が誤っていると、攻撃者がクライアントの信頼アンカーのセットを変更できます。
The Authenticated Data control allows a server to provide data back to the client in an authenticated manner. This control uses the Authenticated Data structure to allow for validation of the data. This control is used where the client has a shared-secret and a secret identifier with the server, but where a trust anchor has not yet been downloaded onto the client so that a signing certificate for the server cannot be validated. The specific case that this control was created for use with is the Publish Trust Anchors control (Section 6.15), but it may be used in other cases as well.
認証されたデータ制御により、サーバーは認証された方法でデータをクライアントに提供できます。このコントロールは、認証されたデータ構造を使用して、データの検証を可能にします。このコントロールは、クライアントがサーバーと共有秘密と秘密の識別子を持っている場合に使用されますが、サーバーの署名証明書を検証できないように、信頼アンカーがまだクライアントにダウンロードされていない場合。このコントロールが使用されるために作成された特定のケースは、Publish Trust Anchors Control（セクション6.15）ですが、他のケースでも使用される場合があります。
The Authenticated Data control is identified by the OID:
認証されたデータ制御は、OIDによって識別されます。
id-cmc-authData ::= { id-cmc 27 }
The Authenticated Data control has the ASN.1 definition:
認証されたデータコントロールには、asn.1定義があります。
AuthPublish ::= BodyPartID
AuthPublish is a body part identifier that refers to a member of the cmsSequence element for the current PKI Response or PKI Data. The cmsSequence element is AuthenticatedData. The encapsulated content is an id-cct-PKIData. The controls in the controlSequence need to be processed if the authentication succeeds. (One example is the Publish Trust Anchors control in Section 6.15.)
Authpublishは、現在のPKI応答またはPKIデータのCMS sequence要素のメンバーを指すボディパーツ識別子です。cms sequence要素は認証されています。カプセル化されたコンテンツはID-CCT-PKIDATAです。認証が成功した場合、制御シーケンスの制御を処理する必要があります。（1つの例は、セクション6.15のパブリッシュトラストアンカーコントロールです。）
If the authentication operation fails, the CMCFailInfo authDataFail is returned.
認証操作が失敗した場合、cmcfailinfo authdatafailが返されます。
These controls allow for an RA to collect multiple requests together into a single Full PKI Request and forward it to a CA. The server would then process the requests and return the results in a Full PKI Response.
これらのコントロールにより、RAは複数のリクエストを1つの完全なPKIリクエストに収集し、CAに転送できます。サーバーはリクエストを処理し、結果を完全なPKI応答で返します。
The Batch Request control is identified by the OID:
バッチリクエストコントロールは、OIDによって識別されます。
id-cmc-batchRequests ::= {id-cmc 28}
The Batch Response control is identified by the OID:
バッチ応答コントロールは、OIDによって識別されます。
id-cmc-batchResponses ::= {id-cmc 29}
Both the Batch Request and Batch Response controls have the ASN.1 definition:
バッチリクエストとバッチ応答コントロールの両方にASN.1定義があります。
BodyPartList ::= SEQUENCE of BodyPartID
The data associated with these controls is a set of body part identifiers. Each request/response is placed as an individual entry in the cmcSequence of the new PKIData/PKIResponse. The body part identifiers of these entries are then placed in the body part list associated with the control.
これらのコントロールに関連付けられたデータは、ボディパーツ識別子のセットです。各リクエスト/応答は、新しいpkidata/pkiresponseのCMC順序に個別のエントリとして配置されます。これらのエントリのボディパーツ識別子は、コントロールに関連付けられたボディパーツリストに配置されます。
When a server processes a Batch Request control, it MAY return the responses in one or more PKI Responses. A CMCStatus value of partial is returned on all but the last PKI Response. The CMCStatus would be success if the Batch Requests control was processed; the responses are created with their own CMCStatus code. Errors on individual requests are not propagated up to the top level.
サーバーがバッチ要求コントロールを処理すると、1つ以上のPKI応答で応答を返す場合があります。部分的なPKI応答を除くすべての部分に対して、部分的なcmcstatus値が返されます。バッチ要求制御が処理された場合、CMCSTATUSは成功します。応答は、独自のCMCSTATUSコードで作成されます。個々のリクエストのエラーは、トップレベルまで伝播されません。
When a PKI Response with a CMCStatus value of partial is returned, the Query Pending control (Section 6.13) is used to retrieve additional results. The returned status includes a suggested time after which the client should ask for the additional results.
部分的なCMCSTATUS値を使用したPKI応答が返されると、追加の結果を取得するためにクエリ保留中のコントロール（セクション6.13）が使用されます。返されたステータスには、推奨される時間が含まれており、その後、クライアントが追加の結果を求める必要があります。
The Publication Information control allows for modifying publication of already issued certificates, both for publishing and removal from publication. A common usage for this control is to remove an existing certificate from publication during a rekey operation. This control should always be processed after the issuance of new certificates and revocation requests. This control should not be processed if a certificate failed to be issued.
出版情報管理により、公開と削除の両方のために、すでに発行された証明書の公開を変更することができます。この制御の一般的な使用法は、Rekey操作中に既存の証明書を公開から削除することです。この制御は、新しい証明書と取り消し要求の発行後、常に処理する必要があります。証明書の発行に失敗した場合、このコントロールを処理しないでください。
The Publication Information control is identified by the OID:
出版情報管理はOIDによって識別されます。
id-cmc-publishCert ::= { id-cmc 30 }
The Publication Information control has the ASN.1 definition:
出版情報管理にはasn.1定義があります。
CMCPublicationInfo ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
certHashes SEQUENCE of OCTET STRING,
pubInfo PKIPublicationInfo
PKIPublicationInfo ::= SEQUENCE {
action INTEGER {
dontPublish (0),
pleasePublish (1) },
pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }
-- pubInfos MUST NOT be present if action is "dontPublish"
-- (if action is "pleasePublish" and pubInfos is omitted,
-- "dontCare" is assumed)
SinglePubInfo ::= SEQUENCE {
pubMethod INTEGER {
dontCare (0),
x500 (1),
web (2),
ldap (3) },
pubLocation GeneralName OPTIONAL }
}
The fields in CMCPublicationInfo have the following meaning:
CMCPublicationInfoのフィールドには、次の意味があります。
hashAlg is the algorithm identifier of the hash algorithm used to compute the values in certHashes.
Hashalgは、Certhashesの値を計算するために使用されるハッシュアルゴリズムのアルゴリズム識別子です。
certHashes are the hashes of the certificates for which publication is to change.
Certhashesは、出版物が変更される証明書のハッシュです。
pubInfo is the information where and how the certificates should be published. The fields in pubInfo (taken from [CRMF]) have the following meanings:
Pubinfoは、証明書をどこでどのように公開するかという情報です。Pubinfo（[CRMF]から取られた）のフィールドには、次の意味があります。
action indicates the action the service should take. It has two values:
アクションは、サービスが取るべきアクションを示します。2つの値があります。
dontPublish indicates that the PKI should not publish the certificate (this may indicate that the requester intends to publish the certificate him/herself). dontPublish has the added connotation of removing from publication the certificate if it is already published.
DontPublishは、PKIが証明書を公開してはならないことを示しています（これは、リクエスターが証明書を自分で公開するつもりであることを示している可能性があります）。DontPublishには、すでに公開されている場合、公開から削除されるという追加の意味合いがあります。
pleasePublish indicates that the PKI MAY publish the certificate using whatever means it chooses unless pubInfos is present. Omission of the CMC Publication Info control results in the same behavior.
PleasePublishは、PUBINFOSが存在しない限り、PKIが選択したあらゆる手段を使用して証明書を公開できることを示します。CMCの出版物情報制御の省略は、同じ動作をもたらします。
pubInfos pubInfos indicates how (e.g., X500, Web, IP Address) the PKI SHOULD publish the certificate.
PubInfos PubInfosは、PKIが証明書を公開する方法（X500、Web、IPアドレスなど）を示しています。
A single certificate SHOULD NOT appear in more than one Publication Information control. The behavior is undefined in the event that it does.
単一の証明書は、複数の出版物情報制御に表示されないでください。動作は、そうする場合に定義されていません。
The Control Processed control allows an RA to indicate to subsequent control processors that a specific control has already been processed. This permits an RA in the middle of a processing stream to process a control defined either in a local context or in a subsequent document.
制御処理制御により、RAは特定の制御がすでに処理されていることをその後の制御プロセッサに示すことができます。これにより、処理ストリームの中央にRAが可能になり、ローカルコンテキストまたは後続のドキュメントのいずれかで定義されたコントロールを処理できます。
The Control Processed control is identified by the OID:
制御処理された制御は、OIDによって識別されます。
id-cmc-controlProcessed ::= { id-cmc 32 }
The Control Processed control has the ASN.1 definition:
制御処理済み制御にはasn.1定義があります。
ControlList ::= SEQUENCE {
bodyList SEQUENCE SIZE (1..MAX) OF BodyPartReference
}
bodyList is a series of body part identifiers that form a path to each of the controls that were processed by the RA. This control is only needed for those controls that are not part of this standard and thus would cause an error condition of a server attempting to deal with a control not defined in this document. No error status is needed since an error causes the RA to return the request to the client with the error rather than passing the request on to the next server in the processing list.
ボディリストは、RAによって処理された各コントロールへのパスを形成する一連のボディパーツ識別子です。この制御は、この標準の一部ではないコントロールにのみ必要であり、したがって、このドキュメントで定義されていないコントロールに対処しようとするサーバーのエラー条件を引き起こすでしょう。エラーは、RAが処理リストの次のサーバーにリクエストを渡すのではなく、エラーを使用してクライアントにリクエストを返すため、エラーステータスは必要ありません。
This specification permits the use of RAs. An RA sits between the EE and the CA. From the EE's perspective, the RA appears to be the CA, and from the server, the RA appears to be a client. RAs receive the PKI Requests, perform local processing and then forward them onto CAs. Some of the types of local processing that an RA can perform include:
この仕様により、RASの使用が可能になります。RAはEEとCAの間にあります。EEの観点から見ると、RAはCAであるように見え、サーバーからはRAはクライアントのように見えます。RASはPKIリクエストを受け取り、ローカル処理を実行してからCASに転送します。RAが実行できるローカル処理の種類の一部は次のとおりです。
o Batching multiple PKI Requests together,
o 複数のPKIリクエストを一緒にバッチする、
o Performing challenge/response POP proofs,
o チャレンジ/応答ポッププルーフを実行する、
o Adding private or standardized certificate extensions to all certification requests,
o すべての認定リクエストにプライベートまたは標準化された証明書拡張機能を追加する、
o Archiving private key material,
o 秘密鍵素材のアーカイブ、
o Routing requests to different CAs.
o 異なるCAへのルーティングリクエスト。
When an RA receives a PKI Request, it has three options: it may forward the PKI Request without modification, it may add a new wrapping layer to the PKI Request, or it may remove one or more existing layers and add a new wrapping layer.
RAがPKIリクエストを受信すると、3つのオプションがあります。PKIリクエストを変更せずに転送するか、PKIリクエストに新しいラッピングレイヤーを追加するか、1つ以上の既存のレイヤーを削除して新しいラッピングレイヤーを追加する場合があります。
When an RA adds a new wrapping layer to a PKI Request, it creates a new PKIData. The new layer contains any controls required (for example, if the RA does the POP proof for an encryption key or the Add Extension control to modify a PKI Request) and the client PKI Request. The client PKI Request is placed in the cmsSequence if it is a Full PKI Request and in the reqSequence if it is a Simple PKI Request. If an RA is batching multiple client PKI Requests together, then each client PKI Request is placed into the appropriate location in the RA's PKIData object along with all relevant controls.
RAがPKIリクエストに新しいラッピングレイヤーを追加すると、新しいPKidataが作成されます。新しいレイヤーには、必要なコントロールが含まれています（たとえば、RAが暗号化キーのポッププルーフまたはPKIリクエストを変更するための追加拡張コントロールを実行する場合）およびクライアントPKIリクエスト。クライアントPKI要求は、完全なPKIリクエストの場合はCMSシーケンスに配置され、単純なPKIリクエストの場合はreqsequenceに配置されます。RAが複数のクライアントPKI要求をバッチしている場合、各クライアントPKIリクエストは、すべての関連するコントロールとともに、RAのPKIDATAオブジェクトの適切な場所に配置されます。
If multiple RAs are in the path between the EE and the CA, this will lead to multiple wrapping layers on the request.
複数のRAがEEとCAの間の経路にある場合、これによりリクエスト上の複数のラッピングレイヤーが発生します。
In processing a PKI Request, an RA MUST NOT alter any certification requests (PKCS #10 or CRMF) as any alteration would invalidate the signature on the certification request and thus the POP for the private key.
PKIリクエストの処理では、RAは認定要求（PKCS＃10またはCRMF）を変更してはなりません。変更は、認定要求の署名を無効にし、したがって秘密キーのPOPを無効にします。
An example of how this would look is illustrated by the following figure:
これがどのように見えるかの例は、次の図で説明されています。
SignedData (by RA) PKIData controlSequence RA added control statements reqSequence Zero or more Simple PKI Requests from clients cmsSequence Zero or more Full PKI Requests from clients SignedData (signed by client) PKIData
SignedData（RAによる）PKIDATA制御シーケンスRA追加制御ステートメントは、クライアントからのCMSシーケンスゼロ以上のフルPKIリクエストをクライアントからsignedData（クライアントが署名する）pkidataからのsequence zeroまたはより単純なpki要求を追加しましたpkidata
Under some circumstances, an RA is required to remove wrapping layers. The following sections look at the processing required if encryption layers and signing layers need to be removed.
状況によっては、ラッピングレイヤーを除去するためにRAが必要です。次のセクションでは、暗号化レイヤーと署名レイヤーを削除する必要がある場合、必要な処理について説明します。
There are two cases that require an RA to remove or change encryption in a PKI Request. In the first case, the encryption was applied for the purposes of protecting the entire PKI Request from unauthorized entities. If the CA does not have a Recipient Info entry in the encryption layer, the RA MUST remove the encryption layer. The RA MAY add a new encryption layer with or without adding a new signing layer.
PKI要求で暗号化を削除または変更するためにRAが必要な2つのケースがあります。最初のケースでは、不正なエンティティからPKI要求全体を保護する目的で暗号化が適用されました。CAに暗号化層に受信者情報エントリがない場合、RAは暗号化層を削除する必要があります。RAは、新しい署名レイヤーを追加する場合とせずに新しい暗号化レイヤーを追加する場合があります。
The second change of encryption that may be required is to change the encryption inside of a signing layer. In this case, the RA MUST remove all signing layers containing the encryption. All control statements MUST be merged according to local policy rules as each signing layer is removed and the resulting merged controls MUST be placed in a new signing layer provided by the RA. If the signing layer provided by the EE needs to also be removed, the RA can also remove this layer.
必要になる可能性のある暗号化の2番目の変更は、署名レイヤー内の暗号化を変更することです。この場合、RAは暗号化を含むすべての署名レイヤーを削除する必要があります。各署名層が削除され、結果のマージされたコントロールをRAが提供する新しい署名レイヤーに配置する必要があるため、すべての制御ステートメントはローカルポリシールールに従ってマージする必要があります。EEが提供する署名層も削除する必要がある場合、RAはこのレイヤーも削除することができます。
Only two instances exist where an RA should remove a signature layer on a Full PKI Request: if an encryption layer needs to be modified within the request, or if a CA will not accept secondary delegation (i.e., multiple RA signatures). In all other situations, RAs SHOULD NOT remove a signing layer from a PKI Request.
RAが完全なPKIリクエストで署名レイヤーを削除する必要がある場合は2つのインスタンスのみが存在します。要求内で暗号化レイヤーを変更する必要がある場合、またはCAが二次委任（つまり、複数のRAシグネチャ）を受け入れない場合。他のすべての状況では、RASはPKIリクエストから署名レイヤーを削除しないでください。
If an RA removes a signing layer from a PKI Request, all control statements MUST be merged according to local policy rules. The resulting merged control statements MUST be placed in a new signing layer provided by the RA.
RAがPKI要求から署名レイヤーを削除する場合、すべての制御ステートメントはローカルポリシールールに従ってマージする必要があります。結果のマージされたコントロールステートメントは、RAが提供する新しい署名レイヤーに配置する必要があります。
Mechanisms for thwarting replay attacks may be required in particular implementations of this protocol depending on the operational environment. In cases where the CA maintains significant state information, replay attacks may be detectable without the inclusion of the optional nonce mechanisms. Implementers of this protocol need to carefully consider environmental conditions before choosing whether or not to implement the senderNonce and recipientNonce controls described in Section 6.6. Developers of state-constrained PKI clients are strongly encouraged to incorporate the use of these controls.
リプレイ攻撃を妨害するためのメカニズムは、運用環境に応じて、このプロトコルの特に実装で必要になる場合があります。CAが重要な状態情報を維持している場合、オプションのNonCEメカニズムを含めることなく、リプレイ攻撃が検出される可能性があります。このプロトコルの実装者は、セクション6.6で説明されているSendernonceおよびRecipientNonceコントロールを実装するかどうかを選択する前に、環境条件を慎重に検討する必要があります。州に制約のあるPKIクライアントの開発者は、これらのコントロールの使用を組み込むことを強く奨励されています。
Extreme care needs to be taken when archiving a signing key. The holder of the archived key may have the ability to use the key to generate forged signatures. There are however reasons why a signing key should be archived. An archived CA signing key can be recovered in the event of failure to continue to produced CRLs following a disaster.
署名キーをアーカイブするときは、細心の注意を払う必要があります。アーカイブキーの所有者は、キーを使用して偽造署名を生成する機能を備えている場合があります。ただし、署名キーをアーカイブする理由はあります。アーカイブされたCA署名キーは、災害後もCRLを生成し続けない場合に回復できます。
Due care must be taken prior to archiving keys. Once a key is given to an archiving entity, the archiving entity could use the keys in a way not conducive to the archiving entity. Users should be made especially aware that proper verification is made of the certificate used to encrypt the private key material.
キーをアーカイブする前に、適切な注意を払う必要があります。アーカイブエンティティにキーが与えられると、アーカイブエンティティはアーカイブエンティティを助長しない方法でキーを使用できます。ユーザーは、秘密のキー資料を暗号化するために使用される証明書の適切な検証が行われていることを特に認識する必要があります。
Clients and servers need to do some checks on cryptographic parameters prior to issuing certificates to make sure that weak parameters are not used. A description of the small subgroup attack is provided in [X942]. Methods of avoiding the small subgroup attack can be found in [SMALL-GROUP]. CMC implementations ought to be aware of this attack when doing parameter validations.
クライアントとサーバーは、弱いパラメーターが使用されていないことを確認するために、証明書を発行する前に暗号化パラメーターをいくつかチェックする必要があります。小さなサブグループ攻撃の説明は[x942]に記載されています。小さなサブグループ攻撃を回避する方法は、[小グループ]にあります。CMCの実装は、パラメーターの検証を行う際にこの攻撃に注意する必要があります。
When using a shared-secret for authentication purposes, the shared-secret should be generated using good random number techniques [RANDOM]. User selection of the secret allows for dictionary attacks to be mounted.
認証目的で共有秘密を使用する場合、共有分泌物は、良好な乱数手法[ランダム]を使用して生成する必要があります。秘密のユーザー選択により、辞書攻撃を取り付けることができます。
Extreme care must be used when processing the Publish Trust Anchors control. Incorrect processing can lead to the practice of slamming where an attacker changes the set of trusted anchors in order to weaken security.
Publish Trust Anchors Controlを処理する際には、極端な注意を使用する必要があります。誤った処理は、セキュリティを弱めるために攻撃者が信頼できるアンカーのセットを変更する場合、スラミングの実践につながる可能性があります。
One method of controlling the use of the Publish Trust Anchors control is as follows. The client needs to associate with each trust anchor accepted by the client the source of the trust anchor. Additionally, the client should associate with each trust anchor the types of messages for which the trust anchor is valid (i.e., is the trust anchor used for validating S/MIME messages, TLS, or CMC enrollment messages?).
パブリッシュトラストアンカー制御の使用を制御する1つの方法は次のとおりです。クライアントは、クライアントが信頼アンカーのソースに受け入れた各トラストアンカーに関連付ける必要があります。さらに、クライアントは、各トラストアンカーに関連付けて、信頼アンカーが有効なメッセージの種類をアンカーする必要があります（つまり、信頼アンカーはS/MIMEメッセージ、TLS、またはCMC登録メッセージの検証に使用されますか？）。
When a new message is received with a Publish Trust Anchors control, the client would accept the set of new trust anchors for specific applications only if the signature validates, the signer of the message has the required policy approval for updating the trust anchors, and local policy also would allow updating the trust anchors.
パブリッシュトラストアンカーコントロールで新しいメッセージが受信されると、クライアントは署名が検証された場合にのみ、特定のアプリケーションの新しい信頼アンカーのセットを受け入れます。ポリシーは、信頼のアンカーを更新することもできます。
The CMS AuthenticatedData structure provides message integrity, it does not provide message authentication in all cases. When using MACs in this document the following restrictions need to be observed. All messages should be for a single entity. If two entities are placed in a single message, the entities can generate new messages that have a valid MAC and might be assumed to be from the original message sender. All entities that have access to the shared-secret can generate messages that will have a successful MAC validation. This means that care must be taken to keep this value secret. Whenever possible, the SignedData structure should be used in preference to the AuthenticatedData structure.
CMS認証Data構造は、メッセージの整合性を提供し、すべての場合にメッセージ認証を提供しません。このドキュメントでMACを使用する場合、次の制限を観察する必要があります。すべてのメッセージは、単一のエンティティ用である必要があります。2つのエンティティが単一のメッセージに配置されている場合、エンティティは有効なMACを持つ新しいメッセージを生成し、元のメッセージ送信者からであると想定される可能性があります。共有秘密にアクセスできるすべてのエンティティは、MAC検証を成功させるメッセージを生成できます。これは、この価値を秘密にするために注意を払わなければならないことを意味します。可能な場合はいつでも、SignedData構造は、認証されたData構造を好むために使用する必要があります。
This document defines a number of control objects. These are identified by Object Identifiers (OIDs). The objects are defined from an arc delegated by IANA to the PKIX Working Group. No further action by IANA is necessary for this document or any anticipated updates.
このドキュメントでは、多くの制御オブジェクトを定義します。これらは、オブジェクト識別子（OID）によって識別されます。オブジェクトは、IANAによって委任されたARCからPKIXワーキンググループに定義されます。このドキュメントまたは予想される更新には、IANAによるさらなるアクションは必要ありません。
The authors and the PKIX Working Group are grateful for the participation of Xiaoyi Liu and Jeff Weinstein in helping to author the original versions of this document.
著者とPKIXワーキンググループは、このドキュメントの元のバージョンの執筆を支援するXiaoyi LiuとJeff Weinsteinの参加に感謝しています。
The authors would like to thank Brian LaMacchia for his work in developing and writing up many of the concepts presented in this document. The authors would also like to thank Alex Deacon and Barb Fox for their contributions.
著者は、この文書に記載されている多くの概念を開発し、書くことの仕事について、ブライアン・ラマッキアに感謝したいと思います。著者はまた、アレックス・ディーコンとバーブ・フォックスの貢献に感謝したいと思います。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS] Housley、R。、「暗号化メッセージ構文（CMS）」、RFC 3852、2004年7月。
[CRMF] Schaad, J., "Internet X.509 Certification Request Message Format", RFC 4211, January 2005.
[CRMF] Schaad、J。、「Internet X.509認証要求メッセージフォーマット」、RFC 4211、2005年1月。
[DH-POP] Prafullchandra, H. and J. Schaad, "Diffie-Hellman Proof-of-Possession Algorithms", RFC 2875, June 2000.
[DH-POP] Prafullchandra、H。およびJ. Schaad、「Diffie-Hellman Proof-of-Possession algorithms」、RFC 2875、2000年6月。
[PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax v1.5", RFC 2314, October 1997.
[PKCS10] Kaliski、B。、「PKCS＃10：認定要求構文V1.5」、RFC 2314、1997年10月。
Note that this version of PKCS #10 is used for compatibility with the use of 1988 ASN.1 syntax. An effort is currently underway in the PKIX working group to update to use 2003 ASN.1 syntax.
このバージョンのPKCS＃10は、1988 ASN.1構文の使用と互換性があるために使用されることに注意してください。PKIXワーキンググループでは、2003 ASN.1構文を使用するための更新に取り組んでいます。
[PKIXCERT] Housley, R., Ford, W., Polk, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[Pkixcert] Housley、R.、Ford、W.、Polk、W。、およびD. Solo、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、RFC 2119、BCP 14、1997年3月。
[CMC-TRANS] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC): Transport Protocols", RFC 5273, June 2008.
[CMC-Trans] Schaad、J。およびM. Myers、「CMS（CMC）の証明書管理：輸送プロトコル」、RFC 5273、2008年6月。
[CMC-COMPL] Schaad, J. and M. Myers, "Certificate Management Messages over CMS (CMC): Compliance Requirements", RFC 5274, June 2008.
[CMC-Compl] Schaad、J。およびM. Myers、「CMS（CMC）を介した証明書管理メッセージ：コンプライアンス要件」、RFC 5274、2008年6月。
[PASSWORD] Burr, W., Dodson, D., and W. Polk, "Electronic Authentication Guideline", NIST SP 800-63, April 2006.
[パスワード] Burr、W.、Dodson、D。、およびW. Polk、「電子認証ガイドライン」、Nist SP 800-63、2006年4月。
[RANDOM] Eastlake, 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[ランダム] Eastlake、3rd、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[SMALL-GROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME", RFC 2785, March 2000.
[Small-Group] Zuccherato、R。、「S/MIMEのDiffie-Hellman Key Asmaterメソッドに対する「小型」攻撃を回避する方法」、RFC 2785、2000年3月。
[X942] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[x942] Rescorla、E。、「Diffie-Hellman Key Asmatement Method」、RFC 2631、1999年6月。
[RFC2797] Myers, M., Liu, X., Schaad, J., and J. Weinstein, "Certificate Management Messages over CMS", RFC 2797, April 2000.
[RFC2797] Myers、M.、Liu、X.、Schaad、J。、およびJ. Weinstein、「CMS上の証明書管理メッセージ」、RFC 2797、2000年4月。
EnrollmentMessageSyntax
{ iso(1) identified-organization(3) dod(4) internet(1)
security(5) mechansims(5) pkix(7) id-mod(0) id-mod-cmc2002(23) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS All --
-- The types and values defined in this module are exported for use
-- in the other ASN.1 modules. Other applications may use them for
-- their own purposes.
IMPORTS
輸入
-- PKIX Part 1 - Implicit From [PKIXCERT]
GeneralName, CRLReason, ReasonFlags
FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit(19)}
-- PKIX Part 1 - Explicit From [PKIXCERT]
AlgorithmIdentifier, Extension, Name, CertificateSerialNumber
FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18)}
-- Cryptographic Message Syntax FROM [CMS]
ContentInfo, Attribute, IssuerAndSerialNumber
FROM CryptographicMessageSyntax2004 { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
modules(0) cms-2004(24)}
-- CRMF FROM [CRMF]
CertReqMsg, PKIPublicationInfo, CertTemplate
FROM PKIXCRMF-2005 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-crmf2005(36)};
-- Global Types
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The content of this type conforms to RFC 2279.
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-cmc OBJECT IDENTIFIER ::= {id-pkix 7} -- CMC controls
id-cct OBJECT IDENTIFIER ::= {id-pkix 12} -- CMC content types
-- The following controls have the type OCTET STRING
- 次のコントロールには、タイプのオクテット文字列があります
id-cmc-identityProof OBJECT IDENTIFIER ::= {id-cmc 3}
id-cmc-dataReturn OBJECT IDENTIFIER ::= {id-cmc 4}
id-cmc-regInfo OBJECT IDENTIFIER ::= {id-cmc 18}
id-cmc-responseInfo OBJECT IDENTIFIER ::= {id-cmc 19}
id-cmc-queryPending OBJECT IDENTIFIER ::= {id-cmc 21}
id-cmc-popLinkRandom OBJECT IDENTIFIER ::= {id-cmc 22}
id-cmc-popLinkWitness OBJECT IDENTIFIER ::= {id-cmc 23}
-- The following controls have the type UTF8String
- 次のコントロールには、UTF8STRINGのタイプがあります
id-cmc-identification OBJECT IDENTIFIER ::= {id-cmc 2}
-- The following controls have the type INTEGER
- 次のコントロールには整数があります
id-cmc-transactionId OBJECT IDENTIFIER ::= {id-cmc 5}
-- The following controls have the type OCTET STRING
- 次のコントロールには、タイプのオクテット文字列があります
id-cmc-senderNonce OBJECT IDENTIFIER ::= {id-cmc 6}
id-cmc-recipientNonce OBJECT IDENTIFIER ::= {id-cmc 7}
-- This is the content type used for a request message in the protocol
- これは、プロトコルのリクエストメッセージに使用されるコンテンツタイプです
id-cct-PKIData OBJECT IDENTIFIER ::= { id-cct 2 }
PKIData ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
bodyIdMax INTEGER ::= 4294967295
BodyPartID ::= INTEGER(0..bodyIdMax)
TaggedAttribute ::= SEQUENCE {
bodyPartID BodyPartID,
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue
}
AttributeValue ::= ANY
TaggedRequest ::= CHOICE {
tcr [0] TaggedCertificationRequest,
crm [1] CertReqMsg,
orm [2] SEQUENCE {
bodyPartID BodyPartID,
requestMessageType OBJECT IDENTIFIER,
requestMessageValue ANY DEFINED BY requestMessageType
}
}
TaggedCertificationRequest ::= SEQUENCE {
bodyPartID BodyPartID,
certificationRequest CertificationRequest
}
CertificationRequest ::= SEQUENCE {
certificationRequestInfo SEQUENCE {
version INTEGER,
subject Name,
subjectPublicKeyInfo SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING },
attributes [0] IMPLICIT SET OF Attribute },
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING
}
TaggedContentInfo ::= SEQUENCE {
bodyPartID BodyPartID,
contentInfo ContentInfo
}
OtherMsg ::= SEQUENCE {
bodyPartID BodyPartID,
otherMsgType OBJECT IDENTIFIER,
otherMsgValue ANY DEFINED BY otherMsgType }
-- This defines the response message in the protocol
id-cct-PKIResponse OBJECT IDENTIFIER ::= { id-cct 3 }
ResponseBody ::= PKIResponse
PKIResponse ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
}
-- Used to return status state in a response
- 応答でステータス状態を返すために使用されます
id-cmc-statusInfo OBJECT IDENTIFIER ::= {id-cmc 1}
CMCStatusInfo ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF BodyPartID,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo } OPTIONAL
}
PendInfo ::= SEQUENCE {
pendToken OCTET STRING,
pendTime GeneralizedTime
}
CMCStatus ::= INTEGER {
success (0),
failed (2),
pending (3),
noSupport (4),
confirmRequired (5),
popRequired (6),
partial (7)
}
-- Note:
-- The spelling of unsupportedExt is corrected in this version.
-- In RFC 2797, it was unsuportedExt.
CMCFailInfo ::= INTEGER {
badAlg (0),
badMessageCheck (1),
badRequest (2),
badTime (3),
badCertId (4),
unsupportedExt (5),
mustArchiveKeys (6),
badIdentity (7),
popRequired (8),
popFailed (9),
noKeyReuse (10),
internalCAError (11),
tryLater (12),
authDataFail (13)
}
-- Used for RAs to add extensions to certification requests
id-cmc-addExtensions OBJECT IDENTIFIER ::= {id-cmc 8}
AddExtensions ::= SEQUENCE {
pkiDataReference BodyPartID,
certReferences SEQUENCE OF BodyPartID,
extensions SEQUENCE OF Extension
}
id-cmc-encryptedPOP OBJECT IDENTIFIER ::= {id-cmc 9}
id-cmc-decryptedPOP OBJECT IDENTIFIER ::= {id-cmc 10}
EncryptedPOP ::= SEQUENCE {
request TaggedRequest,
cms ContentInfo,
thePOPAlgID AlgorithmIdentifier,
witnessAlgID AlgorithmIdentifier,
witness OCTET STRING
}
DecryptedPOP ::= SEQUENCE {
bodyPartID BodyPartID,
thePOPAlgID AlgorithmIdentifier,
thePOP OCTET STRING
}
id-cmc-lraPOPWitness OBJECT IDENTIFIER ::= {id-cmc 11}
LraPopWitness ::= SEQUENCE {
pkiDataBodyid BodyPartID,
bodyIds SEQUENCE OF BodyPartID
}
--
id-cmc-getCert OBJECT IDENTIFIER ::= {id-cmc 15}
GetCert ::= SEQUENCE {
issuerName GeneralName,
serialNumber INTEGER }
id-cmc-getCRL OBJECT IDENTIFIER ::= {id-cmc 16}
GetCRL ::= SEQUENCE {
issuerName Name,
cRLName GeneralName OPTIONAL,
time GeneralizedTime OPTIONAL,
reasons ReasonFlags OPTIONAL }
id-cmc-revokeRequest OBJECT IDENTIFIER ::= {id-cmc 17}
RevokeRequest ::= SEQUENCE {
issuerName Name,
serialNumber INTEGER,
reason CRLReason,
invalidityDate GeneralizedTime OPTIONAL,
passphrase OCTET STRING OPTIONAL,
comment UTF8String OPTIONAL }
id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= {id-cmc 24}
CMCCertId ::= IssuerAndSerialNumber
-- The following is used to request V3 extensions be added to a
-- certificate
id-ExtensionReq OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) 14}
ExtensionReq ::= SEQUENCE SIZE (1..MAX) OF Extension
-- The following exists to allow Diffie-Hellman Certification Requests
-- Messages to be well-formed
id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2}
NoSignatureValue ::= OCTET STRING
-- Unauthenticated attribute to carry removable data.
-- This could be used in an update of "CMC Extensions: Server Side
-- Key Generation and Key Escrow" (February 2005) and in other
-- documents.
id-aa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2)}
id-aa-cmc-unsignedData OBJECT IDENTIFIER ::= {id-aa 34}
CMCUnsignedData ::= SEQUENCE {
bodyPartPath BodyPartPath,
identifier OBJECT IDENTIFIER,
content ANY DEFINED BY identifier
}
-- Replaces CMC Status Info --
-CMCステータス情報を置き換える -
id-cmc-statusInfoV2 OBJECT IDENTIFIER ::= {id-cmc 25}
CMCStatusInfoV2 ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF
BodyPartReference,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo,
extendedFailInfo SEQUENCE {
failInfoOID OBJECT IDENTIFIER,
failInfoValue AttributeValue
}
} OPTIONAL
}
BodyPartReference ::= CHOICE {
bodyPartID BodyPartID,
bodyPartPath BodyPartPath
}
BodyPartPath ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
-- Allow for distribution of trust anchors --
- 信頼アンカーの配布を可能にします -
id-cmc-trustedAnchors OBJECT IDENTIFIER ::= {id-cmc 26}
PublishTrustAnchors ::= SEQUENCE {
seqNumber INTEGER,
hashAlgorithm AlgorithmIdentifier,
anchorHashes SEQUENCE OF OCTET STRING
}
id-cmc-authData OBJECT IDENTIFIER ::= {id-cmc 27}
AuthPublish ::= BodyPartID
-- These two items use BodyPartList
id-cmc-batchRequests OBJECT IDENTIFIER ::= {id-cmc 28}
id-cmc-batchResponses OBJECT IDENTIFIER ::= {id-cmc 29}
BodyPartList ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
--
id-cmc-publishCert OBJECT IDENTIFIER ::= {id-cmc 30}
CMCPublicationInfo ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
certHashes SEQUENCE OF OCTET STRING,
pubInfo PKIPublicationInfo
}
id-cmc-modCertTemplate OBJECT IDENTIFIER ::= {id-cmc 31}
ModCertTemplate ::= SEQUENCE {
pkiDataReference BodyPartPath,
certReferences BodyPartList,
replace BOOLEAN DEFAULT TRUE,
certTemplate CertTemplate
}
-- Inform follow on servers that one or more controls have already been
-- processed
id-cmc-controlProcessed OBJECT IDENTIFIER ::= {id-cmc 32}
ControlsProcessed ::= SEQUENCE {
bodyList SEQUENCE SIZE(1..MAX) OF BodyPartReference
}
-- Identity Proof control w/ algorithm agility
- アルゴリズムの俊敏性を備えたアイデンティティ証明制御
id-cmc-identityProofV2 OBJECT IDENTIFIER ::= { id-cmc 34 }
IdentifyProofV2 ::= SEQUENCE {
proofAlgID AlgorithmIdentifier,
macAlgId AlgorithmIdentifier,
witness OCTET STRING
}
id-cmc-popLinkWitnessV2 OBJECT IDENTIFIER ::= { id-cmc 33 }
PopLinkWitnessV2 ::= SEQUENCE {
keyGenAlgorithm AlgorithmIdentifier,
macAlgorithm AlgorithmIdentifier,
witness OCTET STRING
}
END
終わり
This section is informational. The purpose of this section is to present, in an abstracted version, the messages that would flow between the client and server for several different common cases.
このセクションは情報提供です。このセクションの目的は、抽象化されたバージョンで、いくつかの異なる一般的なケースに対してクライアントとサーバーの間に流れるメッセージを提示することです。
This section looks at the messages that would flow in the event that an enrollment is occurring for a signing-only key. If the certificate was designed for both signing and encryption, the only difference would be the key usage extension in the certification request.
このセクションでは、署名のみのキーのために登録が発生している場合に流れるメッセージを調べます。証明書が署名と暗号化の両方に対して設計された場合、唯一の違いは、認証要求の重要な使用法延長です。
Message #2 from client to server:
クライアントからサーバーへのメッセージ＃2：
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIData
eContent
controlSequence
{102, id-cmc-identityProof, computed value}
{103, id-cmc-senderNonce, 10001}
reqSequence
certRequest
certReqId = 201
certTemplate
subject = My Proposed DN
publicKey = My Public Key
extensions
{id-ce-subjectPublicKeyIdentifier, 1000}
{id-ce-keyUsage, digitalSignature}
SignedData.SignerInfos
SignerInfo
sid.subjectKeyIdentifier = 1000
Response from server to client:
サーバーからクライアントへの応答：
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{102, id-cmc-statusInfoV2, {success, 201}}
{103, id-cmc-senderNonce, 10005}
{104, id-cmc-recipientNonce, 10001}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
This section looks at the messages that would flow in the event that an enrollment has one RA in the middle of the data flow. That RA will modify the certification request before passing it on to the CA.
このセクションでは、登録がデータフローの途中に1つのRAがある場合に流れるメッセージを調べます。そのRAは、CAに渡す前に認証要求を変更します。
Message from client to RA:
クライアントからRAへのメッセージ：
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIData
eContent
controlSequence
{102, id-cmc-identityProof, computed value}
{103, id-cmc-senderNonce, 10001}
reqSequence
certRequest
certReqId = 201
certTemplate
subject = My Proposed DN
publicKey = My Public Key
extensions
{id-ce-subjectPublicKeyIdentifier, 1000}
{id-ce-keyUsage, digitalSignature}
SignedData.SignerInfos
SignerInfo
sid.subjectKeyIdentifier = 1000
Message from RA to CA:
RAからCAへのメッセージ：
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIData
eContent
controlSequence
{ 102, id-cmc-batchRequests, { 1, 2} }
{ 103, id-cmc-addExtensions,
{ {1, 201, {id-ce-certificatePolicies, anyPolicy}}
{1, 201, {id-ce-subjectAltName, {extension data}}
{2, XXX, {id-ce-subjectAltName, {extension data}}}
The Value XXX is not known here; it would
reference into the second client request,
which is not displayed above.
cmsSequence
{ 1, <Message from client to RA #1> }
{ 2, <Message from client to RA #2> }
SignedData.SignerInfos
SignerInfo
sid = RA key.
Response from CA to RA:
CAからRAへの応答：
ContentInfo.contentType = id-signedData ContentInfo.content SignedData.encapContentInfo eContentType = id-ct-PKIResponse eContent controlSequence {102, id-cmc-BatchResponse, {999, 998}}
contentinfo.contentType = id-signedData contentinfo.content signeddata.encapcontentinfo econtenttype = id-ct-pkiresponse econtentコントロールシーケンス{102、id-cmc-batchResponse、{999、998}}}}}}
{103, id-cmc-statusInfoV2, {failed, 2, badIdentity}}
cmsSequence
{ bodyPartID = 999
contentInfo
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{102, id-cmc-statusInfoV2, {success, 201}}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
}
{ bodyPartID = 998,
contentInfo
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{102, id-cmc-statusInfoV2, {failure, badAlg}}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
}
SignedData.SignerInfos
Signed by CA
Response from RA to client:
RAからクライアントへの応答：
ContentInfo.contentType = id-signedData ContentInfo.content SignedData.encapContentInfo eContentType = id-ct-PKIResponse eContent controlSequence {102, id-cmc-statusInfoV2, {success, 201}} certificates Newly issued certificate Other certificates SignedData.SignerInfos Signed by CA
contentinfo.contenttype = id-signeddata contentinfo.content signeddata.encapcontentinfo econtenttype = id-ct-pkiresponse econtentコントロールシーケンス{102、id-cmc-statusinfov2、{success、201}}
This section looks at the messages that would flow in the event that an enrollment is done for an encryption only certificate using an direct POP method. For simplicity, it is assumed that the certification requester already has a signing-only certificate.
このセクションでは、直接POPメソッドを使用して暗号化のみの証明書に対して登録が行われた場合に流れるメッセージを調べます。簡単にするために、認定要求者はすでに署名のみの証明書を持っていると想定されています。
The fact that a second round-trip is required is implicit rather than explicit. The server determines this based on the fact that no other POP exists for the certification request.
2回目の往復が必要であるという事実は、明示的ではなく暗黙的です。サーバーは、認証要求のために他のPOPが存在しないという事実に基づいてこれを決定します。
Message #1 from client to server:
クライアントからサーバーへのメッセージ＃1：
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIData
eContent
controlSequence
{102, id-cmc-transactionId, 10132985123483401}
{103, id-cmc-senderNonce, 10001}
{104, id-cmc-dataReturn, <packet of binary data identifying
where the key in question is.>}
reqSequence
certRequest
certReqId = 201
certTemplate
subject = <My DN from my signing cert>
publicKey = My Public Key
extensions
{id-ce-keyUsage, keyEncipherment}
popo
keyEncipherment
subsequentMessage
SignedData.SignerInfos
SignerInfo
Signed by requester's signing cert
Response #1 from server to client:
サーバーからクライアントへの応答＃1：
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{101, id-cmc-statusInfoV2, {failed, 201, popRequired}}
{102, id-cmc-transactionId, 10132985123483401}
{103, id-cmc-senderNonce, 10005}
{104, id-cmc-recipientNonce, 10001}
{105, id-cmc-encryptedPOP, {
request {
certRequest
certReqId = 201
certTemplate
subject = <My DN from my signing cert>
publicKey = My Public Key
extensions
{id-ce-keyUsage, keyEncipherment}
popo
keyEncipherment
subsequentMessage
}
cms
contentType = id-envelopedData
content
recipientInfos.riid.issuerSerialNumber = <NULL, 201>
encryptedContentInfo
eContentType = id-data
eContent = <Encrypted value of 'y'>
thePOPAlgID = HMAC-SHA1
witnessAlgID = SHA-1
witness <hashed value of 'y'>}}
{106, id-cmc-dataReturn, <packet of binary data identifying
where the key in question is.>}
certificates
Other certificates (optional)
SignedData.SignerInfos
Signed by CA
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIData
eContent
controlSequence
{102, id-cmc-transactionId, 10132985123483401}
{103, id-cmc-senderNonce, 100101}
{104, id-cmc-dataReturn, <packet of binary data identifying
where the key in question is.>}
{105, id-cmc-recipientNonce, 10005}
{107, id-cmc-decryptedPOP, {
bodyPartID 201,
thePOPAlgID HMAC-SHA1,
thePOP <HMAC computed value goes here>}}
reqSequence
certRequest
certReqId = 201
certTemplate
subject = <My DN from my signing cert>
publicKey = My Public Key
extensions
{id-ce-keyUsage, keyEncipherment}
popo
keyEncipherment
subsequentMessage
SignedData.SignerInfos SignerInfo Signed by requester's signing cert
signeddata.signerinfos signerinfoは、リクエスターの署名証明書に署名されました
Response #2 from server to client:
サーバーからクライアントへの応答＃2：
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{101, id-cmc-transactionId, 10132985123483401}
{102, id-cmc-statusInfoV2, {success, 201}}
{103, id-cmc-senderNonce, 10019}
{104, id-cmc-recipientNonce, 100101}
{105, id-cmc-dataReturn, <packet of binary data identifying
where the key in question is.>}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
Appendix C. Production of Diffie-Hellman Public Key Certification Requests
付録C. diffie-hellman公開キー認定リクエストの作成
Part of a certification request is a signature over the request; Diffie-Hellman is a key agreement algorithm and cannot be used to directly produce the required signature object. [DH-POP] provides two ways to produce the necessary signature value. This document also defines a signature algorithm that does not provide a POP value, but can be used to produce the necessary signature value.
認証要求の一部は、リクエストに対する署名です。Diffie-Hellmanは重要な契約アルゴリズムであり、必要な署名オブジェクトを直接生成するために使用することはできません。[DH-POP]は、必要な署名値を作成する2つの方法を提供します。このドキュメントは、ポップ値を提供しないが、必要な署名値を作成するために使用できる署名アルゴリズムも定義します。
Key management (encryption/decryption) private keys cannot always be used to produce some type of signature value as they can be in a decrypt-only device. Certification requests require that the signature field be populated. This section provides a signature algorithm specifically for that purposes. The following object identifier and signature value are used to identify this signature type:
キー管理（暗号化/復号化）プライベートキーを使用して、復号化のみのデバイスにあるため、何らかのタイプの署名値を生成することはできません。認定リクエストでは、署名フィールドを入力する必要があります。このセクションでは、その目的に特化した署名アルゴリズムを提供します。次のオブジェクト識別子と署名値を使用して、この署名タイプを識別します。
id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2}
NoSignatureValue ::= OCTET STRING
The parameters for id-alg-noSignature MUST be present and MUST be encoded as NULL. NoSignatureValue contains the hash of the certification request. It is important to realize that there is no security associated with this signature type. If this signature type is on a certification request and the Certification Authority policy requires proof-of-possession of the private key, the POP mechanism defined in Section 6.7 MUST be used.
id-alg-nosignatureのパラメーターは存在する必要があり、nullとしてエンコードする必要があります。nosignaturevalueには、認証要求のハッシュが含まれています。この署名タイプに関連するセキュリティがないことを認識することが重要です。この署名タイプが認証要求に基づいており、認定機関のポリシーが秘密鍵の入金の証明を必要とする場合、セクション6.7で定義されているポップメカニズムを使用する必要があります。
Authors' Addresses
著者のアドレス
Jim Schaad Soaring Hawk Consulting PO Box 675 Gold Bar, WA 98251
Jim Schaad Soaring Hawk Consulting Po Box 675 Gold Bar、WA 98251
Phone: (425) 785-1031 EMail: jimsch@nwlink.com
電話：（425）785-1031メール：jimsch@nwlink.com
Michael Myers TraceRoute Security, Inc.
MichaelMyers Traceroute Security、Inc。
EMail: mmyers@fastq.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。