Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for Certificates and Certificate Revocation Lists
draft-jenkins-cnsa2-pkix-profile-04
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Michael J. Jenkins , Alison Becker | ||
| Last updated | 2026-04-02 | ||
| RFC stream | Independent Submission | ||
| Intended RFC status | Informational | ||
| Formats | |||
| Stream | ISE state | In ISE Review | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-jenkins-cnsa2-pkix-profile-04
Network Working Group M. Jenkins
Internet-Draft NSA-CCSS
Obsoletes: 8603 (if approved) A. Becker
Intended status: Informational 2 April 2026
Expires: 4 October 2026
Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for
Certificates and Certificate Revocation Lists
draft-jenkins-cnsa2-pkix-profile-04
Abstract
This document specifies a profile of X.509 v3 Certificates and X.509
v2 Certificate Revocation Lists for applications that use Commercial
National Security Algorithm Suite published by the United States
Government.
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.
This memo is not an IETF standard, and does not represent IETF
community consensus. The profile is made publicly available for use
by developers and operators of these and any other system
deployments. This document obsoletes [RFC8603], the CNSA 1.0
guidance.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 4 October 2026.
Jenkins & Becker Expires 4 October 2026 [Page 1]
Internet-Draft CNSA2 Cert and CRL Profile April 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Commercial National Security Algorithm Suite . . . . . . 3
4. General Requirements . . . . . . . . . . . . . . . . . . . . 4
5. CNSA Suite Object Identifiers . . . . . . . . . . . . . . . . 5
6. CNSA Suite Base Certificate Required Values . . . . . . . . . 5
6.1. signature and signatureAlgorithm . . . . . . . . . . . . 6
6.2. signatureValue . . . . . . . . . . . . . . . . . . . . . 6
6.3. version . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.4. subjectPublicKeyInfo . . . . . . . . . . . . . . . . . . 6
7. Certificate Extensions for Particular Types of
Certificates . . . . . . . . . . . . . . . . . . . . . . 6
7.1. CNSA Suite Self-Signed CA Certificates . . . . . . . . . 6
7.2. CNSA Suite Non-Self-Signed CA Certificates . . . . . . . 7
7.3. CNSA Suite End-Entity Signature and Key Establishment
Certificates . . . . . . . . . . . . . . . . . . . . . . 7
8. CNSA Suite CRL Requirements . . . . . . . . . . . . . . . . . 8
9. Requirements for Other Revocation Notification Methods . . . 8
10. Security Considerations . . . . . . . . . . . . . . . . . . . 8
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
12.1. Normative References . . . . . . . . . . . . . . . . . . 8
12.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. 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 [cnsafaq]. 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]. The profile is also
Jenkins & Becker Expires 4 October 2026 [Page 2]
Internet-Draft CNSA2 Cert and CRL Profile April 2026
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" [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 [RFC5280]. All MUST-level requirements of
[RFC5280] 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
[RFC5280]". This profile contains changes that elevate some SHOULD-
level options in [RFC5280] to MUST-level and also contains changes
that elevate some MAY-level options in [RFC5280] to SHOULD-level or
MUST-level. All options from [RFC5280] that are not listed in this
profile remain at the requirement level of [RFC5280].
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 [RFC8603].
2. 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 [RFC2119] [RFC8174] 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 ([RFC5280] 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
[cnsafaq], unless stated otherwise.
3. 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
Jenkins & Becker Expires 4 October 2026 [Page 3]
Internet-Draft CNSA2 Cert and CRL Profile April 2026
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 [cnsafaq].
The National Institute for Standards and Technology (NIST) has
standardized several post-quantum asymmetric algorithms. From these,
NSA has selected two: ML-DSA-87 [FIPS204] for signing and ML-KEM-1024
[FIPS203] 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.
4. 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:
* [RFC9881] for the algorithm identifier, and the syntax and
semantics for the Subject Public Key Information field in
certificates that support ML-DSA-87 and
Jenkins & Becker Expires 4 October 2026 [Page 4]
Internet-Draft CNSA2 Cert and CRL Profile April 2026
* [RFC9935] 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 [FIPS204] and
Section 8 of [RFC9881] 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.
5. CNSA Suite Object Identifiers
The object identifiers for use of CNSA 2.0 Suite in certificates and
CRLs are defined in [RFC9881] and [RFC9935]. 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:
id-ml-dsa-87 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) sigAlgs(3) 19 }
id-alg-ml-kem-1024 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) kems(4) 3 }
6. CNSA Suite Base Certificate Required Values
This section specifies changes to the basic requirements in [RFC5280]
for applications that create or use CNSA Suite certificates. Note
that [RFC5280] 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.
Jenkins & Becker Expires 4 October 2026 [Page 5]
Internet-Draft CNSA2 Cert and CRL Profile April 2026
6.1. 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.
6.2. signatureValue
ML-DSA digital signature generation is described in [FIPS204]. 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 [RFC9881] MUST be
followed.
6.3. version
For this profile, the version field MUST be set to INTEGER value
0x02, indicating that the certificate conforms to X.509 version 3.
6.4. 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.
7. 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 [RFC5280] not explicitly listed in
this profile remain at the requirement levels of [RFC5280].
7.1. CNSA Suite Self-Signed CA Certificates
In adherence with [RFC5280], self-signed CA certificates in this
profile MUST contain the subjectKeyIdentifier, keyUsage, and
basicConstraints extensions.
Jenkins & Becker Expires 4 October 2026 [Page 6]
Internet-Draft CNSA2 Cert and CRL Profile April 2026
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 [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.
7.2. 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 [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.
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 [RFC5280] when they appear in non-self-signed CA
certificates.
7.3. CNSA Suite End-Entity Signature and Key Establishment Certificates
In adherence with [RFC5280], 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.
Jenkins & Becker Expires 4 October 2026 [Page 7]
Internet-Draft CNSA2 Cert and CRL Profile April 2026
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.
8. CNSA Suite CRL Requirements
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.
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 and Section 6.2.
9. 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 Section 4, and with section 4.2.2.2 of [RFC6960].
10. Security Considerations
This document introduces no security considerations beyond those in
[RFC5280], of which it is a profile.
11. IANA Considerations
This document has no IANA actions.
12. References
12.1. Normative References
Jenkins & Becker Expires 4 October 2026 [Page 8]
Internet-Draft CNSA2 Cert and CRL Profile April 2026
[cnsafaq] National Security Agency, "The Commercial National
Security Algorithm Suite 2.0 and Quantum Computing FAQ",
December 2024, <https://media.defense.gov/2022/
Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF>.
[FIPS203] National Institute of Standards and Technology, "Module-
Lattice-Based Key Establishment Mechanism Standard",
Federal Information Processing Standard 203,
DOI 10.6028/NIST.FIPS.203, August 2023,
<https://doi.org/10.6028/NIST.FIPS.203>.
[FIPS204] National Institute of Standards and Technology, "Module-
Lattice-Based Digital Signature Standard", Federal
Information Processing Standard 204,
DOI 10.6028/NIST.FIPS.204, August 2023,
<https://doi.org/10.6028/NIST.FIPS.204>.
[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>.
[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>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/info/rfc6960>.
[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>.
[RFC8603] Jenkins, M. and L. Zieglar, "Commercial National Security
Algorithm (CNSA) Suite Certificate and Certificate
Revocation List (CRL) Profile", RFC 8603,
DOI 10.17487/RFC8603, May 2019,
<https://www.rfc-editor.org/info/rfc8603>.
Jenkins & Becker Expires 4 October 2026 [Page 9]
Internet-Draft CNSA2 Cert and CRL Profile April 2026
[RFC9881] Massimo, J., Kampanakis, P., Turner, S., and B. E.
Westerbaan, "Internet X.509 Public Key Infrastructure --
Algorithm Identifiers for the Module-Lattice-Based Digital
Signature Algorithm (ML-DSA)", RFC 9881,
DOI 10.17487/RFC9881, October 2025,
<https://www.rfc-editor.org/info/rfc9881>.
[RFC9935] Turner, S., Kampanakis, P., Massimo, J., and B. E.
Westerbaan, "Internet X.509 Public Key Infrastructure -
Algorithm Identifiers for the Module-Lattice-Based Key-
Encapsulation Mechanism (ML-KEM)", RFC 9935,
DOI 10.17487/RFC9935, March 2026,
<https://www.rfc-editor.org/info/rfc9935>.
12.2. Informative References
[SP80059] National Institute of Standards and Technology, "Guideline
for Identifying an Information System as a National
Security System", Special Publication 59,
DOI 10.6028/NIST.SP.800-59, August 2003,
<https://csrc.nist.gov/publications/detail/sp/800-59/
final>.
Authors' Addresses
Michael Jenkins
NSA Center for Cybersecurity Standards
Email: mjjenki@cyber.nsa.gov
Alison Becker
Email: aebecke@uwe.nsa.gov
Jenkins & Becker Expires 4 October 2026 [Page 10]