]> National Security Agency

mjjenki@cyber.nsa.gov

Security Network Working Group CNSA NSS certificate enrollment 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. This document obsoletes , the CNSA 1.0 guidance.

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 . 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 . 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 new cryptographic algorithm; instead, it defines a CNSA-compliant profile of CMC. CMC is defined in , , and and is updated by . This document profiles CMC to manage X.509 public key certificates in compliance with the CNSA Suite Certificate and Certificate Revocation List (CRL) 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. Non-requirement aspects of 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.

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. The terminology in 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.

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 (NSS). 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”, 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 . 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 establishment ML-KEM-1024. With SHA-384 (or 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 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.

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 , , , and 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 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 CA certificates. In that case, the terms "end-entity" and "end-entity certificate" refers to the RA and RA certificate or CA and CA certificate respectively. Note that this usage is ad hoc and is consistent with but not the definition which states that "End entity certificates are issued to subjects that are not authorized to issue certificates". Signatures MUST be ML-DSA-87. 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.

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 . The PKIData content type defined in 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 ) or crm (see ) 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. In that case, procedural means that ensure the identity of the requestor MUST be used; see . The encapsulating SignedData MUST be generated using SHA-384 (SignerInfo digestAlgorithm, when used to compute the message-digest attribute) and ML-DSA-87 (SignerInfo signatureAlgorithm). A Full PKI Request that is authenticated using a shared-secret (e.g. because no appropriate certificate exists yet to authenticate the request) MUST be signed using the private key corresponding to the public key of one of the requested certificates contained therein.

Tagged Certification Request The reqSequence tcr choice conveys PKCS #10 syntax. The CertificateRequest MUST comply with Section 3.2.1.2.1, with the following additional requirements:

• certificationRequestInfo:
  • subjectPublicKeyInfo MUST be set as defined in .
  • Attributes:
    • The ExtensionReq attribute MUST be included with its contents as follows:
      • The keyUsage extension MUST be included, and it MUST be set as defined in .
      • For rekey requests, if the subject field of the certificate being used to generate the signature is NULL, 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).
      • Other extension requests MAY be included as desired.
    • The ChangeSubjectName attribute, as defined in , 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.

Certificate Request Message The reqSequence crm choice conveys Certificate Request Message Format (CRMF) syntax. The CertReqMsg MUST comply with 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 Section 4.1 for signature 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 Section 3.2.1.2.2, with the following additional requirements:

• If version is included, it MUST be set to 2 as defined in .
• publicKey MUST be set as defined in .
• Extensions:
  • The keyUsage extension MUST be included, and it MUST be set as defined in .
  • 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 , 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.

RA Requirements This section addresses the optional case where one or more RAs act as intermediaries between clients and a CA as described in 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.

RA Processing of Requests RAs conforming to this document MUST ensure that only the permitted signature and hash 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 . When processing end-entity-generated SignedData objects, RAs MUST NOT perform Cryptographic Message Syntax (CMS) Content Constraints (CCC) certificate extension processing . Other RA processing is performed as described in .

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 . The PKIData content type complies with 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 . The RA certificate MAY also include the CCC certificate extension , 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). 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.

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 in the RA certificate (this method is preferred).
• inclusion of include the CCC certificate extension in the RA certificate, with the object identifier for the PKIResponse content type.
• assertion of authorization through a locally configured implementation-specific mechanism.

CA Requirements This section specifies the requirements for CAs that receive PKI Requests and generate PKI Responses.

CA Processing of PKI Requests CAs conforming to this document MUST ensure that only the permitted signature and hash 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 . 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 . If a client-generated PKI Request includes the ChangeSubjectName attribute as described in or above, the CA MUST ensure that name change is authorized. The mechanism for 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 .

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 . 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 . 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. Authorization to sign Full PKI Responses SHOULD be indicated in the CA certificate by inclusion of the id-kp-cmcCA EKU from . The CA certificate MAY also include the CCC certificate extension , 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 .

