Network Working Group M. Jenkins
Internet-Draft A. Becker
Updates: 8756 (if approved) NSA
Intended status: Informational 29 August 2025
Expires: 2 March 2026
Commercial National Security Algorithm (CNSA) Suite Profile of
Certificate Management over CMS
draft-jenkins-cnsa2-cmc-profile-01
Abstract
This document specifies a profile of the Certificate Management over
CMS (CMC) protocol for managing X.509 public key certificates in
applications that use the Commercial National Security Algorithm
(CNSA) 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 manage X.509
public key certificates over CMS. 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 here for
use by developers and operators of these and any other system
deployments.
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 2 March 2026.
Jenkins & Becker Expires 2 March 2026 [Page 1]
Internet-Draft CNSA2 CMC Profile August 2025
Copyright Notice
Copyright (c) 2025 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. Client Requirements: Generating PKI Requests . . . . . . . . 5
5.1. Tagged Certification Request . . . . . . . . . . . . . . 5
5.2. Certificate Request Message . . . . . . . . . . . . . . . 6
6. RA Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. RA Processing of Requests . . . . . . . . . . . . . . . . 7
6.2. RA-Generated PKI Requests . . . . . . . . . . . . . . . . 8
6.3. RA-Generated PKI Responses . . . . . . . . . . . . . . . 9
7. CA Requirements . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. CA Processing of PKI Requests . . . . . . . . . . . . . . 9
7.2. CA-Generated PKI Responses . . . . . . . . . . . . . . . 10
8. Client Requirements: Processing PKI Responses . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
This document specifies a profile of the Certificate Management over
CMS (CMC) protocol to comply with the United States National Security
Agency's Commercial National Security Algorithm (CNSA) Suite
[cnsafaq]. The profile applies to the capabilities, configuration,
and operation of all components of US National Security Systems that
employ managed X.509 certificates. US National Security Systems are
described in NIST Special Publication 800-59 [SP80059]. 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.
Jenkins & Becker Expires 2 March 2026 [Page 2]
Internet-Draft CNSA2 CMC Profile August 2025
This document does not define any new cryptographic algorithm;
instead, it defines a CNSA-compliant profile of CMC. CMC is defined
in [RFC5272], [RFC5273], and [RFC5274] and is updated by [RFC6402].
This document profiles CMC to manage X.509 public key certificates in
compliance with the CNSA Suite Certificate and Certificate Revocation
List (CRL) profile [I-D.jenkins-cnsa2-pkix-profile]. This document
specifically focuses on defining CMC interactions for both the
initial enrollment and rekey of CNSA Suite public key certificates
between a client and a Certification Authority (CA). One or more
Registration Authorities (RAs) may act as intermediaries between the
client and the CA. This profile may be further tailored by specific
communities to meet their needs. Specific communities will also
define certificate policies that implementations need to comply with.
This memo is not an IETF standard, and does not represent IETF
community consensus.
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.
The terminology in [RFC5272] Section 2.1 applies to this profile.
The term "certificate request" is used to refer to a single PKCS #10
or Certificate Request Message Format (CRMF) structure. All PKI
Requests are Full PKI Requests, and all PKI Responses are Full PKI
Responses; the respective set of terms should be interpreted
synonymously in this document.
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
information concerning their proper use and configuration within the
scope of US Government National Security Systems.
The Commercial National Security Algorithm (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”,
Jenkins & Becker Expires 2 March 2026 [Page 3]
Internet-Draft CNSA2 CMC Profile August 2025
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”, establishes
fully PQ protection [cnsafaq].
The National Institute for Standards and Technology (NIST) has
standardized several post-quantum asymmetric algorithms. From these,
NSA has selected two: one for signing ML-DSA-87, and another for key
management ML-KEM-1024. With SHA384 (or SHA512), 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 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.
4. General Requirements
This document assumes that the required trust anchors have been
securely provisioned to the client and, when applicable, to any RAs.
All requirements in [RFC5272], [RFC5273], [RFC5274], and [RFC6402]
apply, except where overridden by this profile.
The term "client" in this profile typically refers to an end-entity.
However, it may instead refer to a third party acting on the end-
entity's behalf. The client may or may not be the entity that
actually generates the key pair, but it does perform the CMC protocol
interactions with the RA and/or CA. For example, the client may be a
token management system that communicates with a cryptographic token
through an out-of-band secure protocol.
This profile uses the term "rekey" in the same manner as CMC does
(defined in [RFC5272] Section 2). The profile makes no specific
statements about the ability to do "renewal" operations; however, the
statements applicable to "rekey" should be applied to "renewal" as
well.
This profile may be used to manage RA and/or CA certificates. In
that case, the RA and/or CA whose certificate is being managed is
considered to be the end-entity.
Jenkins & Becker Expires 2 March 2026 [Page 4]
Internet-Draft CNSA2 CMC Profile August 2025
5. Client Requirements: Generating PKI Requests
This section specifies the conventions employed when a client
requests a certificate from a Public Key Infrastructure (PKI).
The Full PKI Request MUST be used; it MUST be encapsulated in a
SignedData; and the SignedData MUST be constructed in accordance with
[draft-becker-cnsa2-smime-profile-00]. The PKIData content type
defined in [RFC5272] is used with the following additional
requirements:
* controlSequence SHOULD be present. TransactionId and SenderNonce
SHOULD be included. Other CMC controls MAY be included.
* reqSequence MUST be present. It MUST include at least one tcr
(see Section 5.1) or crm (see Section 5.2) TaggedRequest. Support
for the orm choice is OPTIONAL.
The private signing key used to generate the encapsulating SignedData
MUST correspond to the public key of an existing signature
certificate unless an appropriate signature certificate does not yet
exist, such as during initial enrollment.
The encapsulating SignedData MUST be generated using SHA-384
(SignerInfo digestAlgorithm, to compute the message-digest attribute)
and ML-DSA-87 (SignerInfo signatureAlgorithm).
If an appropriate signature certificate does not yet exist, the Full
PKI Request MUST be signed using the private key corresponding to the
public key of one of the requested certificates.
5.1. Tagged Certification Request
The reqSequence tcr choice conveys PKCS #10 [RFC2986] syntax. The
CertificateRequest MUST comply with [RFC5272] Section 3.2.1.2.1, with
the following additional requirements:
* certificationRequestInfo:
- subjectPublicKeyInfo MUST be set as defined in
[I-D.jenkins-cnsa2-pkix-profile].
- Attributes:
o The ExtensionReq attribute MUST be included with its
contents as follows:
Jenkins & Becker Expires 2 March 2026 [Page 5]
Internet-Draft CNSA2 CMC Profile August 2025
+ The keyUsage extension MUST be included, and it MUST be
set as defined in [I-D.jenkins-cnsa2-pkix-profile].
+ For rekey requests, the SubjectAltName extension MUST be
included and set equal to the SubjectAltName of the
certificate that is being used to sign the SignedData
encapsulating the request (i.e., not the certificate
being rekeyed) if the subject field of the certificate
being used to generate the signature is NULL.
+ Other extension requests MAY be included as desired.
o The ChangeSubjectName attribute, as defined in [RFC6402],
MUST be included if the Full PKI Request encapsulating this
Tagged Certification Request is being signed by a key for
which a certificate currently exists and the existing
certificate's subject field or SubjectAltName extension does
not match the desired subject name or SubjectAltName
extension of this certification request.
- signatureAlgorithm MUST be id-ml-dsa-87.
- signature MUST be generated using the private key corresponding
to the public key in the CertificationRequestInfo for signature
certification requests, or with an existing signing private key
that has been previously certified to the same Subject.
5.2. Certificate Request Message
The reqSequence crm choice conveys Certificate Request Message Format
(CRMF) [RFC4211] syntax. The CertReqMsg MUST comply with [RFC5272]
Section 3.2.1.2.2, with the following additional requirements:
* popo MUST be included using the signature (POPOSigningKey) proof-
of-possession choice and be set as defined in [RFC4211]
Section 4.1 for both signature and key establishment certification
requests. The POPOSigningKey poposkInput field MUST be omitted.
The POPOSigningKey algorithmIdentifier MUST be id-ml-dsa-87. The
signature MUST be generated using the private key corresponding to
the public key in the CertTemplate, or to the public key in an
existing signature certificate issued to the same Subject.
The CertTemplate MUST comply with [RFC5272] Section 3.2.1.2.2, with
the following additional requirements:
* If version is included, it MUST be set to 2 as defined in
[I-D.jenkins-cnsa2-pkix-profile].
Jenkins & Becker Expires 2 March 2026 [Page 6]
Internet-Draft CNSA2 CMC Profile August 2025
* publicKey MUST be set as defined in
[I-D.jenkins-cnsa2-pkix-profile].
* Extensions:
- The keyUsage extension MUST be included, and it MUST be set as
defined in [I-D.jenkins-cnsa2-pkix-profile].
- For rekey requests, the SubjectAltName extension MUST be
included and set equal to the SubjectAltName of the certificate
that is being used to sign the SignedData encapsulating the
request (i.e., not the certificate being rekeyed) if the
subject name of the certificate being used to generate the
signature is NULL.
- Other extension requests MAY be included as desired.
* Controls:
- The ChangeSubjectName attribute, as defined in [RFC6402], MUST
be included if the Full PKI Request encapsulating this Tagged
Certification Request is being signed by a key for which a
certificate currently exists and the existing certificate's
subject name or SubjectAltName extension does not match the
desired subject name or SubjectAltName extension of this
certification request.
6. RA Requirements
This section addresses the optional case where one or more RAs act as
intermediaries between clients and a CA as described in [RFC5272]
Section 7. In this section, the term "client" refers to the entity
from which the RA received the PKI Request. This section is only
applicable to RAs.
6.1. RA Processing of Requests
RAs conforming to this document MUST ensure that only the permitted
signature, hash, and MAC algorithms described throughout this profile
are used in requests; if they are not, the RA MUST reject those
requests. The RA SHOULD return a CMCFailInfo with the value of
badAlg [RFC5272].
When processing end-entity-generated SignedData objects, RAs MUST NOT
perform Cryptographic Message Syntax (CMS) Content Constraints (CCC)
certificate extension processing [RFC6010].
Other RA processing is performed as described in [RFC5272].
Jenkins & Becker Expires 2 March 2026 [Page 7]
Internet-Draft CNSA2 CMC Profile August 2025
6.2. RA-Generated PKI Requests
RAs mediate the certificate request process by collecting client
requests in batches. The RA MUST encapsulate client-generated PKI
Requests in a new RA-signed PKI Request, it MUST create a Full PKI
Request encapsulated in a SignedData, and the SignedData MUST be
constructed in accordance with [draft-becker-cnsa2-smime-profile-00].
The PKIData content type complies with [RFC5272] with the following
additional requirements:
* controlSequence MUST be present. It MUST include the following
CMC controls: Transaction ID, Sender Nonce, and Batch Requests.
Other appropriate CMC controls MAY be included.
* cmsSequence MUST be present. It contains the original, unmodified
request(s) received from the client.
SignedData (applied by the RA)
PKIData
controlSequence (Transaction ID, Sender Nonce,
Batch Requests)
cmsSequence
SignedData (applied by client)
PKIData
controlSequence (Transaction ID, Sender Nonce)
reqSequence
TaggedRequest
{TaggedRequest}
{SignedData (second client request)
PKIData...}
Authorization to sign RA-generated Full PKI Requests SHOULD be
indicated in the RA certificate by inclusion of the id-kp-cmcRA
Extended Key Usage (EKU) from [RFC6402]. The RA certificate MAY also
include the CCC certificate extension [RFC6010], or it MAY indicate
authorization through inclusion of the CCC certificate extension
alone. The RA certificate may also be authorized through the local
configuration.
If the RA is authorized via the CCC extension, then the CCC extension
MUST include the object identifier for the PKIData content type. CCC
SHOULD be included if constraints are to be placed on the content
types generated.
The outer SignedData MUST be generated using SHA-384 (SignerInfo
digestAlgorithm, to compute the message-digest attribute) and ML-
DSA-87 (SignerInfo signatureAlgorithm).
Jenkins & Becker Expires 2 March 2026 [Page 8]
Internet-Draft CNSA2 CMC Profile August 2025
If the Full PKI Response is a successful response to a PKI Request
that only contained a Get Certificate or Get CRL control, then the
algorithm used in the response MUST match the algorithm used in the
request.
6.3. RA-Generated PKI Responses
An RA that also generates responses MUST assert authority to do so by
at least one of
* inclusion of the id-kp-cmcRA EKU from [RFC6402] in the RA
certificate (this method is preferred).
* inclusion of include the CCC certificate extension [RFC6010] in
the RA certificate, with the object identifier for the PKIResponse
content type.
* assertion of authorization through a locally configured
implementation-specific mechanism.
7. CA Requirements
This section specifies the requirements for CAs that receive PKI
Requests and generate PKI Responses.
7.1. CA Processing of PKI Requests
CAs conforming to this document MUST ensure that only the permitted
signature, hash, and MAC algorithms described throughout this profile
are used in requests; if they are not, the CA MUST reject those
requests. The CA SHOULD return a CMCStatusInfoV2 control with a
CMCStatus of failed and a CMCFailInfo with the value of badAlg
[RFC5272].
For requests involving an RA (i.e., batched requests), the CA MUST
verify the RA's authorization. The following certificate fields MUST
NOT be modifiable using the Modify Certification Request control:
publicKey and the keyUsage extension. The request MUST be rejected
if an attempt to modify those certification request fields is
present. The CA SHOULD return a CMCStatusInfoV2 control with a
CMCStatus of failed and a CMCFailInfo with a value of badRequest.
When processing end-entity-generated SignedData objects, CAs MUST NOT
perform CCC certificate extension processing [RFC6010].
If a client-generated PKI Request includes the ChangeSubjectName
attribute as described in Section 5.1 or Section 5.2 above, the CA
MUST ensure that name change is authorized. The mechanism for
Jenkins & Becker Expires 2 March 2026 [Page 9]
Internet-Draft CNSA2 CMC Profile August 2025
ensuring that the name change is authorized is out of scope. A CA
that performs this check and finds that the name change is not
authorized MUST reject the PKI Request. The CA SHOULD return an
Extended CMC Status Info control (CMCStatusInfoV2) with a CMCStatus
of failed.
Other processing of PKIRequests is performed as described in
[RFC5272].
7.2. CA-Generated PKI Responses
CAs send PKI Responses to both client-generated requests and RA-
generated requests. If a Full PKI Response is returned in direct
response to a client-generated request, it MUST be encapsulated in a
SignedData, and the SignedData MUST be constructed in accordance with
[draft-becker-cnsa2-smime-profile-00].
If the PKI Response is in response to an RA-generated PKI Request,
then the above PKI Response is encapsulated in another CA-generated
PKI Response. That PKI Response MUST be encapsulated in a
SignedData, and the SignedData MUST be constructed in accordance with
[draft-becker-cnsa2-smime-profile-00]. The above PKI Response is
placed in the encapsulating PKI Response cmsSequence field. The
other fields are as above with the addition of the batch response
control in controlSequence. The following illustrates a successful
CA response to an RA-encapsulated PKI Request, both of which include
Transaction IDs and Nonces:
SignedData (applied by the CA)
PKIResponse
controlSequence (Transaction ID, Sender Nonce, Recipient
Nonce, Batch Response)
cmsSequence
SignedData (applied by CA and includes returned
certificates)
PKIResponse
controlSequence (Transaction ID, Sender Nonce,
Recipient Nonce)
The same private key used to sign certificates MUST NOT be used to
sign Full PKI Response messages. Instead, a separate certificate
indicating authorization to sign CMC responses MUST be used.
Jenkins & Becker Expires 2 March 2026 [Page 10]
Internet-Draft CNSA2 CMC Profile August 2025
Authorization to sign Full PKI Responses SHOULD be indicated in the
CA certificate by inclusion of the id-kp-cmcCA EKU from [RFC6402].
The CA certificate MAY also include the CCC certificate extension
[RFC6010], or it MAY indicate authorization through inclusion of the
CCC certificate extension alone. The CA certificate may also be
authorized through local configuration.
In order for a CA certificate using the CCC certificate extension to
be authorized to generate responses, the object identifier for the
PKIResponse content type must be present in the CCC certificate
extension. CCC SHOULD be included if constraints are to be placed on
the content types generated.
Signatures applied to individual certificates are as required in
[I-D.jenkins-cnsa2-pkix-profile].
8. Client Requirements: Processing PKI Responses
Clients conforming to this document MUST ensure that only the
permitted signature, hash, and MAC algorithms described throughout
this profile are used in responses; if they are not, the client MUST
reject those responses.
Clients MUST authenticate all Full PKI Responses. This includes
verifying that the PKI Response is signed by an authorized CA or RA
whose certificate validates back to a trust anchor. The client MUST
verify that
* the CA certificate includes the id-kp-cmcCA EKU or a CCC extension
asserting the PKIResponse content type, or
* the CA is authorized to sign responses through a locally
configured implementation-specific mechanism.
The PKI Response can be signed by an RA if it is an error message, if
it is a response to a Get Certificate or Get CRL request, or if the
PKI Response contains an inner PKI Response signed by a CA. In the
last case, each layer of PKI Response MUST still contain an
authorized, valid signature signed by an entity with a valid
certificate that verifies back to an acceptable trust anchor. The
client MUST verify that
* the RA certificate includes the id-kp-cmcRA EKU or a CCC extension
that includes the object identifier for the PKIResponse content
type, or
* the RA is authorized to sign responses through a local configured
implementation-specific mechanism.
Jenkins & Becker Expires 2 March 2026 [Page 11]
Internet-Draft CNSA2 CMC Profile August 2025
When a newly issued certificate is included in the PKI Response, the
client MUST verify that the newly issued certificate's public key
matches the public key that the client requested. The client MUST
also ensure that the certificate's signature is valid and that the
signature validates back to an acceptable trust anchor.
Clients MUST reject PKI Responses that do not pass these tests.
Local policy will determine whether the client returns a Full PKI
Response with an Extended CMC Status Info control (CMCStatusInfoV2)
with the CMCStatus set to failed to a user console, error log, or the
server.
If the Full PKI Response contains an Extended CMC Status Info control
with a CMCStatus set to failed, then local policy will determine
whether the client resends a duplicate certification request back to
the server or an error state is returned to a console or error log.
9. Security Considerations
Protocol security considerations are found in [RFC2986], [RFC4211],
[draft-becker-cnsa2-smime-profile-00], [RFC5272], [RFC5273],
[RFC5274], [I-D.jenkins-cnsa2-pkix-profile], and [RFC6402]. When CCC
is used to authorize RA and CA certificates, then the security
considerations in [RFC6010] also apply. Algorithm security
considerations are found in [draft-becker-cnsa2-smime-profile-00].
This specification requires implementations to generate key pairs and
other random values. The use of inadequate pseudorandom number
generators (PRNGs) can result in little or no security. The
generation of quality random numbers is difficult. NIST Special
Publication 800-90A [SP80090A], FIPS 186-3 [FIPS186], and [RFC4086]
offer random number generation guidance.
When RAs are used, the list of authorized RAs MUST be securely
distributed out of band to CAs.
Presence of the POP Link Witness Version 2 and POP Link Random
attributes protects against substitution attacks.
The certificate policy for a particular environment will specify
whether expired certificates can be used to sign certification
requests.
10. IANA Considerations
This document has no IANA actions.
11. References
Jenkins & Becker Expires 2 March 2026 [Page 12]
Internet-Draft CNSA2 CMC Profile August 2025
11.1. Normative References
[draft-becker-cnsa2-smime-profile-00]
Jenkins, M. and A. Becker, "Commercial National Security
Algorithm (CNSA) Suite Profile for Secure/ Multipurpose
Internet Mail Extensions (S/MIME)", March 2025,
.
[I-D.jenkins-cnsa2-pkix-profile]
Jenkins, M. and A. Becker, "Commercial National Security
Algorithm Suite Certificate and Certificate Revocation
List Profile", January 2025,
.
[cnsafaq] National Security Agency, "The Commercial National
Security Algorithm Suite 2.0 and Quantum Computing FAQ",
December 2024, .
[FIPS186] National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", DOI 10.6028/NIST.FIPS.186-4,
FIPS PUB 186-4, July 2013,
.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000,
.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
.
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)", RFC 4211,
DOI 10.17487/RFC4211, September 2005,
.
Jenkins & Becker Expires 2 March 2026 [Page 13]
Internet-Draft CNSA2 CMC Profile August 2025
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
.
[RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC): Transport Protocols", RFC 5273,
DOI 10.17487/RFC5273, June 2008,
.
[RFC5274] Schaad, J. and M. Myers, "Certificate Management Messages
over CMS (CMC): Compliance Requirements", RFC 5274,
DOI 10.17487/RFC5274, June 2008,
.
[RFC6010] Housley, R., Ashmore, S., and C. Wallace, "Cryptographic
Message Syntax (CMS) Content Constraints Extension",
RFC 6010, DOI 10.17487/RFC6010, September 2010,
.
[RFC6402] Schaad, J., "Certificate Management over CMS (CMC)
Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011,
.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, .
11.2. Informative References
[SP80059] National Institute of Standards and Technology, "Guideline
for Identifying an Information System as a National
Security System", DOI 10.6028/NIST.SP.800-59, Special
Publication 800-59, August 2003,
.
[SP80090A] National Institute of Standards and Technology,
"Recommendation for Random Number Generation Using
Deterministic Random Bit Generators",
DOI 10.6028/NIST.SP.800-90Ar1, Special Publication
800-90A Revision 1, June 2015,
.
Authors' Addresses
Michael Jenkins
National Security Agency
Email: mjjenki@cyber.nsa.gov
Jenkins & Becker Expires 2 March 2026 [Page 14]
Internet-Draft CNSA2 CMC Profile August 2025
Alison Becker
National Security Agency
Email: aebecke@uwe.nsa.gov
Jenkins & Becker Expires 2 March 2026 [Page 15]