[要約] 要約：RFC 8756は、商用国家安全アルゴリズム（CNSA）スイートプロファイルに関するものであり、CMS上の証明書管理についてのガイドラインを提供しています。目的：このRFCの目的は、CNSAスイートプロファイルを使用して証明書管理を行うための標準化された手順とプロトコルを提供することです。
Independent Submission M. Jenkins
Request for Comments: 8756 L. Zieglar
Category: Informational NSA
ISSN: 2070-1721 March 2020
Commercial National Security Algorithm (CNSA) Suite Profile of Certificate Management over CMS
CMSによる証明書管理の商用国家安全保障アルゴリズム（CNSA）スイートプロファイル
Abstract
概要
This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing X.509 public key certificates in applications that use the Commercial National Security Algorithm (CNSA) Suite published by the United States Government.
このドキュメントでは、米国政府によって発行された商用国家安全保障アルゴリズム（CNSA）スイートを使用するアプリケーションでX.509公開鍵証明書を管理するためのCMS（CMS）プロトコルを介した証明書管理のプロファイルを指定します。
The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that manage X.509 public key certificates over CMS. It is also appropriate for all other US Government systems that process high-value information.
このプロファイルは、CMSを介してX.509公開鍵証明書を管理するUS National Security Systemsのすべてのコンポーネントの機能、構成、および操作に適用されます。また、高価値の情報を処理する他のすべての米国政府システムにも適しています。
The profile is made publicly available here for use by developers and operators of these and any other system deployments.
プロファイルは、これらおよびその他のシステム展開の開発者およびオペレーターが使用できるように、ここで公開されています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc8756.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8756で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction
1.1. Terminology
2. The Commercial National Security Algorithm Suite
3. Requirements and Assumptions
4. Client Requirements: Generating PKI Requests
4.1. Tagged Certification Request
4.2. Certificate Request Message
5. RA Requirements
5.1. RA Processing of Requests
5.2. RA-Generated PKI Requests
5.3. RA-Generated PKI Responses
6. CA Requirements
6.1. CA Processing of PKI Requests
6.2. CA-Generated PKI Responses
7. Client Requirements: Processing PKI Responses
8. Shared-Secrets
9. Security Considerations
10. IANA Considerations
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Scenarios
A.1. Initial Enrollment
A.2. Rekey
Authors' Addresses
This document specifies a profile of the Certificate Management over CMS (CMC) protocol to comply with the United States National Security Agency's Commercial National Security Algorithm (CNSA) Suite [CNSA]. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems [SP80059]. It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.
このドキュメントは、米国国家安全保障局の商用国家安全保障アルゴリズム（CNSA）スイート[CNSA]に準拠するためのCMS（CMC）プロトコルを介した証明書管理のプロファイルを指定します。このプロファイルは、US National Security Systems [SP80059]のすべてのコンポーネントの機能、構成、および操作に適用されます。また、高価値の情報を処理する他のすべての米国政府システムにも適しています。これらおよびその他のシステム展開の開発者およびオペレーターが使用できるように公開されています。
This document does not define any new cryptographic algorithm suites; instead, it defines a CNSA-compliant profile of CMC. CMC is defined in [RFC5272], [RFC5273], and [RFC5274] and is updated by [RFC6402]. This document profiles CMC to manage X.509 public key certificates in compliance with the CNSA Suite Certificate and Certificate Revocation List (CRL) profile [RFC8603]. This document specifically focuses on defining CMC interactions for both the initial enrollment and rekey of CNSA Suite 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.
このドキュメントでは、新しい暗号化アルゴリズムスイートを定義していません。代わりに、CMCのCNSA準拠プロファイルを定義します。 CMCは[RFC5272]、[RFC5273]、および[RFC5274]で定義され、[RFC6402]によって更新されます。このドキュメントは、CNSA Suite証明書および証明書失効リスト（CRL）プロファイル[RFC8603]に準拠してX.509公開鍵証明書を管理するようにCMCをプロファイルしています。このドキュメントでは特に、クライアントと認証局（CA）間のCNSA Suite公開鍵証明書の初期登録と鍵再生成の両方に対するCMC相互作用の定義に焦点を当てています。 1つまたは複数の登録機関（RA）が、クライアントとCAの間の仲介者として機能する場合があります。このプロファイルは、特定のコミュニティによって、ニーズに合わせてさらに調整される場合があります。特定のコミュニティは、実装が準拠する必要がある証明書ポリシーも定義します。
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]で説明されているように解釈されます。
The terminology in [RFC5272], Section 2.1 applies to this profile.
[RFC5272]の用語、セクション2.1がこのプロファイルに適用されます。
The term "certificate request" is used to refer to a single PKCS #10 or Certificate Request Message Format (CRMF) structure. All PKI Requests are Full PKI Requests, and all PKI Responses are Full PKI Responses; the respective set of terms should be interpreted synonymously in this document.
「証明書要求」という用語は、単一のPKCS＃10または証明書要求メッセージフォーマット（CRMF）構造を指すために使用されます。すべてのPKI要求は完全なPKI要求であり、すべてのPKI応答は完全なPKI応答です。このドキュメントでは、それぞれの用語セットを同義に解釈する必要があります。
The National Security Agency (NSA) profiles commercial cryptographic algorithms and protocols as part of its mission to support secure, interoperable communications for US Government National Security Systems. To this end, it publishes guidance both to assist with the US Government transition to new algorithms and to provide vendors -- and the Internet community in general -- with information concerning their proper use and configuration within the scope of US Government National Security Systems.
国家安全保障局（NSA）は、米国政府の国家安全保障システムのための安全で相互運用可能な通信をサポートするという使命の一環として、商用暗号アルゴリズムとプロトコルをプロファイルしています。この目的のために、米国政府による新しいアルゴリズムへの移行を支援するためのガイダンスと、米国政府の国家安全保障システムの範囲内での適切な使用と構成に関する情報をベンダー（およびインターネットコミュニティ全般）に提供するためのガイダンスを公開しています。
Recently, cryptographic transition plans have become overshadowed by the prospect of the development of a cryptographically relevant quantum computer. The NSA has established the Commercial National Security Algorithm (CNSA) Suite to provide vendors and IT users near-term flexibility in meeting their cybersecurity interoperability requirements. The purpose behind this flexibility is to avoid having vendors and customers make two major transitions in a relatively short timeframe, as we anticipate a need to shift to quantum-resistant cryptography in the near future.
最近、暗号化の移行計画は、暗号化に関連する量子コンピューターの開発の見通しに影を落としました。 NSAは商用の国家安全保障アルゴリズム（CNSA）スイートを確立して、サイバーセキュリティの相互運用性の要件を満たすベンダーとITユーザーに近い将来の柔軟性を提供します。この柔軟性の背後にある目的は、近い将来量子耐性暗号に移行する必要があると予想されるため、ベンダーと顧客が比較的短い時間枠で2つの主要な移行を行うことを回避することです。
The NSA is authoring a set of RFCs, including this one, to provide updated guidance concerning the use of certain commonly available commercial algorithms in IETF protocols. These RFCs can be used in conjunction with other RFCs and cryptographic guidance (e.g., NIST Special Publications) to properly protect Internet traffic and data-at-rest for US Government National Security Systems.
NSAは、IETFプロトコルで一般的に利用可能な特定の商用アルゴリズムの使用に関する最新のガイダンスを提供するために、これを含む一連のRFCを作成しています。これらのRFCは、他のRFCおよび暗号化ガイダンス（NIST特別出版物など）と組み合わせて使用して、米国政府の国家安全保障システムのインターネットトラフィックと保管データを適切に保護できます。
Elliptic Curve Digital Signature Algorithm (ECDSA) and Elliptic Curve Diffie-Hellman (ECDH) key pairs are on the P-384 curve. FIPS 186-4 [FIPS186], Appendix B.4 provides useful guidance for elliptic curve key pair generation that SHOULD be followed by systems that conform to this document.
楕円曲線デジタル署名アルゴリズム（ECDSA）と楕円曲線Diffie-Hellman（ECDH）のキーペアは、P-384曲線上にあります。 FIPS 186-4 [FIPS186]、付録B.4は、このドキュメントに準拠するシステムが従うべき楕円曲線鍵ペアの生成に関する有用なガイダンスを提供します。
RSA key pairs (public, private) are identified by the modulus size expressed in bits; RSA-3072 and RSA-4096 are computed using moduli of 3072 bits and 4096 bits, respectively.
RSA鍵のペア（公開、秘密）は、ビット単位で表される係数サイズによって識別されます。 RSA-3072およびRSA-4096は、それぞれ3072ビットおよび4096ビットの係数を使用して計算されます。
RSA signature key pairs used in CNSA Suite-compliant implementations are either RSA-3072 or RSA-4096. The RSA exponent e MUST satisfy 2^(16) < e < 2^(256) and be odd per [FIPS186].
CNSA Suite準拠の実装で使用されるRSA署名鍵ペアは、RSA-3072またはRSA-4096のいずれかです。 RSA指数eは2 ^（16）<e <2 ^（256）を満たし、[FIPS186]ごとに奇数でなければなりません。
It is recognized that, while the vast majority of RSA signatures are currently made using the RSASSA-PKCS1-v1_5 algorithm, the preferred RSA signature scheme for new applications is RSASSA-PSS. CNSA Suite-compliant X.509 certificates will be issued in accordance with [RFC8603], and while those certificates must be signed and validated using RSASSA-PKCS1-v1_5, the subject's private key can be used to generate signatures of either signing scheme. Where use of RSASSA-PSS is indicated in this document, the following parameters apply:
現在、RSA署名の大部分はRSASSA-PKCS1-v1_5アルゴリズムを使用して作成されていますが、新しいアプリケーションに推奨されるRSA署名方式はRSASSA-PSSです。 CNSA Suite準拠のX.509証明書は[RFC8603]に従って発行されます。これらの証明書はRSASSA-PKCS1-v1_5を使用して署名および検証される必要がありますが、サブジェクトの秘密鍵を使用して、いずれかの署名スキームの署名を生成できます。このドキュメントでRSASSA-PSSの使用が示されている場合、次のパラメーターが適用されます。
* The hash algorithm MUST be id-sha384 as defined in [RFC8017];
* [RFC8017]で定義されているように、ハッシュアルゴリズムはid-sha384でなければなりません。
* The mask generation function MUST use the algorithm identifier mfg1SHA384Identifier as defined in [RFC4055];
* マスク生成関数は、[RFC4055]で定義されているアルゴリズム識別子mfg1SHA384Identifierを使用する必要があります。
* The salt length MUST be 48 octets; and
* ソルトの長さは48オクテットでなければなりません。そして
* The trailerField MUST have value 1.
* TrailerFieldの値は1でなければなりません。
These parameters will not appear in a certificate and MUST be securely communicated with the signature, as required by Section 2.2 of [RFC4056]. Application developers are obliged to ensure that the chosen signature scheme is appropriate for the application and will be interoperable within the intended operating scope of the application.
これらのパラメータは証明書には表示されず、[RFC4056]のセクション2.2で要求されているように、署名と安全に通信する必要があります。アプリケーション開発者は、選択した署名方式がアプリケーションに適切であり、アプリケーションの意図された操作範囲内で相互運用可能であることを確認する義務があります。
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 CMC does (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と同じように「キー更新」という用語を使用しています（[RFC5272]のセクション2で定義）。このプロファイルでは、「更新」操作を実行する機能について具体的な説明はありません。ただし、「更新」に適用されるステートメントは、「更新」にも適用する必要があります。
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 discuss 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.
このプロファイルは、所有証明のための鍵確立鍵でワンタイム署名を生成できない暗号モジュールからの鍵確立認証要求については説明しません。その場合、別の所有証明技術の使用を定義するには、別のプロファイルが必要になります。
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 in accordance with [RFC8755]. The PKIData content type defined in [RFC5272] is used with the following additional requirements:
完全なPKI要求を使用する必要があります。 SignedDataにカプセル化する必要があります。そしてSignedDataは[RFC8755]に従って構築されなければなりません。 [RFC5272]で定義されているPKIDataコンテンツタイプは、次の追加要件とともに使用されます。
* controlSequence SHOULD be present.
* controlSequenceが存在する必要があります。
- TransactionId and SenderNonce SHOULD be included. Other CMC controls MAY be included.
- TransactionIdとSenderNonceを含める必要があります。他のCMCコントロールが含まれる場合があります。
- If the request is being authenticated using a shared-secret, then Identity Proof Version 2 control MUST be included with the following constraints:
- リクエストが共有シークレットを使用して認証されている場合は、Identity Proofバージョン2コントロールを次の制約とともに含める必要があります。
o hashAlgId MUST be id-sha384 for all certification requests (algorithm OIDs are defined in [RFC5754]).
o hashAlgIdは、すべての認証要求でid-sha384でなければなりません（アルゴリズムOIDは[RFC5754]で定義されています）。
o macAlgId MUST be HMAC-SHA384 (the Hashed Message Authentication Code (HMAC) algorithm is defined in [RFC4231]).
o macAlgIdはHMAC-SHA384でなければなりません（ハッシュメッセージ認証コード（HMAC）アルゴリズムは[RFC4231]で定義されています）。
- If the subject name 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 [RFC2986] or Certificate Request Message Format (CRMF) [RFC4211] request as described in Sections 4.1 and 4.2.
- 認証要求に含まれるサブジェクト名がNULLであるか、エンドエンティティを一意に識別しない場合は、POPリンクランダムコントロールを含める必要があり、POPリンク監視バージョン2コントロールを内部PKCS＃10に含める必要があります[ RFC2986]またはセクション4.1および4.2で説明されている証明書要求メッセージ形式（CRMF）[RFC4211]要求。
* 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.
* reqSequenceが存在する必要があります。少なくとも1つのtcr（セクション4.1を参照）またはcrm（セクション4.2を参照）TaggedRequestを含める必要があります。 ormの選択のサポートはオプションです。
The private signing key used to generate the encapsulating SignedData MUST correspond to the public key of an existing signature certificate unless an appropriate signature certificate does not yet exist, such as during initial enrollment.
カプセル化するSignedDataの生成に使用される秘密署名鍵は、初期登録時などに適切な署名証明書がまだ存在しない場合を除き、既存の署名証明書の公開鍵に対応している必要があります。
The encapsulating SignedData MUST be generated using SHA-384 and either ECDSA on P-384 or RSA using either RSASSA-PKCS1-v1_5 or RSASSA-PSS with an RSA-3072 or RSA-4096 key.
カプセル化するSignedDataは、SHA-384およびP-384上のECDSAまたはRSA-3072またはRSA-4096キーを使用したRSASSA-PKCS1-v1_5またはRSASSA-PSSを使用するRSAを使用して生成する必要があります。
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要求は、鍵確立証明書での使用を目的とした鍵ペアを使用して署名できます（MAY）。ただし、サーバーがこの動作を許可する必要はありません。
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]構文を伝えます。 CertificateRequestは、[RFC5272]のセクション3.2.1.2.1に準拠する必要があり、次の追加要件があります。
* certificationRequestInfo:
* certificateRequestInfo：
- subjectPublicKeyInfo MUST be set as defined in Section 5.4 of [RFC8603].
- subjectPublicKeyInfoは、[RFC8603]のセクション5.4の定義に従って設定する必要があります。
- Attributes:
- 属性：
o The ExtensionReq attribute MUST be included with its contents as follows:
o ExtensionReq属性は、次のようにそのコンテンツに含める必要があります。
+ The keyUsage extension MUST be included, and it MUST be set as defined in [RFC8603].
+ keyUsage拡張が含まれている必要があり、[RFC8603]で定義されているように設定する必要があります。
+ 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.
+ キーの再生成要求の場合、SubjectAltName拡張機能を含めて、リクエストのカプセル化に使用されている証明書のSubjectAltNameに等しく設定する必要があります（つまり、再生成される証明書ではなく）、証明書のサブジェクトフィールドが生成に使用されている場合。署名はNULLです。
+ 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 field or SubjectAltName extension does not match the desired subject name or SubjectAltName extension of this certification request.
o [RFC6402]で定義されているChangeSubjectName属性は、このタグ付き証明書リクエストをカプセル化する完全なPKIリクエストが、現在証明書が存在するキーによって署名されており、既存の証明書のサブジェクトフィールドまたはSubjectAltName拡張が希望するものと一致しない場合に含める必要があります。この認証要求のサブジェクト名またはSubjectAltName拡張。
o The POP Link Witness Version 2 attribute MUST be included if the request is being authenticated using a shared-secret and the subject name 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-sha384 for certification requests, as defined in [RFC5754]; macAlgorithm MUST be HMAC-SHA384, as defined in [RFC4231].
o POPリンク監視バージョン2属性は、リクエストが共有シークレットを使用して認証され、認証リクエストのサブジェクト名がNULLであるか、エンドエンティティを一意に識別しない場合に含める必要があります。 [RFC5754]で定義されているように、POPリンク監視バージョン2属性では、認証要求のkeyGenAlgorithmはid-sha384でなければなりません。 [RFC4231]で定義されているように、macAlgorithmはHMAC-SHA384でなければなりません。
- signatureAlgorithm MUST be ecdsa-with-sha384 for P-384 certification requests and sha384WithRSAEncryption or id-RSASSA-PSS for RSA-3072 and RSA-4096 certification requests.
- signatureAlgorithmは、P-384認証要求の場合はecdsa-with-sha384、RSA-3072およびRSA-4096認証要求の場合はsha384WithRSAEncryptionまたはid-RSASSA-PSSでなければなりません。
- 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 CA.
- 署名は、署名と鍵確立の認証要求の両方について、CertificationRequestInfoの公開鍵に対応する秘密鍵を使用して生成する必要があります。署名は、秘密鍵の所持証明をCAに提供します。
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の選択は、証明書要求メッセージ形式（CRMF）[RFC4211]構文を伝達します。 CertReqMsgは、[RFC5272]のセクション3.2.1.2.2に準拠する必要があり、次の追加要件があります。
* popo MUST be included using the signature (POPOSigningKey) proof-of-possession choice and be set as defined in [RFC4211], Section 4.1 for both signature and key establishment certification requests. The POPOSigningKey poposkInput field MUST be omitted. The POPOSigningKey algorithmIdentifier MUST be ecdsa-with-sha384 for P-384 certification requests and sha384WithRSAEncryption or id-RSASSA-PSS for RSA-3072 and RSA-4096 certification requests. The signature MUST be generated using the private key corresponding to the public key in the CertTemplate.
* popoは、署名（POPOSigningKey）の所有証明の選択を使用して含まれている必要があり、[RFC4211]のセクション4.1で定義されているように、署名と鍵の確立の認証リクエストの両方に対して設定する必要があります。 POPOSigningKey poposkInputフィールドは省略しなければなりません。 POPOSigningKeyアルゴリズムIDは、P-384認証要求の場合はecdsa-with-sha384、RSA-3072およびRSA-4096認証要求の場合はsha384WithRSAEncryptionまたはid-RSASSA-PSSでなければなりません。署名は、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に準拠する必要があり、次の追加要件があります。
* If version is included, it MUST be set to 2 as defined in Section 5.3 of [RFC8603].
* バージョンが含まれている場合は、[RFC8603]のセクション5.3で定義されているように、バージョンを2に設定する必要があります。
* publicKey MUST be set as defined in Section 5.4 of [RFC8603].
* [RFC8603]のセクション5.4で定義されているとおりにpublicKeyを設定する必要があります。
* Extensions:
* 拡張：
- The keyUsage extension MUST be included, and it MUST be set as defined in [RFC8603].
- keyUsage拡張が含まれている必要があり、[RFC8603]で定義されているように設定する必要があります。
- 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 name of the certificate being used to generate the signature is NULL.
- キーの再生成要求の場合、SubjectAltName拡張機能を含めて、要求のカプセル化に使用されているSignedDataの署名に使用されている証明書のSubjectAltNameと等しく設定する必要があります（つまり、再生成される証明書ではなく）、証明書のサブジェクト名が生成に使用されている場合署名はNULLです。
- Other extension requests MAY be included as desired.
- その他の拡張リクエストは、必要に応じて含めることができます。
* Controls:
* コントロール：
- 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 name or SubjectAltName extension does not match the desired subject name or SubjectAltName extension of this certification request.
- [RFC6402]で定義されているChangeSubjectName属性は、このタグ付き証明書リクエストをカプセル化する完全なPKIリクエストが、現在証明書が存在し、既存の証明書のサブジェクト名またはSubjectAltName拡張が目的のキーと一致しないキーによって署名されている場合に含める必要があります。この認証要求のサブジェクト名またはSubjectAltName拡張。
- The POP Link Witness Version 2 attribute MUST be included if the request is being authenticated using a shared-secret and the subject name 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-sha384 for certification requests; macAlgorithm MUST be HMAC-SHA384 when keyGenAlgorithm is id-sha384.
- POPリンク監視バージョン2属性は、リクエストが共有シークレットを使用して認証され、認証リクエストのサブジェクト名がNULLであるか、エンドエンティティを一意に識別しない場合に含める必要があります。 POPリンク監視バージョン2属性では、認証要求のkeyGenAlgorithmはid-sha384でなければなりません。 keyGenAlgorithmがid-sha384の場合、macAlgorithmはHMAC-SHA384でなければなりません。
This section addresses the optional case where one or more RAs act as intermediaries between clients and a 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要求を受信したエンティティを指します。このセクションは、RAにのみ適用されます。
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].
このドキュメントに準拠するRAは、このプロファイル全体で説明されている許可された署名、ハッシュ、およびMACアルゴリズムのみがリクエストで使用されるようにする必要があります。そうでない場合、RAはそれらの要求を拒否する必要があります。 RAは、badAlg [RFC5272]の値を持つCMCFailInfoを返す必要があります（SHOULD）。
When processing end-entity-generated SignedData objects, RAs MUST NOT perform Cryptographic Message Syntax (CMS) Content Constraints (CCC) certificate extension processing [RFC6010].
エンドエンティティで生成されたSignedDataオブジェクトを処理する場合、RAは暗号化メッセージ構文（CMS）コンテンツ制約（CCC）証明書拡張処理[RFC6010]を実行してはならない（MUST NOT）。
Other RA processing is performed as described in [RFC5272].
[RFC5272]で説明されているように、他のRA処理が実行されます。
RAs mediate the certificate request process by collecting client requests in batches. The RA MUST encapsulate client-generated PKI Requests in a new RA-signed PKI Request, it MUST create a Full PKI Request encapsulated in a SignedData, and the SignedData MUST be constructed in accordance with [RFC8755]. The PKIData content type complies with [RFC5272] with the following additional requirements:
RAは、クライアント要求をバッチで収集することにより、証明書要求プロセスを仲介します。 RAは、クライアントが生成したPKI要求を新しいRA署名付きPKI要求にカプセル化し、SignedDataにカプセル化された完全なPKI要求を作成する必要があり、SignedDataは[RFC8755]に従って構築する必要があります。 PKIDataコンテンツタイプは、[RFC5272]に準拠しており、次の追加要件があります。
* 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.
* controlSequenceが存在する必要があります。次のCMCコントロールを含める必要があります：トランザクションID、送信者ナンス、およびバッチリクエスト。他の適切なCMCコントロールが含まれる場合があります。
* cmsSequence MUST be present. It contains the original, unmodified request(s) received from the client.
* cmsSequenceが存在する必要があります。クライアントから受信した、変更されていない元のリクエストが含まれています。
SignedData (applied by the RA)
PKIData
controlSequence (Transaction ID, Sender Nonce,
Batch Requests)
cmsSequence
SignedData (applied by client)
PKIData
controlSequence (Transaction ID, Sender Nonce)
reqSequence
TaggedRequest
{TaggedRequest}
{SignedData (second client request)
PKIData...}
Authorization to sign RA-generated Full PKI Requests SHOULD be indicated in the RA certificate by inclusion of the id-kp-cmcRA Extended Key Usage (EKU) from [RFC6402]. The RA certificate MAY also include the CCC certificate extension [RFC6010], or it MAY indicate authorization through inclusion of the CCC certificate extension alone. The RA certificate may also be authorized through the local configuration.
[RFC6402]のid-kp-cmcRA拡張キー使用法（EKU）を含めることにより、RA生成の完全なPKI要求に署名するための承認をRA証明書に示す必要があります（SHOULD）。 RA証明書には、CCC証明書拡張[RFC6010]も含まれる場合があります。または、CCC証明書拡張のみを含めることで承認を示す場合があります。 RA証明書は、ローカル構成を通じて承認される場合もあります。
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がCCC拡張を介して承認される場合、CCC拡張にはPKIDataコンテンツタイプのオブジェクト識別子を含める必要があります。生成されるコンテンツタイプに制約を課す場合は、CCCを含める必要があります。
The outer SignedData MUST be generated using SHA-384 and either ECDSA on P-384 or RSA using RSASSA-PKCS1-v1_5 or RSASSA-PSS with an RSA-3072 or RSA-4096 key.
外側のSignedDataは、SHA-384およびP-384上のECDSAまたはRSA-3072またはRSA-4096キーを使用したRSASSA-PKCS1-v1_5またはRSASSA-PSSを使用するRSAを使用して生成する必要があります。
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 algorithm used in the response MUST match the algorithm used in the request.
完全なPKI応答が、Get CertificateまたはGet CRLコントロールのみを含んだPKI要求に対する成功した応答である場合、応答で使用されるアルゴリズムは、要求で使用されるアルゴリズムと一致する必要があります。
In order for an RA certificate using the CCC certificate extension to be authorized to generate responses, the object identifier for the PKIResponse content type must be present in the CCC certificate extension.
CCC証明書拡張を使用するRA証明書が応答の生成を許可されるためには、PKIResponseコンテンツタイプのオブジェクト識別子がCCC証明書拡張に存在している必要があります。
This section specifies the requirements for CAs that receive PKI Requests and generate PKI Responses.
このセクションでは、PKI要求を受信してPKI応答を生成するCAの要件を指定します。
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 a CMCStatus of failed and a CMCFailInfo with the value of badAlg [RFC5272].
このドキュメントに準拠するCAは、このプロファイル全体で説明されている許可された署名、ハッシュ、およびMACアルゴリズムのみがリクエストで使用されるようにする必要があります。そうでない場合、CAはそれらの要求を拒否する必要があります。 CAは、CMCStatusがfailedで、CMCFailInfoがbadAlg [RFC5272]の値であるCMCStatusInfoV2コントロールを返す必要があります（SHOULD）。
For requests involving an RA (i.e., batched requests), 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 keyUsage 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 a CMCStatus of failed and a CMCFailInfo with a value of badRequest.
RAを含むリクエスト（つまり、バッチリクエスト）の場合、CAはRAの承認を確認する必要があります。次の証明書フィールドは、証明書要求の変更コントロールを使用して変更できません：publicKeyおよびkeyUsage拡張。これらの認証要求フィールドを変更する試みが存在する場合、要求は拒否されなければなりません（MUST）。 CAは、CMCStatusがfailedで、CMCFailInfoがbadRequestの値を持つCMCStatusInfoV2コントロールを返す必要があります（SHOULD）。
When processing end-entity-generated SignedData objects, CAs MUST NOT perform CCC certificate extension processing [RFC6010].
エンドエンティティによって生成されたSignedDataオブジェクトを処理するとき、CAはCCC証明書拡張処理を実行してはなりません[RFC6010]。
If a client-generated PKI Request includes the ChangeSubjectName attribute as described in Section 4.1 or 4.2 above, the CA MUST ensure that name change is authorized. The mechanism for ensuring that the name change is authorized is out of scope. A CA that performs this check and finds that the name change is not authorized MUST reject the PKI Request. The CA SHOULD return an Extended CMC Status Info control (CMCStatusInfoV2) with a CMCStatus of failed.
上記のセクション4.1または4.2で説明されているように、クライアントが生成したPKI要求にChangeSubjectName属性が含まれている場合、CAは名前の変更が承認されていることを確認する必要があります。名前の変更を確実に許可するメカニズムは範囲外です。このチェックを実行し、名前の変更が許可されていないことを検出したCAは、PKI要求を拒否する必要があります。 CAは、CMCStatusがfailedの拡張CMCステータス情報コントロール（CMCStatusInfoV2）を返す必要があります（SHOULD）。
Other processing of PKIRequests is performed as described in [RFC5272].
[RFC5272]で説明されているように、PKIRequestsの他の処理が実行されます。
CAs send PKI Responses to both client-generated requests and RA-generated requests. If a Full PKI Response is returned in direct response to a client-generated request, it MUST be encapsulated in a SignedData, and the SignedData MUST be constructed in accordance with [RFC8755].
CAは、クライアントが生成した要求とRAが生成した要求の両方にPKI応答を送信します。完全なPKI応答がクライアント生成の要求への直接の応答で返される場合、それはSignedDataにカプセル化されなければならず（MUST）、SignedDataは[RFC8755]に従って構築されなければならない（MUST）。
If the PKI Response is in response to an RA-generated 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 in accordance with [RFC8755]. 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応答はSignedDataにカプセル化されなければならず（MUST）、SignedDataは[RFC8755]に従って構築されなければならない（MUST）。上記のPKI応答は、カプセル化PKI応答のcmsSequenceフィールドに配置されます。他のフィールドは上記と同じで、controlSequenceにバッチ応答コントロールが追加されています。以下は、RAでカプセル化されたPKI要求に対する成功したCA応答を示しています。どちらにもトランザクションIDとノンスが含まれています。
SignedData (applied by the CA) PKIResponse controlSequence (Transaction ID, Sender Nonce, Recipient Nonce, Batch Response) cmsSequence SignedData (applied by CA and includes returned certificates) PKIResponse controlSequence (Transaction ID, Sender Nonce, Recipient Nonce)
SignedData（CAによって適用）PKIResponse controlSequence（トランザクションID、送信者ナンス、受信者ノンス、バッチ応答）cmsSequence SignedData（CAによって適用され、返された証明書を含む）PKIResponse controlSequence（トランザクションID、送信者ノンス、受信者ノンス）
The same private key used to sign certificates MUST NOT be used to sign Full PKI Response messages. Instead, a separate certificate indicating authorization to sign CMC responses MUST be used.
証明書の署名に使用したのと同じ秘密鍵を、完全なPKI応答メッセージの署名に使用してはなりません（MUST NOT）。代わりに、CMC応答に署名する権限を示す別の証明書を使用する必要があります。
Authorization to sign Full PKI Responses SHOULD be indicated in the CA certificate by inclusion of the id-kp-cmcCA EKU from [RFC6402]. The CA certificate MAY also include the CCC certificate extension [RFC6010], or it MAY indicate authorization through inclusion of the CCC certificate extension alone. The CA certificate may also be authorized through local configuration.
[RFC6402]のid-kp-cmcCA EKUを含めることにより、完全なPKI応答に署名するための承認をCA証明書に示す必要があります。 CA証明書には、CCC証明書拡張[RFC6010]も含まれる場合があります。または、CCC証明書拡張のみを含めることで認証を示す場合があります。 CA証明書は、ローカル設定を通じて承認される場合もあります。
In order for a CA certificate using the CCC certificate extension to be authorized to generate responses, the object identifier for the PKIResponse content type must be present in the CCC certificate extension. CCC SHOULD be included if constraints are to be placed on the content types generated.
CCC証明書拡張を使用するCA証明書が応答の生成を許可されるようにするには、PKIResponseコンテンツタイプのオブジェクト識別子がCCC証明書拡張に存在する必要があります。生成されるコンテンツタイプに制約を課す場合は、CCCを含める必要があります。
Signatures applied to individual certificates are as required in [RFC8603].
個々の証明書に適用される署名は、[RFC8603]で要求されているとおりです。
The signature on the SignedData of a successful response to a client-generated request, or each individual inner SignedData on the successful response to an RA-generated request, MUST be generated using SHA-384 and either ECDSA on P-384 or RSA using RSASSA-PKCS1-v1_5 or RSASSA-PSS with an RSA-3072 or RSA-4096 key. An unsuccessful response MUST be signed using the same key type and algorithm that signed the request.
クライアント生成要求への成功応答のSignedDataの署名、またはRA生成要求への成功応答の各個別のSignedDataは、SHA-384およびP-384のECDSAまたはRSASSAを使用したRSAを使用して生成する必要があります。 -RSA-3072またはRSA-4096キーを使用したPKCS1-v1_5またはRSASSA-PSS。失敗した応答は、要求に署名したのと同じ鍵タイプとアルゴリズムを使用して署名する必要があります。
The outer SignedData on the Full PKI Response to any RA-generated PKI Request MUST be signed with the same key type and algorithm that signed the request.
RAで生成されたPKI要求に対する完全なPKI応答の外側のSignedDataは、要求に署名したのと同じ鍵タイプとアルゴリズムで署名する必要があります。
The SignedData on a successful Full PKI Response to a PKI Request that only contained a Get Certificate or Get CRL control MUST be signed with the same key type and algorithm that signed the request.
Get CertificateまたはGet CRLコントロールのみを含んだPKI要求に対する成功した完全な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 a CCC extension that includes the object identifier for the PKIResponse content type. Otherwise, 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 extension that includes the object identifier for the PKIResponse content type. Otherwise, the RA is determined to be authorized to sign responses through local configuration.
クライアントはすべての完全なPKI応答を認証する必要があります。これには、PKI応答が信頼できるCAまたはRAによって署名されていることの検証が含まれます。承認されたCA証明書には、id-kp-cmcCA EKUおよび/またはPKIResponseコンテンツタイプのオブジェクト識別子を含むCCC拡張を含める必要があります。それ以外の場合、CAは、実装固有のメカニズムを通じて応答に署名することを許可されていると判断されます。 PKI応答は、エラーメッセージである場合、Get CertificateまたはGet CRL要求への応答である場合、またはPKI応答にCAによって署名された内部PKI応答が含まれる場合、RAによって署名できます。最後のケースでは、PKI応答の各層には、エンティティによって署名された、承認された有効な署名が含まれている必要があります。承認されたRA証明書には、id-kp-cmcRA EKUを含めるか、PKIResponseコンテンツタイプのオブジェクト識別子を含むCCC拡張を含める必要があります。それ以外の場合、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 (CMCStatusInfoV2) with the CMCStatus set to failed to a user console, error log, or the server.
クライアントは、これらのテストに合格しないPKI応答を拒否する必要があります。ローカルポリシーは、クライアントが拡張CMCステータス情報コントロール（CMCStatusInfoV2）で完全なPKI応答を返し、CMCStatusがユーザーコンソール、エラーログ、またはサーバーに失敗に設定されているかどうかを判断します。
If the Full PKI Response contains an Extended CMC Status Info control 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がfailedに設定された拡張CMCステータス情報コントロールが含まれている場合、ローカルポリシーは、クライアントが重複した認証要求をサーバーに再送信するか、エラー状態がコンソールまたはエラーログに返されるかを決定します。
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 192 bits of strength.
Identity Proof V2およびPOP Link Witness V2コントロールを使用する場合、共有シークレットをランダムに生成して安全に配布する必要があります。共有シークレットは、少なくとも192ビットの強度を提供する必要があります。
Protocol security considerations are found in [RFC2986], [RFC4211], [RFC8755], [RFC5272], [RFC5273], [RFC5274], [RFC8603], 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 [RFC8755].
プロトコルのセキュリティに関する考慮事項は、[RFC2986]、[RFC4211]、[RFC8755]、[RFC5272]、[RFC5273]、[RFC5274]、[RFC8603]、および[RFC6402]にあります。 CCCを使用してRAおよびCA証明書を承認する場合、[RFC6010]のセキュリティに関する考慮事項も適用されます。アルゴリズムのセキュリティに関する考慮事項は、[RFC8755]にあります。
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回限りの所有証明を除き、1つの鍵ペアを署名と鍵の確立の両方に使用してはなりません（MUST NOT）。
This specification requires implementations to generate key pairs and other random values. The use of inadequate pseudorandom number generators (PRNGs) can result in little or no security. The generation of quality random numbers is difficult. NIST Special Publication 800-90A [SP80090A], FIPS 186-3 [FIPS186], and [RFC4086] offer random number generation guidance.
この仕様では、キーのペアやその他のランダムな値を生成するための実装が必要です。不適切な疑似乱数ジェネレータ（PRNG）を使用すると、セキュリティがほとんどまたはまったく発生しなくなります。高品質の乱数の生成は困難です。 NIST Special Publication 800-90A [SP80090A]、FIPS 186-3 [FIPS186]、および[RFC4086]は、乱数生成のガイダンスを提供します。
When RAs are used, the list of authorized RAs MUST be securely distributed out of band to CAs.
RAを使用する場合は、承認されたRAのリストを帯域外でCAに安全に配布する必要があります。
Presence of the POP Link Witness Version 2 and POP Link Random attributes protects against substitution attacks.
POPリンク監視バージョン2とPOPリンクランダム属性の存在は、置換攻撃を防ぎます。
The certificate policy for a particular environment will specify whether expired certificates can be used to sign certification requests.
特定の環境の証明書ポリシーでは、期限切れの証明書を使用して認証要求に署名できるかどうかを指定します。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[CNSA] Committee on National Security Systems, "Use of Public Standards for Secure Information Sharing", CNSS Policy 15, October 2016, <https://www.cnss.gov/CNSS/issuances/Policies.cfm>.
[CNSA]国家安全保障システム委員会、「安全な情報共有のための公的基準の使用」、2016年10月のCNSSポリシー15、<https://www.cnss.gov/CNSS/issuances/Policies.cfm>。
[FIPS186] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", DOI 10.6028/NIST.FIPS.186-4, FIPS PUB 186-4, July 2013, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf>.
[FIPS186]米国国立標準技術研究所、「デジタル署名標準（DSS）」、DOI 10.6028 / NIST.FIPS.186-4、FIPS PUB 186-4、2013年7月、<http://nvlpubs.nist.gov/ nistpubs / FIPS / NIST.FIPS.186-4.pdf>。
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2986] 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>.
[RFC2986] Nystrom、M。、およびB. Kaliski、「PKCS＃10：Certification Request Syntax Specification Version 1.7」、RFC 2986、DOI 10.17487 / RFC2986、2000年11月、<https://www.rfc-editor.org/info / rfc2986>。
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, DOI 10.17487/RFC4055, June 2005, <https://www.rfc-editor.org/info/rfc4055>.
[RFC4055] Schaad、J.、Kaliski、B。、およびR. Housley、「インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイルで使用するためのRSA暗号化の追加のアルゴリズムおよび識別子」、RFC 4055 、DOI 10.17487 / RFC4055、2005年6月、<https://www.rfc-editor.org/info/rfc4055>。
[RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS)", RFC 4056, DOI 10.17487/RFC4056, June 2005, <https://www.rfc-editor.org/info/rfc4056>.
[RFC4056] Schaad、J。、「暗号化メッセージ構文（CMS）でのRSASSA-PSS署名アルゴリズムの使用」、RFC 4056、DOI 10.17487 / RFC4056、2005年6月、<https://www.rfc-editor.org/ info / rfc4056>。
[RFC4086] 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>.
[RFC4086] 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>。
[RFC4211] 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>.
[RFC4211] Schaad、J。、「Internet X.509 Public Key Infrastructure Certificate Request Message Format（CRMF）」、RFC 4211、DOI 10.17487 / RFC4211、2005年9月、<https://www.rfc-editor.org/info / rfc4211>。
[RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC 4231, DOI 10.17487/RFC4231, December 2005, <https://www.rfc-editor.org/info/rfc4231>.
[RFC4231] Nystrom、M。、「HMAC-SHA-224、HMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512の識別子とテストベクトル」、RFC 4231、DOI 10.17487 / RFC4231、2005年12月、<https://www.rfc-editor.org/info/rfc4231>。
[RFC5272] 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>.
[RFC5272] Schaad、J。およびM. Myers、「CMS（CMC）を介した証明書管理」、RFC 5272、DOI 10.17487 / RFC5272、2008年6月、<https://www.rfc-editor.org/info/rfc5272> 。
[RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC): Transport Protocols", RFC 5273, DOI 10.17487/RFC5273, June 2008, <https://www.rfc-editor.org/info/rfc5273>.
[RFC5273] Schaad、J。およびM. Myers、「CMS（CMC）を介した証明書管理：トランスポートプロトコル」、RFC 5273、DOI 10.17487 / RFC5273、2008年6月、<https://www.rfc-editor.org/info / rfc5273>。
[RFC5274] Schaad, J. and M. Myers, "Certificate Management Messages over CMS (CMC): Compliance Requirements", RFC 5274, DOI 10.17487/RFC5274, June 2008, <https://www.rfc-editor.org/info/rfc5274>.
[RFC5274] Schaad、J。およびM. Myers、「CMS（CMC）を介した証明書管理メッセージ：コンプライアンス要件」、RFC 5274、DOI 10.17487 / RFC5274、2008年6月、<https://www.rfc-editor.org/ info / rfc5274>。
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 2010, <https://www.rfc-editor.org/info/rfc5754>.
[RFC5754] Turner、S。、「Using SHA2 Algorithms with Cryptographic Message Syntax」、RFC 5754、DOI 10.17487 / RFC5754、2010年1月、<https://www.rfc-editor.org/info/rfc5754>。
[RFC6010] Housley, R., Ashmore, S., and C. Wallace, "Cryptographic Message Syntax (CMS) Content Constraints Extension", RFC 6010, DOI 10.17487/RFC6010, September 2010, <https://www.rfc-editor.org/info/rfc6010>.
[RFC6010] Housley、R.、Ashmore、S。、およびC. Wallace、「Cryptographic Message Syntax（CMS）Content Constraints Extension」、RFC 6010、DOI 10.17487 / RFC6010、2010年9月、<https：//www.rfc- editor.org/info/rfc6010>。
[RFC6402] Schaad, J., "Certificate Management over CMS (CMC) Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, <https://www.rfc-editor.org/info/rfc6402>.
[RFC6402] Schaad、J。、「CMS（CMC）更新による証明書管理」、RFC 6402、DOI 10.17487 / RFC6402、2011年11月、<https://www.rfc-editor.org/info/rfc6402>。
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, <https://www.rfc-editor.org/info/rfc8017>.
[RFC8017] Moriarty、K.、Ed。、Kaliski、B.、Jonsson、J.、and A. Rusch、 "PKCS＃1：RSA Cryptography Specifications Version 2.2"、RFC 8017、DOI 10.17487 / RFC8017、November 2016、< https://www.rfc-editor.org/info/rfc8017>。
[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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8603] Jenkins, M. and L. Zieglar, "Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile", RFC 8603, DOI 10.17487/RFC8603, May 2019, <https://www.rfc-editor.org/info/rfc8603>.
[RFC8603] Jenkins、M。およびL. Zieglar、「Commercial National Security Algorithm（CNSA）Suite Certificate and Certificate Revocation List（CRL）Profile」、RFC 8603、DOI 10.17487 / RFC8603、2019年5月、<https：// www。 rfc-editor.org/info/rfc8603>。
[RFC8755] Jenkins, M., "Using Commercial National Security Algorithm Suite Algorithms in Secure/Multipurpose Internet Mail Extensions", RFC 8755, DOI 10.17487/RFC8755, March 2020, <https://www.rfc-editor.org/info/rfc8755>.
[RFC8755] Jenkins、M。、「Secure / Multipurpose Internet Mail ExtensionsでのNational National Security Algorithm Suiteアルゴリズムの使用」、RFC 8755、DOI 10.17487 / RFC8755、2020年3月、<https://www.rfc-editor.org/info / rfc8755>。
[SP80057] National Institute of Standards and Technology, "Recommendation for Key Management, Part 1: General", DOI 10.6028/NIST.SP.800-57pt1r4, Special Publication 800-57, Part 1, Revision 4, January 2016, <http://doi.org/10.6028/NIST.SP.800-57pt1r4>.
[SP80057]米国国立標準技術研究所、「鍵管理の推奨、パート1：一般」、DOI 10.6028 / NIST.SP.800-57pt1r4、特別刊行物800-57、パート1、改訂4、2016年1月、<http ：//doi.org/10.6028/NIST.SP.800-57pt1r4>。
[SP80059] National Institute of Standards and Technology, "Guideline for Identifying an Information System as a National Security System", DOI 10.6028/NIST.SP.800-59, Special Publication 800-59, August 2003, <https://csrc.nist.gov/publications/detail/sp/800-59/ final>.
[SP80059]米国国立標準技術研究所、「情報システムを国家安全保障システムとして特定するためのガイドライン」、DOI 10.6028 / NIST.SP.800-59、特別刊行物800-59、2003年8月、<https：// csrc .nist.gov / publications / detail / sp / 800-59 / final>。
[SP80090A] National Institute of Standards and Technology, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", DOI 10.6028/NIST.SP.800-90Ar1, Special Publication 800-90A Revision 1, June 2015, <http://doi.org/10.6028/NIST.SP.800-90Ar1>.
[SP80090A]米国国立標準技術研究所、「確定的ランダムビットジェネレータを使用した乱数生成の推奨」、DOI 10.6028 / NIST.SP.800-90Ar1、特別刊行物800-90Aリビジョン1、2015年6月、<http：// doi.org/10.6028/NIST.SP.800-90Ar1>。
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 certified signature key-pair (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 a private signing key and a corresponding public key certificate obtained from a cryptographic module manufacturer recognized by the CA. The end-entity signs a Full PKI Request with the private key that corresponds to the subject public key of the previously installed signature certificate. The CA will verify the authorization of the previously installed certificate and issue an appropriate new certificate to the end-entity.
このシナリオでは、エンドエンティティには、CAによって認識された暗号化モジュールの製造元から取得した秘密署名キーと対応する公開キー証明書があります。エンドエンティティは、以前にインストールされた署名証明書のサブジェクト公開キーに対応する秘密キーを使用して、完全な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 name in the end-entity's enclosed PKCS #10 [RFC2986] or CRMF [RFC4211] 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-secret/subject distinguished name linking mechanism as described in [RFC5272], Section 6.3.2. The subject name in the enclosed PKCS #10 [RFC2986] or CRMF [RFC4211] certification request does not necessarily match the issued certificate, as it may be used just to help identify the request (and the corresponding shared-secret) to the CA.
このシナリオでは、CAはエンドエンティティが認証要求の認証に使用するエンドエンティティに帯域外の共有シークレットを配布します。エンドエンティティは、証明書が要求されている秘密キーを使用して、完全なPKI要求に署名します。エンドエンティティには、共有シークレットを使用して要求を認証するためのIdentity Proofバージョン2コントロールが含まれています。 CAは、ID制御またはエンドエンティティの囲まれたPKCS＃10 [RFC2986]またはCRMF [RFC4211]証明書要求メッセージの件名を使用して、要求を識別します。エンドエンティティは、[RFC5272]のセクション6.3.1.1で説明されているPOPリンク監視バージョン2メカニズム、または[RFC5272]のセクション6.3.2で説明されている共有秘密/サブジェクト識別名リンクメカニズムを実行します。囲まれたPKCS＃10 [RFC2986]またはCRMF [RFC4211]証明書要求のサブジェクト名は、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 the organizational policy requires an RA's involvement. The end-entity creates a Full PKI Request and sends it to an RA. The RA verifies the authenticity of the request. If the request is approved, the RA encapsulates and signs the request as described in Section 4.2, forwarding the new request on to the CA. The subject name in the PKCS #10 [RFC2986] or CRMF [RFC4211] 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は要求の信頼性を検証します。リクエストが承認されると、RAはセクション4.2で説明されているようにリクエストをカプセル化して署名し、新しいリクエストをCAに転送します。 PKCS＃10 [RFC2986]またはCRMF [RFC4211]証明書リクエストのサブジェクト名は、発行された証明書と一致する必要はありません。 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つはキー確立証明書のキーの再生成に対処します。通常、組織のポリシーでは、証明書のキーを再発行するには現在有効である必要があり、キーの再発行が不可能な場合は、最初の登録を繰り返す必要がある場合があります。ただし、組織のポリシーによっては、期限切れの証明書を使用して鍵の再生成に使用できる猶予期間が許可されている場合があります。
When a signature certificate is rekeyed, the PKCS #10 [RFC2986] or CRMF [RFC4211] certification request message enclosed in the Full PKI Request will include the same subject name 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 [RFC2986]またはCRMF [RFC4211]証明書要求メッセージには、現在の署名証明書と同じサブジェクト名が含まれます。完全な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の初期登録オプションのいずれかを使用できます。
Authors' Addresses
著者のアドレス
Michael Jenkins National Security Agency
マイケルジェンキンス国家安全保障局
Email: mjjenki@nsa.gov
Lydia Zieglar National Security Agency
リディアジーグラー国家安全保障局
Email: llziegl@tycho.ncsc.mil