[要約] RFC 8603は、商用国家安全アルゴリズム（CNSA）スイート証明書および証明書失効リスト（CRL）プロファイルに関するものです。このRFCの目的は、CNSAスイートの証明書とCRLの使用に関するガイドラインを提供することです。
Independent Submission M. Jenkins
Request for Comments: 8603 L. Zieglar
Category: Informational NSA
ISSN: 2070-1721 May 2019
Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile
商用国家安全保障アルゴリズム（CNSA）スイートの証明書および証明書失効リスト（CRL）プロファイル
Abstract
概要
This document specifies a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for use with the United States National Security Agency's Commercial National Security Algorithm (CNSA) Suite. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ such X.509 certificates. US National Security Systems are described in NIST Special Publication 800-59. 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）スイートで使用するX.509 v3証明書およびX.509 v2証明書失効リスト（CRL）の基本プロファイルを指定します。プロファイルは、そのようなX.509証明書を使用する米国国家安全保障システムのすべてのコンポーネントの機能、構成、および操作に適用されます。米国国家安全保障システムは、NIST Special Publication 800-59に記載されています。また、高価値の情報を処理する他のすべての米国政府システムにも適しています。これらおよびその他のシステム展開の開発者およびオペレーターが使用できるように公開されています。
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/rfc8603.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8603で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Commercial National Security Algorithm Suite . . . . . . 4
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. General Requirements and Assumptions . . . . . . . . . . . . 4
4.1. Implementing the CNSA Suite . . . . . . . . . . . . . . . 5
4.2. CNSA Suite Object Identifiers . . . . . . . . . . . . . . 6
5. CNSA Suite Base Certificate Required Values . . . . . . . . . 7
5.1. signatureAlgorithm . . . . . . . . . . . . . . . . . . . 7
5.2. signatureValue . . . . . . . . . . . . . . . . . . . . . 7
5.3. Version . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.4. SubjectPublicKeyInfo . . . . . . . . . . . . . . . . . . 8
6. Certificate Extensions for Particular Types of Certificates . 9
6.1. CNSA Suite Self-Signed CA Certificates . . . . . . . . . 9
6.2. CNSA Suite Non-Self-Signed CA Certificates . . . . . . . 9
6.3. CNSA Suite End-Entity Signature and Key Establishment
Certificates . . . . . . . . . . . . . . . . . . . . . . 10
7. CNSA Suite CRL Requirements . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
This document specifies a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for use by applications that support 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 that employ such X.509 certificates. US National Security Systems are described in NIST Special Publication 800-59 [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]をサポートするアプリケーションが使用するX.509 v3証明書とX.509 v2証明書失効リスト（CRL）の基本プロファイルを指定します。プロファイルは、そのようなX.509証明書を使用する米国国家安全保障システムのすべてのコンポーネントの機能、構成、および操作に適用されます。米国の国家安全保障システムは、NIST Special Publication 800-59 [SP80059]で説明されています。また、高価値の情報を処理する他のすべての米国政府システムにも適しています。これらおよびその他のシステム展開の開発者およびオペレーターが使用できるように公開されています。
This document does not define any new cryptographic algorithm suite; instead, it defines a CNSA-compliant profile of "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280]. It applies to all CNSA Suite solutions that make use of X.509 v3 Certificates or X.509 v2 CRLs. The reader is assumed to have familiarity with RFC 5280. All MUST-level requirements of RFC 5280 apply throughout this profile and are generally not repeated here. In cases where a MUST-level requirement is repeated for emphasis, the text notes the requirement is "in adherence with RFC 5280". This profile contains changes that elevate some SHOULD-level options in RFC 5280 to MUST-level and also contains changes that elevate some MAY-level options in RFC 5280 to SHOULD-level or MUST-level. All options from RFC 5280 that are not listed in this profile remain at the requirement level of RFC 5280.
このドキュメントでは、新しい暗号アルゴリズムスイートは定義していません。代わりに、「インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル」[RFC5280]のCNSA準拠のプロファイルを定義しています。これは、X.509 v3証明書またはX.509 v2 CRLを使用するすべてのCNSA Suiteソリューションに適用されます。読者はRFC 5280に精通していると想定されます。RFC5280のすべての必須レベルの要件は、このプロファイル全体に適用され、通常、ここでは繰り返されません。強調するためにMUSTレベルの要件が繰り返される場合、テキストは要件が「RFC 5280に準拠している」ことを注記しています。このプロファイルには、RFC 5280の一部のSHOULDレベルオプションをMUSTレベルに昇格させる変更が含まれており、RFC 5280の一部のMAYレベルオプションをSHOULDレベルまたはMUSTレベルに昇格させる変更も含まれています。このプロファイルにリストされていないRFC 5280のすべてのオプションは、RFC 5280の要件レベルのままです。
The reader is also assumed to have familiarity with these documents:
読者は、これらのドキュメントに精通していることも前提としています。
o [RFC5480] for the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography,
o [RFC5480]楕円曲線暗号をサポートする証明書のサブジェクト公開鍵情報フィールドの構文とセマンティクスについては、
o [RFC5758] for the algorithm identifiers for Elliptic Curve Digital Signature Algorithm (ECDSA),
o [RFC5758]楕円曲線デジタル署名アルゴリズム（ECDSA）のアルゴリズム識別子については、
o [RFC3279] for the syntax and semantics for the Subject Public Key Information field in certificates that support RSA Cryptography, and
o [RFC3279] RSA暗号化をサポートする証明書のサブジェクト公開鍵情報フィールドの構文とセマンティクス
o [RFC4055] for the algorithm identifiers for RSA Cryptography with the SHA-384 hash function.
o [RFC4055]は、SHA-384ハッシュ関数を使用したRSA暗号化のアルゴリズム識別子です。
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 transitioning the United States Government to new algorithms and to provide vendors, and the Internet community in general, with information concerning their proper use and configuration.
国家安全保障局（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 vendors and customers making two major transitions in a relatively short time frame, 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特別出版物など）と組み合わせて使用して、米国政府の国家安全保障システムのインターネットトラフィックと保管データを適切に保護できます。
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 goal of this document is to define a base set of requirements for certificates and CRLs to support interoperability among CNSA Suite solutions. Specific communities, such as those associated with US National Security Systems, may define community profiles that further restrict certificate and CRL contents by mandating the presence of extensions that are optional in this base profile, defining new optional or critical extension types, or restricting the values and/ or presence of fields within existing extensions. However, communications between distinct communities MUST conform with the requirements specified in this document when interoperability is desired. Applications may add requirements for additional non-critical extensions, but they MUST NOT assume that a remote peer will be able to process them.
このドキュメントの目的は、CNSA Suiteソリューション間の相互運用性をサポートするための証明書とCRLの基本的な要件セットを定義することです。米国国家安全保障システムに関連するコミュニティなどの特定のコミュニティは、この基本プロファイルでオプションの拡張機能の存在を義務付け、新しいオプションまたは重要な拡張機能タイプを定義するか、値を制限することにより、証明書とCRLコンテンツをさらに制限するコミュニティプロファイルを定義する場合があります。および/または既存の拡張機能内のフィールドの存在。ただし、相互運用性が必要な場合、個別のコミュニティ間の通信は、このドキュメントで指定されている要件に準拠する必要があります。アプリケーションは、重要ではない追加の拡張機能の要件を追加できますが、リモートピアがそれらを処理できると想定してはなりません。
Every CNSA Suite certificate MUST use the X.509 v3 format and contain one of the following:
すべてのCNSA Suite証明書はX.509 v3形式を使用し、次のいずれかを含む必要があります。
o An ECDSA-capable signature verification key using curve P-384, or
o 曲線P-384を使用するECDSA対応の署名検証鍵、または
o An ECDH-capable (Elliptic Curve Diffie-Hellman) key establishment key using curve P-384, or
o 曲線P-384を使用したECDH対応の（Elliptic Curve Diffie-Hellman）鍵確立鍵、または
o An RSA-capable signature verification key using RSA-3072 or RSA-4096, or
o RSA-3072またはRSA-4096を使用したRSA対応の署名検証鍵、または
o An RSA-capable key transport key using RSA-3072 or RSA-4096.
o RSA-3072またはRSA-4096を使用したRSA対応のキー転送キー。
The signature applied to all CNSA Suite certificates and CRLs MUST be made with a signing key that is either generated on the curve P-384, or is an RSA-3072 or RSA-4096 key. The SHA-384 hashing algorithm MUST be used for all certificate and CRL signatures irrespective of the type of key used.
すべてのCNSA Suite証明書とCRLに適用される署名は、曲線P-384で生成された署名鍵、またはRSA-3072またはRSA-4096鍵のいずれかで作成する必要があります。使用される鍵のタイプに関係なく、すべての証明書とCRL署名にSHA-384ハッシングアルゴリズムを使用する必要があります。
The RSA exponent "e" MUST satisfy 2^16<e<2^256 and be odd per [FIPS186].
RSA指数「e」は2 ^ 16 <e <2 ^ 256を満たし、[FIPS186]ごとに奇数でなければなりません。
The requirements of this document are not intended to preclude use of RSASSA-PSS signatures. However, Certification Authorities (CAs) conforming with this document will not issue certificates specifying that algorithm for subject public keys. Protocols that use RSASSA-PSS should be configured to use certificates that specify rsaEncryption as the subject public key algorithm. Protocols that use these keys with RSASSA-PSS signatures must use the following parameters: the hash algorithm (used for both mask generation and signature generation) must be SHA-384, the mask generation function 1 from [RFC8017] must be used, and the salt length must be 48 octets.
このドキュメントの要件は、RSASSA-PSS署名の使用を排除することを意図したものではありません。ただし、このドキュメントに準拠する認証局（CA）は、対象の公開鍵に対してそのアルゴリズムを指定する証明書を発行しません。 RSASSA-PSSを使用するプロトコルは、サブジェクトの公開キーアルゴリズムとしてrsaEncryptionを指定する証明書を使用するように構成する必要があります。 RSASSA-PSS署名でこれらの鍵を使用するプロトコルは、次のパラメーターを使用する必要があります。ハッシュアルゴリズム（マスク生成と署名生成の両方に使用）はSHA-384である必要があり、[RFC8017]のマスク生成関数1を使用する必要があります。ソルトの長さは48オクテットでなければなりません。
The primary Object Identifier (OID) structure for the CNSA Suite is as follows per [X962], [SEC2], [RFC5480], and [RFC5758].
CNSA Suiteの主要なオブジェクト識別子（OID）構造は、[X962]、[SEC2]、[RFC5480]、および[RFC5758]に従って次のとおりです。
ansi-X9-62 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) 10045 }
certicom-arc OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) }
id-ecPublicKey OBJECT IDENTIFIER ::= {
ansi-X9-62 keyType(2) 1 }
secp384r1 OBJECT IDENTIFIER ::= {
certicom-arc curve(0) 34 }
id-ecSigType OBJECT IDENTIFIER ::= {
ansi-X9-62 signatures(4) }
ecdsa-with-SHA384 OBJECT IDENTIFIER ::= {
id-ecSigType ecdsa-with-SHA2(3) 3 }
The primary OID structure for CNSA Suite is as follows per [RFC3279].
CNSA Suiteの主要なOID構造は、[RFC3279]によると次のとおりです。
pkcs-1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 }
rsaEncryption OBJECT IDENTIFIER ::= {
pkcs-1 1}
The rsaEncryption OID is intended to be used in the algorithm field of a value of type AlgorithmIdentifier. The parameters field MUST have ASN.1 type NULL for this algorithm identifier.
rsaEncryption OIDは、タイプAlgorithmIdentifierの値のアルゴリズムフィールドで使用することを目的としています。パラメータフィールドは、このアルゴリズム識別子に対してASN.1タイプNULLを持っている必要があります。
The object identifier used to identify the PKCS #1 version 1.5 signature algorithm with SHA-384 is per [RFC4055]:
SHA-384でPKCS＃1バージョン1.5署名アルゴリズムを識別するために使用されるオブジェクト識別子は、[RFC4055]に準拠しています。
sha384WithRSAEncryption OBJECT IDENTIFIER ::= {
pkcs-1 12 }
This section specifies changes to the basic requirements in [RFC5280] for applications that create or use CNSA Suite certificates. Note that RFC 5280 has varying mandates for marking extensions as critical or non-critical. This profile changes some of those mandates for extensions that are included in CNSA Suite certificates.
このセクションでは、CNSA Suite証明書を作成または使用するアプリケーションの[RFC5280]の基本要件の変更について説明します。 RFC 5280には、拡張をクリティカルまたは非クリティカルとしてマークするためのさまざまな権限があることに注意してください。このプロファイルは、CNSA Suite証明書に含まれる拡張機能に対するそれらの義務の一部を変更します。
For ECDSA, the algorithm identifier used by the CNSA Suite is as described in [RFC5758] and [X962]:
ECDSAの場合、CNSAスイートで使用されるアルゴリズム識別子は、[RFC5758]および[X962]で説明されています。
1.2.840.10045.4.3.3 for ecdsa-with-SHA384
1.2.840.10045.4.3.3（ecdsa-with-SHA384の場合）
The parameters MUST be absent as per [RFC5758].
[RFC5758]に従って、パラメータは存在しない必要があります。
For RSA, the algorithm identifier used by the CNSA Suite is as described in [RFC4055]:
RSAの場合、CNSAスイートで使用されるアルゴリズム識別子は[RFC4055]で説明されています。
1.2.840.113549.1.1.12 for sha384WithRSAEncryption.
1.2.840.113549.1.1.12（sha384WithRSAEncryption）。
Per [RFC4055], the parameters MUST be NULL. Implementations MUST accept the parameters being absent as well as present.
[RFC4055]に従って、パラメータはNULLでなければなりません。実装は、存在するだけでなく、存在しないパラメーターを受け入れる必要があります。
ECDSA digital signature generation is described in [FIPS186]. An ECDSA signature value is composed of two unsigned integers, denoted as "r" and "s". "r" and "s" MUST be represented as ASN.1 INTEGERs. If the high-order bit of the unsigned integer is a 1, an octet with the value 0x00 MUST be prepended to the binary representation before encoding it as an ASN.1 INTEGER. Unsigned integers for the P-384 curves can be a maximum of 48 bytes. Therefore, converting each "r" and "s" to an ASN.1 INTEGER will result in a maximum of 49 bytes for the P-384 curve.
ECDSAデジタル署名の生成については、[FIPS186]で説明されています。 ECDSA署名値は、「r」と「s」で示される2つの符号なし整数で構成されます。 「r」と「s」は、ASN.1 INTEGERとして表現する必要があります。符号なし整数の高位ビットが1の場合、値0x00のオクテットをバイナリ表現の前に付加してから、ASN.1 INTEGERとしてエンコードする必要があります。 P-384曲線の符号なし整数は最大48バイトです。したがって、各「r」と「s」をASN.1 INTEGERに変換すると、P-384曲線で最大49バイトになります。
The ECDSA signatureValue in an X.509 certificate is encoded as a BIT STRING value of a DER-encoded SEQUENCE of the two INTEGERS.
X.509証明書のECDSA signatureValueは、2つのINTEGERSのDERエンコードされたSEQUENCEのBIT STRING値としてエンコードされます。
The RSA signature generation process and the encoding of the result is RSASSA-PKCS1-v1_5 as described in detail in PKCS #1 version 2.2 [RFC8017].
PKCS＃1バージョン2.2 [RFC8017]で詳細に説明されているように、RSA署名生成プロセスと結果のエンコードはRSASSA-PKCS1-v1_5です。
For this profile, Version MUST be v3, which means the value MUST be set to 2.
このプロファイルの場合、バージョンはv3でなければなりません。つまり、値は2に設定する必要があります。
For ECDSA signature verification keys and ECDH key agreement keys, the algorithm ID id-ecPublicKey MUST be used.
ECDSA署名検証鍵とECDH鍵合意鍵の場合、アルゴリズムID id-ecPublicKeyを使用する必要があります。
The parameters of the AlgorithmIdentifier in this field MUST use the namedCurve option. The specifiedCurve and implicitCurve options described in [RFC5480] MUST NOT be used. The namedCurve MUST be the OID for secp384r1 (curve P-384) [RFC5480].
このフィールドのAlgorithmIdentifierのパラメーターは、namedCurveオプションを使用する必要があります。 [RFC5480]で説明されているspecifiedCurveおよびimplicitCurveオプションを使用してはなりません（MUST NOT）。 namedCurveは、secp384r1（曲線P-384）[RFC5480]のOIDでなければなりません。
The elliptic curve public key, ECPoint, SHALL be the OCTET STRING representation of an elliptic curve point following the conversion routine in Section 2.2 of [RFC5480] and Sections 2.3.1 and 2.3.2 of [SEC1].
楕円曲線の公開鍵ECPointは、[RFC5480]のセクション2.2および[SEC1]のセクション2.3.1および2.3.2の変換ルーチンに従う楕円曲線ポイントのOCTET STRING表現である必要があります。
CNSA Suite implementations MAY use either the uncompressed form or the compressed form of the elliptic curve point [RFC5480]. For interoperability purposes, all relying parties MUST be prepared to process the uncompressed form.
CNSA Suiteの実装では、楕円曲線点の非圧縮形式または圧縮形式のいずれかを使用できます[RFC5480]。相互運用性の目的で、すべての依存パーティは、非圧縮フォームを処理する準備ができていなければなりません。
The elliptic curve public key (an ECPoint that is an OCTET STRING) is mapped to a subjectPublicKey (a BIT STRING) as follows: the most significant bit of the OCTET STRING becomes the most significant bit of the BIT STRING, and the least significant bit of the OCTET STRING becomes the least significant bit of the BIT STRING [RFC5480].
楕円曲線の公開キー（OCTET STRINGであるECPoint）は、次のようにsubjectPublicKey（ビットストリング）にマッピングされます。OCTETストリングの最上位ビットはビットストリングの最上位ビットになり、最下位ビットはOCTET STRINGのBIT STRINGの最下位ビットになります[RFC5480]。
For RSA signature verification keys and key transport keys, the algorithm ID, rsaEncryption, MUST be used.
RSA署名検証鍵と鍵転送鍵の場合、アルゴリズムID、rsaEncryptionを使用する必要があります。
The parameters field MUST have ASN.1 type NULL for this algorithm identifier [RFC3279].
パラメータフィールドは、このアルゴリズム識別子[RFC3279]に対してASN.1タイプNULLを持つ必要があります。
The RSA public key MUST be encoded using the ASN.1 type RSAPublicKey per Section 2.3.1 of [RFC3279].
[RFC3279]のセクション2.3.1に従って、RSA公開鍵はASN.1タイプのRSAPublicKeyを使用してエンコードする必要があります。
Different types of certificates in this profile have different required and recommended extensions. Those are listed in this section. Those extensions from RFC 5280 not explicitly listed in this profile remain at the requirement levels of RFC 5280.
このプロファイルの異なるタイプの証明書には、異なる必須および推奨の拡張があります。それらはこのセクションにリストされています。このプロファイルに明示的にリストされていないRFC 5280の拡張機能は、RFC 5280の要件レベルのままです。
In adherence with [RFC5280], self-signed CA certificates in this profile MUST contain the subjectKeyIdentifier, keyUsage, and basicConstraints extensions.
[RFC5280]に準拠して、このプロファイルの自己署名CA証明書には、subjectKeyIdentifier、keyUsage、およびbasicConstraints拡張が含まれている必要があります。
The keyUsage extension MUST be marked as critical. The keyCertSign and cRLSign bits MUST be set. The digitalSignature and nonRepudiation bits MAY be set. All other bits MUST NOT be set.
keyUsage拡張は、クリティカルとしてマークする必要があります。 keyCertSignおよびcRLSignビットを設定する必要があります。 digitalSignatureおよびnonRepudiationビットが設定される場合があります。他のすべてのビットは設定してはいけません。
In adherence with [RFC5280], the basicConstraints extension MUST be marked as critical. The cA boolean MUST be set to indicate that the subject is a CA, and the pathLenConstraint MUST NOT be present.
[RFC5280]に準拠して、basicConstraints拡張機能をクリティカルとしてマークする必要があります。 cAブール値は、サブジェクトがCAであることを示すように設定する必要があり、pathLenConstraintが存在してはなりません（MUST NOT）。
Non-self-signed CA Certificates in this profile MUST contain the authorityKeyIdentifier, keyUsage, and basicConstraints extensions. If there is a policy to be asserted, then the certificatePolicies extension MUST be included.
このプロファイルの非自己署名CA証明書には、authorityKeyIdentifier、keyUsage、およびbasicConstraints拡張が含まれている必要があります。アサートするポリシーがある場合は、certificatePolicies拡張を含める必要があります。
The keyUsage extension MUST be marked as critical. The keyCertSign and CRLSign bits MUST be set. The digitalSignature and nonRepudiation bits MAY be set. All other bits MUST NOT be set.
keyUsage拡張は、クリティカルとしてマークする必要があります。 keyCertSignおよびCRLSignビットを設定する必要があります。 digitalSignatureおよびnonRepudiationビットが設定される場合があります。他のすべてのビットは設定してはいけません。
In adherence with [RFC5280], the basicConstraints extension MUST be marked as critical. The cA boolean MUST be set to indicate that the subject is a CA, and the pathLenConstraint subfield is OPTIONAL.
[RFC5280]に準拠して、basicConstraints拡張機能をクリティカルとしてマークする必要があります。サブジェクトがCAであることを示すためにcAブール値を設定する必要があり、pathLenConstraintサブフィールドはオプションです。
If a policy is asserted, the certificatePolicies extension MUST be marked as non-critical, MUST contain the OIDs for the applicable certificate policies, and SHOULD NOT use the policyQualifiers option. If a policy is not asserted, the certificatePolicies extension MUST be omitted.
ポリシーがアサートされる場合、certificatePolicies拡張機能は非クリティカルとしてマークされなければならず、適切な証明書ポリシーのOIDを含んでいる必要があり、policyQualifiersオプションを使用してはなりません（SHOULD NOT）。ポリシーがアサートされていない場合は、certificatePolicies拡張を省略しなければなりません（MUST）。
Relying party applications conforming to this profile MUST be prepared to process the policyMappings, policyConstraints, and inhibitAnyPolicy extensions, regardless of criticality, following the guidance in [RFC5280] when they appear in non-self-signed CA certificates.
このプロファイルに準拠する証明書利用者アプリケーションは、非自己署名CA証明書に表示される[RFC5280]のガイダンスに従って、重要度に関係なく、policyMappings、policyConstraints、およびpreventAnyPolicy拡張を処理できるように準備する必要があります。
In adherence with [RFC5280], end-entity certificates in this profile MUST contain the authorityKeyIdentifier and keyUsage extensions. If there is a policy to be asserted, then the certificatePolicies extension MUST be included. End-entity certificates SHOULD contain the subjectKeyIdentifier extension.
[RFC5280]に準拠して、このプロファイルのエンドエンティティ証明書には、authorityKeyIdentifierおよびkeyUsage拡張が含まれている必要があります。アサートするポリシーがある場合は、certificatePolicies拡張を含める必要があります。エンドエンティティ証明書には、subjectKeyIdentifier拡張が含まれている必要があります（SHOULD）。
The keyUsage extension MUST be marked as critical.
keyUsage拡張は、クリティカルとしてマークする必要があります。
For end-entity digital signature certificates, the keyUsage extension MUST be set for digitalSignature. The nonRepudiation bit MAY be set. All other bits in the keyUsage extension MUST NOT be set.
エンドエンティティのデジタル署名証明書の場合、digitalSignatureにkeyUsage拡張を設定する必要があります。 nonRepudiationビットが設定される場合があります。 keyUsage拡張機能の他のすべてのビットは設定してはなりません（MUST NOT）。
For end-entity key establishment certificates, in ECDH certificates, the keyUsage extension MUST be set for keyAgreement; in RSA certificates, the keyUsage extension MUST be set for keyEncipherment. The encipherOnly or decipherOnly bit MAY be set. All other bits in the keyUsage extension MUST NOT be set.
エンドエンティティキー確立証明書の場合、ECDH証明書では、keyAgreementにkeyUsage拡張を設定する必要があります。 RSA証明書では、keyUsage拡張をkeyEnciphermentに設定する必要があります。 encipherOnlyまたはdecipherOnlyビットが設定される場合があります。 keyUsage拡張機能の他のすべてのビットは設定してはなりません（MUST NOT）。
If a policy is asserted, the certificatePolicies extension MUST be marked as non-critical, MUST contain the OIDs for the applicable certificate policies, and SHOULD NOT use the policyQualifiers option. If a policy is not asserted, the certificatePolicies extension MUST be omitted.
ポリシーがアサートされる場合、certificatePolicies拡張機能は非クリティカルとしてマークされなければならず、適切な証明書ポリシーのOIDを含んでいる必要があり、policyQualifiersオプションを使用してはなりません（SHOULD NOT）。ポリシーがアサートされていない場合は、certificatePolicies拡張を省略しなければなりません（MUST）。
This CNSA Suite CRL profile is a profile of [RFC5280]. There are changes in the requirements from [RFC5280] for the signatures on CRLs of this profile.
このCNSA Suite CRLプロファイルは、[RFC5280]のプロファイルです。このプロファイルのCRLの署名の[RFC5280]からの要件に変更があります。
The signatures on CRLs in this profile MUST follow the same rules from this profile that apply to signatures in the certificates. See Section 4.
このプロファイルのCRLの署名は、証明書の署名に適用されるこのプロファイルの同じルールに従う必要があります。セクション4を参照してください。
The security considerations in [RFC3279], [RFC4055], [RFC5280], [RFC5480], [RFC5758], and [RFC8017] apply.
[RFC3279]、[RFC4055]、[RFC5280]、[RFC5480]、[RFC5758]、および[RFC8017]のセキュリティに関する考慮事項が適用されます。
A single key pair SHOULD NOT be used for both signature and key establishment per [SP80057].
[SP80057]に従って、単一の鍵ペアを署名と鍵の確立の両方に使用してはなりません（SHOULD NOT）。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[CNSA] Committee for National Security Systems, "Use of Public Standards for Secure Information Sharing", CNSSP 15, October 2016, <https://www.cnss.gov/CNSS/Issuances/Policies.htm>.
[CNSA]国家安全保障システム委員会、「安全な情報共有のための公的基準の使用」、CNSSP 15、2016年10月、<https://www.cnss.gov/CNSS/Issuances/Policies.htm>。
[FIPS186] National Institute of Standards and Technology (NIST), "Digital Signature Standard (DSS)", FIPS PUB 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013, <https://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf>.
[FIPS186]米国国立標準技術研究所（NIST）、「デジタル署名標準（DSS）」、FIPS PUB 186-4、DOI 10.6028 / NIST.FIPS.186-4、2013年7月、<https：//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>。
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 2002, <https://www.rfc-editor.org/info/rfc3279>.
[RFC3279] Bassham、L.、Polk、W。、およびR. Housley、「インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイルのアルゴリズムと識別子」、RFC 3279、DOI 10.17487 / RFC3279、 2002年4月、<https://www.rfc-editor.org/info/rfc3279>。
[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>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, <https://www.rfc-editor.org/info/rfc5480>.
[RFC5480]ターナー、S。、ブラウン、D。、ユウ、K。、ハウズリー、R。、およびT.ポーク、「楕円曲線暗号化サブジェクト公開鍵情報」、RFC 5480、DOI 10.17487 / RFC5480、2009年3月、< https://www.rfc-editor.org/info/rfc5480>。
[RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. Polk, "Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA", RFC 5758, DOI 10.17487/RFC5758, January 2010, <https://www.rfc-editor.org/info/rfc5758>.
[RFC5758] Dang、Q.、Santesson、S.、Moriarty、K.、Brown、D。、およびT. Polk、「Internet X.509 Public Key Infrastructure：Additional Algorithms and Identifiers for DSA and ECDSA」、RFC 5758、 DOI 10.17487 / RFC5758、2010年1月、<https://www.rfc-editor.org/info/rfc5758>。
[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。、編、Kaliski、B.、Jonsson、J。、およびA. Rusch、「PKCS＃1：RSA Cryptography Specifications Version 2.2」、RFC 8017、DOI 10.17487 / RFC8017、2016年11月、< 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>。
[SEC1] Standards for Efficient Cryptography Group, "SEC1: Elliptic Curve Cryptography", May 2009, <https://www.secg.org/sec1-v2.pdf>.
[SEC1] Standards for Efficient Cryptography Group、「SEC1：Elliptic Curve Cryptography」、2009年5月、<https://www.secg.org/sec1-v2.pdf>。
[SEC2] Standards for Efficient Cryptography Group, "SEC 2: Recommended Elliptic Curve Domain Parameters", January 2010, <https://www.secg.org/sec2-v2.pdf>.
[SEC2] Standards for Efficient Cryptography Group、「SEC 2：Recommended Elliptic Curve Domain Parameters」、2010年1月、<https://www.secg.org/sec2-v2.pdf>。
[SP80057] National Institute of Standards and Technology, "Recommendation for Key Management - Part 1: General", NIST Special Publication 800-57 Revision 4, DOI 10.6028/NIST.SP.800-57pt1r4, January 2016, <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-57pt1r4.pdf>.
[SP80057] National Institute of Standards and Technology、「Recommendation for Key Management-Part 1：General」、NIST Special Publication 800-57 Revision 4、DOI 10.6028 / NIST.SP.800-57pt1r4、January、<https：// nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-57pt1r4.pdf>。
[SP80059] National Institute of Standards and Technology, "Guideline for Identifying an Information System as a National Security System", NIST Special Publication 800-59, DOI 10.6028/NIST.SP.800-59, August 2003, <https://csrc.nist.gov/publications/detail/sp/800-59/ final>.
[SP80059]米国国立標準技術研究所、「情報システムを国家安全保障システムとして特定するためのガイドライン」、NIST Special Publication 800-59、DOI 10.6028 / NIST.SP.800-59、2003年8月、<https：// csrc.nist.gov/publications/detail/sp/800-59/ final>。
[X962] American National Standards Institute, "Public Key Cryptography for the Financial Services Industry; The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62, November 2005.
[X962] American National Standards Institute、「金融サービス業界の公開鍵暗号化、楕円曲線デジタル署名アルゴリズム（ECDSA）」、ANSI X9.62、2005年11月。
Authors' Addresses
著者のアドレス
Michael Jenkins National Security Agency
マイケルジェンキンス国家安全保障局
Email: mjjenki@nsa.gov
Lydia Zieglar National Security Agency
リディアジーグラー国家安全保障局
Email: llziegl@tycho.ncsc.mil