< draft-jenkins-cnsa-cert-crl-profile-06.txt   rfc8603.txt 
Internet Engineering Task Force M. Jenkins Independent Submission M. Jenkins
Internet-Draft L. Zieglar Request for Comments: 8603 L. Zieglar
Intended status: Informational NSA Category: Informational NSA
Expires: August 11, 2019 February 7, 2019 ISSN: 2070-1721 May 2019
Commercial National Security Algorithm (CNSA) Suite Certificate and Commercial National Security Algorithm (CNSA) Suite Certificate and
Certificate Revocation List (CRL) Profile Certificate Revocation List (CRL) Profile
draft-jenkins-cnsa-cert-crl-profile-06
Abstract Abstract
This document specifies a base profile for X.509 v3 Certificates and This document specifies a base profile for X.509 v3 Certificates and
X.509 v2 Certificate Revocation Lists (CRLs) for use with the United X.509 v2 Certificate Revocation Lists (CRLs) for use with the United
States National Security Agency's Commercial National Security States National Security Agency's Commercial National Security
Algorithm (CNSA) Suite. The reader is assumed to have familiarity Algorithm (CNSA) Suite. The profile applies to the capabilities,
with RFC 5280, "Internet X.509 Public Key Infrastructure Certificate configuration, and operation of all components of US National
and Certificate Revocation List (CRL) Profile". The profile applies Security Systems that employ such X.509 certificates. US National
to the capabilities, configuration, and operation of all components Security Systems are described in NIST Special Publication 800-59.
of US National Security Systems that employ such X.509 certificates. It is also appropriate for all other US Government systems that
US National Security Systems are described in NIST Special process high-value information. It is made publicly available for
Publication 800-59. It is also appropriate for all other US use by developers and operators of these and any other system
Government systems that process high-value information. It is made deployments.
publicly available for use by developers and operators of these and
any other system deployments.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This is a contribution to the RFC Series, independently of any other
and may be updated, replaced, or obsoleted by other documents at any RFC stream. The RFC Editor has chosen to publish this document at
time. It is inappropriate to use Internet-Drafts as reference its discretion and makes no statement about its value for
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on August 11, 2019. 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.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document.
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Commercial National Security Algorithm Suite . . . . . . 3 2. The Commercial National Security Algorithm Suite . . . . . . 4
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. General Requirements and Assumptions . . . . . . . . . . . . 4 4. General Requirements and Assumptions . . . . . . . . . . . . 4
4.1. Implementing the CNSA Suite . . . . . . . . . . . . . . . 4 4.1. Implementing the CNSA Suite . . . . . . . . . . . . . . . 5
4.2. CNSA Suite Object Identifiers . . . . . . . . . . . . . . 5 4.2. CNSA Suite Object Identifiers . . . . . . . . . . . . . . 6
5. CNSA Suite Base Certificate Required Values . . . . . . . . . 6 5. CNSA Suite Base Certificate Required Values . . . . . . . . . 7
5.1. signatureAlgorithm . . . . . . . . . . . . . . . . . . . 6 5.1. signatureAlgorithm . . . . . . . . . . . . . . . . . . . 7
5.2. signatureValue . . . . . . . . . . . . . . . . . . . . . 7 5.2. signatureValue . . . . . . . . . . . . . . . . . . . . . 7
5.3. Version . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Version . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.4. SubjectPublicKeyInfo . . . . . . . . . . . . . . . . . . 7 5.4. SubjectPublicKeyInfo . . . . . . . . . . . . . . . . . . 8
6. Certificate Extensions for Particular Types of Certificates . 8 6. Certificate Extensions for Particular Types of Certificates . 9
6.1. CNSA Suite Self-Signed CA Certificates . . . . . . . . . 8 6.1. CNSA Suite Self-Signed CA Certificates . . . . . . . . . 9
6.2. CNSA Suite Non-Self-Signed CA Certificates . . . . . . . 8 6.2. CNSA Suite Non-Self-Signed CA Certificates . . . . . . . 9
6.3. CNSA Suite End Entity Signature and Key Establishment 6.3. CNSA Suite End-Entity Signature and Key Establishment
Certificates . . . . . . . . . . . . . . . . . . . . . . 9 Certificates . . . . . . . . . . . . . . . . . . . . . . 10
7. CNSA Suite CRL Requirements . . . . . . . . . . . . . . . . . 10 7. CNSA Suite CRL Requirements . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
This document specifies a base profile for X.509 v3 Certificates and This document specifies a base profile for X.509 v3 Certificates and
X.509 v2 Certificate Revocation Lists (CRLs) for use by applications X.509 v2 Certificate Revocation Lists (CRLs) for use by applications
that support the United States National Security Agency's Commercial that support the United States National Security Agency's Commercial
National Security Algorithm (CNSA) Suite [CNSA]. The profile applies National Security Algorithm (CNSA) Suite [CNSA]. The profile applies
to the capabilities, configuration, and operation of all components to the capabilities, configuration, and operation of all components
of US National Security Systems that employ such X.509 certificates. of US National Security Systems that employ such X.509 certificates.
US National Security Systems are described in NIST Special US National Security Systems are described in NIST Special
Publication 800-59 [SP-800-59]. It is also appropriate for all other Publication 800-59 [SP80059]. It is also appropriate for all other
US Government systems that process high-value information. It is US Government systems that process high-value information. It is
made publicly available for use by developers and operators of these made publicly available for use by developers and operators of these
and any other system deployments. and any other system deployments.
This document does not define any new cryptographic algorithm suite; This document does not define any new cryptographic algorithm suite;
instead, it defines a CNSA compliant profile of [RFC5280]. It instead, it defines a CNSA-compliant profile of "Internet X.509
applies to all CNSA Suite solutions that make use of X.509 v3 Public Key Infrastructure Certificate and Certificate Revocation List
Certificates or X.509 v2 CRLs. The reader is assumed to have (CRL) Profile" [RFC5280]. It applies to all CNSA Suite solutions
familiarity with RFC 5280. All MUST-level requirements of RFC 5280 that make use of X.509 v3 Certificates or X.509 v2 CRLs. The reader
apply throughout this profile and are generally not repeated here. is assumed to have familiarity with RFC 5280. All MUST-level
In cases where a MUST-level requirement is repeated for emphasis, the requirements of RFC 5280 apply throughout this profile and are
text notes the requirement is "in adherence with RFC 5280". This generally not repeated here. In cases where a MUST-level requirement
profile contains changes that elevate some SHOULD-level options in is repeated for emphasis, the text notes the requirement is "in
RFC 5280 to MUST-level for this profile; this profile also contains 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- changes that elevate some MAY-level options in RFC 5280 to SHOULD-
level or MUST-level in this profile. All options from RFC 5280 that level or MUST-level. All options from RFC 5280 that are not listed
are not listed in this profile remain at the requirement level of RFC in this profile remain at the requirement level of RFC 5280.
5280.
The reader is also assumed to have familiarity with these documents: The reader is also assumed to have familiarity with these documents:
o [RFC5480] for the syntax and semantics for the Subject Public Key o [RFC5480] for the syntax and semantics for the Subject Public Key
Information field in certificates that support Elliptic Curve Information field in certificates that support Elliptic Curve
Cryptography; Cryptography,
o [RFC5758] for the algorithm identifiers for Elliptic Curve Digital o [RFC5758] for the algorithm identifiers for Elliptic Curve Digital
Signature Algorithm (ECDSA); Signature Algorithm (ECDSA),
o [RFC3279] for the syntax and semantics for the Subject Public Key o [RFC3279] for the syntax and semantics for the Subject Public Key
Information field in certificates that support RSA Cryptography; Information field in certificates that support RSA Cryptography,
and and
o [RFC4055] for the algorithm identifiers for RSA Cryptography with o [RFC4055] for the algorithm identifiers for RSA Cryptography with
the SHA-384 hash function. the SHA-384 hash function.
2. The Commercial National Security Algorithm Suite 2. The Commercial National Security Algorithm Suite
The National Security Agency (NSA) profiles commercial cryptographic The National Security Agency (NSA) profiles commercial cryptographic
algorithms and protocols as part of its mission to support secure, algorithms and protocols as part of its mission to support secure,
interoperable communications for US Government National Security interoperable communications for US Government National Security
Systems. To this end, it publishes guidance both to assist with the Systems. To this end, it publishes guidance both to assist with
USG transition to new algorithms, and to provide vendors - and the transitioning the United States Government to new algorithms and to
Internet community in general - with information concerning their provide vendors, and the Internet community in general, with
proper use and configuration. information concerning their proper use and configuration.
Recently, cryptographic transition plans have become overshadowed by Recently, cryptographic transition plans have become overshadowed by
the prospect of the development of a cryptographically-relevant the prospect of the development of a cryptographically relevant
quantum computer. NSA has established the Commercial National quantum computer. The NSA has established the Commercial National
Security Algorithm (CNSA) Suite to provide vendors and IT users near- Security Algorithm (CNSA) Suite to provide vendors and IT users near-
term flexibility in meeting their IA interoperability requirements. term flexibility in meeting their cybersecurity interoperability
The purpose behind this flexibility is to avoid vendors and customers requirements. The purpose behind this flexibility is to avoid
making two major transitions in a relatively short timeframe, as we vendors and customers making two major transitions in a relatively
anticipate a need to shift to quantum-resistant cryptography in the short time frame, as we anticipate a need to shift to quantum-
near future. resistant cryptography in the near future.
NSA is publishing a set of RFCs, including this one, to provide The NSA is authoring a set of RFCs, including this one, to provide
updated guidance concerning the use of certain commonly available updated guidance concerning the use of certain commonly available
commercial algorithms in IETF protocols. These RFCs can be used in commercial algorithms in IETF protocols. These RFCs can be used in
conjunction with other RFCs and cryptographic guidance (e.g., NIST conjunction with other RFCs and cryptographic guidance (e.g., NIST
Special Publications) to properly protect Internet traffic and data- Special Publications) to properly protect Internet traffic and data-
at-rest for US Government National Security Systems. at-rest for US Government National Security Systems.
3. Conventions 3. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
4. General Requirements and Assumptions 4. General Requirements and Assumptions
The goal of this document is to define a base set of requirements for The goal of this document is to define a base set of requirements for
certificates and CRLs to support interoperability among CNSA Suite certificates and CRLs to support interoperability among CNSA Suite
solutions. Specific communities, such as those associated with US solutions. Specific communities, such as those associated with US
National Security Systems, may define community profiles that further National Security Systems, may define community profiles that further
restrict certificate and CRL contents by mandating the presence of restrict certificate and CRL contents by mandating the presence of
extensions that are optional in this base profile, defining new extensions that are optional in this base profile, defining new
optional or critical extension types, or restricting the values and/ optional or critical extension types, or restricting the values and/
or presence of fields within existing extensions. However, or presence of fields within existing extensions. However,
communications between distinct communities MUST conform to the communications between distinct communities MUST conform with the
requirements specified in this document when interoperability is requirements specified in this document when interoperability is
desired. Applications may add requirements for additional non- desired. Applications may add requirements for additional
critical extensions but they MUST NOT assume that a remote peer will non-critical extensions, but they MUST NOT assume that a remote peer
be able to process them. will be able to process them.
4.1. Implementing the CNSA Suite 4.1. Implementing the CNSA Suite
Every CNSA Suite certificate MUST use the X.509 v3 format, and Every CNSA Suite certificate MUST use the X.509 v3 format and contain
contain either: one of the following:
o An ECDSA-capable signature verification key using curve P-384; or o An ECDSA-capable signature verification key using curve P-384, or
o An ECDH-capable (Elliptic Curve Diffie-Hellman) key establishment o An ECDH-capable (Elliptic Curve Diffie-Hellman) key establishment
key using curve P-384; or key using curve P-384, or
o An RSA-capable signature verification key using RSA-3072 or RSA- o An RSA-capable signature verification key using RSA-3072 or
4096; or RSA-4096, or
o An RSA-capable key transport key using RSA-3072 or RSA-4096. o An RSA-capable key transport key using RSA-3072 or RSA-4096.
The signature algorithm applied to all CNSA Suite certificates and The signature applied to all CNSA Suite certificates and CRLs MUST be
CRLs MUST be made with a signing key generated on the curve P-384, or made with a signing key that is either generated on the curve P-384,
that is an RSA-3072 or RSA-4096 key, and with the SHA-384 hashing or is an RSA-3072 or RSA-4096 key. The SHA-384 hashing algorithm
algorithm. MUST be used for all certificate and CRL signatures irrespective of
the type of key used.
RSA exponents e MUST satisfy 2^16<e<2^256 and be odd per [FIPS186-4]. The RSA exponent "e" MUST satisfy 2^16<e<2^256 and be odd per
[FIPS186].
The requirements of this document are not intended to preclude use of The requirements of this document are not intended to preclude use of
RSASSA-PSS signatures. However, CAs conforming to this document will RSASSA-PSS signatures. However, Certification Authorities (CAs)
not issue certificates specifying that algorithm for subject public conforming with this document will not issue certificates specifying
keys. Protocols that use RSASSA-PSS should be configured to use that algorithm for subject public keys. Protocols that use RSASSA-
certificates that specify rsaEncryption as the subject public key PSS should be configured to use certificates that specify
algorithm. Protocols that use these keys with RSASSA-PSS signatures rsaEncryption as the subject public key algorithm. Protocols that
must use the following parameters: the hash algorithm (used for both use these keys with RSASSA-PSS signatures must use the following
mask generation and signature generation) must be SHA-384, the mask parameters: the hash algorithm (used for both mask generation and
generation function 1 from [RFC8017] must be used, and the salt signature generation) must be SHA-384, the mask generation function 1
length must be 48 octets. from [RFC8017] must be used, and the salt length must be 48 octets.
4.2. CNSA Suite Object Identifiers 4.2. CNSA Suite Object Identifiers
4.2.1. CNSA Suite Object Identifiers for ECDSA 4.2.1. CNSA Suite Object Identifiers for ECDSA
The primary Object Identifier (OID) structure for the CNSA Suite is The primary Object Identifier (OID) structure for the CNSA Suite is
as follows per [X9.62], [SEC2], [RFC5480], and [RFC5758]. as follows per [X962], [SEC2], [RFC5480], and [RFC5758].
ansi-X9-62 OBJECT IDENTIFIER ::= { ansi-X9-62 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) 10045 } iso(1) member-body(2) us(840) 10045 }
certicom-arc OBJECT IDENTIFIER ::= { certicom-arc OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) } iso(1) identified-organization(3) certicom(132) }
id-ecPublicKey OBJECT IDENTIFIER ::= { id-ecPublicKey OBJECT IDENTIFIER ::= {
ansi-X9-62 keyType(2) 1 } ansi-X9-62 keyType(2) 1 }
skipping to change at page 6, line 37 skipping to change at page 7, line 17
This section specifies changes to the basic requirements in [RFC5280] This section specifies changes to the basic requirements in [RFC5280]
for applications that create or use CNSA Suite certificates. Note for applications that create or use CNSA Suite certificates. Note
that RFC 5280 has varying mandates for marking extensions as critical that RFC 5280 has varying mandates for marking extensions as critical
or non-critical. This profile changes some of those mandates for or non-critical. This profile changes some of those mandates for
extensions that are included in CNSA Suite certificates. extensions that are included in CNSA Suite certificates.
5.1. signatureAlgorithm 5.1. signatureAlgorithm
5.1.1. ECDSA 5.1.1. ECDSA
For ECDSA, the algorithm identifier used by the CNSA Suite is: For ECDSA, the algorithm identifier used by the CNSA Suite is as
described in [RFC5758] and [X962]:
1.2.840.10045.4.3.3 for ecdsa-with-SHA384, as described in 1.2.840.10045.4.3.3 for ecdsa-with-SHA384
[RFC5758] and [X9.62].
The parameters MUST be absent as per [RFC5758]. The parameters MUST be absent as per [RFC5758].
5.1.2. RSA 5.1.2. RSA
For RSA, the algorithm identifier used by the CNSA Suite is: For RSA, the algorithm identifier used by the CNSA Suite is as
described in [RFC4055]:
1.2.840.113549.1.1.12 for sha384WithRSAEncryption, as described in 1.2.840.113549.1.1.12 for sha384WithRSAEncryption.
[RFC4055]
Per [RFC4055], the parameters MUST be NULL. Implementations MUST Per [RFC4055], the parameters MUST be NULL. Implementations MUST
accept the parameters being absent as well as present. accept the parameters being absent as well as present.
5.2. signatureValue 5.2. signatureValue
5.2.1. ECDSA 5.2.1. ECDSA
ECDSA digital signature generation is described in [FIPS186-4]. An ECDSA digital signature generation is described in [FIPS186]. An
ECDSA signature value is composed of two unsigned integers, denoted 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 as "r" and "s". "r" and "s" MUST be represented as ASN.1 INTEGERs.
high order bit of the unsigned integer is a 1, an octet with the If the high-order bit of the unsigned integer is a 1, an octet with
value 0x00 MUST be prepended to the binary representation before the value 0x00 MUST be prepended to the binary representation before
encoding it as an ASN.1 INTEGER. Unsigned integers for the P-384 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 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 and "s" to an ASN.1 INTEGER will result in a maximum of 49 bytes for
the P-384 curve. the P-384 curve.
The ECDSA signatureValue in an X.509 certificate is encoded as a BIT The ECDSA signatureValue in an X.509 certificate is encoded as a BIT
STRING value of a DER-encoded SEQUENCE of the two INTEGERS. STRING value of a DER-encoded SEQUENCE of the two INTEGERS.
5.2.2. RSA 5.2.2. RSA
The RSA signature generation process and the encoding of the result 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 is RSASSA-PKCS1-v1_5 as described in detail in PKCS #1 version 2.2
[RFC8017] [RFC8017].
5.3. Version 5.3. Version
For this profile, Version MUST be v3, which means the value MUST be For this profile, Version MUST be v3, which means the value MUST be
set to 2. set to 2.
5.4. SubjectPublicKeyInfo 5.4. SubjectPublicKeyInfo
5.4.1. Elliptic Curve Cryptography 5.4.1. Elliptic Curve Cryptography
For ECDSA signature verification keys and ECDH key agreement keys, For ECDSA signature verification keys and ECDH key agreement keys,
the algorithm ID id-ecPublicKey MUST be used. the algorithm ID id-ecPublicKey MUST be used.
The parameters of the AlgorithmIdentifier in this field MUST use the The parameters of the AlgorithmIdentifier in this field MUST use the
namedCurve option. The specifiedCurve and implicitCurve options namedCurve option. The specifiedCurve and implicitCurve options
described in [RFC5480] MUST NOT be used. The namedCurve MUST be the described in [RFC5480] MUST NOT be used. The namedCurve MUST be the
OID for secp384r1 (curve P-384) [RFC5480]. OID for secp384r1 (curve P-384) [RFC5480].
The elliptic curve public key, ECPoint, SHALL be the OCTET STRING The elliptic curve public key, ECPoint, SHALL be the OCTET STRING
representation of an elliptic curve point following the conversion 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 routine in Section 2.2 of [RFC5480] and Sections 2.3.1 and 2.3.2 of
[SEC1]. [SEC1].
CNSA Suite implementations MAY use either the uncompressed form or CNSA Suite implementations MAY use either the uncompressed form or
the compressed form of the elliptic curve point [RFC5480]. For the compressed form of the elliptic curve point [RFC5480]. For
interoperability purposes, all relying parties MUST be prepared to interoperability purposes, all relying parties MUST be prepared to
process the uncompressed form. process the uncompressed form.
The elliptic curve public key (an ECPoint that is an OCTET STRING) is The elliptic curve public key (an ECPoint that is an OCTET STRING) is
mapped to a subjectPublicKey (a BIT STRING) as follows: the most mapped to a subjectPublicKey (a BIT STRING) as follows: the most
significant bit of the OCTET STRING becomes the most significant bit significant bit of the OCTET STRING becomes the most significant bit
of the BIT STRING and the least significant bit of the OCTET STRING of the BIT STRING, and the least significant bit of the OCTET STRING
becomes the least significant bit of the BIT STRING [RFC5480]. becomes the least significant bit of the BIT STRING [RFC5480].
5.4.2. RSA 5.4.2. RSA
For RSA signature verification keys and key transport keys, the For RSA signature verification keys and key transport keys, the
algorithm ID, rsaEncryption MUST be used. algorithm ID, rsaEncryption, MUST be used.
The parameters field MUST have ASN.1 type NULL for this algorithm The parameters field MUST have ASN.1 type NULL for this algorithm
identifier [RFC3279]. identifier [RFC3279].
The RSA public key MUST be encoded using the ASN.1 type RSAPublicKey The RSA public key MUST be encoded using the ASN.1 type RSAPublicKey
per section 2.3.1 of [RFC3279]. per Section 2.3.1 of [RFC3279].
6. Certificate Extensions for Particular Types of Certificates 6. Certificate Extensions for Particular Types of Certificates
Different types of certificates in this profile have different Different types of certificates in this profile have different
required and recommended extensions. Those are listed in this required and recommended extensions. Those are listed in this
section. Those extensions from RFC 5280 not explicitly listed in section. Those extensions from RFC 5280 not explicitly listed in
this profile remain at the requirement levels of RFC 5280. this profile remain at the requirement levels of RFC 5280.
6.1. CNSA Suite Self-Signed CA Certificates 6.1. CNSA Suite Self-Signed CA Certificates
In adherence with [RFC5280], self-signed CA certificates in this In adherence with [RFC5280], self-signed CA certificates in this
profile MUST contain the subjectKeyIdentifier, keyUsage, and profile MUST contain the subjectKeyIdentifier, keyUsage, and
basicConstraints extensions. basicConstraints extensions.
The keyUsage extension MUST be marked as critical. The keyCertSign The keyUsage extension MUST be marked as critical. The keyCertSign
and cRLSign bits MUST be set. The digitalSignature and and cRLSign bits MUST be set. The digitalSignature and
nonRepudiation bits MAY be set. All other bits MUST NOT be set. nonRepudiation bits MAY be set. All other bits MUST NOT be set.
In adherence with [RFC5280], the basicConstraints extension MUST be In adherence with [RFC5280], the basicConstraints extension MUST be
marked as critical. The cA boolean MUST be set to indicate that the marked as critical. The cA boolean MUST be set to indicate that the
subject is a CA and the pathLenConstraint MUST NOT be present. subject is a CA, and the pathLenConstraint MUST NOT be present.
6.2. CNSA Suite Non-Self-Signed CA Certificates 6.2. CNSA Suite Non-Self-Signed CA Certificates
Non-self-signed CA Certificates in this profile MUST contain the Non-self-signed CA Certificates in this profile MUST contain the
authorityKeyIdentifier, keyUsage, and basicConstraints extensions. authorityKeyIdentifier, keyUsage, and basicConstraints extensions.
If there is a policy to be asserted, then the certificatePolicies If there is a policy to be asserted, then the certificatePolicies
extension MUST be included. extension MUST be included.
The keyUsage extension MUST be marked as critical. The keyCertSign The keyUsage extension MUST be marked as critical. The keyCertSign
and CRLSign bits MUST be set. The digitalSignature and and CRLSign bits MUST be set. The digitalSignature and
nonRepudiation bits MAY be set. All other bits MUST NOT be set. nonRepudiation bits MAY be set. All other bits MUST NOT be set.
In adherence with [RFC5280], the basicConstraints extension MUST be In adherence with [RFC5280], the basicConstraints extension MUST be
marked as critical. The cA boolean MUST be set to indicate that the marked as critical. The cA boolean MUST be set to indicate that the
subject is a CA and the pathLenConstraint subfield is OPTIONAL. subject is a CA, and the pathLenConstraint subfield is OPTIONAL.
If a policy is asserted, the certificatePolicies extension MUST be If a policy is asserted, the certificatePolicies extension MUST be
marked as non-critical, MUST contain the OIDs for the applicable marked as non-critical, MUST contain the OIDs for the applicable
certificate policies and SHOULD NOT use the policyQualifiers option. certificate policies, and SHOULD NOT use the policyQualifiers option.
If a policy is not asserted, the certificatePolicies extension MUST If a policy is not asserted, the certificatePolicies extension MUST
be omitted. be omitted.
Relying party applications conforming to this profile MUST be Relying party applications conforming to this profile MUST be
prepared to process the policyMappings, policyConstraints, and prepared to process the policyMappings, policyConstraints, and
inhibitAnyPolicy extensions, regardless of criticality, following the inhibitAnyPolicy extensions, regardless of criticality, following the
guidance in [RFC5280] when they appear in non-self-signed CA guidance in [RFC5280] when they appear in non-self-signed CA
certificates. certificates.
6.3. CNSA Suite End Entity Signature and Key Establishment Certificates 6.3. CNSA Suite End-Entity Signature and Key Establishment Certificates
In adherence with [RFC5280], end entity certificates in this profile In adherence with [RFC5280], end-entity certificates in this profile
MUST contain the authorityKeyIdentifier and keyUsage extensions. If MUST contain the authorityKeyIdentifier and keyUsage extensions. If
there is a policy to be asserted, then the certificatePolicies there is a policy to be asserted, then the certificatePolicies
extension MUST be included. End entity certificates SHOULD contain extension MUST be included. End-entity certificates SHOULD contain
the subjectKeyIdentifier extension. the subjectKeyIdentifier extension.
The keyUsage extension MUST be marked as critical. The keyUsage extension MUST be marked as critical.
For end entity digital signature certificates, the keyUsage extension For end-entity digital signature certificates, the keyUsage extension
MUST be set for digitalSignature. The nonRepudiation bit MAY be set. MUST be set for digitalSignature. The nonRepudiation bit MAY be set.
All other bits in the keyUsage extension MUST NOT be set. All other bits in the keyUsage extension MUST NOT be set.
For end entity key establishment certificates, in ECDH certificates For end-entity key establishment certificates, in ECDH certificates,
the keyUsage extension MUST BE set for keyAgreement, and in RSA the keyUsage extension MUST be set for keyAgreement; in RSA
certificates the keyUsage extension MUST be set for keyEncipherment. certificates, the keyUsage extension MUST be set for keyEncipherment.
The encipherOnly or decipherOnly bit MAY be set. All other bits in The encipherOnly or decipherOnly bit MAY be set. All other bits in
the keyUsage extension MUST NOT be set. the keyUsage extension MUST NOT be set.
If a policy is asserted, the certificatePolicies extension MUST be If a policy is asserted, the certificatePolicies extension MUST be
marked as non-critical, MUST contain the OIDs for the applicable marked as non-critical, MUST contain the OIDs for the applicable
certificate policies and SHOULD NOT use the policyQualifiers option. certificate policies, and SHOULD NOT use the policyQualifiers option.
If a policy is not asserted, the certificatePolicies extension MUST If a policy is not asserted, the certificatePolicies extension MUST
be omitted. be omitted.
7. CNSA Suite CRL Requirements 7. CNSA Suite CRL Requirements
This CNSA Suite CRL profile is a profile of [RFC5280]. There are This CNSA Suite CRL profile is a profile of [RFC5280]. There are
changes in the requirements from [RFC5280] for the signatures on CRLs changes in the requirements from [RFC5280] for the signatures on CRLs
of this profile. of this profile.
The signatures on CRLs in this profile MUST follow the same rules The signatures on CRLs in this profile MUST follow the same rules
from this profile that apply to signatures in the certificates, see from this profile that apply to signatures in the certificates. See
section 4. Section 4.
8. Security Considerations 8. Security Considerations
The security considerations in [RFC3279], [RFC4055], [RFC5280], The security considerations in [RFC3279], [RFC4055], [RFC5280],
[RFC5480], and [RFC5758], and [RFC8017] apply. [RFC5480], [RFC5758], and [RFC8017] apply.
A single key pair SHOULD NOT be used for both signature and key A single key pair SHOULD NOT be used for both signature and key
establishment per [SP-800-57]. establishment per [SP80057].
9. IANA Considerations 9. IANA Considerations
No IANA actions are required. This document has no IANA actions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[FIPS186-4] [CNSA] Committee for National Security Systems, "Use of Public
National Institute of Standards and Technology, "Digital Standards for Secure Information Sharing", CNSSP 15,
Signature Standard", FIPS 186-4, July 2013, October 2016,
<http://nvlpubs.nist.gov/nistpubs/FIPS/ <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>. NIST.FIPS.186-4.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
skipping to change at page 11, line 40 skipping to change at page 12, line 22
"PKCS #1: RSA Cryptography Specifications Version 2.2", "PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016, RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/info/rfc8017>. <https://www.rfc-editor.org/info/rfc8017>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[SEC1] Standards for Efficient Cryptography Group, "SEC1: [SEC1] Standards for Efficient Cryptography Group, "SEC1:
Elliptic Curve Cryptography", May 2009, Elliptic Curve Cryptography", May 2009,
<http://www.secg.org/sec1-v2.pdf>. <https://www.secg.org/sec1-v2.pdf>.
10.2. Informative References 10.2. Informative References
[CNSA] Committee for National Security Systems, "Commercial
National Security Algorithm (CNSA) Suite", 2015,
<https://www.iad.gov/iad/programs/iad-initiatives/
cnsa-suite.cfm>.
[SEC2] Standards for Efficient Cryptography Group, "SEC 2: [SEC2] Standards for Efficient Cryptography Group, "SEC 2:
Recommended Elliptic Curve Domain Parameters", September Recommended Elliptic Curve Domain Parameters", January
2000. 2010, <https://www.secg.org/sec2-v2.pdf>.
[SP-800-57] [SP80057] National Institute of Standards and Technology,
Barker, E., "Recommendation for Key Management-Part 1 "Recommendation for Key Management - Part 1: General",
Revision 4: General", Special Publication 800 57, January NIST Special Publication 800-57 Revision 4,
2016, DOI 10.6028/NIST.SP.800-57pt1r4, January 2016,
<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-57pt1r4.pdf>. NIST.SP.800-57pt1r4.pdf>.
[SP-800-59] [SP80059] National Institute of Standards and Technology, "Guideline
Barker, W., "Guideline for Identifying an Information for Identifying an Information System as a National
System as a National Security System", Special Publication Security System", NIST Special Publication 800-59,
800 59, August 2003, DOI 10.6028/NIST.SP.800-59, August 2003,
<https://csrc.nist.gov/publications/detail/sp/800-59/ > <https://csrc.nist.gov/publications/detail/sp/800-59/
final>. final>.
[X9.62] American National Standards Institute, "Public Key [X962] American National Standards Institute, "Public Key
Cryptography for the Financial Services Industry; The Cryptography for the Financial Services Industry; The
Elliptic Curve Digital Signature Algorithm (ECDSA)", Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI
ANS X9.62, December 2005. X9.62, November 2005.
Authors' Addresses Authors' Addresses
Michael Jenkins Michael Jenkins
National Security Agency National Security Agency
Email: mjjenki@nsa.gov Email: mjjenki@nsa.gov
Lydia Zieglar Lydia Zieglar
National Security Agency National Security Agency
 End of changes. 65 change blocks. 
162 lines changed or deleted 157 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/