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)
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:
この文書では、CMCのための基本構文は、暗号メッセージ構文（CMS）を使用して、証明書管理プロトコルを定義します。このプロトコルは、インターネット公開鍵インフラストラクチャ（PKI）コミュニティ内の二つの当面のニーズに対処します。
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:
この文書では、CMCのための基本構文は、暗号メッセージ構文（CMS）を使用して、証明書管理プロトコルを定義します。このプロトコルは、インターネットPKIコミュニティ内の二つの当面のニーズに対処します。
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＃7に続いてPKCS＃10証明書要求の現在の業界慣行をサポートしている必要があります。
The protocol must easily support the multi-key enrollment protocols required by S/MIME and other groups.
プロトコルは、簡単にS / MIMEおよび他のグループによって要求されるマルチキー登録プロトコルをサポートしている必要があります。
The protocol must supply a way of doing all enrollment operations in a single round-trip. When this is not possible the number of round-trips is to be minimized.
プロトコルは、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.
プロトコルがproof-の所持（POP）メソッドを含んでいなければなりません。必要に応じて複数のラウンドトリップPOPのオプション条項が行われます。
The protocol must support deferred and pending responses to enrollment requests for cases where external procedures are required to issue a certificate.
プロトコルは、外部プロシージャが証明書を発行するために必要とされている例の登録要求に延期、保留中の応答をサポートしている必要があります。
The protocol must support arbitrary chains of Registration Authorities (RAs) as intermediaries between certification requesters and Certification Authorities (CAs).
プロトコルは、認証要求者と証明機関（CA）との間に仲介者としての登録局（RA）の任意のチェーンをサポートしている必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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].
私たちは、文書のレイアウトの大幅な見直しを行っています。これは、二つの異なるステップを含みます。第一に、私たちは、ドキュメントからのいくつかのセクションを削除し、他の二つの文書にそれらを動かしました。私たちのメッセージを転送する方法については、現在、[CMC-TRANS]で発見されています。制御し、この文書のセクションでは、アルゴリズムが要求されるとともに実施されなければならない情報は、現在[CMC-COMPL]に見出すことができます。
A number of new controls have been added in this version:
新しいコントロールの数は、このバージョンで追加されました。
Extended CMC Status Info Section 6.1.1
拡張CMCステータス情報6.1.1項
Publish Trust Anchors Section 6.15
トラストアンカーセクション6.15を公開
Authenticate Data Section 6.16
認証データセクション6.16
Batch Request and Response Processing Section 6.17
バッチリクエストとレスポンスの処理セクション6.17
Publication Information Section 6.18
文献情報セクション6.18
Modify Certification Request Section 6.5.1
認証要求部6.5.1を変更
Control Processed Section 6.19
制御加工断面6.19
Identity Proof Section 6.2.2
アイデンティティ証明6.2.2項
Identity POP Link Witness V2 Section 6.3.1.1
アイデンティティPOPリンク証人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登録トランザクションは、一般的に、メッセージの1回のラウンドトリップで構成されています。最も単純なケース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要求：1つの以上のPKCS＃10、CRMFまたはその他の要求メッセージの構造はPKIDataの一部としてCMSのカプセル化に包まれました。
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.)
特別なサービスは、更新のいずれかのために提供されていない（つまり、新しい同じキーを持つ証明書）またはリキー（すなわち、新しいキーを持つ新しい証明書）クライアント証明書の。身元証明が信頼できるCAから、既存の証明書によって供給されていることを除き、代わりにリニューアルし、リキーの要求は、任意の認証要求と同じに見えます（これは通常、同じ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.
特別なサービスは、再入力要求と（一般的に、新たな目的のために）新しい証明書要求を区別するために提供されていません。証明書を非公開にするための制御は、通常、鍵更新要求に含まれることになる、と新しい証明書要求では省略すること。 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要求の第二の層でそれらをラップして、CAににこの新しい拡張されたPKI要求を渡すことによって、プロトコルに参加するために提供が存在します
This specification makes no assumptions about the underlying transport mechanism. The use of CMS does not imply an email-based transport. Several different possible transport methods are defined in [CMC-TRANS].
この仕様は、下位のトランスポートメカニズムを想定していません。 CMSを使用すると、電子メールベースの輸送を意味するものではありません。いくつかの異なる可能な輸送方法が[CMC-TRANS]で定義されています。
Optional services available through this specification are transaction management, replay detection (through nonces), deferred certificate issuance, certificate revocation requests and certificate/certificate revocation list (CRL) retrieval.
この仕様を介して利用可能なオプションサービスは、トランザクション管理、（ナンスを介して）リプレイ検出、繰延証明書発行、証明書失効要求および証明書/証明書失効リスト（CRL）取得されています。
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はエンドエンティティと認証局の間に存在することができます。 RAは、このようなキー生成やキーのアーカイブなどの追加サービスを行うことができます。この文書では、RAやLRAの両方のための長期的なRAを使用しています。
Certification Authority (CA) refers to the entity that issues certificates.
認証局（CA）が証明書を発行するエンティティを指します。
Client refers to an entity that creates a PKI Request. In this document, both RAs and EEs can be clients.
クライアントは、PKI要求を作成したエンティティを指します。この文書では、RasおよびEEの両方がクライアントにすることができます。
Server refers to the entities that process PKI Requests and create PKI Responses. In this document, both CAs and RAs can be servers.
Serverは、PKIの要求を処理し、PKI応答を作成するエンティティを指します。このドキュメントでは、CAおよびRAの両方をサーバーにすることができます。
PKCS #10 refers to the Public Key Cryptography Standard #10 [PKCS10], which defines a certification request syntax.
PKCS＃10証明書要求の構文を定義する公開鍵暗号規格＃10 [PKCS10]を指します。
CRMF refers to the Certificate Request Message Format RFC [CRMF]. CMC uses this certification request syntax defined in this document as part of the protocol.
CRMFは、証明書要求メッセージ形式のRFC [CRMF]を参照します。 CMCは、プロトコルの一部として、このドキュメントで定義されたこの証明書要求の構文を使用しています。
CMS refers to the Cryptographic Message Syntax RFC [CMS]. This document provides for basic cryptographic services including encryption and signing with and without key management.
CMSは、暗号メッセージ構文RFC [CMS]を指します。この文書では、とし、鍵管理なしの暗号化と署名などの基本的な暗号化サービスを提供します。
PKI Request/Response refers to the requests/responses described in this document. PKI Requests include certification requests, revocation requests, etc. PKI Responses include certs-only messages, failure messages, etc.
PKI要求/応答は、この文書で説明要求/応答を指します。 PKI要求は、PKI応答が本命のみのメッセージ、障害メッセージ、などが含まれるなど、認証要求、取り消し要求を含み、
Proof-of-Identity refers to the client proving they are who they say that they are to the server.
実証のアイデンティティは、彼らが、彼らは、サーバーにあることを言う人です証明するクライアントを指します。
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:
プルーフ・オブ・持ち手（POP）は、公開鍵に対応する秘密鍵を所有しており、エンドエンティティによって使用することができることを証明するために使用することができる値です。 POPの異なるタイプは次のとおりです。
Signature provides the required POP by a signature operation over some data.
署名は、いくつかのデータに対する署名操作によって必要なPOPを提供します。
Direct provides the required POP operation by an encrypted challenge/response mechanism.
直接には暗号化されたチャレンジ/レスポンスメカニズムによって必要なPOP操作を提供します。
Indirect provides the required POP operation by returning the issued certificate in an encrypted state. (This method is not used by CMC.)
間接的には、暗号化された状態で発行された証明書を返すことによって、必要なPOP操作を提供します。 （この方法は、CMCによって使用されません。）
Publish provides the required POP operation by providing the private key to the certificate issuer. (This method is not currently used by CMC. It would be used by Key Generation or Key Escrow extensions.)
公開証明書発行者の秘密鍵を提供することにより、必要なPOP操作を提供します。 （このメソッドは、現在、CMCで使用されていません。これは、鍵生成や鍵の預託拡張によって使用されます。）
Attested provides the required POP operation by allowing a trusted entity to assert that the POP has been proven by one of the above methods.
証明は、信頼されたエンティティがPOPは、上記のいずれかの方法で証明されていることを主張できるようにすることで、必要なPOP動作を提供します。
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.
PKI要求の2つのタイプがあり。このセクションでは、両方のタイプの詳細が表示されます。
A Simple PKI Request uses the PKCS #10 syntax CertificationRequest [PKCS10].
シンプルなPKI要求は、PKCS＃10構文CertificationRequest [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).
秘密鍵が署名の何らかのタイプ（すなわち、ディフィー・ヘルマン（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:
クライアントはExtensionReq属性としてPKCS＃10に基づいて、すべての証明書要求内の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拡張を処理できるように要求されない、また彼らは、専用の拡張機能を処理できるように要求されています。サーバは、証明書の中に、すべてのクライアントが要求した拡張を置く必要はありません。サーバは、クライアントが要求した拡張子を変更することが許可されています。クライアントが要求した拡張子の本来の意図を無効にするように、サーバーは、拡張子を変更してはなりません。 （例えば、デジタル署名にするKeyAgreementからキー使用法を変更する。）の認証要求が拒否された場合により要求された拡張およびPKIレスポンスを扱うことができないことに返され、サーバは値を持つCMCFailInfo値を持つPKI応答を返さなければなりませんunsupportedExt 。
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（3.2.1）のカプセル化されたコンテンツタイプでのSignedData又はAuthenticatedDataのいずれかにカプセル化されます。
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のsubjectKeyIdentifier形態が使用されなければなりません。
c. The value of the subjectKeyIdentifier form of SignerInfo MUST be the Subject Key Identifier specified in the corresponding certification request. (The subjectKeyIdentifier form of SignerInfo is used here because no certificates have yet been issued for the signing key.) If the request key is used for signing, there MUST be only one SignerInfo in the SignedData.
C。 SignerInfoのsubjectKeyIdentifierフォームの値は、対応する認証要求で指定されたサブジェクト鍵識別子でなければなりません。 （証明書がまだ署名鍵のために発行されていないためのSignerInfoのsubjectKeyIdentifierフォームがここで使用されます。）要求キーが署名に使用されている場合は、SignedDataの中に一つだけのSignerInfoがあるに違いありません。
If AuthenticatedData is used, then:
認証されたデータが使用されている場合は、次のようになります。
a. The Password Recipient Info option of RecipientInfo MUST be used.
A。 RecipientInfoのパスワード受信者Infoオプションを使用しなければなりません。
b. A randomly generated key is used to compute the Message Authentication Code (MAC) value on the encapsulated content.
B。ランダムに生成された鍵は、カプセル化されたコンテンツ上のメッセージ認証コード（MAC）値を計算するために使用されます。
c. The input for the key derivation algorithm is a concatenation of the identifier (encoded as UTF8) and the shared-secret.
C。キー導出アルゴリズムの入力は、（UTF8としてエンコード）識別子と共有秘密の連結です。
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。 CAとRAは使用署名証明書の追加の制限を課すことができます。彼らは、クライアントのための最も最近発行された署名証明書を使用することを要求することができます。
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.
controlSequenceは、コントロールのシーケンスです。この文書で定義されたコントロールは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は、認証要求のシーケンスです。認証要求はCertificationRequest（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.
cmsSequenceは[CMS]メッセージオブジェクトの配列です。詳細については、セクション3.2.1.3を参照してください。
otherMsgSequence is a sequence of arbitrary data objects. Data objects placed here are referred to by one or more controls. This allows for controls to use large amounts of data without the data being embedded in the control. See Section 3.2.1.4 for more details.
otherMsgSequenceは、任意のデータオブジェクトのシーケンスです。ここに置かれたデータオブジェクトは、一の以上のコントロールによって参照されています。コントロールは、データがコントロールに埋め込まれることなく、大量のデータを使用するためにこれができます。詳細は、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を参照）RASがPKIDataのcmsSequenceに受信PKI要求を配置することが期待されています。
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.
reqSequence 2.アイテムはコントロールによって参照されていません。認証要求されているこれらの項目は、また、処理される必要があります。コントロールと同じように、適切な処理が即時処理以降の処理のための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のcmsSequence又はotherMsgSequenceメンバーのために必要とされません。この場合、cmsSequenceとotherMsgSequenceメンバーは無視されます。
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.
attrValues制御処理に使用されるデータ値です。データの構造は、特定の制御に依存しています。
The final server MUST fail the processing of an entire PKIData if any included control is not recognized, that control is not already marked as processed by a Control Processed control (see Section 6.19) and no other error is generated. The PKI Response MUST include a CMCFailInfo value with the value badRequest and the bodyList MUST contain the bodyPartID of the invalid or unrecognized control(s). A server is the final server if and only if it is not passing the PKI Request on to another server. A server is not considered to be the final server if the server would have passed the PKI Request on, but instead it returned a processing error.
コントロール処理された制御によって処理されるような任意の制御が含まれている場合、最終的なサーバーが認識されない全体PKIDataの処理を失敗しなければなりません、その制御が既にマークされていない（セクション6.19を参照）、他のエラーが発生しません。 PKI応答badRequest及びバディリストが無効または認識されないコントロール（単数または複数）のbodyPartIDを含まなければならない値と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は、外部で定義された証明書要求です。一つの例は、属性証明書要求です。この構造体のフィールドは、次のとおりです。
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製品は、認証要求を受信すると、被写体の名前を割り当てるための情報の中央レポジトリを使用して操作されます。この動作モードに対応するために、CertificationRequestにおけるサブジェクトフィールドは、nullの場合もあるが、存在しなければなりません。 NULLサブジェクトフィールドでCertificationRequestを受け取るCAは、このような証明書の要求を拒否することがあります。拒否され、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の中の公開鍵フィールドの両方が定義されなければなりません。サブジェクトフィールドは、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の間接的な方法は、このプロトコルでサポートされていません。 （本書では説明直接法を含む）、他のいずれかの方法を使用しなければなりません。 SubsequentMessageでencrCertの値を使用してはいけません。
Since the subject and publicKeyValues are always present, the POPOSigningKeyInput MUST NOT be used when computing the value for POPSigningKey.
主題とpublicKeyValuesが常に存在するためPOPSigningKeyの値を計算するとき、POPOSigningKeyInputを使用してはいけません。
A server is not required to use all of the values suggested by the client in the CRMF certification request. Servers MUST be able to process all extensions defined, but not prohibited in [PKIXCERT]. Servers are not required to be able to process other X.509v3 extensions transmitted using this protocol, nor are they required to be able to process private extensions. Servers are permitted to modify client-requested extensions. Servers MUST NOT alter an extension so as to invalidate the original intent of a client-requested extension. (For example, change key usage from keyAgreement to digitalSignature.) If a certification request is denied due to the inability to handle a requested extension, the server MUST respond with a Full PKI Response with a CMCFailInfo value with the value of unsupportedExt.
サーバはCRMF証明書要求でクライアントによって提案されたすべての値を使用する必要はありません。サーバーは、定義されたすべての拡張機能を処理できますが、[PKIXCERT]で禁止されていないしなければなりません。サーバーは、このプロトコルを使用して送信される他のX.509v3拡張を処理できるように要求されない、また彼らは、専用の拡張機能を処理できるように要求されています。サーバは、クライアントが要求した拡張子を変更することが許可されています。クライアントが要求した拡張子の本来の意図を無効にするように、サーバーは、拡張子を変更してはなりません。 （例えば、デジタル署名にするKeyAgreementからキー使用法を変更してください。）認証要求が要求された拡張子を扱うことができないことが原因で拒否された場合、サーバはunsupportedExtの値を持つ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メッセージのcmsSequenceフィールドは、ゼロ個以上のタグ付けされたコンテンツ情報オブジェクトが含まれています。このような構造の構文は次のとおりです。
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].
cmsSequenceで使用される4つのコンテンツタイプはAuthenticatedData、データ、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).
暗号化されたPOP制御にPOPの証明のために暗号化されたランダム値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の上の復号化に失敗した場合は、完全なPKI応答badMessageCheckのCMCFailInfo値と0のbodyPartIDで返されます。
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要求/応答処理の一環として、署名（S）を検証しなければなりません。署名が検証されないとPKIのリクエスト/レスポンスがCMCステータス情報制御以外のものが含まれている場合は、CMCのステータス情報の制御を含む完全なPKI応答はbadMessageCheckの値と0のbodyPartIDで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要求/応答のotherMsgSequenceフィールドは、PKIの要求/応答の一部として実施される任意のデータオブジェクトを可能にします。これは、すでにcmsSequenceフィールド（セクション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).
本体部の識別子は（TaggedRequestで）CertReqMsgオブジェクトに対するcertReqIdsフィールドまたは他のオブジェクトのbodyPartIDフィールドに符号化されます。ボディ部分識別子は、単一のPKIDataまたはPKIResponse内で一意でなければなりません。本体部の識別子は（例えば、別の中に埋め込まれPKIData）異なる層に複製することができます。
The bodyPartID value of 0 is reserved for use as the reference to the current PKIData object.
0のbodyPartID値は、現在のPKIDataオブジェクトへの参照として使用するために予約されています。
Some controls, such as the Add Extensions control (Section 6.5.2), use the body part identifier in the pkiDataReference field to refer to a PKI Request in the current PKIData. Some controls, such as the Extended CMC Status Info control (Section 6.1.1), will also use body part identifiers to refer to elements in the previous PKI Request/
そのような拡張コントロールを追加します（6.5.2項）などの一部のコントロールは、現在のPKIDataにおけるPKI要求を参照するためにpkiDataReferenceフィールドにボディ部の識別子を使用しています。こうした拡張CMCステータス情報制御などの一部のコントロール、（6.1.1項）が、また以前のPKI要求内の要素を参照するために、本体部の識別子を使用します/
Response. This allows an error to be explicit about the control or PKI Request to which the error applies.
応答。これは、エラーはエラーが適用される制御または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は次のように定義されています。
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符号なしデータでは、この問題のアドレスを属性。
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符号なしデータ属性は、直接クライアントによって署名されていない情報が含まれています。 RAは、それが集約されたリクエストの符号なしまたは未認証の属性フィールドに、この属性を検出すると、CMC符号なしデータ属性は前cmsSequenceに要求を置くことへの要求から除去し、RAの署名の符号なしまたは未認証の属性に置かれていますまたはデータラッパを認証されました。
The CMC Unsigned Data attribute is identified by:
CMC符号なしデータ属性はによって識別されます。
id-aa-cmc-unsignedData OBJECT IDENTIFIER ::= {id-aa 34}
The CMC Unsigned Data attribute has the ASN.1 definition:
CMC符号なしデータ属性は、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又はAuthenticatedDataのデータをラップの一部として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.
SignerInfoのUnsignedAttributeシーケンスまたはAuthenticatedDataのUnauthenticatedAttribute順に最大1つのCMC符号なしデータ属性があるに違いありません。 UnsignedAttributeは、値のセットで構成され、属性は、そのセットでゼロより大きい任意の数の値を持つことができます。 CMC符号なしデータ属性が1のSignerInfoかAuthenticatedDataであれば、それはすべてのSignerInfoとAuthenticatedDataの項目に同じ値（S）が表示されなければなりません。
Two types of PKI Responses exist. This section gives the details on both types.
PKI応答の2つのタイプがあり。このセクションでは、両方のタイプについての詳細を提供します。
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の応答なしEncapsulatedContentInfoなしの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応答PKIResponseコンテンツタイプをカプセル化するのSignedDataかAuthenticatedDataで構成されています。 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を返してもよいです。サーバーは、自己署名証明書を含むかもしれません。クライアントは、暗黙のうちに過ぎないため、証明書袋でのプレゼンスに含まれる自己署名証明書を信頼してはなりません。イベントでは、クライアントがサーバから新しい自己署名証明書を受け取り、クライアントが明示的に信頼アンカーとして証明書を使用することを可能にするメカニズムを提供することができます。 （トラストアンカー証明書の配布を可能にする目的のために存在します（セクション6.15）トラストアンカーコントロールを公開します。信頼できるアンカーが新しい信頼できるアンカーを発行した場合、これは新しいトラストアンカーの自動化された信頼が許可される可能性があるケースです。）
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.
controlSequenceは、コントロールのシーケンスです。この文書で定義されたコントロールは6コントロールは、他の当事者によって定義することができ、セクションに記載されています。 TaggedAttribute構造の詳細は、3.2.1.1項に記載されています。
cmsSequence is a sequence of [CMS] message objects. See Section 3.2.1.3 for more details.
cmsSequenceは[CMS]メッセージオブジェクトの配列です。詳細については、セクション3.2.1.3を参照してください。
otherMsgSequence is a sequence of arbitrary data objects. Data objects placed here are referred to by one or more controls. This allows for controls to use large amounts of data without the data being embedded in the control. See Section 3.2.1.4 for more details.
otherMsgSequenceは、任意のデータオブジェクトのシーケンスです。ここに置かれたデータオブジェクトは、一の以上のコントロールによって参照されています。コントロールは、データがコントロールに埋め込まれることなく、大量のデータを使用するためにこれができます。詳細は、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のcmsSequence又はotherMsgSequenceメンバーのために必要とされません。この場合、cmsSequenceとotherMsgSequenceメンバーは無視されることになります。
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の要求と応答を暗号化するための手段を説明します。 cmsSequenceフィールドに配置されている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:
機密性は、EnvelopedDataでPKI要求/応答（のSignedData）を包むことによって提供されます。 EnvelopedDataでネストされたコンテンツタイプは、ID-のSignedDataです。これは暗号化され署名されたデータとの間に配置されたMIMEの層が存在するS / MIMEとは異なることに留意されたいです。 EnvelopedDataの層はPKI要求/応答に適用された場合、第2の署名層をEnvelopedDataの層の外側に配置することが推奨されます。次の図は、このネストが行われることになる方法を示しています。
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のリクエストを処理することができない限り、PKI要求を拒否するかもしれ復号化することはできませんPKI要求を受けたRA（すなわち、それがないすべては、複数の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要求を保護するために、新たなEnvelopedDataの層を適用することができます。第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として符号化される（処理システムは、第一OID（TaggedAttribute ATTRTYPEを検出するであろう。データの符号化が制御に基づいている。セクション3.2.1.1の構文を参照）、対応する処理メッセージ本文を処理する前に、制御値（TaggedAttributeのattrValues）。
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の単一の整数でBodyPartReferenceのbodyPartID選択です。
statusString contains additional description information. This string is human readable.
statusStringは、追加の説明情報が含まれています。この文字列は、人間が読める形式です。
otherInfo contains additional information that expands on the CMC status code returned in the cMCStatus field.
otherInfoはcMCStatusフィールドに返さCMCステータスコードを拡張し、追加の情報が含まれています。
The fields in OtherStatusInfo have the following meaning:
OtherStatusInfoのフィールドは以下の意味があります。
failInfo is described in Section 6.1.4. It provides an error code that details what failure occurred. This choice is present only if cMCStatus contains the value failed.
failInfoは、セクション6.1.4に記載されています。これは、何が起こったか、障害の詳細エラーコードを提供します。この選択はcMCStatusが失敗した値が含まれている場合にのみ存在しています。
pendInfo contains information about when and how the client should request the result of this request. It is present when the cMCStatus is either pending or partial. pendInfo uses the structure PendInfo, which has the fields:
pendInfoは、クライアントがこの要求の結果を要求しなければならない時期と方法に関する情報が含まれています。 cMCStatusが保留中または部分的のいずれかであるとき、それは存在しています。 pendInfoは、フィールドを持つ構造PendInfoを、使用しています。
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値を仮定することができます。このフィールドは、タイプExtendedFailInfoを使用しています。 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は、Extended 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.
confirmRequiredは、証明書を使用する前に返却しなければならないことを確認し、証明書受理制御（セクション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は、Extended 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.
badAlgは認識されていないか、サポートされていないアルゴリズムを示しています。
badMessageCheck indicates integrity check failed.
badMessageCheckは、整合性チェックが失敗したことを示します。
badRequest indicates transaction was not permitted or supported.
badRequestは、トランザクションを許可するか、サポートされなかったことを示します。
badTime indicates message time field was not sufficiently close to the system time.
BADTIMEは、メッセージの時間フィールドはシステム時刻に十分近いれなかったことを示します。
badCertId indicates no certificate could be identified matching the provided criteria.
badCertIdには証明書が提供さ条件に一致する識別することはできなかった示しています。
unsupportedExt indicates a requested X.509 extension is not supported by the recipient CA.
unsupportedExtは、要求されたX.509拡張は、受信者のCAによってサポートされていないことを示します
mustArchiveKeys indicates private key material must be supplied.
mustArchiveKeysは、秘密鍵の材料を供給する必要がありますを示しています。
badIdentity indicates identification control failed to verify.
badIdentity識別制御が検証に失敗を示しています。
popRequired indicates server requires a POP proof before issuing certificate.
popRequiredは、サーバーが証明書を発行する前にPOPの証明が必要なことを示します。
popFailed indicates POP processing failed.
popFailedは、POP処理が失敗したことを示します。
noKeyReuse indicates server policy does not allow key reuse.
noKeyReuseは、キーの再利用を許可しないサーバーポリシーを示します。
internalCAError indicates that the CA had an unknown internal failure.
internalCAErrorは、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ステータス情報制御にExtendedFailureInfoアイテムを使用すべきです。しかし、閉じられた環境のために、彼らはこのタイプを使用して定義することができます。そのようなコードは、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].
一部のCAとRAは実証の身元を認証要求に含まれている必要があります。これを行うためのさまざまな方法は、セキュリティと信頼性の異なる程度で存在しています。大半は身元証明の形態としてあなたの母親の旧姓を提供するために、銀行の要求に精通しています。プルーフ・オブ・アイデンティティを必要とするの背後にある理由は、[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は、クライアント/サーバ共有秘密に基づいて、クライアントの身元を証明するための方法を提供します。クライアントは完全な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項）を提供します。このコントロールは、サーバーにある状態にクライアントを許可するための簡単な方法です。一般的には、秘密共有し、その共有秘密の識別子は、サーバからクライアントに渡されます。識別子は、識別制御に配置され、共有秘密は、アイデンティティ証明コントロールを計算するために使用されます。
The Identity Proof Version 2 control is identified by the OID:
アイデンティティ証明バージョン2制御はOIDで識別されます。
id-cmc-identityProofV2 ::= { id-cmc 34 }
The Identity Proof Version 2 control has the ASN.1 definition:
アイデンティティ証明バージョン2制御は、ASN.1定義があります。
IdentifyProofV2 ::= SEQUENCE {
hashAlgID AlgorithmIdentifier,
macAlgID AlgorithmIdentifier,
witness OCTET STRING
}
｝
The fields of IdentityProofV2 have the following meaning:
IdentityProofV2のフィールドは以下の意味があります。
hashAlgID is the identifier and parameters for the hash algorithm used to convert the shared-secret into a key for the MAC algorithm.
hashAlgIDはMACアルゴリズムのキーに共有秘密を変換するために使用されるハッシュアルゴリズムの識別子とパラメータです。
macAlgID is the identifier and the parameters for the message authentication code algorithm used to compute the value of the witness field.
macAlgID識別子と証人フィールドの値を計算するために使用されるメッセージ認証コードのアルゴリズムのためのパラメータです。
witness is the identity proof.
目撃者は、身元証明です。
The required method starts with an out-of-band transfer of a token (the shared-secret). The shared-secret should be generated in a random manner. The distribution of this token is beyond the scope of this document. The client then uses this token for an identity proof as follows:
必要な方法は、トークン（共有秘密）のアウトオブバンド転送始まります。共有秘密は、ランダムに生成されなければなりません。このトークンの分布は、このドキュメントの範囲を超えています。次のようにクライアントは、身元証明のために、このトークンを使用しています。
1. The PKIData reqSequence field (encoded exactly as it appears in the Full PKI Request including the sequence type and length) is the value to be validated.
1. PKIData reqSequenceフィールドは、（それが配列の型と長さを含む完全な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. A MACは、メッセージとキーとして工程2からの値としてステップ1で得た値を用いて計算されます。
4. The result from Step 3 is then encoded as the witness value in the Identity Proof Version 2 control.
4.ステップ3からの結果は、次いで、アイデンティティ証明バージョン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.
サーバはアイデンティティ証明バージョン2コントロールを検証すると、それは同じようにMAC値を計算し、PKI Requestに含まれている証人値と比較します。
If a server fails the verification of an Identity Proof Version 2 control, the CMCFailInfo value MUST be present in the Full PKI Response and MUST have a value of badIdentity.
サーバはアイデンティティ証明バージョン2制御の検証に失敗した場合、CMCFailInfo値は全PKIレスポンス内に存在しなければならないとbadIdentityの値を持たなければなりません。
Reuse of the shared-secret on certification request retries allows the client and server to maintain the same view of acceptable identity proof values. However, reuse of the shared-secret can potentially open the door for some types of attacks.
証明書要求の再試行の共有秘密の再利用は、クライアントとサーバーが許容身元証明の値の同じビューを維持することができます。しかし、共有秘密の再利用は、潜在的な攻撃のいくつかのタイプの扉を開くことができます。
Implementations MUST be able to support tokens at least 16 characters long. Guidance on the amount of entropy actually obtained from a given length token based on character sets can be found in Appendix A of [PASSWORD].
実装は、少なくとも16文字の長トークンをサポートすることができなければなりません。実際の文字セットに基づいて、所定の長さトークンから得られたエントロピーの量に関するガイダンスは、[パスワード]の付録Aに見出すことができます。
The Identity Proof control is identified by the OID:
アイデンティティ証明制御はOIDで識別されます。
id-cmc-identityProof ::= { id-cmc 3 }
The Identity Proof control has the ASN.1 definition:
アイデンティティ証明コントロールは、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.
この制御はアイデンティティ証明バージョン2コントロールと同じように処理されます。この場合には、ハッシュアルゴリズムは、SHA1に固定され、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.
必要に応じて、サーバは、識別証明コントロールで保護されていない識別制御の包含を必要とする場合があります。識別制御はアイデンティティ証明コントロールの内容を検証するために必要な共有秘密を見つけるには、サーバーを支援するテキスト文字列を含むように意図されます。識別制御をフルPKI要求に含まれている場合、（セクション6.2.1から）ステップ2における鍵の導出は、タイプすることなく共有秘密の連結のハッシュとUTF8アイデンティティ値（そのように変更されます長さバイトは）ちょうど共有秘密ではなく、ハッシュ化されています。
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要求では、クライアントに関するID情報は、認証要求のすべてを含むの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.
暗号共有秘密から導出さ証人値（セクション6.3.1.3）と共有秘密/サブジェクト識別名（DN）マッチング（セクション6.3.2）：このセクションでは、アイデンティティおよびPOP情報を連結するための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).
同一性およびPOP情報を結ぶ第一の技術は、暗号各証明要求（PKCS＃10またはCRMF）内の符号付き拡張として共有秘密から得られる情報の一部を含むようにクライアントを強制します。
The POP Link Witness Version 2 control is identified by the OID:
POPリンク証人バージョン2制御はOIDで識別されます。
id-cmc-popLinkWitnessV2 ::= { id-cmc 33 }
The POP Link Witness Version 2 control has the ASN.1 definition:
POPリンク証人バージョン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:
ヌル被写体のDNが使用される場合、この技術は、（例えば、サーバのみ共有秘密に基づいて証明書のサブジェクトDNを生成することができ、ため）に有用です。クライアントがサーバからのアウトオブバンド共有秘密を受信したときに処理が開始されます。次に、クライアントは、次の値を計算します。
1. The client generates a random byte-string, R, which SHOULD be at least 512 bits in length.
1.クライアントは、長さが少なくとも512ビットであるべきであるランダムなバイト列、Rを生成します。
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. A MACは、ステップ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で製造したランダム値がPOPリンクランダムコントロールの値として符号化されます。このコントロールは、完全な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値がPOPリンク証人制御又はPOPリンク証人V2制御の証人フィールドのいずれかに配置されます。
* For CRMF, the POP Link Witness/POP Link Witness V2 control is
included in the controls field of the CertRequest structure.
* 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のリンク証人/ POPリンク証人V2制御がCertificationRequestInfo構造の属性フィールドに含まれています。
Upon receipt, servers MUST verify that each certification request contains a copy of the POP Link Witness/POP Link Witness V2 control and that its value was derived using the above method from the shared-secret and the random string included in the POP Link Random control.
受信すると、サーバは各認証要求はPOPリンク証人/ POPリンク証人V2コントロールのコピーが含まれていることと、その値が共有秘密から、上記の方法やPOPリンクランダムコントロールに含まれてランダムな文字列を使用して誘導されたことを確かめなければなりません。
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:
POPリンク証人制御はOIDで識別されます。
id-cmc-popLinkWitness ::= { id-cmc 23 }
The POP Link Witness control has the ASN.1 definition:
POPリンク証人制御は、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:
POPリンクランダム制御はOIDで識別されます。
id-cmc-popLinkRandom ::= { id-cmc 22 }
The POP Link Random control has the ASN.1 definition:
POPリンクランダム制御は、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.)
同一性およびPOP情報をリンクする第二の技術は、帯域外に分散され、身元を証明するために共有秘密を使用して、クライアントが正確なことを含むことを必要とする共有秘密を特定の対象の識別名（サブジェクト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を生成する場合次のように要求、それはこの二つの情報を使用する必要があります。
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）またはアイデンティティ証明バージョン共有秘密由来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.
更新を行っているか、証明書要求をリキーすると、アイデンティティとPOP情報をリンクするのは簡単です。クライアントのコピーを作られて、各証明書の要求のサブジェクト名フィールドに現在の署名証明書のサブジェクトDN。各証明書の要求のためのPOPは今、その情報をカバーします。最外署名層は、元のアイデンティティが証明要求に関連付けることができ、現在の署名証明書を使用して作成されます。現在の署名証明書と証明書要求の試合で名に名前ので、必要なリンクが達成されています。
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.
データリターンコントロールは、クライアントがサーバに任意のデータ（内部状態情報の通常いくつかの種類）を送信するとFull PKI応答の一部として返されたデータを持つことができます。データリターンコントロールに配置されたデータはサーバに不透明であると考えられています。同様の制御が完全なPKI要求と応答の両方のために使用されています。データ復帰制御が完全なPKI Requestに表示された場合、サーバーは、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は、証明書の任意のフィールドを交換するか、削除することができます。第二の制御は、拡張機能（6.5.2項）を追加し、唯一の拡張機能を追加できます。
The Modify Certification Request control is used by RAs to change fields in a requested certificate.
変更証明書要求の制御が要求された証明書のフィールドを変更するためのRAで使用されています。
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配列の各BodyPartIDはCertReqMsg（CRMF）内TaggedCertificationRequest（PKCS＃10）のbodyPartID又はcertrequestコマンドのcertReqIdいずれかに等しくなければなりません。定義では、証明書拡張はcertReferencesシーケンスで参照されているすべての認証要求に適用されているCertTemplateのフィールドに含まれています。 bodyPartIDに対応するリクエストが見つからない場合は、badRequestの値を持つCMCFailInfoは、このコントロールその参照が返されます。
replace specifies if the target certification request is to be modified by replacing or deleting fields. If the value is TRUE, the data in this control replaces the data in the target certification request. If the value is FALSE, the data in the target certification request is deleted. The action is slightly different for the extensions field of certTemplate; each extension is treated individually rather than as a single unit.
ターゲット証明書要求は、交換またはフィールドを削除することによって変更される場合は指定を交換してください。値がTRUEの場合、このコントロールのデータは、ターゲット証明書要求内のデータを置き換えます。値がFALSEの場合、対象の証明書要求のデータが削除されます。アクションはCertTemplateのの拡張フィールドに少し異なります。各拡張はなく、単一のユニットとしてより個別に処理されます。
certTemplate is a certificate template object [CRMF]. If a field is present and replace is TRUE, it replaces that field in the certification request. If the field is present and replace is FALSE, the field in the certification request is removed. If the field is absent, no action is performed. Each extension is treated as a single field.
CertTemplateの証明書テンプレートオブジェクト[CRMF]です。フィールドが存在し、置き換えるTRUEであれば、証明書要求にそのフィールドを置き換えます。フィールドが存在し、置き換えるFALSEであれば、証明書要求のフィールドが削除されます。フィールドが存在しない場合は、何もアクションは実行されません。各拡張は、単一のフィールドとして扱われます。
Servers MUST be able to process all extensions defined, but not prohibited, in [PKIXCERT]. Servers are not required to be able to process every X.509v3 extension transmitted using this protocol, nor are they required to be able to process other, private extensions. Servers are not required to put all RA-requested extensions into a certificate. Servers are permitted to modify RA-requested extensions. Servers MUST NOT alter an extension so as to reverse the meaning of a client-requested extension. If a certification request is denied due to the inability to handle a requested extension and a Full PKI Response is returned, the server MUST return a CMCFailInfo value with the value of unsupportedExt.
サーバは[PKIXCERT]で、すべての拡張機能が定義されていますが、禁止されていない処理できなければなりません。サーバーは、このプロトコルを使用して送信、すべてのX.509v3拡張を処理できるようにする必要はありません、また、彼らは他の、プライベート拡張を処理できるように要求されています。サーバは、証明書にすべてのRA-要求された機能拡張を置く必要はありません。サーバは、RA-要求された拡張子を変更することが許可されています。クライアントが要求した拡張子の意味を逆にするように、サーバーは、拡張子を変更してはなりません。認証要求が原因要求された拡張子を扱うことができないことに拒否され、完全な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.
制御Aが制御Bの層を含む層に存在する場合、O、換言すれば、制御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.
制御Aおよび制御Bが同じPKIData（すなわち、同じラッピング層）である場合、O、アプリケーションの順序は非確定的です。
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.
拡張機能の追加コントロールが変更証明書要求の制御のために廃止されました。拡張子以外の証明書要求のフィールドを変更することができるように、それは置き換えられました。
The Add Extensions control is used by RAs to specify additional extensions that are to be included in certificates.
追加の拡張制御は、証明書に含まれている追加の拡張子を指定するためのRAで使用されています。
The Add Extensions control is identified by the OID:
追加の拡張制御はOIDで識別されます。
id-cmc-addExtensions ::= { id-cmc 8 }
The Add Extensions control has the ASN.1 definition:
追加の拡張制御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は、埋め込まれた認証リクエストのボディ部のIDが含まれています。
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内に含まれる認証要求の一つ以上への参照のリストです。 certReferences配列の各部位識別子はTaggedCertificationRequestのbodyPartID（PKCS＃10）またはCertReqMsg内certrequestコマンドの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-要求された機能拡張を置く必要はありません。サーバは、RA-要求された拡張子を変更することが許可されています。クライアントが要求した拡張子の意味を逆にするように、サーバーは、拡張子を変更してはなりません。認証要求は要求された拡張子を処理できないことが原因で拒否され、応答が返された場合、サーバはunsupportedExtの値でCMCFailInfoを返さなければなりません。
If multiple Add Extensions controls exist in a Full PKI Request, the exact behavior is left up to the CA policy. However, it is recommended that the following policy be used. These rules would be applied to individual extensions within an Add Extensions control (as opposed to an "all or nothing" approach).
複数の拡張機能のコントロールは完全なPKI要求内に存在する追加した場合、正確な振る舞いは、CAのポリシーに委ねられています。しかし、次のポリシーを使用することをお勧めします。これらのルールは、追加の拡張コントロール内の個々の拡張機能（「オール・オア・ナッシング」のアプローチではなく）に適用されます。
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は、要求された拡張をオーバーライドすることを可能にする）が使用されるであろう。
6.6. Transaction Identifier Control and Sender and Recipient Nonce Controls
6.6. トランザクション識別子制御と送信者と受信者ナンスコントロール
Transactions are identified and tracked with a transaction identifier. If used, clients generate transaction identifiers and retain their value until the server responds with a Full PKI Response that completes the transaction. Servers correspondingly include received transaction identifiers in the Full PKI Response.
取引は、取引識別子で識別し、追跡されます。使用している場合、クライアントは、トランザクション識別子を生成し、サーバがトランザクションを完了した全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.
リプレイ保護は、送信者と受信者のナンスのコントロールを使用してサポートされています。ナンスを使用する場合、トランザクションの最初のメッセージでは、受信者ノンス制御は送信されません。送信者ナンス制御は、トランザクションオリジネータで含まれ、後で参照するために保持されています。送信者ノンス制御の受信者は、受信者ナンスコントロールとしてバック発信元に、この値を反映し、独自の送信者Nonceのコントロールが含まれています。この応答のトランザクションオリジネータによって受信すると、トランザクションオリジネータは、その保持値に受信者のノンスコントロールの値を比較します。値が一致した場合、メッセージは、さらに、セキュリティ処理のために受理することができます。送信者ノンス制御のための受信された値は、同じトランザクションに関連付けられた次のメッセージに含めるために保持されます。
The Sender Nonce and Recipient Nonce controls are identified by the OIDs:
送信者および受信者ノンスノンスコントロールはOIDにより識別されます。
id-cmc-senderNonce ::= { id-cmc 6 }
id-cmc-recipientNonce ::= { id-cmc 7 }
The Sender Nonce control has the ASN.1 definition:
送信者ナンス制御は、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の制御を含むかもしれません。メッセージが送信者ノンス制御が含まれている場合、応答は、受信者ノンスコントロールとして以前に受信された送信者ノンス制御の送信された値を含み、その送信者ノンスコントロールとして新しい値を含まなければなりません。
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方式を使用することを要求することができます。サーバーは必要なPOPがPKIData内の任意の要素のために欠落している場合PKIData内に含まれるすべての認証要求を拒否すべきです。
Many servers require proof that the entity that generated the certification request actually possesses the corresponding private component of the key pair. For keys that can be used as signature keys, signing the certification request with the private key serves as a POP on that key pair. With keys that can only be used for encryption operations, POP MUST be performed by forcing the client to decrypt a value. See Section 5 of [CRMF] for a detailed discussion of POP.
多くのサーバは、証明書要求を生成したエンティティが実際に鍵ペアの対応する秘密の成分を有することを証明する必要があります。署名鍵として使用することができる鍵のために、秘密鍵と証明書要求に署名すると、その鍵ペアにPOPとして機能します。唯一の暗号化操作のために使用することができるキーで、POPには、値を復号化するために、クライアントを強制的に実行しなければなりません。 POPの詳細な議論については、[CRMF]のセクション5を参照してください。
By necessity, POP for encryption-only keys cannot be done in one round-trip, since there are four distinct steps:
4つの別個のステップがあるので、必然的に、暗号化キーだけのための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.サーバはクライアントに提示し、公開暗号鍵で暗号化POPチャレンジを送信します。
3. Client decrypts the POP challenge using the private key that corresponds to the presented public key and sends the plaintext back to the server.
3.クライアントは、提示された公開鍵に対応し、サーバーに戻って平文を送信し、秘密鍵を使用してPOPチャレンジを復号化します。
4. Server validates the decrypted POP challenge and continues processing the certification request.
4.サーバーは、復号化されたPOPの課題を検証し、認証要求を処理し続けます。
CMC defines two different controls. The first deals with the encrypted challenge sent from the server to the user in Step 2. The second deals with the decrypted challenge sent from the client to the server in Step 3.
CMCは、二つの異なるコントロールを定義します。ステップ3で、クライアントからサーバーに送信され、復号化という課題にステップ2. 2番目の取引でユーザーにサーバーから送信された暗号化の課題と最初の取引。
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.)
暗号化されたPOPコントロールはPKIResponseの一環として、サーバからクライアントに暗号化されたチャレンジを送信するために使用されます。 （上記ステップ1で送信されたメッセージが完全PKI要求され、ステップ2における応答がPOPが明示的に必要とされることを指定CMCFailInfo含む完全なPKI応答であり、そしてencryptedPOPにPOPチャレンジを提供することと仮定されることに注意してくださいコントロール。）
The Encrypted POP control is identified by the OID:
暗号化されたPOP制御はOIDで識別されます。
id-cmc-encryptedPOP ::= { id-cmc 9 }
The Encrypted POP control has the ASN.1 definition:
暗号化されたPOP制御はASN.1定義があります。
EncryptedPOP ::= SEQUENCE {
request TaggedRequest,
cms ContentInfo,
thePOPAlgID AlgorithmIdentifier,
witnessAlgID AlgorithmIdentifier,
witness OCTET STRING
}
The Decrypted POP control is identified by the OID:
復号化されたPOP制御はOIDで識別されます。
id-cmc-decryptedPOP ::= { id-cmc 10 }
The Decrypted POP control has the ASN.1 definition:
復号化されたPOP制御はASN.1定義があります。
DecryptedPOP ::= SEQUENCE {
bodyPartID BodyPartID,
thePOPAlgID AlgorithmIdentifier,
thePOP OCTET STRING
}
The encrypted POP algorithm works as follows:
次のように暗号化されたPOPアルゴリズムは動作します：
1. The server randomly generates the POP Proof Value and associates it with the request.
1.サーバーがランダムPOP証明値を生成し、要求に関連付けます。
2. The server returns the Encrypted POP control with the following fields set:
2.サーバが設定され、次のフィールドで暗号化されたPOPコントロールを返します。
request is the original certification request (it is included
here so the client need not keep a copy of the request).
cms is an EnvelopedData, the encapsulated content type being id-data and the content being the POP Proof Value; this value needs to be long enough that one cannot reverse the value from the witness hash. If the certification request contains a
CMSはEnvelopedDataの、カプセル化されたコンテンツタイプであるIDデータとPOPプルーフ値である内容です。この値は、1つの証人ハッシュから値を元に戻すことはできませんことを十分に長くする必要があります。証明書要求が含まれている場合
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.
サブジェクト鍵識別子（SKI）拡張、その後、受信者識別子は、SKIであるべきです。 issuerAndSerialNumberフォームが使用される場合、IssuerNameはNULLと証明要求のbodyPartIDとしてのSerialNumberとして符号化されなければなりません。
thePOPAlgID identifies the algorithm to be used in computing the return POP value.
thePOPAlgID戻りPOP値を計算する際に使用するアルゴリズムを識別する。
witnessAlgID identifies the hash algorithm used on the POP Proof Value to create the field witness.
witnessAlgIDは、フィールドの証人を作成するにはPOP証拠価値に使用されるハッシュアルゴリズムを特定します。
witness is the hashed value of the POP Proof Value.
証人はPOP証拠価値のハッシュ値です。
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.クライアントはPOP証拠価値を得るために、CMSフィールドを復号化します。クライアントはwitnessAlgIDを用いてH（POP証明値）を計算し、証人の値と比較します。値が比較しないか、復号化が成功しなかった場合、クライアントは、登録プロセスを中止しなければなりません。クライアントは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の一環として、復号化されたPOPコントロールを作成します。 DecryptedPOPのフィールドは次のとおりです。
bodyPartID refers to the certification request in the new PKI
Request.
thePOPAlgID is copied from the encryptedPOP.
thePOPAlgIDはencryptedPOPからコピーされます。
thePOP contains the possession proof. This value is computed by thePOPAlgID using the POP Proof Value and the request.
thePOPは証拠所持が含まれています。この値はPOP証拠価値と要求を使用してthePOPAlgIDによって計算されます。
5. The server then re-computes the value of thePOP from its cached value and the request and compares to the value of thePOP. If the values do not match, the server MUST NOT issue the certificate. The server MAY re-issue a new challenge or MAY fail the request altogether.
5.サーバは、そのキャッシュされた値と要求からthePOPの値を再計算し、thePOPの値と比較します。値が一致しない場合、サーバーは証明書を発行してはいけません。サーバーは、新たな挑戦を再発行したり、完全に要求を失敗することがあります。
When defining the algorithms for thePOPAlgID and witnessAlgID, care must be taken to ensure that the result of witnessAlgID is not a useful value to shortcut the computation with thePOPAlgID. The POP Proof Value is used as the secret value in the HMAC algorithm and the request is used as the data. If the POP Proof Value is greater than 64 bytes, only the first 64 bytes of the POP Proof Value is used as the secret.
thePOPAlgIDとwitnessAlgIDためのアルゴリズムを定義する場合、注意がwitnessAlgIDの結果はthePOPAlgIDで計算をショートカットするための有用な値ではないことを保証するために注意しなければなりません。 POP保証値（proof value）は、HMACアルゴリズムで秘密値として使用され、要求がデータとして使用されます。 POP保証値（proof value）が64のバイトよりも大きい場合、POP保証値（proof value）の最初の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.
上記のアルゴリズムの一つの潜在的な問題は、CAが返さPOP値を確認するために維持する必要がある状態の量です。以下は、状態の量を減少させることによって問題に対処する多くの可能な方法のいずれかの値の単一（または小集合）にCAに保持記載されています。
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.
認証要求R 2.、サーバは（R、X）Y = Fを計算します。 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は、それがPOPを行っているCAに通知する方法が必要です。 RA POP証人制御は、この問題に対処しています。
The RA POP Witness control is identified by the OID:
RA POP証人制御はOIDで識別されます。
id-cmc-lraPOPWitness ::= { id-cmc 11 }
The RA POP Witness control has the ASN.1 definition:
RA POP証人制御は、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要求を含むネストされたTaggedContentInfoの身体の一部の識別子が含まれています。リクエストが現在の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がPOP検証を行うことができない場合は、popFailedの値を持つCMCFailInfoを返します。 CAは、POP自体を再確認するためのチャレンジ・レスポンスを開始してはなりません。
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.
取得証明書の制御は、証明書のリポジトリから以前に発行された証明書を取得するために使用されます。 CA、RA、または独立したサービスは、このリポジトリを提供することができます。この機能を使用することが期待クライアントが完全に展開ディレクトリが実行不可能または望ましくないのいずれかであるものです。
The Get Certificate control is identified by the OID:
取得証明書の制御はOIDで識別されます。
id-cmc-getCert ::= { id-cmc 15 }
The Get Certificate control has the ASN.1 definition:
取得証明書の管理は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.
issuerNameは、証明書発行者の名前です。
serialNumber identifies the certificate to be retrieved.
serialNumberを取得される証明書を識別する。
The server that responds to this request places the requested certificate in the certificates field of a SignedData. If the Get Certificate control is the only control in a Full PKI Request, the response should be a Simple PKI Response.
この要求に応答するサーバはSignedDataの証明書の分野で要求された証明書を配置します。取得証明書の制御が完全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.
取得CRL制御がたCRLのリポジトリからCRLを取得するために使用されます。 CA、RA、または独立したサービスは、このリポジトリを提供することができます。この機能を使用することが期待クライアントが完全に展開ディレクトリが実行不可能または望ましくないのいずれかであるものです。
The Get CRL control is identified by the OID:
ゲットCRL制御はOIDで識別されます。
id-cmc-getCRL ::= { id-cmc 16 }
The Get CRL control has the ASN.1 definition:
取得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.
issuerNameは、CRL発行者の名前です。
cRLName may be the value of CRLDistributionPoints in the subject certificate or equivalent value in the event the certificate does not contain such a value.
cRLName証明書が、そのような値が含まれていない場合に対象証明書又は同等の値でCRLDistributionPointsの値であってもよいです。
time is used by the client to specify from among potentially several issues of CRL that one whose thisUpdate value is less than but nearest to the specified time. In the absence of a time component, the CA always returns with the most recent CRL.
時間は、CRLの潜在的にいくつかの問題の中からそのthisUpdateの値よりも小さいですが、最寄りの指定した時間に1つを指定するために、クライアントによって使用されます。時間コンポーネントがない場合には、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の中から指定するために使用されます。実装者は、特定の失効要求は、単一のCRLReasonコードを有していることを心に留めなければならない - その結果、CRLのエントリは、単一のCRLReasonコード値を持っているでしょう - 単一のCRLは、一つ以上の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ののCRLの分野で要求されたCRLを配置します。取得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.
issuerNameは、失効する証明書のissuerNameです。
serialNumber is the serial number of the certificate to be revoked.
serialNumberを、失効する証明書のシリアル番号です。
reason is the suggested CRLReason code for why the certificate is being revoked. The CA can use this value at its discretion in building the CRL.
その理由は、証明書が失効されている理由のための提案CRLReasonコードです。 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は、その署名秘密鍵の使用を失った場合に、それが不可能です。取り消し要求制御は、EEがCAにEEの署名秘密鍵の使用の損失のインスタンスに代替認証サーバとして使用することができる共有秘密を送信することができます。このような行為の容認は、ローカルセキュリティポリシーの問題です。
It is possible to sign the revocation for the lost certificate with a different certificate in some circumstances. A client can sign a revocation for an encryption key with a signing certificate if the name information matches. Similarly, an administrator or RA can be assigned the ability to revoke the certificate of a third party. Acceptance of the revocation by the server depends on local policy in these cases.
いくつかの状況では異なる証明書を使用して、失われた証明書の失効に署名することが可能です。名前の情報が一致した場合、クライアントは、署名証明書と暗号化キーの失効に署名することができます。同様に、管理者またはRAは、第三者の証明書を失効させる能力を割り当てることができます。サーバによる失効の受け入れは、これらのケースではローカルポリシーに依存します。
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共有秘密を含む符号なし失効要求制御（無署名とのSignedDataからなる未署名のメッセージ）を製造することができなければなりません。クライアントが共有秘密に基づく自己取消しを提供する場合、クライアントは、共有秘密を含む失効要求制御を生成することができなければなりません。サーバーは、失効要求の両方の形式を受け入れることができなければなりません。
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.
一部の環境では、手動の介入または他の身元確認のためのプロセス要件は、証明書の復帰を遅らせることができます。照会保留中のコントロールは、クライアントが保留中の証明書要求の状態についてのサーバーを照会することができます。サーバーは、拡張CMCステータス情報と（otherInfoフィールド内）CMCステータス情報統制の一環としてpendTokenを返します。クライアントコピーの照会保留にpendTokenは、サーバへの正しい証明書要求を識別するために制御します。サーバーは、クライアントが保留中の証明書の要求の状態を照会する時間の目安を返します。
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を（トランザクションがまだ保留されている）を返した場合、otherInfoを省略することができます。 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ステータス情報がconfirmRequiredある場合、クライアントは完全な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つの完全なラウンドトリップがあることに注意してください。
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.クライアントは、Extended 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].
トラストアンカーコントロールを公開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:
トラストアンカーを公開制御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.
anchorHashesは、クライアントが信頼アンカーとして扱われる証明書のハッシュです。実際の証明書が含まのSignedData構造の証明書のバッグに輸送されます。
While it is recommended that the sender place the certificates that are to be trusted in the PKI Response, it is not required as the certificates should be obtainable using normal discovery techniques.
それは送信者がPKI応答に信頼されるようにされている証明書を配置することをお勧めしますが、証明書は、通常の発見技術を用いて得るべきであるとして、これは必須ではありません。
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.
認証されたデータコントロールは、サーバーが認証方法で、クライアントにデータを提供することができます。このコントロールは、データの検証を可能にするために認証されたデータ構造を使用しています。クライアントは、共有秘密とサーバとの秘密の識別子を有する場合、このコントロールが使用されますが、サーバーの署名証明書を検証することができないように、トラストアンカーは、まだクライアントにダウンロードされていないところ。この制御は、で使用するために作成された特定の場合には、トラストアンカー制御パブリッシュ（セクション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データのcmsSequence要素のメンバーを指すボディ部分識別子です。 cmsSequence要素がAuthenticatedDataです。カプセル化されたコンテンツは、ID-CCT-PKIDataあります。 controlSequenceのコントロールは、認証が成功した場合に処理する必要があります。 （一例は、セクション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.
これらのコントロールは、単一の完全なPKI要求に合わせて複数の要求を収集し、CAに転送するRAを可能にその後、サーバは要求を処理し、完全な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のcmcSequenceにおける個々のエントリとして配置されています。これらのエントリの身体部分識別子は、次いで、コントロールに関連付けられている身体部分リストに配置されています。
When a server processes a Batch Request control, it MAY return the responses in one or more PKI Responses. A CMCStatus value of partial is returned on all but the last PKI Response. The CMCStatus would be success if the Batch Requests control was processed; the responses are created with their own CMCStatus code. Errors on individual requests are not propagated up to the top level.
サーバがバッチリクエスト制御を処理するとき、それは、一つ以上のPKIレスポンスで応答を返すことがあります。部分のCMCStatus値は、すべてが、最後のPKIレスポンスに返されます。バッチ要求コントロールが処理された場合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.
出版情報制御の両方の出版と出版物から除去するため、既に発行された証明書の出版を変更することができます。この制御のための一般的な使用は、再入力動作中にパブリケーションから既存の証明書を削除することです。このコントロールは、常に新しい証明書と失効リクエストの発行後に処理されなければなりません。証明書を発行することに失敗した場合には、この制御は、処理すべきではありません。
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は、どのように証明書が公表されるべき情報です。 （[CRMF]から取られた）pubInfoのフィールドは以下の意味を有します。
action indicates the action the service should take. It has two values:
アクションは、サービスがとるべき行動を示しています。これは、2つの値があります。
dontPublish indicates that the PKI should not publish the certificate (this may indicate that the requester intends to publish the certificate him/herself). dontPublish has the added connotation of removing from publication the certificate if it is already published.
dontPublishは、PKIが証明書を発行してはならないことを示している（これは、要求者が証明書に彼/彼女自身を公開する予定であることを示す場合があります）。 dontPublishは、それがすでに公開されている場合の出版物からの証明書を除去する追加的な意味合いを持っています。
pleasePublish indicates that the PKI MAY publish the certificate using whatever means it chooses unless pubInfos is present. Omission of the CMC Publication Info control results in the same behavior.
pleasePublishは、PKIがpubInfosが存在しない限り、それが選択したあらゆる手段を使用して証明書を発行することを示しています。同じ動作でCMC出版情報管理の結果の省略。
pubInfos pubInfos indicates how (e.g., X500, Web, IP Address) the PKI SHOULD publish the certificate.
pubInfos pubInfosは（例えば、X500、ウェブ、IPアドレス）がPKI証明書を発行する方法を示します。
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は、クライアントのように見えます。 RAはPKI要求を受け、地元の処理を実行して、CAの上にそれらを転送します。 RAが実行できるローカル処理の種類のいくつかは、次のとおりです。
o Batching multiple PKI Requests together,
、一緒にバッチ処理複数のPKI要求O
o Performing challenge/response POP proofs,
Oチャレンジ/レスポンスPOPの証明を行います、
o Adding private or standardized certificate extensions to all certification requests,
Oすべての認証要求にプライベートまたは標準化された証明書の拡張を追加し、
o Archiving private key material,
Oのアーカイブ秘密鍵の材料、
o Routing requests to different CAs.
Oルーティングが異なる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要求に新しいラッピング層を追加することができ、またはそれは1つ以上の既存の層を除去し、新しいラッピング層を追加することができ、修正なしPKI要求を転送することができます。
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を作成します。クライアントのPKI要求（RAは、暗号鍵やPKI要求を変更するための追加の拡張制御のためのPOP証明を行う場合、たとえば）新たな層は、必要なすべてのコントロールが含まれています。それは単純なPKI要求であれば、それは完全なPKI要求とreqSequenceであれば、クライアントのPKI要求がcmsSequenceに配置されます。 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は、認証要求、したがって秘密鍵のPOPの署名を無効にする任意の変化のような任意の認証要求（PKCS＃10またはCRMF）を変更してはなりません。
An example of how this would look is illustrated by the following figure:
これがどのように見えるかの例を次の図で示されています：
SignedData (by RA) PKIData controlSequence RA added control statements reqSequence Zero or more Simple PKI Requests from clients cmsSequence Zero or more Full PKI Requests from clients SignedData (signed by client) PKIData
（RAによる）のSignedDataはPKIData controlSequence RAは、制御文reqSequenceゼロまたはクライアントのSignedData（クライアントによって署名された）PKIDataからクライアントcmsSequenceゼロ以上のフルPKI要求から、よりシンプルなPKI要求を追加しました
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.
暗号化層は、要求内で変更する必要がある場合、またはCAセカンダリ委任（すなわち、複数のRAの署名）を受け入れない場合：RAフルPKI要求に署名層を除去しなければならない場合のみ2つのインスタンスが存在します。他のすべての状況では、RAは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は、重要状態情報を維持する場合には、リプレイ攻撃は、オプションのナンス・メカニズムを含むことなく検出することができます。このプロトコルの実装者は慎重にセクション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]で提供されます。小さなサブグループの攻撃を回避する方法は、[SMALL-GROUP]で見つけることができます。 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.
トラストアンカーを公開コントロールを処理する際に細心の注意を使用する必要があります。不正な処理は、攻撃者がセキュリティを弱めるためには、信頼できるアンカーのセットを変更するスラミングの実践につながることができます。
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 AuthenticatedData構造は、メッセージの整合性を提供し、それはすべてのケースでメッセージ認証を提供していません。この文書に記載されているMACを使用する場合は以下の制限が観察する必要があります。すべてのメッセージは、単一のエンティティのためにする必要があります。 2つのエンティティが単一のメッセージに配置されている場合は、エンティティは、有効なMACを持っているし、元のメッセージの送信者からのものであると仮定されるかもしれない新しいメッセージを生成することができます。共有秘密へのアクセス権を持つすべてのエンティティは、成功したMACの検証を持つことになりますメッセージを生成することができます。これは、介護がこの値を秘密にしておくように注意しなければならないことを意味しています。可能な限り、のSignedData構造はAuthenticatedData構造に優先して使用する必要があります。
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）によって識別されます。オブジェクトは、PKIXワーキンググループにIANAによって委任円弧から定義されています。 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劉とジェフ・ワインスタインの参加に感謝しています。
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.、 "インターネット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、 "ディフィー - ヘルマンプルーフ・オブ・所有アルゴリズム"、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.
[PKIXCERT] Housley, R., Ford, W., Polk, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[PKIXCERT] Housley氏、R.、フォード、W.、ポーク、W.、およびD.ソロ、 "インターネット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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.マイヤーズ、 "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.マイヤーズ、 "CMS（CMC）以上の証明書管理メッセージ：コンプライアンス要件"、RFC 5274、2008年6月。
[PASSWORD] Burr, W., Dodson, D., and W. Polk, "Electronic Authentication Guideline", NIST SP 800-63, April 2006.
[PASSWORD]バリ、W.、ドッドソン、D.、およびW.ポーク、 "電子認証に関するガイドライン"、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.
[ランダム]イーストレーク、第3、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、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鍵合意方式に対する攻撃 "小サブグループ" の回避のための方法"、RFC 2785、2000年3月。
[X942] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[X942]レスコラ、E.、 "ディフィー・ヘルマン鍵共有方式"、RFC 2631、1999年6月。
[RFC2797] Myers, M., Liu, X., Schaad, J., and J. Weinstein, "Certificate Management Messages over CMS", RFC 2797, April 2000.
[RFC2797]マイヤーズ、M.、劉、X.、Schaad、J.、およびJ.ワインスタイン、 "CMSオーバー証明書の管理のメッセージ"、RFC 2797、2000年4月。
Appendix A. ASN.1 Module
付録A. ASN.1モジュール
EnrollmentMessageSyntax { iso(1) identified-organization(3) dod(4) internet(1) security(5) mechansims(5) pkix(7) id-mod(0) id-mod-cmc2002(23) }
EnrollmentMessageSyntax {ISO（1）同定された組織（3）DOD（4）インターネット（1）セキュリティ（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.
- すべてのエクスポート - - このモジュールで定義されたタイプと値が使用のためにエクスポートされる - 他のASN.1モジュールに。独自の目的 - 他のアプリケーションがためにそれらを使用することができます。
IMPORTS
輸入
-- PKIX Part 1 - Implicit From [PKIXCERT] GeneralName, CRLReason, ReasonFlags FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19)}
- PKIXパート1 - [PKIXCERT]のGeneralName、CRLReason、PKIX1Implicit88 {ISO（1）同定された組織からのReasonFlags（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）IDから、暗黙-mod（0）ID-pkix1-暗黙（19）}
-- PKIX Part 1 - Explicit From [PKIXCERT] AlgorithmIdentifier, Extension, Name, CertificateSerialNumber FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18)}
- PKIXパート1 - [PKIXCERT]のAlgorithmIdentifier、拡張、名前、CertificateSerialNumber PKIX1Explicit88 FROM {ISO（1）同定された組織からの明示的な（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7 ）ID-MOD（0）ID-pkix1-明示（18）}
-- Cryptographic Message Syntax FROM [CMS] ContentInfo, Attribute, IssuerAndSerialNumber FROM CryptographicMessageSyntax2004 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24)}
- 暗号メッセージ構文PKCS [CMS] ContentInfo、属性、CryptographicMessageSyntax2004 FROM IssuerAndSerialNumber {ISO（1）部材本体（2）米国（840）RSADSI（113549）（1）からPKCS-9（9）SMIME（16）モジュール（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)};
- PKIXCRMF-2005 {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD FROM [CRMF] CertReqMsg、PKIPublicationInfo、CertTemplateのFROM CRMF （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
- 次のコントロールは、タイプ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.
- 注： - unsupportedExtのスペルが、このバージョンで修正されています。 - RFC 2797では、それが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
- 証明書 - 次はに追加することがV3拡張を要求するために使用されます
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
- 以下はのDiffie-Hellman認証要求を許可するように存在している - 整形するメッセージを
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.
- 認証されていない属性は、リムーバブルデータを運ぶために。 （2005年2月）および他の中で - ドキュメント： - - これは、「鍵の生成とキーエスクローサーバー側CMC拡張機能」の更新に使用することができます。
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
- アイデンティティ証明制御のw /アルゴリズムの俊敏性
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
終わり
Appendix B. Enrollment Message Flows
付録B.登録メッセージ・フロー
This section is informational. The purpose of this section is to present, in an abstracted version, the messages that would flow between the client and server for several different common cases.
このセクションでは情報です。このセクションの目的は、抽象化されたバージョンでは、いくつかの異なる一般的なケースのために、クライアントとサーバーの間を流れるだろうメッセージを提示することです。
B.1. Request of a Signing Certificate
B.1。署名証明書の要求
This section looks at the messages that would flow in the event that an enrollment is occurring for a signing-only key. If the certificate was designed for both signing and encryption, the only difference would be the key usage extension in the certification request.
このセクションでは、登録が署名のみのキーのために発生しているイベントに流れるだろうメッセージを見ます。証明書が署名と暗号化の両方のために設計された場合は、唯一の違いは、証明書要求で鍵用途拡張だろう。
Message #2 from client to server:
クライアントからサーバへのメッセージ＃2：
ContentInfo.contentType = id-signedData ContentInfo.content SignedData.encapContentInfo eContentType = id-ct-PKIData eContent controlSequence {102, id-cmc-identityProof, computed value} {103, id-cmc-senderNonce, 10001} reqSequence certRequest certReqId = 201 certTemplate subject = My Proposed DN publicKey = My Public Key extensions {id-ce-subjectPublicKeyIdentifier, 1000} {id-ce-keyUsage, digitalSignature} SignedData.SignerInfos SignerInfo sid.subjectKeyIdentifier = 1000
ContentInfo.contentType = ID-たsignedData ContentInfo.content SignedData.encapContentInfoのeContentType = ID-CT-PKIData e-コンテンツcontrolSequence {102、ID-CMC-identityProof、計算値}、{103、ID-CMC-senderNonce、10001} reqSequence certrequestコマンドcertReqId = 201 CertTemplateの対象=マイ提案DN公開=私の公開鍵拡張{ID-CE-subjectPublicKeyIdentifier 1000} {ID-CE-のkeyUsage、デジタル署名} 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
ContentInfo.contentType = ID-たsignedData ContentInfo.content SignedData.encapContentInfoのeContentType = ID-CT-PKIResponse e-コンテンツcontrolSequence {102、ID-CMC-statusInfoV2、{成功、201}、{103、ID-CMC-senderNonce、10005} {104 、ID-CMC-recipientNonce、10001}証明書が新たに発行された証明書の他の証明書SignedData.SignerInfos CAによって署名されました
B.2. Single Certification Request, But Modified by RA
B.2。シングル証明書要求、しかし、RAにより変更されました
This section looks at the messages that would flow in the event that an enrollment has one RA in the middle of the data flow. That RA will modify the certification request before passing it on to the CA.
このセクションでは、登録は、データフローの途中で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
ContentInfo.contentType = ID-たsignedData ContentInfo.content SignedData.encapContentInfoのeContentType = ID-CT-PKIData e-コンテンツcontrolSequence {102、ID-CMC-identityProof、計算値}、{103、ID-CMC-senderNonce、10001} reqSequence certrequestコマンドcertReqId = 201 CertTemplateの対象=マイ提案DN公開=私の公開鍵拡張{ID-CE-subjectPublicKeyIdentifier 1000} {ID-CE-のkeyUsage、デジタル署名} SignedData.SignerInfosのSignerInfo sid.subjectKeyIdentifier = 1000
Message from RA to CA:
CAへのRAからのメッセージ：
ContentInfo.contentType = id-signedData ContentInfo.content SignedData.encapContentInfo eContentType = id-ct-PKIData eContent controlSequence { 102, id-cmc-batchRequests, { 1, 2} } { 103, id-cmc-addExtensions, { {1, 201, {id-ce-certificatePolicies, anyPolicy}} {1, 201, {id-ce-subjectAltName, {extension data}} {2, XXX, {id-ce-subjectAltName, {extension data}}} The Value XXX is not known here; it would reference into the second client request, which is not displayed above. cmsSequence { 1, <Message from client to RA #1> } { 2, <Message from client to RA #2> } SignedData.SignerInfos SignerInfo sid = RA key.
ContentInfo.contentType = ID-たsignedData ContentInfo.content SignedData.encapContentInfoのeContentType = ID-CT-PKIData e-コンテンツcontrolSequence {102、ID-CMC-batchRequests、{1,2}}、{103、ID-CMC-addExtensions、{{1、 201、{ID-CE-certificatePolicies、anyPolicy}}、{1、201、{ID-CE-のsubjectAltName、{拡張データ}}、{2、XXX、{ID-CE-のsubjectAltName、{拡張データ}}}値XXXここでは知られていません。それは、上記の表示されていない第2のクライアント要求、に参照します。 cmsSequence {1、<メッセージクライアントからのRA＃1>}、{2、<クライアントからRA＃2へのメッセージ>} SignedData.SignerInfosのSignerInfo SID = RAキー。
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 e-コンテンツcontrolSequence {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 e-コンテンツcontrolSequence {102、ID-CMC-statusInfoV2、{成功、201}}新たに発行された証明書の他の証明書SignedData.SignerInfosは、CAによって署名された証明書
B.3. Direct POP for an RSA Certificate
B.3。 RSA証明書を直接POP
This section looks at the messages that would flow in the event that an enrollment is done for an encryption only certificate using an direct POP method. For simplicity, it is assumed that the certification requester already has a signing-only certificate.
このセクションでは、登録が直接POPメソッドを使用して暗号化のための証明書のみを実行された場合に流れてしまうのメッセージを見ます。簡単のために、認証要求者がすでに署名のみの証明書を持っていると仮定されます。
The fact that a second round-trip is required is implicit rather than explicit. The server determines this based on the fact that no other POP exists for the certification request.
第二ラウンドトリップが必要とされているという事実は、暗黙的ではなく、明示的です。サーバーは、他の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
ContentInfo.contentType = ID-たsignedData ContentInfo.content SignedData.encapContentInfoのeContentType = ID-CT-PKIData e-コンテンツcontrolSequence {102、ID-CMC-のtransactionId、10132985123483401} {103、ID-CMC-senderNonce、10001}、{104、ID-CMC -dataReturn、<バイナリデータのパケット当該キーがどこにあるか識別する。>} reqSequence certrequestコマンドcertReqId = 201 CertTemplateの被験者= <私の署名証明書から自分のDN>公開=マイ公開鍵拡張{ID-CE-のkeyUsage、keyEncipherment}ポポkeyEncipherment subsequentMessage SignedData.SignerInfosのSignerInfo要求者の署名証明書によって署名されました
Response #1 from server to client:
サーバーからクライアントへの応答＃1：
ContentInfo.contentType = id-signedData ContentInfo.content SignedData.encapContentInfo eContentType = id-ct-PKIResponse eContent controlSequence {101, id-cmc-statusInfoV2, {failed, 201, popRequired}} {102, id-cmc-transactionId, 10132985123483401} {103, id-cmc-senderNonce, 10005} {104, id-cmc-recipientNonce, 10001} {105, id-cmc-encryptedPOP, { request { certRequest certReqId = 201 certTemplate subject = <My DN from my signing cert> publicKey = My Public Key extensions {id-ce-keyUsage, keyEncipherment}
ContentInfo.contentType = ID-たsignedData ContentInfo.content SignedData.encapContentInfoのeContentType = ID-CT-PKIResponse e-コンテンツcontrolSequence {101、ID-CMC-statusInfoV2、{失敗、201、popRequired}}、{102、ID-CMC-のtransactionId、10132985123483401} {103、ID-CMC-senderNonce、10005}、{104、ID-CMC-recipientNonce、10001}、{105、ID-CMC-encryptedPOP、{要求{certrequestコマンドcertReqId = 201 CertTemplateの被験者= <私の署名からマイDN CERT>公開=私の公開キー拡張{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
ポポkeyEncipherment subsequentMessage} CMSのcontentType = ID-EnvelopedDataのコンテンツrecipientInfos.riid.issuerSerialNumber = <NULL、201> encryptedContentInfoのeContentType = ID-データe-コンテンツ= thePOPAlgID = HMAC-SHA1 witnessAlgID = SHA1証人< 'Y' の暗号化された値> < 「Y」>}}、{106、ID-CMC-dataReturn、当該キーがどこにあるか識別するバイナリデータの<パケットのハッシュ値>}証明書の他の証明書CAによって署名（オプション）SignedData.SignerInfos
ContentInfo.contentType = id-signedData ContentInfo.content SignedData.encapContentInfo eContentType = id-ct-PKIData eContent controlSequence {102, id-cmc-transactionId, 10132985123483401} {103, id-cmc-senderNonce, 100101} {104, id-cmc-dataReturn, <packet of binary data identifying where the key in question is.>} {105, id-cmc-recipientNonce, 10005} {107, id-cmc-decryptedPOP, { bodyPartID 201, thePOPAlgID HMAC-SHA1, thePOP <HMAC computed value goes here>}} reqSequence certRequest certReqId = 201 certTemplate subject = <My DN from my signing cert> publicKey = My Public Key extensions {id-ce-keyUsage, keyEncipherment} popo keyEncipherment subsequentMessage
ContentInfo.contentType = ID-たsignedData ContentInfo.content SignedData.encapContentInfoのeContentType = ID-CT-PKIData e-コンテンツcontrolSequence {102、ID-CMC-のtransactionId、10132985123483401} {103、ID-CMC-senderNonce、100101} {104、ID-CMC -dataReturn、<当該キーがどこにあるか識別するバイナリデータのパケット。>} {105、ID-CMC-recipientNonce、10005}、{107、ID-CMC-decryptedPOP、{bodyPartID 201、thePOPAlgID HMAC-SHA1、thePOP <HMAC計算された値は、ここに行く>}} reqSequence certrequestコマンドcertReqId = 201 CertTemplateの対象= <私の署名証明書から私のDN>公開=私の公開キー拡張{ID-CE-のkeyUsage、keyEncipherment}ポポ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
ContentInfo.contentType = ID-たsignedData ContentInfo.content SignedData.encapContentInfoのeContentType = ID-CT-PKIResponse e-コンテンツcontrolSequence {101、ID-CMC-のtransactionId、10132985123483401} {102、ID-CMC-statusInfoV2、{成功、201}、{103 、ID-CMC-senderNonce、10019}、{104、ID-CMC-recipientNonce、100101} {105、ID-CMC-dataReturn、<当該キーがどこにあるか識別するバイナリデータのパケット。>}証明書新たに発行された証明書を他の証明書CAによって署名されたSignedData.SignerInfos
Appendix C. Production of Diffie-Hellman Public Key Certification Requests
Diffie-Hellman公開鍵証明書要求の付録C.生産
Part of a certification request is a signature over the request; Diffie-Hellman is a key agreement algorithm and cannot be used to directly produce the required signature object. [DH-POP] provides two ways to produce the necessary signature value. This document also defines a signature algorithm that does not provide a POP value, but can be used to produce the necessary signature value.
認証要求の一部は、要求上の署名です。ディフィー・ヘルマン鍵合意アルゴリズムで直接必要な署名オブジェクトを生成するために使用することができません。 [DH-POP]は、必要な署名値を生成する2つの方法を提供します。この文書はまた、POP値を提供していない署名アルゴリズムを定義するが、必要に応じて署名値を生成するために使用することができます。
C.1. No-Signature Signature Mechanism
C.1。無署名の署名機構
Key management (encryption/decryption) private keys cannot always be used to produce some type of signature value as they can be in a decrypt-only device. Certification requests require that the signature field be populated. This section provides a signature algorithm specifically for that purposes. The following object identifier and signature value are used to identify this signature type:
鍵管理（暗号化/復号化）秘密鍵は常に彼らが解読専用デバイスにすることができて署名値のいくつかのタイプを生成するために使用することはできません。認証要求が署名フィールドが設定されている必要があります。このセクションでは、その目的のために特別に署名アルゴリズムを提供します。以下のオブジェクト識別子と署名値は、この署名タイプを識別するために使用されます。
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節で定義されたPOPメカニズムを使用しなければなりません。
Authors' Addresses
著者のアドレス
Jim Schaad Soaring Hawk Consulting PO Box 675 Gold Bar, WA 98251
ジムSchaad高騰ホークコンサルティング私書箱675ゴールドバー、WA 98251
Phone: (425) 785-1031 EMail: jimsch@nwlink.com
電話：（425）785-1031 Eメール：jimsch@nwlink.com
Michael Myers TraceRoute Security, Inc.
マイケル・マイヤーズTRACEROUTE Security社
EMail: mmyers@fastq.com
メールアドレス：mmyers@fastq.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。