[要約] RFC 6403は、CMS上の証明書管理のためのSuite Bプロファイルに関するものであり、要約すると以下のようになります。1. Suite Bセキュリティプロファイルを使用して、CMS上で証明書の管理を行うためのガイドラインを提供する。 2. Suite Bセキュリティアルゴリズムの使用に関する要件と制約を定義する。 3. Suite Bセキュリティプロファイルを使用して、証明書の生成、配布、更新、失効などの操作を安全かつ効率的に行うための手順を提供する。
Internet Engineering Task Force (IETF) L. Zieglar
Request for Comments: 6403 NSA
Category: Informational S. Turner
ISSN: 2070-1721 IECA
M. Peck
November 2011
Suite B Profile of Certificate Management over CMS
CMSを超える証明書管理のスイートBプロファイル
Abstract
概要
The United States government has published guidelines for "NSA Suite B Cryptography", which defines cryptographic algorithm policy for national security applications. This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing Suite B X.509 public key certificates. This profile is a refinement of RFCs 5272, 5273, and 5274.
米国政府は、「NSA Suite B Cryptography」のガイドラインを公開しました。これは、国家安全保障アプリケーションの暗号化アルゴリズムポリシーを定義しています。このドキュメントは、スイートB X.509公開証明書を管理するためのCMS（CMC）プロトコルを介した証明書管理のプロファイルを指定します。このプロファイルは、RFCS 5272、5273、および5274の改良です。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6403.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6403で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントは必須です
include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、簡素化されたBSDライセンスに記載されている保証なしで提供される簡略化されたBSDライセンステキストを含めます。
This document specifies a profile for using the Certificate Management over CMS (CMC) protocol, defined in [RFC5272], [RFC5273], and [RFC5274], and updated by [RFC6402], to manage X.509 public key certificates compliant with the United States National Security Agency's Suite B Cryptography as defined in the Suite B Certificate and Certificate Revocation List (CRL) Profile [RFC5759]. This document specifically focuses on defining CMC interactions for both initial enrollment and rekey of Suite B public key certificates between a client and a Certification Authority (CA). One or more Registration Authorities (RAs) may act as intermediaries between the client and the CA. This profile may be further tailored by specific communities to meet their needs. Specific communities will also define Certificate Policies that implementations need to comply with.
このドキュメントは、[RFC5272]、[RFC5273]、および[RFC5274]で定義されているCMS（CMC）プロトコルを介して証明書管理を使用するためのプロファイルを指定し、[RFC6402]によって更新され、X.509の公的キー証明書を管理するために更新されます。Suite B証明書および証明書取消リスト（CRL）プロファイル[RFC5759]で定義されている米国国家安全保障局のスイートB暗号化。このドキュメントは、クライアントと認証機関（CA）の間のスイートB公開証明書の初期登録と再キーの両方のCMC相互作用の定義に特に焦点を当てています。1つ以上の登録当局（RAS）は、クライアントとCAの間の仲介者として機能する場合があります。このプロファイルは、特定のコミュニティによってさらに調整され、ニーズを満たすことができます。特定のコミュニティは、実装が従う必要がある証明書ポリシーも定義します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The terminology in [RFC5272] Section 2.1 applies to this profile.
[RFC5272]セクション2.1の用語は、このプロファイルに適用されます。
All key pairs are on either the curve P-256 or the curve P-384. FIPS 186-3 [DSS], Appendix B.4, provides useful guidance for elliptic curve key pair generation that SHOULD be followed by systems that conform to this document.
すべての重要なペアは、曲線P-256または曲線P-384のいずれかにあります。FIPS 186-3 [DSS]、付録B.4は、このドキュメントに準拠するシステムが続いて続く必要がある楕円曲線キーペア生成の有用なガイダンスを提供します。
This document assumes that the required trust anchors have been securely provisioned to the client and, when applicable, to any RAs.
このドキュメントは、必要な信頼アンカーがクライアントに安全にプロビジョニングされ、該当する場合は任意のRAに安全にプロビジョニングされていることを前提としています。
All requirements in [RFC5272], [RFC5273], [RFC5274], and [RFC6402] apply, except where overridden by this profile.
[RFC5272]、[RFC5273]、[RFC5274]、および[RFC6402]のすべての要件が適用されます。ただし、このプロファイルによってオーバーライドされた場合を除きます。
This profile was developed with the scenarios described in Appendix A in mind. However, use of this profile is not limited to just those scenarios.
このプロファイルは、付録Aを念頭に置いて説明したシナリオで開発されました。ただし、このプロファイルの使用は、これらのシナリオだけに限定されません。
The term "client" in this profile typically refers to an end-entity. However, it may instead refer to a third party acting on the end-entity's behalf. The client may or may not be the entity that
このプロファイルの「クライアント」という用語は、通常、エンディティを指します。ただし、代わりに、エンドエンティティに代わって行動する第三者を指す場合があります。クライアントは、
actually generates the key pair, but it does perform the CMC protocol interactions with the RA and/or CA. For example, the client may be a token management system that communicates with a cryptographic token through an out-of-band secure protocol.
実際にキーペアを生成しますが、RAおよび/またはCAとのCMCプロトコル相互作用を実行します。たとえば、クライアントは、バンド外の安全なプロトコルを介して暗号化トークンと通信するトークン管理システムである場合があります。
This profile uses the term "rekey" in the same manner as does CMC (defined in Section 2 of [RFC5272]). The profile makes no specific statements about the ability to do "renewal" operations; however, the statements applicable to rekey should be applied to renewal as well.
このプロファイルは、CMCと同じ方法で「Rekey」という用語を使用します（[RFC5272]のセクション2で定義）。プロファイルは、「更新」操作を行う能力に関する具体的な記述を作成しません。ただし、Rekeyに適用されるステートメントも更新に適用する必要があります。
This profile may be used to manage RA and/or CA certificates. In that case, the RA and/or CA whose certificate is being managed is considered to be the end-entity.
このプロファイルは、RAおよび/またはCA証明書の管理に使用できます。その場合、証明書が管理されているRAおよび/またはCAは、エンティティと見なされます。
This profile does not support key establishment certification requests from cryptographic modules that cannot generate a one-time signature with a key establishment key for proof-of-possession purposes. In that case, a separate profile would be needed to define the use of another proof-of-possession technique.
このプロファイルは、所有証明の目的でキー設立キーを使用して1回限りの署名を生成できない暗号化モジュールからの主要な確立認証要求をサポートしていません。その場合、別のプルーフオブポッセッション手法の使用を定義するには、別のプロファイルが必要になります。
This section specifies the conventions employed when a client requests a certificate from a Public Key Infrastructure (PKI).
このセクションでは、クライアントが公開キーインフラストラクチャ（PKI）から証明書を要求したときに採用された規則を指定します。
The Full PKI Request MUST be used; it MUST be encapsulated in a SignedData; and the SignedData MUST be constructed as defined in [RFC6318]. The PKIData content type complies with [RFC5272] with the following additional requirements:
完全なPKIリクエストを使用する必要があります。SignedDataにカプセル化する必要があります。[RFC6318]で定義されているように、SignedDataを構築する必要があります。Pkidataコンテンツタイプは、次の追加要件で[RFC5272]に準拠しています。
o controlSequence SHOULD be present, and it SHOULD include the following CMC controls: Transaction ID and Sender Nonce. Other CMC controls MAY be included. If the request is being authenticated using a shared-secret, then the following requirements in this paragraph apply: Identity Proof Version 2 control, as defined in [RFC5272], MUST be included; hashAlgId MUST be id-sha256 or id-sha384 for P-256 certification requests, and MUST be id-sha384 for P-384 certification requests (both algorithm OIDs are defined in [RFC5754]); macAlgId MUST be HMAC-SHA256 when the hashAlgId is id-sha256, and MUST be HMAC-SHA384 when the hashAlgId is id-sha384 (both HMAC algorithms are defined in [RFC4231]). If the subject included in the certification request is NULL or otherwise does not uniquely identify the end-entity, then the POP Link Random control MUST be included, and the POP Link Witness Version 2 control MUST be included in the inner PKCS #10 or Certificate Request Message Format (CRMF) request as described in Sections 4.1 and 4.2.
o 制御シーケンスが存在する必要があり、次のCMCコントロールを含める必要があります：トランザクションIDおよび送信者NonCE。他のCMCコントロールが含まれる場合があります。リクエストが共有秘密を使用して認証されている場合、この段落の次の要件が適用されます。[RFC5272]で定義されているID証明バージョン2コントロールを含める必要があります。 Hashalgidは、P-256認証要求のID-Sha256またはID-Sha384でなければならず、P-384認証要求の場合はID-Sha384でなければなりません（両方のアルゴリズムOIDは[RFC5754]で定義されています）。 HashalgidがID-Sha256である場合、HMAC-SHA256でなければなりません。HASHALGIDがID-SHA384の場合、HMAC-SHA384でなければなりません（両方のHMACアルゴリズムが[RFC4231]で定義されています）。認定リクエストに含まれるサブジェクトがnullまたはその他の場合、エンドエンティティを一意に識別しない場合、ポップリンクランダムコントロールを含める必要があり、ポップリンク証言バージョン2コントロールを内部PKCS＃10または証明書に含める必要がありますセクション4.1および4.2で説明されているように、メッセージフォーマット（CRMF）要求を要求します。
o reqSequence MUST be present. It MUST include at least one tcr (see Section 4.1) or crm (see Section 4.2) TaggedRequest. Support for the orm choice is OPTIONAL.
o reqsequenceが存在する必要があります。少なくとも1つのTCR（セクション4.1を参照）またはCRM（セクション4.2を参照）TaggedRequestを含める必要があります。ORM選択のサポートはオプションです。
If the Full PKI Request contains a P-256 public key certification request, then the SignedData encapsulating the Full PKI Request MUST be generated using either SHA-256 and ECDSA on P-256 or using SHA-384 and ECDSA on P-384. If the Full PKI Request contains a P-384 public key certification request, then the SignedData MUST be generated using SHA-384 and ECDSA on P-384.
完全なPKI要求にP-256公開キー認証要求が含まれている場合、PKIリクエストをカプセル化するSignedDataは、P-256のSHA-256およびECDSAのいずれかを使用して、またはP-384でSHA-384およびECDSAを使用して生成する必要があります。完全なPKIリクエストにP-384公開キー認証要求が含まれている場合、P-384のSHA-384およびECDSAを使用してSignedDataを生成する必要があります。
A Full PKI Request MUST be signed using the private key that corresponds to the public key of an existing signature certificate unless an appropriate signature certificate does not yet exist, such as during initial enrollment.
最初の登録中など、適切な署名証明書がまだ存在しない限り、既存の署名証明書の公開キーに対応する秘密鍵を使用して、完全なPKI要求を署名する必要があります。
If an appropriate signature certificate does not yet exist, and if a Full PKI Request includes one or more certification requests and is authenticated using a shared-secret (because no appropriate certificate exists yet to authenticate the request), the Full PKI Request MUST be signed using the private key corresponding to the public key of one of the requested certificates. When necessary (i.e., because there is no existing signature certificate and there is no signature certification request included), a Full PKI Request MAY be signed using a key pair intended for use in a key establishment certificate. However, servers are not required to allow this behavior.
適切な署名証明書がまだ存在しない場合、および完全なPKIリクエストに1つ以上の認定リクエストが含まれ、共有秘密を使用して認証されている場合（リクエストを認証するための適切な証明書がまだ存在しないため）、完全なPKIリクエストに署名する必要があります要求された証明書の1つの公開鍵に対応する秘密鍵を使用します。必要に応じて（つまり、既存の署名証明書がなく、署名認証リクエストが含まれていないため）、キー設立証明書で使用することを目的としたキーペアを使用して、完全なPKIリクエストを署名することができます。ただし、この動作を許可するためにサーバーは必要ありません。
The reqSequence tcr choice conveys PKCS #10 [RFC2986] syntax. The CertificateRequest MUST comply with [RFC5272], Section 3.2.1.2.1, with the following additional requirements:
ReqSequence TCR選択は、PKCS＃10 [RFC2986]構文を伝えます。証明書は、次の追加要件を伴う[RFC5272]、セクション3.2.1.2.1に準拠する必要があります。
o certificationRequestInfo:
o certificationRequestinfo：
* subjectPublicKeyInfo MUST be set as defined in Section 4.4 of [RFC5759];
* [RFC5759]のセクション4.4で定義されているように、[rfc5759]で定義されているように設定する必要があります。
* attributes:
* 属性：
- The ExtensionReq attribute MUST be included with its contents as follows:
- extensionReq属性は、次のようにその内容に含める必要があります。
o The Key Usage extension MUST be included, and it MUST be set as defined in [RFC5759].
o 主要な使用法拡張機能を含める必要があり、[RFC5759]で定義されているように設定する必要があります。
o For rekey requests, the SubjectAltName extension MUST be included and set equal to the SubjectAltName of the certificate that is being used to sign the SignedData encapsulating the request (i.e., not the certificate being rekeyed) if the Subject field of the certificate being used to generate the signature is NULL.
o Rekeyリクエストの場合、subjectaltname拡張子を含めて、リクエストのカプセル化された署名dataに署名するために使用されている証明書のsumberaltaltnameに等しく設定する必要があります（つまり、証明書が再キーにされているわけではありません）。署名はnullです。
o Other extension requests MAY be included as desired.
o その他の拡張リクエストは、必要に応じて含まれる場合があります。
- The ChangeSubjectName attribute, as defined in [RFC6402], MUST be included if the Full PKI Request encapsulating this Tagged Certification Request is being signed by a key for which a certificate currently exists and the existing certificate's Subject or SubjectAltName does not match the desired Subject or SubjectAltName of this certification request.
- [rfc6402]で定義されている変更ブドウムの属性は、このタグ付けされた認証要求をカプセル化する完全なPKIリクエストが証明書が現在存在するキーによって署名され、既存の証明書の件名または件名が望ましい科目または件名と一致しない場合に含める必要があります。この認定リクエストのsubjectaltname。
- The POP Link Witness Version 2 attribute MUST be included if the request is being authenticated using a shared-secret and the Subject in the certification request is NULL or otherwise does not uniquely identify the end-entity. In the POP Link Witness Version 2 attribute, keyGenAlgorithm MUST be id-sha256 or id-sha384 for P-256 certification requests and MUST be id-sha384 for P-384 certification requests, as defined in [RFC5754]; macAlgorithm MUST be HMAC-SHA256 when the keyGenAlgorithm is id-sha256 and MUST be HMAC-SHA384 when the keyGenAlgorithm is id-sha384, as defined in [RFC4231].
- リクエストが共有秘密を使用して認証されている場合は、POP Link Witnessバージョン2属性を含める必要があり、認定リクエストの主題はnullまたはその他の方法で終了性を一意に識別しません。POP Link Witnessバージョン2属性では、[RFC5754]で定義されているように、KeyGenalGorithmはP-256認証要求のID-SHA256またはID-SHA384でなければならず、P-384認証要求のID-SHA384でなければなりません。[rfc4231]で定義されているように、keygenalgorithmがid-sha384である場合、keygenalgorithmがid-sha256であり、[rfc4231]で定義されている場合は、keygenalgorithmがid-sha256であり、hmac-sha384でなければならない場合、hmac-sha256でなければなりません。
* signatureAlgorithm MUST be ecdsa-with-sha256 for P-256 certification requests and MUST be ecdsa-with-sha384 for P-384 certification requests;
* SignatureAlgorithmは、P-256認証要求のECDSA-SHA256である必要があり、P-384認証要求の場合はECDSA-SHA384でなければなりません。
* signature MUST be generated using the private key corresponding to the public key in the CertificationRequestInfo, for both signature and key establishment certification requests. The signature provides proof-of-possession of the private key to the Certification Authority.
* Signature Requestinfoの公開キーに対応する秘密鍵を使用して、署名とキーの設立認証要求の両方について生成する必要があります。署名は、認証機関の秘密鍵の監視の証明を提供します。
The reqSequence crm choice conveys Certificate Request Message Format (CRMF) [RFC4211] syntax. The CertReqMsg MUST comply with [RFC5272], Section 3.2.1.2.2, with the following additional requirements:
ReqSequence CRM Choiceは、証明書要求メッセージ形式（CRMF）[RFC4211]構文を伝えます。CertreQMSGは、次の追加要件を伴う[RFC5272]、セクション3.2.1.2.2に準拠する必要があります。
o popo MUST be included using the signature (POPOSigningKey) proof-of-possession choice and set as defined in [RFC4211], Section 4.1, for both signature and key establishment certification requests.
o POPOは、署名（PopoSigingKey）Proof-ossession選択の選択を使用して含め、[RFC4211]、セクション4.1で定義されているように設定され、署名と主要な確立認証要求の両方で設定する必要があります。
The POPOSigningKey poposkInput field MUST be omitted. The POPOSigningKey algorithmIdentifier MUST be ecdsa-with-sha256 for P-256 certification requests and MUST be ecdsa-with-sha384 for P-384 certification requests. The signature MUST be generated using the private key corresponding to the public key in the CertTemplate.
PopoSigingKey PopoSkinputフィールドは省略する必要があります。PoposigingKey AlgorithMidentifierは、P-256認証要求の場合はECDSA-SHA256でなければならず、P-384認証リクエストの場合はECDSA-SHA384でなければなりません。署名は、certtemplateの公開キーに対応する秘密鍵を使用して生成する必要があります。
The CertTemplate MUST comply with [RFC5272], Section 3.2.1.2.2, with the following additional requirements:
CERTTEMPLATEは、次の追加要件を使用して、[RFC5272]、セクション3.2.1.2.2に準拠する必要があります。
o version MAY be included and, if included, it MUST be set to 2 as defined in Section 4.3 of [RFC5759];
o バージョンを含めることができ、含まれている場合は、[RFC5759]のセクション4.3で定義されているように2に設定する必要があります。
o publicKey MUST be set as defined in Section 4.4 of [RFC5759];
o [RFC5759]のセクション4.4で定義されているように、publicKeyを設定する必要があります。
o extensions:
o 拡張機能：
* The Key Usage extension MUST be included, and it MUST be set as defined in [RFC5759].
* 主要な使用法拡張機能を含める必要があり、[RFC5759]で定義されているように設定する必要があります。
* For rekey requests, the SubjectAltName extension MUST be included and set equal to the SubjectAltName of the certificate that is being used to sign the SignedData encapsulating the request (i.e., not the certificate being rekeyed) if the Subject field of the certificate being used to generate the signature is NULL.
* Rekeyリクエストの場合、subjectaltname拡張子を含めて、リクエストのカプセル化された署名dataに署名するために使用されている証明書のsumberaltaltnameに等しく設定する必要があります（つまり、証明書が再キーにされているわけではありません）。署名はnullです。
* Other extension requests MAY be included as desired.
* その他の拡張リクエストは、必要に応じて含まれる場合があります。
o controls:
o コントロール：
* The ChangeSubjectName attribute, as defined in [RFC6402], MUST be included if the Full PKI Request encapsulating this Tagged Certification Request is being signed by a key for which a certificate currently exists and the existing certificate's Subject or SubjectAltName does not match the desired Subject or SubjectAltName of this certification request.
* [rfc6402]で定義されている変更ブドウムの属性は、このタグ付けされた認証要求をカプセル化する完全なPKIリクエストが証明書が現在存在するキーによって署名され、既存の証明書の件名または件名が望ましい科目または件名と一致しない場合に含める必要があります。この認定リクエストのsubjectaltname。
* The POP Link Witness Version 2 attribute MUST be included if the request is being authenticated using a shared-secret, and the Subject in the certification request is NULL or otherwise does not uniquely identify the end-entity. In the POP Link Witness Version 2 attribute, keyGenAlgorithm MUST be id-sha256 or id-sha384 for P-256 certification requests and MUST be id-sha384 for P-384 certification requests; macAlgorithm MUST be HMAC-SHA256 when keyGenAlgorithm is id-sha256 and MUST be HMAC-SHA384 when keyGenAlgorithm is id-sha384.
* リクエストが共有秘密を使用して認証されている場合は、POP Link Witnessバージョン2属性を含める必要があり、認定リクエストの主題はnullであるか、その他の方法で終了性を一意に識別しません。POP Link Witnessバージョン2属性では、KeyGenalGorithmはP-256認証要求のID-SHA256またはID-SHA384でなければならず、P-384認証要求の場合はID-SHA384でなければなりません。keygenalgorithmがID-SHA256である場合、マカルゴリズムはHMAC-SHA256でなければならず、keygenalgorithmがid-sha384の場合はhmac-sha384でなければなりません。
This section addresses the optional case where one or more RAs act as intermediaries between the client and CA as described in Section 7 of [RFC5272]. In this section, the term "client" refers to the entity from which the RA received the PKI Request. This section is only applicable to RAs.
このセクションでは、[RFC5272]のセクション7で説明されているように、1つ以上のRAがクライアントとCAの間の仲介者として機能するオプションのケースについて説明します。このセクションでは、「クライアント」という用語は、RAがPKI要求を受け取ったエンティティを指します。このセクションは、RASにのみ適用できます。
RAs conforming to this document MUST ensure that only the permitted signature, hash, and MAC algorithms described throughout this profile are used in requests; if they are not, the RA MUST reject those requests. The RA SHOULD return a CMCFailInfo with the value of badAlg [RFC5272].
このドキュメントに準拠するRASは、このプロファイル全体で説明されている署名、ハッシュ、およびMacアルゴリズムのみがリクエストで使用されることを確認する必要があります。そうでない場合、RAはそれらのリクエストを拒否しなければなりません。RAは、バダルグ[RFC5272]の値でCMCFailInfoを返す必要があります。
When processing end-entity-generated SignedData objects, RAs MUST NOT perform Cryptographic Message Syntax (CMS) Content Constraints (CCC) certificate extension processing [RFC6010].
エンドエンティティで生成されたSignedDataオブジェクトを処理する場合、RASは暗号化メッセージ構文（CMS）コンテンツ制約（CCC）証明書拡張処理[RFC6010]を実行してはなりません。
Other RA processing is as in [RFC5272].
他のRA処理は[RFC5272]と同様です。
If the RA encapsulates the client-generated PKI Request in a new RA-signed PKI Request, it MUST create a Full PKI Request encapsulated in a SignedData, and the SignedData MUST be constructed as defined in [RFC6318]. The PKIData content type complies with [RFC5272] with the following additional requirements:
RAが新しいRAに署名したPKIリクエストでクライアントが生成したPKI要求をカプセル化する場合、signedDataにカプセル化された完全なPKIリクエストを作成する必要があり、[RFC6318]で定義されているように署名dataを構築する必要があります。Pkidataコンテンツタイプは、次の追加要件で[RFC5272]に準拠しています。
o controlSequence MUST be present. It MUST include the following CMC controls: Transaction ID, Sender Nonce, and Batch Requests. Other appropriate CMC controls MAY be included.
o 制御シーケンスが存在する必要があります。次のCMCコントロールを含める必要があります：トランザクションID、送信者NonCE、およびBatchリクエスト。他の適切なCMCコントロールが含まれる場合があります。
o cmsSequence MUST be present. It contains the original, unmodified request(s) received from the client.
o CMSシーケンスが存在する必要があります。クライアントから受け取った元の変更されていないリクエストが含まれています。
RA certificates are authorized to sign Full PKI Requests with an Extended Key Usage (EKU) and/or with the CCC certificate extension [RFC6010]. Certificates may also be authorized through local configuration. Authorized certificates SHOULD include the id-kp-cmcRA EKU from [RFC6402]. Authorized certificates MAY also include the CCC certificate extension [RFC6010], or the authorized certificate MAY just include the CCC certificate extension. If the RA is authorized via the CCC extension, then the CCC extension MUST include the object identifier for the PKIData content type. CCC SHOULD be included if constraints are to be placed on the content types generated.
RA証明書は、拡張キー使用量（EKU）および/またはCCC証明書延長[RFC6010]で完全なPKIリクエストに署名する権限があります。証明書は、ローカル構成を通じて許可される場合があります。承認された証明書には、[RFC6402]のID-KP-CMCRA EKUを含める必要があります。許可された証明書には、CCC証明書延長[RFC6010]が含まれる場合もあれば、CCC証明書延長のみが含まれる場合もあります。RAがCCC拡張機能を介して承認されている場合、CCC拡張にはPKIDATAコンテンツタイプのオブジェクト識別子を含める必要があります。制約が生成されたコンテンツタイプに制約を配置する場合は、CCCを含める必要があります。
If the RA-signed PKI Request contains a certification request for a P-256 public key, then the SignedData MUST be generated using either SHA-256 and ECDSA on P-256 or SHA-384 and ECDSA on P-384. If the request contains a certification request for a P-384 public key, then the SignedData MUST be generated using SHA-384 and ECDSA on P-384. If the RA-signed PKI Request contains requests for certificates on the P-256 and P-384 curve, then the SignedData MUST be generated using SHA-384 and ECDSA on P-384. If the Full PKI Response is a successful response to a PKI Request that only contained a Get Certificate or Get CRL control, then the SignedData MUST be signed by either SHA-256 and ECDSA on P-256 or SHA-384 and ECDSA on P-384, the algorithm used in the response MUST match the algorithm used in the request.
RA-Signed PKIリクエストにP-256公開キーの認証要求が含まれている場合、P-256またはP-384でECDSAのSHA-256とECDSAのいずれかを使用してSignedDataを生成する必要があります。リクエストにP-384公開キーの認証要求が含まれている場合、P-384のSHA-384およびECDSAを使用してSignedDataを生成する必要があります。RA-Signed PKIリクエストにP-256およびP-384曲線の証明書のリクエストが含まれている場合、P-384でSHA-384およびECDSAを使用してSignedDataを生成する必要があります。完全なPKI応答がGET証明書のみを含むPKIリクエストに対する成功した応答である場合、PKIコントロールのみが含まれている場合、SIGNEDDATAはP-256またはP-256またはSHA-384およびECDSAのSHA-256およびECDSAによって署名されなければなりません。384、応答で使用されるアルゴリズムは、リクエストで使用されるアルゴリズムと一致する必要があります。
RA certificates authorized with the CCC certificate extension [RFC6010] MUST include the object identifier for the PKIResponse content type to authorize them to generate responses.
CCC証明書拡張[RFC6010]で承認されたRA証明書は、PKiresponseコンテンツタイプのオブジェクト識別子を含めて、応答を生成することを許可する必要があります。
This section specifies the requirements for CAs that receive PKI Requests and that generate PKI Responses.
このセクションでは、PKIリクエストを受信し、PKI応答を生成するCASの要件を指定します。
CAs conforming to this document MUST ensure that only the permitted signature, hash, and MAC algorithms described throughout this profile are used in requests; if they are not, the CA MUST reject those requests. The CA SHOULD return a CMCStatusInfoV2 control with CMCStatus of failed and a CMCFailInfo with the value of badAlg [RFC5272].
このドキュメントに準拠するCASは、このプロファイル全体で説明されている署名、ハッシュ、およびMacアルゴリズムのみがリクエストで使用されることを確認する必要があります。そうでない場合、CAはそれらのリクエストを拒否しなければなりません。CAは、cMCStatusのcMcStatusを使用してCMCSTATUSINFOV2コントロールを返し、BADALG [RFC5272]の値を持つCMCFailInfoを返す必要があります。
For requests involving an RA, the CA MUST verify the RA's authorization. The following certificate fields MUST NOT be modifiable using the Modify Certification Request control: publicKey and the key usage extension. The request MUST be rejected if an attempt to modify those certification request fields is present. The CA SHOULD return a CMCStatusInfoV2 control with CMCStatus of failed and a CMCFailInfo with a value of badRequest.
RAを含むリクエストについては、CAはRAの承認を確認する必要があります。次の証明書フィールドは、修正認定リクエストコントロール：publicKeyおよびキー使用拡張機能を使用して変更できないでください。これらの認証要求フィールドを変更しようとする試みが存在する場合、リクエストを拒否する必要があります。CAは、cMCStatusのcMCStatusを使用してCMCSTATUSINFOV2コントロールを返し、badRequestの値を持つCMCFailInfoを返す必要があります。
When processing end-entity-generated SignedData objects, CAs MUST NOT perform CCC certificate extension processing [RFC6010].
エンドエンティティで生成されたSignedDataオブジェクトを処理する場合、CASはCCC証明書拡張処理[RFC6010]を実行してはなりません。
If the client-generated PKI Request includes a ChangeSubjectName attribute either in the CertRequest controls field for a CRMF request or in the tcr attributes field for a PKCS#10 request, then the CA
クライアントで生成されたPKI要求に、CRMF要求のCERTREQUESTコントロールフィールドのいずれかにChangesubjectName属性が含まれている場合、またはPKCS＃10リクエストのTCR属性フィールドに含まれる場合、CAはCAに
MUST ensure that name change is authorized. The mechanism for ensuring that the name change is authorized is out of scope. If the CA performs this check, and the name change is not authorized, then the CA MUST reject the PKI Request. The CA SHOULD return a CMCStatusInfoV2 control with CMCStatus of failed.
名前の変更が承認されていることを確認する必要があります。名前の変更が承認されていることを確認するためのメカニズムは範囲外です。CAがこのチェックを実行し、名前の変更が許可されていない場合、CAはPKI要求を拒否する必要があります。CAは、失敗したCMCSTATUSを使用してCMCSTATUSINFOV2コントロールを返す必要があります。
Other processing of PKIRequests is as in [RFC5272].
pkirequestsのその他の処理は[RFC5272]のようです。
If a Full PKI Response is returned, it MUST be encapsulated in a SignedData, and the SignedData MUST be constructed as defined in [RFC6318].
完全なPKI応答が返される場合、signedDataにカプセル化する必要があり、[RFC6318]で定義されているように署名dataを構築する必要があります。
If the PKI Response is in response to an RA-encapsulated PKI Request, then the above PKI Response is encapsulated in another CA-generated PKI Response. That PKI Response MUST be encapsulated in a SignedData and the SignedData MUST be constructed as defined in [RFC6318]. The above PKI Response is placed in the encapsulating PKI Response cmsSequence field. The other fields are as above with the addition of the batch response control in controlSequence. The following illustrates a successful CA response to an RA-encapsulated PKI Request, both of which include Transaction IDs and Nonces:
PKI応答がRAでカプセル化されたPKI要求に応じている場合、上記のPKI応答は別のCA生成されたPKI応答にカプセル化されます。そのPKI応答は署名dataにカプセル化され、[RFC6318]で定義されているように署名されたdataを構築する必要があります。上記のPKI応答は、カプセル化PKI応答CMSシーケンスフィールドに配置されます。他のフィールドは、制御シーケンスにバッチ応答制御が追加されることで、上記のようです。以下は、RAでカプセル化されたPKIリクエストに対するCA応答が成功したことを示しています。
SignedData (applied by the CA) PKIData controlSequence (Transaction ID, Sender Nonce, Recipient Nonce, Batch Response) cmsSequence SignedData (applied by CA and includes returned certificates) PKIData controlSequence (Transaction ID, Sender Nonce, Recipient Nonce)
SignedData（CAによって適用）Pkidata制御シーケンス（トランザクションID、送信者NonCE、Reciontient NonCe、Batch Response）
The same private key used to sign certificates MUST NOT be used to sign Full PKI Response messages. Instead, a separate certificate authorized to sign CMC responses MUST be used. Certificates are authorized to sign Full PKI Responses with an EKU and/or with the CCC certificate extension [RFC6010]. Certificates may also be authorized through local configuration. Authorized certificates SHOULD include the id-kp-cmcCA EKU from [RFC6402]. Authorized certificates MAY also include the CCC certificate extension [RFC6010], or the authorized certificate MAY just include the CCC certificate extension. If the CA is authorized via the CCC extension, then the CCC extension MUST include the object identifier for the PKIResponse content type. CCC SHOULD be included if constraints are to be placed on the content types generated.
証明書に署名するために使用される同じ秘密鍵を使用して、完全なPKI応答メッセージに署名する必要はありません。代わりに、CMC応答に署名することを許可された別の証明書を使用する必要があります。証明書は、EKUおよび/またはCCC証明書延長[RFC6010]で完全なPKI応答に署名する権限があります。証明書は、ローカル構成を通じて許可される場合があります。承認された証明書には、[RFC6402]のID-KP-CMCCA EKUを含める必要があります。許可された証明書には、CCC証明書延長[RFC6010]が含まれる場合もあれば、CCC証明書延長のみが含まれる場合もあります。CAがCCC拡張機能を介して承認されている場合、CCC拡張にはPKiresponseコンテンツタイプのオブジェクト識別子を含める必要があります。制約が生成されたコンテンツタイプに制約を配置する場合は、CCCを含める必要があります。
The signature on the SignedData MUST be generated using either ECDSA P-256 on SHA-256 or ECDSA P-384 on SHA-384. If the Full PKI Response is a successful response to a P-256 public key certification request, then the SignedData MUST be generated using either SHA-256 and ECDSA on P-256 or SHA-384 and ECDSA on P-384. If the Full PKI Response is a successful response to a P-384 public key certification request, then the SignedData MUST be generated using SHA-384 and ECDSA on P-384. If the Full PKI Response is a successful response to certification requests on both the P-256 and P-356 curves, then the SignedData MUST be generated using SHA-384 and ECDSA on P-384. If the Full PKI Response is an unsuccessful response to a PKI Request, then the SignedData MUST be signed by either SHA-256 and ECDSA on P-256 or SHA-384 and ECDSA on P-384, the algorithm used in the response MUST match the algorithm used in the request. If the Full PKI Response is an unsuccessful response to certification requests on both the P-256 and P-356 curves, then the SignedData MUST be generated using SHA-384 and ECDSA on P-384. If the Full PKI Response is a successful response to a PKI Request that only contained a Get Certificate or Get CRL control, then the SignedData MUST be signed by either SHA-256 and ECDSA on P-256 or SHA-384 and ECDSA on P-384, the algorithm used in the response MUST match the algorithm used in the request.
SignedDataの署名は、SHA-256のECDSA P-256またはSHA-384のECDSA P-384を使用して生成する必要があります。完全なPKI応答がP-256公開キー認証リクエストに対する成功した応答である場合、P-256またはP-384でECDSAのSHA-256とECDSAのいずれかを使用してSignedDataを生成する必要があります。完全なPKI応答がP-384公開キー認証リクエストに対する成功した応答である場合、P-384のSHA-384およびECDSAを使用してSignedDataを生成する必要があります。完全なPKI応答がP-256とP-356曲線の両方で認証要求に対する成功した応答である場合、P-384のSHA-384およびECDSAを使用してSignedDataを生成する必要があります。完全なPKI応答がPKIリクエストに対する応答に失敗した場合、署名DataはP-256またはSHA-384のECDSAおよびP-384のECDSAで署名する必要があります。リクエストで使用されるアルゴリズム。完全なPKI応答がP-256およびP-356曲線の両方で認証要求に対する応答に失敗した場合、P-384のSHA-384およびECDSAを使用してSignedDataを生成する必要があります。完全なPKI応答がGET証明書のみを含むPKIリクエストに対する成功した応答である場合、PKIコントロールのみが含まれている場合、SIGNEDDATAはP-256またはP-256またはSHA-384およびECDSAのSHA-256およびECDSAによって署名されなければなりません。 384、応答で使用されるアルゴリズムは、リクエストで使用されるアルゴリズムと一致する必要があります。
If the PKI Response is in response to an RA-encapsulated PKI Request, the signature algorithm for each SignedData is selected independently.
PKI応答がRAでカプセル化されたPKIリクエストに応答している場合、各SignedDataの署名アルゴリズムが個別に選択されます。
Clients conforming to this document MUST ensure that only the permitted signature, hash, and MAC algorithms described throughout this profile are used in responses; if they are not, the client MUST reject those responses.
このドキュメントに準拠しているクライアントは、このプロファイル全体で説明されている署名、ハッシュ、およびMacアルゴリズムのみが応答で使用されることを確認する必要があります。そうでない場合、クライアントはそれらの応答を拒否する必要があります。
Clients MUST authenticate all Full PKI Responses. This includes verifying that the PKI Response is signed by an authorized CA or RA whose certificate validates back to a trust anchor. The authorized CA certificate MUST include the id-kp-cmcCA EKU and/or include a CCC extension that includes the object identifier for the PKIResponse content type. Or, the CA is determined to be authorized to sign responses through an implementation-specific mechanism. The PKI Response can be signed by an RA if it is an error message, if it is a response to a Get Certificate or Get CRL request, or if the PKI Response contains an inner PKI Response signed by a CA. In the last case, each layer of PKI Response MUST still contain an authorized, valid signature signed by an entity with a valid certificate that verifies back to an acceptable trust anchor. The authorized RA certificate MUST include the id-kp-cmcRA EKU and/or include a CCC
クライアントは、すべての完全なPKI応答を認証する必要があります。これには、PKI応答が信頼のアンカーに戻って検証する認定CAまたはRAによって署名されていることを確認することが含まれます。承認されたCA証明書には、ID-KP-CMCCA EKUを含める必要があります。または、CAは、実装固有のメカニズムを介して応答に署名することを許可されると判断されます。PKI応答は、それがエラーメッセージである場合、それがGET証明書またはGET CRL要求への応答である場合、RAによって署名することができます。最後のケースでは、PKI応答の各レイヤーには、許容可能な信頼アンカーに戻る有効な証明書を持つエンティティが署名した承認された有効な署名を依然として含める必要があります。承認されたRA証明書には、ID-KP-CMCRA EKUを含める必要があります、および/またはCCCを含める必要があります
extension that includes the object identifier for the PKIResponse content type. Or, the RA is determined to be authorized to sign responses through an implementation-specific mechanism.
pkiresponseコンテンツタイプのオブジェクト識別子を含む拡張機能。または、RAは、実装固有のメカニズムを介して応答に署名することを許可されると判断されます。
When a newly issued certificate is included in the PKI Response, the client MUST verify that the newly issued certificate's public key matches the public key that the client requested. The client MUST also ensure that the certificate's signature is valid and that the signature validates back to an acceptable trust anchor.
新しく発行された証明書がPKI応答に含まれる場合、クライアントは、新しく発行された証明書の公開キーがクライアントが要求した公開キーと一致することを確認する必要があります。また、クライアントは、証明書の署名が有効であること、および署名が許容可能な信頼アンカーに戻ることを確認する必要があります。
Clients MUST reject PKI Responses that do not pass these tests. Local policy will determine whether the client returns a Full PKI Response with an Extended CMC Status Info control with CMCStatus set to failed to a user console, error log, or the server.
クライアントは、これらのテストに合格しないPKI応答を拒否する必要があります。ローカルポリシーは、CMCSTATUSがユーザーコンソール、エラーログ、またはサーバーに失敗するように設定された拡張CMCステータス情報コントロールを使用して、クライアントが完全なPKI応答を返すかどうかを判断します。
If the Full PKI Response contains an Extended Status Info with a CMCStatus set to failed, then local policy will determine whether the client resends a duplicate certification request back to the server or an error state is returned to a console or error log.
完全なPKI応答に、CMCSTATUSセットが失敗するように拡張されたステータス情報が含まれている場合、ローカルポリシーは、クライアントがサーバーに重複した認証要求を再送信するか、エラー状態がコンソールまたはエラーログに返されるかどうかを決定します。
When the Identity Proof V2 and POP Link Witness V2 controls are used, the shared-secret MUST be randomly generated and securely distributed. The shared-secret MUST provide at least 128 bits of strength for P-256 certification requests and at least 192 bits of strength for P-384 certification requests.
身分証明V2およびPOP Link Witness V2コントロールを使用する場合、共有分泌範囲をランダムに生成し、安全に分布する必要があります。共有秘密は、P-256認証要求に少なくとも128ビットの強度を提供する必要があり、P-384認証要求には少なくとも192ビットの強度を提供する必要があります。
Protocol security considerations are found in [RFC2986], [RFC4211], [RFC6318], [RFC5272], [RFC5273], [RFC5274], [RFC5759], and [RFC6402]. When CCC is used to authorize RA and CA certificates, then the security considerations in [RFC6010] also apply. Algorithm security considerations are found in [RFC6318].
プロトコルのセキュリティに関する考慮事項は、[RFC2986]、[RFC4211]、[RFC6318]、[RFC5272]、[RFC5273]、[RFC5274]、[RFC5759]、および[RFC6402]にあります。CCCを使用してRAおよびCA証明書を承認する場合、[RFC6010]のセキュリティ上の考慮事項も適用されます。アルゴリズムのセキュリティ上の考慮事項は[RFC6318]にあります。
Compliant with NIST Special Publication 800-57 [SP80057], this profile defines proof-of-possession of a key establishment private key by performing a digital signature. Except for one-time proof-of-possession, a single key pair MUST NOT be used for both signature and key establishment.
NIST Special Publication 800-57 [SP80057]に準拠しているこのプロファイルは、デジタル署名を実行することにより、キー設立の秘密鍵の所有の証明を定義しています。1回限りのプルーフオブポッセッションを除き、署名と主要な設立の両方に単一のキーペアを使用してはなりません。
This specification requires implementations to generate key pairs and other random values. The use of inadequate pseudo-random number generators (PRNGs) can result in little or no security. The generation of quality random numbers is difficult. NIST Special Publication 800-90 [SP80090], FIPS 186-3 [DSS], and [RFC4086] offer random number generation guidance.
この仕様では、キーペアやその他のランダム値を生成するための実装が必要です。不十分な擬似ランダム数ジェネレーター（PRNG）を使用すると、セキュリティがほとんどまたはまったくなりません。品質の乱数の生成は困難です。NIST Special Publication 800-90 [SP80090]、FIPS 186-3 [DSS]、および[RFC4086]は、乱数生成ガイダンスを提供します。
When RAs are used, the list of authorized RAs must be securely distributed out-of-band to CAs.
RASを使用する場合、承認されたRAのリストは、CASに帯域外に安全に配布する必要があります。
Presence of the POP Link Witness Version 2 and POP Link Random attributes protects against substitution attacks.
ポップリンクの存在バージョン2およびPOPリンクランダム属性は、代替攻撃から保護します。
The Certificate Policy for a particular environment will specify whether expired certificates can be used to sign certification requests.
特定の環境の証明書ポリシーは、期限切れの証明書を使用して認証要求に署名できるかどうかを指定します。
Michael Peck wishes to acknowledge that he was employed at the National Security Agency during much of the work on this document.
マイケル・ペックは、この文書の作業の多くの間に国家安全保障局に雇用されていたことを認めたいと考えています。
[DSS] National Institute of Standards and Technology (NIST), FIPS 186-3: Digital Signature Standard (DSS), June 2009.
[DSS]国立標準技術研究所（NIST）、FIPS 186-3：Digital Signature Standard（DSS）、2009年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, November 2000.
[RFC2986] Nystrom、M。およびB. Kaliski、「PKCS＃10：認定要求構文仕様バージョン1.7」、RFC 2986、2000年11月。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] EastLake 3rd、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, September 2005.
[RFC4211] Schaad、J。、「Internet X.509公開キーインフラストラクチャ証明書リクエストメッセージフォーマット（CRMF）」、RFC 4211、2005年9月。
[RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC 4231, December 2005.
[RFC4231] Nystrom、M。、「HMAC-SHA-224、HMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512 "の識別子およびテストベクター、RFC 4231、2005年12月。
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, June 2008.
[RFC5272] Schaad、J。およびM. Myers、「CMS（CMC）の証明書管理」、RFC 5272、2008年6月。
[RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC): Transport Protocols", RFC 5273, June 2008.
[RFC5273] Schaad、J。およびM. Myers、「CMS上の証明書管理（CMC）：輸送プロトコル」、RFC 5273、2008年6月。
[RFC5274] Schaad, J. and M. Myers, "Certificate Management Messages over CMS (CMC): Compliance Requirements", RFC 5274, June 2008.
[RFC5274] Schaad、J。およびM. Myers、「CMS上の証明書管理メッセージ（CMC）：コンプライアンス要件」、RFC 5274、2008年6月。
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, January 2010.
[RFC5754] Turner、S。、「暗号化メッセージ構文を使用したSHA2アルゴリズムを使用」、RFC 5754、2010年1月。
[RFC5759] Solinas, J. and L. Zieglar, "Suite B Certificate and Certificate Revocation List (CRL) Profile", RFC 5759, January 2010.
[RFC5759] Solinas、J。およびL. Zieglar、「Suite B証明書および証明書取消リスト（CRL）プロファイル」、RFC 5759、2010年1月。
[RFC6010] Housley, R., Ashmore, S., and C. Wallace, "Cryptographic Message Syntax (CMS) Content Constraints Extension", RFC 6010, September 2010.
[RFC6010] Housley、R.、Ashmore、S。、およびC. Wallace、「暗号化メッセージ構文（CMS）コンテンツ制約拡張」、RFC 6010、2010年9月。
[RFC6318] Housley, R. and J. Solinas, "Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)", RFC 6318, June 2011.
[RFC6318] Housley、R。およびJ. Solinas、「安全/多目的インターネットメールエクステンション（S/MIME）のスイートB」、RFC 6318、2011年6月。
[RFC6402] Schaad, J., "Certificate Management over CMS (CMC) Updates", RFC 6402, November 2011.
[RFC6402] Schaad、J。、「CMS（CMC）更新に関する証明書管理」、RFC 6402、2011年11月。
[SP80057] National Institute of Standards and Technology (NIST), Special Publication 800-57 Part 1: Recommendation for Key Management, March 2007.
[SP80057]国立標準技術研究所（NIST）、特別出版800-57パート1：2007年3月の主要管理のための推奨。
[SP80090] National Institute of Standards and Technology (NIST), Special Publication 800-90: Recommendation for Random Number Generation Using Deterministic Random Number Bits Generators (Revised), March 2007.
[SP80090]国立標準技術研究所（NIST）、特別出版800-90：決定論的乱数BITSジェネレーターを使用した乱数生成の推奨（改訂）、2007年3月。
This section illustrates several potential certificate enrollment and rekey scenarios supported by this profile. This section does not intend to place any limits or restrictions on the use of CMC.
このセクションでは、このプロファイルでサポートされているいくつかの潜在的な証明書の登録と再キーのシナリオを示しています。このセクションでは、CMCの使用に制限または制限を課すつもりはありません。
This section describes three scenarios for authenticating initial enrollment requests:
このセクションでは、初期登録要求を認証するための3つのシナリオについて説明します。
1. Previously installed signature certificate (e.g., Manufacturer Installed Certificate);
1. 以前にインストールされた署名証明書（たとえば、メーカーのインストールされた証明書）。
2. Shared-secret distributed securely out-of-band;
2. 共有秘密分布は安全に帯域外に分散しています。
3. RA authentication.
3. RA認証。
In this scenario, the end-entity has had a signature certificate installed by the cryptographic module manufacturer. As the end-entity already has a signature certificate, it can be used to authenticate a request for a new certificate. The end-entity signs the Full PKI Request with the private key that corresponds to the subject public key of a previously installed signature certificate. The CA will recognize the authorization of the previously installed certificate and issue an appropriate certificate to the end-entity.
このシナリオでは、エンドエンティティには、暗号化モジュールメーカーによってインストールされた署名証明書がありました。エンドエンティティにはすでに署名証明書があるため、新しい証明書のリクエストを認証するために使用できます。エンドエンティティは、以前にインストールされた署名証明書の主題の公開鍵に対応する秘密鍵で完全なPKI要求に署名します。CAは、以前にインストールされた証明書の承認を認識し、エンドエンティティに適切な証明書を発行します。
In this scenario, the CA distributes a shared-secret out-of-band to the end-entity that the end-entity uses to authenticate its certification request. The end-entity signs the Full PKI Request with the private key for which the certification is being requested. The end-entity includes the Identity Proof Version 2 control to authenticate the request using the shared-secret. The CA uses either the Identification control or the Subject in the end-entity's enclosed PKCS #10 or CRMF certification request message to identify the request. The end-entity performs either the POP Link Witness Version 2 mechanism as described in [RFC5272], Section 6.3.1.1, or the Shared-Subject/Subject Distinguished Name (DN) linking mechanism as described in [RFC5272], Section 6.3.2. The Subject in the enclosed PKCS #10 or CRMF certification request does not necessarily match the issued certificate, as it may be used just to help identify the request (and corresponding shared-secret) to the CA.
このシナリオでは、CAは、エンドエンティティが認定リクエストを認証するために使用するエンドエンティティに共有分泌範囲外の外れを分配します。エンドエンティティは、認定が要求されている秘密鍵で完全なPKI要求に署名します。エンドエンティティには、共有分泌範囲を使用してリクエストを認証するID証明バージョン2コントロールが含まれています。CAは、識別コントロールまたはエンドエンティティの囲まれたPKCS＃10またはCRMF認定要求メッセージの被験者のいずれかを使用して、リクエストを識別します。エンドエンティティは、[RFC5272]、セクション6.3.1.1、または[RFC5272]に記載されているように、[RFC5272]に記載されている共有サブスク/サブジェクトの識別名（DN）リンクリンクリンクのリンクされたポップリンク証人バージョン2メカニズムを実行します。。囲まれたPKCS＃10またはCRMF認定リクエストの被験者は、リクエスト（および対応する共有セクレット）をCAに識別するためだけに使用されるため、発行された証明書と必ずしも一致するわけではありません。
In this scenario, the end-entity does not automatically authenticate its enrollment request to the CA, either because the end-entity has nothing to authenticate the request with or because organizational policy requires RA involvement. The end-entity creates a Full PKI Request and sends it to an RA. The RA verifies the authenticity of the request, then, if approved, encapsulates and signs the request as described in Section 5.2, forwarding the new request on to the CA. The Subject in the PKCS #10 or CRMF certification request is not required to match the issued certificate, it may be used just to help identify the request to the RA and/or CA.
このシナリオでは、エンドエンティティがCAに登録要求を自動的に認証するものではありません。これは、エンドエンティティがリクエストを認証するものがない場合、または組織ポリシーにRAの関与が必要であるためです。エンドエンティティは完全なPKIリクエストを作成し、RAに送信します。RAは、リクエストの信ity性を検証し、承認された場合、セクション5.2で説明されているようにリクエストをカプセル化および署名し、新しいリクエストをCAに転送します。PKCS＃10またはCRMF認定リクエストの主題は、発行された証明書と一致する必要はありません。RAおよび/またはCAのリクエストを特定するためだけに使用できます。
There are two scenarios to support the rekey of certificates that are already enrolled. One addresses the rekey of signature certificates and the other addresses the rekey of key establishment certificates. Typically, organizational policy will require certificates to be currently valid to be rekeyed, and it may require initial enrollment to be repeated when rekey is not possible. However, some organizational policies might allow a grace period during which an expired certificate could be used to rekey.
すでに登録されている証明書の再キーをサポートする2つのシナリオがあります。1つは署名証明書の再キーに対処し、もう1つは主要な設立証明書の再キーに対処します。通常、組織のポリシーでは、現在、再キーを再キーにするために証明書が有効であることを要求し、Rekeyが不可能な場合に初期登録を繰り返す必要がある場合があります。ただし、一部の組織ポリシーでは、期限切れの証明書を使用して再キーを使用することができる場合があります。
When a signature certificate is rekeyed, the PKCS #10 or CRMF certification request message enclosed in the Full PKI Request will include the same Subject as the current signature certificate. The Full PKI Request will be signed by the current private key corresponding to the current signature certificate.
署名証明書が再キーになった場合、完全なPKI要求に囲まれたPKCS＃10またはCRMF認定要求メッセージには、現在の署名証明書と同じ件名が含まれます。完全なPKI要求は、現在の署名証明書に対応する現在の秘密鍵によって署名されます。
When a key establishment certificate is rekeyed, the Full PKI Request will generally be signed by the current private key corresponding to the current signature certificate. If there is no current signature certificate, one of the initial enrollment options in Appendix A.1 may be used.
キー設立証明書が再キーになった場合、完全なPKI要求は通常、現在の署名証明書に対応する現在の秘密鍵によって署名されます。現在の署名証明書がない場合、付録A.1の初期登録オプションの1つを使用できます。
Authors' Addresses
著者のアドレス
Lydia Zieglar National Information Assurance Research Laboratory National Security Agency
リディア・ジーグラー国家情報保証研究研究所国家安全保障局
EMail: llziegl@tycho.ncsc.mil
Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA
Sean Turner IECA、Inc。3057 Nutley Street、Suite 106 Fairfax、VA 22031 USA
EMail: turners@ieca.com
Michael Peck
マイケル・ペック
EMail: mpeck@alumni.virginia.edu