Independent Submission M. Jenkins
Request for Comments: 8603 L. Zieglar
Category: Informational NSA
ISSN: 2070-1721 May 2019
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.
本文档指定了X.509 v3证书和X.509 v2证书撤销列表（CRL）的基本配置文件，用于美国国家安全局的商业国家安全算法（CNSA）套件。该概要文件适用于采用此类X.509证书的美国国家安全系统所有组件的能力、配置和操作。NIST特别出版物800-59中描述了美国国家安全系统。它也适用于处理高价值信息的所有其他美国政府系统。它公开提供给这些和任何其他系统部署的开发人员和操作员使用。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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编辑批准发布的文件不适用于任何级别的互联网标准；见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.
版权（c）2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 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
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.
本文档指定了X.509 v3证书和X.509 v2证书撤销列表（CRL）的基本配置文件，供支持美国国家安全局商业国家安全算法（CNSA）套件[CNSA]的应用程序使用。该概要文件适用于采用此类X.509证书的美国国家安全系统所有组件的能力、配置和操作。NIST特别出版物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.
本文件未定义任何新的加密算法套件；相反，它定义了符合CNSA的配置文件“Internet X.509公钥基础设施证书和证书吊销列表（CRL）配置文件”[RFC5280]。它适用于所有使用X.509 v3证书或X.509 v2 CRL的CNSA套件解决方案。假定读者熟悉RFC 5280。RFC 5280的所有必须达到的水平要求适用于本概要文件，此处通常不再重复。如果为了强调而重复了必须达到的水平要求，则正文中注明该要求“符合RFC 5280”。此配置文件包含将RFC 5280中的某些“应该级别”选项提升为“必须级别”的更改，还包含将RFC 5280中的某些“可能级别”选项提升为“应该级别”或“必须级别”的更改。本概要文件中未列出的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用户提供短期灵活性，以满足其网络安全互操作性要求。这种灵活性背后的目的是避免供应商和客户在相对较短的时间内进行两次主要的转换，因为我们预计在不久的将来需要转向量子抗加密。
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正在编写一套RFC，包括本RFC，以提供有关IETF协议中某些常用商业算法使用的更新指南。这些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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照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
本文档的目标是定义证书和CRL的基本要求集，以支持CNSA套件解决方案之间的互操作性。特定社区（如与美国国家安全系统相关的社区）可通过强制在此基本配置文件中存在可选扩展、定义新的可选或关键扩展类型来定义进一步限制证书和CRL内容的社区配置文件，或者限制现有扩展中的值和/或字段的存在。但是，当互操作性需要时，不同社区之间的通信必须符合本文件中规定的要求
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.
渴望的应用程序可能会增加对其他非关键扩展的需求，但它们不能假设远程对等方能够处理这些扩展。
Every CNSA Suite certificate MUST use the X.509 v3 format and contain one of the following:
每个CNSA套件证书必须使用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的（椭圆曲线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套件证书和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的协议应配置为使用将RSASSA加密指定为主题公钥算法的证书。将这些密钥用于RSASSA-PSS签名的协议必须使用以下参数：哈希算法（用于掩码生成和签名生成）必须为SHA-384，必须使用[RFC8017]中的掩码生成函数1，salt长度必须为48个八位字节。
The primary Object Identifier (OID) structure for the CNSA Suite is as follows per [X962], [SEC2], [RFC5480], and [RFC5758].
根据[X962]、[SEC2]、[RFC5480]和[RFC5758]，CNSA套件的主要对象标识符（OID）结构如下所示。
ansi-X9-62 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) 10045 }
ansi-X9-62 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) 10045 }
certicom-arc OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) }
certicom-arc OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) }
id-ecPublicKey OBJECT IDENTIFIER ::= {
ansi-X9-62 keyType(2) 1 }
id-ecPublicKey OBJECT IDENTIFIER ::= {
ansi-X9-62 keyType(2) 1 }
secp384r1 OBJECT IDENTIFIER ::= {
certicom-arc curve(0) 34 }
secp384r1 OBJECT IDENTIFIER ::= {
certicom-arc curve(0) 34 }
id-ecSigType OBJECT IDENTIFIER ::= {
ansi-X9-62 signatures(4) }
id-ecSigType OBJECT IDENTIFIER ::= {
ansi-X9-62 signatures(4) }
ecdsa-with-SHA384 OBJECT IDENTIFIER ::= {
id-ecSigType ecdsa-with-SHA2(3) 3 }
ecdsa-with-SHA384 OBJECT IDENTIFIER ::= {
id-ecSigType ecdsa-with-SHA2(3) 3 }
The primary OID structure for CNSA Suite is as follows per [RFC3279].
根据[RFC3279]，CNSA套件的主要OID结构如下所示。
pkcs-1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 }
pkcs-1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 }
rsaEncryption OBJECT IDENTIFIER ::= {
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.
RSAOID加密用于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 }
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.
本节规定了[RFC5280]中对创建或使用CNSA套件证书的应用程序的基本要求的更改。请注意，RFC 5280对将扩展标记为关键或非关键有不同的要求。此配置文件更改了CNSA套件证书中包含的扩展的一些授权。
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适用于带RSA加密的SHA384。
Per [RFC4055], the parameters MUST be NULL. Implementations MUST accept the parameters being absent as well as present.
根据[RFC4055]，参数必须为空。实现必须接受既不存在又存在的参数。
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.
[FIPS186]中描述了ECDSA数字签名生成。ECDSA签名值由两个无符号整数组成，表示为“r”和“s”。“r”和“s”必须表示为ASN.1整数。如果无符号整数的高位为1，则在将其编码为ASN.1整数之前，必须将值为0x00的八位字节前置到二进制表示形式。P-384曲线的无符号整数最多可为48字节。因此，将每个“r”和“s”转换为ASN.1整数将导致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编码为两个整数的DER编码序列的位字符串值。
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].
RSA签名生成过程和结果编码为RSASSA-PKCS1-v1#U 5，详见PKCS#1 2.2版[RFC8017]。
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 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].
此字段中算法标识符的参数必须使用namedCurve选项。不得使用[RFC5480]中描述的指定曲线和隐式曲线选项。命名曲线必须是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节中转换例程后椭圆曲线点的八位字符串表示。
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套件实现可以使用椭圆曲线点[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].
椭圆曲线公钥（八位字符串的ECPoint）映射到subjectPublicKey（位字符串），如下所示：八位字符串的最高有效位成为位字符串的最高有效位，八位字符串的最低有效位成为位字符串的最低有效位[RFC5480]。
For RSA signature verification keys and key transport keys, the algorithm ID, rsaEncryption, MUST be used.
对于RSA签名验证密钥和密钥传输密钥，必须使用算法ID RSA加密。
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节，必须使用ASN.1类型的RSAPublicKey对RSA公钥进行编码。
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.
密钥使用扩展必须标记为关键。必须设置keyCertSign和cRLSign位。可以设置数字签名和非否认位。不得设置所有其他位。
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]，基本约束扩展必须标记为关键。必须设置cA布尔值以指示主题是cA，并且pathLenConstraint不能存在。
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扩展。如果要声明策略，则必须包括CertificatePolicys扩展。
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.
密钥使用扩展必须标记为关键。必须设置keyCertSign和CRLSign位。可以设置数字签名和非否认位。不得设置所有其他位。
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]，基本约束扩展必须标记为关键。必须设置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.
如果断言策略，则CertificatePolicys扩展必须标记为非关键，必须包含适用证书策略的OID，并且不应使用policyQualifiers选项。如果未声明策略，则必须省略CertificatePolicys扩展。
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.
[RFC5280]中的指南，当它们出现在非自签名CA证书中时。
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扩展。如果要声明策略，则必须包括CertificatePolicys扩展。终端实体证书应包含subjectKeyIdentifier扩展。
The keyUsage extension MUST be marked as critical.
密钥使用扩展必须标记为关键。
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扩展。可以设置不可否认位。不得设置keyUsage扩展中的所有其他位。
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扩展。可以设置仅加密或仅解密位。不得设置keyUsage扩展中的所有其他位。
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.
如果断言策略，则CertificatePolicys扩展必须标记为非关键，必须包含适用证书策略的OID，并且不应使用policyQualifiers选项。如果未声明策略，则必须省略CertificatePolicys扩展。
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套件CRL配置文件是[RFC5280]的配置文件。[RFC5280]对该配置文件CRL上签名的要求有所变化。
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]，单个密钥对不应同时用于签名和密钥建立。
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-42013年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公钥基础设施证书和证书撤销列表（CRL）配置文件”，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]Turner，S.，Brown，D.，Yiu，K.，Housley，R.，和T.Polk，“椭圆曲线加密主题公钥信息”，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，“互联网X.509公钥基础设施：DSA和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.，Ed.，Kaliski，B.，Jonsson，J.，和A.Rusch，“PKCS#1:RSA加密规范版本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]高效密码标准组，“SEC1：椭圆曲线密码术”，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]高效密码组标准，“SEC2：建议的椭圆曲线域参数”，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]国家标准与技术研究所，“密钥管理建议-第1部分：总则”，NIST专门出版物800-57第4版，DOI 10.6028/NIST.SP.800-57pt1r4，2016年1月<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特别出版物800-59，DOI 10.6028/NIST.SP.800-59，2003年8月<https://csrc.nist.gov/publications/detail/sp/800-59/ 最终>。
[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]美国国家标准协会，“金融服务业的公钥加密；椭圆曲线数字签名算法（ECDSA）”，ANSI X9.622005年11月。
Authors' Addresses
作者地址
Michael Jenkins National Security Agency
迈克尔·詹金斯国家安全局
Email: mjjenki@nsa.gov
Email: mjjenki@nsa.gov
Lydia Zieglar National Security Agency
莉迪亚·齐格勒国家安全局
Email: llziegl@tycho.ncsc.mil
Email: llziegl@tycho.ncsc.mil