Network Working Group M. Myers
Request for Comments: 2797 VeriSign
Category: Standards Track X. Liu
Cisco
J. Schaad
Microsoft
J. Weinstein
April 2000
Certificate Management Messages over CMS
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）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This document defines a Certificate Management protocol using CMS (CMC). This protocol addresses two immediate needs within the Internet PKI community:
この文書では、CMS（CMC）を使用して、証明書管理プロトコルを定義します。このプロトコルは、インターネットPKIコミュニティ内の二つの当面のニーズに対処します。
1. The need for an interface to public key certification products and services based on [CMS] and [PKCS10], and 2. The need in [SMIMEV3] for a certificate enrollment protocol for DSA-signed certificates with Diffie-Hellman public keys.
1.公開鍵証明書の製品とサービス[CMS]に基づいて、[PKCS10]、および2のDiffie-Hellman公開鍵とDSA署名の証明書用の証明書登録プロトコルのための[SMIMEV3]での必要性へのインタフェースが必要。
A small number of additional services are defined to supplement the core certificate request service.
追加サービスの少数のコア証明書要求のサービスを補完するために定義されています。
Throughout this specification the term CMS is used to refer to both [CMS] and [PKCS7]. For both signedData and envelopedData, CMS is a superset of the PKCS7. In general, the use of PKCS7 in this document is aligned to the Cryptographic Message Syntax [CMS] that provides a superset of the PKCS7 syntax. The term CMC refers to this specification.
本明細書を通してCMSの両方を指すために使用される用語[CMS]と[PKCS7]。たsignedDataとEnvelopedDataの両方のために、CMSはPKCS7のスーパーセットです。一般に、本文書でPKCS7の使用は、PKCS7構文のスーパーセットを提供する暗号メッセージ構文[CMS]に整列されます。用語CMCは、この仕様を参照します。
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 [RFC 2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC 2119]に記載されているように解釈されます。
- The protocol is to be based as much as possible on the existing CMS, PKCS#10 and CRMF specifications. - The protocol must support the current industry practice of a PKCS#10 request followed by a PKCS#7 response as a subset of the protocol. - The protocol needs to easily support the multi-key enrollment protocols required by S/MIME and other groups. - The protocol must supply a way of doing all operations in a single-round trip. When this is not possible the number of round trips is to be minimized. - The protocol will be designed such that all key generation can occur on the client. - The mandatory algorithms must superset the required algorithms for S/MIME. - The protocol will contain POP methods. Optional provisions for multiple-round trip POP will be made if necessary. - The protocol will support deferred and pending responses to certificate request for cases where external procedures are required to issue a certificate. - The protocol needs to support arbitrary chains of local registration authorities as intermediaries between certificate requesters and issuers.
- プロトコルは、既存のCMS、PKCS＃10とCRMF仕様にできるだけ多くをベースとすることです。 - プロトコルは、プロトコルの一部としてPKCS＃7応答続いてPKCS＃10要求の現在の業界慣行をサポートしなければなりません。 - プロトコルは、簡単にS / MIMEおよび他のグループによって必要とされるマルチキー登録プロトコルをサポートする必要があります。 - プロトコルは、単一のラウンドトリップですべての操作を行う方法を提供する必要があります。これができない場合は、ラウンドトリップの数を最小限に抑えることです。 - プロトコルは、すべての鍵の生成は、クライアント上で発生する可能性があるように設計されます。 - 義務的なアルゴリズムは、S / MIMEのために必要なアルゴリズムをスーパーセットしなければなりません。 - プロトコルは、POPのメソッドが含まれます。必要に応じて複数のラウンドトリップPOPのオプション条項が行われます。 - プロトコルは、外部プロシージャが証明書を発行するために必要とされる場合の証明書要求に延期、保留中の応答をサポートします。 - プロトコルは、証明書の要求者と発行者間の仲介としてローカル登録機関の任意のチェーンをサポートする必要があります。
An enrollment transaction in this specification is generally composed of a single round trip of messages. In the simplest case an enrollment request is sent from the client to the server and an enrollment response is then returned from the server to the client. In some more complicated cases, such as delayed certificate issuance and polling for responses, more than one round trip is required.
この仕様での登録トランザクションは、一般的に、メッセージの1回の往復で構成されています。最も単純なケースでは、登録要求は、クライアントからサーバに送信され、登録応答は、サーバからクライアントに返されます。そのような応答のために遅れた証明書発行とポーリングなど、いくつかのより複雑な例では、複数のラウンドトリップが必要です。
This specification supports two different request messages and two different response messages.
この仕様は、二つの異なる要求メッセージと二つの異なる応答メッセージをサポートしています。
Public key certification requests can be based on either the PKCS10 or CRMF object. The two different request messages are (a) the bare PKCS10 (in the event that no other services are needed), and (b) the PKCS10 or CRMF message wrapped in a CMS encapsulation as part of a PKIData object.
公開鍵証明書の要求は、PKCS10かCRMFオブジェクトのいずれかに基づくことができます。二つの異なる要求メッセージはPKIDataオブジェクトの一部としてCMSのカプセルに包まれた（他のサービスが必要とされないことが場合）（a）の裸PKCS10、および（b）PKCS10またはCRMFメッセージです。
Public key certification responses are based on the CMS signedData object. The response may be either (a) a degenerate CMS signedData object (in the event no other services are needed), or (b) a ResponseBody object wrapped in a CMS signedData object.
公開鍵証明書応答はCMS SignedDataオブジェクトに基づいています。応答は、（A）縮重CMS SignedDataオブジェクト（イベントで他のサービスが必要とされない）、またはCMS SignedDataオブジェクトに包まれた（B）ResponseBodyオブジェクトのいずれであってもよいです。
No special services are provided for doing either renewal (new certificates with the same key) or re-keying (new certificates on new keys) of clients. Instead a renewal/re-key message looks the same as any enrollment message, with the identity proof being supplied by existing certificates from the CA.
特別なサービスがリニューアル（同じキーを持つ新しい証明書）、またはクライアントの再キーイング（新しいキーで新しい証明書）のいずれかを行うために提供されていません。代わりに、更新/再キーメッセージは、CAから、既存の証明書によって提供される身元証明された状態で、任意の登録メッセージと同じに見えます
A provision exists for Local Registration Authorities (LRAs) to participate in the protocol by taking client enrollment messages, wrapping them in a second layer of enrollment message with additional requirements or statements from the LRA and then passing this new expanded request on to the Certification Authority.
規定は、クライアントの登録メッセージを服用LRAからの追加要件または文を登録メッセージの第二の層でそれらをラップして、認証局への上に、この新しい拡張され、要求を渡すことによって、プロトコルに参加するローカル登録機関（LRAは）のために存在します。
This specification makes no assumptions about the underlying transport mechanism. The use of CMS is not meant to imply an email-based transport.
この仕様は、下位のトランスポートメカニズムを想定していません。 CMSの使用は、電子メールベースのトランスポートを意味するものではありません。
Optional services available through this specification are transaction management, replay detection (through nonces), deferred certificate issuance, certificate revocation requests and certificate/CRL retrieval.
この仕様を介して利用可能なオプションサービスは、トランザクション管理、（ナンスを介して）リプレイ検出、繰延証明書発行、証明書失効要求および証明書/ CRLの取得です。
There are several different terms, abbreviations and acronyms used in this document that we define here for convenience and consistency of usage:
我々は、使用の利便性と一貫性のために、ここで定義し、このドキュメントで使用されているいくつかの異なる用語、略語があります。
"End-Entity" (EE) refers to the entity that owns a key pair and for whom a certificate is issued. "LRA" or "RA" refers to a (Local) Registration Authority. A registration authority acts as an intermediary between an End-Entity and a Certification Authority. Multiple RAs can exist between the End-Entity and the Certification Authority. "CA" refers to a Certification Authority. A Certification Authority is the entity that performs the actual issuance of a certificate. "Client" refers to an entity that creates a PKI request. In this document both RAs and End-Entities can be clients. "Server" refers to the entities that process PKI requests and create PKI responses. CAs and RAs can be servers in this document. "PKCS#10" refers the Public Key Cryptography Standard #10. This is one of a set of standards defined by RSA Laboratories in the 1980s. PKCS#10 defines a Certificate Request Message syntax. "CRMF" refers to the Certificate Request Message Format RFC [CRMF]. We are using certificate request message format defined in this document as part of our management protocol. "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.
「エンドエンティティ」（EE）は、鍵のペアを所有し、誰のための証明書が発行されたエンティティを指します。 「LRA」または「RAは」（ローカル）登録機関を指します。登録機関は、エンドエンティティおよび認証局との間の仲介として機能します。複数のRAはエンドエンティティと認証局の間に存在することができます。 「CAは、」認証局を指します。証明機関は、証明書の実際の発行を実行するエンティティです。 「クライアントは、」PKI要求を作成したエンティティを指します。この文書では、両方のRAとエンドエンティティは、クライアントにすることができます。 「サーバー」とは、PKI要求を処理し、PKI応答を作成するエンティティを指します。 CAとRAは、この文書に記載されているサーバーにすることができます。 「PKCS＃10」公開鍵暗号化標準＃10が参照します。これは、1980年代にRSA研究所によって定義された標準のセットの1つです。 PKCS＃10証明書要求メッセージの構文を定義します。 「CRMFは、」証明書要求メッセージ形式のRFC [CRMF]を参照します。私たちは、管理プロトコルの一部として、このドキュメントで定義された証明書要求メッセージ・フォーマットを使用しています。 「CMSは、」暗号メッセージ構文RFC [CMS]を参照します。この文書では、とし、鍵管理なしの暗号化と署名などの基本的な暗号化サービスを提供します。
"POP" is an acronym for "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. "Transport wrapper" refers to the outermost CMS wrapping layer.
「POP」とは、「所有の証明」の頭文字をとったものです。 POPは、公開鍵に対応する秘密鍵を所有しており、エンドエンティティによって使用することができることを証明するために使用することができる値です。 「交通ラッパーは」最も外側のCMSラッピング層を意味します。
Figure 1 shows the Simple Enrollment Request and Response messages. The contents of these messages are detailed in Sections 4.1 and 4.3 below.
図1は、簡単な登録要求と応答メッセージが表示されます。これらのメッセージの内容は、セクション4.1および以下の4.3で詳述されています。
Simple PKI Request Simple PKI Response
------------------------- --------------------------
+----------+ +------------------+
| PKCS #10 | | CMS "certs-only" |
+----------+--------------+ | message |
| | +------------------+------+
| Certificate Request | | |
| | | CMS Signed Data, |
| Subject Name | | no signerInfo |
| Subject Public Key Info | | |
| (K_PUB) | | signedData contains one |
| Attributes | | or more certificates in |
| | | the "certificates" |
+-----------+-------------+ | portion of the |
| signed with | | signedData. |
| matching | | |
| K_PRIV | | encapsulatedContentInfo |
+-------------+ | is empty. |
| |
+--------------+----------+
| unsigned |
+----------+
Figure 1: Simple PKI Request and Response Messages
図1：単純なPKIの要求および応答メッセージ
Full PKI Request Full PKI Response
----------------------- ------------------------
+----------------+ +----------------+
| CMS signedData | | CMS signedData |
| object | | object |
+----------------+--------+ +----------------+--------+
| | | |
| PKIData object | | ResponseBody object |
| | | |
| Sequence of: | | Sequence of: |
| <enrollment attribute>* | | <enrollment attribute>* |
| <certification request>*| | <CMS object>* |
| <CMS objects>* | | <other message>* |
| <other message>* | | |
| | | where * == zero or more |
| where * == zero or more | | |
| | | All certificates issued |
| Certificate requests | | as part of the response |
| are CRMF or PKCS#10 | | are included in the |
| objects. Attributes are | | "certificates" portion |
| (OID, ANY defined by | | of the signedData. |
| OID) pairs. | | Relevant CA certs and |
| | | CRLs can be included as |
+-------+-----------------+ | well. |
| signed (keypair | | |
| used may be pre-| +---------+---------------+
| existing or | | signed by the |
| identified in | | CA or an LRA |
| the request) | +---------------+
+-----------------+
Figure 2: Full PKI Request and Response Messages
図2：フルPKIの要求および応答メッセージ
Figure 2 shows the Full Enrollment Request and Response messages. The contents of these messages are detailed in Sections 4.2 and 4.4 below.
図2は、全登録要求と応答メッセージが表示されます。これらのメッセージの内容は、セクション4.2および以下の4.4で詳述されています。
This section covers each of the different elements that may be used to construct enrollment request and enrollment response messages. Section 4 will cover how to build the enrollment request and response messages.
このセクションでは、登録要求および登録応答メッセージを構築するために使用され得る種々の要素のそれぞれを覆っています。第4章では、登録要求と応答メッセージを構築する方法を説明します。
The new content object PKIData has been defined for this protocol. This new object is used as the body of the full PKI request message. The new body is identified by:
新しいコンテンツオブジェクトPKIDataは、このプロトコルのために定義されています。この新しいオブジェクトは、完全なPKI要求メッセージのボディとして使用されています。新しいボディがによって識別されます。
id-cct-PKIData OBJECT IDENTIFIER ::= { id-cct 2 }
The ASN.1 structure corresponding to this new content type is:
この新しいコンテンツタイプに対応する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
}
-- controlSequence consists of a sequence of control attributes. The control attributes defined in this document are found in section 5. As control sequences are defined by OIDs, other parties can define additional control attributes. Unrecognized OIDs MUST result in no part of the request being successfully processed.
- controlSequenceは、制御属性の配列からなります。制御配列のOIDで定義されているように、この文書で定義された制御属性は、他の当事者は、追加の制御属性を定義することができ、セクション5に記載されています。認識されないOIDは正常に処理されている要求の無い部分をもたらさなければなりません。
-- reqSequence consists of a sequence of certificate requests. The certificate requests can be either a CertificateRequest (PKCS10 request) or a CertReqMsg. Details on each of these request types are found in sections 3.3.1 and 3.3.2 respectively.
- reqSequenceは、証明書の要求のシーケンスで構成されています。証明書要求は、CertificateRequest（PKCS10要求）またはCertReqMsgのいずれかになります。これらの要求タイプのそれぞれの詳細については、それぞれのセクション3.3.1と3.3.2で発見されています。
-- cmsSequence consists of a sequence of [CMS] message objects. This protocol only uses EnvelopedData, SignedData and EncryptedData. See section 3.6 for more details.
- cmsSequenceは[CMS]メッセージオブジェクトの配列からなります。このプロトコルはEnvelopedDataの、のSignedDataとはEncryptedDataを使用しています。詳細については、セクション3.6を参照してください。
-- otherMsgSequence allows for other arbitrary data items to be placed into the enrollment protocol. The {OID, any} pair of values allows for arbitrary definition of material. Data objects are placed here while control objects are placed in the controlSequence field. See section 3.7 for more details.
- otherMsgSequenceは、登録プロトコル中に配置される他の任意のデータ項目を可能にします。 {OIDは、任意の値}の対は、材料の任意の定義を可能にします。コントロールオブジェクトはcontrolSequenceフィールドに配置されている間、データオブジェクトは、ここに配置されています。詳細については、3.7節を参照してください。
The new content object ResponseBody has been defined for this protocol. This new object is used as the body of the full PKI response message. The new body is identified by:
新しいコンテンツオブジェクトResponseBodyは、このプロトコルのために定義されています。この新しいオブジェクトは、完全なPKI応答メッセージのボディとして使用されています。新しいボディがによって識別されます。
id-cct-PKIResponse OBJECT IDENTIFIER ::= { id-cct 3 }
The ASN.1 structure corresponding to this body content type is:
この本体のコンテンツタイプに対応するASN.1構造です。
ResponseBody ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
-- controlSequence consists of a sequence of control attributes. The control attributes defined in this document are found in section 3.5. Other parties can define additional control attributes.
- controlSequenceは、制御属性の配列からなります。この文書で定義された制御属性は、セクション3.5に記載されています。他の当事者は、追加の制御属性を定義することができます。
-- cmsSequence consists of a sequence of [CMS] message objects. This protocol only uses EnvelopedData, SignedData and EncryptedData. See section 3.6 for more details.
- cmsSequenceは[CMS]メッセージオブジェクトの配列からなります。このプロトコルはEnvelopedDataの、のSignedDataとはEncryptedDataを使用しています。詳細については、セクション3.6を参照してください。
-- otherMsgSequence allows for other arbitrary items to be placed into the enrollment protocol. The {OID, any} pair of values allows for arbitrary definition of material. Data objects are placed here while control objects are placed in the controlSequence field. See section 3.7 for more details.
- otherMsgSequenceは、登録プロトコル中に配置される他の任意のアイテムを可能にします。 {OIDは、任意の値}の対は、材料の任意の定義を可能にします。コントロールオブジェクトはcontrolSequenceフィールドに配置されている間、データオブジェクトは、ここに配置されています。詳細については、3.7節を参照してください。
Certification Requests are based on either PKCS10 or CRMF messages. Section 3.3.1 specifies mandatory and optional requirements for clients and servers dealing with PKCS10 request messages. Section 3.3.2 specifies mandatory and optional requirements for clients and servers dealing with CRMF request messages.
認証要求は、PKCS10かCRMFメッセージのいずれかに基づいています。セクション3.3.1は、PKCS10要求メッセージを扱うクライアントとサーバのための必須およびオプションの要件を指定します。 3.3.2はCRMF要求メッセージを扱うクライアントとサーバのための必須およびオプションの要件を指定します。
Servers MUST be able to understand and process PKCS10 request bodies. Clients MUST produce a PKCS10 request body when using the Simple Enrollment Request message. Clients MAY produce a PKCS10 request body when using the Full Enrollment Request message.
サーバーは、PKCS10要求ボディーを理解し、処理できなければなりません。簡単な登録要求メッセージを使用している場合、クライアントはPKCS10要求体を生成しなければなりません。全登録要求メッセージを使用している場合、クライアントはPKCS10要求体を生成することができます。
When producing a PKCS10 request body, clients MUST produce a PKCS10 message body containing a subject name and public key. Some certification products are operated using a central repository of information to assign subject names upon receipt of a public key for certification. To accommodate this mode of operation, the subject name in a CertificationRequest MAY be NULL, but MUST be present. CAs that receive a CertificationRequest with a NULL subject name MAY reject such requests. If rejected and a response is returned, the CA MUST respond with the failInfo attribute of badRequest.
PKCS10要求体を製造する場合、クライアントは、サブジェクト名と公開鍵を含むPKCS10メッセージ本文を生成しなければなりません。いくつかの認定製品は、認証のための公開鍵を受信すると、サブジェクト名を割り当てるための情報の中央リポジトリを使用して操作されます。この動作モードに対応するために、CertificationRequestでのサブジェクト名はnullの場合もあるが、存在しなければなりません。 NULLサブジェクト名とCertificationRequestを受け取るCAは、そのような要求を拒否することがあります。拒否され、応答が返された場合、CAはbadRequestのfailInfo属性で応じなければなりません。
The client MAY incorporate one or more standard X.509 v3 extensions in any PKCS10 request as an ExtensionReq attribute. An ExtensionReq attribute is defined as
クライアントはExtensionReq属性として任意のPKCS10リクエストに1つまたは複数の標準X.509 v3の拡張を組み込むことができます。 ExtensionReq属性は以下のように定義されます
ExtensionReq ::= SEQUENCE OF Extension
where Extension is imported from [PKIXCERT] and ExtensionReq is identified by {pkcs-9 14}.
拡張が[PKIXCERT]からインポートされ、ここでExtensionReqは{PKCS-9 14}によって識別されます。
Servers MUST be able to process all extensions defined in [PKIXCERT]. Servers are not required to be able to process other V3 X.509 extensions transmitted using this protocol, nor are they required to be able to process other, 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 key exchange to signing.) If a certification request is denied due to the inability to handle a requested extension and a response is returned, the server MUST respond with the failInfo attribute of unsupportedExt.
サーバは[PKIXCERT]で定義されたすべての拡張を処理できなければなりません。サーバーは、このプロトコルを使用して送信される他のV3 X.509拡張を処理できるように要求されない、また彼らは他の、プライベート拡張を処理できるように要求されています。サーバは、証明書の中に、すべてのクライアントが要求した拡張を置く必要はありません。サーバは、クライアントが要求した拡張子を変更することが許可されています。クライアントが要求した拡張子の本来の意図を無効にするように、サーバーは、拡張子を変更してはなりません。 （例えば、署名への鍵交換から鍵の使用を変更する。）の認証要求は要求された拡張子を処理できないことが原因で拒否され、応答は、サーバがunsupportedExtのfailInfo属性で応じなければなりません、返された場合。
Servers MUST be able to understand and process CRMF request body. Clients MAY produce a CRMF message body when using the Full Enrollment Request message.
サーバはCRMF要求体を理解し、処理できなければなりません。全登録要求メッセージを使用している場合、クライアントはCRMFメッセージ本文を生成することができます。
This memo imposes the following additional changes on the construction and processing of CRMF messages:
このメモはCRMFメッセージの構築および処理に関する次の追加の変更を課し：
- When CRMF message bodies are used in the Full Enrollment Request message, each CRMF message MUST include both the subject and publicKey fields in the CertTemplate. As in the case of PKCS10 requests, the subject may be encoded as NULL, but MUST be present. - In general, when both CRMF and CMC controls exist with equivalent functionality, the CMC control SHOULD be used. The CMC control MUST override any CRMF control. - The regInfo field MUST NOT be used on a CRMF message. Equivalent functionality is provided in the regInfo control attribute (section 5.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 instead if POP is desired. The value of encrCert in SubsequentMessage MUST NOT be used.
- CRMFメッセージ体はフル登録要求メッセージに使用される場合、各CRMFメッセージは、対象とCertTemplateの中の公開鍵フィールドの両方を含まなければなりません。 PKCS10要求の場合のように、被験体は、NULLとして符号化されてもよいが、存在しなければなりません。 - 両方CRMFとCMCコントロールは同等の機能で存在する場合一般に、CMCコントロールを使用すべきです。 CMCコントロールは、任意のCRMFコントロールをオーバーライドする必要があります。 - REGINFOフィールドはCRMFメッセージに使用してはいけません。同等の機能はREGINFO制御属性（セクション5.12）で提供されます。 - POPを証明する間接的な方法は、このプロトコルでサポートされていません。 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 certificate template. Servers MUST be able to process all extensions defined in [PXIXCERT]. Servers are not required to be able to process other V3 X.509 extension transmitted using this protocol, nor are they required to be able to process other, 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 key exchange to signing.) If a certificate request is denied due to the inability to handle a requested extension, the server MUST respond with a failInfo attribute of unsupportedExt.
サーバーは、証明書テンプレートにクライアントによって提案されたすべての値を使用する必要はありません。サーバは[PXIXCERT]で定義されたすべての拡張を処理できなければなりません。サーバはこのプロトコルを使用して送信、他のV3 X.509拡張を処理できるようにする必要はありません、また、彼らは他の、プライベート拡張を処理できるように要求されています。サーバは、クライアントが要求した拡張子を変更することが許可されています。クライアントが要求した拡張子の本来の意図を無効にするように、サーバーは、拡張子を変更してはなりません。証明書の要求が原因要求された拡張子を扱うことができないことに拒否された場合（例えば、署名への鍵交換から鍵の使用を変更します。）、サーバーはunsupportedExtのfailInfo属性で応じなければなりません。
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値を提供していない署名アルゴリズムを定義するが、必要に応じて署名値を生成するために使用することができます。
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 5.7 MUST be used.
ID-ALG-noSignatureのパラメータが存在しなければならないとNULLとして符号化されなければなりません。 NoSignatureValueは、認証要求のハッシュが含まれています。この署名タイプに関連付けられたセキュリティが存在しないことを認識することが重要です。この署名タイプは、証明書要求であると認証局のポリシーは実証の所持秘密鍵のを必要とする場合は、セクション5.7で定義されたPOPメカニズムを使用しなければなりません。
CMC compliant implementations MUST support section 5 of [DH-POP].
CMC準拠実装は、[DH-POP]のセクション5をサポートしなければなりません。
CMC compliant implementations MAY support section 4 of [DH-POP].
CMC準拠実装は、[DH-POP]のセクション4をサポートするかもしれません。
Each element of a PKIData or PKIResponse message has an associated body part identifier. The Body Part Identifier is a 4-octet integer 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 object. Body Part Identifiers can be duplicated in different layers (for example a CMC message embedded within another). The Body Part Id of zero is reserved to designate the current PKIData object. This value is used in control attributes such as the Add Extensions Control in the pkiDataReference field to refer to a request in the current PKIData object.
PKIData又はPKIResponseメッセージの各要素は、関連する身体部分の識別子を有します。ボディパート識別子（TaggedRequestで）CertReqMsgオブジェクトまたは他のオブジェクトのbodyPartIdフィールドにcertReqIdsフィールドで符号化された4オクテットの整数です。ボディパート識別子は、単一のPKIDataまたはPKIResponseオブジェクト内で一意でなければなりません。ボディパート識別子（たとえばCMCメッセージが別の内に埋め込まれた）異なる層に複製することができます。ゼロの身体各部Idが電流PKIDataオブジェクトを指定するために予約されています。この値は、現在のPKIDataオブジェクト内の要求を参照するためにpkiDataReferenceフィールドに拡張コントロールの追加などの制御属性で使用されています。
Some control attribute, such as the CMC Status Info attribute, will also use Body Part Identifiers to refer to elements in the previous message. This allows an error to be explicit about the attribute or request to which the error applies.
このようCMCステータス情報の属性など、一部の制御属性は、また、前のメッセージ内の要素を参照するために身体各部の識別子を使用します。これは、エラーはエラーが適用される属性や要求に関する明示的にすることができます。
The overall control flow of how a message is processed in this document is based on the control attributes. Each control attribute consists of an object identifier and a value based on the object identifier.
メッセージは、この文書でどのように処理されるかの全体的な制御フローを制御属性に基づいています。各制御属性は、オブジェクト識別子と、オブジェクト識別子に基づく値から成ります。
Servers MUST fail the processing of an entire PKIData message if any included control attribute is not recognized. The response MUST be the error badRequest and bodyList MUST contain the bodyPartID of the invalid or unrecognized control attribute.
いずれかのコントロール属性が認識されない含まれている場合、サーバーが全体PKIDataメッセージの処理を失敗しなければなりません。応答はbadRequestとバディリストが無効または認識されない制御属性のbodyPartIDを含まなければならないエラーでなければなりません。
The syntax of a control attribute is
制御属性の構文は次のとおりです。
TaggedAttribute ::= SEQUENCE {
bodyPartID BodyPartId,
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue
}
-- bodyPartId is a unique integer that is used to reference this control attribute. The id of 0 is reserved for use as the reference to the current PKIData object.
- bodyPartIdは、この制御属性を参照するために使用される一意の整数です。 0のIDが現在PKIDataオブジェクトへの参照として使用するために予約されています。
-- attrType is the OID defining the associated data in attrValues
- ATTRTYPEはattrValuesに関連付けられたデータを定義するOIDであります
-- attrValues contains the set of data values used in processing the control attribute.
- attrValues制御属性を処理する際に使用されるデータ値のセットを含みます。
The set of control attributes that are defined by this memo are found in section 5.
このメモで定義された制御属性のセット部5に見出されます。
The cmsSequence field of the PKIRequest and PKIResponse messages contains zero or more tagged content info objects. The syntax for this structure is
PKIRequestとPKIResponseメッセージのcmsSequenceフィールドは、ゼロ個以上のタグ付けされたコンテンツ情報オブジェクトが含まれています。このような構造の構文は次のとおりです。
TaggedContentInfo ::= SEQUENCE {
bodyPartID BodyPartId,
contentInfo ContentInfo
}
-- bodyPartId is a unique integer that is used to reference this content info object. The id of 0 is reserved for use as the reference to the current PKIData object.
- bodyPartIdは、このコンテンツ情報オブジェクトを参照するために使用される一意の整数です。 0のIDが現在PKIDataオブジェクトへの参照として使用するために予約されています。
-- contentInfo contains a ContentInfo object (defined in [CMS]). The three contents used in this location are SignedData, EnvelopedData and Data.
- contentInfoは（[CMS]で定義される）ContentInfoオブジェクトを含みます。この場所で使用される3つのコンテンツはSignedDataの、EnvelopedDataのとデータです。
EnvelopedData provides for shrouding of data. Data allows for general transport of unstructured data.
EnvelopedDataのは、データのシュラウドを提供します。データは、非構造化データの一般的な輸送が可能になります。
The SignedData object from [CMS] is also used in this specification to provide for authentication as well as serving as the general transport wrapper of requests and responses.
[CMS]からSignedDataオブジェクトはまた、要求と応答の一般的なトランスポート・ラッパーとしてだけでなく、認証を提供するために本明細書で使用されます。
The signedData object is used in two different locations when constructing enrollment messages. The signedData object is used as a wrapper for a PKIData as part of the enrollment request message. The signedData object is also used as the outer part of an enrollment response message.
登録メッセージを構築する際にSignedDataオブジェクトは、2つの異なる場所で使用されています。 SignedDataオブジェクトは、登録要求メッセージの一部としてPKIDataのラッパーとして使用されます。 SignedDataオブジェクトはまた、登録応答メッセージの外側の一部として使用されます。
For the enrollment response the signedData wrapper allows the server to sign the returning data, if any exists, and to carry the certificates and CRLs for the enrollment request. If no data is being returned beyond the certificates, no signerInfo objects are placed in the signedData object.
登録応答についてたsignedDataラッパーは、いずれかが存在する場合、サーバが返すデータに署名することを可能にし、登録要求のための証明書とCRLを運ぶために。データが証明書を超えて返却されていない場合は、何のSignerInfoオブジェクトはSignedDataオブジェクトに配置されていません。
EnvelopedData is the primary method of providing confidentiality for sensitive information in this protocol. The protocol currently uses EnvelopedData to provide encryption of an entire request (see section 4.5). The envelopedData object would also be used to wrap private key material for key archival.
EnvelopedDataのは、このプロトコルで機密情報の機密性を提供する主要な方法です。プロトコルは現在、要求全体の暗号化を提供するためのEnvelopedDataを使用しています（セクション4.5を参照してください）。 EnvelopedDataのオブジェクトは、キーのアーカイブのための秘密鍵の材料をラップするために使用されるだろう。
Servers MUST implement envelopedData according to [CMS]. There is an ambiguity (about encrypting content types other than id-data) in the PKCS7 specification that has lead to non-interoperability.
サーバーは、[CMS]に従ったEnvelopedData実装しなければなりません。非相互運用性をもたらしたPKCS7仕様で（ID-データ以外のコンテンツタイプの暗号化について）あいまいさがあります。
The other message body portion of the message allows for arbitrary data objects to be carried as part of a message. This is intended to contain data that is not already wrapped in a CMS contentInfo object. The data is ignored unless a control attribute references the data by bodyPartId.
メッセージの他のメッセージボディ部は、メッセージの一部として実施される任意のデータオブジェクトを可能にします。これは、すでにCMS contentInfoのオブジェクトにラップされていないデータを含むように意図されます。制御属性がbodyPartIdでデータを参照しない限り、データは無視されます。
OtherMsg ::= SEQUENCE {
bodyPartID BodyPartID,
otherMsgType OBJECT IDENTIFIER,
otherMsgValue ANY DEFINED BY otherMsgType }
-- bodyPartID contains the unique id of this object
- bodyPartIDは、このオブジェクトの一意のIDが含まれています
-- otherMsgType contains the OID defining both the usage of this body part and the syntax of the value associated with this body part
- otherMsgTypeこの身体部分の使用と、この本体部に関連付けられた値の構文の両方を定義するOIDが含まれてい
-- otherMsgValue contains the data associated with the message body part.
- otherMsgValueは、メッセージボディ部に関連付けられたデータを含みます。
This section discusses the details of putting together the different enrollment request and response messages.
このセクションでは、さまざまな登録要求メッセージと応答メッセージを一緒に入れての詳細を説明します。
The simplest form of an enrollment request is a plain PKCS10 message. If this form of enrollment request is used for a private key that is capable of generating a signature, the PKCS10 MUST be signed with that private key. If this form of the enrollment request is used for a D-H key, then the D-H POP mechanism described in [DH-POP] MUST be used.
登録要求の最も簡単な形式は、プレーンPKCS10メッセージです。登録要求のこの形態は、署名を生成することが可能である秘密鍵に使用される場合、PKCS10は、その秘密鍵で署名されなければなりません。登録要求のこの形態は、DHキーのために使用されている場合は、[DH-POP]に記載のDH POPメカニズムが使用されなければなりません。
Servers MUST support the Simple Enrollment Request message. If the Simple Enrollment Request message is used, servers MUST return the Simple Enrollment Response message (see Section 4.3) if the enrollment request is granted. If the enrollment request fails, the Full Enrollment Response MAY be returned or no response MAY be returned.
サーバーは、シンプルな登録要求メッセージをサポートしなければなりません。簡単な登録要求メッセージが使用されている場合は、登録要求が許可されている場合、サーバは（4.3節を参照）単純登録応答メッセージを返さなければなりません。登録要求が失敗した場合、全登録応答が返されることがありますか応答が返ってこないかもしれません。
Many advanced services specified in this memo are not supported by the Simple Enrollment Request message.
このメモで指定された多くの高度なサービスは、単純な登録要求メッセージによってサポートされていません。
The Full Enrollment Request provides the most functionality and flexibility. Clients SHOULD use the Full Enrollment Request message when enrolling. Servers MUST support the Full Enrollment Request message. An enrollment response (full or simple as appropriate) MUST be returned to all Full Enrollment Requests.
全登録要求は、ほとんどの機能と柔軟性を提供します。登録時にクライアントが完全な登録要求メッセージを使用すべきです。サーバーは、完全な登録要求メッセージをサポートしなければなりません。 （完全または必要に応じて簡単な）登録応答は、すべての完全な登録要求に返さなければなりません。
The Full Enrollment Request message consists of a PKIData object wrapped in a signedData CMS object. The objects in the PKIData are ordered as follows:
全登録要求メッセージは、CMSたsignedDataオブジェクトに包まれPKIDataオブジェクトで構成されています。次のようにPKIData内のオブジェクトを注文されています。
1. All Control Attributes, 2. All certification requests, 3. All CMS objects, 4. All other messages.
1.すべてのコントロールは、2.すべての認証要求、3。すべてのCMSオブジェクト、4.他のすべてのメッセージ属性。
Each element in a Full Enrollment Request is identified by a Body Part Identifier. If duplicate ids are found, the server MUST return the error badRequest with a bodyPartID of 0.
全登録要求内の各要素は、身体各部の識別子によって識別されます。重複したIDが発見された場合、サーバは0のbodyPartIDでエラーbadRequestを返さなければなりません。
The signedData object wrapping the PKIData may be signed either by the private key material of the signature certification request, or by a previously certified signature key. If the private key of a signature certification request is being used, then: a) the certification request containing the corresponding public key MUST include a Subject Key Identifier extension request, b) the subjectKeyIdentifier form of signerInfo MUST be used, and c) the value of the subjectKeyIdentifier form of signerInfo MUST be the Subject Key Identifier specified in the corresponding certification request.
PKIDataラッピングSignedDataオブジェクトは、署名証明書要求の秘密鍵材料によって、又は以前に認定された署名キーのいずれかによって署名されてもよいです。署名証明書要求の秘密鍵が使用されている場合、その後は、a）対応する公開鍵を含む証明書要求は、B）のSignerInfoのsubjectKeyIdentifierフォームを使用しなければならない、そしてc）値サブジェクト鍵識別子拡張要求を含まなければなりませんSignerInfoのsubjectKeyIdentifier形の対応する認証要求で指定されたサブジェクト鍵識別子でなければなりません。
(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 object in the signedData object.
（証明書がまだ署名鍵のために発行されていないためのSignerInfoのsubjectKeyIdentifierフォームがここで使用されます。）要求キーが署名に使用されている場合は、SignedDataオブジェクトで唯一のSignerInfoオブジェクトがあるに違いありません。
When creating a message to renew a certificate, the following should be taken into consideration:
証明書を更新するメッセージを作成するときは、以下を考慮する必要があります。
1. The identification and identityProof control statements are not required. The same information is provided by the use of an existing certificate from the CA when signing the enrollment message. 2. CAs and LRAs may impose additional restrictions on the signing certificate used. They may require that the most recently issued signing certificate for an entity be used. 3. A renewal message may occur either by creating a new set of keys, or by re-using an existing set of keys. Some CAs may prevent re-use of keys by policy. In this case the CA MUST return NOKEYREUSE as the failure code.
1.識別およびidentityProof制御ステートメントは必要とされません。同じ情報は、登録メッセージに署名CAから既存の証明書を使用することによって提供されます。 2. CAとLRAは使用署名証明書の追加の制限を課すことができます。彼らは、エンティティのための最も最近発行された署名証明書を使用することを要求することができます。 3.更新メッセージは、鍵の新しいセットを作成することによって、またはキーの既存のセットを再使用することによってのいずれかで起こり得ます。一部のCAは、ポリシーによって、キーの再使用を防止することがあります。この場合、CAは、故障コードとしてNOKEYREUSEを返さなければなりません。
Servers SHOULD use the simple enrollment response message whenever possible. Clients MUST be able to process the simple enrollment response message. The simple enrollment response message consists of a signedData object with no signerInfo objects on it. The certificates requested are returned in the certificate bag of the signedData object.
サーバーは、可能な限り簡単な登録応答メッセージを使用すべきです。クライアントは、簡単な登録応答メッセージを処理できなければなりません。簡単な登録応答メッセージは、その上に無いのSignerInfoオブジェクトとSignedDataオブジェクトで構成されています。要求された証明書は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 self-signed certificates, 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 explicitly trust the certificate.
クライアントは、証明書がどのような順序であると仮定してはいけません。サーバは、一つ以上の自己署名証明書だけでなく、新たに発行された証明書（複数可）への完全な鎖を形成するために必要なすべての中間証明書を含むべきです。サーバーは、さらにCRL袋にCRLを返してもよいです。サーバーは、自己署名証明書を含むかもしれません。クライアントは、暗黙のうちに過ぎないため、証明書袋でのプレゼンスに含まれる自己署名証明書を信頼してはなりません。イベントでは、クライアントがサーバから新しい自己署名証明書を受け取り、クライアントが明示的に証明書を信頼することを可能にするメカニズムを提供する必要があります。
Servers MUST return full PKI response messages if a) a full PKI request message failed or b) additional services other than returning certificates are required. Servers MAY return full PKI responses with failure information for simple PKI requests. Following section 4.3 above, servers returning only certificates and a success status to the client SHOULD use the simple PKI response message.
a）は、完全なPKI要求メッセージが失敗したか、またはb）の証明書を返す以外の追加サービスが必要な場合、サーバーは、完全なPKI応答メッセージを返さなければなりません。サーバーは、単純なPKI要求のための障害情報との完全なPKI応答を返してもよいです。上記のセクション4.3に続いて、クライアントにのみ証明書と成功ステータスを返すサーバは、単純なPKI応答メッセージを使用すべきです。
Clients MUST be able to process a full PKI response message.
クライアントは、完全なPKI応答メッセージを処理できなければなりません。
The full enrollment response message consists of a signedData object encapsulating a responseBody object. In a responseBody object all Control Attributes MUST precede all CMS objects. The certificates granted in an enrollment response are returned in the certificates field of the immediately encapsulating signedData object.
完全な登録応答メッセージはresponseBodyオブジェクトをカプセル化するSignedDataオブジェクトで構成されています。 responseBodyオブジェクト内のすべてのコントロールは、すべてのCMSオブジェクトを先行しなければならない属性。登録応答に付与された証明書はすぐにカプセル化するSignedDataオブジェクトの証明書フィールドに返されます。
Clients MUST NOT assume the certificates are in any order. Servers SHOULD include all intermediate certificates needed to form complete chains one ore more self-signed certificates, 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 explicitly trust the certificate.
クライアントは、証明書がどのような順序であると仮定してはいけません。サーバーは、完全なチェーン1つ以上の自己署名証明書だけでなく、新たに発行された証明書（複数可）を形成するのに必要なすべての中間証明書を含むべきです。サーバーは、さらにCRL袋にCRLを返してもよいです。サーバーは、自己署名証明書を含むかもしれません。クライアントは、暗黙のうちに過ぎないため、証明書袋でのプレゼンスに含まれる自己署名証明書を信頼してはなりません。イベントでは、クライアントがサーバから新しい自己署名証明書を受け取り、クライアントが明示的に証明書を信頼することを可能にするメカニズムを提供する必要があります。
There are occasions where a PKI request or response message must be encrypted in order to prevent any information about the enrollment from being accessible to unauthorized entities. This section describes the means used to encrypt a PKI message. This section is not applicable to a simple enrollment message.
PKI要求や応答メッセージが不正なエンティティにアクセス可能であることから入学に関するあらゆる情報を防ぐために暗号化されなければならない場面があります。このセクションでは、PKIメッセージを暗号化するために使用する手段が記載されています。このセクションでは、簡単な登録メッセージには適用されません。
Confidentiality is provided by wrapping the PKI message (a signedData object) in a CMS EnvelopedData object. 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 objects. It is recommended that if an enveloped data layer is applied to a PKI message, a second signing layer be placed outside of the enveloped data layer. The following figure shows how this nesting would be done:
機密性は、CMS EnvelopedDataのオブジェクト内のPKIメッセージ（SignedDataオブジェクト）を包むことによって提供されます。 EnvelopedDataでネストされたコンテンツタイプは、ID-たsignedDataです。これは暗号化され署名されたデータ・オブジェクトとの間に配置されたMIMEの層が存在するS / MIMEとは異なることに留意されたいです。なお、エンベロープデータ層はPKIメッセージに適用される場合、第二の署名層はエンベロープデータ層の外側に配置することが推奨されます。次の図は、このネストが行われることになる方法を示しています。
Normal Option 1 Option 2
------ -------- --------
SignedData EnvelopedData SignedData
PKIData SignedData EnvelopedData
PKIData SignedData
PKIData
Options 1 and 2 provide the benefit of preventing leakage of sensitive data by encrypting the information. LRAs can remove the enveloped data wrapping, and replace or forward without further processing. Section 6 contains more information about LRA processing.
オプション1と2は、情報を暗号化することにより、機密データの漏洩を防止することの利点を提供します。 LRAははエンベロープデータの折り返しを取り外し、交換またはさらに処理せずに転送することができます。第6節は、LRAの処理に関する詳細情報が含まれています。
PKI Messages MAY be encrypted or transmitted in the clear. Servers MUST provided support for all three versions.
PKIメッセージは、暗号化またはクリアに伝送することができます。サーバーはすべての3つのバージョンのサポートを提供しなければなりません。
Alternatively, an authenticated, secure channel could exist between the parties requiring encryption. Clients and servers MAY use such channels instead of the technique described above to provide secure, private communication of PKI request and response messages.
また、認証された、セキュアなチャネルは、暗号化を必要とする関係者の間に存在する可能性があります。クライアントとサーバーはPKI要求と応答メッセージの安全な、プライベートな通信を提供する代わりに、上記の技術のようなチャネルを使用するかもしれません。
Control attributes are carried as part of both PKI requests and responses. Each control attribute is encoded as a unique Object Identifier followed by that data for the control attribute. The encoding of the data is based on the control attribute object identifier. Processing systems would first detect the OID and process the corresponding attribute value prior to processing the message body.
コントロールの属性はPKI要求と応答の両方の一環として実施しています。各制御属性は、制御属性のためのデータが続く一意のオブジェクト識別子として符号化されます。データの符号化を制御する属性オブジェクト識別子に基づいています。処理システムは、第OIDを検出し、メッセージ本文を処理する前に対応する属性値を処理することになります。
The following table lists the names, OID and syntactic structure for each of the control attributes documented in this memo.
次の表は、このメモに記載さ制御属性ごとに名前、OIDと構文構造を示しています。
Control Attribute OID Syntax
----------------- ---------- --------------
cMCStatusInfo id-cmc 1 CMCStatusInfo
identification id-cmc 2 UTF8String
identityProof id-cmc 3 OCTET STRING
dataReturn id-cmc 4 OCTET STRING
transactionId id-cmc 5 INTEGER
senderNonce id-cmc 6 OCTET STRING
recipientNonce id-cmc 7 OCTET STRING
addExtensions id-cmc 8 AddExtensions
encryptedPOP id-cmc 9 EncryptedPOP
decryptedPOP id-cmc 10 DecryptedPOP
lraPOPWitness id-cmc 11 LraPOPWitness
getCert id-cmc 15 GetCert
getCRL id-cmc 16 GetCRL
revokeRequest id-cmc 17 RevokeRequest
regInfo id-cmc 18 OCTET STRING
responseInfo id-cmc 19 OCTET STRING
QueryPending id-cmc 21 OCTET STRING
idPOPLinkRandom id-cmc 22 OCTET STRING
idPOPLinkWitness id-cmc 23 OCTET STRING
idConfirmCertAcceptance id-cmc 24 CMCCertId
The CMC status info control is used in full PKI Response messages to return information on a client request. 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 response message. This statement uses the following ASN.1 definition:
CMCのステータス情報コントロールは、クライアントの要求に応じて情報を返すために、完全なPKI応答メッセージに使用されています。サーバーは、単一の身体の部分を参照する複数のCMCのステータス情報のコントロールを放出することができます。クライアントは、応答メッセージで複数のCMCのステータス情報のコントロールに対処できなければなりません。この文は、次のASN.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 is described in section 5.1.1
- cMCStatusは、セクション5.1.1に記載されています
-- bodyList contains the list of body parts in the request message to which this status information applies. If an error is being returned for a simple enrollment message, body list will contain a single integer of value '1'.
- バディリストは、このステータス情報が適用される要求メッセージでボディパーツのリストが含まれています。エラーは、簡単な登録メッセージのために返されている場合は、体のリストは、値の単一の整数が含まれています「1」。
-- statusString contains a string with additional description information. This string is human readable.
- statusStringは、追加の記述情報を持つ文字列が含まれています。この文字列は、人間が読める形式です。
-- failInfo is described in section 5.1.2. It provides a detailed error on what the failure was. This choice is present only if cMCStatus is failed.
- failInfoは、セクション5.1.2に記載されています。それは失敗が何であったかについての詳細なエラーを提供します。この選択はcMCStatusが失敗した場合にのみ存在しています。
-- pendToken is the token to be used in the queryPending control attribute.
- pendTokenはqueryPending制御属性で使用されるトークンです。
-- pendTime contains the suggested time the server wants to be queried about the status of the request.
- pendTimeは、サーバが要求の状況について質問したいの提案の時間が含まれています。
If the cMCStatus field is success, the CMC Status Info Control MAY be omitted unless it is only item in the response message. If no status exists for a certificate request or other item requiring processing, then the value of success is to be assumed.
cMCStatusフィールドが成功であれば、それは、応答メッセージにのみの項目でない限り、CMCステータス情報コントロールを省略することができます。いかなる状況が証明書要求または処理を必要とする他の項目のために存在しない場合は、成功の値が想定されます。
CMCStatus is a field in the CMCStatusInfo structure. This field contains a code representing the success or failure of a specific operation. CMCStatus has the ASN.1 structure of:
CMCStatusはCMCStatusInfo構造体のフィールドです。このフィールドは、特定の操作の成功または失敗を示すコードが含まれています。 CMCStatusは、ASN.1の構造を有します：
CMCStatus ::= INTEGER {
success (0),
-- request was granted
-- reserved (1),
-- not used, defined where the original structure was defined
failed (2),
-- you don't get what you want, more information elsewhere in
the message
pending (3),
-- the request body part has not yet been processed,
-- requester is responsible to poll back on this
-- pending may only be return for certificate request
operations.
noSupport (4),
-- the requested operation is not supported
confirmRequired (5)
-- conformation using the idConfirmCertAcceptance control is required -- before use of certificate }
- }証明書の使用前 - idConfirmCertAcceptanceコントロールを使用してコンフォメーションが必要です
CMCFailInfo conveys information relevant to the interpretation of a failure condition. The CMCFailInfo has the following ASN.1 structure:
CMCFailInfoは、障害状態の解釈に関連する情報を伝えます。 CMCFailInfoは以下のASN.1構造を有しています。
CMCFailInfo ::= INTEGER {
badAlg (0)
-- Unrecognized or unsupported algorithm
badMessageCheck (1)
-- integrity check failed
badRequest (2)
-- transaction not permitted or supported
badTime (3)
-- Message time field was not sufficiently close to the system
time
badCertId (4)
-- No certificate could be identified matching the provided
criteria
unsuportedExt (5)
-- A requested X.509 extension is not supported by the
recipient CA.
mustArchiveKeys (6)
-- Private key material must be supplied
badIdentity (7)
-- Identification Attribute failed to verify
popRequired (8)
-- Server requires a POP proof before issuing certificate
popFailed (9)
-- POP processing failed
noKeyReuse (10)
-- Server policy does not allow key re-use
internalCAError (11)
tryLater (12)
}
Additional failure reasons MAY be defined for closed environments with a need.
追加の失敗の理由が必要で、閉じた環境のために定義されるかもしれません。
Some CAs and LRAs 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 people are familiar with the request of a bank to provide your mother's maiden name as a form of identity proof.
一部のCAおよびLRAはは身元の証明が認証要求に含まれている必要があります。これを行うためのさまざまな方法は、セキュリティと信頼性の異なる程度で存在しています。ほとんどの人は身元証明の形態としてあなたの母親の旧姓を提供するために、銀行の要求に精通しています。
CMC provides one method of proving the client's identity based on a shared secret between the certificate requestor and the verifying authority. If clients support full request messages, clients MUST implement this method of identity proof. Servers MUST provide this method and MAY also have a bilateral method of similar strength available.
CMCは、証明書の要求者と検証機関の間の共有秘密に基づいて、クライアントの身元を証明する1つの方法を提供します。クライアントは、完全な要求メッセージをサポートしている場合、クライアントは身元証明のこのメソッドを実装しなければなりません。サーバーは、このメソッドを提供しなければならないし、また、利用できる同様の強度の二国間の方法を持っているかもしれません。
The CMC method starts with an out-of-band transfer of a token (the shared secret). The distribution of this token is beyond the scope of this document. The client then uses this token for an identity proof as follows:
CMC方法は、トークン（共有シークレット）のアウトオブバンド転送始まります。このトークンの分布は、このドキュメントの範囲を超えています。次のようにクライアントは、身元証明のために、このトークンを使用しています。
1. The reqSequence field of the PKIData object (encoded exactly as it appears in the request message including the sequence type and length) is the value to be validated. 2. A SHA1 hash of the token is computed. 3. An HMAC-SHA1 value is then computed over the value produced in Step 1, as described in [HMAC], using the hash of the token from Step 2 as the shared secret value. 4. The 160-bit HMAC-SHA1 result from Step 3 is then encoded as the value of the identityProof attribute.
1. PKIDataオブジェクト（それが配列の型と長さを含む要求メッセージに表示されるとおりにコードされる）のreqSequenceフィールドが検証される値です。トークンの2 A SHA1ハッシュが計算されます。共有秘密値としてステップ2からのトークンのハッシュを使用して、[HMAC]で説明したように3アンHMAC-SHA1値は、次に、ステップ1で得た値にわたって計算されます。 4.ステップ3から160ビットのHMAC-SHA1結果は、その後identityProof属性の値として符号化されます。
When the server verifies the identityProof attribute, it computes the HMAC-SHA1 value in the same way and compares it to the identityProof attribute contained in the enrollment request.
サーバがidentityProof属性を検証すると、それは同じようにHMAC-SHA1値を計算し、登録要求に含まれるidentityProof属性と比較します。
If a server fails the verification of an identityProof attribute and the server returns a response message, the failInfo attribute MUST be present in the response and MUST have a value of badIdentity.
サーバがidentityProof属性の検証に失敗し、サーバーが応答メッセージを返す場合、failInfo属性が応答で存在しなければならないとbadIdentityの値を持たなければなりません。
Optionally, servers MAY require the inclusion of the unprotected identification attribute with an identification attribute. The identification attribute is intended to contain either a text string or a numeric quantity, such as a random number, which assists the server in locating the shared secret needed to validate the contents of the identityProof attribute. Numeric values MUST be converted to text string representations prior to encoding as UTF8-STRINGs in this attribute. If the identification control attribute is included in the message, the derivation of the shared secret in step 2 is altered so that the hash of the concatenation of the token and the identity value are hashed rather than just the token.
必要に応じて、サーバは、識別属性を持つ保護されていない識別属性を含めることが必要な場合があります。識別属性は、テキスト文字列またはそのようなidentityProof属性の内容を検証するために必要な共有秘密情報を見つけるのサーバを支援する乱数などの数値量、のいずれかを含むことを意図しています。数値は、この属性でUTF8-文字列として符号化の前にテキスト文字列表現に変換されなければなりません。識別制御属性がメッセージに含まれている場合、トークンの連結と同一の値のハッシュを単にトークンではなく、ハッシュ化されるように、ステップ2で共有秘密の派生が変更されます。
The shared secret between the end-entity and the identity verify is sometimes transferred using a hardware device that generates a series of tokens based on some shared secret value. The user can therefore prove their 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:
エンドエンティティと同一の間の共有秘密を確認し、時にはいくつかの共有秘密値に基づいてトークンの系列を生成するハードウェアデバイスを使用して転送されます。したがって、ユーザは、名前の文字列と一緒に平文でこのトークンを転送することによって、自分の身元を証明することができます。上記のプロトコルは、以下の変更によって、ハードウェア共有秘密トークン生成装置と共に使用することができます。
1. The identification attribute MUST be included and MUST contain the hardware-generated token. 2. The shared secret value used above is the same hardware-generated token. 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.
1.識別属性を含まなければなりませんとハードウェア生成されたトークンを含まなければなりません。 2.上記使用される共有秘密の値は、同じハードウェア生成されたトークンです。 3.すべての認証要求がサブジェクト名を持つ必要がありますし、サブジェクト名は、ハードウェアトークンデバイスの所有者を特定するために必要なフィールドを含まなければなりません。
In a PKI Full Request message identity information about the creator/author of the message is carried in the signature of the CMS SignedData object containing all of the certificate requests. Proof-of-possession information for key pairs requesting certification, however, is carried separately for each PKCS#10 or CRMF message. (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 5.7 below are used.) In order to prevent substitution-style attacks we must guarantee that the same entity generated both the POP and proof-of-identity information.
メッセージの作成者/著者に関するPKIのフル要求メッセージの識別情報で証明書の要求のすべてを含むCMS SignedDataオブジェクトの署名で運ばれます。認証を要求する鍵ペアの証明の所持情報、しかし、それぞれPKCS＃10またはCRMFメッセージを別々に実施されます。 （デジタル署名を生成することができる鍵のために、POPは、PKCS＃10またはCRMF要求に署名することによって提供される。セクションの下5.7に記載のコントロールが使用されている暗号化キーのみの場合。）置換スタイルの攻撃を防止するために私たちは、同じエンティティがPOPと実証の身元情報の両方を生成することを保証しなければなりません。
This section describes two mechanisms for linking identity and POP information: witness values cryptographically derived from the shared-secret (Section 5.3.1) and shared-secret/subject DN matching (Section 5.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 certificate request that can be directly associated with the shared-secret; this will defeat attempts to include certificate requests from different entities in a single Full PKI Request message.
証人の暗号共有秘密から導出される値（5.3.1項）と共有秘密/サブジェクトDNマッチング（セクション5.3.2）：このセクションでは、アイデンティティおよびPOP情報を連結するための2つのメカニズムを説明しています。クライアントとサーバーは、証人の価値技法をサポートしなければなりません。クライアントとサーバーは、共有秘密/サブジェクトDNマッチングや同様の強度の他の二国間の技術をサポートするかもしれません。両方のメカニズムの背後にある考え方は、直接共有秘密に関連付けることができ、各証明書要求に一部のデータに署名するためにクライアントを強制することです。これは、単一の完全なPKI Requestメッセージ内の異なるエンティティからの証明書要求を含めるしようとする試みを打ち負かすだろう。
The first technique for doing identity-POP linking works by forcing the client to include a piece of information cryptographically-derived from the shared-secret token as a signed extension within each certificate request (PKCS#10 or CRMF) message. 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 token out-of-band from the server. The client then computes the following values:
各証明書要求（PKCS＃10またはCRMF）メッセージ内の符号付き拡張として共有秘密トークンから暗号由来の情報の一部を含むようにクライアントを強制することによって識別-POP連結作業を行うための第一の技術。 （例えば、サーバのみ共有秘密に基づいて証明書のサブジェクトDNを生成することができ、ため）NULLサブジェクトDNが使用される場合、この技術は有用です。クライアントがサーバからの帯域外の共有秘密トークンを受信したときに処理が開始されます。次に、クライアントは、次の値を計算します。
1. The client generates a random byte-string, R, which SHOULD be at least 512 bits in length. 2. A SHA1 hash of the token is computed. 3. An HMAC-SHA1 value is then computed over the random value produced in Step 1, as described in [HMAC], using the hash of the token from Step 2 as the shared secret. 4. The random value produced in Step 1 is encoded as the value of an idPOPLinkRandom control attribute. This control attribute MUST be included in the Full PKI Request message. 5. The 160-bit HMAC-SHA1 result from Step 3 is encoded as the value of an idPOPLinkWitness extension to the certificate request. a. For CRMF, idPOPLinkWitness is included in the controls section of the CertRequest structure. b. For PKCS#10, idPOPLinkWitness is included in the attributes section of the CertificationRequest structure.
1.クライアントは、長さが少なくとも512ビットであるべきであるランダムなバイト列、Rを生成します。トークンの2 A SHA1ハッシュが計算されます。共有秘密として工程2からのトークンのハッシュを使用して、[HMAC]で説明したように3アンHMAC-SHA1値は、次に、ステップ1で作製したランダム値にわたって計算されます。 4.ステップ1で製造したランダム値がidPOPLinkRandom制御属性の値として符号化されます。この制御属性は、完全なPKI Requestメッセージに含まれなければなりません。 5.ステップ3から160ビットのHMAC-SHA1結果は、証明書要求にidPOPLinkWitness拡張の値として符号化されます。 A。 CRMFため、idPOPLinkWitnessはcertrequestコマンド構造の制御部に含まれています。 B。 PKCS＃10のために、idPOPLinkWitnessはCertificationRequest構造の属性セクションに含まれています。
Upon receipt, servers MUST verify that each certificate request contains a copy of the idPOPLinkWitness and that its value was derived in the specified manner from the shared secret and the random string included in the idPOPLinkRandom control attribute.
受信すると、サーバは、各証明書の要求はidPOPLinkWitnessのコピーが含まれ、その値が共有秘密から指定された方法で導出し、ランダムな文字列がidPOPLinkRandom制御属性に含まれていたことをことを確かめなければなりません。
The second technique for doing identity-POP linking 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 certificate request. It is expected that many client-server connections using shared-secret based proof-of-identity will use this mechanism. (It is common not to omit the subject DN information from the certificate request messages.)
アイデンティティ-POPのリンクを行うための第2の技術は、帯域外に分布し、身元を証明するために、共有シークレットを使用して、クライアントが正確なことを含めることを要求して、共有秘密に特定のサブジェクト識別名（サブジェクトDN）をリンクすることですすべての証明書の要求でサブジェクトDN。共有秘密に基づく実証のアイデンティティを使用して多くのクライアント - サーバ接続は、このメカニズムを使用することが期待されます。 （証明書要求メッセージからサブジェクトDN情報を省略することではないが一般的です。）
When the shared secret is generated and transferred out-of-band to initiate the registration process (Section 5.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 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 message, it MUST use these two pieces of information as follows:
共有秘密は、登録プロセス（セクション5.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 certificate request (PKCS#10 and/or CRMF) in the Full PKI Request. The subject names in the requests MUST NOT be null. 2. The client MUST include the identityProof control attribute (Section 5.2), derived from the shared secret, in the Full PKI Request.
1.クライアントは、それが完全なPKI Requestに（PKCS＃10及び/又はCRMF）すべての証明書要求にサブジェクト名として共有秘密鍵と一緒に受け取った特定被写体DNを含まなければなりません。リクエストでのサブジェクト名はNULLであってはなりません。 2.クライアントは、完全なPKI Requestに、共有秘密由来identityProof制御属性（5.2節）を含まなければなりません。
The server receiving this message MUST (a) validate the identityProof control attribute and then, (b) check that the subject DN included in each certificate request matches that associated with the shared secret. If either of these checks fails the certificate request MUST be rejected.
このメッセージを受信したサーバは、（A）identityProof制御属性を検証した後、（b）は、DNは、各証明書要求に含まれる被写体が共有される秘密に関連付けられたものと一致することをチェックしなければなりません。これらのチェックのいずれかが失敗した場合、証明書の要求を拒絶しなければなりません。
In a renewal or re-key message, the subject DN in (a) the certificate referenced by the CMS SignerInfo object, and (b) all certificate requests within the request message MUST match according to the standard name match rules described in [PKIXCERT].
（a）は、証明書がCMSのSignerInfoオブジェクトによって参照される、および（b）要求メッセージ内のすべての証明書の要求は[PKIXCERT]に記載されている標準名の一致規則に従って一致する必要があり、更新または再キーメッセージ、件名DNに。
The data return control attribute 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 enrollment response message. Data placed in a data return statement is considered to be opaque to the server. The same control is used for both requests and responses. If the data return statement appears in an enrollment message, the server MUST return it as part of the enrollment response message.
データ復帰制御属性は、クライアントがサーバに任意のデータ（内部状態情報の通常いくつかの種類）を送信すると、登録応答メッセージの一部として返されたデータを持つことができます。データreturn文に配置されたデータはサーバに不透明であると考えられています。同様の制御が要求と応答の両方のために使用されています。データreturn文は、登録メッセージに表示された場合、サーバは登録応答メッセージの一部としてそれを返さなければなりません。
In the event that the information in the data return statement 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.
データreturn文の情報は機密にする必要があるという場合には、クライアントが含まれているデータを暗号化のいくつかのタイプを適用することが期待されるが、これについての詳細は、この仕様の範囲外です。
An example of using this feature is for a client 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.
クライアントは、秘密鍵の材料の正確なソースをマーキング識別子を配置するために、この機能を使用する例です。これは、秘密鍵を含むハードウェアデバイスの識別子であるかもしれません。
The Add Extensions control attribute is used by LRAs in order to specify additional extensions that are to be placed on certificates. This attribute uses the following ASN.1 definition:
拡張機能を追加制御属性は、証明書の上に置くことになっている追加の拡張子を指定するために、LRAはで使用されています。この属性は、以下のASN.1定義を使用しています。
AddExtensions ::= SEQUENCE {
pkiDataReference BodyPartID
certReferences SEQUENCE OF BodyPartID,
extensions SEQUENCE OF Extension
}
-- pkiDataReference field contains the body part id of the embedded request message.
- pkiDataReferenceフィールドは、埋め込まれた要求メッセージのボディ部IDを含んでいます。
-- certReferences field is a list of references to one or more of the payloads contained within a PKIData. Each element of the certReferences sequence MUST be equal to either the bodyPartID of a TaggedCertificationRequest or the certReqId of the CertRequest within a CertReqMsg. By definition, the listed extensions are to be applied to every element referenced in the certReferences sequence. If a request corresponding to bodyPartID cannot be found, the error badRequest is returned referencing this control attribute.
- certReferencesフィールドはPKIData内に含まれるペイロードの一つ以上への参照のリストです。 certReferences配列の各要素はCertReqMsg内TaggedCertificationRequestのbodyPartID又はcertrequestコマンドのcertReqIdいずれかに等しくなければなりません。定義上、記載されている拡張子はcertReferences順番に参照されているすべての要素に適用されます。 bodyPartIDに対応するリクエストが見つからない場合は、エラーbadRequestは、この制御属性を参照して返されます。
-- extensions field contains the sequence of extensions to be applied to the referenced certificate requests.
- 拡張フィールドは、参照された証明書要求に適用される拡張子の配列を含みます。
Servers MUST be able to process all extensions defined in [PKIXCERT]. Servers are not required to be able to process every V3 X.509 extension transmitted using this protocol, nor are they required to be able to process other, private extensions. Servers are not required to put all LRA-requested extensions into a certificate. Servers are permitted to modify LRA-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 failInfo attribute with the value of unsupportedExt.
サーバは[PKIXCERT]で定義されたすべての拡張を処理できなければなりません。サーバーは、このプロトコルを使用して送信すべてのV3 X.509拡張を処理できるようにする必要はありません、また、彼らは他の、プライベート拡張を処理できるように要求されています。サーバは、証明書にすべてのLRA-要求された機能拡張を置く必要はありません。サーバーは、LRA-要求された拡張子を変更することが許可されています。クライアントが要求した拡張子の意味を逆にするように、認証要求が原因要求された拡張子を扱うことができないことに拒否され、応答が返された場合、サーバは、拡張子を変更してはいけません、サーバがの値でfailInfo属性を返さなければなりませんunsupportedExt。
If multiple Add Extensions statements exist in an enrollment message, the exact behavior is left up to the certificate issuer policy. However it is recommended that the following policy be used. These rules would be applied to individual extensions within an Add Extensions control attribute (as opposed to an "all or nothing" approach).
複数の追加拡張文が登録メッセージに存在する場合、正確な振る舞いは、証明書発行ポリシーに任されています。しかし、次のポリシーを使用することをお勧めします。これらのルールは、拡張機能を追加制御属性内の個々の拡張機能（「オール・オア・ナッシング」のアプローチではなく）に適用されます。
1. If the conflict is within a single PKIData object, the certificate request would be rejected with an error of badRequest.
1.競合が単一PKIDataオブジェクト内であれば、証明書要求はbadRequestのエラーで拒否されるであろう。
2. If the conflict is between different PKIData objects, the outermost version of the extension would be used (allowing an LRA to override the extension requested by the end-entyt).
2.競合が異なるPKIDataオブジェクトの間にある場合、拡張の最バージョンは、（エンドentytによって要求された拡張をオーバーライドするLRAを可能にする）使用されます。
Transactions are identified and tracked using a transaction identifier. If used, clients generate transaction identifiers and retain their value until the server responds with a message that completes the transaction. Servers correspondingly include received transaction identifiers in the response.
取引が識別され、トランザクション識別子を使用して追跡しています。使用している場合、クライアントは、トランザクション識別子を生成し、サーバがトランザクションを完了メッセージで応答するまで、その値を保持します。サーバは、それに応じて対応して受信したトランザクション識別子を含みます。
The transactionId attribute identifies a given transaction. It is used between client and server to manage the state of an operation. Clients MAY include a transactionID attribute in request messages. If the original request contains a transactionID attribute, all subsequent request and response messages MUST include the same transactionID attribute. A server MUST use only transactionIds in the outermost PKIdata object. TransactionIds on inner PKIdata objects are for intermediate entities.
TransactionId属性は、指定されたトランザクションを識別します。操作の状態を管理するために、クライアントとサーバの間で使用されています。クライアントが要求メッセージでトランザクションID属性を含むかもしれません。元の要求は、トランザクションID属性が含まれている場合は、後続のすべての要求と応答メッセージは、同じトランザクションID属性を含まなければなりません。サーバーは、最も外側のPKIdataオブジェクトにのみtransactionIdsを使用しなければなりません。インナーPKIdataオブジェクトのTransactionIdsは、中間エンティティのためのものです。
Replay protection can be supported through the use of sender and recipient nonces. If nonces are used, in the first message of a transaction, no recipientNonce is transmitted; a senderNonce is instantiated by the message originator and retained for later reference. The recipient of a sender nonce reflects this value back to the originator as a recipientNonce and includes it's own senderNonce. Upon receipt by the transaction originator of this message, the originator compares the value of recipientNonce to its retained value. If the values match, the message can be accepted for further security processing. The received value for senderNonce is also retained for inclusion in the next message associated with the same transaction.
リプレイ保護は、送信者と受信者のナンスを使用してサポートすることができます。ナンスを使用する場合、トランザクションの最初のメッセージで、何recipientNonceが送信されません。 senderNonceはメッセージ発信元によってインスタンス化し、後で参照するために保持されます。送信者ナンスの受信者はrecipientNonceとして戻って発信元に、この値を反映し、それが自分のsenderNonceだ含まれています。このメッセージのトランザクションオリジネータによって受信すると、発信者は、その保持値にrecipientNonceの値を比較します。値が一致した場合、メッセージは、さらに、セキュリティ処理のために受理することができます。 senderNonceのための受信された値は、同じトランザクションに関連付けられた次のメッセージに含めるために保持されます。
The senderNonce and recipientNonce attribute can be used to provide application-level replay prevention. Clients MAY include a senderNonce in the initial request message. Originating messages include only a value for senderNonce. If a message includes a senderNonce, the response MUST include the transmitted value of the previously received senderNonce as recipientNonce and include new value for senderNonce. A server MUST use only nonces in the outermost PKIdata object. Nonces on inner PKIdata objects are for intermediate entities.
senderNonceとrecipientNonce属性は、アプリケーション・レベルのリプレイ防止を提供するために使用することができます。クライアントは、最初の要求メッセージにsenderNonceを含むかもしれません。送信されたメッセージは、senderNonceのための唯一の値が含まれています。メッセージはsenderNonceが含まれている場合、応答はrecipientNonceとして以前に受信senderNonceの送信された値を含み、senderNonceの新しい値を含まなければなりません。サーバーは、最も外側のPKIdataオブジェクトにのみナンスを使用しなければなりません。インナーPKIdataオブジェクトのナンスは、中間エンティティのためのものです。
Everything described in this section is optional to implement, for both servers and clients. Servers MAY require this POP method be used only if another POP method is unavailable. Servers SHOULD reject all 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 an entity requesting a certificate for a public key 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 phases:
必然的に、暗号化キーのみのためのPOPは、4つの異なる段階があるので、1往復で行うことができません。
1. Client tells the server about the public component of a new encryption key pair. 2. Server sends the client a POP challenge, encrypted with the presented public encryption key, which the client must decrypt. 3. Client decrypts the POP challenge and sends it back to the server. 4. Server validates the decrypted POP challenge and continues processing the certificate request.
1.クライアントは、新しい暗号鍵ペアの公開コンポーネントをサーバに伝えます。 2.サーバは、クライアントが復号化する必要があります提示公開暗号鍵で暗号化クライアントPOPチャレンジを送信します。 3.クライアントは、POPチャレンジを復号化し、それをサーバに送り返します。 4.サーバーは、復号化されたPOPの課題を検証し、証明書要求の処理を継続します。
CMC defines two different attributes. 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 encryptedPOP attribute is used to send the encrypted challenge from the server to the client. As such, it is encoded as a tagged attribute within the controlSequence of a ResponseBody. (Note that we assume that the message sent in Step 1 above is an enrollment request and that the response in step 2 is a Full Enrollment Response including a failureInfo specifying that a POP is explicitly required, and providing the POP challenge in the encryptedPOP attribute.)
encryptedPOP属性は、サーバからクライアントに暗号化されたチャレンジを送信するために使用されます。このように、それがResponseBodyのcontrolSequence内のタグ付けされた属性として符号化されます。 （私たちは上記のステップ1で送信されたメッセージが登録要求であるとステップ2での応答はPOPが明示的に必要とされることを指定し、encryptedPOP属性にPOPチャレンジを提供failureInfo含む全登録応答であることをことを前提としています。 ）
EncryptedPOP ::= SEQUENCE {
request TaggedRequest,
cms contentInfo,
thePOPAlgID AlgorithmIdentifier,
witnessAlgID AlgorithmIdentifier,
witness OCTET STRING
}
｝
DecryptedPOP ::= SEQUENCE {
bodyPartID BodyPartID,
thePOPAlgID AlgorithmIdentifier,
thePOP OCTET STRING
}
The encrypted POP algorithm works as follows:
次のように暗号化されたPOPアルゴリズムは動作します：
1. The server generates a random value y and associates it with the request. 2. The server returns the encrypted pop with the following fields set: a. request is the certificate request in the original request message (it is included here so the client need not key a copy of the request), b. cms is an EnvelopedData object, the content type being id-data and the content being the value y. If the certificate request contains a subject key identifier (SKI) extension, then the recipient identifier SHOULD be the SKI. If the issuerAndSerialNumber form is used, the IsserName MUST be encoded as NULL and the SerialNumber as the bodyPartId of the certificate request, c. thePOPAlgID contains the algorithm to be used in computing the return POP value, d. witnessAlgID contains the hash algorithm used on y to create the field witness, e. witness contains the hashed value of y. 3. The client decrypts the cms field to obtain the value y. The client computes H(y) 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 message containing a CMCStatusInfo control attribute with failInfo value of popFailed. 4. The client creates the decryptedPOP as part of a new PKIData message. The fields in the decryptedPOP are: a. bodyPartID refers to the certificate request in the new enrollment message, b. thePOPAlgID is copied from the encryptedPOP, c. thePOP contains the possession proof. This value is computed by thePOPAlgID using the value y and request referenced in (4a). 5. The server then re-computes the value of thePOP from its cached value of y 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.
1.サーバーは、ランダムな値yを生成し、要求に関連付けます。 2.サーバが設定され、次のフィールドで暗号化されたポップを返します。リクエストは、元の要求メッセージ（クライアントが要求のコピーをキー入力する必要がないので、それがここに含まれる）、Bでの証明書の要求です。 CMSはEnvelopedDataのオブジェクト、コンテンツタイプビーイングIDのデータと値yであるコンテンツです。証明書要求は、対象キー識別子（SKI）拡張が含まれている場合、受信者識別子は、SKIであるべきです。 issuerAndSerialNumberフォームが使用される場合、IsserNameはNULLと証明書要求のbodyPartId、CなどのSerialNumberとして符号化されなければなりません。 thePOPAlgIDは戻りPOP値、Dの計算に使用するアルゴリズムが含まれています。 witnessAlgIDは、フィールド証人、Eを作成するには、yに使用されるハッシュアルゴリズムが含まれています。証人は、yのハッシュ値が含まれています。 3.クライアントは、値yを得るために、CMSフィールドを復号化します。クライアントはwitnessAlgIDを用いてH（y）を計算し、証人の値と比較します。値が比較しないか、復号化が成功しなかった場合、クライアントは、登録プロセスを中止しなければなりません。クライアントはpopFailedのfailInfo値とCMCStatusInfo制御属性を含む要求メッセージを送信することにより、プロセスを中止します。 4.クライアントは、新しいPKIDataメッセージの一部としてdecryptedPOPを作成します。 decryptedPOP内のフィールドは以下の通りです。 bodyPartIDは、新しい登録メッセージ、Bに証明書要求を指します。 thePOPAlgIDはencryptedPOP、Cからコピーされます。 thePOPは証拠所持が含まれています。この値は、（4A）で参照値yと要求を使用thePOPAlgIDによって計算されます。 5.サーバは、そのキャッシュされたyの値と要求から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. Clients MUST implement SHA-1 for witnessAlgID. Clients MUST implement HMAC-SHA1 for thePOPAlgID. The value of y is used as the secret value in the HMAC algorithm and the request referenced in (4a) is used as the data. If y is greater than 64 bytes, only the first 64 bytes of y are used as the secret.
thePOPAlgIDとwitnessAlgIDケアのためのアルゴリズムを定義するときwitnessAlgIDの結果はthePOPAlgIDで計算をショートカットするための有用な値ではないことを保証するために注意しなければなりません。クライアントはwitnessAlgIDのためにSHA-1を実装しなければなりません。クライアントはthePOPAlgIDのためにHMAC-SHA1を実装しなければなりません。 yの値は、HMACアルゴリズムで秘密値として使用され、（4A）で参照要求をデータとして使用されます。 yが64のバイトよりも大きい場合、Yの最初の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. This 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.) 2. For certificate 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 cert request structure. y should not be predictable based on knowledge of R, thus the use of a OWF like HMAC-SHA1.
1.サーバーは、すべての要求にわたって一定ランダムシードxを生成します。 （xの値は、通常、定期的に変更すること、その後短時間保持あろう。）2.証明書要求Rについて、サーバは、Yは、F（X、R）=計算します。 Fは、例えば、HMAC-SHA1（X、R）とすることができます。すべてのことは、無国籍のために重要だyは、唯一の既知の状態定数xと関数Fを用いて証明書リクエスト構造からの他の入力一貫して計算可能であることです。 YはR、HMAC-SHA1などOWFの従って使用の知識に基づいて予測可能であるべきではありません。
In an enrollment scenario involving an LRAs the CA may allow (or require) the LRA to perform the POP protocol with the entity requesting certification. In this case the LRA needs a way to inform the CA it has done the POP. This control attribute has been created to address this issue.
LRAはCAを含む登録シナリオでエンティティ要求認証とPOPプロトコルを実行するためのLRAを可能にする（または必要とする）ことができます。この場合、LRAは、それがPOPを行っているCAに通知する方法が必要です。この制御属性は、この問題に対処するために作成されています。
The ASN.1 structure for the LRA POP witness is as follows:
次のようにLRA POPの証人のためのASN.1構造は次のとおりです。
LraPopWitness ::= SEQUENCE {
pkiDataBodyid BodyPartID,
bodyIds SEQUENCE of BodyPartID
}
-- pkiDataBodyid field contains the body part id of the nested CMS body object containing the client's full request message. pkiDataBodyid is set to 0 if the request is in the current PKIRequest body.
- pkiDataBodyidフィールドは、クライアントの完全な要求メッセージを含むネストされたCMSボディオブジェクトのボディ部のIDが含まれています。要求は、現在のPKIRequest本体にある場合pkiDataBodyidは0に設定されています。
-- bodyIds contains a list of certificate requests for which the LRA has performed an out-of-band authentication. The method of authentication could be archival of private key material, challenge-response or other means.
- bodyIdsは、LRAは、アウトオブバンド認証を行っているため、証明書要求のリストが含まれています。認証の方法は、秘密鍵の材料、チャレンジ・レスポンスまたは他の手段のアーカイブである可能性があります。
If a certificate server does not allow for an LRA to do the POP verification, it returns an error of POPFAILURE. The CA MUST NOT start a challenge-response to re-verify the POP itself.
証明書サーバーがPOP検証を行うためにLRAを許可しない場合、それはPOPFAILUREのエラーを返します。 CAは、POP自体を再確認するためのチャレンジ・レスポンスを開始してはなりません。
Everything described in this section is optional to implement.
このセクションで説明するすべてが実装するためにオプションです。
The get certificate control attribute is used to retrieve previously issued certificates from a repository of certificates. A Certificate Authority, an LRA or an independent service may provide this repository. The clients expected to use this facility are those operating in a resource-constrained environment. (An example of a resource-constrained client would be a low-end IP router that does not retain its own certificate in non-volatile memory.)
GET証明書の制御属性は、証明書のリポジトリから以前に発行された証明書を取得するために使用されます。認証局、LRAまたは独立したサービスは、このリポジトリを提供することができます。この機能を使用することが期待クライアントがリソースに制約のある環境で動作したものです。 （リソースに制約のあるクライアントの例は、不揮発性メモリに独自の証明書を保持していないローエンドのIPルータになります。）
The get certificate control attribute has the following ASN.1 structure:
GET証明書の制御属性は以下のASN.1構造を有しています。
GetCert ::= SEQUENCE {
issuerName GeneralName,
serialNumber INTEGER }
The service responding to the request will place the requested certificate in the certificates field of a SignedData object. If the get certificate attribute is the only control in a Full PKI Request message, the response would be a Simple Enrollment Response.
リクエストに応答するサービスはSignedDataオブジェクトの証明書の分野で要求された証明書を配置します。 GET証明書属性は完全なPKI Requestメッセージでのみ制御された場合、レスポンスはシンプルな登録応答になります。
Everything described in this section is optional to implement.
このセクションで説明するすべてが実装するためにオプションです。
The get CRL control attribute is used to retrieve CRLs from a repository of CRLs. A Certification Authority, an LRA 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を取得するために使用されます。認証局、LRAまたは独立したサービスは、このリポジトリを提供することができます。この機能を使用することが期待クライアントが完全に展開ディレクトリが実行不可能または望ましくないのいずれかであるものです。
The get CRL control attribute has the following ASN.1 structure:
GETのCRL制御属性は以下のASN.1構造を有しています。
GetCRL ::= SEQUENCE {
issuerName Name,
cRLName GeneralName OPTIONAL,
time GeneralizedTime OPTIONAL,
reasons ReasonFlags OPTIONAL }
The fields in a GetCRL have the following meanings:
GetCRLのフィールドは以下の意味があります。
-- issuerName is the name of the CRL issuer.
- 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 service responding to the request will place the requested CRL in the crls field of a SignedData object. If the get CRL attribute is the only control in a full enrollment message, the response would be a simple enrollment response.
リクエストに応答するサービスはSignedDataオブジェクトのCRLの分野で要求されたCRLを配置します。取得CRL属性は完全な登録メッセージでのみ制御された場合、応答は、簡単な登録応答になります。
The revocation request control attribute is used to request that a certificate be revoked.
失効要求制御属性は、証明書が失効することを要求するために使用されます。
The revocation request control attribute has the following ASN.1 syntax:
失効要求制御属性は、次のASN.1構文があります。
RevRequest ::= SEQUENCE {
issuerName Name,
serialNumber INTEGER,
reason CRLReason,
invalidityDate GeneralizedTime OPTIONAL,
sharedSecret OCTET STRING OPTIONAL,
comment UTF8string OPTIONAL }
-- issuerName contains the issuerName of the certificate to be revoked.
- issuerNameは、失効する証明書のissuerNameが含まれています。
-- serialNumber contains the serial number of the certificate to be revoked
- のserialNumberは、証明書のシリアル番号を失効することが含まれてい
-- reason contains 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 contains 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 contains 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 contains a human readable comment.
- コメントは、人間が読めるコメントが含まれています。
For a revocation request to become a reliable object in the event of a dispute, a strong proof of originator authenticity is required. However, in the instance when an end-entity has lost use of its signature private key, it is impossible for the end-entity to produce a digital signature (prior to the certification of a new signature key pair). The RevRequest provides for the optional transmission from the end-entity to the CA of a shared secret that may be used as an alternative authenticator in the instance of loss of use. The acceptability of this practice is a matter of local security policy.
失効要求は、紛争が生じた場合における信頼性の対象となるためには、発信元の真正性の強い証拠が必要です。エンドエンティティは、（前に新しい署名鍵ペアの認証に）デジタル署名を生成するためしかし、エンドエンティティは、その署名秘密鍵の使用を失った場合に、それが不可能です。 RevRequestは、使用の損失のインスタンスに別のオーセンティケータとして使用することができる共有秘密のCAに対するエンドエンティティからの任意の伝送を提供します。このような行為の容認は、ローカルセキュリティポリシーの問題です。
(Note that in some situations a Registration Authority may be delegated authority to revoke certificates on behalf of some population within its scope control. In these situations the CA would accept the LRA's digital signature on the request to revoke a certificate, independent of whether the end entity still had access to the private component of the key pair.)
（、終了するかどうかの独立した証明書を失効する。いくつかの状況では登録機関は、その範囲制御内の一部の住民に代わって証明書を失効する権限を委任することができることに注意してくださいこのような状況では、CAは、リクエストに応じてLRAのデジタル署名を受け入れるだろうエンティティは、まだ鍵ペアのプライベートコンポーネントへのアクセスを持っていました。）
Clients MUST provide the capability to produce a digitally signed revocation request control attribute. Clients SHOULD be capable of producing an unsigned revocation request containing the end-entity's shared secret. If a client provides shared secret based self-revocation, the client MUST be capable of producing a revocation request containing the shared secret. Servers MUST be capable of accepting both forms of revocation requests.
クライアントはデジタル署名された失効要求制御属性を生成する機能を提供しなければなりません。クライアントは、エンドエンティティの共有秘密を含む未署名の失効要求を生成することができるべきです。クライアントが共有秘密に基づく自己取消しを提供する場合、クライアントは共有シークレットを含む失効要求を生成することができなければなりません。サーバーは、失効要求の両方の形式を受け入れることができなければなりません。
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. The shared secret has a one-time use, that of causing the certificate to be revoked, 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 response message MUST be returned for a revocation request.
完全な応答メッセージは、失効要求に対して返さなければなりません。
The regInfo control attribute is for clients and LRAs to pass additional information as part a PKI request. The regInfo control attribute uses the ASN.1 structure:
クライアントとLRAははPKI要求一環として、追加の情報を渡すためREGINFO制御属性があります。 REGINFO制御属性は、ASN.1構造を使用しています。
RegInfo ::= OCTET STRING
The content of this data is based on bilateral agreement between the client and server.
このデータの内容は、クライアントとサーバの間の二国間の合意に基づいています。
If a server (or LRA) needs to return information back to a requestor in response to data submitted in a regInfo attribute, then that data is returned as a responseInfo control attribute. The content of the OCTET STRING for response information is based on bilateral agreement between the client and server.
サーバ（またはLRA）はREGINFO属性に提出されたデータに応じて、要求元に戻って情報を返すために必要がある場合、そのデータはresponseInfo制御属性として返されます。応答情報のためのオクテット文字列の内容は、クライアントとサーバの間の二国間の合意に基づいています。
In some environments, process requirements for manual intervention or other identity checking can cause a delay in returning the certificate related to a certificate request. The query pending attribute allows for a client to query a server about the state of a pending certificate request. The server returns a token as part of the CMCStatusInfo attribute (in the otherInfo field). The client puts the token into the query pending attribute to identify the correct request to the server. The server can also return a suggested time for the client to query for the state of a pending certificate request.
一部の環境では、手動の介入や他のIDチェックのためのプロセス要件は、証明書要求に関連した証明書を返すの遅延を引き起こす可能性があります。クライアントは、保留中の証明書の要求の状態についてのサーバーを照会するためのクエリ保留属性ができます。サーバは、（otherInfoフィールド内）CMCStatusInfo属性の一部としてトークンを返します。クライアントは、サーバへの正しい要求を識別するために、クエリ保留属性にトークンを置きます。また、サーバは、クライアントが保留中の証明書の要求の状態を照会するために提案された時間を返すことができます。
The ASN.1 structure used by the query pending control attribute is:
クエリ保留制御属性で使用されるASN.1構造は次のとおりです。
QueryPending ::= OCTET STRING
If a server returns a pending state (the transaction is still pending), the otherInfo MAY be omitted. If it is not omitted then the same value MUST be returned (the token MUST NOT change during the request).
サーバは（トランザクションがまだ保留中である）保留状態を返した場合、otherInfoを省略することができます。それが省略されていない場合は、同じ値が（トークンが要求中に変えてはいけません）が返されなければなりません。
Some Certification Authorities require that clients give a positive conformation that the certificates issued to it are acceptable. The Confirm Certificate Acceptance control attribute is used for that purpose. If the CMCStatusInfo on a certificate request is confirmRequired, then the client MUST return a Confirm Certificate
一部の証明機関は、クライアントがそれに発行された証明書が許容されている正の立体構造を与えることが必要です。確認証明書受付制御属性は、その目的のために使用されています。証明書の要求にCMCStatusInfoがconfirmRequiredされている場合、クライアントは、確認証を返さなければなりません
Acceptance prior to any usage of the certificate. Clients SHOULD wait for the response from the server that the conformation has been received.
証明書のいずれかの使用法に先立って受け入れ。クライアントは、立体構造が受信されたサーバーからの応答を待つ必要があります。
The confirm certificate acceptance structure is:
確認証明書の受け入れ構造は次のとおりです。
CMCCertId ::= IssuerSerial
-- CMCCertId contains the issuer and serial number of the certificate being accepted.
- CMCCertIdは、証明書の発行者とシリアル番号が受け入れられているが含まれています。
Servers MUST return a full enrollment response for a confirm certificate acceptance control.
サーバは確認証明書の受け入れ制御のための完全な登録応答を返さなければなりません。
This specification permits the use of Local Registration Authorities (LRAs). An LRA sits between the end-entity and the Certification Authority. From the end-entity's perspective, the LRA appears to be the Certification Authority and from the server the LRA appears to be a client. LRAs receive the enrollment messages, perform local processing and then forward onto Certificate Authorities. Some of the types of local processing that an LRA can perform include:
この仕様は、ローカル登録機関（LRAは）を使用することが可能になります。 LRAは、エンドエンティティおよび認証局の間に位置します。エンドエンティティの観点から、LRAは、認証局であるように思われると、サーバーからLRAは、クライアントのように見えます。 LRAは、登録メッセージは、認証局への前方、ローカル処理を実行し、受信します。 LRAが実行できるローカル処理の種類のいくつかは、次のとおりです。
- batching multiple enrollment messages together, - challenge/response POP proofs, - addition of private or standardized certificate extensions to all requests, - archival of private key material, - routing of requests to different CAs.
- 、一緒に複数登録メッセージをバッチ処理 - チャレンジ/レスポンスPOPプルーフ、 - すべての要求にプライベートまたは標準化された証明書拡張の追加、 - 異なるCAへの要求のルーティング - 秘密鍵の材料、のアーカイブ。
When an LRA receives an enrollment message it has three options: it may forward the message without modification, it may add a new wrapping layer to the message, or it may remove one or more existing layers and add a new wrapping layer.
LRAは、登録メッセージを受信した場合には、3つのオプションがあります：それは、メッセージに新しいラッピング層を追加することができ、またはそれは1つの以上の既存の層を除去し、新しいラッピング層を追加することができ、変更せずにメッセージを転送することができます。
When an LRA adds a new wrapping layer to a message it creates a new PKIData object. The new layer contains any control attributes required (for example if the LRA does the POP proof for an encryption key or the addExtension control attribute to modify an enrollment request) and the client enrollment message. The client enrollment message is placed in the cmsSequence if it is a Full Enrollment message and in the reqSequence if it is a Simple Enrollment message. If an LRA is batching multiple client messages together, then each client enrollment message is placed into the appropriate location in the LRA's PKIData object along with all relevant control attributes.
LRAはメッセージに新しいラッピング層を追加するとき、それは新しいPKIDataオブジェクトを作成します。クライアント登録メッセージ（LRAは、暗号化キーまたは登録要求を修正するaddExtension制御属性のためのPOPの証明を行う場合など）、新しい層は、必要な制御属性が含まれています。それは簡単な登録メッセージであれば、それは完全な登録メッセージとreqSequenceであれば、クライアントの登録メッセージがcmsSequenceに配置されます。 LRAは、一緒に複数のクライアントメッセージをバッチ処理されている場合、各クライアントの登録メッセージは、すべての関連する制御属性とともにLRAのPKIDataオブジェクト内の適切な位置に配置されます。
(If multiple LRAs are in the path between the end-entity and the Certification Authority, this will lead to multiple wrapping layers on the message.)
（複数のLRAは、エンドエンティティと認証局の間のパスにある場合、これは、メッセージに複数の包装層につながります。）
In processing an enrollment message, an LRA MUST NOT alter any certificate request body (PKCS #10 or CRMF) as any alteration would invalidate the signature on the request and thus the POP for the private key.
リクエストと秘密鍵のためのこのようPOP上の署名が無効になる登録メッセージを処理する際に、LRAは、任意の変更のような任意の証明書要求体（PKCS＃10またはCRMF）を変更してはなりません。
An example of how this would look is illustrated by the following figure:
これがどのように見えるかの例を次の図で示されています：
SignedData (by LRA) PKIData controlSequence LRA added control statements reqSequence Zero or more Simple CertificationRequests from clients cmsSequence Zero or more Full PKI messages from clients SignedData (by client) PKIData
SignedData（LRAによる）PKIData controlSequence LRAは、（クライアントによって）クライアントのSignedDataからクライアントcmsSequenceゼロ以上のフルPKIメッセージからの制御文reqSequenceゼロ以上のシンプルCertificationRequestsを追加しましたPKIData
Under some circumstances an LRA is required to remove wrapping layers. The following sections look at the processing required if encryption layers and signing layers need to be removed.
いくつかの状況下ではLRAは、ラッピング層を除去する必要があります。暗号化層と署名層を除去する必要がある場合は、次のセクションでは、必要な処理を見てください。
There are two cases that require an LRA to remove or change encryption in an enrollment message. In the first case the encryption was applied for the purposes of protecting the entire enrollment request from unauthorized entities. If the CA does not have a recipient info entry in the encryption layer, the LRA MUST remove the encryption layer. The LRA MAY add a new encryption layer with or without adding a new signing layer.
登録メッセージに暗号化を削除または変更するには、LRAが必要な2つのケースがあります。最初のケースでは暗号化は不正なエンティティから全体の登録要求を保護する目的のために適用しました。 CAは、暗号化層内の受信者情報のエントリを持っていない場合は、LRAは、暗号化層を除去しなければなりません。 LRAはとか、新しい署名層を追加することなく、新しい暗号化層を追加するかもしれません。
The second change of encryption that may be required is to change the encryption inside of a signing layer. In this case the LRA 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 LRA. If the signing layer provided by the end-entity needs to be removed to the LRA can remove the layer.
必要とされ得る暗号化の第2の変更は、署名層の内部に暗号化を変更することです。この場合、LRAは、暗号化を含むすべての署名層を除去しなければなりません。各署名層を除去し、得られたマージされたコントロールがLRAによって提供される新しい署名層に置かなければならないように、すべての制御ステートメントは、ローカルポリシールールに従ってマージされなければなりません。エンドエンティティによって提供される署名層は、LRAに除去する必要がある場合に層を除去することができます。
Only two instances exist where an LRA should remove a signature layer on a Full Enrollment message. If an encryption needs to be modified within the message, or if a Certificate Authority will not accept secondary delegation (i.e. multiple LRA signatures). In all other situations LRAs SHOULD NOT remove a signing layer from a message.
LRAは、完全登録メッセージに署名層を除去しなければならない場合のみ2つのインスタンスが存在します。暗号化は、メッセージ内で変更する必要がある場合、または認証機関は、二次委任（すなわち、複数LRA署名）を受け入れない場合。他のすべての状況ではLRAは、メッセージから署名層を削除しないでください。
If an LRA removes a signing layer from a message, 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 LRA.
LRAは、メッセージから署名層を除去する場合、すべての制御ステートメントは、ローカルポリシールールに従ってマージされなければなりません。得られたマージされた制御ステートメントは、LRAによって提供される新しい署名層に配置する必要があります。
Not all methods of transporting data allow for sending unlabeled raw binary data, in may cases standard methods of encoding can be used to greatly ease this issue. These methods normally consist of wrapping some identification of the content around the binary data, possibly applying an encoding to the data and labeling the data. We document for use three different wrapping methods.
データを輸送するではないすべてのメソッドは、5月のケースでは、符号化の標準的な方法が大幅にこの問題を緩和するために使用することができ、非標識生のバイナリデータを送信するための許可します。これらの方法は、通常、おそらくデータに符号化を適用し、データを標識する、バイナリデータの周囲のコンテンツのいくつかの識別を包装から成ります。我々は、使用するための3つの異なるラッピング方法を文書化します。
-- MIME wrapping is for transports that are natively MIME based such as HTTP and E-mail. -- Binary file transport is defined since floppy disk transport is still very common. File transport can be done either as MIME wrapped (section 7.1) or bare (section 7.2). -- Socket based transport uses the raw BER encoded object.
- MIMEラッピングはネイティブなHTTPやEメールとしてMIMEをベースとしているトランスポート用です。 - フロッピーディスクの輸送はまだ非常に一般的ですので、バイナリファイル転送が定義されています。ファイル転送は、どちらかのMIME包まれた（セクション7.1）、または裸（セクション7.2）とを行うことができます。 - ソケットベースのトランスポートは、生のBER符号化されたオブジェクトを使用します。
MIME wrapping is defined for those environments that are MIME native. These include E-Mail based protocols as well as HTTP.
MIMEラッピングは、MIMEのネイティブですこれらの環境のために定義されています。これらは、電子メールベースのプロトコルだけでなく、HTTPが含まれています。
The basic mime wrapping in this section is taken from [SMIMEV2] and [SMIMEV3]. Simple enrollment requests are encoded using the application/pkcs10 content type. A file name MUST be included either in a content type or content disposition statement. The extension for the file MUST be ".p10".
このセクションの基本的なMIMEラッピングは[SMIMEV3] [SMIMEV2]から取り出されています。簡単な登録要求は、アプリケーション/ PKCS10のコンテンツタイプを使用してエンコードされています。ファイル名は、いずれかのコンテンツタイプまたはコンテンツの処分計算書に含まれなければなりません。ファイルの拡張子は」.p10" でなければなりません。
Simple enrollment response messages MUST be encoded as content-type application/pkcs7-mime. An smime-type parameter MUST be on the content-type statement with a value of "certs-only." A file name with the ".p7c" extension MUST be specified as part of the content-type or content-disposition.
簡単な登録応答メッセージは、コンテンツタイプアプリケーション/ PKCS7-MIMEとして符号化されなければなりません。 SMIME-typeパラメータは、の値を持つコンテンツタイプステートメントになければなりません「本命だけ。」 「.p7c」拡張子のファイル名は、コンテンツタイプまたはコンテンツ・処分の一部として指定する必要があります。
Full enrollment request messages MUST be encoded as content-type application/pkcs7-mime. The smime-type parameter MUST be included with a value of "CMC-enroll". A file name with the ".p7m" extension MUST be specified as part of the content-type or content-disposition statement.
全登録要求メッセージは、コンテンツタイプアプリケーション/ PKCS7-MIMEでエンコードする必要があります。 SMIME-typeパラメータは、「CMC-な登録」の値に含まれなければなりません。 「.p7m」拡張子のファイル名は、コンテンツタイプまたはコンテンツ・処分文の一部として指定する必要があります。
Full enrollment response messages MUST be encoded as content-type application/pkcs7-mime. The smime-type parameter MUST be included with a value of "CMC-response." A file name with the ".p7m" extensions MUST be specified as part of the content-type or content-disposition.
完全な登録応答メッセージは、コンテンツタイプアプリケーション/ PKCS7-MIMEでエンコードする必要があります。 SMIME型パラメータの値に含まれなければならない「CMC-応答」。 「.p7m」の拡張子を持つファイル名は、コンテンツタイプまたはコンテンツ・処分の一部として指定する必要があります。
MIME TYPE File Extension SMIME-TYPE
MIMEタイプファイル拡張子SMIME-TYPE
application/pkcs10 .p10 N/A (simple PKI request)
アプリケーション/ PKCS10の.p10 N / A（単純なPKI要求）
application/pkcs7-mime .p7m CMC-request (full PKI request)
アプリケーション/ PKCS7-マイム.p7m CMC-要求（フルPKI要求）
application/pkcs7-mime .p7c certs-only (simple PKI response)
アプリケーション/ PKCS7-MIME .p7cの本命のみ（簡単なPKI応答）
application/pkcs7-mime .p7m CMC-response (full PKI response)
アプリケーション/ PKCS7-MIME .p7m CMC-応答（完全なPKI応答）
Enrollment messages and responses may also be transferred between clients and servers using file system-based mechanisms, such as when enrollment is performed for an off-line client. When files are used to transport binary, BER-encoded Full Enrollment Request and Response messages, the following file type extensions SHOULD be used:
登録メッセージと応答も、そのような登録がオフラインのクライアントのために実行されたときのように、ファイルシステムベースのメカニズムを使用して、クライアントとサーバ間で転送することができます。ファイルがバイナリ、BERエンコードされた全登録要求メッセージと応答メッセージを転送するために使用されている場合は、次のファイルの種類の拡張子を使用する必要があります。
Message Type File Extension
メッセージタイプのファイル拡張子
Full PKI Request .crq
完全なPKI要求.crq
Full PKI Response .crp
完全なPKI応答.crp
When enrollment messages and responses are sent over sockets, no wrapping is required. Messages SHOULD be sent in their binary, BER-encoded form.
登録メッセージと応答がソケット経由で送信された場合、何のラッピングは必要ありません。メッセージは、そのバイナリ、BER符号化された形式で送信されるべきです。
CMC clients and servers MUST be capable of producing and processing message signatures using the Digital Signature Algorithm [DSA]. DSA signatures MUST be indicated by the DSA AlgorithmIdentifier value (as specified in section 7.2.2 of [PKIXCERT]). PKI clients and servers SHOULD also be capable of producing and processing RSA signatures (as specified in section 7.2.1 of [PKIXCERT]).
CMCクライアントとサーバは、デジタル署名アルゴリズム[DSA]を使用してメッセージの署名を生成し、処理できなければなりません。 DSA署名は（[PKIXCERT]のセクション7.2.2で指定されるように）DSAのAlgorithmIdentifier値で示されなければなりません。 PKIクライアントとサーバは、（[PKIXCERT]のセクション7.2.1で指定されるように）RSA署名を生成し、処理することができなければなりません。
CMC clients and servers MUST be capable of protecting and accessing message encryption keys using the Diffie-Hellman (D-H) key exchange algorithm. D-H/3DES protection MUST be indicated by the D-H AlgorithmIdentifier value specified in [CMS]. PKI clients and servers SHOULD also be capable of producing and processing RSA key transport. When used for PKI messages, RSA key transport MUST be indicated as specified in section 7.2.1 of [PKIXCERT].
CMCクライアントとサーバは、ディフィー・ヘルマン（D-H）鍵交換アルゴリズムを使用してメッセージの暗号化キーを保護し、アクセス可能でなければなりません。 D-H / 3DES保護は[CMS]で指定されたD-HのAlgorithmIdentifier値で示されなければなりません。 PKIクライアントとサーバはまた、RSAキー・トランスポートを作成し、処理することが可能でなければなりません。 PKIメッセージのために使用される場合、RSA鍵の輸送は[PKIXCERT]のセクション7.2.1で指定されるように示されなければなりません。
A minimally compliant CMC server:
最小限に準拠したCMCサーバー：
a) MUST accept a Full PKI Request message i) MUST accept CRMF Request Bodies within a Full PKI Request ii) MUST accept PKCS#10 Request Bodies within a Full PKI Request b) MUST accept a Simple Enrollment Request message c) MUST be able to return a Full PKI Response. (A Full PKI Response is always a valid response, but for interoperability with downlevel clients a compliant server SHOULD use the Simple Enrollment Response whenever possible.)
A）iができなければならない）単純な登録要求メッセージCを受け入れなければならない）フルPKI要求B内のPKCS＃10要求体を受け入れなければならない）フルPKI要求II内CRMF要求体を受け入れなければならない）フルPKI Requestメッセージを受け入れなければなりません完全なPKI応答を返します。 （フルPKIレスポンスは常に有効な応答であるが、可能な限りダウンレベルクライアントとの相互運用性のために準拠したサーバーは、シンプルな登録応答を使用すべきです。）
A minimally-complaint CMC client:
最小限に苦情CMCクライアント：
a) MAY use either the Simple Enrollment Message or the Full PKI Request. i) clients MUST use PKCS#10 with the Simple Enrollment Message ii) clients MAY use either PKCS#10 or CRMF with the Full PKI Request b) MUST understand the Simple Enrollment Response. c) MUST understand the Full PKI Response.
a）のシンプルな登録メッセージまたは完全なPKI要求のいずれかを使用するかもしれません。 ⅰ）クライアントは、単純な登録応答を理解しなければならない）クライアントは完全なPKI要求BとPKCS＃10かCRMFのいずれかを使用する場合があります）簡単な登録メッセージIIとPKCS＃10を使用しなければなりません。 C）全PKI応答を理解する必要があります。
Initiation of a secure communications channel between an end-entity and a CA or LRA (and, similarly, between an LRA and another LRA or CA) necessarily requires an out-of-band trust initiation mechanism. For example, a secure channel may be constructed between the end-entity and the CA via IPSEC or TLS. Many such schemes exist and the choice of any particular scheme for trust initiation is outside the scope of this document. Implementers of this protocol are strongly encouraged to consider generally accepted principles of secure key management when integrating this capability within an overall security architecture.
（LRA別LRAまたはCAの間で同様と、）エンドエンティティとCAとの間の安全な通信チャネルの開始またはLRAは、必ずしもアウトオブバンド信頼開始機構を必要とします。例えば、安全なチャネルがエンドエンティティとIPSECまたはTLSを介してCAとの間に構成されてもよいです。多くのこのような制度が存在し、信託開始のための任意の特定の方式の選択は、この文書の範囲外です。このプロトコルの実装者が強く全体的なセキュリティアーキテクチャ内でこの機能を統合する際、安全な鍵管理の一般的に受け入れられた原則を考慮することが奨励されています。
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 attributes described in section 5.6. Developers of state-constrained PKI clients are strongly encouraged to incorporate the use of these attributes.
リプレイ攻撃を阻止するための機構は、運用環境に応じて、このプロトコルの特定の実装に必要になることがあります。 CAは、重要状態情報を維持する場合には、リプレイ攻撃は、オプションのナンス・メカニズムを含むことなく検出することができます。このプロトコルの実装者は慎重にセクション5.6で説明senderNonceとrecipientNonce属性を実装するかどうかを選択する前に、環境条件を考慮する必要があります。状態に制約のPKIクライアントの開発が強く、これらの属性の使用を組み込むことが奨励されています。
Under no circumstances should a signing key be archived. Doing so allows the archiving entity to potentially use the key for forging signatures.
いかなる状況においても、署名キーをアーカイブする必要があります。そうすることで、アーカイブエンティティが潜在的に署名を鍛造するためのキーを使用することができます。
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]. CMC implementations ought to be aware of this attack when doing parameter validations.
クライアントとサーバーは弱いのパラメータが使用されていないことを確認する証明書を発行する前に暗号化パラメータにいくつかのチェックを行う必要があります。小さなサブグループ攻撃の説明は、[X942]で提供されます。 CMCの実装は、パラメータの検証を行うときに、この攻撃に注意するべきです。
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", RFC 2630, June 1999.
[CMS] Housley氏、R.、 "暗号メッセージ構文"、RFC 2630、1999年6月。
[CRMF] Myers, M., Adams, C., Solo, D. and D. Kemp, "Internet X.509 Certificate Request Message Format", RFC 2511, March 1999.
[CRMF]マイヤーズ、M.、アダムス、C.、ソロ、D.とD.ケンプ、 "インターネットX.509証明書要求メッセージ形式"、RFC 2511、1999年3月。
[DH] B. Kaliski, "PKCS 3: Diffie-Hellman Key Agreement v1.4"
[DH] B. Kaliski、 "PKCS 3：のDiffie-Hellman鍵協定V1.4"
[DH-POP] H. Prafullchandra, J. Schaad, "Diffie-Hellman Proof-of-Possession Algorithms", Work in Progress.
[DH-POP] H. Prafullchandra氏、J. Schaad、 "ディフィー - ヘルマンプルーフ・オブ・所有アルゴリズム"、ProgressのWork。
[HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk、H.、ベラー、M。およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[PKCS1] Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5", RFC 2313, March 1998.
[PKCS1] Kaliski、B.、 "PKCS＃1：RSA暗号化、バージョン1.5"、RFC 2313、1998年3月。
[PKCS7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax v1.5", RFC 2315, October 1997.
[PKCS7] Kaliski、B.、 "PKCS＃7：暗号メッセージ構文のV1.5"、RFC 2315、1997年10月。
[PKCS8] RSA Laboratories, "PKCS#8: Private-Key Information Syntax Standard, Version 1.2", November 1, 1993.
[PKCS8] RSA Laboratories社、 "PKCS＃8：プライベート・キー情報構文規格、バージョン1.2"、1993年11月1日。
[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月。
[PKIXCERT] Housley, R., Ford, W., Polk, W. and D. Solo "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999.
[PKIXCERT] Housley氏、R.、フォード、W.、ポーク、W.およびD.ソロ "インターネットX.509公開鍵暗号基盤証明書とCRLプロファイル"、RFC 2459、1999年1月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[SMIMEV2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998.
【SMIMEV2] Dusse、S.、ホフマン、P.、Ramsdell、B.、Lundblade、L.及びL. Repka、 "S / MIMEバージョン2メッセージ仕様"、RFC 2311、1998年3月。
[SMIMEV3] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
【SMIMEV3] Ramsdell、B.、 "S / MIMEバージョン3メッセージ仕様"、RFC 2633、1999年6月。
[X942] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[X942]レスコラ、E.、 "ディフィー・ヘルマン鍵共有方式"、RFC 2631、1999年6月。
Michael Myers VeriSign Inc. 1350 Charleston Road Mountain View, CA, 94043
マイケル・マイヤーズベリサイン株式会社1350チャールストンロード、マウンテンビュー、CA、94043
Phone: (650) 429-3402 EMail: mmyers@verisign.com
電話：（650）429-3402 Eメール：mmyers@verisign.com
Xiaoyi Liu Cisco Systems 170 West Tasman Drive San Jose, CA 95134
Xiaoyi劉シスコシステムズ170西タスマン・ドライブサンノゼ、CA 95134
Phone: (480) 526-7430 EMail: xliu@cisco.com
電話：（480）526-7430 Eメール：xliu@cisco.com
Jim Schaad
ジムSchaad
EMail: jimsch@nwlink.com
メールアドレス：jimsch@nwlink.com
Jeff Weinstein
ジェフ・ワインスタイン
EMail: jsw@meer.net
メールアドレス：jsw@meer.net
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-cmc(6) }
EnrollmentMessageSyntax {ISO（1）同定された組織（3）DOD（4）インターネット（1）セキュリティ（5）mechansims（5）PKIX（7）ID-MOD（0）ID-MOD-CMC（6）}
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
輸入
-- Information Directory Framework (X.501) Name FROM InformationFramework { joint-iso-itu-t ds(5) modules(1) informationFramework(1) 3 }
- InformationFrameworkからの情報ディレクトリフレームワーク（X.501）名前{関節イソITU-TのDS（5）モジュール（1）informationFramework（1）3}
-- Directory Authentication Framework (X.509) AlgorithmIdentifier, AttributeCertificate, Certificate, CertificateList, CertificateSerialNumber FROM AuthenticationFramework { joint-iso-itu-t ds(5) module(1) authenticationFramework(7) 3 }
- ディレクトリ認証フレームワーク（X.509）のAlgorithmIdentifier、AttributeCertificate、証明書、CertificateListの、CertificateSerialNumber AuthenticationFramework FROM {関節イソITU-T DS（5）モジュール（1）authenticationFramework（7）3}
-- PKIX Part 1 - Implicit 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-88(2)}
- PKIXパート1 - 暗黙のGeneralName、CRLReason、PKIX1Implicit88 FROM ReasonFlags {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0 ）ID-pkix1-暗黙-88（2）}
-- PKIX Part 1 - Explicit SubjectPublicKeyInfo, Extension FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)}
- PKIXパート1 - 明示的SubjectPublicKeyInfoで、PKIX1Explicit88 {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）IDからの伸長-pkix1-明示-88（1）}
-- Cryptographic Message Syntax ContentInfo, Attribute FROM CryptographicMessageSyntax { 1 2 840 113549 1 9 16 0 1}
- 暗号メッセージ構文ContentInfo、暗号メッセージ構文{1 2 840 113549 1 9 16 0 1}から属性
-- CRMF CertReqMsg FROM CRMF { 1 3 6 1 5 5 7 0 5 };
- CRMF {1 3 6 1 5 7 0 5} FROM CRMF CertReqMsg。
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）}
id-cmc OBJECT IDENTIFIER ::= {id-pkix 7} -- CMC controls
id-cct OBJECT IDENTIFIER ::= {id-pkix 12} -- CMC content types
-- The following controls have simple type content (usually OCTET STRING)
- 次のコントロールは、単純なタイプのコンテンツを持っている（通常はオクテットSTRING）
id-cmc-identification OBJECT IDENTIFIER ::= {id-cmc 2}
id-cmc-identityProof OBJECT IDENTIFIER ::= {id-cmc 3}
id-cmc-dataReturn OBJECT IDENTIFIER ::= {id-cmc 4}
id-cmc-transactionId OBJECT IDENTIFIER ::= {id-cmc 5}
id-cmc-senderNonce OBJECT IDENTIFIER ::= {id-cmc 6}
id-cmc-recipientNonce OBJECT IDENTIFIER ::= {id-cmc 7}
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)
-- 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
}
｝
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 ::= 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-cMCStatusInfo OBJECT IDENTIFIER ::= {id-cmc 1}
CMCStatusInfo ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF INTEGER,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo, pendInfo PendInfo } OPTIONAL
}
PendInfo ::= SEQUENCE {
pendToken INTEGER,
pendTime GENERALIZEDTIME
}
CMCStatus ::= INTEGER {
success (0),
-- you got exactly what you asked for
failed (2),
-- you don't get it, more information elsewhere in the message
pending (3),
-- the request body part has not yet been processed,
-- requester is responsible to poll back on this
noSupport (4)
-- the requested operation is not supported
}
CMCFailInfo ::= INTEGER {
badAlg (0),
-- Unrecognized or unsupported algorithm
badMessageCheck (1),
-- integrity check failed
badRequest (2),
-- transaction not permitted or supported
badTime (3),
-- Message time field was not sufficiently close to the system
time
badCertId (4),
-- No certificate could be identified matching the provided
criteria
unsuportedExt (5),
-- A requested X.509 extension is not supported by the recipient
CA.
mustArchiveKeys (6),
-- Private key material must be supplied
badIdentity (7),
-- Identification Attribute failed to verify
popRequired (8),
-- Server requires a POP proof before issuing certificate
popFailed (9),
-- Server failed to get an acceptable POP for the request
noKeyReuse (10)
-- Server policy does not allow key re-use
internalCAError (11)
tryLater (12)
}
｝
-- Used for LRAs to add extensions to certificate 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}
RevRequest ::= SEQUENCE {
issuerName Name,
serialNumber INTEGER,
reason CRLReason,
invalidityDate GeneralizedTime OPTIONAL,
passphrase OCTET STRING OPTIONAL,
comment UTF8String OPTIONAL }
id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= {pkix-cmc 24}
CMCCertId ::= IssuerSerial
-- 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 OF Extension
-- The following exists to allow Diffie-Hellman Certificate Requests Messages to be -- well-formed
- 整形 - 以下はのDiffie-Hellmanの証明書があることをメッセージを要求できるようにするために存在します
id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2}
NoSignatureValue ::= OCTET STRING
END
終わり
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。