[要約] RFC 2797は、CMS上での証明書管理メッセージに関する標準化されたプロトコルを提供します。その目的は、証明書の生成、更新、取り消し、および検証などの証明書管理タスクを効率的に実行することです。
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
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.
Copyright（c）The Internet Society（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コミュニティ内の2つの直接的なニーズに対応しています。
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 Public Keysを使用した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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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＃10リクエストの現在の業界慣行に続いて、プロトコルのサブセットとしてPKCS＃7応答をサポートする必要があります。 - プロトコルは、S/MIMEおよび他のグループが必要とするマルチキー登録プロトコルを簡単にサポートする必要があります。 - プロトコルは、1ラウンドの旅行ですべての操作を行う方法を提供する必要があります。これが不可能な場合、往復数を最小限に抑えることができます。 - プロトコルは、すべてのキー生成がクライアントで発生するように設計されます。 - 必須アルゴリズムは、S/MIMEに必要なアルゴリズムをスーパーセットする必要があります。 - プロトコルには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.
この仕様の登録トランザクションは、通常、メッセージの往復旅行で構成されています。最も簡単な場合、登録要求がクライアントからサーバーに送信され、登録応答がサーバーからクライアントに返されます。遅延証明書の発行や回答の投票など、いくつかのより複雑なケースでは、複数の往復が必要です。
This specification supports two different request messages and two different response messages.
この仕様は、2つの異なる要求メッセージと2つの異なる応答メッセージをサポートしています。
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オブジェクトのいずれかに基づいています。2つの異なるリクエストメッセージは、（a）むき出しのPKCS10（他のサービスが不要な場合）、および（b）PKIDATAオブジェクトの一部としてCMSカプセル化にラップされた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オブジェクト（他のサービスが不要な場合）、または（b）CMS SignedDataオブジェクトに包まれた応答ボディオブジェクトのいずれかです。
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.
クライアントの更新（同じキーの新しい証明書）または再キー（新しいキーの新しい証明書）のいずれかを行うための特別なサービスは提供されていません。代わりに、更新/キーメッセージは登録メッセージと同じように見え、IDの証明は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からの追加要件またはステートメントを含む登録メッセージの2番目のレイヤーに包み、この新しい拡張リクエストを認定機関に渡すことにより、プロトコルに参加するための規定が存在します。。
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.
この仕様を通じて利用可能なオプションのサービスは、トランザクション管理、リプレイ検出（NONCES）、繰延証明書発行、証明書の取り消しリクエスト、証明書/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リクエストを作成するエンティティを指します。このドキュメントでは、RASとエンドエンティティの両方がクライアントになる可能性があります。「サーバー」とは、PKI要求を処理してPKI応答を作成するエンティティを指します。CASとRASは、このドキュメントではサーバーになります。「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.
- 制御シーケンスは、コントロール属性のシーケンスで構成されています。このドキュメントで定義されている制御属性は、セクション5にあります。制御シーケンスはOIDによって定義されるため、他の当事者は追加の制御属性を定義できます。認識されていない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は、一連の証明書要求で構成されています。証明書要求は、証明書（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.
-CMSシーケンスは、[CMS]メッセージオブジェクトのシーケンスで構成されています。このプロトコルは、EnvelopedData、SignedData、および暗号化されたDataのみを使用します。詳細については、セクション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.
-othermsg sequenceを使用すると、他の任意のデータ項目を登録プロトコルに配置できます。{oid、Any}の値は、材料の任意の定義を可能にします。データオブジェクトはここに配置され、制御オブジェクトが制御シーケンスフィールドに配置されます。詳細については、セクション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.
- 制御シーケンスは、コントロール属性のシーケンスで構成されています。このドキュメントで定義されている制御属性は、セクション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.
-CMSシーケンスは、[CMS]メッセージオブジェクトのシーケンスで構成されています。このプロトコルは、EnvelopedData、SignedData、および暗号化されたDataのみを使用します。詳細については、セクション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.
-othermsg sequenceを使用すると、他の任意のアイテムを登録プロトコルに配置できます。{oid、Any}の値は、材料の任意の定義を可能にします。データオブジェクトはここに配置され、制御オブジェクトが制御シーケンスフィールドに配置されます。詳細については、セクション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メッセージ本文を作成する必要があります。一部の認証製品は、情報の中央リポジトリを使用して運用されており、公開鍵を受け取って認定のために主題名を割り当てます。この操作モードに対応するには、認定リケストのサブジェクト名がnullである場合がありますが、存在する必要があります。nullのサブジェクト名で認定リケストを受け取ったCASは、そのような要求を拒否する場合があります。拒否され、応答が返された場合、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
クライアントは、PKCS10要求にextensionReq属性として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が必要な場合は、代わりに他の方法の1つ（このドキュメントで説明されている直接的な方法を含む）を使用する必要があります。後続のメッサージにおけるencrcertの値を使用してはなりません。
- Since the subject and publicKeyValues are always present, the POPOSigningKeyInput MUST NOT be used when computing the value for POPSigningKey.
- 件名とpublicKeyValuesは常に存在するため、PopSigingKeyの値を計算するときにPopoSigingKeyInputを使用する必要はありません。
A server is not required to use all of the values suggested by the client in the 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.
認証要求の一部は、リクエストに対する署名です。Diffie-Hellmanは重要な契約アルゴリズムであり、必要な署名オブジェクトを直接生成するために使用することはできません。[DH-POP]は、必要な署名値を作成する2つの方法を提供します。このドキュメントは、ポップ値を提供しないが、必要な署名値を作成するために使用できる署名アルゴリズムも定義します。
Key management (encryption/decryption) private keys cannot always be used to produce some type of signature value as they can be in a decrypt only device. Certification requests require that the signature field be populated. This section provides a signature algorithm specifically for that purposes. The following object identifier and signature value are used to identify this signature type:
キー管理（暗号化/復号化）プライベートキーを使用して、復号化のみのデバイスにあるため、何らかのタイプの署名値を作成することはできません。認定リクエストでは、署名フィールドを入力する必要があります。このセクションでは、その目的に特化した署名アルゴリズムを提供します。次のオブジェクト識別子と署名値を使用して、この署名タイプを識別します。
id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2}
NoSignatureValue ::= OCTET STRING
The parameters for id-alg-noSignature MUST be present and MUST be encoded as NULL. NoSignatureValue contains the hash of the certification request. It is important to realize that there is no security associated with this signature type. If this signature type is on a certification request and the Certification Authority policy requires proof-of-possession of the private key, the POP mechanism defined in section 5.7 MUST be used.
id-alg-nosignatureのパラメーターは存在する必要があり、nullとしてエンコードする必要があります。nosignaturevalueには、認証要求のハッシュが含まれています。この署名タイプに関連するセキュリティがないことを認識することが重要です。この署名タイプが認証要求に載っており、認定機関のポリシーが秘密鍵の入力証明を必要とする場合、セクション5.7で定義されているポップメカニズムを使用する必要があります。
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メッセージの各要素には、関連する身体部分識別子があります。ボディパーツ識別子は、CertreQMSGオブジェクトのCertreQidsフィールド（タグ付きRequest）または他のオブジェクトのボディパルティッドフィールドにエンコードされた4オクテットの整数です。ボディ部分識別子は、単一のpkidataまたはpkiresponseオブジェクト内で一意でなければなりません。体の識別子は、異なる層で複製できます（たとえば、別の層に埋め込まれたCMCメッセージ）。ゼロのボディパーツIDは、現在のpkidataオブジェクトを指定するために予約されています。この値は、現在のPKidataオブジェクトのリクエストを参照するために、pkidatareferenceフィールドのAdd拡張コントロールなどの制御属性で使用されます。
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メッセージ全体の処理に失敗する必要があります。応答はエラーである必要があり、ボディリストは無効または認識されていないコントロール属性のボディパルティドを含める必要があります。
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は、アトラットの関連データを定義する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メッセージのCMSシーケンスフィールドには、ゼロ以上のタグ付きコンテンツ情報オブジェクトが含まれています。この構造の構文はです
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.
-pontentInfoには、contentinfoオブジェクト（[cms]で定義）が含まれています。この場所で使用される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]に従って封筒を実装する必要があります。PKCS7仕様には、非触媒性につながるPKCS7仕様には、あいまいさ（ID-DATA以外のコンテンツタイプの暗号化について）があります。
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.
メッセージのもう1つのメッセージ本文部分により、任意のデータオブジェクトをメッセージの一部として携帯することができます。これは、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にその秘密鍵で署名する必要があります。このフォームの登録要求がD-Hキーに使用される場合、[DH-POP]で説明されているD-H 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:
完全な登録要求メッセージは、SignedData CMSオブジェクトに包まれた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をラッピングする署名dataオブジェクトは、署名認証リクエストの秘密キー資料、または以前に認定された署名キーのいずれかによって署名される場合があります。署名認証リクエストの秘密鍵が使用されている場合、a）対応する公開キーを含む認定要求には、サブジェクトキー識別子拡張要求を含める必要があります。SignerInfoのsubjecteyidentifier形式の形式は、対応する認証要求で指定されたサブジェクトキー識別子でなければなりません。
(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のsubjecteyidentifier形式は、署名キーの証明書がまだ発行されていないため、ここで使用されます。）リクエストキーが署名に使用されている場合、SignedDataオブジェクトにSignerInfoオブジェクトが1つだけある必要があります。
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. 識別とIDPROOF制御ステートメントは必要ありません。登録メッセージに署名するときに、CAから既存の証明書を使用することにより、同じ情報が提供されます。2. CASおよびLRASは、使用される署名証明書に追加の制限を課す場合があります。彼らは、エンティティの最近発行された署名証明書を使用することを要求する場合があります。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.
クライアントは、証明書がいかなる順序であると仮定してはなりません。サーバーには、新しく発行された証明書だけでなく、完全なチェーンを1つ以上の自己署名証明書に形成するために必要なすべての中間証明書を含める必要があります。サーバーはさらに、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オブジェクトで構成されています。応答ボディオブジェクトでは、すべての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つの鉱石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メッセージに適用される場合は、包み込まれたデータレイヤーの外側に2番目の署名レイヤーを配置することをお勧めします。次の図は、このネストがどのように行われるかを示しています。
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は、情報を暗号化することにより、機密データの漏れを防ぐことの利点を提供します。LRASは、包絡したデータラップを削除し、さらに処理することなく交換または転送できます。セクション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'.
-BodyListには、このステータス情報が適用されるリクエストメッセージにボディパーツのリストが含まれています。単純な登録メッセージに対してエラーが返されている場合、ボディリストには値「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 Control属性で使用されるトークンです。
-- 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
}
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.
一部のCASおよびLRASは、IDの証明を認証リクエストに含める必要があります。これを行う多くの異なる方法は、さまざまな程度のセキュリティと信頼性で存在します。ほとんどの人は、あなたの母親の乙女の名前を身元証明の形として提供するように銀行の要求に精通しています。
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オブジェクトのreq sequenceフィールド（シーケンスタイプと長さを含むリクエストメッセージに表示されるとまったく同じエンコード）は、検証される値です。2.トークンのSHA1ハッシュが計算されます。3. [HMAC]で説明されているように、ステップ2で説明されているように、ステップ2のハッシュを共有秘密値として使用して、ステップ1で生成された値に対してHMAC-SHA1値を計算します。4.ステップ3からの160ビットHMAC-SHA1の結果は、IDプルーフ属性の値としてエンコードされます。
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.
サーバーがIDPROOF属性を検証すると、HMAC-SHA1値を同じ方法で計算し、登録要求に含まれるIDPROOF属性と比較します。
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.
サーバーがIDPROOF属性の検証に失敗し、サーバーが応答メッセージを返す場合、RESPORDにFailINFO属性が存在する必要があり、不良の値が必要です。
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.
オプションで、サーバーは、保護されていない識別属性を識別属性に含める必要がある場合があります。識別属性は、テキスト文字列またはランダム数などの数値のいずれかを含むことを目的としています。これにより、サーバーがIDPROOF属性の内容を検証するために必要な共有シークレットを見つけるのに役立ちます。この属性の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オブジェクトの署名で、メッセージの作成者/著者に関するID情報のID情報。ただし、認証を要求する主要ペアのプルーフオブポッセッション情報は、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.
このセクションでは、アイデンティティとポップ情報をリンクするための2つのメカニズムについて説明します。目撃者値は、共有分泌（セクション5.3.1）と共有分泌/被験者のDNマッチング（セクション5.3.2）から暗号化されました。クライアントとサーバーは、証人価値のテクニックをサポートする必要があります。クライアントとサーバーは、共有秘密/被験者のDNマッチングまたは同様の強度のその他の二国間技術をサポートする場合があります。両方のメカニズムの背後にあるアイデアは、クライアントが共有秘密に直接関連付けることができる各証明書要求にいくつかのデータに署名するように強制することです。これにより、単一の完全なPKIリクエストメッセージに異なるエンティティからの証明書要求を含める試みを打ち負かします。
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）メッセージ内の署名された拡張機能として共有秘密のトークンから暗号化された情報由来の情報を含めることを強制することにより、作業を行う最初の手法です。この手法は、NULLの被験者DNSが使用される場合に役立ちます（たとえば、サーバーは共有秘密に基づいて証明書のサブジェクト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. クライアントは、ランダムなバイトストリングrを生成します。これは、少なくとも512ビットの長さである必要があります。2.トークンのSHA1ハッシュが計算されます。3. [HMAC]で説明されているように、ステップ2のハッシュをステップ2のハッシュを共有秘密として使用して、HMAC-SHA1値をステップ1で生成したランダム値で計算されます。4.ステップ1で生成されたランダム値は、idpoplinkrandomコントロール属性の値としてエンコードされます。この制御属性は、完全なPKIリクエストメッセージに含める必要があります。5.ステップ3からの160ビットHMAC-SHA1の結果は、証明書リクエストのIDPOPLINKWITNESS拡張の値としてエンコードされます。a。CRMFの場合、IdPoplinkWitnessはCertrequest構造のコントロールセクションに含まれています。b。PKCS＃10の場合、IDPoplinkWitnessは、認証Request構造の属性セクションに含まれています。
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 Control属性に含まれるランダム文字列から指定された方法で導き出されたことを確認する必要があります。
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.)
アイデンティティポップリンクを行うための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リクエストを生成したときメッセージ、これらの2つの情報を次のように使用する必要があります。
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リクエストに、すべての証明書要求（PKCS＃10および/またはCRMF）のサブジェクト名として共有秘密とともに受け取った特定のサブジェクトDNを含める必要があります。リクエストのサブジェクト名はnullであってはなりません。2.クライアントは、完全なPKI要求に、共有秘密から派生したIDPROOF制御属性（セクション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）IDプルーフ制御属性を検証し、次に、（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.
Data Return Control属性により、クライアントはサーバーに任意のデータ（通常は何らかのタイプの内部状態情報）を送信し、登録応答メッセージの一部としてデータを返すことができます。データリターンステートメントに配置されたデータは、サーバーに不透明であると見なされます。リクエストと応答の両方に同じコントロールが使用されます。登録メッセージにデータ返信ステートメントが表示される場合、サーバーは登録応答メッセージの一部としてそれを返す必要があります。
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.
データリターンステートメントの情報が機密である必要がある場合、クライアントは含まれるデータに何らかのタイプの暗号化を適用することが予想されますが、この詳細はこの仕様の範囲外です。
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:
ADD拡張機能コントロール属性は、証明書に配置される追加の拡張機能を指定するためにLRASによって使用されます。この属性は、次の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内に含まれるペイロードの1つ以上への参照のリストです。Certreferencesシーケンスの各要素は、TaggedCertificationRequestのBody -Partidまたはcertreqmsg内のcertreqidの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要求拡張機能を変更することができます。サーバーは、要求された拡張機能を処理できず、応答が返されないために認証要求が拒否された場合、クライアントが要求した拡張機能の意味を逆転させるために拡張機能を変更してはなりません。Unsportedext。
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).
登録メッセージに複数の追加エクステンションステートメントが存在する場合、正確な動作は証明書発行者ポリシーに任されます。ただし、次のポリシーを使用することをお勧めします。これらのルールは、ADD拡張コントロール属性内の個々の拡張機能に適用されます（「すべてまたは何も」アプローチとは対照的に）。
1. If the conflict is within a single PKIData object, the certificate request would be rejected with an error of badRequest.
1. 競合が単一のPKIDATAオブジェクト内にある場合、証明書要求はバッドレクエストのエラーで拒否されます。
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オブジェクト間である場合、拡張機能の最も外側のバージョンが使用されます（LRAがEnd-entytで要求された拡張機能をオーバーライドできるようにします）。
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属性は、特定のトランザクションを識別します。操作の状態を管理するためにクライアントとサーバーの間で使用されます。クライアントには、リクエストメッセージにTransactionID属性を含めることができます。元の要求にTransactionID属性が含まれている場合、後続の要求と応答メッセージにはすべて同じTransactionID属性を含める必要があります。サーバーは、最も外側のpkidataオブジェクトにトランザクションIDのみを使用する必要があります。内側の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.
リプレイ保護は、送信者と受信者のノンセスを使用してサポートできます。Noncesが使用されている場合、トランザクションの最初のメッセージで、ReciontientNonceは送信されません。Sendernonceはメッセージのオリジネーターによってインスタンス化され、後で参照するために保持されます。送信者Nonceの受信者は、この値をRecipientNonceとしてオリジネーターに反映し、独自のSendernonceを含みます。このメッセージのトランザクションオリジネーターが受信すると、オリジネーターはReciontIentNonceの値をその保持値と比較します。値が一致する場合、さらなるセキュリティ処理のためにメッセージを受け入れることができます。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とReciontientNonce属性を使用して、アプリケーションレベルのリプレイ予防を提供できます。クライアントは、最初のリクエストメッセージにsendernonceを含めることができます。発生するメッセージには、Sendernonceの値のみが含まれます。メッセージにSendernonceが含まれている場合、応答には、以前に受信したSendernonceの送信値をRecipientNonceとして含め、Sendernonceの新しい価値を含める必要があります。サーバーは、最も外側のpkidataオブジェクトのNoncesのみを使用する必要があります。内側の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メソッドが利用できない場合にのみ、このポップメソッドを使用する必要があります。サーバーは、pkidata内の要素に対して必要なPOPが欠落している場合、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の詳細については、[CRMF]のセクション5を参照してください。
By necessity, POP for encryption-only keys cannot be done in one round-trip, since there are four distinct phases:
必然的に、4つの異なるフェーズがあるため、暗号化のみのキー用のPOPを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.サーバーは、クライアントが復号化する必要がある提示されたパブリック暗号化キーで暗号化されたポップチャレンジをクライアントに送信します。3.クライアントはポップチャレンジを復号化し、サーバーに送り返します。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は2つの異なる属性を定義します。最初のものは、ステップ2でサーバーからユーザーに送信された暗号化された課題を扱います。2番目の扱いには、ステップ3でクライアントからサーバーに送信された復号化された課題を扱います。
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.)
暗号化されたPop属性を使用して、サーバーからクライアントに暗号化されたチャレンジを送信します。そのため、応答ボディの制御シーケンス内のタグ付き属性としてエンコードされます。（上記のステップ1で送信されたメッセージは登録リクエストであり、ステップ2の応答は、POPが明示的に必要であることを指定し、暗号化されたPop属性にPOPチャレンジを提供する障害を含む完全な登録応答であると仮定することに注意してください。））
EncryptedPOP ::= SEQUENCE {
request TaggedRequest, cms contentInfo, thePOPAlgID AlgorithmIdentifier, witnessAlgID AlgorithmIdentifier, witness OCTET STRING
Request TaggedRequest、CMS ContentInfo、ThePopalgid AlgorithMidentifier、WitnesalGid AlgorithMidentifier、Witness Octet String
}
}
DecryptedPOP ::= SEQUENCE {
bodyPartID BodyPartID,
thePOPAlgID AlgorithmIdentifier,
thePOP OCTET STRING
}
The encrypted POP algorithm works as follows:
暗号化されたポップアルゴリズムは次のように機能します。
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-DATAであり、コンテンツは値です。証明書要求にサブジェクトキー識別子（SKI）拡張機能が含まれている場合、受信者識別子はスキーである必要があります。発行済みのフォームが使用されている場合、発行者はnullとしてエンコードされ、証明書リクエストのボディパルティッドとしてserialnumberとしてエンコードする必要があります。Popalgidには、リターンポップ値の計算に使用されるアルゴリズムが含まれていますd。WitnessalGidには、フィールド証人を作成するためにYに使用されるハッシュアルゴリズムが含まれていますe。証人にはyのハッシュ値が含まれています。3.クライアントはCMSフィールドを復号化して値yを取得します。クライアントは、WitningalGidを使用してH（Y）を計算し、証人の価値と比較します。値が比較されない場合、または復号化が成功しない場合、クライアントは登録プロセスを中止する必要があります。クライアントは、PopFailedのFailInfo値を持つCMCSTATUSINFOコントロール属性を含むリクエストメッセージを送信することにより、プロセスを中止します。4.クライアントは、新しいpkidataメッセージの一部としてDecryptedPopを作成します。DecryptedPopのフィールドは次のとおりです。BodyPartidは、新しい登録メッセージの証明書要求を指しますb。Popalgidは、暗号化されたpopからコピーされますc。ThePopには所有証明が含まれています。この値は、（4a）で参照される値yと要求を使用して、Popalgidによって計算されます。5.次に、サーバーは、Yのキャッシュ値とリクエストからPOPの値を再計算し、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.
PopalgidおよびWitnessalGidのケアのアルゴリズムを定義するときは、WitnessalGidの結果がポパルジッドとの計算のショートカットに有用な価値ではないことを確認する必要があります。クライアントは、Sha-1をsha-1に実装する必要があります。クライアントは、Popalgidに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.
上記のアルゴリズムの潜在的な問題の1つは、CAが返されたPOP値を検証するために必要な状態の量です。これは、CAに保管されている状態の量を単一の（または小さなセット）値に減らすことにより、問題に対処する多くの考えられる方法の1つを説明します。
1. Server generates random seed x, constant across all requests. (The value of x would normally be altered on a regular basis and kept for a short time afterwards.) 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のみであり、CERTリクエスト構造から来る他の入力で一貫して計算可能であることです。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はLRAが認証を要求するエンティティを使用してPOPプロトコルを実行することを許可する（または要求する）ことができます。この場合、LRAはPOPを行ったCAに通知する方法が必要です。この制御属性は、この問題に対処するために作成されています。
The ASN.1 structure for the LRA POP witness is as follows:
LRAポップ証人の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.
証明書サーバーがLRAがポップ検証を行うことを許可していない場合、ポップファイルのエラーを返します。CAは、ポップ自体を再確認するためにチャレンジ応答を開始してはなりません。
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要求メッセージの唯一のコントロールである場合、応答は単純な登録応答になります。
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.
GET 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は、件名証明書におけるCRLDISTRIBUTIONPONTSの値または同等の値である場合があります。証明書にはそのような値が含まれていない場合です。
-- time is used by the client to specify from among potentially several issues of CRL that one whose thisUpdate value is less than but nearest to the specified time. In the absence of a time component, the CA always returns with the most recent CRL.
- クライアントが時間を使用して、CRLの潜在的にいくつかの問題の中から指定して、この値が指定された時間に近いほうが少ないものです。時間コンポーネントがない場合、CAは常に最新のCRLで戻ります。
-- reasons is used to specify from among CRLs partitioned by revocation reason. Implementers should bear in mind that while a specific revocation request has a single CRLReason code--and consequently entries in the CRL would have a single CRLReason code value--a single CRL can aggregate information for one or more reasonFlags.
- 理由は、取り消し理由によって分割されたCRLの間から指定するために使用されます。実装者は、特定の取り消しリクエストには単一のCRLREASOONコードがあり、その結果、CRLのエントリには単一のCRLREASONコード値があるが、単一のCRLが1つ以上の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.
リクエストに応答するサービスは、要求されたCRLをSignedDataオブジェクトのCRLSフィールドに配置します。GET CRL属性が完全な登録メッセージの唯一のコントロールである場合、応答は単純な登録応答になります。
The revocation request control attribute is used to request that a certificate be revoked.
Request Request Control属性は、証明書を取り消すことを要求するために使用されます。
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は、取り消される証明書の発行名が含まれています。
-- 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.
-NevalidityDateには、無効な日付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へのエンドエンティティから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:
RegINFO Control属性は、クライアントとLRAがパートA PKI要求として追加情報を渡すことです。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コントロール属性として返されます。応答情報のOctet文字列のコンテンツは、クライアントとサーバー間の二国間合意に基づいています。
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.
一部の環境では、手動介入またはその他の身元確認のためのプロセス要件により、証明書リクエストに関連する証明書の返却が遅れる可能性があります。クエリ保留中の属性により、クライアントは保留中の証明書リクエストの状態についてサーバーに照会することができます。サーバーは、CMCSTATUSINFO属性の一部としてトークンを返します（他のINFOフィールド）。クライアントは、サーバーへの正しいリクエストを識別するために、クエリ属性のクエリにトークンを入れます。サーバーは、保留中の証明書リクエストの状態をクライアントが照会するための提案された時間を返すこともできます。
The ASN.1 structure used by the query pending control attribute is:
Query保留中の制御属性で使用される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).
サーバーが保留中の状態を返す場合（トランザクションはまだ保留中です）、その他のInfoは省略される場合があります。省略されていない場合、同じ値を返す必要があります（リクエスト中にトークンを変更してはなりません）。
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が確認された場合、クライアントは確認証明書を返す必要があります
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は、エンドエンティティと認証機関の間にあります。End-Entityの観点から見ると、LRAは認証機関であるように見え、サーバーからLRAはクライアントのように見えます。LRASは登録メッセージを受け取り、ローカル処理を実行してから、証明書当局に転送します。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.
- 複数の登録メッセージを一緒にバッチ、 - チャレンジ/レスポンスポッププルーフ、 - すべてのリクエストにプライベートまたは標準化された証明書拡張機能を追加する - プライベートキーマテリアルのアーカイブ - 異なる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コントロール属性のポッププルーフを実行する場合）およびクライアント登録メッセージ。クライアントの登録メッセージは、完全な登録メッセージである場合はCMSシーケンスに配置され、単純な登録メッセージの場合はreqsequenceに配置されます。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.
登録メッセージの処理では、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制御シーケンスLRAは、クライアントからのCMS Sequence Zeroまたはより多くの完全なPKIメッセージ（クライアントによる）（クライアントによる）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.
登録メッセージで暗号化を削除または変更する必要がある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 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ラッピングは、[Smimev2]および[smimev3]から取得されます。簡単な登録要求は、アプリケーション/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タイプのパラメーターは、「CERTSのみ」の値を持つコンテンツタイプのステートメントに載っている必要があります。「.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タイプのパラメーターは、「CMC-Enroll」の値に含める必要があります。「.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タイプファイル拡張スマイムタイプ
application/pkcs10 .p10 N/A (simple PKI request)
Application/PKCS10 .P10 N/A（単純なPKIリクエスト）
application/pkcs7-mime .p7m CMC-request (full PKI request)
Application/PKCS7-MIME .P7M CMC-REQUEST（完全なPKIリクエスト）
application/pkcs7-mime .p7c certs-only (simple PKI response)
Application/PKCS7-MIME .P7C CERTSのみ（単純なPKI応答）
application/pkcs7-mime .p7m CMC-response (full PKI response)
アプリケーション/PKCS7-MIME .P7M CMC-Response（完全な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.
登録メッセージと応答がソケットを介して送信される場合、ラッピングは必要ありません。メッセージは、バイナリのバーエンコード形式で送信する必要があります。
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の署名は、DSAアルゴリズムのIdentifier値（[pkixcert]のセクション7.2.2で指定されているように）で示される必要があります。PKIクライアントとサーバーは、RSAシグネチャを生産および処理できる必要があります（[PKIXCERT]のセクション7.2.1で指定されています）。
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クライアントとサーバーは、Diffie-Hellman（D-H）キーExchangeアルゴリズムを使用して、メッセージ暗号化キーを保護およびアクセスできる必要があります。D-H/3DES保護は、[CMS]で指定されているD-HアルゴリズムIdentifier値によって示さなければなりません。PKIクライアントとサーバーは、RSAキートランスポートを生産および処理できる必要があります。PKIメッセージに使用する場合、[PKIXCERT]のセクション7.2.1で指定されているように、RSAキートランスポートを示す必要があります。
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) 完全なPKIリクエストメッセージを受け入れる必要がありますi）完全なPKIリクエスト内のCRMF要求ボディを受け入れる必要がありますII）完全なPKIリクエスト内のPKCS＃10リクエスト本体を受け入れる必要がありますb）完全な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リクエストのいずれかを使用する場合があります。i）クライアントは、単純な登録メッセージでPKCS＃10を使用する必要がありますII）クライアントは、完全なPKIリクエストでPKCS＃10またはCRMFを使用することができますb）単純な登録応答を理解する必要があります。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.
エンドエンティティとCAまたはLRAの間の安全な通信チャネルの開始（および同様に、LRAと別のLRAまたはCAの間）は、必然的にバンド外の信頼開始メカニズムを必要とします。たとえば、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が重要な状態情報を維持している場合、オプションのNonCEメカニズムを含めることなく、リプレイ攻撃が検出される可能性があります。このプロトコルの実装者は、セクション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] Myers、M.、Adams、C.、Solo、D。、およびD. Kemp、「インターネットX.509証明書リクエストメッセージフォーマット」、RFC 2511、1999年3月。
[DH] B. Kaliski, "PKCS 3: Diffie-Hellman Key Agreement v1.4"
[DH] B. Kaliski、「PKCS 3：Diffie-Hellman Key Agreement v1.4」
[DH-POP] H. Prafullchandra, J. Schaad, "Diffie-Hellman Proof-of-Possession Algorithms", Work in Progress.
[DH-POP] H. Prafullchandra、J。Schaad、「Diffie-Hellman Proof of-possession algorithms」、進行中の作業。
[HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk、H.、Bellare、M。、およびR. Canetti、「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：Cryptographic Message Syntax 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：Private-Key Information Syntax Standard、バージョン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.、Ford、W.、Polk、W。and D. Solo "Internet 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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Hoffman、P.、Ramsdell、B.、Lundblade、L。and 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] Rescorla、E。、「Diffie-Hellman Key Asmatement Method」、RFC 2631、1999年6月。
Michael Myers VeriSign Inc. 1350 Charleston Road Mountain View, CA, 94043
Michael Myers Verisign Inc. 1350 Charleston Road Mountain View、CA、94043
Phone: (650) 429-3402 EMail: mmyers@verisign.com
電話：（650）429-3402メール：mmyers@verisign.com
Xiaoyi Liu Cisco Systems 170 West Tasman Drive San Jose, CA 95134
Xiaoyi Liu Cisco Systems 170 West Tasman Drive San Jose、CA 95134
Phone: (480) 526-7430 EMail: xliu@cisco.com
電話：（480）526-7430メール：xliu@cisco.com
Jim Schaad
ジム・シャード
EMail: jimsch@nwlink.com
Jeff Weinstein
ジェフ・ワインスタイン
EMail: 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) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS All --
-- The types and values defined in this module are exported for use
-- in the other ASN.1 modules. Other applications may use them for
-- their own purposes.
IMPORTS
輸入
-- Information Directory Framework (X.501) Name FROM InformationFramework { joint-iso-itu-t ds(5) modules(1) informationFramework(1) 3 }
- 情報ディレクトリフレームワーク（x.501）情報フレームワークからの名前{goint-iso-itu-t ds（5）モジュール（1）情報フレームワーク（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 }
-directory認証フレームワーク（x.509）Algorithmidentifier、astributeCertificate、証明書、証明書、証明書の承認フレームワーク{aintion-iso-itu-t ds（5）Module（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 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)}
-- Cryptographic Message Syntax ContentInfo, Attribute FROM CryptographicMessageSyntax { 1 2 840 113549 1 9 16 0 1}
- 暗号化メッセージ構文ContentInfo、cryptographicmessagesyntax {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 5 7 0 5}からのCRMF CertreQMSG;
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-cmc OBJECT IDENTIFIER ::= {id-pkix 7} -- CMC controls
id-cct OBJECT IDENTIFIER ::= {id-pkix 12} -- CMC content types
-- The following controls have simple type content (usually OCTET 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 }
ISSUERNAME名、CRLNAME GENERALNAMEオプション、Time generalizedTimeオプション、ReasoneverShowsFlagsオプション}}
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
id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2}
NoSignatureValue ::= OCTET STRING
ENDFull Copyright Statement
完全な著作権ステートメントを終了します
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。