Client Requirements: Processing PKI Responses Clients conforming to this document MUST ensure that only the permitted signature and hash 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.

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, and document the rejection in a way appropriate to the system. For example, the client MAY construct a CMC Status Info control (CMCStatusInfoV2) with the CMC Stuats set to "failed", and display the code to a user console, append to an error log, or communicate to a server, depending on local policy. 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.

Security Considerations Protocol security considerations are found in , , , , , , , and . When CCC is used to authorize RA and CA certificates, then the security considerations in also apply. Algorithm security considerations are found in . 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 , FIPS 186 , and offer random number generation guidance. As is the case with all digital signature schemes, and especially those employed in security infrastructure, protection of private keys is paramount. Where possible, security tokens (e.g. HSMs) should be used to mitigate the risk of key compromise. 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.

IANA Considerations This document has no IANA actions.

References Normative References National Security Agency National Institute of Standards and Technology National Institute of Standards and Technology (2024) Informative References National Institute of Standards and Technology National Institute of Standards and Technology

Scenarios This section illustrates several potential certificate enrollment and rekey scenarios supported by this profile. This section does not intend to place any limits or restrictions on the use of CMC.

Initial Enrollment This section describes three scenarios for authenticating initial enrollment requests:

1. Previously certified signature key-pair (e.g., Manufacturer Installed Certificate).
2. Shared-secret distributed securely out of band.
3. RA authentication.

Previously Certified Signature Key-Pair In this scenario, the end-entity has a private signing key and a corresponding public key certificate obtained from a cryptographic module manufacturer recognized by the CA. The end-entity signs a Full PKI Request with the private key that corresponds to the subject public key of the previously installed signature certificate. The CA will verify the authorization of the previously installed certificate and issue an appropriate new certificate to the end-entity.

Shared-Secret Distributed Securely Out of Band In this scenario, the CA distributes a shared-secret out of band to the end-entity that the end-entity uses to authenticate its certification request. The end-entity signs the Full PKI Request with the private key for which the certification is being requested. The end-entity includes the Identity Proof Version 2 control to authenticate the request using the shared-secret. The CA uses either the Identification control or the subject name in the end-entity's enclosed PKCS #10 or CRMF certification request message to identify the request. The end-entity performs either the POP Link Witness Version 2 mechanism as described in Section 6.3.1.1 or the shared-secret/subject distinguished name linking mechanism as described in Section 6.3.2. The subject name in the enclosed PKCS #10 or CRMF certification request does not necessarily match the issued certificate, as it may be used just to help identify the request (and the corresponding shared-secret) to the CA.

RA Authentication In this scenario, the end-entity does not automatically authenticate its enrollment request to the CA, either because the end-entity has nothing to authenticate the request with or because the organizational policy requires an RA's involvement. The end-entity creates a Full PKI Request and sends it to an RA. The RA verifies the authenticity of the request. If the request is approved, the RA encapsulates and signs the request as described in , forwarding the new request on to the CA. The subject name in the PKCS #10 or CRMF certification request is not required to match the issued certificate; it may be used just to help identify the request to the RA and/or CA.

Rekey There are two scenarios to support the rekey of certificates that are already enrolled. One addresses the rekey of signature certificates, and the other addresses the rekey of key establishment certificates. Typically, organizational policy will require certificates to be currently valid to be rekeyed, and it may require initial enrollment to be repeated when rekey is not possible. However, some organizational policies might allow a grace period during which an expired certificate could be used to rekey.

Rekey of Signature Certificates When a signature certificate is rekeyed, the PKCS #10 or CRMF certification request message enclosed in the Full PKI Request will include the same subject name as the current signature certificate. The Full PKI Request will be signed by the current private key corresponding to the current signature certificate.

Rekey of Key Establishment Certificates When a key establishment certificate is rekeyed, the Full PKI Request will generally be signed by the current private key corresponding to the current signature certificate. If there is no current signature certificate, one of the initial enrollment options in may be used.