RFC 8756: Commercial National Security Algorithm (CNSA) Suite Profile of Certificate Management over CMS

Status of This Memo

This document is not an Internet Standards Track specification; it is published for informational purposes.¶

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for 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.¶

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/rfc8756.¶

Copyright Notice

Copyright (c) 2020 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.¶

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 [CNSA]. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems [SP80059]. It 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 suites; 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 [RFC8603]. 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.¶

2. 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 the US Government transition 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.¶

Recently, cryptographic transition plans have become overshadowed by the prospect of the development of a cryptographically relevant quantum computer. The NSA has established the Commercial National Security Algorithm (CNSA) Suite to provide vendors and IT users near-term flexibility in meeting their cybersecurity interoperability requirements. The purpose behind this flexibility is to avoid having vendors and customers make two major transitions in a relatively short timeframe, as we anticipate a need to shift to quantum-resistant cryptography in the near future.¶

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.¶

3. Requirements and Assumptions

Elliptic Curve Digital Signature Algorithm (ECDSA) and Elliptic Curve Diffie-Hellman (ECDH) key pairs are on the P-384 curve. FIPS 186-4 [FIPS186], Appendix B.4 provides useful guidance for elliptic curve key pair generation that SHOULD be followed by systems that conform to this document.¶

RSA key pairs (public, private) are identified by the modulus size expressed in bits; RSA-3072 and RSA-4096 are computed using moduli of 3072 bits and 4096 bits, respectively.¶

RSA signature key pairs used in CNSA Suite-compliant implementations are either RSA-3072 or RSA-4096. The RSA exponent e MUST satisfy 2¹⁶ < e < 2²⁵⁶ and be odd per [FIPS186].¶

It is recognized that, while the vast majority of RSA signatures are currently made using the RSASSA-PKCS1-v1_5 algorithm, the preferred RSA signature scheme for new applications is RSASSA-PSS. CNSA Suite-compliant X.509 certificates will be issued in accordance with [RFC8603], and while those certificates must be signed and validated using RSASSA-PKCS1-v1_5, the subject's private key can be used to generate signatures of either signing scheme. Where use of RSASSA-PSS is indicated in this document, the following parameters apply:¶

These parameters will not appear in a certificate and MUST be securely communicated with the signature, as required by Section 2.2 of [RFC4056]. Application developers are obliged to ensure that the chosen signature scheme is appropriate for the application and will be interoperable within the intended operating scope of the application.¶

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.¶

This profile was developed with the scenarios described in Appendix A in mind. However, use of this profile is not limited to just those scenarios.¶

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 of [RFC5272]). 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.¶

This profile does not discuss key establishment certification requests from cryptographic modules that cannot generate a one-time signature with a key establishment key for proof-of-possession purposes. In that case, a separate profile would be needed to define the use of another proof-of-possession technique.¶

4. 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 [RFC8755]. The PKIData content type defined in [RFC5272] is used with the following additional requirements:¶

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 and either ECDSA on P-384 or RSA using either RSASSA-PKCS1-v1_5 or RSASSA-PSS with an RSA-3072 or RSA-4096 key.¶

If an appropriate signature certificate does not yet exist and if a Full PKI Request includes one or more certification requests and is authenticated using a shared-secret (because no appropriate certificate exists yet to authenticate the request), the Full PKI Request MUST be signed using the private key corresponding to the public key of one of the requested certificates. When necessary (i.e., because there is no existing signature certificate and there is no signature certification request included), a Full PKI Request MAY be signed using a key pair intended for use in a key establishment certificate. However, servers are not required to allow this behavior.¶

5. 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 of [RFC5272]. 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.¶

      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...}

6. CA Requirements

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

      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)

7. 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 authorized CA certificate MUST include the id-kp-cmcCA EKU and/or a CCC extension that includes the object identifier for the PKIResponse content type. Otherwise, the CA is determined to be authorized to sign responses through an 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 authorized RA certificate MUST include the id-kp-cmcRA EKU and/or include a CCC extension that includes the object identifier for the PKIResponse content type. Otherwise, the RA is determined to be authorized to sign responses through local configuration.¶

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.¶

8. Shared-Secrets

When the Identity Proof V2 and POP Link Witness V2 controls are used, the shared-secret MUST be randomly generated and securely distributed. The shared-secret MUST provide at least 192 bits of strength.¶

9. Security Considerations

Protocol security considerations are found in [RFC2986], [RFC4211], [RFC8755], [RFC5272], [RFC5273], [RFC5274], [RFC8603], 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 [RFC8755].¶

Compliant with NIST Special Publication 800-57 [SP80057], this profile defines proof-of-possession of a key establishment private key by performing a digital signature. Except for one-time proof-of-possession, a single key pair MUST NOT be used for both signature and key establishment.¶

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.¶

Appendix A. 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.¶

Authors' Addresses