Network Working Group M. Jenkins Internet-Draft L. Zieglar Intended status: Informational NSA Expires: August 11, 2019 February 7, 2019 Commercial National Security Algorithm (CNSA) Suite Profile of Certificate Management over CMS draft-jenkins-cnsa-cmc-profile-01 Abstract The United States government has published the NSA Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing X.509 public key certificates in applications using the CNSA Suite. It is a refinement of RFCs 5272, 5273, and 5274. 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. US National Security Systems are described in NIST Special Publication SP-800-59. 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. 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 August 11, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. Jenkins & Zieglar Expires August 11, 2019 [Page 1] Internet-Draft CNSA Suite CMC Profile February 2019 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Commercial National Security Algorithm Suite . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Requirements and Assumptions . . . . . . . . . . . . . . . . 4 5. Client Requirements: Generating PKI Requests . . . . . . . . 5 5.1. Tagged Certification Request . . . . . . . . . . . . . . 7 5.2. Certificate Request Message . . . . . . . . . . . . . . . 8 6. RA Requirements . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. RA Processing of Requests . . . . . . . . . . . . . . . . 9 6.2. RA-Generated PKI Requests . . . . . . . . . . . . . . . . 9 6.3. RA-Generated Errors . . . . . . . . . . . . . . . . . . . 10 7. CA Requirements . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. CA Processing of PKI Requests . . . . . . . . . . . . . . 11 7.2. CA-Generated PKI Responses . . . . . . . . . . . . . . . 11 8. Client Requirements: Processing PKI Responses . . . . . . . . 13 9. Shared-Secrets . . . . . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 12.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. Scenarios . . . . . . . . . . . . . . . . . . . . . 17 A.1. Initial Enrollment . . . . . . . . . . . . . . . . . . . 17 A.2. Rekey . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 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 [CNSSP15]. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems [SP-800-59]. It is also appropriate for all other US Government systems that process high-value information. It is made publicly Jenkins & Zieglar Expires August 11, 2019 [Page 2] Internet-Draft CNSA Suite CMC Profile February 2019 available for use by developers and operators of these and any other system deployments. This document does not define any new cryptographic algorithm suite; 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 [ID.cnsa-cert-profile]. This document specifically focuses on defining CMC interactions for both 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 USG transition to new algorithms, and to provide vendors - and the Internet community in general - with information concerning their proper use and configuration. Recently, cryptographic transition plans have become overshadowed by the prospect of the development of a cryptographically-relevant quantum computer. NSA has established the Commercial National Security Algorithm (CNSA) Suite to provide vendors and IT users near- term flexibility in meeting their IA interoperability requirements. The purpose behind this flexibility is to avoid vendors and customers making two major transitions in a relatively short timeframe, as we anticipate a need to shift to quantum-resistant cryptography in the near future. NSA is publishing 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. Jenkins & Zieglar Expires August 11, 2019 [Page 3] Internet-Draft CNSA Suite CMC Profile February 2019 3. 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 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. 4. Requirements and Assumptions Elliptic Curve Digital Signature Algorithm (ECDSA) and Elliptic Curve Diffie-Hellman (ECDH) key pairs are on the curve P-384. FIPS 186-4 [DSS], 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^16. [DSS] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", July 2013, . [ID.cnsa-cert-profile] Jenkins, M. and L. Zieglar, "Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile", January 2018, . Work in progress. [ID.cnsa-smime-profile] Jenkins, M., "Using CNSA Suite Algorithms in Secure/ Multipurpose Internet Mail Extensions(S/MIME)", February 2018. Work in progress. [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, . [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, DOI 10.17487/RFC4055, June 2005, . Jenkins & Zieglar Expires August 11, 2019 [Page 15] Internet-Draft CNSA Suite CMC Profile February 2019 [RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS)", RFC 4056, DOI 10.17487/RFC4056, June 2005, . [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, . [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC 4231, DOI 10.17487/RFC4231, December 2005, . [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, . [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 2010, . [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, . Jenkins & Zieglar Expires August 11, 2019 [Page 16] Internet-Draft CNSA Suite CMC Profile February 2019 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 12.2. Informative References [SP-800-59] National Institute of Standards and Technology, "Guideline for Identifying an Information System as a National Security System", Special Publication 800 59, August 2003, final>. [SP80057] National Institute of Standards and Technology, "Recommendation for Key Management, Part 1: General", January 2016, . [SP80090] National Institute of Standards and Technology, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", June 2015, . 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. A.1. Initial Enrollment This section describes three scenarios for authenticating initial enrollment requests: 1. Previously installed signature certificate (e.g., Manufacturer Installed Certificate); 2. Shared-secret distributed securely out-of-band; 3. RA authentication. Jenkins & Zieglar Expires August 11, 2019 [Page 17] Internet-Draft CNSA Suite CMC Profile February 2019 A.1.1. Previously Installed Signature Certificate In this scenario, the end-entity has had a signature certificate installed by the cryptographic module manufacturer. As the end- entity already has a signature certificate, it can be used to authenticate a request for a new certificate. The end-entity signs the Full PKI Request with the private key that corresponds to the subject public key of a previously installed signature certificate. The CA will recognize the authorization of the previously installed certificate and issue an appropriate certificate to the end-entity. A.1.2. 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 in the end-entity's enclosed PKCS #10 [RFC2986] or CRMF [RFC4211] certification request message to identify the request. The end-entity performs either the POP Link Witness Version 2 mechanism as described in [RFC5272], Section 6.3.1.1, or the Shared-Subject/Subject Distinguished Name (DN) linking mechanism as described in [RFC5272], Section 6.3.2. The Subject in the enclosed PKCS #10 [RFC2986] or CRMF [RFC4211] certification request does not necessarily match the issued certificate, as it may be used just to help identify the request (and corresponding shared-secret) to the CA. A.1.3. 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 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, then, if approved, encapsulates and signs the request as described in Section 5.2, forwarding the new request on to the CA. The Subject in the PKCS #10 [RFC2986] or CRMF [RFC4211] 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. A.2. 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. Jenkins & Zieglar Expires August 11, 2019 [Page 18] Internet-Draft CNSA Suite CMC Profile February 2019 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. A.2.1. Rekey of Signature Certificates When a signature certificate is rekeyed, the PKCS #10 [RFC2986] or CRMF [RFC4211] certification request message enclosed in the Full PKI Request will include the same Subject as the current signature certificate. The Full PKI Request will be signed by the current private key corresponding to the current signature certificate. A.2.2. 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 Appendix A.1 may be used. Authors' Addresses Michael Jenkins National Security Agency Email: mjjenki@nsa.gov Lydia Zieglar National Security Agency Email: llziegl@ntycho.ncsc.mil Jenkins & Zieglar Expires August 11, 2019 [Page 19]