[要約] RFC 10002は、CMSを用いる証明書管理プロトコルCMCの基本構文、PKI要求・応答、制御、登録機関の処理を規定します。CMSおよびPKCS #10ベースの証明サービスへの共通インターフェースと、暗号化専用鍵を含むPKI登録を提供し、RFC 5272およびRFC 6402を廃止します。完全なCMC仕様は、トランスポートを定めるRFC 10003および適合要件を定めるRFC 10004と組み合わせて使用します。
Internet Engineering Task Force (IETF) J. Mandel, Ed.
Request for Comments: 10002 AKAYLA, Inc.
Obsoletes: 5272, 6402 S. Turner, Ed.
Category: Standards Track sn3rd
ISSN: 2070-1721 July 2026
This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community:
この文書は、暗号メッセージ構文 (CMS) を使用する証明書管理プロトコルである CMC の基本構文を定義します。このプロトコルは、インターネット公開キー基盤 (PKI) コミュニティ内での 2 つの差し迫ったニーズに対応します。
1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Cryptography Standard), and
1. CMS および PKCS #10 (Public Key Cryptography Standard) に基づく公開キー認証製品およびサービスへのインターフェイスの必要性、および
2. The need for a PKI enrollment protocol for encryption-only keys due to algorithm or hardware design.
2. アルゴリズムまたはハードウェア設計による、暗号化専用キーの PKI 登録プロトコルの必要性。
CMC also requires the use of the transport document (RFC 10003) and the requirements usage document (RFC 10004) along with this document for a full definition.
CMC では、完全な定義のために、この文書とともにトランスポート文書 (RFC 10003) および要件使用文書 (RFC 10004) を使用することも要求しています。
This document obsoletes RFCs 5272 and 6402.
この文書は RFC 5272 および 6402 を廃止します。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc10002.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc10002 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この文書には、2008 年 11 月 10 日より前に発行または一般公開された IETF 文書または IETF 寄稿の資料が含まれている場合があります。この資料の一部の著作権を管理している人物は、IETF 標準プロセス外でそのような資料の変更を許可する権利を IETF トラストに付与していない可能性があります。かかる資料の著作権を管理する者から適切なライセンスを取得しない限り、この文書を IETF 標準プロセスの外で変更することはできません。また、RFC として出版するための形式にするか、英語以外の言語に翻訳する場合を除き、IETF 標準プロセスの外でその派生著作物を作成することはできません。
1. Introduction
1.1. Protocol Requirements
1.2. Requirements Terminology
1.3. Changes Since RFC 2797
1.4. Updates Made by RFC 6402
1.5. Changes Since RFC 6402
2. Protocol Overview
2.1. Terminology
2.2. Protocol Requests/Responses
3. PKI Requests
3.1. Simple PKI Request
3.2. Full PKI Request
3.2.1. PKIData Content Type
3.2.2. Body Part Identification
3.2.3. CMC Unsigned Data Attribute
4. PKI Responses
4.1. Simple PKI Response
4.2. Full PKI Response
4.2.1. PKIResponse Content Type
5. Application of Encryption to a PKI Request/Response
6. Controls
6.1. CMC Status Info Controls
6.1.1. Extended CMC Status Info Control
6.1.2. CMC Status Info Control
6.1.3. CMCStatus Values
6.1.4. CMCFailInfo
6.2. Identification and Identity Proof Controls
6.2.1. Identity Proof Version 2 Control
6.2.2. Identity Proof Control
6.2.3. Identification Control
6.2.4. Hardware Shared-Secret Token Generation
6.3. Linking Identity and POP Information
6.3.1. Cryptographic Linkage
6.3.2. Shared-Secret/Subject DN Linking
6.3.3. Existing Certificate Linking
6.4. Data Return Control
6.5. RA Certificate Modification Controls
6.5.1. Modify Certification Request Control
6.5.2. Add Extensions Control
6.6. Transaction Identifier Control and Sender and Recipient
Nonce Controls
6.7. Encrypted and Decrypted POP Controls
6.8. RA POP Witness Control
6.9. Get Certificate Control
6.10. Get CRL Control
6.11. Revocation Request Control
6.12. Registration and Response Information Controls
6.13. Query Pending Control
6.14. Confirm Certificate Acceptance Control
6.15. Publish Trust Anchors Control
6.16. Authenticated Data Control
6.17. Batch Request and Response Controls
6.18. Publication Information Control
6.19. Control Processed Control
6.20. RA Identity Proof Witness Control
6.21. Response Body Control
7. Other Attributes
7.1. Change Subject Name Attribute
8. Registration Authorities
8.1. Encryption Removal
8.2. Signature Layer Removal
9. CMC Infrastructure Certificate Requirements
9.1. Extended Key Usage
9.2. Subject Information Access
10. Security Considerations
11. IANA Considerations
12. References
12.1. Normative References
12.2. Informative References
Appendix A. ASN.1 Modules
A.1. ASN.1 Module for CMC
A.2. ASN.1 Module for PBKDF2 PRFs
Appendix B. Enrollment Message Flows
B.1. Request of a Signing Certificate
B.2. Single Certification Request Modified by RA
B.3. Direct POP for an RSA or KEM Certificate
B.4. Direct POP with No Signature Mechanism
Appendix C. Production of Diffie-Hellman Public Key Certification
Requests
C.1. No-Signature Signature Mechanism
Acknowledgements
Contributors
Authors' Addresses
This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet PKI community:
この文書は、暗号メッセージ構文 (CMS) を使用する証明書管理プロトコルである CMC の基本構文を定義します。このプロトコルは、インターネット PKI コミュニティ内の 2 つの当面のニーズに対応します。
1. The need for an interface to public key certification products and services based on CMS and PKCS #10, and
1. CMS および PKCS #10 に基づく公開鍵認証製品およびサービスへのインターフェースの必要性
2. The need for a PKI enrollment protocol for encryption-only keys due to algorithm or hardware design.
2. アルゴリズムまたはハードウェア設計による、暗号化専用キーの PKI 登録プロトコルの必要性。
A small number of additional services are defined to supplement the core certification request service.
コアの証明書要求サービスを補足するために、少数の追加サービスが定義されています。
CMC also requires the use of the transport document [CMC-TRANS] and the requirements usage document [CMC-COMPL] along with this document for a full definition.
CMC はまた、完全な定義のために、この文書とともにトランスポート文書 [CMC-TRANS] および要件使用文書 [CMC-COMPL] を使用することも要求しています。
This document obsoletes RFCs 5272 [CMC-PROTv1] and 6402 [CMC-Updates].
この文書は、RFC 5272 [CMC-PROTv1] および 6402 [CMC-Updates] を廃止します。
As much as possible, the protocol must be based on the existing CMS [CMS] [CMS-AE], PKCS #10 [PKCS10], and CRMF (Certificate Request Message Format) [CRMF] specifications.
可能な限り、プロトコルは既存の CMS [CMS] [CMS-AE]、PKCS #10 [PKCS10]、および CRMF (証明書要求メッセージ形式) [CRMF] 仕様に基づいていなければなりません。
The protocol must support the current industry practice of a PKCS #10 certification request followed by a PKCS #7 "certs-only" response as a subset of the protocol.
このプロトコルは、PKCS #10 認証リクエストの後にプロトコルのサブセットとして PKCS #7 の「証明書のみ」応答が続くという現在の業界慣行をサポートする必要があります。
The protocol must easily support the multi-key enrollment protocols required by S/MIME and other groups.
このプロトコルは、S/MIME およびその他のグループで必要なマルチキー登録プロトコルを容易にサポートする必要があります。
The protocol must supply a way of doing all enrollment operations in a single round trip. When this is not possible, the number of round trips is to be minimized.
プロトコルは、すべての登録操作を 1 回の往復で実行する方法を提供する必要があります。それが不可能な場合は、往復回数を最小限に抑える必要があります。
The protocol must be designed such that all key generation can occur on the client.
プロトコルは、すべての鍵生成がクライアント上で行われるように設計する必要があります。
Support must exist for the mandatory algorithms used by S/MIME. Support should exist for all other algorithms cited by the S/MIME core documents.
S/MIME で使用される必須アルゴリズムがサポートされている必要があります。S/MIME コア文書で引用されている他のすべてのアルゴリズムのサポートが存在する必要があります。
The protocol must contain Proof-of-Possession (POP) methods. Optional provisions for multiple-round-trip POP will be made if necessary.
プロトコルには所有証明 (POP) メソッドが含まれている必要があります。必要に応じて、複数往復の POP のオプションが提供されます。
The protocol must support deferred and pending responses to enrollment requests for cases where external procedures are required to issue a certificate.
プロトコルは、証明書の発行に外部手順が必要な場合に備えて、登録要求に対する遅延および保留中の応答をサポートする必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
[CMC-PROTv1] was a major overhaul on the layout of [RFC2797]. This included two different steps. Primarily, the removal of some sections from the document to be moved to two other documents:
[CMC-PROTv1] は、[RFC2797] のレイアウトを大幅に見直したものです。これには 2 つの異なる手順が含まれていました。主に、ドキュメントからいくつかのセクションを削除して、他の 2 つのドキュメントに移動します。
* Information on how to transport messages is now found in [CMC-TRANS].
* メッセージの転送方法に関する情報は、[CMC-TRANS] に記載されています。
* Information on which controls and sections of this document must be implemented along with which algorithms are required can now be found in [CMC-COMPL].
* このドキュメントのどのコントロールとセクションを実装する必要があるか、またどのアルゴリズムが必要かに関する情報は、現在 [CMC-COMPL] で見つけることができます。
A number of new controls were added in [CMC-PROTv1]:
[CMC-PROTv1] には、いくつかの新しいコントロールが追加されました。
* "Extended CMC Status Info Control" (Section 6.1.1)
* 「拡張CMCステータス情報制御」(セクション6.1.1)
* "Publish Trust Anchors Control (Section 6.15)
* 「トラストアンカーコントロールの公開 (セクション 6.15)」
* "Authenticated Data Control (Section 6.16)
* 「認証済みデータの管理 (セクション 6.16)」
* "Batch Request and Response Controls (Section 6.17)
* 「バッチリクエストとバッチレスポンスの制御(セクション6.17)」
* "Publication Information Control (Section 6.18)
* 「出版情報の管理（セクション6.18）」
* "Modify Certification Request Control (Section 6.5.1)
* 「証明書要求制御の変更 (セクション 6.5.1)」
* "Control Processed Control (Section 6.19)
* 「制御処理された制御 (セクション 6.19)」
* "Identity Proof Control (Section 6.2.2)
* 「身元証明制御 (セクション 6.2.2)」
* "POP Link Witness Version 2 Controls (Section 6.3.1.1)
* 「POP Link Witness バージョン 2 コントロール (セクション 6.3.1.1)」
[CMC-Updates] includes changes to [CMC-PROTv1] that are noted in this section.
[CMC-Updates] には、このセクションに記載されている [CMC-PROTv1] への変更が含まれています。
Two added controls:
2 つの追加コントロール:
* Registration Authority (RA) Identity Witness allows for an RA to perform identity checking using the identity and shared-secret, and tell any following servers that the identity check was successfully performed.
* 登録機関 (RA) Identity Witness を使用すると、RA が ID と共有秘密を使用して ID チェックを実行し、後続のサーバーに ID チェックが正常に実行されたことを通知できます。
* Response Body allows for an RA to identify a nested response for an End-Entity (EE) to process.
* レスポンスボディを使用すると、RA はエンドエンティティ (EE) が処理するネストされたレスポンスを識別できます。
[CMC-Updates] also:
[CMC アップデート] も:
* Creates the Change Subject Name attribute, which allows a client to request a change in the subject field and Subject Alternative Name extension in a certificate.
* 「サブジェクト名の変更」属性を作成します。これにより、クライアントは証明書のサブジェクト フィールドとサブジェクト代替名拡張子の変更を要求できるようになります。
* Adds Extended Key Usages (EKUs) for CMC to distinguish server types.
* サーバー タイプを区別するために CMC に拡張キー使用法 (EKU) を追加します。
* Defines a new Subject Information Access extension to hold locations to contact the CMC server.
* CMC サーバーに接続するための場所を保持するための新しいサブジェクト情報アクセス拡張機能を定義します。
* Clarifies that the use of a preexisting certificate is not limited to just renewal and rekey messages and is required for support. This formalizes a requirement for the ability to do renewal and rekey that previously was implicit.
* 既存の証明書の使用は更新メッセージとキー再生成メッセージだけに限定されず、サポートには必要であることを明確にします。これにより、以前は暗黙的であった更新とキー再生成を実行する機能の要件が形式化されます。
This document introduces changes to [CMC-PROTv1] that are noted in this section.
この文書では、このセクションに記載されている [CMC-PROTv1] への変更を紹介します。
* Merged [CMC-Updates] text.
* [CMC-Updates] テキストを統合しました。
* Included updates inspired by the following errata reports: [Err8385], [Err8137], [Err8027], [Err7629], [Err7628], [Err7627], [Err7379], [Err6571], [Err5931], [Err4775], [Err2731], [Err2063], and [Err3943] (for [CMC-Updates]).
* 次の正誤表レポートに基づいた更新が含まれています: [Err8385]、[Err8137]、[Err8027]、[Err7629]、[Err7628]、[Err7627]、[Err7379]、[Err6571]、[Err5931]、[Err4775]、[Err2731]、[Err2063] および [Err3943] ([CMC-Updates] の場合)。
* To support adopting SHA-256 and HMAC-SHA256, maca-hMAC-SHA256 was added to POPAlgs and mda-sha256 was added to WitnessAlgs. Both were included in the example in Appendix B.
* SHA-256 および HMAC-SHA256 の採用をサポートするために、maca-hMAC-SHA256 が POPAlgs に追加され、mda-sha256 が WitnessAlgs に追加されました。どちらも付録 B の例に含まれています。
* Updated the "Encrypted and Decrypted POP Controls" section (Section 6.7) to use HMAC-SHA256.
* HMAC-SHA256 を使用するように「暗号化および復号化された POP コントロール」セクション (セクション 6.7) を更新しました。
* Updated the ASN.1 module to import from the 2008 ASN.1 module from [ADD-ASN1].
* [ADD-ASN1] の 2008 ASN.1 モジュールからインポートするように ASN.1 モジュールを更新しました。
* Modified the ASN.1 module in Appendix A.1 to import Password-Based Key Derivation Function 2 (PBKDF2) Pseudorandom Functions (PRFs) from Appendix A.2.
* 付録 A.2 からパスワードベースのキー導出関数 2 (PBKDF2) 擬似乱数関数 (PRF) をインポートするように、付録 A.1 の ASN.1 モジュールを変更しました。
* Added a direct POP example to address management of Key Encapsulation Mechanism (KEM) certificates.
* Key Encapsulation Mechanism (KEM) 証明書の管理に対処するための直接 POP の例を追加しました。
* Added id-ce-subjectKeyIdentifier to examples.
* id-ce-subjectKeyIdentifier を例に追加しました。
* Clarified that the subjectKeyIdentifier choice must be used with id-alg-noSignature.
* subjectKeyIdentifier の選択は id-alg-noSignature とともに使用する必要があることを明確にしました。
* Updated the CMC Control Attribute Table (see Table 1) to include raIdentityWitness and responseBody from [CMC-Updates].
* CMC コントロール属性テーブル (表 1 を参照) を更新して、[CMC-Updates] の raIdentityWitness と responseBody を追加しました。
* Added support for AuthEnvelopedData.
* AuthEnvelopedData のサポートが追加されました。
A PKI enrollment transaction in this specification is generally composed of a single round trip of messages. In the simplest case, a PKI enrollment request, henceforth referred to as a PKI Request, is sent from the client to the server; a PKI enrollment response, henceforth referred to as a PKI Response, is then returned from the server to the client. In more complicated cases, such as delayed certificate issuance, more than one round trip is required.
この仕様における PKI 登録トランザクションは通常、メッセージの 1 往復で構成されます。最も単純なケースでは、PKI 登録要求 (以降、PKI 要求と呼びます) がクライアントからサーバーに送信されます。その後、PKI 登録応答 (以降、PKI 応答と呼びます) がサーバーからクライアントに返されます。証明書の発行が遅れるなど、より複雑なケースでは、複数回の往復が必要になります。
This specification defines two PKI Request types and two PKI Response types.
この仕様では、2 つの PKI 要求タイプと 2 つの PKI 応答タイプを定義します。
PKI Requests are formed using either the PKCS #10 or CRMF structure. The two PKI Requests are:
PKI リクエストは、PKCS #10 または CRMF 構造のいずれかを使用して形成されます。2 つの PKI リクエストは次のとおりです。
Simple PKI Request:
単純な PKI リクエスト:
the bare PKCS #10 (in the event that no other services are needed).
ベア PKCS #10 (他のサービスが必要ない場合)。
Full PKI Request:
完全な PKI リクエスト:
one or more PKCS #10, CRMF, or Other Request Message structures wrapped in a CMS encapsulation as part of a PKIData.
PKIData の一部として CMS カプセル化にラップされた 1 つ以上の PKCS #10、CRMF、またはその他の要求メッセージ構造。
PKI Responses are based on SignedData or AuthenticatedData [CMS]. The two PKI Responses are:
PKI 応答は、SignedData または AuthenticatedData [CMS] に基づいています。2 つの PKI 応答は次のとおりです。
Simple PKI Response:
単純な PKI 応答:
a "certs-only" SignedData (in the event no other services are needed).
「証明書のみ」の SignedData (他のサービスが必要ない場合)。
Full PKI Response:
完全な PKI 応答:
a PKIResponse content type wrapped in a SignedData.
SignedData でラップされた PKIResponse コンテンツ タイプ。
No special services are provided for either renewal (i.e., a new certificate with the same key) or rekey (i.e., a new certificate with a new key) of client certificates. Instead, renewal and rekey requests look the same as any certification request, except that the Proof-of-Identity is supplied by existing certificates from a trusted Certification Authority (CA).
クライアント証明書の更新 (つまり、同じキーを持つ新しい証明書) またはキーの再作成 (つまり、新しいキーを持つ新しい証明書) に対して特別なサービスは提供されません。代わりに、更新およびキー再生成の要求は、ID 証明が信頼できる認証局 (CA) からの既存の証明書によって提供されることを除いて、他の証明書要求と同じように見えます。
Note: This is usually the same CA, but it could be a different CA in the same organization where naming is shared.
注: これは通常は同じ CA ですが、名前が共有されている同じ組織内の別の CA である場合もあります。
No special services are provided to distinguish between a rekey request and a new certification request (generally for a new purpose). CAs or other publishing agents are also expected to have policies for removing certificates from publication based either on new certificates being added or the expiration or revocation of a certificate. A control to unpublish a certificate would normally be included in a rekey request if the CA did not wish to have a grace period between the certificates, be omitted if the CA wishes to have a grace period between certificates, and be omitted from a new certification request.
キー再生成要求と新しい認証要求 (通常は新しい目的のため) を区別するための特別なサービスは提供されません。CA またはその他の公開エージェントは、追加される新しい証明書、または証明書の有効期限または失効に基づいて、公開から証明書を削除するためのポリシーを持つことも期待されます。証明書を非公開にする制御は、通常、CA が証明書間に猶予期間を設けたくない場合にはキー再生成要求に含まれ、CA が証明書間に猶予期間を設けたい場合には省略され、新しい証明書要求からは省略されます。
A provision exists for RAs to participate in the protocol by taking PKI Requests, wrapping them in a second layer of PKI Request with additional requirements or statements from the RA, and then passing this new expanded PKI Request on to the CA.
RA がプロトコルに参加するには、PKI リクエストを受け取り、RA からの追加要件またはステートメントを含む PKI リクエストの第 2 層でラップし、この新しく拡張された PKI リクエストを CA に渡すという規定が存在します。
This specification makes no assumptions about the underlying transport mechanism. The use of CMS does not imply an email-based transport. Several different possible transport methods are defined in [CMC-TRANS].
この仕様では、基礎となるトランスポート メカニズムについては仮定しません。CMS の使用は、電子メールベースのトランスポートを意味するものではありません。いくつかの異なる可能な転送方法が [CMC-TRANS] で定義されています。
Optional services available through this specification are transaction management, replay detection (through nonces), deferred certificate issuance, certificate revocation requests and certificate / Certificate Revocation List (CRL) retrieval.
この仕様を通じて利用可能なオプション サービスは、トランザクション管理、リプレイ検出 (nonce による)、延期された証明書発行、証明書失効要求、および証明書/証明書失効リスト (CRL) の取得です。
There are several different terms, abbreviations, and acronyms used in this document. These are defined here, in no particular order, for convenience and consistency of usage:
このドキュメントでは、いくつかの異なる用語、略語、頭字語が使用されています。これらは、利便性と使用の一貫性のために、ここで順不同で定義されています。
End-Entity (EE):
エンドエンティティ (EE):
Refers to the entity that owns a key pair and for whom a certificate is issued.
キーペアを所有し、証明書が発行されるエンティティを指します。
Registration Authority (RA) or Local RA (LRA):
登録局 (RA) またはローカル RA (LRA):
Refers to an entity that acts as an intermediary between the EE and the CA. Multiple RAs can exist between the EE and the CA. RAs may perform additional services such as key generation or key archival. This document uses the term RA for both RA and LRA.
EE と CA の間の仲介者として機能するエンティティを指します。EE と CA の間には複数の RA が存在できます。RA は、キーの生成やキーのアーカイブなどの追加サービスを実行する場合があります。この文書では、RA と LRA の両方に対して RA という用語を使用します。
Certification Authority (CA):
認証局 (CA):
Refers to the entity that issues certificates.
証明書を発行するエンティティを指します。
Client:
クライアント:
Refers to an entity that creates a PKI Request. In this document, both RAs and EEs can be clients.
PKI リクエストを作成するエンティティを指します。このドキュメントでは、RA と EE の両方がクライアントになることができます。
Server:
サーバ:
Refers to the entities that process PKI Requests and create PKI Responses. In this document, both CAs and RAs can be servers.
PKI 要求を処理し、PKI 応答を作成するエンティティを指します。このドキュメントでは、CA と RA の両方がサーバーになることができます。
PKCS #10:
PKCS #10:
Refers to the Public Key Cryptography Standard #10 [PKCS10], which defines a certification request syntax.
証明書要求の構文を定義する公開鍵暗号化標準 #10 [PKCS10] を指します。
CRMF:
CRMF:
Refers to the Certificate Request Message Format [CRMF]. CMC uses the certification request syntax defined in this document as part of the protocol.
証明書要求メッセージ形式 [CRMF] を指します。CMC は、この文書で定義されている認証要求構文をプロトコルの一部として使用します。
CMS:
CMS:
Refers to the Cryptographic Message Syntax [CMS]. This document provides for basic cryptographic services including encryption and signing with and without key management.
暗号メッセージ構文 [CMS] を指します。この文書では、鍵管理の有無にかかわらず、暗号化と署名を含む基本的な暗号化サービスについて説明します。
PKI Request/Response:
PKI リクエスト/レスポンス:
Refers to the requests/responses described in this document. PKI Requests include certification requests, revocation requests, etc. PKI Responses include "certs-only" messages, failure messages, etc.
このドキュメントで説明されているリクエスト/レスポンスを指します。PKI 要求には、認証要求、失効要求などが含まれます。PKI 応答には、「証明書のみ」メッセージ、失敗メッセージなどが含まれます。
Proof-of-Identity:
身元証明:
Refers to the client proving they are who they say that they are to the server.
クライアントがサーバーに対して自分が誰であるかを証明することを指します。
Enrollment or certification request:
登録または認定のリクエスト:
Refers to the process of a client requesting a certificate. A certification request is a subset of the PKI Requests.
クライアントが証明書を要求するプロセスを指します。認証リクエストは PKI リクエストのサブセットです。
Proof-of-Possession (POP):
所有証明 (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 EE. The different types of POP are:
公開鍵に対応する秘密鍵が所有されており、EE が使用できることを証明するために使用できる値を指します。POP には次のような種類があります。
* Signature provides the required POP by a signature operation over some data.
* 署名は、一部のデータに対する署名操作によって必要な POP を提供します。
* Direct provides the required POP operation by an encrypted challenge-response mechanism.
* Direct は、暗号化されたチャレンジ/レスポンス メカニズムによって必要な POP 操作を提供します。
* Indirect provides the required POP operation by returning the issued certificate in an encrypted state. (This method is not used by CMC.)
* Indirect は、発行された証明書を暗号化された状態で返すことにより、必要な POP 操作を提供します。(この方法は CMC では使用されません。)
* Publish provides the required POP operation by providing the private key to the certificate issuer. (This method is not currently used by CMC. It would be used by Key Generation or Key Escrow extensions.)
* 発行では、証明書発行者に秘密キーを提供することで、必要な POP 操作が提供されます。(この方法は現在 CMC では使用されていません。キー生成またはキー エスクロー拡張機能で使用されます。)
* Attested provides the required POP operation by allowing a trusted entity to assert that the POP has been proven by one of the above methods.
* Attested は、信頼できるエンティティが POP が上記のいずれかの方法で証明されたことを主張できるようにすることで、必要な POP 操作を提供します。
Object IDentifier (OID):
オブジェクト識別子 (OID):
A primitive type in Abstract Syntax Notation One [ASN.1].
抽象構文表記法 1 [ASN.1] のプリミティブ型。
HMAC:
HMAC:
Refers to the Hashed Message Authentication Code. CMC uses the ASN.1 module defined in [HMAC-ALGS].
ハッシュされたメッセージ認証コードを指します。CMC は、[HMAC-ALGS] で定義されている ASN.1 モジュールを使用します。
Figure 1 shows the Simple PKI Requests and Responses. The contents of the Simple PKI Request and Response are detailed in Sections 3.1 and 4.1.
図 1 は、単純な PKI の要求と応答を示しています。シンプル PKI リクエストとレスポンスの内容については、セクション 3.1 と 4.1 で詳しく説明します。
Simple PKI Request Simple PKI Response
------------------------- --------------------------
+----------+ +------------------+
| PKCS #10 | | CMS ContentInfo |
+----------+--------------+ +------------------+------+
| Certification Request | | CMS Signed Data, |
| | | no SignerInfo |
| Subject Name | | |
| Subject Public Key Info | | SignedData contains one |
| (K_PUB) | | or more certificates in |
| Attributes | | the certificates field |
| | | Relevant CA certs and |
+-----------+-------------+ | CRLs can be included |
| signed with | | as well. |
| matching | | |
| K_PRIV | | encapsulatedContentInfo |
+-------------+ | is absent. |
+--------------+----------+
| unsigned |
+----------+
Figure 1: Simple PKI Requests and Responses
図 1: 単純な PKI リクエストと応答
Figure 2 shows the Full PKI Requests and Responses. The contents of the Full PKI Request and Response are detailed in Sections 3.2 and 4.2.
図 2 は、完全な PKI 要求と応答を示しています。完全な PKI 要求と応答の内容については、セクション 3.2 と 4.2 で詳しく説明します。
Full PKI Request Full PKI Response
----------------------- ------------------------
+----------------+ +----------------+
| CMS ContentInfo| | CMS ContentInfo|
| CMS SignedData | | CMS SignedData |
| or Auth Data | | or Auth Data |
| object | | object |
+----------------+--------+ +----------------+--------+
| | | |
| PKIData | | PKIResponse |
| | | |
| Sequence of: | | Sequence of: |
| <enrollment control>* | | <enrollment control>* |
| <certification request>*| | <CMS object>* |
| <CMS object>* | | <other message>* |
| <other message>* | | |
| | | where * == zero or more |
| where * == zero or more | | |
| | | All certificates issued |
| Certification requests | | as part of the response |
| are CRMF, PKCS #10, or | | are included in the |
| Other. | | "certificates" field |
| | | of the SignedData. |
+-------+-----------------+ | Relevant CA certs and |
| signed (keypair | | CRLs can be included as |
| used may be pre-| | well. |
| existing or | | |
| identified in | +---------+---------------+
| the request) | | signed by the |
+-----------------+ | CA or an LRA |
+---------------+
Figure 2: Full PKI Requests and Responses
図 2: 完全な PKI リクエストと応答
Two types of PKI Requests exist. This section gives the details for both types.
2 種類の PKI リクエストが存在します。このセクションでは、両方のタイプの詳細について説明します。
A Simple PKI Request uses the PKCS #10 syntax CertificationRequest [PKCS10].
シンプル PKI リクエストは、PKCS #10 構文 CertificationRequest [PKCS10] を使用します。
When a server processes a Simple PKI Request, the PKI Response returned is:
サーバーが単純な PKI 要求を処理すると、返される PKI 応答は次のとおりです。
* Simple PKI Response on success.
* 成功時の単純な PKI 応答。
* Full PKI Response on failure. The server MAY choose not to return a PKI Response in this case.
* 失敗時の完全な PKI 応答。この場合、サーバーは PKI 応答を返さないことを選択してもよい(MAY)。
The Simple PKI Request MUST NOT be used if a Proof-of-Identity needs to be included.
Proof-of-Identity を含める必要がある場合、Simple PKI リクエストを使用してはなりません (MUST NOT)。
The Simple PKI Request cannot be used if the private key is not capable of producing some type of signature.
秘密キーがある種の署名を生成できない場合、簡易 PKI リクエストは使用できません。
Note: Diffie-Hellman (DH) and Elliptic Curve Diffie-Hellman (ECDH) keys can use the integrity check algorithms in [DH-POP] to prove they have access to the corresponding private key.
注: Diffie-Hellman (DH) 鍵と楕円曲線 Diffie-Hellman (ECDH) 鍵は、[DH-POP] の整合性チェック アルゴリズムを使用して、対応する秘密鍵にアクセスできることを証明できます。
The Simple PKI Request cannot be used for any of the advanced services specified in this document.
Simple PKI リクエストは、この文書で指定されている高度なサービスには使用できません。
The client MAY incorporate one or more X.509v3 extensions in any certification request based on PKCS #10 as an ExtensionReq attribute. The ExtensionReq attribute is defined as:
クライアントは、PKCS #10 に基づく認証リクエストに 1 つ以上の X.509v3 拡張機能を ExtensionReq 属性として組み込むことができます (MAY)。ExtensionReq 属性は次のように定義されます。
ExtensionReq ::= SEQUENCE SIZE (1..MAX) OF Extension
where Extension is imported from [PKIXCERT] [ADD-ASN1] and ExtensionReq is identified by:
ここで、Extension は [PKIXCERT] [ADD-ASN1] からインポートされ、ExtensionReq は次によって識別されます。
id-ExtensionReq OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 14 }
Servers MUST be able to process all extensions defined, but not prohibited, in [PKIXCERT]. Servers are not required to be able to process other X.509v3 extensions transmitted using this protocol, nor are they required to be able to process private extensions. Servers are not required to put all client-requested extensions into a certificate. Servers are permitted to modify client-requested extensions. Servers MUST NOT alter an extension so as to invalidate the original intent of a client-requested extension. (For example, changing key usage from keyAgreement to digitalSignature.) If a certification request is denied due to the inability to handle a requested extension and a PKI Response is returned, the server MUST return a PKI Response with a CMCFailInfo value with the value unsupportedExt.
サーバーは、[PKIXCERT] で定義されているが禁止されていないすべての拡張機能を処理できなければなりません (MUST)。サーバーは、このプロトコルを使用して送信される他の X.509v3 拡張機能を処理できる必要はなく、プライベート拡張機能を処理できる必要もありません。サーバーは、クライアントが要求したすべての拡張機能を証明書に含める必要はありません。サーバーは、クライアントが要求した拡張機能を変更することが許可されています。サーバーは、クライアントが要求した拡張機能の本来の意図を無効にするために拡張機能を変更してはなりません (MUST NOT)。(たとえば、鍵の使用法を keyAgreement から digitalSignature に変更する。) 要求された拡張機能を処理できないために認証要求が拒否され、PKI 応答が返された場合、サーバーは、値 unsupportedExt を持つ CMCFailInfo 値を含む PKI 応答を返さなければなりません (MUST)。
The Full PKI Request provides the most functionality and flexibility.
フル PKI リクエストは、最も多くの機能と柔軟性を提供します。
The Full PKI Request is encapsulated in either a SignedData or an AuthenticatedData with an encapsulated content type of id-cct-PKIData (Section 3.2.1).
完全な PKI リクエストは、id-cct-PKIData のカプセル化されたコンテンツ タイプを持つ SignedData または AuthenticatedData のいずれかにカプセル化されます (セクション 3.2.1)。
When a server processes a Full PKI Request, a PKI Response MUST be returned. The PKI Response returned is:
サーバーが完全な PKI 要求を処理する場合、PKI 応答を返さなければなりません (MUST)。返される PKI 応答は次のとおりです。
* Simple PKI Response if the enrollment was successful and only certificates are returned. (An Extended CMC Status Info V2 control with success is implied.)
* 登録が成功し、証明書のみが返された場合の単純な PKI 応答。(拡張 CMC ステータス情報 V2 コントロールの成功が暗黙的に示されます。)
* Full PKI Response if the enrollment was successful and information is returned in addition to certificates, if the enrollment is pending, or if the enrollment failed.
* 登録が成功し、証明書に加えて情報が返された場合、登録が保留中の場合、または登録が失敗した場合の完全な PKI 応答。
If SignedData is used, the signature can be generated using either the private key material of an embedded signature certification request (i.e., included in the TaggedRequest tcr or crm fields) or a previously certified signature key. If the private key of a signature certification request is used, then:
SignedData を使用する場合、埋め込み署名認証リクエスト (つまり、TaggedRequest tcr または crm フィールドに含まれる) の秘密キー素材、または以前に認証された署名キーのいずれかを使用して署名を生成できます。署名証明リクエストの秘密キーが使用される場合は、次のようになります。
1. The certification request containing the corresponding public key MUST include a Subject Key Identifier extension.
1. 対応する公開鍵を含む認証リクエストには、Subject Key Identifier 拡張子が含まれなければなりません (MUST)。
2. The subjectKeyIdentifier form of the signerIdentifier in SignerInfo MUST be used.
2. SignerInfo のsignerIdentifier の subjectKeyIdentifier 形式を使用しなければなりません (MUST)。
3. The value of the subjectKeyIdentifier form of SignerInfo MUST be the Subject Key Identifier specified in the corresponding certification request. (The subjectKeyIdentifier form of SignerInfo is used here because no certificates have yet been issued for the signing key.) If the request key is used for signing, there MUST be only one SignerInfo in the SignedData.
3. SignerInfo の subjectKeyIdentifier 形式の値は、対応する認証要求で指定されたサブジェクト キー識別子でなければなりません。(署名キーの証明書がまだ発行されていないため、ここでは SignerInfo の subjectKeyIdentifier 形式が使用されています。) 要求キーが署名に使用される場合、SignedData には SignerInfo が 1 つだけ存在する必要があります。
If AuthenticatedData is used, then:
AuthenticatedData が使用される場合は、次のようになります。
1. The Password Recipient Info option of RecipientInfo MUST be used.
1. RecipientInfo の Password Recipient Info オプションを使用する必要があります。
2. A randomly generated key is used to compute the Message Authentication Code (MAC) value on the encapsulated content.
2. ランダムに生成されたキーは、カプセル化されたコンテンツのメッセージ認証コード (MAC) 値を計算するために使用されます。
3. The input for the key derivation algorithm is a concatenation of the identifier (encoded as UTF-8) and the shared-secret.
3. キー導出アルゴリズムの入力は、識別子 (UTF-8 としてエンコード) と共有秘密の連結です。
When creating a PKI Request to renew or rekey a certificate:
証明書を更新またはキー再生成するための PKI リクエストを作成する場合:
1. The Identification and Identity Proof controls are absent. The same information is provided by the use of an existing certificate from a CA when signing the PKI Request. In this case, the CA that issued the original certificate and the CA the request is made to will usually be the same, but they could have a common operator.
1. Identification および Identity Proof コントロールはありません。PKI リクエストに署名するときに CA からの既存の証明書を使用することによっても、同じ情報が提供されます。この場合、元の証明書を発行した CA とリクエストの送信先 CA は通常同じですが、共通のオペレーターが存在する可能性があります。
2. CAs and RAs can impose additional restrictions on the signing certificate used. They may require that the most recently issued signing certificate for a client be used.
2. CA と RA は、使用する署名証明書に追加の制限を課すことができます。クライアントに対して最後に発行された署名証明書の使用を要求する場合があります。
3. Some CAs may prevent renewal operations (i.e., reuse of the same keys). In this case, the CA MUST return a PKI Response with noKeyReuse as the CMCFailInfo failure code.
3. CA によっては、更新操作 (つまり、同じキーの再利用) を禁止する場合があります。この場合、CA は CMCFailInfo 失敗コードとして noKeyReuse を含む PKI 応答を返さなければなりません。
The PKIData content type is used for the Full PKI Request. A PKIData content type is identified by:
PKIData コンテンツ タイプは、完全な PKI リクエストに使用されます。PKIData コンテンツ タイプは次によって識別されます。
id-cct-PKIData OBJECT IDENTIFIER ::= { id-pkix id-cct(12) 2 }
The ASN.1 structure corresponding to the PKIData content type is:
PKIData コンテンツ タイプに対応する ASN.1 構造は次のとおりです。
PKIData ::= SEQUENCE {
controlSequence SEQUENCE SIZE (0..MAX) OF TaggedAttribute,
reqSequence SEQUENCE SIZE (0..MAX) OF TaggedRequest,
cmsSequence SEQUENCE SIZE (0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE (0..MAX) OF OtherMsg
}
The fields in PKIData have the following meanings:
PKIData のフィールドには次の意味があります。
* controlSequence is a sequence of controls. The controls defined in this document are found in Section 6. Controls can be defined by other parties. Details on the TaggedAttribute structure can be found in Section 3.2.1.1.
* controlSequence はコントロールのシーケンスです。この文書で定義されているコントロールはセクション 6 にあります。コントロールは他の当事者によって定義される場合があります。TaggedAttribute 構造の詳細については、セクション 3.2.1.1 を参照してください。
* reqSequence is a sequence of certification requests. The certification requests can be a CertificationRequest (PKCS #10), a CertReqMsg (CRMF), or an externally defined PKI Request. Full details are found in Section 3.2.1.2. If an externally defined certification request is present, but the server does not understand the certification request (or will not process it), a CMCStatus of noSupport MUST be returned for the certification request item and no other certification requests are processed.
* reqSequence は、一連の認証要求です。認証要求には、CertificationRequest (PKCS #10)、CertReqMsg (CRMF)、または外部定義された PKI 要求を使用できます。詳細については、セクション 3.2.1.2 を参照してください。外部定義された認証要求が存在するが、サーバーが認証要求を理解できない (または処理しない) 場合、その認証要求項目に対して noSupport の CMCStatus を返さなければならず、他の認証要求は処理されません。
* cmsSequence is a sequence of CMS (see [CMS]) message objects. See Section 3.2.1.3 for more details.
* cmsSequence は、CMS ([CMS] を参照) メッセージ オブジェクトのシーケンスです。詳細については、セクション 3.2.1.3 を参照してください。
* otherMsgSequence is a sequence of arbitrary data objects. Data objects placed here are referred to by one or more controls. This allows for controls to use large amounts of data without the data being embedded in the control. See Section 3.2.1.4 for more details.
* otherMsgSequence は、任意のデータ オブジェクトのシーケンスです。ここに配置されたデータ オブジェクトは、1 つ以上のコントロールによって参照されます。これにより、コントロールにデータを埋め込むことなく、コントロールで大量のデータを使用できるようになります。詳細については、セクション 3.2.1.4 を参照してください。
All certification requests encoded into a single PKIData SHOULD be for the same identity. RAs that batch process (see Section 6.17) are expected to place the PKI Requests received into the cmsSequence of a PKIData.
単一の PKIData にエンコードされたすべての認証リクエストは、同じ ID に対するものである必要があります (SHOULD)。バッチ処理する RA (セクション 6.17 を参照) は、受信した PKI リクエストを PKIData の cmsSequence に配置することが期待されます。
Processing of the PKIData by a recipient is as follows:
受信者による PKIData の処理は次のとおりです。
1. All controls should be examined and processed in an appropriate manner. The appropriate processing is to complete processing at this time, to ignore the control, or to place the control on a to-do list for later processing. Controls can be processed in any order; the order in the sequence is not significant.
1. すべてのコントロールを検査し、適切な方法で処理する必要があります。適切な処理は、この時点で処理を完了するか、コントロールを無視するか、後の処理のためにコントロールを ToDo リストに入れることです。コントロールは任意の順序で処理できます。シーケンス内の順序は重要ではありません。
2. Items in the reqSequence are not referenced by a control. These items, which are certification requests, also need to be processed. As with controls, the appropriate processing can be either immediate processing or addition to a to-do list for later processing.
2. reqSequence 内の項目はコントロールによって参照されません。認証要求であるこれらの項目も処理する必要があります。コントロールと同様に、適切な処理は、即時処理か、後で処理するために To Do リストに追加するかのいずれかです。
3. Finally, the to-do list is processed. In many cases, the to-do list will be ordered by grouping specific tasks together.
3. 最後に、To Do リストが処理されます。多くの場合、ToDo リストは特定のタスクをグループ化して順序付けされます。
No processing is required for cmsSequence or otherMsgSequence members of PKIData if they are present and are not referenced by a control. In this case, the cmsSequence and otherMsgSequence members are ignored.
PKIData の cmsSequence または otherMsgSequence メンバーが存在し、コントロールによって参照されない場合、処理は必要ありません。この場合、cmsSequence メンバーと otherMsgSequence メンバーは無視されます。
The actions to be performed for a PKI Request/Response are based on the included controls. Each control consists of an OID and a value based on the OID.
PKI 要求/応答に対して実行されるアクションは、含まれているコントロールに基づいています。各コントロールは、OID と、OID に基づく値で構成されます。
The syntax of a control is:
コントロールの構文は次のとおりです。
TaggedAttribute ::= SEQUENCE {
bodyPartID BodyPartID,
attrType CMC-CONTROL.&id({Cmc-Control-Set}),
attrValues SET OF CMC-CONTROL.
&Type({Cmc-Control-Set}{@attrType})
}
The fields in TaggedAttribute have the following meanings:
TaggedAttribute のフィールドには次の意味があります。
* bodyPartID is a unique integer that identifies this control.
* bodyPartID は、このコントロールを識別する一意の整数です。
* attrType is the OID that identifies the control.
* attrType はコントロールを識別する OID です。
* attrValues is comprised of the data values used in processing the control. The structure of the data is dependent on the specific control.
* attrValues は、コントロールの処理に使用されるデータ値で構成されます。データの構造は特定のコントロールによって異なります。
The final server MUST fail the processing of an entire PKIData if any included control is not recognized, that control is not already marked as processed by a Control Processed control (see Section 6.19), and no other error is generated. The PKI Response MUST include a CMCFailInfo value with the value badRequest and the bodyList MUST contain the bodyPartID of the invalid or unrecognized control(s). A server is the final server if and only if it is not passing the PKI Request on to another server. A server is not considered to be the final server if the server would have passed the PKI Request on, but instead it returned a processing error.
最終サーバーは、含まれるコントロールが認識されず、そのコントロールがまだ Control Processed コントロールによって処理済みとしてマークされておらず (セクション 6.19 を参照)、その他のエラーが生成されない場合、PKIData 全体の処理に失敗しなければなりません (MUST)。PKI 応答には、値 badRequest を持つ CMCFailInfo 値が含まれなければならず (MUST)、bodyList には無効なコントロールまたは認識されないコントロールの bodyPartID が含まれなければなりません (MUST)。サーバーは、PKI 要求を別のサーバーに渡さない場合に限り、最終サーバーになります。サーバーが PKI 要求を渡しても処理エラーを返した場合、そのサーバーは最終サーバーとはみなされません。
The controls defined by this document are found in Section 6.
この文書で定義されているコントロールはセクション 6 にあります。
Certification requests are based on PKCS #10, CRMF, or Other Request formats. Section 3.2.1.2.1 specifies the requirements for clients and servers dealing with PKCS #10. Section 3.2.1.2.2 specifies the requirements for clients and servers dealing with CRMF. Section 3.2.1.2.3 specifies the requirements for clients and servers dealing with Other Requests.
認証リクエストは、PKCS #10、CRMF、またはその他のリクエスト形式に基づいています。セクション 3.2.1.2.1 では、PKCS #10 を処理するクライアントとサーバーの要件を指定します。セクション 3.2.1.2.2 では、CRMF を処理するクライアントとサーバーの要件を指定します。セクション 3.2.1.2.3 では、その他のリクエストを処理するクライアントとサーバーの要件を指定します。
TaggedRequest ::= CHOICE {
tcr [0] TaggedCertificationRequest,
crm [1] CertReqMsg,
orm [2] SEQUENCE {
bodyPartID BodyPartID,
requestMessageType OTHER-REQUEST.&id({OtherRequests}),
requestMessageValue OTHER-REQUEST.&Type({OtherRequests}
{@.requestMessageType})
}
}
The fields in TaggedRequest have the following meanings:
TaggedRequest のフィールドには次の意味があります。
* tcr is a certification request that uses the PKCS #10 syntax. Details on PKCS #10 are found in Section 3.2.1.2.1.
* tcr は、PKCS #10 構文を使用する認証リクエストです。PKCS #10 の詳細については、セクション 3.2.1.2.1 を参照してください。
* crm is a certification request that uses the CRMF syntax. Details on CRMF are found in Section 3.2.1.2.2.
* crm は、CRMF 構文を使用する認証リクエストです。CRMF の詳細については、セクション 3.2.1.2.2 を参照してください。
* orm is an externally defined certification request. One example is an attribute certification request. The fields of this structure are:
* orm は、外部で定義された認証リクエストです。一例として、属性認証リクエストがあります。この構造体のフィールドは次のとおりです。
- bodyPartID is the identifier number for this certification request. Details on body part identifiers are found in Section 3.2.2.
- bodyPartID は、この認証リクエストの識別番号です。身体部分の識別子の詳細については、セクション 3.2.2 を参照してください。
- requestMessageType identifies the other request type. These values are defined outside of this document.
- requestMessageType は、他のリクエスト タイプを識別します。これらの値は、このドキュメントの外で定義されます。
- requestMessageValue is the data associated with the other request type.
- requestMessageValue は、他のリクエスト タイプに関連付けられたデータです。
A certification request based on PKCS #10 uses the following ASN.1 structure:
PKCS #10 に基づく認証リクエストでは、次の ASN.1 構造が使用されます。
TaggedCertificationRequest ::= SEQUENCE {
bodyPartID BodyPartID,
certificationRequest CertificationRequest
}
The fields in TaggedCertificationRequest have the following meanings:
TaggedCertificationRequest のフィールドには次の意味があります。
* bodyPartID is the identifier number for this certification request. Details on body part identifiers are found in Section 3.2.2.
* bodyPartID は、この認証リクエストの識別番号です。身体部分の識別子の詳細については、セクション 3.2.2 を参照してください。
* certificationRequest contains the certification request based on PKCS #10. Its fields are described in [PKCS10].
* certificationRequest には、PKCS #10 に基づく認証リクエストが含まれます。そのフィールドは [PKCS10] で説明されています。
When producing a certification request based on PKCS #10, clients MUST produce the certification request with a subject name and public key. Some PKI products are operated using a central repository of information to assign subject names upon receipt of a certification request. To accommodate this mode of operation, the subject field in a CertificationRequest MAY be NULL, but it MUST be present. CAs that receive a CertificationRequest with a NULL subject field MAY reject such certification requests. If rejected and a PKI Response is returned, the CA MUST return a PKI Response with the CMCFailInfo value with the value badRequest.
PKCS #10 に基づいて認証リクエストを作成する場合、クライアントはサブジェクト名と公開キーを使用して認証リクエストを作成しなければなりません (MUST)。一部の PKI 製品は、認証要求の受信時にサブジェクト名を割り当てる情報の中央リポジトリを使用して運用されています。この動作モードに対応するために、CertificationRequest の subject フィールドは NULL であっても構いませんが、存在しなければなりません。NULL 件名フィールドを持つ CertificationRequest を受信した CA は、そのような認証リクエストを拒否してもよい(MAY)。拒否されて PKI 応答が返された場合、CA は CMCFailInfo 値と値 badRequest を含む PKI 応答を返さなければなりません。
A CRMF message uses the following ASN.1 structure (defined in [CRMF][ADD-ASN1] and included here for convenience):
CRMF メッセージは、次の ASN.1 構造を使用します ([CRMF][ADD-ASN1] で定義されており、便宜上ここに含まれています)。
CertReqMsg ::= SEQUENCE {
certReq CertRequest,
popo ProofOfPossession OPTIONAL,
-- content depends upon key type
regInfo SEQUENCE SIZE (1..MAX) OF
SingleAttribute{{RegInfoSet}} OPTIONAL }
CertRequest ::= SEQUENCE {
certReqId INTEGER,
-- ID for matching request and reply
certTemplate CertTemplate,
-- Selected fields of cert to be issued
controls Controls OPTIONAL }
-- Attributes affecting issuance
CertTemplate ::= SEQUENCE {
version [0] Version OPTIONAL,
serialNumber [1] INTEGER OPTIONAL,
signingAlg [2] AlgorithmIdentifier{SIGNATURE-ALGORITHM,
{SignatureAlgorithms}} OPTIONAL,
issuer [3] Name OPTIONAL,
validity [4] OptionalValidity OPTIONAL,
subject [5] Name OPTIONAL,
publicKey [6] SubjectPublicKeyInfo OPTIONAL,
issuerUID [7] UniqueIdentifier OPTIONAL,
subjectUID [8] UniqueIdentifier OPTIONAL,
extensions [9] Extensions{{CertExtensions}} OPTIONAL }
The fields in CertReqMsg are explained in [CRMF].
CertReqMsg のフィールドについては [CRMF] で説明されています。
This document imposes the following additional restrictions on the construction and processing of CRMF:
この文書では、CRMF の構築と処理に次の追加の制限を課します。
* When a Full PKI Request includes a CRMF, both the subject and publicKey fields in the CertTemplate MUST be defined. The subject field can be encoded as NULL, but it MUST be present.
* フル PKI リクエストに CRMF が含まれる場合、CertTemplate の subject フィールドと publicKey フィールドの両方を定義する必要があります。subject フィールドは NULL としてエンコードできますが、存在する必要があります。
* When both CRMF and CMC controls exist with equivalent functionality, the CMC control SHOULD be used. The CMC control MUST override the CRMF control.
* CRMF コントロールと CMC コントロールの両方が同等の機能を備えて存在する場合、CMC コントロールを使用する必要があります (SHOULD)。CMC コントロールは CRMF コントロールをオーバーライドしなければなりません (MUST)。
* The regInfo field MUST NOT be used on a CRMF. Equivalent functionality is provided in the CMC regInfo control (Section 6.12).
* regInfo フィールドは CRMF で使用してはなりません (MUST NOT)。同等の機能が CMC regInfo コントロールで提供されます (セクション 6.12)。
* The indirect method of proving POP is not supported in this protocol. One of the other methods (including the direct method described in this document) MUST be used. The value of encrCert in SubsequentMessage MUST NOT be used.
* このプロトコルでは、POP を証明する間接的な方法はサポートされていません。他の方法 (この文書で説明されている直接方法を含む) のいずれかを使用する必要があります。SubsequentMessage の encrCert の値は使用してはなりません (MUST NOT)。
* Since the subject and publicKey fields are always present, the POPOSigningKeyInput MUST NOT be used when computing the value for POPSigningKey.
* subject フィールドと publicKey フィールドは常に存在するため、POPSigningKey の値を計算するときに POPOSigningKeyInput を使用してはなりません (MUST NOT)。
A server is not required to use all of the values suggested by the client in the CRMF. Servers MUST be able to process all extensions defined, but not prohibited, in [PKIXCERT]. Servers are not required to be able to process other X.509v3 extensions transmitted using this protocol, nor are they required to be able to process private extensions. Servers are permitted to modify client-requested extensions. Servers MUST NOT alter an extension so as to invalidate the original intent of a client-requested extension. (For example, change key usage from keyAgreement to digitalSignature.) If a certification request is denied due to the inability to handle a requested extension and a Full PKI Response is returned, the server MUST return a CMCFailInfo value with the value of unsupportedExt.
サーバーは、CRMF でクライアントによって提案されたすべての値を使用する必要はありません。サーバーは、[PKIXCERT] で定義されているが禁止されていないすべての拡張機能を処理できなければなりません (MUST)。サーバーは、このプロトコルを使用して送信される他の X.509v3 拡張機能を処理できる必要はなく、プライベート拡張機能を処理できる必要もありません。サーバーは、クライアントが要求した拡張機能を変更することが許可されています。サーバーは、クライアントが要求した拡張機能の本来の意図を無効にするために拡張機能を変更してはなりません (MUST NOT)。(たとえば、キーの使用法を keyAgreement からdigitalSignature に変更します。) 要求された拡張機能を処理できないために認証要求が拒否され、完全な PKI 応答が返された場合、サーバーは unsupportedExt の値を持つ CMCFailInfo 値を返さなければなりません (MUST)。
This document allows for other certification request formats to be defined and used as well. An example of another certification request format is one for Attribute Certificates. These other certification request formats are defined by specifying an OID for identification and the structure to contain the data to be passed.
この文書では、他の認証要求フォーマットを定義して使用することもできます。別の認証要求フォーマットの例としては、属性証明書のフォーマットがあります。これらの他の認証要求フォーマットは、識別のための OID と、渡されるデータを含む構造を指定することによって定義されます。
The cmsSequence field of the PKIData and PKIResponse messages contains zero or more tagged content info objects. The syntax for this structure is:
PKIData および PKIResponse メッセージの cmsSequence フィールドには、0 個以上のタグ付きコンテンツ情報オブジェクトが含まれます。この構造の構文は次のとおりです。
TaggedContentInfo ::= SEQUENCE {
bodyPartID BodyPartID,
contentInfo ContentInfo
}
The fields in TaggedContentInfo have the following meanings:
TaggedContentInfo のフィールドには次の意味があります。
* bodyPartID is a unique integer that identifies this content info object.
* bodyPartID は、このコンテンツ情報オブジェクトを識別する一意の整数です。
* contentInfo is a ContentInfo object (defined in [CMS]).
* contentInfo は ContentInfo オブジェクト ([CMS] で定義) です。
The five content types used in cmsSequence are AuthenticatedData, Data, EnvelopedData, SignedData, and AuthEnvelopedData. The first four content types are defined in [CMS] and the last is defined in [CMS-AE].
cmsSequence で使用される 5 つのコンテンツ タイプは、AuthenticatedData、Data、EnvelopedData、SignedData、および AuthEnvelopedData です。最初の 4 つのコンテンツ タイプは [CMS] で定義され、最後のコンテンツ タイプは [CMS-AE] で定義されます。
The AuthenticatedData content type provides a method of doing pre-shared-secret-based validation of data being sent between two parties. Unlike SignedData, it does not specify which party actually generated the information.
AuthenticatedData コンテンツ タイプは、2 者間で送信されるデータの事前共有秘密ベースの検証を行う方法を提供します。SignedData とは異なり、どの当事者が実際に情報を生成したかは指定されません。
AuthenticatedData provides origination authentication in those circumstances where a shared-secret exists, but a PKI-based trust has not yet been established. No PKI-based trust may have been established because a trust anchor has not been installed on the client or no certificate exists for a signing key.
AuthenticatedData は、共有秘密は存在するが、PKI ベースの信頼がまだ確立されていない状況で発信元認証を提供します。トラスト アンカーがクライアントにインストールされていないか、署名キーの証明書が存在しないため、PKI ベースの信頼が確立されていない可能性があります。
AuthenticatedData content type is used by this document for:
AuthenticatedData コンテンツ タイプは、このドキュメントで次の目的で使用されます。
* The id-cmc-authData control (Section 6.16), and
* id-cmc-authData コントロール (セクション 6.16)、および
* The top-level wrapper in environments where an encryption-only key is being certified or where a shared-secret exists, but a PKI-based trust (needed for SignedData) has not yet been established.
* 暗号化専用キーが認証されている環境、または共有秘密が存在するが、PKI ベースの信頼 (SignedData に必要) がまだ確立されていない環境のトップレベル ラッパー。
This content type can include both PKIData and PKIResponse as the encapsulated content types. These embedded content types can contain additional controls that need to be processed.
このコンテンツ タイプには、カプセル化されたコンテンツ タイプとして PKIData と PKIResponse の両方を含めることができます。これらの埋め込みコンテンツ タイプには、処理が必要な追加のコントロールが含まれる場合があります。
The Data content type allows for general transport of unstructured data.
データ コンテンツ タイプを使用すると、非構造化データの一般的な転送が可能になります。
The Data content type is used by this document for:
データ コンテンツ タイプは、このドキュメントで次の目的で使用されます。
* Holding the encrypted random value y for POP in the Encrypted POP control (see Section 6.7).
* 暗号化された POP コントロール内の POP の暗号化されたランダム値 y を保持します (セクション 6.7 を参照)。
The EnvelopedData content type provides for the shrouding of data.
EnvelopedData コンテンツ タイプは、データの覆いを提供します。
The EnvelopedData content type is one confidentiality method for sensitive information in this protocol. EnvelopedData can provide encryption of an entire PKI Request (see Section 5). EnvelopedData can also be used to wrap private key material that is to be archived. If the decryption on an EnvelopedData fails, a Full PKI Response is returned with a CMCFailInfo value of badMessageCheck and a bodyPartID of 0.
EnvelopedData コンテンツ タイプは、このプロトコルにおける機密情報の機密保持方法の 1 つです。EnvelopedData は、PKI リクエスト全体の暗号化を提供できます (セクション 5 を参照)。EnvelopedData は、アーカイブされる秘密キー素材をラップするために使用することもできます。EnvelopedData の復号化が失敗した場合、完全な PKI 応答が、CMCFailInfo 値 badMessageCheck および bodyPartID 0 とともに返されます。
The SignedData content type provides for authentication and integrity.
SignedData コンテンツ タイプは、認証と整合性を提供します。
The SignedData content type is used by this document for:
SignedData コンテンツ タイプは、このドキュメントで次の目的で使用されます。
* The outer wrapper for a PKI Request.
* PKI リクエストの外側のラッパー。
* The outer wrapper for a PKI Response.
* PKI 応答の外側のラッパー。
As part of processing a PKI Request/Response, the signature(s) MUST be verified. If the signature does not verify and the PKI Request/ Response contains anything other than an Extended CMC Status Info or a CMC Status Info control, a Full PKI Response containing an Extended CMC Status Info or a CMC Status Info control MUST be returned using a CMCFailInfo with a value of badMessageCheck and a bodyPartID of 0.
PKI 要求/応答の処理の一部として、署名を検証する必要があります。署名が検証されず、PKI 要求/応答に拡張 CMC ステータス情報または CMC ステータス情報コントロール以外のものが含まれている場合、拡張 CMC ステータス情報または CMC ステータス情報コントロールを含む完全な PKI 応答を、値 badMessageCheck および bodyPartID 0 を持つ CMCFailInfo を使用して返さなければなりません (MUST)。
For the PKI Response, SignedData allows the server to sign the returning data, if any exists, and to carry the certificates and CRLs corresponding to the PKI Request. If no data is being returned beyond the certificates and CRLs, there is no eContent field in the EncapsulatedContentInfo and no SignerInfo.
PKI 応答の場合、SignedData を使用すると、サーバーは返されるデータ (存在する場合) に署名し、PKI 要求に対応する証明書と CRL を保持できます。証明書と CRL を超えてデータが返されない場合、EncapsulatedContentInfo に eContent フィールドも SignerInfo もありません。
Only if the server is unable to sign the response (and unable to use any RecipientInfo options of the AuthenticatedData content type), should it send a negative response. A Full PKI Response SignedData type containing an Extended CMC Status Info or a CMC Status Info control MUST be returned using a CMCFailInfo with a value of internalCAError and a bodyPartID of 0, and the eContent field in the EncapsulatedContentInfo as well as SignerInfo fields MUST NOT be populated.
サーバーが応答に署名できない (および AuthenticatedData コンテンツ タイプの RecipientInfo オプションを使用できない) 場合にのみ、否定応答を送信する必要があります。拡張 CMC ステータス情報または CMC ステータス情報コントロールを含む完全な PKI 応答 SignedData タイプは、internalCAError の値と 0 の bodyPartID を持つ CMCFailInfo を使用して返されなければなりません (MUST)。また、EncapsulatedContentInfo の eContent フィールドおよび SignerInfo フィールドには値を設定してはなりません (MUST NOT)。
The AuthEnvelopedData content type provides for the shrouding of data.
AuthEnvelopedData コンテンツ タイプは、データの覆いを提供します。
The AuthEnvelopedData content type is the primary confidentiality method for sensitive information in this protocol. AuthEnvelopedData can provide encryption of an entire PKI Request (see Section 5). AuthEnvelopedData can also be used to wrap private key material that is to be archived. If the decryption on an AuthEnvelopedData fails, a Full PKI Response is returned with a CMCFailInfo value of badMessageCheck and a bodyPartID of 0.
AuthEnvelopedData コンテンツ タイプは、このプロトコルにおける機密情報の主要な機密性保持方法です。AuthEnvelopedData は、PKI リクエスト全体の暗号化を提供できます (セクション 5 を参照)。AuthEnvelopedData は、アーカイブされる秘密キー素材をラップするために使用することもできます。AuthEnvelopedData の復号化が失敗した場合、完全な PKI 応答が、CMCFailInfo 値 badMessageCheck および bodyPartID 0 とともに返されます。
The otherMsgSequence field of the PKI Request/Response allows for arbitrary data objects to be carried as part of a PKI Request/ Response. This is intended to contain a data object that is not already wrapped in a cmsSequence field (Section 3.2.1.3). The data object is ignored unless a control references the data object by bodyPartID.
PKI 要求/応答の otherMsgSequence フィールドを使用すると、任意のデータ オブジェクトを PKI 要求/応答の一部として伝送できます。これは、cmsSequence フィールド (セクション 3.2.1.3) にまだラップされていないデータ オブジェクトを含めることを目的としています。コントロールが bodyPartID によってデータ オブジェクトを参照しない限り、データ オブジェクトは無視されます。
OtherMsg ::= SEQUENCE {
bodyPartID BodyPartID,
otherMsgType OTHER-MSG.&id({OtherMsgSet}),
otherMsgValue OTHER-MSG.&Type({OtherMsgSet}{@otherMsgType}) }
The fields in OtherMsg have the following meanings:
OtherMsg のフィールドには次の意味があります。
* bodyPartID is the unique id identifying this data object.
* bodyPartID は、このデータ オブジェクトを識別する一意の ID です。
* otherMsgType is the OID that defines the type of message body.
* otherMsgType は、メッセージ本文のタイプを定義する OID です。
* otherMsgValue is the data.
* otherMsgValue はデータです。
Each element of a PKIData or PKIResponse has an associated body part identifier. The body part identifier is a 4-octet integer using the ASN.1 of:
PKIData または PKIResponse の各要素には、関連する本体部分の識別子があります。ボディ部分の識別子は、次の ASN.1 を使用した 4 オクテットの整数です。
bodyIdMax INTEGER ::= 4294967295
BodyPartID ::= INTEGER(0..bodyIdMax)
Body part identifiers are encoded in the certReqIds field for CertReqMsg objects (in a TaggedRequest) or in the bodyPartID field of the other objects. The body part identifier MUST be unique within a single PKIData or PKIResponse. Body part identifiers can be duplicated in different layers (for example, a PKIData embedded within another).
ボディ部分の識別子は、CertReqMsg オブジェクト (TaggedRequest 内) の certReqIds フィールド、または他のオブジェクトの bodyPartID フィールドでエンコードされます。ボディ部分の識別子は、単一の PKIData または PKIResponse 内で一意でなければなりません。身体部分の識別子は、異なるレイヤーで複製できます (たとえば、別のレイヤーに埋め込まれた PKIData)。
The bodyPartID value of 0 is reserved for use as the reference to the current PKIData object.
bodyPartID 値 0 は、現在の PKIData オブジェクトへの参照として使用するために予約されています。
Some controls, such as the Add Extensions control (Section 6.5.2), use the body part identifier in the pkiDataReference field to refer to a PKI Request in the current PKIData. Some controls, such as the Extended CMC Status Info control (Section 6.1.1), will also use body part identifiers to refer to elements in the previous PKI Request/ Response. This allows an error to be explicit about the control or PKI Request to which the error applies.
拡張機能の追加コントロール (セクション 6.5.2) などの一部のコントロールは、pkiDataReference フィールドのボディ部分識別子を使用して、現在の PKIData 内の PKI リクエストを参照します。拡張 CMC ステータス情報コントロール (セクション 6.1.1) などの一部のコントロールは、ボディ部分の識別子を使用して前の PKI 要求/応答の要素を参照します。これにより、エラーが適用されるコントロールまたは PKI リクエストについてエラーを明示できるようになります。
A BodyPartList contains a list of body parts in a PKI Request/ Response (i.e., the Batch Request control in Section 6.17). The ASN.1 type BodyPartList is defined as:
BodyPartList には、PKI リクエスト/レスポンス (つまり、セクション 6.17 のバッチ リクエスト コントロール) のボディ パーツのリストが含まれます。ASN.1 タイプの BodyPartList は次のように定義されます。
BodyPartList ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
A BodyPartPath contains a path of body part identifiers moving through nesting (i.e., the Modify Certification Request control in Section 6.5.1). The ASN.1 type BodyPartPath is defined as:
BodyPartPath には、ネストを介して移動するボディ パーツ識別子のパスが含まれます (つまり、セクション 6.5.1 の証明書要求の変更コントロール)。ASN.1 タイプの BodyPartPath は次のように定義されます。
BodyPartPath ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
There is sometimes a need to include data in a PKI Request designed to be removed by an RA during processing. An example of this is the inclusion of an encrypted private key, where a Key Archive Agent removes the encrypted private key before sending it on to the CA. One side effect of this desire is that every RA that encapsulates this information needs to move the data so that it is not covered by that RA's signature. (A client PKI Request encapsulated by an RA cannot have a signed control removed by the Key Archive Agent without breaking the RA's signature.) The CMC Unsigned Data attribute addresses this problem.
処理中に RA によって削除されるように設計された PKI リクエストにデータを含める必要がある場合があります。この例としては、暗号化された秘密キーを含める場合が挙げられます。この場合、キー アーカイブ エージェントは暗号化された秘密キーを CA に送信する前に削除します。この要望の副作用の 1 つは、この情報をカプセル化するすべての RA が、その RA の署名でカバーされないようにデータを移動する必要があることです。(RA によってカプセル化されたクライアント PKI 要求は、RA の署名を破壊せずにキー アーカイブ エージェントによって署名付きコントロールを削除することはできません。) CMC 署名なしデータ属性は、この問題に対処します。
The CMC Unsigned Data attribute contains information that is not directly signed by a client. When an RA encounters this attribute in the unsigned or unauthenticated attribute field of a request it is aggregating, the CMC Unsigned Data attribute is removed from the request prior to placing the request in a cmsSequence and placed in the unsigned or unauthenticated attributes of the RA's signed or authenticated data wrapper.
CMC 署名なしデータ属性には、クライアントによって直接署名されていない情報が含まれています。RA が、集約中のリクエストの未署名または未認証属性フィールドでこの属性を検出すると、CMC 未署名データ属性は、リクエストを cmsSequence に配置する前にリクエストから削除され、RA の署名付きまたは認証済みデータ ラッパーの未署名または未認証属性に配置されます。
The CMC Unsigned Data attribute is identified by:
CMC 署名なしデータ属性は次によって識別されます。
id-aa-cmc-unsignedData OBJECT IDENTIFIER ::= { id-aa 34 }
The CMC Unsigned Data attribute has the ASN.1 definition:
CMC 署名なしデータ属性には、ASN.1 定義があります。
CMCUnsignedData ::= SEQUENCE {
bodyPartPath BodyPartPath,
identifier TYPE-IDENTIFIER.&id,
content TYPE-IDENTIFIER.&Type
}
The fields in CMCUnsignedData have the following meanings:
CMCUnsignedData のフィールドには次の意味があります。
* bodyPartPath is the path pointing to the control associated with this data. When an RA moves the control in an unsigned or unauthenticated attribute up one level as part of wrapping the data in a new SignedData or AuthenticatedData, the body part identifier of the embedded item in the PKIData is prepended to the bodyPartPath sequence.
* bodyPartPath は、このデータに関連付けられたコントロールを指すパスです。新しい SignedData または AuthenticatedData でデータをラップする一環として、RA が unsigned または unauthenticated 属性のコントロールを 1 レベル上に移動すると、PKIData 内の埋め込み項目のボディ部分識別子が bodyPartPath シーケンスの先頭に追加されます。
* identifier is the OID that defines the associated data.
* identifier は、関連するデータを定義する OID です。
* content is the data.
* コンテンツはデータです。
There MUST be at most one CMC Unsigned Data attribute in the UnsignedAttribute sequence of a SignerInfo or in the UnauthenticatedAttribute sequence of an AuthenticatedData. UnsignedAttribute consists of a set of values; the attribute can have any number of values greater than zero in that set. If the CMC Unsigned Data attribute is in one SignerInfo or AuthenticatedData, it MUST appear with the same values(s) in all SignerInfo and AuthenticatedData items.
SignerInfo の UnsignedAttribute シーケンスまたは AuthenticatedData の UnauthenticatedAttribute シーケンスには、最大 1 つの CMC Unsigned Data 属性が存在する必要があります。UnsignedAttribute は一連の値で構成されます。属性には、そのセット内でゼロより大きい任意の数の値を含めることができます。CMC 署名なしデータ属性が 1 つの SignerInfo または AuthenticatedData にある場合、それはすべての SignerInfo および AuthenticatedData 項目に同じ値で表示されなければなりません。
Two types of PKI Responses exist. This section gives the details on both types.
2 種類の PKI 応答が存在します。このセクションでは、両方のタイプについて詳しく説明します。
Clients MUST be able to process the Simple PKI Response. The Simple PKI Response consists of a SignedData with no EncapsulatedContentInfo and no SignerInfo. The certificates requested in the PKI Response are returned in the certificate field of the SignedData.
クライアントは、Simple PKI Response を処理できなければなりません。シンプル PKI 応答は、EncapsulatedContentInfo や SignerInfo を含まない SignedData で構成されます。PKI 応答で要求された証明書は、SignedData の証明書フィールドで返されます。
Clients MUST NOT assume the certificates are in any order. Servers SHOULD include all intermediate certificates needed to form complete certification paths to one or more trust anchors, not just the newly issued certificate(s). The server MAY additionally return CRLs in the crls field. Servers MAY include the self-signed certificates. Clients MUST NOT implicitly trust an included self-signed certificate(s) merely due to its presence in the certificates field. In the event clients receive a new self-signed certificate from the server, clients SHOULD provide a mechanism to enable the user to use the certificate as a trust anchor.
クライアントは、証明書が任意の順序であると想定してはなりません。サーバーには、新しく発行された証明書だけでなく、1 つ以上のトラスト アンカーへの完全な証明書パスを形成するために必要なすべての中間証明書を含める必要があります (SHOULD)。サーバーは、crls フィールドで CRL をさらに返すこともできます (MAY)。サーバーには自己署名証明書が含まれていてもよい（MAY）。クライアントは、単に証明書フィールドに存在するという理由だけで、含まれている自己署名証明書を暗黙的に信頼してはなりません。クライアントがサーバーから新しい自己署名証明書を受け取った場合、クライアントはユーザーがその証明書をトラストアンカーとして使用できるようにするメカニズムを提供すべきです(SHOULD)。
Note: The Publish Trust Anchors control (Section 6.15) should be used in the event that the server intends the client to accept one or more certificates as trust anchors. This requires the use of the Full PKI Response message.
注: トラスト アンカーの発行コントロール (セクション 6.15) は、サーバーがクライアントに 1 つ以上の証明書をトラスト アンカーとして受け入れることを意図している場合に使用する必要があります。これには、完全な PKI 応答メッセージを使用する必要があります。
Clients MUST be able to process a Full PKI Response.
クライアントは完全な PKI 応答を処理できなければなりません。
The Full PKI Response consists of a SignedData or AuthenticatedData encapsulating a PKIResponse content type. The certificates issued in a PKI Response are returned in the certificates field of the immediately encapsulating SignedData.
完全な PKI 応答は、PKIResponse コンテンツ タイプをカプセル化する SignedData または AuthenticatedData で構成されます。PKI 応答で発行された証明書は、すぐにカプセル化された SignedData の証明書フィールドで返されます。
Clients MUST NOT assume the certificates are in any order. Servers SHOULD include all intermediate certificates needed to form complete chains to one or more trust anchors, not just the newly issued certificate(s). The server MAY additionally return CRLs in the CRL bag. Servers MAY include self-signed certificates. Clients MUST NOT implicitly trust an included self-signed certificate(s) merely due to its presence in the certificates field. In the event clients receive a new self-signed certificate from the server, clients MAY provide a mechanism to enable the user to explicitly use the certificate as a trust anchor.
クライアントは、証明書が任意の順序であると想定してはなりません。サーバーには、新しく発行された証明書だけでなく、1 つ以上のトラスト アンカーへの完全なチェーンを形成するために必要なすべての中間証明書を含める必要があります (SHOULD)。サーバーはさらに CRL バッグ内の CRL を返してもよい (MAY)。サーバーには自己署名証明書が含まれていてもよい（MAY）。クライアントは、単に証明書フィールドに存在するという理由だけで、含まれている自己署名証明書を暗黙的に信頼してはなりません。クライアントがサーバーから新しい自己署名証明書を受信した場合、クライアントは、ユーザーがその証明書をトラストアンカーとして明示的に使用できるようにするメカニズムを提供してもよい(MAY)。
Note: The Publish Trust Anchors control (Section 6.15) exists for the purpose of allowing for distribution of trust anchor certificates. If a trusted anchor publishes a new trusted anchor, this is one case where automated trust of the new trust anchor could be allowed.
注: トラスト アンカーの発行コントロール (セクション 6.15) は、トラスト アンカー証明書の配布を可能にするために存在します。トラステッド アンカーが新しいトラステッド アンカーを公開する場合、これは新しいトラスト アンカーの自動信頼が許可される 1 つのケースです。
The PKIResponse content type is used for the Full PKI Response. The PKIResponse content type is identified by:
PKIResponse コンテンツ タイプは、完全な PKI 応答に使用されます。PKIResponse コンテンツ タイプは次によって識別されます。
id-cct-PKIResponse OBJECT IDENTIFIER ::= { id-pkix id-cct(12) 3 }
The ASN.1 structure corresponding to the PKIResponse content type is:
PKIResponse コンテンツ タイプに対応する ASN.1 構造は次のとおりです。
PKIResponse ::= SEQUENCE {
controlSequence SEQUENCE SIZE (0..MAX) OF TaggedAttribute,
cmsSequence SEQUENCE SIZE (0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE (0..MAX) OF OtherMsg
}
ResponseBody ::= PKIResponse
Note: In [RFC2797], this ASN.1 type was named ResponseBody. It has been renamed to PKIResponse for clarity and the old name kept as a synonym.
注: [RFC2797] では、この ASN.1 タイプは ResponseBody と呼ばれていました。わかりやすくするために名前が PKIResponse に変更され、古い名前は同義語として保持されます。
The fields in PKIResponse have the following meanings:
PKIResponse のフィールドには次の意味があります。
* controlSequence is a sequence of controls. The controls defined in this document are found in Section 6. Controls can be defined by other parties. Details on the TaggedAttribute structure are found in Section 3.2.1.1.
* controlSequence はコントロールのシーケンスです。この文書で定義されているコントロールはセクション 6 にあります。コントロールは他の当事者によって定義される場合があります。TaggedAttribute 構造の詳細については、セクション 3.2.1.1 を参照してください。
* cmsSequence is a sequence of [CMS] message objects. See Section 3.2.1.3 for more details.
* cmsSequence は、[CMS] メッセージ オブジェクトのシーケンスです。詳細については、セクション 3.2.1.3 を参照してください。
* otherMsgSequence is a sequence of arbitrary data objects. Data objects placed here are referred to by one or more controls. This allows for controls to use large amounts of data without the data being embedded in the control. See Section 3.2.1.4 for more details.
* otherMsgSequence は、任意のデータ オブジェクトのシーケンスです。ここに配置されたデータ オブジェクトは、1 つ以上のコントロールによって参照されます。これにより、コントロールにデータを埋め込むことなく、コントロールで大量のデータを使用できるようになります。詳細については、セクション 3.2.1.4 を参照してください。
Processing of PKIResponse by a recipient is as follows:
受信者による PKIResponse の処理は次のとおりです。
1. All controls should be examined and processed in an appropriate manner. The appropriate processing is to complete processing at this time, to ignore the control, or to place the control on a to-do list for later processing.
1. すべてのコントロールを検査し、適切な方法で処理する必要があります。適切な処理は、この時点で処理を完了するか、コントロールを無視するか、後の処理のためにコントロールを ToDo リストに入れることです。
2. Additional processing of non-element items includes the saving of certificates and CRLs present in wrapping layers. This type of processing is based on the consumer of the element and should not be relied on by generators.
2. 非要素項目の追加処理には、ラッピング層に存在する証明書と CRL の保存が含まれます。このタイプの処理は要素のコンシューマに基づいており、ジェネレータによって依存されるべきではありません。
No processing is required for cmsSequence or otherMsgSequence members of the PKIResponse if items are present and are not referenced by a control. In this case, the cmsSequence and otherMsgSequence members are to be ignored.
項目が存在し、コントロールによって参照されない場合、PKIResponse の cmsSequence または otherMsgSequence メンバーに対する処理は必要ありません。この場合、cmsSequence および otherMsgSequence メンバーは無視されます。
There are occasions when a PKI Request or Response must be encrypted in order to prevent disclosure of information in the PKI Request/ Response from being accessible to unauthorized entities. This section describes the means to encrypt Full PKI Requests and Responses (Simple PKI Requests cannot be encrypted). Data portions of PKI Requests and Responses that are placed in the cmsSequence field can be encrypted separately.
PKI 要求/応答内の情報の開示が無許可のエンティティにアクセスされるのを防ぐために、PKI 要求または応答を暗号化する必要がある場合があります。このセクションでは、完全な PKI リクエストと応答を暗号化する方法について説明します (単純な PKI リクエストは暗号化できません)。cmsSequence フィールドに配置される PKI 要求と応答のデータ部分は、個別に暗号化できます。
Confidentiality is provided by wrapping the PKI Request/Response (a SignedData) in an EnvelopedData or an AuthEnvelopedData. When using EnvelopedData or AuthEnvelopedData, the nested content type is id-SignedData. Note that this is different from S/MIME where there is a MIME layer placed between the encrypted and signed data for EnvelopedData and between the authenticated encryption and signed data for AuthEnvelopedData. It is recommended that if an EnvelopedData or AuthEnvelopedData layer is applied to a PKI Request/ Response, a second signature layer be placed outside of the EnvelopedData or AuthEnvelopedData layer. The following figure shows how this nesting would be done:
機密性は、PKI 要求/応答 (SignedData) を EnvelopedData または AuthEnvelopedData でラップすることによって提供されます。EnvelopedData または AuthEnvelopedData を使用する場合、ネストされたコンテンツ タイプは id-SignedData です。これは、EnvelopedData の暗号化データと署名データの間に、および AuthEnvelopedData の認証された暗号化データと署名データの間に MIME 層が配置される S/MIME とは異なることに注意してください。EnvelopedData 層または AuthEnvelopedData 層が PKI 要求/応答に適用される場合、2 番目の署名層を EnvelopedData 層または AuthEnvelopedData 層の外側に配置することをお勧めします。次の図は、このネストがどのように行われるかを示しています。
Normal Option 1 Option 2
------ -------- --------
SignedData EnvelopedData SignedData
PKIData SignedData EnvelopedData
PKIData SignedData
PKIData
Note: PKIResponse can be substituted for PKIData in the above figure.
注: 上の図の PKIData は PKIResponse に置き換えることができます。
Note: AuthEnvelopedData can be substituted for EnvelopedData in the above figure.
注: 上の図の EnvelopedData は AuthEnvelopedData に置き換えることができます。
Options 1 and 2 prevent leakage of sensitive data by encrypting the Full PKI Request/Response. An RA that receives a PKI Request that it cannot decrypt MAY reject the PKI Request unless it can process the PKI Request without knowledge of the contents (i.e., all it does is amalgamate multiple PKI Requests and forward them to a server).
オプション 1 と 2 は、完全な PKI リクエスト/レスポンスを暗号化することで機密データの漏洩を防ぎます。復号化できない PKI リクエストを受信した RA は、内容を知らなくても PKI リクエストを処理できる場合を除き、PKI リクエストを拒否してもよい(MAY) (つまり、RA が行うのは複数の PKI リクエストを結合してサーバに転送することだけである)。
After the RA removes the envelope and completes processing, it may then apply a new EnvelopedData or AuthEnvelopedData layer to protect PKI Requests for transmission to the next processing agent. Section 8 contains more information about RA processing.
RA はエンベロープを削除して処理を完了した後、新しい EnvelopedData レイヤーまたは AuthEnvelopedData レイヤーを適用して、次の処理エージェントに送信する PKI リクエストを保護します。セクション 8 には、RA 処理に関する詳細情報が含まれています。
Full PKI Requests/Responses can be encrypted or transmitted in the clear. Servers that support EnvelopedData or AuthEnvelopedData MUST provide support for all three EnvelopedData or AuthEnvelopedData options, respectively.
完全な PKI リクエスト/レスポンスは暗号化することも、平文で送信することもできます。EnvelopedData または AuthEnvelopedData をサポートするサーバーは、それぞれ 3 つの EnvelopedData または AuthEnvelopedData オプションすべてをサポートしなければなりません。
Alternatively, an authenticated, secure channel could exist between the parties that require confidentiality. Clients and servers MAY use such channels instead of the technique described above to provide secure, private communication of Simple and Full PKI Requests/ Responses.
あるいは、機密性を必要とする当事者間に、認証された安全なチャネルが存在することもあります。クライアントとサーバーは、シンプルおよびフル PKI リクエスト/レスポンスの安全でプライベートな通信を提供するために、上記の手法の代わりにそのようなチャネルを使用してもよい(MAY)。
Controls are carried as part of both Full PKI Requests and Responses. Each control is encoded as a unique OID followed by the data for the control (see syntax in Section 3.2.1.1). The encoding of the data is based on the control. Processing systems would first detect the OID (TaggedAttribute attrType) and process the corresponding control value (TaggedAttribute attrValues) prior to processing the message body.
コントロールは、完全な PKI 要求と応答の両方の一部として伝送されます。各コントロールは、コントロールのデータが後に続く一意の OID としてエンコードされます (セクション 3.2.1.1 の構文を参照)。データのエンコードはコントロールに基づいています。処理システムは、メッセージ本文を処理する前に、まず OID (TaggedAttribute attrType) を検出し、対応する制御値 (TaggedAttribute attrValues) を処理します。
The OIDs are all defined under the following arc:
OID はすべて、次のアークの下で定義されます。
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-cmc OBJECT IDENTIFIER ::= { id-pkix 7 }
The following table lists the names, OID, and syntactic structure for each of the controls described in this document.
次の表に、このドキュメントで説明されている各コントロールの名前、OID、および構文構造を示します。
+============================+========+=====================+=======+
|Identifier Description | OID |ASN.1 Structure |Section|
+============================+========+=====================+=======+
|id-cmc-statusInfo | id-cmc |CMCStatusInfo |Section|
| | 1 | |6.1.2 |
+----------------------------+--------+---------------------+-------+
|id-cmc-identification | id-cmc |UTF8String |Section|
| | 2 | |6.2.3 |
+----------------------------+--------+---------------------+-------+
|id-cmc-identityProof | id-cmc |OCTET STRING |Section|
| | 3 | |6.2.2 |
+----------------------------+--------+---------------------+-------+
|id-cmc-dataReturn | id-cmc |OCTET STRING |Section|
| | 4 | |6.4 |
+----------------------------+--------+---------------------+-------+
|id-cmc-transactionId | id-cmc |INTEGER |Section|
| | 5 | |6.6 |
+----------------------------+--------+---------------------+-------+
|id-cmc-senderNonce | id-cmc |OCTET STRING |Section|
| | 6 | |6.6 |
+----------------------------+--------+---------------------+-------+
|id-cmc-recipientNonce | id-cmc |OCTET STRING |Section|
| | 7 | |6.6 |
+----------------------------+--------+---------------------+-------+
|id-cmc-addExtensions | id-cmc |AddExtensions |Section|
| | 8 | |6.5.2 |
+----------------------------+--------+---------------------+-------+
|id-cmc-encryptedPOP | id-cmc |EncryptedPOP |Section|
| | 9 | |6.7 |
+----------------------------+--------+---------------------+-------+
|id-cmc-decryptedPOP | id-cmc |DecryptedPOP |Section|
| | 10 | |6.7 |
+----------------------------+--------+---------------------+-------+
|id-cmc-lraPOPWitness | id-cmc |LraPopWitness |Section|
| | 11 | |6.8 |
+----------------------------+--------+---------------------+-------+
|id-cmc-getCert | id-cmc |GetCert |Section|
| | 15 | |6.9 |
+----------------------------+--------+---------------------+-------+
|id-cmc-getCRL | id-cmc |GetCRL |Section|
| | 16 | |6.10 |
+----------------------------+--------+---------------------+-------+
|id-cmc-revokeRequest | id-cmc |RevokeRequest |Section|
| | 17 | |6.11 |
+----------------------------+--------+---------------------+-------+
|id-cmc-regInfo | id-cmc |OCTET STRING |Section|
| | 18 | |6.12 |
+----------------------------+--------+---------------------+-------+
|id-cmc-responseInfo | id-cmc |OCTET STRING |Section|
| | 19 | |6.12 |
+----------------------------+--------+---------------------+-------+
|id-cmc-queryPending | id-cmc |OCTET STRING |Section|
| | 21 | |6.13 |
+----------------------------+--------+---------------------+-------+
|id-cmc-popLinkRandom | id-cmc |OCTET STRING |Section|
| | 22 | |6.3.1.3|
+----------------------------+--------+---------------------+-------+
|id-cmc-popLinkWitness | id-cmc |OCTET STRING |Section|
| | 23 | |6.3.1.2|
+----------------------------+--------+---------------------+-------+
|id-cmc-confirmCertAcceptance| id-cmc |IssuerAndSerialNumber|Section|
| | 24 | |6.14 |
+----------------------------+--------+---------------------+-------+
|id-cmc-statusInfoV2 | id-cmc |CMCStatusInfoV2 |Section|
| | 25 | |6.1.1 |
+----------------------------+--------+---------------------+-------+
|id-cmc-trustedAnchors | id-cmc |PublishTrustAnchors |Section|
| | 26 | |6.15 |
+----------------------------+--------+---------------------+-------+
|id-cmc-authData | id-cmc |BodyPartID |Section|
| | 27 | |6.16 |
+----------------------------+--------+---------------------+-------+
|id-cmc-batchRequests | id-cmc |BodyPartList |Section|
| | 28 | |6.17 |
+----------------------------+--------+---------------------+-------+
|id-cmc-batchResponses | id-cmc |BodyPartList |Section|
| | 29 | |6.17 |
+----------------------------+--------+---------------------+-------+
|id-cmc-publishCert | id-cmc |CMCPublicationInfo |Section|
| | 30 | |6.18 |
+----------------------------+--------+---------------------+-------+
|id-cmc-modCertTemplate | id-cmc |ModCertTemplate |Section|
| | 31 | |6.5.1 |
+----------------------------+--------+---------------------+-------+
|id-cmc-controlProcessed | id-cmc |ControlList |Section|
| | 32 | |6.19 |
+----------------------------+--------+---------------------+-------+
|id-cmc-popLinkWitnessV2 | id-cmc |PopLinkWitnessV2 |Section|
| | 33 | |6.3.1.1|
+----------------------------+--------+---------------------+-------+
|id-cmc-identityProofV2 | id-cmc |IdentityProofV2 |Section|
| | 34 | |6.2.1 |
+----------------------------+--------+---------------------+-------+
|id-cmc-raIdentityWitness | id-cmc |BodyPartPath |Section|
| | 35 | |6.20 |
+----------------------------+--------+---------------------+-------+
|id-cmc-responseBody | id-cmc |BodyPartPath |Section|
| | 37 | |6.21 |
+----------------------------+--------+---------------------+-------+
Table 1: CMC Control Attributes
表 1: CMC 制御属性
The CMC Status Info controls return information about the status of a client/server request/response. Two controls are described in this section. The Extended CMC Status Info control is the preferred control; the CMC Status Info control is included for backward compatibility with [RFC2797].
CMC ステータス情報コントロールは、クライアント/サーバーの要求/応答のステータスに関する情報を返します。このセクションでは 2 つのコントロールについて説明します。拡張 CMC ステータス情報コントロールが推奨されるコントロールです。CMC ステータス情報コントロールは、[RFC2797] との下位互換性のために組み込まれています。
Servers MAY emit multiple CMC Status Info controls referring to a single body part. Clients MUST be able to deal with multiple CMC Status Info controls in a PKI Response. Servers MUST use the Extended CMC Status Info control, but they MAY additionally use the CMC Status Info control. Clients MUST be able to process the Extended CMC Status Info control.
サーバーは、単一の身体部分を参照する複数の CMC ステータス情報コントロールを発行してもよい(MAY)。クライアントは、PKI 応答で複数の CMC ステータス情報コントロールを処理できなければなりません。サーバーは拡張 CMC ステータス情報コントロールを使用しなければなりません (MUST) が、追加で CMC ステータス情報コントロールを使用してもよいです。クライアントは、拡張 CMC ステータス情報コントロールを処理できなければなりません。
The Extended CMC Status Info control is identified by the OID:
拡張 CMC ステータス情報コントロールは、OID によって識別されます。
id-cmc-statusInfoV2 OBJECT IDENTIFIER ::= { id-cmc 25 }
The Extended CMC Status Info control has the ASN.1 definition:
拡張 CMC ステータス情報コントロールには、ASN.1 定義があります。
CMCStatusInfoV2 ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF
BodyPartReference,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo,
extendedFailInfo [1] SEQUENCE {
failInfoOID TYPE-IDENTIFIER.&id
({ExtendedFailures}),
failInfoValue TYPE-IDENTIFIER.&Type
({ExtendedFailures}
{@.failInfoOID})
}
} OPTIONAL
}
PendInfo ::= SEQUENCE {
pendToken OCTET STRING,
pendTime GeneralizedTime
}
BodyPartReference ::= CHOICE {
bodyPartID BodyPartID,
bodyPartPath BodyPartPath
}
The fields in CMCStatusInfoV2 have the following meanings:
CMCStatusInfoV2 のフィールドは次の意味を持ちます。
* cMCStatus contains the returned status value. Details are in Section 6.1.3.
* cMCStatus には、返されたステータス値が含まれます。詳細はセクション 6.1.3 に記載されています。
* bodyList identifies the controls or other elements to which the status value applies. If an error is returned for a Simple PKI Request, this field is the bodyPartID choice of BodyPartReference with the single integer of value 1.
* bodyList は、ステータス値が適用されるコントロールまたはその他の要素を識別します。Simple PKI リクエストに対してエラーが返された場合、このフィールドは、値 1 の単一の整数を持つ BodyPartReference の bodyPartID 選択になります。
* statusString contains additional description information. This string is human readable.
* statusString には追加の説明情報が含まれています。この文字列は人間が判読可能です。
* otherInfo contains additional information that expands on the CMC status code returned in the cMCStatus field.
* otherInfo には、cMCStatus フィールドに返される CMC ステータス コードを拡張する追加情報が含まれています。
The fields in otherStatusInfo have the following meanings:
otherStatusInfo のフィールドには次の意味があります。
* failInfo is described in Section 6.1.4. It provides an error code that details what failure occurred. This choice is present only if cMCStatus contains the value failed.
* failedInfo についてはセクション 6.1.4 で説明されています。発生したエラーの詳細を示すエラー コードが表示されます。この選択肢は、cMCStatus に値 failed が含まれている場合にのみ存在します。
* pendInfo contains information about when and how the client should request the result of this request. It is present when the cMCStatus is either pending or partial. pendInfo uses the structure PendInfo, which has the fields:
* pendInfo には、クライアントがこのリクエストの結果をいつどのようにリクエストする必要があるかに関する情報が含まれています。これは、cMCStatus が保留中または部分的な場合に存在します。pendInfo は、次のフィールドを持つ構造体 PendInfo を使用します。
- pendToken is the token used in the Query Pending control (Section 6.13).
- pendToken は、クエリ保留コントロール (セクション 6.13) で使用されるトークンです。
- pendTime contains the suggested time the server wants to be queried about the status of the certification request.
- pendTime には、サーバーが認証要求のステータスについてクエリされることを希望する推奨時間が含まれます。
* extendedFailInfo includes application-dependent detailed error information. This choice is present only if cMCStatus contains the value failed. Caution should be used when defining new values as they may not be correctly recognized by all clients and servers. The CMCFailInfo value of internalCAError may be assumed if the extended error is not recognized. This field uses the type ExtendedFailInfo. ExtendedFailInfo has the fields:
* extendFailInfo には、アプリケーションに依存する詳細なエラー情報が含まれます。この選択肢は、cMCStatus に値 failed が含まれている場合にのみ存在します。新しい値を定義する場合は、すべてのクライアントおよびサーバーで正しく認識されるわけではない可能性があるため、注意が必要です。拡張エラーが認識されない場合は、internalCAError の CMCFailInfo 値が想定される場合があります。このフィールドは ExtendedFailInfo タイプを使用します。ExtendedFailInfo には次のフィールドがあります。
- failInfoOID contains an OID that is associated with a set of extended error values.
- failedInfoOID には、拡張エラー値のセットに関連付けられた OID が含まれています。
- failInfoValue contains an extended error code from the defined set of extended error codes.
- failedInfoValue には、定義された拡張エラー コードのセットからの拡張エラー コードが含まれます。
If the cMCStatus field is success, the Extended CMC Status Info control MAY be omitted unless it is the only item in the response.
cMCStatus フィールドが成功の場合、拡張 CMC ステータス情報コントロールは、応答内の唯一の項目でない限り、省略してもよい(MAY)。
The CMC Status Info control is identified by the OID:
CMC ステータス情報コントロールは、OID によって識別されます。
id-cmc-statusInfo OBJECT IDENTIFIER ::= { id-cmc 1 }
The CMC Status Info control has the ASN.1 definition:
CMC ステータス情報コントロールには、ASN.1 定義があります。
CMCStatusInfo ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList BodyPartList,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo } OPTIONAL
}
The fields in CMCStatusInfo have the following meanings:
CMCStatusInfo のフィールドには次の意味があります。
* cMCStatus contains the returned status value. Details are in Section 6.1.3.
* cMCStatus には、返されたステータス値が含まれます。詳細はセクション 6.1.3 に記載されています。
* bodyList contains the list of controls or other elements to which the status value applies. If an error is being returned for a Simple PKI Request, this field contains a single integer of value 1.
* bodyList には、ステータス値が適用されるコントロールまたはその他の要素のリストが含まれます。Simple PKI リクエストに対してエラーが返された場合、このフィールドには値 1 の単一の整数が含まれます。
* statusString contains additional description information. This string is human readable.
* statusString には追加の説明情報が含まれています。この文字列は人間が判読可能です。
* otherInfo provides additional information that expands on the CMC status code returned in the cMCStatus field.
* otherInfo は、cMCStatus フィールドに返される CMC ステータス コードを拡張した追加情報を提供します。
- failInfo is described in Section 6.1.4. It provides an error code that details what failure occurred. This choice is present only if cMCStatus is failed.
- failedInfo についてはセクション 6.1.4 で説明されています。発生したエラーの詳細を示すエラー コードが表示されます。この選択肢は、cMCStatus が失敗した場合にのみ存在します。
- pendInfo uses the PendInfo ASN.1 structure in Section 6.1.1. It contains information about when and how the client should request results of this request. The pendInfo field MUST be populated for a cMCStatus value of pending or partial. Further details can be found in Sections 6.1.1 and 6.13.
- pendInfo は、セクション 6.1.1 の PendInfo ASN.1 構造を使用します。これには、クライアントがこのリクエストの結果をいつどのようにリクエストする必要があるかに関する情報が含まれています。pendInfo フィールドには、保留中または部分的な cMCStatus 値を設定する必要があります。詳細については、セクション 6.1.1 および 6.13 を参照してください。
If the cMCStatus field is success, the CMC Status Info control MAY be omitted unless it is the only item in the response. If no status exists for a Simple or Full PKI Request, then the value of success is assumed.
cMCStatus フィールドが成功の場合、応答内の唯一の項目でない限り、CMC ステータス情報コントロールは省略されてもよい(MAY)。シンプルまたはフル PKI リクエストのステータスが存在しない場合は、成功の値が想定されます。
CMCStatus is a field in the Extended CMC Status Info and CMC Status Info controls. This field contains a code representing the success or failure of a specific operation. CMCStatus has the ASN.1 structure:
CMCStatus は、拡張 CMC ステータス情報および CMC ステータス情報コントロールのフィールドです。このフィールドには、特定の操作の成功または失敗を表すコードが含まれます。CMCStatus には ASN.1 構造があります。
CMCStatus ::= INTEGER {
success (0),
-- reserved (1),
failed (2),
pending (3),
noSupport (4),
confirmRequired (5),
popRequired (6),
partial (7)
}
The values of CMCStatus have the following meanings:
CMCStatus の値には次の意味があります。
* success indicates the request was granted or the action was completed.
* success は、リクエストが許可されたか、アクションが完了したことを示します。
* failed indicates the request was not granted or the action was not completed. More information is included elsewhere in the response.
* failed は、リクエストが許可されなかったか、アクションが完了しなかったことを示します。詳細については、応答の他の場所に記載されています。
* pending indicates the PKI Request has yet to be processed. The requester is responsible to poll back on this Full PKI Request. pending may only be returned for certification request operations.
* pending は、PKI 要求がまだ処理されていないことを示します。要求者は、この完全な PKI 要求をポーリングバックする責任があります。pending は、証明書要求操作の場合にのみ返される場合があります。
* noSupport indicates the requested operation is not supported.
* noSupport は、要求された操作がサポートされていないことを示します。
* confirmRequired indicates a Confirm Certificate Acceptance control (Section 6.14) must be returned before the certificate can be used.
* confirmRequired は、証明書を使用する前に、証明書の受け入れの確認コントロール (セクション 6.14) を返す必要があることを示します。
* popRequired indicates a direct POP operation is required (Section 6.3.1.3).
* popRequired は、直接 POP 操作が必要であることを示します (セクション 6.3.1.3)。
* partial indicates a partial PKI Response is returned. The requester is responsible to poll back for the unfulfilled portions of the Full PKI Request.
* 部分的は、部分的な PKI 応答が返されることを示します。要求者は、完全な PKI 要求の満たされていない部分をポーリングバックする責任があります。
CMCFailInfo is a field in the Extended CMC Status Info and CMC Status Info controls. CMCFailInfo conveys more detailed information relevant to the interpretation of a failure condition. The CMCFailInfo has the following ASN.1 structure:
CMCFailInfo は、拡張 CMC ステータス情報および CMC ステータス情報コントロールのフィールドです。CMCFailInfo は、障害状態の解釈に関連するより詳細な情報を伝えます。CMCFailInfo には次の ASN.1 構造があります。
CMCFailInfo ::= INTEGER {
badAlg (0),
badMessageCheck (1),
badRequest (2),
badTime (3),
badCertId (4),
unsupportedExt (5),
mustArchiveKeys (6),
badIdentity (7),
popRequired (8),
popFailed (9),
noKeyReuse (10),
internalCAError (11),
tryLater (12),
authDataFail (13)
}
The values of CMCFailInfo have the following meanings:
CMCFailInfo の値には次の意味があります。
* badAlg indicates unrecognized or unsupported algorithm.
* badAlg は、認識されないアルゴリズムまたはサポートされていないアルゴリズムを示します。
* badMessageCheck indicates integrity check failed.
* badMessageCheck は、整合性チェックが失敗したことを示します。
* badRequest indicates transaction was not permitted or supported.
* badRequest は、トランザクションが許可されなかった、またはサポートされていなかったことを示します。
* badTime indicates message time field was not sufficiently close to the system time.
* badTime は、メッセージ時刻フィールドがシステム時刻に十分近くなかったことを示します。
* badCertId indicates no certificate could be identified matching the provided criteria.
* badCertId は、指定された基準に一致する証明書を識別できなかったことを示します。
* unsupportedExt indicates a requested X.509 extension is not supported by the recipient CA.
* unsupportedExt は、要求された X.509 拡張機能が受信側 CA によってサポートされていないことを示します。
* mustArchiveKeys indicates private key material must be supplied.
* mustArchiveKeys は、秘密キー素材を提供する必要があることを示します。
* badIdentity indicates identification control failed to verify.
* badIdentity は、識別制御が検証できなかったことを示します。
* popRequired indicates server requires a POP before issuing certificate.
* popRequired は、サーバーが証明書を発行する前に POP を必要とすることを示します。
* popFailed indicates POP processing failed.
* popFailed は、POP 処理が失敗したことを示します。
* noKeyReuse indicates server policy does not allow key reuse.
* noKeyReuse は、サーバー ポリシーがキーの再利用を許可していないことを示します。
* internalCAError indicates that the CA had an unknown internal failure.
* internalCAError は、CA に不明な内部障害が発生したことを示します。
* tryLater indicates that the server is not accepting requests at this time and the client should try at a later time.
* tryLater は、サーバーが現時点ではリクエストを受け付けていないため、クライアントが後でリクエストを試みる必要があることを示します。
* authDataFail indicates failure occurred during processing of authenticated data.
* authDataFail は、認証データの処理中にエラーが発生したことを示します。
If additional failure reasons are needed, they SHOULD use the ExtendedFailureInfo item in the Extended CMC Status Info control. However, for closed environments, they can be defined using this type. Such codes MUST be in the range from 1000 to 1999.
追加の失敗理由が必要な場合は、Extended CMC Status Info コントロールの ExtendedFailureInfo 項目を使用する必要があります (SHOULD)。ただし、閉じた環境の場合は、このタイプを使用して定義できます。このようなコードは 1000 から 1999 の範囲内でなければなりません。
Some CAs and RAs require that a Proof-of-Identity be included in a certification request. Many different ways of doing this exist with different degrees of security and reliability. Most are familiar with a bank's request to provide your mother's maiden name as a form of Proof-of-Identity. The reasoning behind requiring a Proof-of-Identity can be found in Appendix C of [CRMF].
一部の CA および RA では、証明書リクエストに ID 証明を含めることを要求しています。これを行うには、さまざまなレベルのセキュリティと信頼性を備えたさまざまな方法が存在します。ほとんどの人は、銀行が身分証明書として母親の旧姓を提出するよう要求したことをよく知っています。身元証明を要求する背後にある理由は、[CRMF] の付録 C に記載されています。
CMC provides a method to prove the client's identity based on a client/server shared-secret. If clients support the Full PKI Request, clients MUST implement this method of Proof-of-Identity (Section 6.2.1). Servers MUST provide this method, but they MAY additionally support bilateral methods of similar strength.
CMC は、クライアント/サーバーの共有秘密に基づいてクライアントの ID を証明する方法を提供します。クライアントがフル PKI リクエストをサポートする場合、クライアントはこの ID 証明方法 (セクション 6.2.1) を実装しなければなりません (MUST)。サーバーはこのメソッドを提供しなければなりません (MUST) が、同様の強度の双方向メソッドを追加でサポートしてもよいです。
This document also provides an Identification control (Section 6.2.3). This control is a simple method to allow a client to state who they are to the server. Generally, a shared-secret AND an identifier of that shared-secret are passed from the server to the client. The identifier is placed in the Identification control, and the shared-secret is used to compute the Identity Proof or Identity Proof v2 control.
この文書では、識別制御 (セクション 6.2.3) も提供します。このコントロールは、クライアントが自分が誰であるかをサーバーに伝えるための簡単な方法です。一般に、共有秘密とその共有秘密の識別子がサーバーからクライアントに渡されます。識別子は ID コントロールに配置され、共有秘密は Identity Proof または Identity Proof v2 コントロールを計算するために使用されます。
The Identity Proof Version 2 control is identified by the OID:
Identity Proof バージョン 2 コントロールは、OID によって識別されます。
id-cmc-identityProofV2 OBJECT IDENTIFIER ::= { id-cmc 34 }
The Identity Proof Version 2 control has the ASN.1 definition:
Identity Proof バージョン 2 コントロールには、ASN.1 定義があります。
IdentityProofV2 ::= SEQUENCE {
proofAlgID AlgorithmIdentifier{DIGEST-ALGORITHM,
{WitnessAlgs}},
macAlgID AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}},
witness OCTET STRING
}
The fields of IdentityProofV2 have the following meanings:
IdentityProofV2 のフィールドは次の意味を持ちます。
* proofAlgID is the identifier and parameters for the hash algorithm used to convert the shared-secret into a key for the MAC algorithm.
* proofAlgID は、共有秘密を MAC アルゴリズムのキーに変換するために使用されるハッシュ アルゴリズムの識別子とパラメーターです。
* macAlgID is the identifier and the parameters for the message authentication code algorithm used to compute the value of the witness field.
* macAlgID は、証人フィールドの値を計算するために使用されるメッセージ認証コード アルゴリズムの識別子とパラメーターです。
* witness is the Proof-of-Identity.
* 証人は身分証明書です。
The required method starts with an out-of-band transfer of a token (the shared-secret). The shared-secret should be generated in a random manner. The distribution of this token is beyond the scope of this document. Then, the client provides Proof-of-Identity with this token as follows:
必要なメソッドは、トークン (共有秘密) の帯域外転送から始まります。共有秘密はランダムな方法で生成される必要があります。このトークンの配布については、このドキュメントの範囲を超えています。次に、クライアントは次のようにこのトークンを使用して ID 証明を提供します。
1. The PKIData reqSequence field (encoded exactly as it appears in the Full PKI Request including the sequence type and length) is the value to be validated.
1. PKIData reqSequence フィールド (シーケンス タイプと長さを含む完全な PKI リクエストに表示されるとおりに正確にエンコードされた) が検証される値です。
2. A hash of the shared-secret as a UTF-8 string is computed using proofAlgID.
2. UTF-8 文字列としての共有秘密のハッシュは、proofAlgID を使用して計算されます。
3. A MAC is then computed using the value produced in Step 1 as the message and the value from Step 2 as the key.
3. 次に、ステップ 1 で生成された値をメッセージとして、ステップ 2 の値をキーとして使用して、MAC が計算されます。
4. The result from Step 3 is then encoded as the witness value in the Identity Proof Version 2 control.
4. ステップ 3 の結果は、Identity Proof Version 2 コントロールの証人値としてエンコードされます。
When the server verifies the Identity Proof Version 2 control, it computes the MAC value in the same way and compares it to the witness value contained in the PKI Request.
サーバーは、Identity Proof Version 2 コントロールを検証するときに、同じ方法で MAC 値を計算し、それを PKI 要求に含まれる監視値と比較します。
If a server fails the verification of an Identity Proof Version 2 control, the CMCFailInfo value MUST be present in the Full PKI Response and MUST have a value of badIdentity.
サーバーが ID 証明バージョン 2 コントロールの検証に失敗した場合、CMCFailInfo 値が完全な PKI 応答に存在しなければならず、値 badIdentity がなければなりません。
Reuse of the shared-secret on certification request retries allows the client and server to maintain the same view of acceptable Proof-of-Identity values. However, reuse of the shared-secret can potentially open the door for some types of attacks.
認証要求の再試行時に共有秘密を再利用すると、クライアントとサーバーは許容可能な ID 証明値の同じビューを維持できます。ただし、共有秘密を再利用すると、一部の種類の攻撃の扉が開く可能性があります。
Implementations MUST be able to support tokens that are at least 16 characters long. Guidance on the amount of entropy actually obtained from a given length token based on character sets can be found in Appendix A of [PASSWORD].
実装では、少なくとも 16 文字の長さのトークンをサポートできなければなりません。文字セットに基づいて特定の長さのトークンから実際に取得されるエントロピーの量に関するガイダンスは、[PASSWORD] の付録 A にあります。
The Identity Proof control is identified by the OID:
Identity Proof コントロールは OID によって識別されます。
id-cmc-identityProof OBJECT IDENTIFIER ::= { id-cmc 3 }
The Identity Proof control has the ASN.1 definition:
Identity Proof コントロールには ASN.1 定義があります。
IdentityProof ::= OCTET STRING
This control is processed in the same way as the Identity Proof Version 2 control. In this case, the hash algorithm is fixed to SHA-1 and the MAC algorithm is fixed to HMAC-SHA1.
このコントロールは、Identity Proof バージョン 2 コントロールと同じ方法で処理されます。この場合、ハッシュ アルゴリズムは SHA-1 に固定され、MAC アルゴリズムは HMAC-SHA1 に固定されます。
Optionally, servers MAY require the inclusion of the unprotected Identification control with an Identification Proof control. The Identification control is intended to contain a text string that assists the server in locating the shared-secret needed to validate the contents of the Identity Proof control. If the Identification control is included in the Full PKI Request, the derivation of the key in Step 2 (from Section 6.2.1) is altered so that the hash of the concatenation of the shared-secret and the UTF-8 identity value (without the type and length bytes) are hashed rather than just the shared-secret.
オプションで、サーバーは、保護されていない ID コントロールを Identification Proof コントロールとともに含めることを要求してもよい (MAY)。Identification コントロールには、サーバーが Identity Proof コントロールの内容を検証するために必要な共有秘密を見つけるのに役立つテキスト文字列が含まれることを目的としています。識別制御がフル PKI リクエストに含まれている場合、ステップ 2 (セクション 6.2.1 から) のキーの導出は、共有シークレットだけではなく、共有シークレットと UTF-8 ID 値 (タイプと長さのバイトなし) を連結したハッシュがハッシュされるように変更されます。
The Identification control is identified by the OID:
識別コントロールは OID によって識別されます。
id-cmc-identification OBJECT IDENTIFIER ::= { id-cmc 2 }
The Identification control has the ASN.1 definition:
識別コントロールには ASN.1 定義があります。
Identification ::= UTF8String
The shared-secret between the EE and the server is sometimes computed using a hardware device that generates a series of tokens. The EE can therefore prove its identity by transferring this token in plain text along with a name string. The above protocol can be used with a hardware shared-secret token generation device by the following modifications:
EE とサーバー間の共有秘密は、一連のトークンを生成するハードウェア デバイスを使用して計算される場合があります。したがって、EE は、このトークンを名前文字列とともにプレーン テキストで転送することで、その身元を証明できます。上記のプロトコルは、次の変更を行うことで、ハードウェア共有秘密トークン生成デバイスで使用できます。
1. The Identification control MUST be included and MUST contain the hardware-generated token.
1. 識別コントロールを含める必要があり、ハードウェアで生成されたトークンを含める必要があります。
2. The shared-secret value used above is the same hardware-generated token.
2. 上記で使用されている共有秘密の値は、同じハードウェア生成トークンです。
3. All certification requests MUST have a subject name, and the subject name MUST contain the fields required to identify the holder of the hardware token device.
3. すべての認証リクエストにはサブジェクト名がなければならず、サブジェクト名にはハードウェア トークン デバイスの所有者を識別するために必要なフィールドが含まれなければなりません。
4. The entire certification request MUST be shrouded in some fashion to prevent eavesdropping. Although the token is time critical, an active eavesdropper cannot be permitted to extract the token and submit a different certification request with the same token value.
4. 盗聴を防ぐために、認証リクエスト全体を何らかの方法で覆い隠す必要があります。トークンは時間が重要ですが、アクティブな盗聴者がトークンを抽出して、同じトークン値を持つ別の認証要求を送信することは許可されません。
In a CMC Full PKI Request, Proof-of-Identity information about the client is carried in the certificate associated with the signature of the SignedData containing the certification requests, one of the two Identity Proof controls, or the MAC computed for the AuthenticatedData containing the certification requests. POP information for key pairs, however, is carried separately for each PKCS #10 or CRMF. (For keys capable of generating a digital signature, the POP is provided by the signature on the PKCS #10 or CRMF. For encryption-only keys, the controls described in Section 6.7 are used.) In order to prevent substitution-style attacks, the protocol must guarantee that the same entity supplied both the POP and Proof-of-Identity information.
CMC フル PKI リクエストでは、クライアントに関する ID 証明情報は、認証リクエストを含む SignedData の署名、2 つの ID 証明コントロールの 1 つ、または認証リクエストを含む AuthenticatedData に対して計算された MAC の署名に関連付けられた証明書に含まれます。ただし、キー ペアの POP 情報は、PKCS #10 または CRMF ごとに個別に伝送されます。(デジタル署名を生成できる鍵の場合、POP は PKCS #10 または CRMF 上の署名によって提供されます。暗号化専用鍵の場合、セクション 6.7 で説明されている制御が使用されます。) 置換スタイルの攻撃を防ぐために、プロトコルは、同じエンティティが POP と ID 証明情報の両方を提供したことを保証する必要があります。
We describe three mechanisms for linking identity and POP information: witness values cryptographically derived from a shared-secret (Section 6.3.1), shared-secret/subject name matching (Section 6.3.2), and subject name matching to an existing certificate (Section 6.3.3). Clients and servers MUST support the witness value and the certificate-linking techniques. Clients and servers MAY support shared-secret/name matching or MAY support other bilateral techniques of similar strength. The idea behind the first two mechanisms is to force the client to sign some data into each certification request that can be directly associated with the shared-secret; this will defeat attempts to include certification requests from different entities in a single Full PKI Request.
ID と POP 情報をリンクするための 3 つのメカニズムについて説明します。共有秘密から暗号的に導出された証人値 (セクション 6.3.1)、共有秘密とサブジェクト名の照合 (セクション 6.3.2)、および既存の証明書とのサブジェクト名の照合 (セクション 6.3.3) です。クライアントとサーバーは、証人値と証明書リンク技術をサポートしなければなりません。クライアントとサーバーは、共有秘密/名前のマッチングをサポートしてもよいし、同様の強度の他の双方向技術をサポートしてもよい(MAY)。最初の 2 つのメカニズムの背後にある考え方は、共有秘密に直接関連付けることができるデータを各証明書リクエストに署名させることをクライアントに強制することです。これにより、さまざまなエンティティからの認証要求を 1 つの完全な PKI 要求に含める試みが無効になります。
The first technique that links identity and POP information forces the client to include a piece of information cryptographically derived from the shared-secret as a signed extension within each certification request (PKCS #10 or CRMF).
ID 情報と POP 情報をリンクする最初の手法では、クライアントは、共有秘密から暗号的に導出された情報を、各認証要求 (PKCS #10 または CRMF) 内の署名付き拡張子として含めることを強制されます。
The POP Link Witness Version 2 control is identified by the OID:
POP Link Witness バージョン 2 コントロールは、OID によって識別されます。
id-cmc-popLinkWitnessV2 OBJECT IDENTIFIER ::= { id-cmc 33 }
The POP Link Witness Version 2 control has the ASN.1 definition:
POP Link Witness バージョン 2 コントロールには、ASN.1 定義があります。
PopLinkWitnessV2 ::= SEQUENCE {
keyGenAlgorithm AlgorithmIdentifier{KEY-DERIVATION,
{KeyDevAlgs}},
macAlgorithm AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}},
witness OCTET STRING
}
The fields of PopLinkWitnessV2 have the following meanings:
PopLinkWitnessV2 のフィールドは次の意味を持ちます。
* keyGenAlgorithm contains the algorithm used to generate the key for the MAC algorithm. This will generally be a hash algorithm, but it could be a more complex algorithm.
* keyGenAlgorithm には、MAC アルゴリズムのキーを生成するために使用されるアルゴリズムが含まれています。これは通常、ハッシュ アルゴリズムですが、より複雑なアルゴリズムになる可能性があります。
* macAlgorithm contains the algorithm used to create the witness value.
* macAlgorithm には、証人値の作成に使用されるアルゴリズムが含まれています。
* witness contains the computed witness value.
* 証人には、計算された証人値が含まれます。
This technique is useful if NULL subject Distinguished Names (DNs) are used (because, for example, the server can generate the subject DN for the certificate based only on the shared-secret). Processing begins when the client receives the shared-secret out-of-band from the server. The client then computes the following values:
この手法は、NULL のサブジェクト識別名 (DN) が使用されている場合に役立ちます (たとえば、サーバーは共有秘密のみに基づいて証明書のサブジェクト DN を生成できるため)。処理は、クライアントがサーバーから共有秘密を帯域外で受信すると開始されます。次に、クライアントは次の値を計算します。
1. The client generates a random byte-string, R, which SHOULD be at least 512 bits in length.
1. クライアントはランダムなバイト文字列 R を生成します。この文字列の長さは少なくとも 512 ビットである必要があります (SHOULD)。
2. The key is computed from the shared-secret using the algorithm in keyGenAlgorithm.
2. キーは、keyGenAlgorithm のアルゴリズムを使用して共有秘密から計算されます。
3. A MAC is then computed over the random value produced in Step 1, using the key computed in Step 2.
3. 次に、ステップ 2 で計算されたキーを使用して、ステップ 1 で生成されたランダム値に対して MAC が計算されます。
4. The random value produced in Step 1 is encoded as the value of a POP Link Random control. This control MUST be included in the Full PKI Request.
4. ステップ 1 で生成されたランダム値は、POP Link Random コントロールの値としてエンコードされます。このコントロールは完全な PKI リクエストに含める必要があります。
5. The MAC value produced in Step 3 is placed in either the POP Link Witness control or the witness field of the POP Link Witness V2 control.
5. ステップ 3 で生成された MAC 値は、POP Link Witness コントロールまたは POP Link Witness V2 コントロールの Witness フィールドのいずれかに配置されます。
* For CRMF, the POP Link Witness / POP Link Witness V2 control is included in the controls field of the CertRequest structure.
* CRMF の場合、POP Link Witness / POP Link Witness V2 コントロールは、CertRequest 構造体のコントロール フィールドに含まれます。
* For PKCS #10, the POP Link Witness / POP Link Witness V2 control is included in the attributes field of the CertificationRequestInfo structure.
* PKCS #10 の場合、POP Link Witness / POP Link Witness V2 コントロールは CertificationRequestInfo 構造体の属性フィールドに含まれます。
Upon receipt, servers MUST verify that each certification request contains a copy of the POP Link Witness / POP Link Witness V2 control and that its value was derived using the above method from the shared-secret and the random string included in the POP Link Random control.
受信時に、サーバーは各認証リクエストに POP Link Witness / POP Link Witness V2 コントロールのコピーが含まれていること、およびその値が共有秘密と POP Link Random コントロールに含まれるランダム文字列から上記の方法を使用して導出されたことを検証しなければなりません。
The Identification control (Section 6.2.3) or the subject DN of a certification request can be used to help identify which shared-secret was used.
識別コントロール (セクション 6.2.3) または証明書リクエストのサブジェクト DN を使用すると、どの共有秘密が使用されたかを特定するのに役立ちます。
The POP Link Witness control is identified by the OID:
POP Link Witness コントロールは OID によって識別されます。
id-cmc-popLinkWitness OBJECT IDENTIFIER ::= { id-cmc 23 }
The POP Link Witness control has the ASN.1 definition:
POP Link Witness コントロールには ASN.1 定義があります。
PopLinkWitness ::= OCTET STRING
For this control, SHA-1 is used as the key generation algorithm. HMAC-SHA1 is used as the MAC algorithm.
この制御では、鍵生成アルゴリズムとして SHA-1 が使用されます。MACアルゴリズムにはHMAC-SHA1が使用されます。
The POP Link Random control is identified by the OID:
POP Link Random コントロールは OID によって識別されます。
id-cmc-popLinkRandom OBJECT IDENTIFIER ::= { id-cmc 22 }
The POP Link Random control has the ASN.1 definition:
POP Link Random コントロールには ASN.1 定義があります。
PopLinkRandom ::= OCTET STRING
The second technique to link identity and POP information is to link a particular subject DN to the shared-secrets that are distributed out-of-band and to require that clients using the shared-secret to prove identity include that exact subject DN in every certification request. It is expected that many client-server connections that use shared-secret-based Proof-of-Identity will use this mechanism.
ID と POP 情報をリンクする 2 番目の手法は、特定のサブジェクト DN を帯域外で配布される共有シークレットにリンクし、共有シークレットを使用して ID を証明するクライアントに、すべての認証要求にその正確なサブジェクト DN を含めるよう要求することです。共有秘密ベースの ID 証明を使用する多くのクライアント/サーバー接続でこのメカニズムが使用されることが予想されます。
Note: It is common to include the subject DN information from the certification request.
注: 証明書リクエストにサブジェクト DN 情報を含めるのが一般的です。
When the shared-secret is generated and transferred out-of-band to initiate the registration process (Section 6.2), a particular subject DN is also associated with the shared-secret and communicated to the client. (The subject DN generated MUST be unique per entity in accordance with the CA policy; a NULL subject DN cannot be used. A common practice could be to place the identification value as part of the subject DN.) When the client generates the Full PKI Request, it MUST use these two pieces of information as follows:
共有シークレットが生成され、帯域外で転送されて登録プロセス (セクション 6.2) を開始すると、特定のサブジェクト DN も共有シークレットに関連付けられ、クライアントに通知されます。(生成されるサブジェクト DN は、CA ポリシーに従ってエンティティごとに一意である必要があります。NULL のサブジェクト DN は使用できません。一般的な方法としては、サブジェクト DN の一部として識別値を配置することが考えられます。) クライアントは完全な PKI リクエストを生成するとき、これら 2 つの情報を次のように使用しなければなりません。
1. The client MUST include the specific subject DN that it received along with the shared-secret as the subject name in every certification request (PKCS #10 and/or CRMF) in the Full PKI Request. The subject names in the certification requests MUST NOT be NULL.
1. クライアントは、完全な PKI リクエスト内のすべての認証リクエスト (PKCS #10 および/または CRMF) にサブジェクト名として共有秘密とともに受信した特定のサブジェクト DN を含めなければなりません (MUST)。証明書リクエストのサブジェクト名は NULL であってはなりません。
2. The client MUST include an Identity Proof control (Section 6.2.2) or Identity Proof Version 2 control (Section 6.2.1), derived from the shared-secret, in the Full PKI Request.
2. クライアントは、完全な PKI リクエストに、共有秘密から派生した ID 証明コントロール (セクション 6.2.2) または ID 証明バージョン 2 コントロール (セクション 6.2.1) を含めなければなりません (MUST)。
The server receiving this message MUST (a) validate the Identity Proof control and then (b) check that the subject DN included in each certification request matches that associated with the shared-secret. If either of these checks fails, the certification request MUST be rejected.
このメッセージを受信するサーバーは、(a) Identity Proof コントロールを検証し、(b) 各認証要求に含まれるサブジェクト DN が共有秘密に関連付けられたものと一致することを確認しなければなりません (MUST)。これらのチェックのいずれかが失敗した場合、認証リクエストは拒否されなければなりません。
Linking between the POP and an identity is easy when an existing certificate is used. The client copies all of the naming information from the existing certificate (subject field and Subject Alternative Name extension) into the new certification request. The POP on the new public key is then performed by using the new key to sign the identity information (linking the POP to a specific identity). The identity information is then tied to the POP information by signing the entire enrollment request with the private key of the existing certificate.
既存の証明書を使用すると、POP と ID 間のリンクが簡単になります。クライアントは、既存の証明書のすべての命名情報 (サブジェクト フィールドおよびサブジェクト代替名拡張子) を新しい証明書要求にコピーします。次に、新しい公開キーでの POP が、新しいキーを使用して ID 情報に署名することによって実行されます (POP を特定の ID にリンクします)。次に、既存の証明書の秘密キーを使用して登録要求全体に署名することによって、ID 情報が POP 情報に関連付けられます。
Existing certificate linking can be used in the following circumstances:
既存の証明書リンクは、次の状況で使用できます。
* When replacing a certificate by doing a renewal or rekey certification request.
* 証明書の更新またはキー再生成要求を実行して証明書を置き換える場合。
* Using an existing certificate to get a new certificate. An example of this would be to get a key establishment certificate after having gotten a signature certificate.
* 既存の証明書を使用して新しい証明書を取得します。この例としては、署名証明書を取得した後に鍵確立証明書を取得することが挙げられます。
* Using a third-party certificate to get a new certificate from a CA. An example of this would be using a certificate and key pair distributed with a device to prove an identity. This requires that the CA have an out-of-band channel to map the identity in the device certificate to the new EE identity.
* サードパーティの証明書を使用して CA から新しい証明書を取得します。この例としては、デバイスとともに配布された証明書とキーのペアを使用して ID を証明することが挙げられます。これには、デバイス証明書内の ID を新しい EE ID にマッピングするための帯域外チャネルが CA に必要です。
The Data Return control allows clients to send arbitrary data (usually some type of internal state information) to the server and to have the data returned as part of the Full PKI Response. Data placed in a Data Return control is considered to be opaque to the server. The same control is used for both Full PKI Requests and Responses. If the Data Return control appears in a Full PKI Request, the server MUST return it as part of the PKI Response.
データ リターン コントロールを使用すると、クライアントは任意のデータ (通常は何らかの内部状態情報) をサーバーに送信し、そのデータを完全な PKI 応答の一部として返すことができます。データ リターン コントロールに配置されたデータは、サーバーに対して不透明であるとみなされます。同じ制御が完全な PKI 要求と応答の両方に使用されます。データ リターン コントロールが完全な PKI リクエストに含まれる場合、サーバーはそれを PKI レスポンスの一部として返さなければなりません (MUST)。
In the event that the information in the Data Return control needs to be confidential, it is expected that the client would apply some type of encryption to the contained data, but the details of this are outside the scope of this specification.
データ リターン コントロール内の情報を機密にする必要がある場合、クライアントは含まれるデータに何らかの種類の暗号化を適用することが期待されますが、その詳細はこの仕様の範囲外です。
The Data Return control is identified by the OID:
データ リターン コントロールは OID によって識別されます。
id-cmc-dataReturn OBJECT IDENTIFIER ::= { id-cmc 4 }
The Data Return control has the ASN.1 definition:
データ リターン コントロールには ASN.1 定義があります。
DataReturn ::= OCTET STRING
A client could use this control to place an identifier marking the exact source of the private key material. This might be the identifier of a hardware device containing the private key.
クライアントはこのコントロールを使用して、秘密キー素材の正確なソースをマークする識別子を配置できます。これは、秘密キーを含むハードウェア デバイスの識別子である可能性があります。
These controls exist for RAs to be able to modify the contents of a certification request. Modifications might be necessary for various reasons. These include addition of certificate extensions or modification of subject and/or subject alternative names.
これらの制御は、RA が認証要求の内容を変更できるようにするために存在します。さまざまな理由により、変更が必要になる場合があります。これには、証明書拡張子の追加、サブジェクトおよび/またはサブジェクトの代替名の変更が含まれます。
Two controls exist for this purpose. The first control, Modify Certification Request (Section 6.5.1), allows the RA to replace or remove any field in the certificate. The second control, Add Extensions (Section 6.5.2), only allows for the addition of extensions.
この目的のために 2 つのコントロールが存在します。最初のコントロールである証明書要求の変更 (セクション 6.5.1) では、RA が証明書内のフィールドを置換または削除できます。2 番目のコントロールである [拡張機能の追加] (セクション 6.5.2) では、拡張機能の追加のみが可能です。
The Modify Certification Request control is used by RAs to change fields in a requested certificate.
Modify Certification Request コントロールは、要求された証明書のフィールドを変更するために RA によって使用されます。
The Modify Certification Request control is identified by the OID:
Modify Certification Request コントロールは、OID によって識別されます。
id-cmc-modCertTemplate OBJECT IDENTIFIER ::= { id-cmc 31 }
The Modify Certification Request has the ASN.1 definition:
証明書の変更要求には、ASN.1 定義があります。
ModCertTemplate ::= SEQUENCE {
pkiDataReference BodyPartPath,
certReferences BodyPartList,
replace BOOLEAN DEFAULT TRUE,
certTemplate CertTemplate
}
The fields in ModCertTemplate have the following meaning:
ModCertTemplate のフィールドには次の意味があります。
* pkiDataReference is the path to the PKI Request containing the certification request(s) to be modified.
* pkiDataReference は、変更する認証要求を含む PKI 要求へのパスです。
* certReferences refers to one or more certification requests in the PKI Request referenced by pkiDataReference to be modified. Each BodyPartID of the certReferences sequence MUST be equal to either the bodyPartID of a TaggedCertificationRequest (PKCS #10) or the certReqId of the CertRequest within a CertReqMsg (CRMF). By definition, the certificate extensions included in the certTemplate field are applied to every certification request referenced in the certReferences sequence. If a request corresponding to bodyPartID cannot be found, the CMCFailInfo with a value of badRequest is returned that references this control.
* certReferences は、変更対象の pkiDataReference によって参照される PKI 要求内の 1 つ以上の証明書要求を参照します。certReferences シーケンスの各 BodyPartID は、TaggedCertificationRequest (PKCS #10) の bodyPartID または CertReqMsg (CRMF) 内の CertRequest の certReqId のいずれかに等しくなければなりません (MUST)。定義上、certTemplate フィールドに含まれる証明書拡張子は、certReferences シーケンスで参照されるすべての証明書要求に適用されます。bodyPartID に対応するリクエストが見つからない場合は、このコントロールを参照する badRequest の値を持つ CMCFailInfo が返されます。
* replace specifies if the target certification request is to be modified by replacing or deleting fields. If the value is TRUE, the data in this control replaces the data in the target certification request. If the value is FALSE, the data in the target certification request is deleted. The action is slightly different for the extensions field of certTemplate; each extension is treated individually rather than as a single unit.
* replace は、フィールドの置換または削除によってターゲット認証リクエストを変更するかどうかを指定します。値が TRUE の場合、このコントロールのデータはターゲット認証要求のデータを置き換えます。値が FALSE の場合、ターゲット証明書リクエストのデータは削除されます。certTemplate の拡張フィールドのアクションは少し異なります。各拡張機能は単一のユニットとしてではなく個別に扱われます。
* certTemplate is a certificate template object [CRMF][ADD-ASN1]. If a field is present and replace is TRUE, it replaces that field in the certification request. If the field is present and replace is FALSE, the field in the certification request is removed. If the field is absent, no action is performed. Each extension is treated as a single field.
* certTemplate は、証明書テンプレート オブジェクト [CRMF][ADD-ASN1] です。フィールドが存在し、replace が TRUE の場合、認証要求内のそのフィールドが置き換えられます。フィールドが存在し、replace が FALSE の場合、証明書リクエストのフィールドは削除されます。フィールドが存在しない場合、アクションは実行されません。各拡張子は単一のフィールドとして扱われます。
Servers MUST be able to process all extensions defined, but not prohibited, in [PKIXCERT]. Servers are not required to be able to process every X.509v3 extension transmitted using this protocol, nor are they required to be able to process other, private extensions. Servers are not required to put all RA-requested extensions into a certificate. Servers are permitted to modify RA-requested extensions. Servers MUST NOT alter an extension so as to reverse the meaning of a client-requested extension. If a certification request is denied due to the inability to handle a requested extension and a Full PKI Response is returned, the server MUST return a CMCFailInfo value with the value of unsupportedExt.
サーバーは、[PKIXCERT] で定義されているが禁止されていないすべての拡張機能を処理できなければなりません (MUST)。サーバーは、このプロトコルを使用して送信されるすべての X.509v3 拡張機能を処理できる必要はなく、また、他のプライベート拡張機能を処理できる必要もありません。サーバーは、RA が要求したすべての拡張機能を証明書に含める必要はありません。サーバーは、RA が要求した拡張機能を変更することが許可されています。サーバーは、クライアントが要求した拡張子の意味を逆にするために拡張子を変更してはなりません (MUST NOT)。要求された拡張機能を処理できないために認証要求が拒否され、完全な PKI 応答が返された場合、サーバーは unsupportedExt の値を持つ CMCFailInfo 値を返さなければなりません (MUST)。
If a certification request is the target of multiple Modify Certification Request controls, the behavior is:
証明書要求が複数の証明書要求変更コントロールのターゲットである場合、動作は次のようになります。
* If control A exists in a layer that contains the layer of control B, control A MUST override control B. In other words, controls should be applied from the innermost layer to the outermost layer.
* コントロール A がコントロール B の層を含む層に存在する場合、コントロール A はコントロール B をオーバーライドしなければなりません (MUST)。言い換えれば、コントロールは最も内側の層から最も外側の層まで適用される必要があります。
* If control A and control B are in the same PKIData (i.e., the same wrapping layer), the order of application is non-determinate.
* コントロール A とコントロール B が同じ PKIData (つまり、同じラッピング層) にある場合、適用の順序は決まりません。
The same order of application is used if a certification request is the target of both a Modify Certification Request control and an Add Extensions control.
証明書要求が証明書要求の変更コントロールと拡張機能の追加コントロールの両方のターゲットである場合、同じ順序の適用が使用されます。
The Add Extensions control has been deprecated in favor of the Modify Certification Request control. It was replaced so that fields in the certification request other than extensions could be modified.
[拡張機能の追加] コントロールは非推奨となり、[証明書要求の変更] コントロールが優先されます。拡張機能以外の証明書リクエストのフィールドを変更できるように置き換えられました。
The Add Extensions control is used by RAs to specify additional extensions that are to be included in certificates.
[拡張機能の追加] コントロールは、証明書に含める追加の拡張機能を指定するために RA によって使用されます。
The Add Extensions control is identified by the OID:
拡張機能の追加コントロールは、OID によって識別されます。
id-cmc-addExtensions OBJECT IDENTIFIER ::= { id-cmc 8 }
The Add Extensions control has the ASN.1 definition:
[拡張機能の追加] コントロールには ASN.1 定義があります。
AddExtensions ::= SEQUENCE {
pkiDataReference BodyPartID,
certReferences SEQUENCE OF BodyPartID,
extensions SEQUENCE OF Extension{{CertExtensions}}
}
The fields in AddExtensions have the following meaning:
AddExtensions のフィールドには次の意味があります。
* pkiDataReference contains the body part identity of the embedded certification request.
* pkiDataReference には、埋め込み認証要求の本文部分の ID が含まれます。
* certReferences is a list of references to one or more of the certification requests contained within a PKIData. Each body part identifier of the certReferences sequence MUST be equal to either the bodyPartID of a TaggedCertificationRequest (PKCS #10) or the certReqId of the CertRequest within a CertReqMsg (CRMF). By definition, the listed extensions are to be applied to every certification request referenced in the certReferences sequence. If a certification request corresponding to bodyPartID cannot be found, the CMCFailInfo with a value of badRequest is returned referencing this control.
* certReferences は、PKIData 内に含まれる 1 つ以上の証明書リクエストへの参照のリストです。certReferences シーケンスの各ボディ部分識別子は、TaggedCertificationRequest (PKCS #10) の bodyPartID または CertReqMsg (CRMF) 内の CertRequest の certReqId のいずれかに等しくなければなりません (MUST)。定義により、リストされている拡張機能は、certReferences シーケンスで参照されるすべての認証要求に適用されます。bodyPartID に対応する認証要求が見つからない場合は、このコントロールを参照して、値が badRequest の CMCFailInfo が返されます。
* extensions is a sequence of extensions to be applied to the referenced certification requests.
* extensions は、参照された証明書リクエストに適用される一連の拡張機能です。
Servers MUST be able to process all extensions defined, but not prohibited, in [PKIXCERT]. Servers are not required to be able to process every X.509v3 extension transmitted using this protocol, nor are they required to be able to process other, private extensions. Servers are not required to put all RA-requested extensions into a certificate. Servers are permitted to modify RA-requested extensions. Servers MUST NOT alter an extension so as to reverse the meaning of a client-requested extension. If a certification request is denied due to the inability to handle a requested extension and a response is returned, the server MUST return a CMCFailInfo with the value of unsupportedExt.
サーバーは、[PKIXCERT] で定義されているが禁止されていないすべての拡張機能を処理できなければなりません (MUST)。サーバーは、このプロトコルを使用して送信されるすべての X.509v3 拡張機能を処理できる必要はなく、また、他のプライベート拡張機能を処理できる必要もありません。サーバーは、RA が要求したすべての拡張機能を証明書に含める必要はありません。サーバーは、RA が要求した拡張機能を変更することが許可されています。サーバーは、クライアントが要求した拡張子の意味を逆にするために拡張子を変更してはなりません (MUST NOT)。要求された拡張機能を処理できないために認証要求が拒否され、応答が返された場合、サーバーは unsupportedExt の値を持つ CMCFailInfo を返さなければなりません (MUST)。
If multiple Add Extensions controls exist in a Full PKI Request, the exact behavior is left up to the CA policy. However, it is recommended that the following policy be used. These rules would be applied to individual extensions within an Add Extensions control (as opposed to an "all or nothing" approach).
フル PKI リクエストに複数の拡張機能の追加コントロールが存在する場合、正確な動作は CA ポリシーに委ねられます。ただし、次のポリシーを使用することをお勧めします。これらのルールは、(「全か無か」のアプローチとは対照的に) 拡張機能の追加コントロール内の個々の拡張機能に適用されます。
1. If the conflict is within a single PKIData, the certification request would be rejected with a CMCFailInfo value of badRequest.
1. 競合が 1 つの PKIData 内にある場合、認証要求は CMCFailInfo 値 badRequest で拒否されます。
2. If the conflict is between different PKIData, the outermost version of the extension would be used (allowing an RA to override the requested extension).
2. 競合が異なる PKIData 間で発生する場合は、拡張機能の最も外側のバージョンが使用されます (RA が要求された拡張機能をオーバーライドできるようになります)。
Transactions are identified and tracked with a transaction identifier. If used, clients generate transaction identifiers and retain their value until the server responds with a Full PKI Response that completes the transaction. Servers correspondingly include received transaction identifiers in the Full PKI Response.
トランザクションはトランザクション識別子で識別および追跡されます。使用すると、クライアントはトランザクション識別子を生成し、サーバーがトランザクションを完了する完全な PKI 応答で応答するまでその値を保持します。これに応じて、サーバーは受信したトランザクション識別子を完全な PKI 応答に含めます。
The Transaction Identifier control is identified by the OID:
トランザクション識別子コントロールは OID によって識別されます。
id-cmc-transactionId OBJECT IDENTIFIER ::= { id-cmc 5 }
The Transaction Identifier control has the ASN.1 definition:
トランザクション識別子コントロールには ASN.1 定義があります。
TransactionId ::= INTEGER
The Transaction Identifier control identifies a given transaction. It is used by client and server to manage the state of an operation. Clients MAY include a Transaction Identifier control in a request. If the original request contains a Transaction Identifier control, all subsequent requests and responses MUST include the same Transaction Identifier control.
トランザクション識別子コントロールは、特定のトランザクションを識別します。これは、クライアントとサーバーによって操作の状態を管理するために使用されます。クライアントはリクエストにトランザクション識別子コントロールを含めてもよい(MAY)。元のリクエストにトランザクション識別子コントロールが含まれている場合、後続のすべてのリクエストと応答には同じトランザクション識別子コントロールが含まれなければなりません(MUST)。
Replay protection is supported through the use of the Sender and Recipient Nonce controls. If nonces are used, in the first message of a transaction, a Recipient Nonce control is not transmitted; a Sender Nonce control is included by the transaction originator and retained for later reference. The recipient of a Sender Nonce control reflects this value back to the originator as a Recipient Nonce control and includes its own Sender Nonce control. Upon receipt by the transaction originator of this response, the transaction originator compares the value of Recipient Nonce control to its retained value. If the values match, the message can be accepted for further security processing. The received value for a Sender Nonce control is also retained for inclusion in the next message associated with the same transaction.
リプレイ保護は、送信者および受信者の Nonce コントロールの使用によってサポートされます。nonce が使用される場合、トランザクションの最初のメッセージでは、Recipient Nonce コントロールは送信されません。Sender Nonce コントロールはトランザクションの発信者によって組み込まれ、後で参照できるように保持されます。Sender Nonce コントロールの受信者は、この値を受信者 Nonce コントロールとして発信者に反映し、独自の Sender Nonce コントロールを含みます。トランザクションの開始者がこの応答を受信すると、トランザクションの開始者は Recipient Nonce コントロールの値をその保持されている値と比較します。値が一致する場合、メッセージはさらなるセキュリティ処理のために受け入れられます。Sender Nonce コントロールの受信値も、同じトランザクションに関連付けられた次のメッセージに含めるために保持されます。
The Sender Nonce and Recipient Nonce controls are identified by the OIDs:
Sender Nonce コントロールと Recipient Nonce コントロールは OID によって識別されます。
id-cmc-senderNonce OBJECT IDENTIFIER ::= { id-cmc 6 }
id-cmc-recipientNonce OBJECT IDENTIFIER ::= { id-cmc 7 }
The Sender Nonce control has the ASN.1 definition:
Sender Nonce コントロールには ASN.1 定義があります。
SenderNonce ::= OCTET STRING
The Recipient Nonce control has the ASN.1 definition:
Recipient Nonce コントロールには ASN.1 定義があります。
RecipientNonce ::= OCTET STRING
Clients MAY include a Sender Nonce control in the initial PKI Request. If a message includes a Sender Nonce control, the response MUST include the transmitted value of the previously received Sender Nonce control as a Recipient Nonce control and include a new value as its Sender Nonce control.
クライアントは、最初の PKI リクエストに Sender Nonce コントロールを含めてもよい (MAY)。メッセージに Sender Nonce コントロールが含まれる場合、応答には、以前に受信した Sender Nonce コントロールの送信値を Recipient Nonce コントロールとして含め、また新しい値を Sender Nonce コントロールとして含めなければなりません (MUST)。
Servers MAY require that this POP method be used only if another POP method is unavailable. Servers SHOULD reject all certification requests contained within a PKIData if any required POP is missing for any element within the PKIData.
サーバーは、別の POP メソッドが利用できない場合にのみ、この POP メソッドを使用することを要求してもよい(MAY)。PKIData 内の要素に必要な POP が欠落している場合、サーバーは PKIData 内に含まれるすべての認証リクエストを拒否する必要があります (SHOULD)。
Many servers require proof that the entity that generated the certification request actually possesses the corresponding private component of the key pair. For keys that can be used as signature keys, signing the certification request with the private key serves as a POP on that key pair. With keys that can only be used for encryption operations, POP MUST be performed by forcing the client to decrypt a value. See Section 5 of [CRMF] for a detailed discussion of POP.
多くのサーバーは、認証リクエストを生成したエンティティがキー ペアの対応するプライベート コンポーネントを実際に所有しているという証明を必要とします。署名キーとして使用できるキーの場合、秘密キーを使用して証明書リクエストに署名すると、そのキー ペアの POP として機能します。暗号化操作にのみ使用できるキーを使用する場合、クライアントに値の復号化を強制することによって POP を実行しなければなりません (MUST)。POP の詳細については、[CRMF] のセクション 5 を参照してください。
By necessity, POP for encryption-only keys cannot be done in one round trip, since there are four distinct steps:
必然的に、暗号化専用キーの POP は 1 往復では実行できません。これは、次の 4 つの異なる手順があるためです。
1. Client tells the server about the public component of a new encryption key pair.
1. クライアントは、新しい暗号化キー ペアの公開コンポーネントについてサーバーに通知します。
2. Server sends the client a POP challenge, encrypted with the presented public encryption key.
2. サーバーは、提示された公開暗号化キーで暗号化された POP チャレンジをクライアントに送信します。
3. Client decrypts the POP challenge using the private key that corresponds to the presented public key and uses it for computing a keyed hash value sent back to the server.
3. クライアントは、提示された公開キーに対応する秘密キーを使用して POP チャレンジを復号し、それを使用して、サーバーに送り返されるキー付きハッシュ値を計算します。
4. Server validates the decrypted POP challenge and continues processing the certification request.
4. サーバーは、復号化された POP チャレンジを検証し、認証要求の処理を続行します。
CMC defines two different controls. The first deals with the encrypted challenge sent from the server to the user in Step 2. The second deals with the value derived from the decrypted challenge sent by the client to the server in Step 3.
CMC は 2 つの異なるコントロールを定義します。1 つ目は、ステップ 2 でサーバーからユーザーに送信された暗号化されたチャレンジを処理します。2 つ目は、ステップ 3 でクライアントによってサーバーに送信された復号化されたチャレンジから導出された値を処理します。
The Encrypted POP control is used to send the encrypted challenge from the server to the client as part of the PKIResponse.
暗号化された POP コントロールは、暗号化されたチャレンジを PKIResponse の一部としてサーバーからクライアントに送信するために使用されます。
Note: It is assumed that the message sent in Step 1 above is a Full PKI Request and that the response in Step 2 is a Full PKI Response including a CMCFailInfo specifying that a POP is explicitly required, and providing the POP challenge in the Encrypted POP control.
注: 上記のステップ 1 で送信されたメッセージは完全な PKI 要求であり、ステップ 2 の応答は、POP が明示的に必要であることを指定し、暗号化された POP コントロールで POP チャレンジを提供する CMCFailInfo を含む完全な PKI 応答であると想定されています。
The Encrypted POP control is identified by the OID:
暗号化された POP コントロールは OID によって識別されます。
id-cmc-encryptedPOP OBJECT IDENTIFIER ::= { id-cmc 9 }
The Encrypted POP control has the ASN.1 definition:
暗号化された POP コントロールには ASN.1 定義があります。
EncryptedPOP ::= SEQUENCE {
request TaggedRequest,
cms ContentInfo,
thePOPAlgID AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}},
witnessAlgID AlgorithmIdentifier{DIGEST-ALGORITHM,
{WitnessAlgs}},
witness OCTET STRING
}
The Decrypted POP control is identified by the OID:
復号化された POP コントロールは OID によって識別されます。
id-cmc-decryptedPOP OBJECT IDENTIFIER ::= { id-cmc 10 }
The Decrypted POP control has the ASN.1 definition:
復号化された POP コントロールには ASN.1 定義があります。
DecryptedPOP ::= SEQUENCE {
bodyPartID BodyPartID,
thePOPAlgID AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}},
thePOP OCTET STRING
}
The encrypted POP algorithm works as follows:
暗号化された POP アルゴリズムは次のように機能します。
1. The server randomly generates the POP Proof Value and associates it with the request.
1. サーバーはランダムに POP Proof Value を生成し、それをリクエストに関連付けます。
2. The server returns the Encrypted POP control with the following fields set:
2. サーバーは、次のフィールドが設定された暗号化 POP コントロールを返します。
* request is the original certification request (it is included here so the client need not keep a copy of the request).
* request は元の認証リクエストです (ここに含まれているため、クライアントはリクエストのコピーを保持する必要はありません)。
* cms is an EnvelopedData or AuthEnvelopedData, the encapsulated content type being id-data and the content being the POP Proof Value; this value needs to be long enough that one cannot reverse the value from the witness hash. If the certification request contains a Subject Key Identifier (SKI) extension, then the recipient identifier SHOULD be the SKI. If the issuerAndSerialNumber form is used, the IssuerName MUST be encoded as NULL and the SerialNumber as the bodyPartID of the certification request.
* cms は EnvelopedData または AuthEnvelopedData で、カプセル化されたコンテンツ タイプは id-data、コンテンツは POP Proof Value です。この値は、証人ハッシュの値を元に戻せないほど十分な長さである必要があります。認証要求にサブジェクト キー識別子 (SKI) 拡張が含まれている場合、受信者識別子は SKI である必要があります (SHOULD)。issuerAndSerialNumber 形式を使用する場合は、IssuerName を NULL としてエンコードし、SerialNumber を認証要求の bodyPartID としてエンコードする必要があります。
* thePOPAlgID identifies the algorithm to be used in computing the return POP value.
* thePOPAlgID は、戻り POP 値の計算に使用されるアルゴリズムを識別します。
* witnessAlgID identifies the hash algorithm used on the POP Proof Value to create the field witness.
* witnessAlgID は、フィールド証人を作成するために POP Proof Value で使用されるハッシュ アルゴリズムを識別します。
* witness is the hashed value of the POP Proof Value.
* Witness は POP Proof Value のハッシュ値です。
3. The client decrypts the cms field to obtain the POP Proof Value. The client computes H(POP Proof Value) using the witnessAlgID and compares to the value of witness. If the values do not compare or the decryption is not successful, the client MUST abort the enrollment process. The client aborts the process by sending a request containing an Extended CMC Status Info or a CMC Status Info control with CMCFailInfo value of popFailed.
3. クライアントは cms フィールドを復号化して、POP Proof Value を取得します。クライアントは、witnessAlgID を使用して H(POP Proof Value) を計算し、witness の値と比較します。値が比較されない場合、または復号化が成功しない場合、クライアントは登録プロセスを中止しなければなりません (MUST)。クライアントは、拡張 CMC ステータス情報、または CMCFailInfo 値が popFailed の CMC ステータス情報コントロールを含む要求を送信することにより、プロセスを中止します。
4. The client creates the Decrypted POP control as part of a new PKIData. The fields in the DecryptedPOP are:
4. クライアントは、新しい PKIData の一部として復号化された POP コントロールを作成します。DecryptedPOP のフィールドは次のとおりです。
* bodyPartID refers to the certification request in the new PKI Request.
* bodyPartID は、新しい PKI リクエスト内の認証リクエストを参照します。
* thePOPAlgID is copied from the encryptedPOP.
* POPAlgID は暗号化された POP からコピーされます。
* thePOP contains the possession proof. This value is computed by thePOPAlgID using the POP Proof Value and the request.
* thePOPには所有証明が記載されています。この値は、POP Proof Value とリクエストを使用して POPAlgID によって計算されます。
5. The server then re-computes the value of thePOP from its cached value and the request and compares to the value of thePOP. If the values do not match, the server MUST NOT issue the certificate. The server MAY reissue a new challenge or MAY fail the request altogether.
5. 次に、サーバーはキャッシュされた値とリクエストから POP の値を再計算し、POP の値と比較します。値が一致しない場合、サーバーは証明書を発行してはなりません。サーバーは新しいチャレンジを再発行してもよいし、リクエストを完全に失敗してもよい。
When defining the algorithms for thePOPAlgID and witnessAlgID, care must be taken to ensure that the result of witnessAlgID is not a useful value to shortcut the computation with thePOPAlgID. The POP Proof Value is used as the secret value in the HMAC algorithm and the request is used as the data. If the POP Proof Value is greater than 64 bytes, only the first 64 bytes of the POP Proof Value is used as the secret.
POPAlgID とwitnessAlgID のアルゴリズムを定義するときは、witnessAlgID の結果が、POPAlgID を使用して計算をショートカットするのに有用な値にならないように注意する必要があります。POP Proof Value は HMAC アルゴリズムの秘密値として使用され、リクエストはデータとして使用されます。POP Proof Value が 64 バイトより大きい場合、POP Proof Value の最初の 64 バイトのみがシークレットとして使用されます。
One potential problem with the algorithm above is the amount of state that a CA needs to keep in order to verify the returned POP value. The following describes one of many possible ways of addressing the problem by reducing the amount of state kept on the CA to a single (or small set) of values.
上記のアルゴリズムに関する潜在的な問題の 1 つは、返された POP 値を検証するために CA が保持する必要がある状態の量です。以下では、CA 上で保持される状態の量を単一 (または小さなセット) の値に減らすことで問題に対処する多くの考えられる方法のうちの 1 つについて説明します。
1. Server generates random seed x, constant across all requests. (The value of x would normally be altered on a regular basis and kept for a short time afterwards.)
1. サーバーは、すべてのリクエストにわたって一定のランダム シード x を生成します。(x の値は通常、定期的に変更され、その後短期間保持されます。)
2. For certification request R, server computes y = F(x,R). F can be, for example, HMAC-SHA256(x,R). All that's important for statelessness is that y be consistently computable with only known state constant x and function F, other inputs coming from the certification request structure. y should not be predictable based on knowledge of R, thus the use of a one-way function like HMAC-SHA256.
2. 認証リクエスト R の場合、サーバーは y = F(x,R) を計算します。たとえば、F は HMAC-SHA256(x,R) です。ステートレス性にとって重要なことは、既知の状態定数 x と関数 F だけを使用して y が一貫して計算可能であり、その他の入力は認証要求構造からのものであることだけです。y は R の知識に基づいて予測できるべきではないため、HMAC-SHA256 のような一方向関数を使用します。
In a certification request scenario that involves an RA, the CA may allow (or require) that the RA perform the POP protocol with the entity that generated the certification request. In this case, the RA needs a way to inform the CA that it has done the POP. The RA POP Witness control addresses this issue.
RA が関係する認証要求シナリオでは、CA は、RA が認証要求を生成したエンティティと POP プロトコルを実行することを許可 (または要求) する場合があります。この場合、RA は POP を実行したことを CA に通知する方法が必要です。RA POP Witness コントロールはこの問題に対処します。
The RA POP Witness control is identified by the OID:
RA POP Witness コントロールは OID によって識別されます。
id-cmc-lraPOPWitness OBJECT IDENTIFIER ::= { id-cmc 11 }
The RA POP Witness control has the ASN.1 definition:
RA POP Witness コントロールには ASN.1 定義があります。
LraPopWitness ::= SEQUENCE {
pkiDataBodyid BodyPartID,
bodyIds SEQUENCE OF BodyPartID
}
The fields in LraPopWitness have the following meaning:
LraPopWitness のフィールドには次の意味があります。
* pkiDataBodyid contains the body part identifier of the nested TaggedContentInfo containing the client's Full PKI Request. pkiDataBodyid is set to 0 if the request is in the current PKIData.
* pkiDataBodyid には、クライアントの完全な PKI リクエストを含むネストされた TaggedContentInfo の本文部分の識別子が含まれます。リクエストが現在の PKIData にある場合、pkiDataBodyid は 0 に設定されます。
* bodyIds is a list of certification requests for which the RA has performed an out-of-band authentication. The method of authentication could be archival of private key material, challenge-response, or other means.
* bodyIds は、RA が帯域外認証を実行した認証要求のリストです。認証方法には、秘密鍵マテリアルのアーカイブ、チャレンジ/レスポンス、またはその他の手段が考えられます。
If a certification server does not allow an RA to do the POP verification, it returns a CMCFailInfo with the value of popFailed. The CA MUST NOT start a challenge-response to reverify the POP itself.
認証サーバーが RA による POP 検証の実行を許可していない場合、popFailed の値を持つ CMCFailInfo を返します。CA は、POP 自体を再検証するためにチャレンジ/レスポンスを開始してはなりません (MUST NOT)。
Everything described in this section is optional to implement.
このセクションで説明されているものはすべて、実装はオプションです。
The Get Certificate control is used to retrieve a previously issued certificate from a certificate repository. A CA, an RA, or an independent service may provide this repository. The clients expected to use this facility are those where a fully deployed directory is either infeasible or undesirable.
Get Certificate コントロールは、以前に発行された証明書を証明書リポジトリから取得するために使用されます。CA、RA、または独立したサービスがこのリポジトリを提供する場合があります。この機能を使用することが想定されるクライアントは、ディレクトリを完全に展開することが不可能か、または望ましくないクライアントです。
The Get Certificate control is identified by the OID:
Get Certificate コントロールは OID によって識別されます。
id-cmc-getCert OBJECT IDENTIFIER ::= { id-cmc 15 }
The Get Certificate control has the ASN.1 definition:
Get Certificate コントロールには ASN.1 定義があります。
GetCert ::= SEQUENCE {
issuerName GeneralName,
serialNumber INTEGER }
The fields in GetCert have the following meaning:
GetCert のフィールドには次の意味があります。
* issuerName is the name of the certificate issuer.
* issuerName は証明書発行者の名前です。
* serialNumber identifies the certificate to be retrieved.
* serialNumber は取得する証明書を識別します。
The server that responds to this request places the requested certificate in the certificates field of a SignedData. If the Get Certificate control is the only control in a Full PKI Request, the response should be a Simple PKI Response.
この要求に応答するサーバーは、要求された証明書を SignedData の証明書フィールドに配置します。Get Certificate コントロールが完全な PKI 要求内の唯一のコントロールである場合、応答は単純な PKI 応答である必要があります。
Everything described in this section is optional to implement.
このセクションで説明されているものはすべて、実装はオプションです。
The Get CRL control is used to retrieve CRLs from a repository of CRLs. A CA, an RA, or an independent service may provide this repository. The clients expected to use this facility are those where a fully deployed directory is either infeasible or undesirable.
Get CRL コントロールは、CRL のリポジトリから CRL を取得するために使用されます。CA、RA、または独立したサービスがこのリポジトリを提供する場合があります。この機能を使用することが想定されるクライアントは、ディレクトリを完全に展開することが不可能か、または望ましくないクライアントです。
The Get CRL control is identified by the OID:
Get CRL コントロールは OID によって識別されます。
id-cmc-getCRL OBJECT IDENTIFIER ::= { id-cmc 16 }
The Get CRL control has the ASN.1 definition:
Get CRL コントロールには ASN.1 定義があります。
GetCRL ::= SEQUENCE {
issuerName Name,
cRLName GeneralName OPTIONAL,
time GeneralizedTime OPTIONAL,
reasons ReasonFlags OPTIONAL }
The fields in a GetCRL have the following meanings:
GetCRL のフィールドには次の意味があります。
* issuerName is the name of the CRL issuer.
* issuerName は CRL 発行者の名前です。
* cRLName may be the value of CRLDistributionPoints in the subject certificate or equivalent value in the event the certificate does not contain such a value.
* cRLName は、サブジェクト証明書内の CRLDistributionPoints の値、または証明書にそのような値が含まれていない場合の同等の値である可能性があります。
* time is used by the client to specify from among potentially several issues of CRL that one whose thisUpdate value is less than but nearest to the specified time. In the absence of a time component, the CA always returns with the most recent CRL.
* time は、クライアントによって、CRL の潜在的に複数の問題の中から、thisUpdate 値が指定された時刻より小さいが、指定された時刻に最も近い問題を指定するために使用されます。時間コンポーネントがない場合、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.
* reason は、失効理由ごとに分割された CRL の中から指定するために使用されます。実装者は、特定の失効リクエストには単一の CRLReason コードがあり、その結果、CRL 内のエントリには単一の CRLReason コード値が含まれることになりますが、単一の CRL は 1 つ以上のreasonFlags の情報を集約できることに留意する必要があります。
A server responding to this request places the requested CRL in the crls field of a SignedData. If the Get CRL control is the only control in a Full PKI Request, the response should be a Simple PKI Response.
このリクエストに応答するサーバーは、リクエストされた CRL を SignedData の crls フィールドに配置します。Get CRL コントロールがフル PKI リクエスト内の唯一のコントロールである場合、応答はシンプル PKI レスポンスである必要があります。
The Revocation Request control is used to request that a certificate be revoked.
失効要求コントロールは、証明書の失効を要求するために使用されます。
The Revocation Request control is identified by the OID:
取り消し要求コントロールは OID によって識別されます。
id-cmc-revokeRequest OBJECT IDENTIFIER ::= { id-cmc 17 }
The Revocation Request control has the ASN.1 definition:
失効要求コントロールには ASN.1 定義があります。
RevokeRequest ::= SEQUENCE {
issuerName Name,
serialNumber INTEGER,
reason CRLReason,
invalidityDate GeneralizedTime OPTIONAL,
sharedSecret OCTET STRING OPTIONAL,
comment UTF8string OPTIONAL }
The fields of RevokeRequest have the following meaning:
RevokeRequest のフィールドには次の意味があります。
* issuerName is the name of the certificate issuer.
* issuerName は証明書発行者の名前です。
* serialNumber is the serial number of the certificate to be revoked.
* serialNumber は、失効する証明書のシリアル番号です。
* reason is the suggested CRLReason code for why the certificate is being revoked. The CA can use this value at its discretion in building the CRL.
* reason は、証明書が取り消される理由を示す推奨 CRLReason コードです。CA は、CRL を構築する際にこの値を独自の裁量で使用できます。
* invalidityDate is the suggested value for the Invalidity Date CRL Extension. The CA can use this value at its discretion in building the CRL.
* validityDate は、Invalidity Date CRL Extension の推奨値です。CA は、CRL を構築する際にこの値を独自の裁量で使用できます。
* sharedSecret is a secret value registered by the EE when the certificate was obtained to allow for revocation of a certificate in the event of key loss.
* sharedSecret は、キーの紛失時に証明書を取り消すことができるように、証明書の取得時に EE によって登録されたシークレット値です。
* comment is a human-readable comment.
* comment は人間が読めるコメントです。
For a revocation request to be reliable in the event of a dispute, a strong proof-of-origin is required. However, in the instance when an EE has lost use of its signature private key, it is impossible for the EE to produce a digital signature (prior to the certification of a new signature key pair). The Revoke Request control allows the EE to send the CA a shared-secret that may be used as an alternative authenticator in the instance of loss of use of the EE's signature private key. The acceptability of this practice is a matter of local security policy.
紛争が発生した場合に取り消し要求が信頼できるようにするには、強力な出所証明が必要です。ただし、EE がその署名秘密鍵の使用を失った場合、EE は (新しい署名鍵ペアの認証前に) デジタル署名を生成することができなくなります。Revoke Request コントロールにより、EE は、EE の署名秘密キーが使用できなくなった場合に代替認証子として使用できる共有秘密を CA に送信できます。この慣行が受け入れられるかどうかは、地域のセキュリティ ポリシーの問題です。
It is possible to sign the revocation for the lost certificate with a different certificate in some circumstances. A client can sign a revocation for an encryption key with a signing certificate if the name information matches. Similarly, an administrator or RA can be assigned the ability to revoke the certificate of a third party. Acceptance of the revocation by the server depends on local policy in these cases.
状況によっては、紛失した証明書の失効に別の証明書を使用して署名することが可能です。名前情報が一致する場合、クライアントは署名証明書を使用して暗号化キーの失効に署名できます。同様に、管理者または RA には、第三者の証明書を取り消す権限を割り当てることができます。このような場合、サーバーによる取り消しの受け入れはローカル ポリシーによって異なります。
Clients MUST provide the capability to produce a digitally signed Revocation Request control. Clients SHOULD be capable of producing an unsigned Revocation Request control containing the EE shared-secret (the unsigned message consisting of a SignedData with no signatures). If a client provides shared-secret-based self-revocation, the client MUST be capable of producing a Revocation Request control containing the shared-secret. Servers MUST be capable of accepting both forms of revocation requests.
クライアントは、デジタル署名された失効要求コントロールを生成する機能を提供しなければなりません (MUST)。クライアントは、EE 共有秘密 (署名のない SignedData で構成される未署名のメッセージ) を含む未署名の失効要求コントロールを生成できる必要があります (SHOULD)。クライアントが共有シークレットベースの自己取り消しを提供する場合、クライアントは共有シークレットを含む取り消し要求コントロールを生成できなければなりません (MUST)。サーバーは両方の形式の取り消し要求を受け入れることができなければなりません。
The structure of an unsigned, shared-secret-based revocation request is a matter of local implementation. The shared-secret does not need to be encrypted when sent in a Revocation Request control. The shared-secret has a one-time use (i.e., it is used to request revocation of the certificate), and public knowledge of the shared-secret after the certificate has been revoked is not a problem. Clients need to inform users that the same shared-secret SHOULD NOT be used for multiple certificates.
署名されていない共有秘密ベースの取り消し要求の構造は、ローカル実装の問題です。共有秘密は、失効要求コントロールで送信するときに暗号化する必要はありません。共有秘密は 1 回限りの使用 (つまり、証明書の失効を要求するために使用されます) であり、証明書が失効した後に共有秘密が公に知られることは問題ありません。クライアントは、同じ共有秘密を複数の証明書に使用すべきではないことをユーザーに通知する必要があります。
A Full PKI Response MUST be returned for a revocation request.
失効リクエストに対しては完全な PKI レスポンスを返さなければなりません。
The Registration Information control allows for clients to pass additional information as part of a Full PKI Request.
登録情報コントロールを使用すると、クライアントは完全な PKI 要求の一部として追加情報を渡すことができます。
The Registration Information control is identified by the OID:
登録情報コントロールは OID によって識別されます。
id-cmc-regInfo OBJECT IDENTIFIER ::= { id-cmc 18 }
The Registration Information control has the ASN.1 definition:
登録情報コントロールには ASN.1 定義があります。
RegInfo ::= OCTET STRING
The content of this data is based on bilateral agreement between the client and server.
このデータの内容は、クライアントとサーバー間の二者間合意に基づいています。
The Response Information control allows a server to return additional information as part of a Full PKI Response.
応答情報コントロールを使用すると、サーバーは完全な PKI 応答の一部として追加情報を返すことができます。
The Response Information control is identified by the OID:
応答情報コントロールは OID によって識別されます。
id-cmc-responseInfo OBJECT IDENTIFIER ::= { id-cmc 19 }
The Response Information control has the ASN.1 definition:
応答情報コントロールには ASN.1 定義があります。
ResponseInfo ::= OCTET STRING
The content of this data is based on bilateral agreement between the client and server.
このデータの内容は、クライアントとサーバー間の二者間合意に基づいています。
In some environments, process requirements for manual intervention or other identity checks can delay the return of the certificate. The Query Pending control allows clients to query a server about the state of a pending certification request. The server returns a pendToken as part of the Extended CMC Status Info and the CMC Status Info controls (in the otherInfo field). The client copies the pendToken into the Query Pending control to identify the correct certification request to the server. The server returns a suggested time for the client to query for the state of a pending certification request.
環境によっては、手動介入やその他の ID チェックのプロセス要件により、証明書の返却が遅れる場合があります。クエリ保留コントロールを使用すると、クライアントは保留中の認証要求の状態についてサーバーにクエリを実行できます。サーバーは、拡張 CMC ステータス情報および CMC ステータス情報コントロール (otherInfo フィールド) の一部として pendToken を返します。クライアントは、サーバーへの正しい証明書要求を識別するために、pendToken をクエリ保留コントロールにコピーします。サーバーは、クライアントが保留中の認証要求の状態を照会するための推奨時間を返します。
The Query Pending control is identified by the OID:
クエリ保留コントロールは OID によって識別されます。
id-cmc-queryPending OBJECT IDENTIFIER ::= { id-cmc 21 }
The Query Pending control has the ASN.1 definition:
Query Pending コントロールには ASN.1 定義があります。
QueryPending ::= OCTET STRING
If a server returns a pending or partial CMCStatusInfo (the transaction is still pending), the otherInfo MAY be omitted. If the otherInfo is not omitted, the value of pendInfo MUST be the same as the original pendInfo value.
サーバーが保留中または部分的な CMCStatusInfo (トランザクションはまだ保留中) を返す場合、otherInfo は省略してもよい(MAY)。otherInfo が省略されない場合、pendInfo の値は元の pendInfo 値と同じでなければなりません。
Some CAs require that clients give a positive confirmation that the certificates issued to the EE are acceptable. The Confirm Certificate Acceptance control is used for that purpose. If the CMC Status Info on a PKI Response is confirmRequired, then the client MUST return a Confirm Certificate Acceptance control contained in a Full PKI Request.
一部の CA では、EE に発行された証明書が受け入れられることをクライアントが明確に確認することを要求します。この目的のために、「証明書の受け入れの確認」コントロールが使用されます。PKI 応答の CMC ステータス情報がconfirmRequired の場合、クライアントは完全な PKI 要求に含まれる証明書受け入れ確認コントロールを返さなければなりません (MUST)。
Clients SHOULD wait for the PKI Response from the server that the confirmation has been received before using the certificate for any purpose.
クライアントは、証明書を何らかの目的で使用する前に、確認が受信されたというサーバーからの PKI 応答を待つ必要があります (SHOULD)。
The Confirm Certificate Acceptance control is identified by the OID:
証明書の受け入れの確認コントロールは、OID によって識別されます。
id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= { id-cmc 24 }
The Confirm Certificate Acceptance control has the ASN.1 definition:
証明書受け入れの確認コントロールには、ASN.1 定義があります。
CMCCertId ::= IssuerAndSerialNumber
CMCCertId contains the issuer and serial number of the certificate being accepted.
CMCCertId には、受け入れられる証明書の発行者とシリアル番号が含まれます。
Servers MUST return a Full PKI Response for a Confirm Certificate Acceptance control.
サーバーは、証明書受け入れ確認コントロールに対して完全な PKI 応答を返さなければなりません。
Note that if the CA includes this control, there will be two full round trips of messages, as follows:
CA にこのコントロールが含まれている場合、次のようにメッセージが 2 回完全に往復することになることに注意してください。
1. The client sends the certification request to the CA.
1. クライアントは認証リクエストを CA に送信します。
2. The CA returns a Full PKI Response with the certificate and this control.
2. CA は、証明書とこのコントロールを含む完全な PKI 応答を返します。
3. The client sends a Full PKI Request to the CA with an Extended CMC Status Info or a CMC Status Info control accepting and a Confirm Certificate Acceptance control or an Extended CMC Status Info or a CMC Status Info control rejecting the certificate.
3. クライアントは、証明書を受け入れる拡張 CMC ステータス情報または CMC ステータス情報コントロール、および証明書を拒否する証明書受け入れ確認コントロールまたは拡張 CMC ステータス情報または CMC ステータス情報コントロールを含む完全な PKI 要求を CA に送信します。
4. The CA sends a Full PKI Response to the client with an Extended CMC Status Info of success.
4. CA は、成功の拡張 CMC ステータス情報を含む完全な PKI 応答をクライアントに送信します。
The Publish Trust Anchors control allows for the distribution of set trust anchors from a central authority to an EE. The same control is also used to update the set of trust anchors. Trust anchors are distributed in the form of certificates. These are expected, but not required, to be self-signed certificates. Information is extracted from these certificates to set the inputs to the certificates validation algorithm in Section 6.1.1 of [PKIXCERT].
トラスト アンカーの発行コントロールを使用すると、設定されたトラスト アンカーを中央機関から EE に配布できます。同じコントロールは、トラスト アンカーのセットを更新するためにも使用されます。トラスト アンカーは証明書の形式で配布されます。これらは自己署名証明書であることが期待されていますが、必須ではありません。これらの証明書から情報が抽出され、[PKIXCERT] のセクション 6.1.1 の証明書検証アルゴリズムへの入力が設定されます。
The Publish Trust Anchors control is identified by the OID:
トラスト アンカーの発行コントロールは、OID によって識別されます。
id-cmc-trustedAnchors OBJECT IDENTIFIER ::= { id-cmc 26 }
The Publish Trust Anchors control has the ASN.1 definition:
トラスト アンカーの発行コントロールには、ASN.1 定義があります。
PublishTrustAnchors ::= SEQUENCE {
seqNumber INTEGER,
hashAlgorithm AlgorithmIdentifier{DIGEST-ALGORITHM,
{HashAlgorithms}},
anchorHashes SEQUENCE OF OCTET STRING
}
The fields in PublishTrustAnchors have the following meaning:
PublishTrustAnchors のフィールドには次の意味があります。
* seqNumber is an integer indicating the location within a sequence of updates.
* seqNumber は、一連の更新内の位置を示す整数です。
* hashAlgorithm is the identifier and parameters for the hash algorithm that is used in computing the values of the anchorHashes field. All implementations MUST implement SHA-256 for this field.
* hashAlgorithm は、anchorHashes フィールドの値の計算に使用されるハッシュ アルゴリズムの識別子とパラメーターです。すべての実装は、このフィールドに SHA-256 を実装しなければなりません。
* anchorHashes are the hashes for the certificates that are to be treated as trust anchors by the client. The actual certificates are transported in the certificates field of the containing SignedData structure.
* アンカーハッシュは、クライアントによってトラストアンカーとして扱われる証明書のハッシュです。実際の証明書は、含まれている SignedData 構造体の証明書フィールドに転送されます。
While it is recommended that the sender place the certificates that are to be trusted in the PKI Response, it is not required as the certificates should be obtainable using normal discovery techniques.
送信者は信頼される証明書を PKI 応答に含めることをお勧めしますが、証明書は通常の検出技術を使用して取得できる必要があるため、必須ではありません。
Prior to accepting the trust anchor's changes, a client MUST at least do the following: validate the signature on the PKI Response to a current trusted anchor, check with policy to ensure that the signer is permitted to use the control, validate that the authenticated publish time in the signature is near to the current time, and validate that the sequence number is greater than the previously used one.
トラストアンカーの変更を受け入れる前に、クライアントは少なくとも次のことを実行しなければなりません: 現在トラステッドアンカーへの PKI 応答の署名を検証し、ポリシーをチェックして署名者にコントロールの使用が許可されていることを確認し、署名内の認証された公開時刻が現在時刻に近いことを検証し、シーケンス番号が以前に使用されたものより大きいことを検証します。
In the event that multiple agents publish a set of trust anchors, it is up to local policy to determine how the different trust anchors should be combined. Clients SHOULD be able to handle the update of multiple trust anchors independently.
複数のエージェントが一連のトラスト アンカーを公開する場合、異なるトラスト アンカーをどのように組み合わせるかはローカル ポリシーによって決まります。クライアントは、複数のトラスト アンカーの更新を個別に処理できる必要があります (SHOULD)。
Note: Clients that handle this control must use extreme care in validating that the operation is permissible. Incorrect handling of this control allows for an attacker to change the set of trust anchors on the client.
注: このコントロールを処理するクライアントは、操作が許可されるかどうかを検証する際に細心の注意を払う必要があります。このコントロールを正しく処理しないと、攻撃者がクライアント上のトラスト アンカーのセットを変更する可能性があります。
The Authenticated Data control allows a server to provide data back to the client in an authenticated manner. This control uses the Authenticated Data structure to allow for validation of the data. This control is used where the client has a shared-secret and a secret identifier with the server, but where a trust anchor has not yet been downloaded onto the client so that a signing certificate for the server cannot be validated. The specific case that this control was created for use with is the Publish Trust Anchors control (Section 6.15), but it may be used in other cases as well.
認証済みデータ コントロールを使用すると、サーバーは認証された方法でデータをクライアントに返すことができます。このコントロールは、Authenticated Data 構造を使用してデータの検証を可能にします。このコントロールは、クライアントがサーバーとの共有秘密および秘密識別子を持っているが、トラスト アンカーがまだクライアントにダウンロードされていないため、サーバーの署名証明書を検証できない場合に使用されます。このコントロールが使用するために作成された具体的なケースは、Publish Trust Anchors コントロール (セクション 6.15) ですが、他のケースでも使用される可能性があります。
The Authenticated Data control is identified by the OID:
認証済みデータ コントロールは OID によって識別されます。
id-cmc-authData OBJECT IDENTIFIER ::= { id-cmc 27 }
The Authenticated Data control has the ASN.1 definition:
認証済みデータ コントロールには ASN.1 定義があります。
AuthPublish ::= BodyPartID
AuthPublish is a body part identifier that refers to a member of the cmsSequence element for the current PKI Response or PKI Data. The cmsSequence element is AuthenticatedData. The encapsulated content is an id-cct-PKIData. The controls in the controlSequence need to be processed if the authentication succeeds.
AuthPublish は、現在の PKI 応答または PKI データの cmsSequence 要素のメンバーを参照するボディ部分の識別子です。cmsSequence 要素は AuthenticatedData です。カプセル化されたコンテンツは id-cct-PKIData です。認証が成功した場合は、controlSequence 内のコントロールを処理する必要があります。
Note: One example is the Publish Trust Anchors control in Section 6.15.
注: 一例は、セクション 6.15 の「Publish Trust Anchors」コントロールです。
If the authentication operation fails, the CMCFailInfo authDataFail is returned.
認証操作が失敗した場合は、CMCFailInfo authDataFail が返されます。
These controls allow for an RA to collect multiple requests together into a single Full PKI Request and forward it to a CA. The server would then process the requests and return the results in a Full PKI Response.
これらの制御により、RA は複数の要求を 1 つの完全な PKI 要求にまとめて CA に転送できます。その後、サーバーはリクエストを処理し、結果を完全な PKI レスポンスで返します。
The Batch Request control is identified by the OID:
バッチ リクエスト コントロールは OID によって識別されます。
id-cmc-batchRequests OBJECT IDENTIFIER ::= { id-cmc 28 }
The Batch Response control is identified by the OID:
バッチ応答コントロールは OID によって識別されます。
id-cmc-batchResponses OBJECT IDENTIFIER ::= { id-cmc 29 }
Both the Batch Request and Batch Response controls have the ASN.1 definition:
バッチ リクエスト コントロールとバッチ レスポンス コントロールの両方に ASN.1 定義があります。
BodyPartList ::= SEQUENCE OF BodyPartID
The data associated with these controls is a set of body part identifiers. Each request/response is placed as an individual entry in the cmcSequence of the new PKIData/PKIResponse. The body part identifiers of these entries are then placed in the body part list associated with the control.
これらのコントロールに関連付けられたデータは、身体部分の識別子のセットです。各リクエスト/レスポンスは、新しい PKIData/PKIResponse の cmcSequence 内の個別のエントリとして配置されます。これらのエントリのボディパーツ識別子は、コントロールに関連付けられたボディパーツリストに配置されます。
When a server processes a Batch Request control, it MAY return the responses in one or more PKI Responses. A CMCStatus value of partial is returned on all but the last PKI Response. The CMCStatus would be success if the Batch Request control was processed; the responses are created with their own CMCStatus code. Errors on individual requests are not propagated up to the top level.
サーバーがバッチ リクエスト コントロールを処理するとき、サーバーは 1 つ以上の PKI レスポンスで応答を返すことができます (MAY)。部分的な CMCStatus 値は、最後の PKI 応答を除くすべての PKI 応答で返されます。Batch Request コントロールが処理された場合、CMCStatus は成功になります。応答は独自の CMCStatus コードを使用して作成されます。個々のリクエストのエラーは最上位レベルまで伝播されません。
When a PKI Response with a CMCStatus value of partial is returned, the Query Pending control (Section 6.13) is used to retrieve additional results. The returned status includes a suggested time after which the client should ask for the additional results.
CMCStatus 値が部分的な PKI 応答が返された場合、クエリ保留コントロール (セクション 6.13) を使用して追加の結果が取得されます。返されるステータスには、クライアントが追加の結果を要求するまでの推奨時間が含まれています。
The Publication Information control allows for modifying publication of already issued certificates, both for publishing and removal from publication. A common usage for this control is to remove an existing certificate from publication during a rekey operation. This control should always be processed after the issuance of new certificates and revocation requests. This control should not be processed if a certificate failed to be issued.
発行情報コントロールを使用すると、発行済みの証明書の発行と発行からの削除の両方を変更できます。このコントロールの一般的な使用法は、キー再生成操作中に既存の証明書を公開から削除することです。この制御は、新しい証明書の発行および失効要求の後に常に処理される必要があります。証明書の発行に失敗した場合、このコントロールは処理されるべきではありません。
The Publication Information control is identified by the OID:
出版情報コントロールは OID によって識別されます。
id-cmc-publishCert OBJECT IDENTIFIER ::= { id-cmc 30 }
The Publication Information control has the ASN.1 definition:
Publication Information コントロールには ASN.1 定義があります。
CMCPublicationInfo ::= SEQUENCE {
hashAlg AlgorithmIdentifier{DIGEST-ALGORITHM,
{HashAlgorithms}},
certHashes SEQUENCE OF OCTET STRING,
pubInfo PKIPublicationInfo
}
PKIPublicationInfo ::= SEQUENCE {
action INTEGER {
dontPublish (0),
pleasePublish (1) },
pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }
-- pubInfos MUST NOT be present if action is "dontPublish"
-- (if action is "pleasePublish" and pubInfos is omitted,
-- "dontCare" is assumed)
SinglePubInfo ::= SEQUENCE {
pubMethod INTEGER {
dontCare (0),
x500 (1),
web (2),
ldap (3) },
pubLocation GeneralName OPTIONAL }
}
The fields in CMCPublicationInfo have the following meaning:
CMCPublicationInfo のフィールドには次の意味があります。
* hashAlg is the algorithm identifier of the hash algorithm used to compute the values in certHashes.
* hashAlg は、certHash の値を計算するために使用されるハッシュ アルゴリズムのアルゴリズム識別子です。
* certHashes are the hashes of the certificates for which publication is to change.
* certHash は、発行が変更される証明書のハッシュです。
* pubInfo is the information where and how the certificates should be published. The fields in pubInfo (taken from [CRMF][ADD-ASN1]) have the following meanings:
* pubInfo は、証明書をどこでどのように公開する必要があるかという情報です。pubInfo のフィールド ([CRMF][ADD-ASN1] から取得) は次の意味を持ちます。
- action indicates the action the service should take. It has two values:
- action は、サービスが実行する必要があるアクションを示します。これには 2 つの値があります。
o dontPublish indicates that the PKI should not publish the certificate (this may indicate that the requester intends to publish the certificate themselves). dontPublish has the added connotation of removing from publication the certificate if it is already published.
o dontPublish は、PKI が証明書を公開すべきではないことを示します (これは、要求者が証明書を自分で公開するつもりであることを示している可能性があります)。dontPublish には、証明書がすでに公開されている場合にその証明書を公開から削除するという意味合いが追加されています。
o pleasePublish indicates that the PKI MAY publish the certificate using whatever means it chooses unless pubInfos is present. Omission of the CMC Publication Info control results in the same behavior.
o pleasePublish は、pubInfos が存在しない限り、PKI が選択した手段を使用して証明書を公開してもよいことを示します。CMC Publication Info コントロールを省略しても、同じ動作になります。
- pubInfos indicates how (e.g., X.500, Web, IP Address) the PKI SHOULD publish the certificate.
- pubInfos は、PKI が証明書を発行する方法 (X.500、Web、IP アドレスなど) を示します。
A single certificate SHOULD NOT appear in more than one Publication Information control. The behavior is undefined in the event that it does.
単一の証明書が複数の出版情報コントロールに表示されるべきではありません。その場合の動作は未定義です。
The Control Processed control allows an RA to indicate to subsequent control processors that a specific control has already been processed. This permits an RA in the middle of a processing stream to process a control defined either in a local context or in a subsequent document.
Control Processed コントロールを使用すると、RA は、特定のコントロールがすでに処理されていることを後続のコントロール プロセッサに示すことができます。これにより、処理ストリームの途中にある RA が、ローカル コンテキストまたは後続のドキュメントで定義されたコントロールを処理できるようになります。
The Control Processed control is identified by the OID:
処理されたコントロール コントロールは、OID によって識別されます。
id-cmc-controlProcessed OBJECT IDENTIFIER ::= { id-cmc 32 }
The Control Processed control has the ASN.1 definition:
Control Processed コントロールには ASN.1 定義があります。
ControlList ::= SEQUENCE {
bodyList SEQUENCE SIZE (1..MAX) OF BodyPartReference
}
* bodyList is a series of body part identifiers that form a path to each of the controls that were processed by the RA. This control is only needed for those controls that are not part of this standard and thus would cause an error condition of a server attempting to deal with a control not defined in this document. No error status is needed since an error causes the RA to return the request to the client with the error rather than passing the request on to the next server in the processing list.
* bodyList は、RA によって処理された各コントロールへのパスを形成する一連のボディ部分識別子です。このコントロールは、この標準の一部ではないコントロールにのみ必要であるため、このドキュメントで定義されていないコントロールを処理しようとするとサーバーでエラー状態が発生します。エラーが発生すると、RA はリクエストを処理リスト内の次のサーバーに渡すのではなく、エラーを含むクライアントにリクエストを返すため、エラー ステータスは必要ありません。
The RA Identity Proof Witness control allows an RA to indicate to subsequent control processors that all of the Proof-of-Identity requirements have been met. This permits the Proof-of-Identity to be performed at a location closer to the EE. For example, the Proof-of-Identity could be done at multiple physical locations, while the CA could operate on a company-wide basis. The RA performs the Proof-of-Identity, and potentially other tasks that require the secret to be used, while the CA is prevented from knowing the secret. If checks related to Proof-of-Identity fail, then the RA returns an error to the client denoting that fact.
RA Identity Proof Witness コントロールを使用すると、RA は、すべての Proof-of-Identity 要件が満たされていることを後続のコントロール プロセッサに示すことができます。これにより、EE に近い場所で ID 証明を実行できるようになります。たとえば、身元証明は複数の物理的な場所で実行できますが、CA は全社ベースで運用できます。RA は、Proof-of-Identity、および潜在的にシークレットの使用を必要とするその他のタスクを実行しますが、CA はシークレットを知ることができません。Proof-of-Identity に関連するチェックが失敗した場合、RA はその事実を示すエラーをクライアントに返します。
The RA Identity Proof Witness control is identified by the OID:
RA Identity Proof Witness コントロールは、OID によって識別されます。
id-cmc-raIdentityWitness OBJECT IDENTIFIER ::= { id-cmc 35 }
The RA Identity Proof Witness control has the ASN.1 definition:
RA Identity Proof Witness コントロールには、ASN.1 定義があります。
cmc-raIdentityWitness CMC-CONTROL ::=
{ BodyPartPath IDENTIFIED BY id-cmc-raIdentityWitness }
* cmc-raIdentityWitness is a CMC-CONTROL associating the OID id-cmc-raIdentityWitness and the type BodyPartPath. This object is omitted from the 1988 module. The object is added to the object set Cmc-Control-Set. The control is permitted to appear only in the control sequence of a PKIData object. It MUST NOT appear in the control sequence of a PKIResponse. The control is permitted to be used only by an RA. The control may appear multiple times in a control sequence with each occurrence pointing to a different object.
* cmc-raIdentityWitness は、OID id-cmc-raIdentityWitness と BodyPartPath タイプを関連付ける CMC-CONTROL です。このオブジェクトは 1988 モジュールから省略されています。オブジェクトがオブジェクト セット Cmc-Control-Set に追加されます。コントロールは、PKIData オブジェクトのコントロール シーケンス内にのみ出現することが許可されます。PKIResponse の制御シーケンスに含めてはなりません (MUST NOT)。このコントロールは RA のみに使用が許可されます。コントロールはコントロール シーケンス内で複数回出現し、それぞれが異なるオブジェクトを指す場合があります。
* id-cmc-raIdentityWitness is the OID used to identify this CMC control.
* id-cmc-raIdentityWitness は、この CMC コントロールを識別するために使用される OID です。
* BodyPartPath is the type structure associated with the control. The syntax of BodyPartPath is defined in Section 3.2.2. The path contains a sequence of body part identifiers leading to one of the following items:
* BodyPartPath は、コントロールに関連付けられた型構造体です。BodyPartPath の構文はセクション 3.2.2 で定義されています。パスには、次の項目のいずれかにつながる一連のボディパーツ識別子が含まれています。
- Identity Proof control if the RA verified the Proof-of-Identity in this control.
- ID 証明コントロール RA がこのコントロールの ID 証明を検証した場合。
- Identity Proof Version 2 control if the RA verified the Proof-of-Identity in this control.
- ID 証明バージョン 2 コントロール。RA がこのコントロールの ID 証明を検証したかどうか。
- Full PKI Request if the RA performed an out-of-band identity proof for this request. The request SHOULD NOT contain either Identity Proof control.
- RA がこの要求に対して帯域外 ID 証明を実行した場合の完全な PKI 要求。リクエストには、Identity Proof コントロールが含まれていてはなりません (SHOULD NOT)。
- Simple PKI Request if the RA performed an out-of-band identity proof for this request.
- 単純な PKI 要求 (RA がこの要求に対して帯域外 ID 証明を実行した場合)。
The RA Identity Proof Witness control will frequently be associated with a Modify Certification Request control, which changes the name fields in the associated certification requests. This is because the RA knows the actual name to be assigned to the entity requesting the certificate, and the EE does not yet have the details of the name.
RA Identity Proof Witness コントロールは、多くの場合、Modify Certification Request コントロールと関連付けられ、関連する証明書リクエストの名前フィールドが変更されます。これは、RA は証明書を要求しているエンティティに割り当てられる実際の名前を知っていますが、EE は名前の詳細をまだ持っていないためです。
Note: The association would be set up by the operator at the time the shared-secret was generated by the RA.
注: この関連付けは、共有秘密が RA によって生成されたときにオペレーターによってセットアップされます。
When this control is placed in a message, it is RECOMMENDED that the Control Processed control be placed in the body sequence as well. Using the explicit new control rather than implicitly relying on the Control Processed control is important due to the need to know explicitly which Proof-of-Identity have been performed. The new control also allows an RA to state that out-of-band Proof-of-Identity have been performed.
このコントロールをメッセージに配置する場合、Control Processed コントロールも本文シーケンスに配置することが推奨されます。どの Proof-of-Identity が実行されたかを明示的に知る必要があるため、Control Processed コントロールに暗黙的に依存するのではなく、明示的に新しいコントロールを使用することが重要です。新しい制御により、RA は帯域外の ID 証明が実行されたことを宣言することもできます。
When the Proof-of-Identity is performed by an RA, the RA also MUST validate the linking between the Proof-of-Identity and the name information wrapped inside of the key proof-of-possession.
Proof-of-Identity が RA によって実行される場合、RA はまた、Proof-of-Identity とキーの所有証明内にラップされている名前情報の間のリンクを検証しなければなりません (MUST)。
The Response Body control is designed to enable an RA to inform an EE that there is an embedded response message that MUST be processed as part of the processing of this message. This control is designed to be used in a couple of different cases where an RA has done some additional processing for the certification request, e.g., as key generation. When an RA performs key generation on behalf of an EE, the RA MUST respond with both the original response message from the certificate issuer (containing the certificate issuance) as part of the response generated by the RA (containing the new key). Another case where this is useful is when the secret is shared between the RA and the EE (rather than between the CA and the EE) and the RA returns the Publish Trust Anchors control (to populate the correct trust points).
Response Body コントロールは、RA が EE に、このメッセージの処理の一部として処理しなければならない埋め込み応答メッセージがあることを通知できるように設計されています。この制御は、RA が認証要求に対して追加の処理 (鍵生成など) を実行したいくつかの異なるケースで使用されるように設計されています。RA が EE に代わって鍵生成を実行する場合、RA は、証明書発行者からの元の応答メッセージ (証明書の発行を含む) と、RA によって生成された応答 (新しい鍵を含む) の一部として応答しなければなりません (MUST)。これが役立つもう 1 つのケースは、シークレットが (CA と EE 間ではなく) RA と EE 間で共有され、RA が (正しいトラスト ポイントを設定するため) Publish Trust Anchors コントロールを返す場合です。
The Response Body control is identified by the OID:
レスポンスボディコントロールは OID によって識別されます。
id-cmc-responseBody OBJECT IDENTIFIER ::= { id-cmc 37 }
The Response Body control has the ASN.1 definition:
レスポンス ボディ コントロールには ASN.1 定義があります。
cmc-responseBody CMC-CONTROL ::=
{ BodyPartPath IDENTIFIED BY id-cmc-responseBody }
* cmc-responseBody is a CMC-CONTROL associating the OID id-cmc-responseBody with the type BodyPartPath. This object is omitted from the 1988 module. The object is added to the object set Cmc-Control-Set. The control is permitted to appear only in the control sequence of a PKIResponse. The control MUST NOT appear in the control sequence of a PKIData. It is expected that only an intermediary RA will use this control; a CA generally does not need the control as it is creating the original innermost message.
* cmc-responseBody は、OID id-cmc-responseBody を BodyPartPath タイプに関連付ける CMC-CONTROL です。このオブジェクトは 1988 モジュールから省略されています。オブジェクトがオブジェクト セット Cmc-Control-Set に追加されます。コントロールは、PKIResponse のコントロール シーケンス内にのみ出現することが許可されます。コントロールは、PKIData のコントロール シーケンスに現れてはなりません (MUST NOT)。中間の RA のみがこのコントロールを使用することが期待されます。CA は通常、元の最も内側のメッセージを作成しているため、コントロールを必要としません。
* id-cmc-responseBody is the OID used to identify this CMC control.
* id-cmc-responseBody は、この CMC コントロールを識別するために使用される OID です。
* BodyPartPath is the type structure associated with the control. The syntax of BodyPartPath is defined in Section 3.2.2. The path contains a sequence of body part identifiers leading to a cmsSequence item, which contains a PKIResponse within it.
* BodyPartPath は、コントロールに関連付けられた型構造体です。BodyPartPath の構文はセクション 3.2.2 で定義されています。パスには、cmsSequence 項目につながる一連のボディ部分識別子が含まれており、その中に PKIResponse が含まれています。
There are a number of different locations where various types of attributes can be placed in either a CMC request or a CMC response message. These places include the attribute sequence of a PKCS #10 request, controls in Section 6 of [CRMF], and the various CMS attribute sequences.
CMC 要求または CMC 応答メッセージには、さまざまなタイプの属性を配置できるさまざまな場所が多数あります。これらの場所には、PKCS #10 リクエストの属性シーケンス、[CRMF] のセクション 6 のコントロール、およびさまざまな CMS 属性シーケンスが含まれます。
The Client Name Change Request attribute is designed for a client to ask for a change in its name as part of a certification request. Because of security issues, this cannot be done in the simple way of just changing the requested subject's name in the certificate template. The name in the certification request MUST match the name in the certificate used to verify the request, in order for identity and possession proofs to be correctly applied.
クライアント名変更要求属性は、クライアントが認証要求の一部として名前の変更を要求できるように設計されています。セキュリティの問題のため、これは、証明書テンプレートで要求されたサブジェクトの名前を変更するだけの単純な方法では実行できません。ID および所有証明が正しく適用されるためには、認証リクエスト内の名前が、リクエストの検証に使用される証明書内の名前と一致しなければなりません。
The relevant ASN.1 for the Client Name Change Request attribute is as follows:
クライアント名変更要求属性に関連する ASN.1 は次のとおりです。
at-cmc-changeSubjectName ATTRIBUTE ::= {
TYPE ChangeSubjectName IDENTIFIED BY id-cmc-changeSubjectName }
id-cmc-changeSubjectName OBJECT IDENTIFIER ::= { id-cmc 36 }
ChangeSubjectName ::= SEQUENCE {
subject Name OPTIONAL,
subjectAlt [1] GeneralNames OPTIONAL
}
(WITH COMPONENTS {..., subject PRESENT} |
WITH COMPONENTS {..., subjectAlt PRESENT} )
The attribute is designed to be used as an ATTRIBUTE object. As such, the attribute is placed in one of the following two places:
この属性は、ATTRIBUTE オブジェクトとして使用されるように設計されています。したがって、属性は次の 2 つの場所のいずれかに配置されます。
* The attributes field in a CertificationRequest.
* CertificationRequest の属性フィールド。
* The controls field of a CertRequest for a CRMF.
* CRMF の CertRequest のコントロール フィールド。
The control is identified by the OID id-cmc-changeSubjectName.
コントロールは、OID id-cmc-changeSubjectName によって識別されます。
The ASN.1 type associated with control is ChangeSubjectName. The fields of the structure are configured as follows:
コントロールに関連付けられた ASN.1 タイプは ChangeSubjectName です。構造体のフィールドは次のように構成されます。
* subject contains the requested subject name for the new certificate.
* subject には、新しい証明書に対して要求されたサブジェクト名が含まれます。
* subjectAlt contains the requested subject alternative name for the new certificate.
* subjectAlt には、新しい証明書に対して要求されたサブジェクトの代替名が含まれます。
At least one of the fields in the sequence MUST be present when encoding the structure.
構造をエンコードするときは、シーケンス内のフィールドの少なくとも 1 つが存在しなければなりません。
When the CA processes this attribute in a certification request, it will do the following:
CA は、証明書リクエスト内のこの属性を処理するときに、次のことを行います。
1. If present, the subject field is copied to the name field of the template. If the subject field is absent, the name field of the template will be set to an empty sequence.
1. 存在する場合、件名フィールドはテンプレートの名前フィールドにコピーされます。件名フィールドが存在しない場合、テンプレートの名前フィールドは空のシーケンスに設定されます。
2. If present, the subjectAlt field is used as the content of a Subject Alternative Name extension in the certificate. If the subjectAlt field is absent, the Subject Alternative Name extension is removed from the certificate template.
2. subjectAlt フィールドが存在する場合、証明書内のサブジェクト代替名拡張のコンテンツとして使用されます。 subjectAlt フィールドが存在しない場合、サブジェクト代替名拡張子は証明書テンプレートから削除されます。
This specification permits the use of RAs. An RA sits between the EE and the CA. From the EE's perspective, the RA appears to be the CA, and from the server, the RA appears to be a client. RAs receive the PKI Requests, perform local processing and then forward them to CAs. Some of the types of local processing that an RA can perform include:
この仕様により、RA の使用が許可されます。RA は EE と CA の間に位置します。EE の観点からは、RA は CA のように見え、サーバーからは RA はクライアントのように見えます。RA は PKI リクエストを受信し、ローカル処理を実行してから CA に転送します。RA が実行できるローカル処理のタイプには次のようなものがあります。
* Batching multiple PKI Requests together,
* 複数の PKI リクエストをまとめてバッチ処理し、
* Performing challenge/response POP proofs,
* チャレンジ/レスポンスPOPプルーフの実行、
* Adding private or standardized certificate extensions to all certification requests,
* すべての証明書リクエストにプライベートまたは標準化された証明書拡張機能を追加します。
* Archiving private key material,
* 秘密鍵マテリアルのアーカイブ、
* Routing requests to different CAs.
* リクエストを異なる CA にルーティングします。
When an RA receives a PKI Request, it has three options: it may forward the PKI Request without modification, it may add a new wrapping layer to the PKI Request, or it may remove one or more existing layers and add a new wrapping layer.
RA が PKI リクエストを受信すると、RA には 3 つのオプションがあります。変更せずに PKI リクエストを転送するか、PKI リクエストに新しいラッピング層を追加するか、1 つ以上の既存の層を削除して新しいラッピング層を追加することができます。
When an RA adds a new wrapping layer to a PKI Request, it creates a new PKIData. The new layer contains any controls required (for example, if the RA does the POP proof for an encryption key or the Add Extension control to modify a PKI Request) and the client PKI Request. The client PKI Request is placed in the cmsSequence if it is a Full PKI Request and in the reqSequence if it is a Simple PKI Request. If an RA is batching multiple client PKI Requests together, then each client PKI Request is placed into the appropriate location in the RA's PKIData object along with all relevant controls.
RA が新しいラッピング レイヤを PKI リクエストに追加すると、新しい PKIData が作成されます。新しい層には、必要なコントロール (たとえば、RA が暗号化キーの POP 証明を行う場合や、PKI リクエストを変更する拡張機能の追加コントロールを行う場合) とクライアント PKI リクエストが含まれます。クライアント PKI リクエストは、フル PKI リクエストの場合は cmsSequence に配置され、シンプル PKI リクエストの場合は reqSequence に配置されます。RA が複数のクライアント PKI 要求をまとめてバッチ処理している場合、各クライアント PKI 要求は、関連するすべてのコントロールとともに RA の PKIData オブジェクト内の適切な場所に配置されます。
If multiple RAs are in the path between the EE and the CA, this will lead to multiple wrapping layers on the request.
EE と CA の間のパスに複数の RA がある場合、リクエストに複数のラッピング層が発生します。
In processing a PKI Request, an RA MUST NOT alter any certification requests (PKCS #10 or CRMF) as any alteration would invalidate the signature on the certification request and thus the POP for the private key.
PKI リクエストを処理する際、RA は認証リクエスト (PKCS #10 または CRMF) を変更してはなりません。変更すると、認証リクエストの署名が無効になり、秘密鍵の POP が無効になるためです。
An example of how this would look is illustrated by the following figure:
これがどのようになるかの例を次の図に示します。
SignedData (by RA)
PKIData
controlSequence
RA added control statements
reqSequence
Zero or more Simple PKI Requests from clients
cmsSequence
Zero or more Full PKI Requests from clients
SignedData (signed by client)
PKIData
Under some circumstances, an RA is required to remove wrapping layers. The following sections look at the processing required if encryption, signing, and authenticated encryption layers need to be removed.
状況によっては、ラッピング層を削除するために RA が必要になる場合があります。次のセクションでは、暗号化、署名、認証された暗号化層を削除する必要がある場合に必要な処理について説明します。
There are two cases that require an RA to remove or change encryption in a PKI Request; both cases are true regardless of whether EnvelopedData or AuthEnvelopedData is used. In the first case, the encryption was applied for the purposes of protecting the entire PKI Request from unauthorized entities. If the CA does not have a RecipientInfo entry in the encryption layer, the RA MUST remove the encryption layer. The RA MAY add a new encryption layer with or without adding a new signing layer.
RA が PKI リクエストの暗号化を削除または変更する必要があるケースは 2 つあります。EnvelopedData と AuthEnvelopedData のどちらが使用されるかに関係なく、どちらの場合も当てはまります。最初のケースでは、PKI リクエスト全体を無許可のエンティティから保護する目的で暗号化が適用されました。CA が暗号化層に RecipientInfo エントリを持たない場合、RA は暗号化層を削除しなければなりません (MUST)。RA は、新しい署名層の追加の有無にかかわらず、新しい暗号化層を追加してもよい(MAY)。
The second change of encryption that may be required is to change the encryption inside of a signing layer. In this case, the RA MUST remove all signing layers containing the encryption. All control statements MUST be merged according to local policy rules as each signing layer is removed and the resulting merged controls MUST be placed in a new signing layer provided by the RA. If the signing layer provided by the EE needs to also be removed, the RA can also remove this layer.
必要となる可能性のある暗号化の 2 番目の変更は、署名層内の暗号化を変更することです。この場合、RA は暗号化を含むすべての署名層を削除しなければなりません (MUST)。すべての制御ステートメントは、各署名層が削除されるときにローカル ポリシー ルールに従ってマージされなければならず (MUST)、結果としてマージされたコントロールは、RA によって提供される新しい署名層に配置されなければなりません (MUST)。EE によって提供された署名層も削除する必要がある場合、RA はこの層も削除できます。
Only two instances exist where an RA should remove a signature layer on a Full PKI Request: if an encryption layer needs to be modified within the request or if a CA will not accept secondary delegation (i.e., multiple RA signatures). In all other situations, RAs SHOULD NOT remove a signing layer from a PKI Request.
RA がフル PKI リクエストの署名層を削除する必要があるインスタンスは 2 つだけ存在します。リクエスト内で暗号化層を変更する必要がある場合、または CA が二次委任 (つまり、複数の RA 署名) を受け入れない場合です。それ以外のすべての状況では、RA は PKI リクエストから署名層を削除してはなりません (SHOULD NOT)。
If an RA removes a signing layer from a PKI Request, all control statements MUST be merged according to local policy rules. The resulting merged control statements MUST be placed in a new signing layer provided by the RA.
RA が PKI リクエストから署名層を削除する場合、すべての制御ステートメントはローカル ポリシー ルールに従ってマージされなければなりません (MUST)。結果としてマージされた制御ステートメントは、RA によって提供される新しい署名層に配置されなければなりません (MUST)。
Certificates for servers used in the CMC protocol SHOULD conform to the profile defined in [PKIXCERT]. This document defines some additional items that MAY appear in CMC server certificates. Section 9.1 defines some additional values for the EKU extension. Section 9.2 defines a Subject Information Access value that allows for a CMC certificate to publish information on how to contact the services it provides.
CMC プロトコルで使用されるサーバーの証明書は、[PKIXCERT] で定義されたプロファイルに準拠する必要があります (SHOULD)。この文書では、CMC サーバー証明書に表示される可能性があるいくつかの追加項目を定義します。セクション 9.1 では、EKU 拡張機能の追加の値をいくつか定義します。セクション 9.2 では、CMC 証明書が提供するサービスへの接続方法に関する情報を公開できるようにするサブジェクト情報アクセス値を定義します。
The EKU extension is used to restrict the use of a certificate to specific applications. We define three different EKUs in this document. The ASN.1 to define these EKUs is:
EKU 拡張機能は、証明書の使用を特定のアプリケーションに制限するために使用されます。このドキュメントでは 3 つの異なる EKU を定義します。これらの EKU を定義する ASN.1 は次のとおりです。
id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 }
id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 }
id-kp-cmcArchive OBJECT IDENTIFIER ::= { id-kp 29 }
The usage description for each of the EKUs is as follows:
各 EKU の使用法の説明は次のとおりです。
* CMC CAs are identified by the id-kp-cmcCA EKU. The certificate may be the same as or different than the CA certificate. If a different certificate is used, the certificates containing the id-kp-cmcCA EKU SHOULD have the same name as the certificate used for issuing the certificates. (Using a separate key pair for CMC protocol operations and for issuing certificates and CRLs decreases the number of operations for which the private key used to sign certificates and CRLs would be used.)
* CMC CA は id-kp-cmcCA EKU によって識別されます。証明書は CA 証明書と同じである場合もあれば、異なる場合もあります。別の証明書が使用される場合、id-kp-cmcCA EKU を含む証明書は、証明書の発行に使用された証明書と同じ名前を持つ必要があります。(CMC プロトコル操作と証明書と CRL の発行に別のキー ペアを使用すると、証明書と CRL の署名に使用される秘密キーが使用される操作の数が減ります。)
* CMC Registration Authorities are identified by the id-kp-cmcRA EKU. This usage is placed into RA certificates.
* CMC 登録機関は、id-kp-cmcRA EKU によって識別されます。この使用法は RA 証明書に組み込まれます。
* CMC Archive Servers are identified by the id-kp-cmcArchive EKU. CMC Archive Servers and the associated protocol are to be defined in a future document.
* CMC アーカイブ サーバーは、id-kp-cmcArchive EKU によって識別されます。CMC アーカイブ サーバーと関連プロトコルは、将来のドキュメントで定義される予定です。
The Subject Information Access extension indicates how to access information and services for the subject of the certificate. This document defines a value for use in this extension, to identify the different locations that CMC services will be available. If this value is placed in a certificate, an appropriate EKU defined in Section 9.1 MUST be included in the certificate as well.
Subject Information Access 拡張機能は、証明書のサブジェクトの情報とサービスにアクセスする方法を示します。このドキュメントでは、CMC サービスが利用できるさまざまな場所を識別するために、この拡張機能で使用する値を定義します。この値が証明書に含まれる場合、セクション 9.1 で定義された適切な EKU も証明書に含める必要があります。
The id-ad-cmc OID is used when the subject offers certification services using the CMC protocol. If the CMC services are available via HTTP or FTP (see Section 2 of [CMC-TRANS] and Section 4 of [CMC-TRANS]), accessLocation MUST be a uniformResourceIdentifier. If the CMC services are available via electronic mail (see Section 3 of [CMC-TRANS]), accessLocation MUST be an rfc822Name. If CMC services are available using TCP/IP (see Section 5 of [CMC-TRANS]), the dNSName or iPAddress name forms MUST be used. Since the GeneralName data structure does not permit the inclusion of a port number, in the absence of other external configuration information, the value of 5318 should be used. (The port registration is in Section 7 of [CMC-TRANS].) The semantics of other name forms of accessLocation (when accessMethod is id-ad-cmc) are not defined by this specification.
id-ad-cmc OID は、サブジェクトが CMC プロトコルを使用して証明書サービスを提供する場合に使用されます。CMC サービスが HTTP または FTP 経由で利用できる場合 ([CMC-TRANS] のセクション 2 および [CMC-TRANS] のセクション 4 を参照)、accessLocation はuniformResourceIdentifier でなければなりません。CMC サービスが電子メール経由で利用できる場合 ([CMC-TRANS] のセクション 3 を参照)、accessLocation は rfc822Name でなければなりません。CMC サービスが TCP/IP を使用して利用できる場合 ([CMC-TRANS] のセクション 5 を参照)、dNSName または iPAddress の名前形式を使用しなければなりません (MUST)。GeneralName データ構造ではポート番号を含めることができないため、他の外部構成情報がない場合は、値 5318 を使用する必要があります。(ポートの登録は [CMC-TRANS] のセクション 7 にあります。) accessLocation の他の名前形式 (accessMethod が id-ad-cmc の場合) のセマンティクスは、この仕様では定義されていません。
The ASN.1 type for this extension is GeneralName (see Section 4.2.1.8 of [PKIXCERT]).
この拡張の ASN.1 タイプは GeneralName です ([PKIXCERT] のセクション 4.2.1.8 を参照)。
id-ad-cmc OBJECT IDENTIFIER ::= { id-ad 12 }
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 Sender Nonce and Recipient Nonce controls described in Section 6.6. Developers of state-constrained PKI clients are strongly encouraged to incorporate the use of these controls.
運用環境に応じて、このプロトコルの特定の実装では、リプレイ攻撃を阻止するためのメカニズムが必要になる場合があります。CA が重要な状態情報を保持している場合、オプションの nonce メカニズムを含めなくてもリプレイ攻撃が検出できる可能性があります。このプロトコルの実装者は、セクション 6.6 で説明されている送信者ノンスおよび受信者ノンス制御を実装するかどうかを選択する前に、環境条件を慎重に検討する必要があります。状態に制約のある PKI クライアントの開発者は、これらのコントロールの使用を組み込むことを強くお勧めします。
Extreme care needs to be taken when archiving a signing key. The holder of the archived key may have the ability to use the key to generate forged signatures. There are however reasons why a signing key should be archived. An archived CA signing key can be recovered in the event of failure to continue to produce CRLs following a disaster.
署名キーをアーカイブする場合は、細心の注意を払う必要があります。アーカイブされたキーの所有者は、そのキーを使用して偽造署名を生成できる可能性があります。ただし、署名キーをアーカイブする必要があるのには理由があります。アーカイブされた CA 署名キーは、災害後に CRL の生成を継続できなくなった場合に復元できます。
Due care must be taken prior to archiving keys. Once a key is given to an archiving entity, the archiving entity could use the keys in a way not conducive to the archiving entity. Users should be made especially aware that proper verification is made of the certificate used to encrypt the private key material.
キーをアーカイブする前に十分な注意を払う必要があります。キーがアーカイブ エンティティに与えられると、アーカイブ エンティティは、アーカイブ エンティティに不利な方法でキーを使用する可能性があります。ユーザーは、秘密キー素材の暗号化に使用される証明書が適切に検証されていることを特に認識する必要があります。
Clients and servers need to do some checks on cryptographic parameters prior to issuing certificates to make sure that weak parameters are not used. A description of the small subgroup attack is provided in [X942]. Methods of avoiding the small subgroup attack can be found in [SMALL-GROUP]. CMC implementations ought to be aware of this attack when doing parameter validations.
クライアントとサーバーは、証明書を発行する前に、暗号パラメータに対していくつかのチェックを行い、弱いパラメータが使用されていないことを確認する必要があります。小規模サブグループ攻撃の説明は [X942] に記載されています。小サブグループ攻撃を回避する方法は [SMALL-GROUP] にあります。CMC 実装は、パラメータ検証を行うときにこの攻撃を認識する必要があります。
When using a shared-secret for authentication purposes, the shared-secret should be generated using good random number techniques [RANDOM]. User selection of the secret allows for dictionary attacks to be mounted.
認証目的で共有秘密を使用する場合、共有秘密は適切な乱数技術 [RANDOM] を使用して生成される必要があります。ユーザーがシークレットを選択すると、辞書攻撃を仕掛けることができます。
Extreme care must be used when processing the Publish Trust Anchors control. Incorrect processing can lead to the practice of slamming where an attacker changes the set of trusted anchors in order to weaken security.
Publish Trust Anchors コントロールを処理するときは、細心の注意を払う必要があります。処理が正しくないと、攻撃者がセキュリティを弱めるために信頼できるアンカーのセットを変更するスラム攻撃が行われる可能性があります。
One method of controlling the use of the Publish Trust Anchors control is as follows. The client needs to associate with each trust anchor accepted by the client the source of the trust anchor. Additionally, the client should associate with each trust anchor the types of messages for which the trust anchor is valid (i.e., is the trust anchor used for validating S/MIME messages, TLS, or CMC enrollment messages?).
Publish Trust Anchors コントロールの使用を制御する 1 つの方法は次のとおりです。クライアントは、クライアントが受け入れた各トラスト アンカーと、トラスト アンカーのソースを関連付ける必要があります。さらに、クライアントは、トラスト アンカーが有効なメッセージのタイプ (つまり、トラスト アンカーは S/MIME メッセージ、TLS、または CMC 登録メッセージの検証に使用されますか?) を各トラスト アンカーに関連付ける必要があります。
When a new message is received with a Publish Trust Anchors control, the client would accept the set of new trust anchors for specific applications only if the signature validates, the signer of the message has the required policy approval for updating the trust anchors, and local policy also would allow updating the trust anchors.
トラスト アンカーの発行コントロールで新しいメッセージを受信すると、クライアントは、署名が検証され、メッセージの署名者がトラスト アンカーの更新に必要なポリシーの承認を持っており、ローカル ポリシーでもトラスト アンカーの更新が許可されている場合にのみ、特定のアプリケーションの新しいトラスト アンカーのセットを受け入れます。
The CMS AuthenticatedData structure provides message integrity; it does not provide message authentication in all cases. When using MACs, in this document, the following restrictions need to be observed. All messages should be for a single entity. If two entities are placed in a single message, the entities can generate new messages that have a valid MAC and might be assumed to be from the original message sender. All entities that have access to the shared-secret can generate messages that will have a successful MAC validation. This means that care must be taken to keep this value secret. Whenever possible, the SignedData structure should be used in preference to the AuthenticatedData structure.
CMS AuthenticatedData 構造はメッセージの整合性を提供します。すべての場合にメッセージ認証が提供されるわけではありません。本書では、MAC を使用する場合、次の制限事項を遵守する必要があります。すべてのメッセージは単一のエンティティ宛てである必要があります。2 つのエンティティが 1 つのメッセージに配置されている場合、エンティティは有効な MAC を持ち、元のメッセージ送信者からのものであると想定される新しいメッセージを生成できます。共有秘密にアクセスできるすべてのエンティティは、MAC 検証が成功するメッセージを生成できます。これは、この値を秘密に保つように注意する必要があることを意味します。可能な限り、AuthenticatedData 構造よりも SignedData 構造を優先して使用する必要があります。
A number of controls, such as the RA Identity Proof Witness control, exist for an RA to either make assertions about or modify a certification request. Any upstream request processor, such as a CA, MUST verify that the RA is fully identified and authorized to make the assertion or modification it is claiming. If it is not identified or authorized, then any request MUST be rejected.
RA Identity Proof Witness コントロールなど、RA が認証要求についてアサーションを行ったり、認証要求を変更したりするための多くのコントロールが存在します。CA などの上流のリクエストプロセッサは、RA が完全に識別され、主張しているアサーションまたは変更を行う権限があることを検証しなければなりません (MUST)。識別または許可されていない場合、リクエストはすべて拒否されなければなりません。
CMC servers, both RAs and CAs, need to perform due diligence in checking the contents of a certification request. At an absolute minimum, all fields should be checked to ensure that the policies of the CA/RA are correctly enforced. While all fields need to be checked, special care should be taken with names, name forms, algorithm choices, and algorithm parameters.
CMC サーバーは、RA と CA の両方で、証明書リクエストの内容を確認する際にデューデリジェンスを実行する必要があります。少なくとも、CA/RA のポリシーが正しく適用されていることを確認するために、すべてのフィールドをチェックする必要があります。すべてのフィールドをチェックする必要がありますが、名前、名前の形式、アルゴリズムの選択、およびアルゴリズムのパラメーターには特別な注意を払う必要があります。
The vulnerability noted in [Str23] is mitigated in Full PKI Requests and Responses because signed attributes are always present and id-data is always used with a media type. The vulnerability noted in [Str23] is not applicable to Simple PKI Requests or Responses because there is no content encryption applied.
[Str23] で指摘されている脆弱性は、署名付き属性が常に存在し、id-data が常にメディア タイプで使用されるため、完全な PKI リクエストとレスポンスでは軽減されます。[Str23] で指摘されている脆弱性は、コンテンツ暗号化が適用されていないため、Simple PKI リクエストまたはレスポンスには適用されません。
This document defines a number of CMC-related control objects, ASN.1 modules, extended key purposes, and content types. All are identified by OIDs. The OIDs are defined from an arc delegated by IANA to the PKIX Working Group with the notable exception of one S/ MIME attribute. All registrations follow.
この文書は、多数の CMC 関連の制御オブジェクト、ASN.1 モジュール、拡張キーの目的、およびコンテンツ タイプを定義します。すべては OID によって識別されます。OID は、1 つの S/MIME 属性を除いて、IANA によって PKIX ワーキング グループに委任されたアークから定義されます。すべての登録は次のとおりです。
For the ASN.1 modules in Appendix A, IANA has assigned an OID for the module identifier 124 with a Description of "id-mod-enrollMsgSyntax-2025" in Appendix A.1 and an OID for the module identifier 125 with a Description of "id-mod-pbkdf2-prfs-2025" in Appendix A.2. The OIDs for the modules should be allocated in the "SMI Security for PKIX Module Identifier" registry [PKIX-MODIDS].
付録 A の ASN.1 モジュールについて、IANA は、付録 A.1 の「id-mod-enrollMsgSyntax-2025」の説明を持つモジュール識別子 124 の OID と、付録 A.2 の「id-mod-pbkdf2-prfs-2025」の説明を持つモジュール識別子 125 の OID を割り当てました。モジュールの OID は、「PKIX モジュール識別子の SMI セキュリティ」レジストリ [PKIX-MODIDS] に割り当てられる必要があります。
IANA has replaced the references for the following S/MIME attributes found in the "SMI Security for S/MIME Attributes" registry [SMIME-ATTRS] with a pointer to this document:
IANA は、「SMI Security for S/MIME Attributes」レジストリ [SMIME-ATTRS] にある次の S/MIME 属性の参照を、この文書へのポインタに置き換えました。
* id-aa-cmc-unsignedData
* id-aa-cmc-unsignedData
IANA has replaced the references for the following key purposes found in the "SMI Security for PKIX Extended Key Purpose" registry [PKIX-EKPS] with a pointer to this document:
IANA は、「PKIX 拡張キー目的の SMI セキュリティ」レジストリ [PKIX-EKPS] にある以下の主要な目的の参照を、この文書へのポインタに置き換えました。
* id-kp-cmcCA
* id-kp-cmcCA
* id-kp-cmcRA
* id-kp-cmcRA
* id-kp-cmcArchive
* id-kp-cmcアーカイブ
IANA has replaced the references for the following signature algorithm found in the "SMI Security for PKIX Algorithms" registry [IANA-PKIX-ALGS] with a pointer to this document:
IANA は、「SMI Security for PKIX Algorithms」レジストリ [IANA-PKIX-ALGS] にある次の署名アルゴリズムの参照を、この文書へのポインタに置き換えました。
* id-alg-noSignature
* id-alg-noSignature
IANA has replaced the references for the following CMC controls found in the "SMI Security for PKIX CMC Controls" registry [CMC-CTRLS] with a pointer to this document:
IANA は、「SMI Security for PKIX CMC Controls」レジストリ [CMC-CTRLS] にある次の CMC コントロールの参照を、この文書へのポインタに置き換えました。
* id-cmc-statusInfo
* id-cmc-status情報
* id-cmc-identification
* id-cmc-識別
* id-cmc-identityProof
* id-cmc-identityProof
* id-cmc-dataReturn
* id-cmc-dataReturn
* id-cmc-transactionId
* id-cmc-transactionId
* id-cmc-senderNonce
* id-cmc-senderNonce
* id-cmc-recipientNonce
* id-cmc-recipientNonce
* id-cmc-addExtensions
* id-cmc-addExtensions
* id-cmc-encryptedPOP
* id-cmc-encryptedPOP
* id-cmc-decryptedPOP
* id-cmc-decryptedPOP
* id-cmc-lraPOPWitness
* id-cmc-lraPOPWitness
* id-cmc-getCert
* id-cmc-getCert
* id-cmc-getCRL
* id-cmc-getCRL
* id-cmc-revokeRequest
* id-cmc-revokeRequest
* id-cmc-regInfo
* id-cmc-regInfo
* id-cmc-responseInfo
* id-cmc-responseInfo
* id-cmc-queryPending
* id-cmc-query保留中
* id-cmc-popLinkRandom
* id-cmc-popリンクランダム
* id-cmc-popLinkWitness
* id-cmc-popLinkWitness
* id-cmc-confirmCertAcceptance
* id-cmc-confirmCertAcceptance
* id-cmc-statusInfoV2
* id-cmc-statusInfoV2
* id-cmc-trustedAnchors
* id-cmc-trustedAnchors
* id-cmc-authData
* id-cmc-authデータ
* id-cmc-batchRequests
* id-cmc-batchRequests
* id-cmc-batchResponses
* id-cmc-batchResponses
* id-cmc-publishCert
* id-cmc-publishCert
* id-cmc-modCertTemplate
* id-cmc-modCertTemplate
* id-cmc-controlProcessed
* id-cmc-control処理済み
* id-cmc-popLinkWitnessV2
* id-cmc-popLinkWitnessV2
* id-cmc-identityProofV2
* id-cmc-identityProofV2
* id-cmc-raIdentityWitness
* id-cmc-raIdentityWitness
* id-cmc-changeSubjectName
* id-cmc-change件名名
* id-cmc-responseBody
* id-cmc-responseBody
IANA has replaced the references for the following CMC content types found in the "SMI Security for PKIX CMC Content Types" registry [CMC-CTS] with a pointer to this document:
IANA は、「SMI Security for PKIX CMC Content Types」レジストリ [CMC-CTS] にある次の CMC コンテンツ タイプの参照を、このドキュメントへのポインタに置き換えました。
* id-cct-PKIData
* id-cct-PKIデータ
* id-cct-PKIResponse
* id-cct-PKI応答
IANA has replaced the references for the following PKIX access descriptor found in the "SMI Security for PKIX Access Descriptor" registry [PKIX-ADS] with a pointer to this document:
IANA は、「SMI Security for PKIX Access Descriptor」レジストリ [PKIX-ADS] にある次の PKIX アクセス記述子の参照を、この文書へのポインタに置き換えました。
* id-ad-cmc
* id-ad-cmc
IANA is to note that the references for the following module OIDs in the "SMI Security for PKIX Module Identifier" registry [PKIX-MODIDS] are to remain unchanged as these modules remain unchanged by this specification:
IANA は、「SMI Security for PKIX Module Identifier」レジストリ [PKIX-MODIDS] 内の以下のモジュール OID の参照は、これらのモジュールがこの仕様によって変更されないままであるため、変更されないことに注意します。
* id-mod-cmc
* id-mod-cmc
* id-mod-cmc2002
* id-mod-cmc2002
* id-mod-enrollMsgSyntax-2011-88
* id-mod-enrollMsgSyntax-2011-88
* id-mod-enrollMsgSyntax-2011-08
* id-mod-enrollMsgSyntax-2011-08
Likewise, the id-cmc-glaRR entry in the "SMI Security for PKIX CMC Controls" registry and all entries in the "SMI Security for PKIX CMC Controls" and "SMI Security for PKIX CMC GLA Requests and Responses" registries are to remain unchanged.
同様に、「SMI Security for PKIX CMC Controls」レジストリの id-cmc-glaRR エントリと、「SMI Security for PKIX CMC Controls」および「SMI Security for PKIX CMC GLA Requests and Responses」レジストリのすべてのエントリは変更されません。
[ADD-ASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
DOI 10.17487/RFC5912, June 2010,
<https://www.rfc-editor.org/info/rfc5912>.
[ASN.1] ITU-T, "Information technology -- Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,
<https://www.itu.int/rec/T-REC-X.680>.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.
[CMS-AE] Housley, R., "Cryptographic Message Syntax (CMS)
Authenticated-Enveloped-Data Content Type", RFC 5083,
DOI 10.17487/RFC5083, November 2007,
<https://www.rfc-editor.org/info/rfc5083>.
[CMS-ALGS] Hoffman, P. and J. Schaad, "New ASN.1 Modules for
Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,
DOI 10.17487/RFC5911, June 2010,
<https://www.rfc-editor.org/info/rfc5911>.
[CRMF] Schaad, J., "Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)", RFC 4211,
DOI 10.17487/RFC4211, September 2005,
<https://www.rfc-editor.org/info/rfc4211>.
[DH-POP] Schaad, J. and H. Prafullchandra, "Diffie-Hellman Proof-
of-Possession Algorithms", RFC 6955, DOI 10.17487/RFC6955,
May 2013, <https://www.rfc-editor.org/info/rfc6955>.
[HMAC-ALGS]
Schaad, J. and S. Turner, "Additional New ASN.1 Modules
for the Cryptographic Message Syntax (CMS) and the Public
Key Infrastructure Using X.509 (PKIX)", RFC 6268,
DOI 10.17487/RFC6268, July 2011,
<https://www.rfc-editor.org/info/rfc6268>.
[PKCS10] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/info/rfc2986>.
[PKIXCERT] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[CMC-COMPL]
Mandel, J., Ed. and S. Turner, Ed., "Certificate
Management over CMS (CMC): Compliance Requirements",
RFC 10004, DOI 10.17487/RFC10004, July 2026,
<https://www.rfc-editor.org/info/rfc10004>.
[CMC-CTRLS]
IANA, "SMI Security for PKIX CMC Controls",
<https://www.iana.org/assignments/smi-numbers/>.
[CMC-CTS] IANA, "SMI Security for PKIX CMC Content Types",
<https://www.iana.org/assignments/smi-numbers/>.
[CMC-PROTv1]
Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
<https://www.rfc-editor.org/info/rfc5272>.
[CMC-TRANS]
Mandel, J., Ed. and S. Turner, Ed., "Certificate
Management over CMS (CMC): Transport Protocols",
RFC 10003, DOI 10.17487/RFC10003, July 2026,
<https://www.rfc-editor.org/info/rfc10003>.
[CMC-Updates]
Schaad, J., "Certificate Management over CMS (CMC)
Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011,
<https://www.rfc-editor.org/info/rfc6402>.
[CMS-KEM] Housley, R., Gray, J., and T. Okubo, "Using Key
Encapsulation Mechanism (KEM) Algorithms in the
Cryptographic Message Syntax (CMS)", RFC 9629,
DOI 10.17487/RFC9629, August 2024,
<https://www.rfc-editor.org/info/rfc9629>.
[Err2063] RFC Errata, Erratum 2063, RFC 5272,
<https://www.rfc-editor.org/errata/eid2063>.
[Err2731] RFC Errata, Erratum 2731, RFC 5272,
<https://www.rfc-editor.org/errata/eid2731>.
[Err3943] RFC Errata, Erratum 3943, RFC 6402,
<https://www.rfc-editor.org/errata/eid3943>.
[Err4775] RFC Errata, Erratum 4775, RFC 5272,
<https://www.rfc-editor.org/errata/eid4775>.
[Err5931] RFC Errata, Erratum 5931, RFC 6402,
<https://www.rfc-editor.org/errata/eid5931>.
[Err6571] RFC Errata, Erratum 6571, RFC 6402,
<https://www.rfc-editor.org/errata/eid6571>.
[Err7379] RFC Errata, Erratum 7379, RFC 5272,
<https://www.rfc-editor.org/errata/eid7379>.
[Err7627] RFC Errata, Erratum 7627, RFC 5272,
<https://www.rfc-editor.org/errata/eid7627>.
[Err7628] RFC Errata, Erratum 7628, RFC 5272,
<https://www.rfc-editor.org/errata/eid7628>.
[Err7629] RFC Errata, Erratum 7629, RFC 5272,
<https://www.rfc-editor.org/errata/eid7629>.
[Err8027] RFC Errata, Erratum 8027, RFC 5272,
<https://www.rfc-editor.org/errata/eid8027>.
[Err8137] RFC Errata, Erratum 8137, RFC 5272,
<https://www.rfc-editor.org/errata/eid8137>.
[Err8385] RFC Errata, Erratum 8385, RFC 6402,
<https://www.rfc-editor.org/errata/eid8385>.
[IANA-PKIX-ALGS]
IANA, "SMI Security for PKIX Algorithms",
<https://www.iana.org/assignments/smi-numbers/>.
[PASSWORD] Temoshok, D., Proud-Madruga, D., Choong, Y., Galluzzo, R.,
Gupta, S., LaSalle, C., Lefkovitz, N., and A. Regenscheid,
"Digital Identity Guidelines", National Institute of
Standards and Technology, NIST SP 800-63-4,
DOI 10.6028/nist.sp.800-63-4, June 2025,
<https://doi.org/10.6028/nist.sp.800-63-4>.
[PKIX-ADS] IANA, "SMI Security for PKIX Access Descriptor",
<https://www.iana.org/assignments/smi-numbers/>.
[PKIX-EKPS]
IANA, "SMI Security for PKIX Extended Key Purpose",
<https://www.iana.org/assignments/smi-numbers/>.
[PKIX-MODIDS]
IANA, "SMI Security for PKIX Module Identifier",
<https://www.iana.org/assignments/smi-numbers/>.
[RANDOM] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC2797] Myers, M., Liu, X., Schaad, J., and J. Weinstein,
"Certificate Management Messages over CMS", RFC 2797,
DOI 10.17487/RFC2797, April 2000,
<https://www.rfc-editor.org/info/rfc2797>.
[SMALL-GROUP]
Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
Attacks on the Diffie-Hellman Key Agreement Method for S/
MIME", RFC 2785, DOI 10.17487/RFC2785, March 2000,
<https://www.rfc-editor.org/info/rfc2785>.
[SMIME-ATTRS]
IANA, "SMI Security for S/MIME Attributes
(1.2.840.113549.1.9.16.2)",
<https://www.iana.org/assignments/smi-numbers/>.
[Str23] Strenzke, F., "ForgedAttributes: An Existential Forgery
Vulnerability of CMS Signatures", Cryptology ePrint
Archive, Paper 2023/1801, 22 November 2023,
<https://ia.cr/2023/1801>.
[X942] Rescorla, E., "Diffie-Hellman Key Agreement Method",
RFC 2631, DOI 10.17487/RFC2631, June 1999,
<https://www.rfc-editor.org/info/rfc2631>.
EnrollmentMessageSyntax-2025
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-enrollMsgSyntax-2025(124) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
EXPORTS ALL;
IMPORTS
AttributeSet{}, Extension{}, EXTENSION, ATTRIBUTE
FROM PKIX-CommonTypes-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) }
AlgorithmIdentifier{}, DIGEST-ALGORITHM, KEY-WRAP, KEY-DERIVATION,
MAC-ALGORITHM, SIGNATURE-ALGORITHM, PUBLIC-KEY
FROM AlgorithmInformation-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) }
CertificateSerialNumber, GeneralName, CRLReason, ReasonFlags,
CertExtensions, GeneralNames
FROM PKIX1Implicit-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-implicit-02(59) }
Name, id-pkix, PublicKeyAlgorithms, SignatureAlgorithms, id-ad,
id-kp
FROM PKIX1Explicit-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51) }
ContentInfo, IssuerAndSerialNumber, CONTENT-TYPE
FROM CryptographicMessageSyntax-2010
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) }
CertReqMsg, PKIPublicationInfo, CertTemplate
FROM PKIXCRMF-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-crmf2005-02(55) }
mda-sha1
FROM PKIXAlgs-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-algorithms2008-02(56) }
maca-hMAC-SHA1
FROM CryptographicMessageSyntaxAlgorithms-2009
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) id-mod-cmsalg-2001-02(37) }
mda-sha256
FROM PKIX1-PSS-OAEP-Algorithms-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-rsa-pkalgs-02(54) }
maca-hMAC-SHA256
FROM HMAC-2010
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) mod(0) id-mod-hmac(74) }
kda-PBKDF2
FROM PBKDF2-PRFs-2025
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0)
id-mod-pbkdf2-prfs-2025(125) } ;
-- CMS content types defined in this document
CMC-ContentTypes CONTENT-TYPE ::= {
ct-PKIData | ct-PKIResponse, ... }
-- Signature Algorithms defined in this document
SignatureAlgs SIGNATURE-ALGORITHM ::= { sa-noSignature }
-- CMS Unsigned Attributes
CMC-UnsignedAtts ATTRIBUTE ::= { aa-cmc-unsignedData }
id-cmc OBJECT IDENTIFIER ::= { id-pkix 7 } -- CMC controls
id-cct OBJECT IDENTIFIER ::= { id-pkix 12 } -- CMC content types
-- This is the content type for a request message in the protocol
ct-PKIData CONTENT-TYPE ::=
{ TYPE PKIData IDENTIFIED BY id-cct-PKIData }
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
}
BodyPartID ::= INTEGER(0..4294967295)
TaggedAttribute ::= SEQUENCE {
bodyPartID BodyPartID,
attrType CMC-CONTROL.&id({Cmc-Control-Set}),
attrValues SET OF CMC-CONTROL.
&Type({Cmc-Control-Set}{@attrType})
}
Cmc-Control-Set CMC-CONTROL ::= {
cmc-identityProof | cmc-dataReturn | cmc-regInfo |
cmc-responseInfo | cmc-queryPending | cmc-popLinkRandom |
cmc-popLinkWitness | cmc-identification | cmc-transactionId |
cmc-senderNonce | cmc-recipientNonce | cmc-statusInfo |
cmc-addExtensions | cmc-encryptedPOP | cmc-decryptedPOP |
cmc-lraPOPWitness | cmc-getCert | cmc-getCRL |
cmc-revokeRequest | cmc-confirmCertAcceptance |
cmc-statusInfoV2 | cmc-trustedAnchors | cmc-authData |
cmc-batchRequests | cmc-batchResponses | cmc-publishCert |
cmc-modCertTemplate | cmc-controlProcessed |
cmc-identityProofV2 | cmc-popLinkWitnessV2 |
cmc-raIdentityWitness | cmc-responseBody, ... }
OTHER-REQUEST ::= TYPE-IDENTIFIER
-- We do not define any other requests in this document.
-- Examples might be attribute certification requests.
OtherRequests OTHER-REQUEST ::= {...}
TaggedRequest ::= CHOICE {
tcr [0] TaggedCertificationRequest,
crm [1] CertReqMsg,
orm [2] SEQUENCE {
bodyPartID BodyPartID,
requestMessageType OTHER-REQUEST.&id({OtherRequests}),
requestMessageValue OTHER-REQUEST.&Type({OtherRequests}
{@.requestMessageType})
}
}
TaggedCertificationRequest ::= SEQUENCE {
bodyPartID BodyPartID,
certificationRequest CertificationRequest
}
AttributeList ATTRIBUTE ::= {
at-extension-req | at-cmc-changeSubjectName, ... }
CertificationRequest ::= SEQUENCE {
certificationRequestInfo SEQUENCE {
version INTEGER,
subject Name,
subjectPublicKeyInfo SEQUENCE {
algorithm AlgorithmIdentifier{PUBLIC-KEY,
{PublicKeyAlgorithms}},
subjectPublicKey BIT STRING
},
attributes [0] IMPLICIT SET OF
AttributeSet{{AttributeList}}
},
signatureAlgorithm AlgorithmIdentifier
{SIGNATURE-ALGORITHM,
{SignatureAlgorithms}},
signature BIT STRING
}
TaggedContentInfo ::= SEQUENCE {
bodyPartID BodyPartID,
contentInfo ContentInfo
}
OTHER-MSG ::= TYPE-IDENTIFIER
-- No other messages currently defined
OtherMsgSet OTHER-MSG ::= {...}
OtherMsg ::= SEQUENCE {
bodyPartID BodyPartID,
otherMsgType OTHER-MSG.&id({OtherMsgSet}),
otherMsgValue OTHER-MSG.&Type({OtherMsgSet}{@otherMsgType}) }
-- This defines the response message in the protocol
ct-PKIResponse CONTENT-TYPE ::=
{ TYPE PKIResponse IDENTIFIED BY id-cct-PKIResponse }
id-cct-PKIResponse OBJECT IDENTIFIER ::= { id-cct 3 }
ResponseBody ::= PKIResponse
PKIResponse ::= SEQUENCE {
controlSequence SEQUENCE SIZE (0..MAX) OF TaggedAttribute,
cmsSequence SEQUENCE SIZE (0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE (0..MAX) OF OtherMsg
}
CMC-CONTROL ::= TYPE-IDENTIFIER
-- The following controls have the type OCTET STRING
cmc-identityProof CMC-CONTROL ::=
{ OCTET STRING IDENTIFIED BY id-cmc-identityProof }
id-cmc-identityProof OBJECT IDENTIFIER ::= { id-cmc 3 }
cmc-dataReturn CMC-CONTROL ::=
{ OCTET STRING IDENTIFIED BY id-cmc-dataReturn }
id-cmc-dataReturn OBJECT IDENTIFIER ::= { id-cmc 4 }
cmc-regInfo CMC-CONTROL ::=
{ OCTET STRING IDENTIFIED BY id-cmc-regInfo }
id-cmc-regInfo OBJECT IDENTIFIER ::= { id-cmc 18 }
cmc-responseInfo CMC-CONTROL ::=
{ OCTET STRING IDENTIFIED BY id-cmc-responseInfo }
id-cmc-responseInfo OBJECT IDENTIFIER ::= { id-cmc 19 }
cmc-queryPending CMC-CONTROL ::=
{ OCTET STRING IDENTIFIED BY id-cmc-queryPending }
id-cmc-queryPending OBJECT IDENTIFIER ::= { id-cmc 21 }
cmc-popLinkRandom CMC-CONTROL ::=
{ OCTET STRING IDENTIFIED BY id-cmc-popLinkRandom }
id-cmc-popLinkRandom OBJECT IDENTIFIER ::= { id-cmc 22 }
cmc-popLinkWitness CMC-CONTROL ::=
{ OCTET STRING IDENTIFIED BY id-cmc-popLinkWitness }
id-cmc-popLinkWitness OBJECT IDENTIFIER ::= { id-cmc 23 }
-- The following controls have the type UTF8String
cmc-identification CMC-CONTROL ::=
{ UTF8String IDENTIFIED BY id-cmc-identification }
id-cmc-identification OBJECT IDENTIFIER ::= { id-cmc 2 }
-- The following controls have the type INTEGER
cmc-transactionId CMC-CONTROL ::=
{ INTEGER IDENTIFIED BY id-cmc-transactionId }
id-cmc-transactionId OBJECT IDENTIFIER ::= { id-cmc 5 }
-- The following controls have the type OCTET STRING
cmc-senderNonce CMC-CONTROL ::=
{ OCTET STRING IDENTIFIED BY id-cmc-senderNonce }
id-cmc-senderNonce OBJECT IDENTIFIER ::= { id-cmc 6 }
cmc-recipientNonce CMC-CONTROL ::=
{ OCTET STRING IDENTIFIED BY id-cmc-recipientNonce }
id-cmc-recipientNonce OBJECT IDENTIFIER ::= { id-cmc 7 }
-- Used to return status in a response
cmc-statusInfo CMC-CONTROL ::=
{ CMCStatusInfo IDENTIFIED BY id-cmc-statusInfo }
id-cmc-statusInfo OBJECT IDENTIFIER ::= { id-cmc 1 }
CMCStatusInfo ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF BodyPartID,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo
} OPTIONAL
}
PendInfo ::= SEQUENCE {
pendToken OCTET STRING,
pendTime GeneralizedTime
}
CMCStatus ::= INTEGER {
success (0),
failed (2),
pending (3),
noSupport (4),
confirmRequired (5),
popRequired (6),
partial (7)
}
CMCFailInfo ::= INTEGER {
badAlg (0),
badMessageCheck (1),
badRequest (2),
badTime (3),
badCertId (4),
unsuportedExt (5),
mustArchiveKeys (6),
badIdentity (7),
popRequired (8),
popFailed (9),
noKeyReuse (10),
internalCAError (11),
tryLater (12),
authDataFail (13)
}
-- Used for RAs to add extensions to certification requests
cmc-addExtensions CMC-CONTROL ::=
{ AddExtensions IDENTIFIED BY id-cmc-addExtensions }
id-cmc-addExtensions OBJECT IDENTIFIER ::= { id-cmc 8 }
AddExtensions ::= SEQUENCE {
pkiDataReference BodyPartID,
certReferences SEQUENCE OF BodyPartID,
extensions SEQUENCE OF Extension{{CertExtensions}}
}
cmc-encryptedPOP CMC-CONTROL ::=
{ EncryptedPOP IDENTIFIED BY id-cmc-encryptedPOP }
cmc-decryptedPOP CMC-CONTROL ::=
{ DecryptedPOP IDENTIFIED BY id-cmc-decryptedPOP }
id-cmc-encryptedPOP OBJECT IDENTIFIER ::= { id-cmc 9 }
id-cmc-decryptedPOP OBJECT IDENTIFIER ::= { id-cmc 10 }
EncryptedPOP ::= SEQUENCE {
request TaggedRequest,
cms ContentInfo,
thePOPAlgID AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}},
witnessAlgID AlgorithmIdentifier{DIGEST-ALGORITHM,
{WitnessAlgs}},
witness OCTET STRING
}
POPAlgs MAC-ALGORITHM ::= {
maca-hMAC-SHA1 | maca-hMAC-SHA256, ... }
WitnessAlgs DIGEST-ALGORITHM ::= { mda-sha1 | mda-sha256, ... }
DecryptedPOP ::= SEQUENCE {
bodyPartID BodyPartID,
thePOPAlgID AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}},
thePOP OCTET STRING
}
cmc-lraPOPWitness CMC-CONTROL ::=
{ LraPopWitness IDENTIFIED BY id-cmc-lraPOPWitness }
id-cmc-lraPOPWitness OBJECT IDENTIFIER ::= { id-cmc 11 }
LraPopWitness ::= SEQUENCE {
pkiDataBodyid BodyPartID,
bodyIds SEQUENCE OF BodyPartID
}
cmc-getCert CMC-CONTROL ::=
{ GetCert IDENTIFIED BY id-cmc-getCert }
id-cmc-getCert OBJECT IDENTIFIER ::= { id-cmc 15 }
GetCert ::= SEQUENCE {
issuerName GeneralName,
serialNumber INTEGER }
cmc-getCRL CMC-CONTROL ::=
{ GetCRL IDENTIFIED BY id-cmc-getCRL }
id-cmc-getCRL OBJECT IDENTIFIER ::= { id-cmc 16 }
GetCRL ::= SEQUENCE {
issuerName Name,
cRLName GeneralName OPTIONAL,
time GeneralizedTime OPTIONAL,
reasons ReasonFlags OPTIONAL }
cmc-revokeRequest CMC-CONTROL ::=
{ RevokeRequest IDENTIFIED BY id-cmc-revokeRequest }
id-cmc-revokeRequest OBJECT IDENTIFIER ::= { id-cmc 17 }
RevokeRequest ::= SEQUENCE {
issuerName Name,
serialNumber INTEGER,
reason CRLReason,
invalidityDate GeneralizedTime OPTIONAL,
passphrase OCTET STRING OPTIONAL,
comment UTF8String OPTIONAL }
cmc-confirmCertAcceptance CMC-CONTROL ::=
{ CMCCertId IDENTIFIED BY id-cmc-confirmCertAcceptance }
id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= { id-cmc 24 }
CMCCertId ::= IssuerAndSerialNumber
-- The following is used to request V3 extensions be added
-- to a certificate
at-extension-req ATTRIBUTE ::= {
TYPE ExtensionReq IDENTIFIED BY id-ExtensionReq }
id-ExtensionReq OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 14 }
ExtensionReq ::= SEQUENCE SIZE (1..MAX) OF
Extension{{CertExtensions}}
-- The following allows Diffie-Hellman Certification Request
-- Messages to be well-formed
sa-noSignature SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-noSignature
VALUE NoSignatureValue
PARAMS TYPE NULL ARE required
HASHES { mda-sha1 }
}
id-alg-noSignature OBJECT IDENTIFIER ::= { id-pkix id-alg(6) 2 }
NoSignatureValue ::= OCTET STRING
-- Unauthenticated attribute to carry removable data.
id-aa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) }
aa-cmc-unsignedData ATTRIBUTE ::= {
TYPE CMCUnsignedData IDENTIFIED BY id-aa-cmc-unsignedData }
id-aa-cmc-unsignedData OBJECT IDENTIFIER ::= { id-aa 34 }
CMCUnsignedData ::= SEQUENCE {
bodyPartPath BodyPartPath,
identifier TYPE-IDENTIFIER.&id,
content TYPE-IDENTIFIER.&Type
}
-- Replaces CMC Status Info
--
cmc-statusInfoV2 CMC-CONTROL ::=
{ CMCStatusInfoV2 IDENTIFIED BY id-cmc-statusInfoV2 }
id-cmc-statusInfoV2 OBJECT IDENTIFIER ::= { id-cmc 25 }
EXTENDED-FAILURE-INFO ::= TYPE-IDENTIFIER
ExtendedFailures EXTENDED-FAILURE-INFO ::= {...}
CMCStatusInfoV2 ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF
BodyPartReference,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo,
extendedFailInfo [1] SEQUENCE {
failInfoOID TYPE-IDENTIFIER.&id
({ExtendedFailures}),
failInfoValue TYPE-IDENTIFIER.&Type
({ExtendedFailures}
{@.failInfoOID})
}
} OPTIONAL
}
BodyPartReference ::= CHOICE {
bodyPartID BodyPartID,
bodyPartPath BodyPartPath
}
BodyPartPath ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
-- Allow for distribution of trust anchors
cmc-trustedAnchors CMC-CONTROL ::=
{ PublishTrustAnchors IDENTIFIED BY id-cmc-trustedAnchors }
id-cmc-trustedAnchors OBJECT IDENTIFIER ::= { id-cmc 26 }
PublishTrustAnchors ::= SEQUENCE {
seqNumber INTEGER,
hashAlgorithm AlgorithmIdentifier{DIGEST-ALGORITHM,
{HashAlgorithms}},
anchorHashes SEQUENCE OF OCTET STRING
}
HashAlgorithms DIGEST-ALGORITHM ::= {
mda-sha1 | mda-sha256, ...
}
cmc-authData CMC-CONTROL ::=
{ AuthPublish IDENTIFIED BY id-cmc-authData }
id-cmc-authData OBJECT IDENTIFIER ::= { id-cmc 27 }
AuthPublish ::= BodyPartID
-- These two items use BodyPartList
cmc-batchRequests CMC-CONTROL ::=
{ BodyPartList IDENTIFIED BY id-cmc-batchRequests }
id-cmc-batchRequests OBJECT IDENTIFIER ::= { id-cmc 28 }
cmc-batchResponses CMC-CONTROL ::=
{ BodyPartList IDENTIFIED BY id-cmc-batchResponses }
id-cmc-batchResponses OBJECT IDENTIFIER ::= { id-cmc 29 }
BodyPartList ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
cmc-publishCert CMC-CONTROL ::=
{ CMCPublicationInfo IDENTIFIED BY id-cmc-publishCert }
id-cmc-publishCert OBJECT IDENTIFIER ::= { id-cmc 30 }
CMCPublicationInfo ::= SEQUENCE {
hashAlg AlgorithmIdentifier{DIGEST-ALGORITHM,
{HashAlgorithms}},
certHashes SEQUENCE OF OCTET STRING,
pubInfo PKIPublicationInfo
}
cmc-modCertTemplate CMC-CONTROL ::=
{ ModCertTemplate IDENTIFIED BY id-cmc-modCertTemplate }
id-cmc-modCertTemplate OBJECT IDENTIFIER ::= { id-cmc 31 }
ModCertTemplate ::= SEQUENCE {
pkiDataReference BodyPartPath,
certReferences BodyPartList,
replace BOOLEAN DEFAULT TRUE,
certTemplate CertTemplate
}
-- Inform follow-on servers that one or more controls have
-- already been processed
cmc-controlProcessed CMC-CONTROL ::=
{ ControlsProcessed IDENTIFIED BY id-cmc-controlProcessed }
id-cmc-controlProcessed OBJECT IDENTIFIER ::= { id-cmc 32 }
ControlsProcessed ::= SEQUENCE {
bodyList SEQUENCE SIZE (1..MAX) OF BodyPartReference
}
-- Identity Proof control w/ algorithm agility
cmc-identityProofV2 CMC-CONTROL ::=
{ IdentityProofV2 IDENTIFIED BY id-cmc-identityProofV2 }
id-cmc-identityProofV2 OBJECT IDENTIFIER ::= { id-cmc 34 }
IdentityProofV2 ::= SEQUENCE {
proofAlgID AlgorithmIdentifier{DIGEST-ALGORITHM,
{WitnessAlgs}},
macAlgId AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}},
witness OCTET STRING
}
cmc-popLinkWitnessV2 CMC-CONTROL ::=
{ PopLinkWitnessV2 IDENTIFIED BY id-cmc-popLinkWitnessV2 }
id-cmc-popLinkWitnessV2 OBJECT IDENTIFIER ::= { id-cmc 33 }
PopLinkWitnessV2 ::= SEQUENCE {
keyGenAlgorithm AlgorithmIdentifier{KEY-DERIVATION,
{KeyDevAlgs}},
macAlgorithm AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}},
witness OCTET STRING
}
KeyDevAlgs KEY-DERIVATION ::= { kda-PBKDF2, ... }
cmc-raIdentityWitness CMC-CONTROL ::=
{ BodyPartPath IDENTIFIED BY id-cmc-raIdentityWitness }
id-cmc-raIdentityWitness OBJECT IDENTIFIER ::= {id-cmc 35}
--
-- Allow for an End-Entity to request a change in name.
-- This item is added to RegControlSet in CRMF.
--
at-cmc-changeSubjectName ATTRIBUTE ::= {
TYPE ChangeSubjectName IDENTIFIED BY id-cmc-changeSubjectName }
id-cmc-changeSubjectName OBJECT IDENTIFIER ::= { id-cmc 36 }
ChangeSubjectName ::= SEQUENCE {
subject Name OPTIONAL,
subjectAlt [1] GeneralNames OPTIONAL
}
(WITH COMPONENTS {..., subject PRESENT} |
WITH COMPONENTS {..., subjectAlt PRESENT} )
--
-- Embedded response from a third party for processing
--
cmc-responseBody CMC-CONTROL ::=
{ BodyPartPath IDENTIFIED BY id-cmc-responseBody }
id-cmc-responseBody OBJECT IDENTIFIER ::= { id-cmc 37 }
--
-- Key purpose identifiers are in the Extended Key Usage extension
--
id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 }
id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 }
id-kp-cmcArchive OBJECT IDENTIFIER ::= { id-kp 29 }
--
-- Subject Information Access identifier
--
id-ad-cmc OBJECT IDENTIFIER ::= { id-ad 12 }
END
PBKDF2-PRFs-2025
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) id-mod-pbkdf2-prfs-2025(125) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN
IMPORTS
ALGORITHM, AlgorithmIdentifier{}, KEY-DERIVATION
FROM AlgorithmInformation-2009 -- From [PKIX-ALGS]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) }
hMAC-SHA1, alg-hMAC-SHA1, id-PBKDF2
FROM CryptographicMessageSyntaxAlgorithms-2009 -- From [CMS-ALGS]
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) id-mod-cmsalg-2001-02(37) }
id-hmacWithSHA224, id-hmacWithSHA256,
id-hmacWithSHA384, id-hmacWithSHA512
FROM HMAC-2010 -- From [HMAC-ALGS]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) mod(0) id-mod-hmac(74) } ;
-- Base OID for algorithms --
rsadsi OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) }
digestAlgorithm OBJECT IDENTIFIER ::= { rsadsi 2 }
id-hmacWithSHA512-224 OBJECT IDENTIFIER ::= { digestAlgorithm 12 }
id-hmacWithSHA512-256 OBJECT IDENTIFIER ::= { digestAlgorithm 13 }
-- PBKDF2-PRFs --
PBKDF2-PRFs ALGORITHM ::= {
alg-hMAC-SHA1 |
alg-hMAC-SHA224 | alg-hMAC-SHA256 |
alg-hMAC-SHA384 | alg-hMAC-SHA512 |
alg-hMAC-SHA512-224 | alg-hMAC-SHA512-256, ... }
PBKDF2-PRFsAlgorithmIdentifier ::=
AlgorithmIdentifier{ ALGORITHM, {PBKDF2-PRFs} }
alg-hMAC-SHA224 ALGORITHM ::= { IDENTIFIER
id-hmacWithSHA224 PARAMS TYPE NULL ARE preferredAbsent }
alg-hMAC-SHA256 ALGORITHM ::= { IDENTIFIER
id-hmacWithSHA256 PARAMS TYPE NULL ARE preferredAbsent }
alg-hMAC-SHA384 ALGORITHM ::= { IDENTIFIER
id-hmacWithSHA384 PARAMS TYPE NULL ARE preferredAbsent }
alg-hMAC-SHA512 ALGORITHM ::= { IDENTIFIER
id-hmacWithSHA512 PARAMS TYPE NULL ARE preferredAbsent }
alg-hMAC-SHA512-224 ALGORITHM ::= { IDENTIFIER
id-hmacWithSHA512-224 PARAMS TYPE NULL ARE preferredAbsent }
alg-hMAC-SHA512-256 ALGORITHM ::= { IDENTIFIER
id-hmacWithSHA512-256 PARAMS TYPE NULL ARE preferredAbsent }
-- PBKDF2-SaltSources --
PBKDF2-SaltSources ALGORITHM ::= { ... }
PBKDF2-SaltSourcesAlgorithmIdentifier ::=
AlgorithmIdentifier {ALGORITHM, {PBKDF2-SaltSources} }
-- PBKDF2-params --
PBKDF2-params ::= SEQUENCE {
salt CHOICE {
specified OCTET STRING,
otherSource PBKDF2-SaltSourcesAlgorithmIdentifier },
iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL,
prf PBKDF2-PRFsAlgorithmIdentifier DEFAULT defaultPBKDF2 }
defaultPBKDF2 PBKDF2-PRFsAlgorithmIdentifier ::=
{ algorithm alg-hMAC-SHA1.&id, parameters NULL:NULL }
-- Key Derivation Algorithms --
KeyDerivationAlgs KEY-DERIVATION ::= { kda-PBKDF2, ... }
kda-PBKDF2 KEY-DERIVATION ::= {
IDENTIFIER id-PBKDF2
PARAMS TYPE PBKDF2-params ARE required
-- No S/MIME caps defined
}
END
This section is informational. The purpose of this section is to present, in an abstracted version, the messages that would flow between the client and server for several different common cases.
このセクションは情報提供です。このセクションの目的は、いくつかの異なる一般的なケースでクライアントとサーバーの間を流れるメッセージを抽象化したバージョンで示すことです。
This section looks at the messages that would flow in the event that an enrollment is occurring for a signing-only key. If the certificate was designed for both signing and encryption, the only difference would be the key usage extension in the certification request.
このセクションでは、署名専用キーの登録が行われる場合に流れるメッセージについて説明します。証明書が署名と暗号化の両方を目的として設計されている場合、唯一の違いは、証明書リクエストのキー使用拡張子です。
Message from client to server:
クライアントからサーバーへのメッセージ:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-cct-PKIData
eContent
controlSequence
{102, id-cmc-identityProof, computed value}
{103, id-cmc-senderNonce, 10001}
reqSequence
crm
certReq
certReqId = 201
certTemplate
subject = My Proposed DN
publicKey = My Public Key
extensions
{id-ce-subjectKeyIdentifier, 1000}
{id-ce-keyUsage, digitalSignature}
SignedData.SignerInfos
SignerInfo
sid.subjectKeyIdentifier = 1000
Response from server to client:
サーバーからクライアントへの応答:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-cct-PKIResponse
eContent
controlSequence
{102, id-cmc-statusInfoV2, {success, 201}}
{103, id-cmc-senderNonce, 10005}
{104, id-cmc-recipientNonce, 10001}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
This section looks at the messages that would flow in the event that an enrollment has one RA in the middle of the data flow. That RA will modify the certification request before passing it on to the CA.
このセクションでは、登録のデータ フローの途中に 1 つの RA がある場合に流れるメッセージについて説明します。その RA は、認証要求を CA に渡す前に変更します。
Message from client to RA:
クライアントから RA へのメッセージ:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-cct-PKIData
eContent
controlSequence
{102, id-cmc-identityProof, computed value}
{103, id-cmc-senderNonce, 10001}
reqSequence
crm
certReq
certReqId = 201
certTemplate
subject = My Proposed DN
publicKey = My Public Key
extensions
{id-ce-subjectKeyIdentifier, 1000}
{id-ce-keyUsage, digitalSignature}
SignedData.SignerInfos
SignerInfo
sid.subjectKeyIdentifier = 1000
Message from RA to CA:
RA から CA へのメッセージ:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-cct-PKIData
eContent
controlSequence
{ 102, id-cmc-batchRequests, { 1, 2} }
{ 103, id-cmc-addExtensions,
{ {1, 201, {id-ce-certificatePolicies, anyPolicy}}
{1, 201, {id-ce-subjectAltName, {extension data}}
{2, XXX, {id-ce-subjectAltName, {extension data}}}
The Value XXX is not known here; it would
reference into the second client request,
which is not displayed above.
cmsSequence
{ 1, <Message from client to RA #1> }
{ 2, <Message from client to RA #2> }
SignedData.SignerInfos
SignerInfo
sid = RA key.
Response from CA to RA:
CA から RA への応答:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-cct-PKIResponse
eContent
controlSequence
{102, id-cmc-batchResponses, {999, 998}}
{103, id-cmc-statusInfoV2, {failed, 2, badIdentity}}
cmsSequence
{ bodyPartID = 999
contentInfo
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-cct-PKIResponse
eContent
controlSequence
{102, id-cmc-statusInfoV2, {success, 201}}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
}
{ bodyPartID = 998,
contentInfo
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-cct-PKIResponse
eContent
controlSequence
{102, id-cmc-statusInfoV2, {failure, badAlg}}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
}
SignedData.SignerInfos
Signed by CA
Response from RA to client:
RA からクライアントへの応答:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-cct-PKIResponse
eContent
controlSequence
{102, id-cmc-statusInfoV2, {success, 201}}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
This section looks at the messages that would flow in the event that an enrollment is done for an encryption-only certificate using a direct POP method; an example message follows. For simplicity, it is assumed that the certification requester already has a signature certificate. This example uses EnvelopedData; however, either EnvelopedData or AuthEnvelopedData can be used.
このセクションでは、直接 POP 方式を使用して暗号化専用証明書の登録が行われた場合に流れるメッセージについて説明します。メッセージの例を次に示します。簡単にするために、認証要求者はすでに署名証明書を持っていると仮定します。この例では EnvelopedData を使用します。ただし、EnvelopedData または AuthEnvelopedData のいずれかを使用できます。
Message #1 from client to server:
クライアントからサーバーへのメッセージ #1:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-cct-PKIData
eContent
controlSequence
{102, id-cmc-transactionId, 10132985123483401}
{103, id-cmc-senderNonce, 10001}
{104, id-cmc-dataReturn, <packet of binary data
identifying where the key
in question is.>}
reqSequence
crm
certReq
certReqId = 201
certTemplate
subject = <My DN>
publicKey = My Public Key
extensions
{id-ce-keyUsage, keyEncipherment}
{id-ce-subjectPublicKeyIdentifier, 1000}
popo
keyEncipherment
subsequentMessage = challengeResp
SignedData.SignerInfos
SignerInfo
Signed by requester's signing cert
Response #1 from server to client:
サーバーからクライアントへの応答 #1:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-cct-PKIResponse
eContent
controlSequence
{101, id-cmc-statusInfoV2, {failed, 201, popRequired}}
{102, id-cmc-transactionId, 10132985123483401}
{103, id-cmc-senderNonce, 10005}
{104, id-cmc-recipientNonce, 10001}
{105, id-cmc-encryptedPOP, {
request {
crm
certReq
certReqId = 201
certTemplate
subject = <My DN>
publicKey = My Public Key
extensions
{id-ce-keyUsage, keyEncipherment}
{id-ce-subjectPublicKeyIdentifier, 1000}
popo
keyEncipherment
subsequentMessage = challengeResp
}
cms
contentType = id-envelopedData
content
recipientInfos.rid.issuerSerialNumber =
<NULL-DN, 201>
encryptedContentInfo
eContentType = id-data
eContent = <Encrypted value of 'y' from
Section 6.7>
thePOPAlgID = HMAC-SHA256
witnessAlgID = SHA-256
witness <hashed value of 'y' from Section 6.7>}}
{106, id-cmc-dataReturn, <packet of binary data
identifying where the key
in question is.>}
certificates
Other certificates
(optional - related to this message's SignedData)
SignedData.SignerInfos
Signed by CA
Message #2 from client to server:
クライアントからサーバーへのメッセージ #2:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-cct-PKIData
eContent
controlSequence
{102, id-cmc-transactionId, 10132985123483401}
{103, id-cmc-senderNonce, 100101}
{104, id-cmc-dataReturn, <packet of binary data
identifying where the key
in question is.>}
{105, id-cmc-recipientNonce, 10005}
{107, id-cmc-decryptedPOP, {
bodyPartID 201,
thePOPAlgID HMAC-SHA256,
thePOP <HMAC computed value goes here>}}
reqSequence
crm
certReq
certReqId = 201
certTemplate
subject = <My DN>
publicKey = My Public Key
extensions
{id-ce-keyUsage, keyEncipherment}
{id-ce-subjectKeyIdentifier, 1000}
popo
keyEncipherment
subsequentMessage = challengeResp
SignedData.SignerInfos
SignerInfo
Signed by requester's signing cert
Response #2 from server to client:
サーバーからクライアントへの応答 #2:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-cct-PKIResponse
eContent
controlSequence
{101, id-cmc-transactionId, 10132985123483401}
{102, id-cmc-statusInfoV2, {success, 201}}
{103, id-cmc-senderNonce, 10019}
{104, id-cmc-recipientNonce, 100101}
{105, id-cmc-dataReturn, <packet of binary data
identifying where the key
in question is.>}
certificates
Newly issued certificate
Other certificates
(optional - related to this message's SignedData)
SignedData.SignerInfos
Signed by CA
This section looks at the messages that would flow in the event that an enrollment is done for an encryption-only certificate using a direct POP method. Instead of assuming that the certification requester already has a signing-only certificate (as in Appendix B.3), here the No Signature mechanism is from Appendix C.1, the public key is for a KEM, and the EnvelopedData uses the KEMRecipientInfo from [CMS-KEM]. This example uses EnvelopedData; however, either EnvelopedData or AuthEnvelopedData can be used.
このセクションでは、直接 POP 方式を使用して暗号化専用証明書の登録が行われた場合に流れるメッセージについて説明します。(付録 B.3 のように) 認証要求者が既に署名専用証明書を持っていると仮定するのではなく、ここでは、署名なしメカニズムは付録 C.1 からのものであり、公開鍵は KEM 用であり、EnvelopedData は [CMS-KEM] からの KEMRecipientInfo を使用しています。この例では EnvelopedData を使用します。ただし、EnvelopedData または AuthEnvelopedData のいずれかを使用できます。
Message #1 from client to server:
クライアントからサーバーへのメッセージ #1:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-cct-PKIData
eContent
controlSequence
{102, id-cmc-transactionId, 10132985123483401}
{103, id-cmc-senderNonce, 10001}
{104, id-cmc-dataReturn, <packet of binary data
identifying where the key
in question is.>}
reqSequence
crm
certReq
certReqId = 201
certTemplate
subject = < My DN >
publicKey = My Public Key
extensions
{id-ce-subjectPublicKeyIdentifier, 1000}
{id-ce-keyUsage, keyEncipherment}
popo
keyEncipherment
subsequentMessage = challengeResp
SignedData.SignerInfos
SignerInfo
sid = < subjectKeyIdentifier >
signatureAlgorithm = id-alg-noSignature
Response #1 from server to client:
サーバーからクライアントへの応答 #1:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-cct-PKIResponse
eContent
controlSequence
{101, id-cmc-statusInfoV2, {failed, 201, popRequired}}
{102, id-cmc-transactionId, 10132985123483401}
{103, id-cmc-senderNonce, 10005}
{104, id-cmc-recipientNonce, 10001}
{105, id-cmc-encryptedPOP, {
request {
crm
certReq
certReqId = 201
certTemplate
subject = < My DN >
publicKey = My Public Key
extensions
{id-ce-keyUsage, keyEncipherment}
{id-ce-subjectPublicKeyIdentifier, 1000}
popo
keyEncipherment
subsequentMessage = challengeResp
}
cms
contentType = id-envelopedData
content < uses ori.KEMRecipientInfo >
recipientInfos.ori.rid.issuerSerialNumber =
<NULL-DN, 201>
encryptedContentInfo
eContentType = id-data
eContent = <Encrypted value of 'y' from
Section 6.7>
thePOPAlgID = KmacWithSHAKE128
witnessAlgID = SHAKE128
witness <hashed value of 'y' from Section 6.7>}}
{106, id-cmc-dataReturn, <packet of binary data
identifying where the key
in question is.>}
certificates
Other certificates
(optional - related to this message's SignedData)
SignedData.SignerInfos
Signed by CA
Message #2 from client to server:
クライアントからサーバーへのメッセージ #2:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-cct-PKIData
eContent
controlSequence
{102, id-cmc-transactionId, 10132985123483401}
{103, id-cmc-senderNonce, 100101}
{104, id-cmc-dataReturn, <packet of binary data
identifying where the key
in question is.>}
{105, id-cmc-recipientNonce, 10005}
{107, id-cmc-decryptedPOP, {
bodyPartID 201,
thePOPAlgID KmacWithSHAKE128,
thePOP <KMAC computed value goes here>}}
reqSequence
crm
certReq
certReqId = 201
certTemplate
subject = < My DN >
publicKey = My Public Key
extensions
{id-ce-keyUsage, keyEncipherment}
{id-ce-subjectPublicKeyIdentifier, 1000}
popo
keyEncipherment
subsequentMessage = challengeResp
SignedData.SignerInfos
SignerInfo
sid = < subjectKeyIdentifier >
signatureAlgorithm = id-alg-noSignature
Response #2 from server to client:
サーバーからクライアントへの応答 #2:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-cct-PKIResponse
eContent
controlSequence
{101, id-cmc-transactionId, 10132985123483401}
{102, id-cmc-statusInfoV2, {success, 201}}
{103, id-cmc-senderNonce, 10019}
{104, id-cmc-recipientNonce, 100101}
{105, id-cmc-dataReturn, <packet of binary data
identifying where the key
in question is.>}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
Part of a certification request is a signature over the request; DH and ECDH are key agreement algorithms and the key encapsulation mechanisms (KEMs) RSA-KEM and ML-KEM (Module-Lattic-Based KEM) cannot be used to directly produce the required signature object. [DH-POP] provides three ways to produce the necessary signature value. This document also defines a signature algorithm that does not provide a POP value but that can be used to produce the necessary signature value.
認証要求の一部は、要求に対する署名です。DH および ECDH は鍵合意アルゴリズムであり、鍵カプセル化メカニズム (KEM) RSA-KEM および ML-KEM (Module-Lattic-Based KEM) を使用して、必要な署名オブジェクトを直接生成することはできません。[DH-POP] は、必要な署名値を生成する 3 つの方法を提供します。この文書は、POP 値を提供しないが、必要な署名値を生成するために使用できる署名アルゴリズムも定義します。
Key management (encryption/decryption) private keys cannot always be used to produce some type of signature value as they can be in a decrypt-only device. Certification requests require that the signature field be populated. This section provides a signature algorithm specifically for that purpose. 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 SHA-1 hash of the certification request. The hash value given by NoSignatureValue SHOULD be ignored. 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 CA policy requires proof-of-possession of the private key, the POP mechanism defined in Section 6.7 MUST be used.
id-alg-noSignature のパラメータは存在しなければならず、NULL としてエンコードされなければなりません。NoSignatureValue には、証明書リクエストの SHA-1 ハッシュが含まれます。NoSignatureValue で指定されたハッシュ値は無視されるべきです (SHOULD)。この署名タイプにはセキュリティが関連付けられていないことを認識することが重要です。この署名タイプが認証要求にあり、CA ポリシーが秘密鍵の所有証明を必要とする場合、セクション 6.7 で定義されている POP メカニズムを使用しなければなりません (MUST)。
When the client generates the SignedData.SignerInfos.SignerInfo.sid field, it has two choices: issuerAndSerialNumber or subjectKeyIdentifier. The client does not yet have a certificate; therefore, it cannot fill in the issuerAndSerialNumber and MUST use the subjectKeyIdentifier choice.
クライアントが SignedData.SignerInfos.SignerInfo.sid フィールドを生成する場合、issuerAndSerialNumber または subjectKeyIdentifier の 2 つの選択肢があります。クライアントはまだ証明書を持っていません。したがって、issuerAndSerialNumber を入力することはできず、subjectKeyIdentifier の選択を使用しなければなりません。
The authors would like to thank Jim Schaad and Michael Myers for their work on RFC 5272.
著者らは、RFC 5272 に関する取り組みについて、Jim Schaad と Michael Myers に感謝の意を表します。
Thank you to Charlie Kaufman, Orie Steele, Paul Wouters, Éric Vyncke, Mike Bishop, Reese Enghardt, Mohamed Boucadair, Russ Housley, and Deb Cooley for reviewing the document and providing comments.
文書をレビューし、コメントを提供してくださった Charlie Kaufman、Orie Steele、Paul Wouters、Éric Vyncke、Mike Bishop、Reese Enghardt、Mohamed Boucadair、Russ Housley、および Deb Cooley に感謝します。
The Acknowledgements section from RFC 5272 follows:
RFC 5272 の謝辞セクションは次のとおりです。
The authors and the PKIX Working Group are grateful for the participation of Xiaoyi Liu and Jeff Weinstein in helping to author the original versions of this document.
著者と PKIX ワーキング グループは、このドキュメントのオリジナル版の作成に協力してくれた Xiaoyi Liu と Jeff Weinstein の参加に感謝しています。
The authors would like to thank Brian LaMacchia for his work in developing and writing up many of the concepts presented in this document. The authors would also like to thank Alex Deacon and Barb Fox for their contributions.
著者らは、この文書に記載されている概念の多くを開発し、執筆した Brian LaMacchia 氏に感謝の意を表します。著者らは、貢献してくれた Alex Deacon と Barb Fox にも感謝したいと思います。
Jim Schaad
August Cellars
Michael Myers
TraceRoute Security, Inc.
Joseph Mandel (editor)
AKAYLA, Inc.
Email: joe@akayla.com
Sean Turner (editor)
sn3rd
Email: sean@sn3rd.com