Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for Certificates and Certificate Revocation Lists

Introduction 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 2.0 . 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 . The profile 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. This document does not define any cryptographic algorithm; instead, it defines a CNSA-compliant profile of "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" . 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 . All MUST-level requirements of 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 ". This profile contains changes that elevate some SHOULD-level options in to MUST-level and also contains changes that elevate some MAY-level options in to SHOULD-level or MUST-level. All options from that are not listed in this profile remain at the requirement level of . This memo is not an IETF standard, and does not represent IETF community consensus. This document obsoletes the CSNA 1.0 guidance in RFC 8603 .

Terminology 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 when, and only when, they appear in all capitals, as shown here. Normative language does not apply beyond the scope of this profile. This is a profile of PKIX ( and other RFCs as cited). Therefore, the requirements language in this memo may be different than that found in the underlying standards. All references to "CNSA" in this document refer to CNSA 2.0 , unless stated otherwise.

The Commercial National Security Algorithm Suite 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 within the scope of US Government National Security Systems. The CNSA Suite is the set of approved commercial algorithms that can be used by vendors and IT users to meet cybersecurity and interoperability requirements for NSS. The first suite of CNSA Suite algorithms, "Suite B", established a baseline for use of commercial algorithms to protect classified information. The next suite, "CNSA 1.0", served as a bridge between the original set and a fully post-quantum cryptographic capability. The current suite, "CNSA 2.0", seeks to provide fully quantum-resistant protection . The National Institute for Standards and Technology (NIST) has standardized several post-quantum asymmetric algorithms. From these, NSA has selected two: ML-DSA-87 for signing and ML-KEM-1024 for key establishment. With SHA-384 (preferred, or alternatively SHA-512), AES-256, and LMS/XMSS, these comprise the CNSA Suite 2.0. The NSA is authoring a set of RFCs, including this one, to provide updated guidance for using CNSA 2.0 algorithms in certain 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.

General Requirements 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. The reader is assumed to have familiarity with these documents:

for the algorithm identifier, and the syntax and semantics for the Subject Public Key Information field in certificates that support ML-DSA-87 and
for the algorithm identifier, and the syntax and semantics for the Subject Public Key Information field in certificates that support ML-KEM-1024.

Every CNSA Suite certificate MUST use the X.509 v3 format and contain one of the following as its subject public key:

A ML-DSA-87 signature verification key.
A ML-KEM-1024 public encapsulation key.

The signature applied to all CNSA Suite certificates and CRLs MUST be made with a ML-DSA-87 signing key. The ML-DSA algorithm incorporates an internal hashing function, so there is no need to apply a hashing algorithm before signing. Where an application or implementation makes it more efficient to perform hashing externally, the external-μ mechanism described in Step 6 of Algorithm 7 of and Section 8 of MAY be used. Any other hashing outside of ML-DSA or ML-KEM MUST use either SHA-384 or SHA-512; SHA-384 SHOULD be used. HashML-DSA is not permitted.

CNSA Suite Object Identifiers The object identifiers for use of CNSA 2.0 Suite in certificates and CRLs are defined in and . These OIDs are used to identify both the algorithm associated with the public key (as part of the Subject Public Key Info field) and the signature on a certificate or CRL (as part of the signatureAlgorithm field in a Certificate or CertificateList and part of the signature field in a TBSCertificate and TBSCertList). They are repeated here for convenience:

CNSA Suite Base Certificate Required Values This section specifies changes to the basic requirements in for applications that create or use CNSA Suite certificates. Note that 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.

signature and signatureAlgorithm ML-DSA is indicated by the id-ml-dsa-87 OID in the AlgorithmIdentifier of the signature field in a TBSCertificate and TBSCertList, and by the signatureAlgorithm field in a Certificate and CertificateList. The contents of the parameters component for each algorithm MUST be absent.

signatureValue ML-DSA digital signature generation is described in . It is converted from a byte string to a DER encoded BIT STRING in the signatureValue field of a Certificate or CertificateList. Stipulations for signature generation from MUST be followed.

version For this profile, the version field MUST be set to INTEGER value 0x02, indicating that the certificate conforms to X.509 version 3.

subjectPublicKeyInfo For signature verification keys, the algorithm ID id-ml-dsa-87 MUST be used. For key establishment keys, the algorithm ID id-alg-ml-kem-1024 MUST be used. In either case, the contents of the parameters component of the AlgorithmIdentifier in this field MUST be absent.

Certificate Extensions for Particular Types of Certificates Different types of certificates in this profile have different required and recommended extensions. Those are listed in this section. Those extensions from not explicitly listed in this profile remain at the requirement levels of .

CNSA Suite Self-Signed CA Certificates In adherence with , self-signed CA certificates in this profile MUST contain the subjectKeyIdentifier, keyUsage, and basicConstraints extensions. 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. In adherence with , 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.

CNSA Suite Non-Self-Signed CA Certificates 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. 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. In adherence with , 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. 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. 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 when they appear in non-self-signed CA certificates.

CNSA Suite End-Entity Signature and Key Establishment Certificates In adherence with , end-entity certificates in this profile MUST contain the authorityKeyIdentifier and keyUsage extensions. End-entity certificates SHOULD contain the subjectKeyIdentifier extension. 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. For end-entity key establishment certificates, the keyUsage extension MUST be set for keyEncipherment. All other bits in the keyUsage extension MUST NOT be set. For all end-entity certificates, the extended key usage extension MUST be present to indicate the intended use of the certificate. The intended use MUST be consistent with the keyUsage extension. The anyExtendedKeyUsage MUST NOT be asserted. 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.

CNSA Suite CRL Requirements This CNSA Suite CRL profile is a profile of . There are changes in the requirements from for the signatures on CRLs of this profile. The signatures on CRLs in this profile MUST follow the same rules from this profile that apply to signatures in the certificates. See and .

Requirements for Other Revocation Notification Methods Revocation notification methods of any type MUST enable authentication of the issuing CA as the source of the revocation information. Specifically, an OCSP response MUST be signed conformant with , and with section 4.2.2.2 of .

Security Considerations This document introduces no security considerations beyond those in , of which it is a profile.

IANA Considerations This document has no IANA actions.