idnits 2.17.1 draft-jenkins-cnsa-cert-crl-profile-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 7, 2019) is 1902 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Jenkins 3 Internet-Draft L. Zieglar 4 Intended status: Informational NSA 5 Expires: August 11, 2019 February 7, 2019 7 Commercial National Security Algorithm (CNSA) Suite Certificate and 8 Certificate Revocation List (CRL) Profile 9 draft-jenkins-cnsa-cert-crl-profile-06 11 Abstract 13 This document specifies a base profile for X.509 v3 Certificates and 14 X.509 v2 Certificate Revocation Lists (CRLs) for use with the United 15 States National Security Agency's Commercial National Security 16 Algorithm (CNSA) Suite. The reader is assumed to have familiarity 17 with RFC 5280, "Internet X.509 Public Key Infrastructure Certificate 18 and Certificate Revocation List (CRL) Profile". The profile applies 19 to the capabilities, configuration, and operation of all components 20 of US National Security Systems that employ such X.509 certificates. 21 US National Security Systems are described in NIST Special 22 Publication 800-59. It is also appropriate for all other US 23 Government systems that process high-value information. It is made 24 publicly available for use by developers and operators of these and 25 any other system deployments. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 11, 2019. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. The Commercial National Security Algorithm Suite . . . . . . 3 63 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. General Requirements and Assumptions . . . . . . . . . . . . 4 65 4.1. Implementing the CNSA Suite . . . . . . . . . . . . . . . 4 66 4.2. CNSA Suite Object Identifiers . . . . . . . . . . . . . . 5 67 5. CNSA Suite Base Certificate Required Values . . . . . . . . . 6 68 5.1. signatureAlgorithm . . . . . . . . . . . . . . . . . . . 6 69 5.2. signatureValue . . . . . . . . . . . . . . . . . . . . . 7 70 5.3. Version . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 5.4. SubjectPublicKeyInfo . . . . . . . . . . . . . . . . . . 7 72 6. Certificate Extensions for Particular Types of Certificates . 8 73 6.1. CNSA Suite Self-Signed CA Certificates . . . . . . . . . 8 74 6.2. CNSA Suite Non-Self-Signed CA Certificates . . . . . . . 8 75 6.3. CNSA Suite End Entity Signature and Key Establishment 76 Certificates . . . . . . . . . . . . . . . . . . . . . . 9 77 7. CNSA Suite CRL Requirements . . . . . . . . . . . . . . . . . 10 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 82 10.2. Informative References . . . . . . . . . . . . . . . . . 11 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 85 1. Introduction 87 This document specifies a base profile for X.509 v3 Certificates and 88 X.509 v2 Certificate Revocation Lists (CRLs) for use by applications 89 that support the United States National Security Agency's Commercial 90 National Security Algorithm (CNSA) Suite [CNSA]. The profile applies 91 to the capabilities, configuration, and operation of all components 92 of US National Security Systems that employ such X.509 certificates. 93 US National Security Systems are described in NIST Special 94 Publication 800-59 [SP-800-59]. It is also appropriate for all other 95 US Government systems that process high-value information. It is 96 made publicly available for use by developers and operators of these 97 and any other system deployments. 99 This document does not define any new cryptographic algorithm suite; 100 instead, it defines a CNSA compliant profile of [RFC5280]. It 101 applies to all CNSA Suite solutions that make use of X.509 v3 102 Certificates or X.509 v2 CRLs. The reader is assumed to have 103 familiarity with RFC 5280. All MUST-level requirements of RFC 5280 104 apply throughout this profile and are generally not repeated here. 105 In cases where a MUST-level requirement is repeated for emphasis, the 106 text notes the requirement is "in adherence with RFC 5280". This 107 profile contains changes that elevate some SHOULD-level options in 108 RFC 5280 to MUST-level for this profile; this profile also contains 109 changes that elevate some MAY-level options in RFC 5280 to SHOULD- 110 level or MUST-level in this profile. All options from RFC 5280 that 111 are not listed in this profile remain at the requirement level of RFC 112 5280. 114 The reader is also assumed to have familiarity with these documents: 116 o [RFC5480] for the syntax and semantics for the Subject Public Key 117 Information field in certificates that support Elliptic Curve 118 Cryptography; 120 o [RFC5758] for the algorithm identifiers for Elliptic Curve Digital 121 Signature Algorithm (ECDSA); 123 o [RFC3279] for the syntax and semantics for the Subject Public Key 124 Information field in certificates that support RSA Cryptography; 125 and 127 o [RFC4055] for the algorithm identifiers for RSA Cryptography with 128 the SHA-384 hash function. 130 2. The Commercial National Security Algorithm Suite 132 The National Security Agency (NSA) profiles commercial cryptographic 133 algorithms and protocols as part of its mission to support secure, 134 interoperable communications for US Government National Security 135 Systems. To this end, it publishes guidance both to assist with the 136 USG transition to new algorithms, and to provide vendors - and the 137 Internet community in general - with information concerning their 138 proper use and configuration. 140 Recently, cryptographic transition plans have become overshadowed by 141 the prospect of the development of a cryptographically-relevant 142 quantum computer. NSA has established the Commercial National 143 Security Algorithm (CNSA) Suite to provide vendors and IT users near- 144 term flexibility in meeting their IA interoperability requirements. 145 The purpose behind this flexibility is to avoid vendors and customers 146 making two major transitions in a relatively short timeframe, as we 147 anticipate a need to shift to quantum-resistant cryptography in the 148 near future. 150 NSA is publishing a set of RFCs, including this one, to provide 151 updated guidance concerning the use of certain commonly available 152 commercial algorithms in IETF protocols. These RFCs can be used in 153 conjunction with other RFCs and cryptographic guidance (e.g., NIST 154 Special Publications) to properly protect Internet traffic and data- 155 at-rest for US Government National Security Systems. 157 3. Conventions 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 161 "OPTIONAL" in this document are to be interpreted as described in BCP 162 14 [RFC2119] [RFC8174] when, and only when, they appear in all 163 capitals, as shown here. 165 4. General Requirements and Assumptions 167 The goal of this document is to define a base set of requirements for 168 certificates and CRLs to support interoperability among CNSA Suite 169 solutions. Specific communities, such as those associated with US 170 National Security Systems, may define community profiles that further 171 restrict certificate and CRL contents by mandating the presence of 172 extensions that are optional in this base profile, defining new 173 optional or critical extension types, or restricting the values and/ 174 or presence of fields within existing extensions. However, 175 communications between distinct communities MUST conform to the 176 requirements specified in this document when interoperability is 177 desired. Applications may add requirements for additional non- 178 critical extensions but they MUST NOT assume that a remote peer will 179 be able to process them. 181 4.1. Implementing the CNSA Suite 183 Every CNSA Suite certificate MUST use the X.509 v3 format, and 184 contain either: 186 o An ECDSA-capable signature verification key using curve P-384; or 188 o An ECDH-capable (Elliptic Curve Diffie-Hellman) key establishment 189 key using curve P-384; or 191 o An RSA-capable signature verification key using RSA-3072 or RSA- 192 4096; or 194 o An RSA-capable key transport key using RSA-3072 or RSA-4096. 196 The signature algorithm applied to all CNSA Suite certificates and 197 CRLs MUST be made with a signing key generated on the curve P-384, or 198 that is an RSA-3072 or RSA-4096 key, and with the SHA-384 hashing 199 algorithm. 201 RSA exponents e MUST satisfy 2^16. 461 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 462 Requirement Levels", BCP 14, RFC 2119, 463 DOI 10.17487/RFC2119, March 1997, 464 . 466 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 467 Identifiers for the Internet X.509 Public Key 468 Infrastructure Certificate and Certificate Revocation List 469 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 470 2002, . 472 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 473 Algorithms and Identifiers for RSA Cryptography for use in 474 the Internet X.509 Public Key Infrastructure Certificate 475 and Certificate Revocation List (CRL) Profile", RFC 4055, 476 DOI 10.17487/RFC4055, June 2005, 477 . 479 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 480 Housley, R., and W. Polk, "Internet X.509 Public Key 481 Infrastructure Certificate and Certificate Revocation List 482 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 483 . 485 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 486 "Elliptic Curve Cryptography Subject Public Key 487 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 488 . 490 [RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. 491 Polk, "Internet X.509 Public Key Infrastructure: 492 Additional Algorithms and Identifiers for DSA and ECDSA", 493 RFC 5758, DOI 10.17487/RFC5758, January 2010, 494 . 496 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 497 "PKCS #1: RSA Cryptography Specifications Version 2.2", 498 RFC 8017, DOI 10.17487/RFC8017, November 2016, 499 . 501 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 502 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 503 May 2017, . 505 [SEC1] Standards for Efficient Cryptography Group, "SEC1: 506 Elliptic Curve Cryptography", May 2009, 507 . 509 10.2. Informative References 511 [CNSA] Committee for National Security Systems, "Commercial 512 National Security Algorithm (CNSA) Suite", 2015, 513 . 516 [SEC2] Standards for Efficient Cryptography Group, "SEC 2: 517 Recommended Elliptic Curve Domain Parameters", September 518 2000. 520 [SP-800-57] 521 Barker, E., "Recommendation for Key Management-Part 1 522 Revision 4: General", Special Publication 800 57, January 523 2016, 524 . 527 [SP-800-59] 528 Barker, W., "Guideline for Identifying an Information 529 System as a National Security System", Special Publication 530 800 59, August 2003, 531 532 final>. 534 [X9.62] American National Standards Institute, "Public Key 535 Cryptography for the Financial Services Industry; The 536 Elliptic Curve Digital Signature Algorithm (ECDSA)", 537 ANS X9.62, December 2005. 539 Authors' Addresses 541 Michael Jenkins 542 National Security Agency 544 Email: mjjenki@nsa.gov 546 Lydia Zieglar 547 National Security Agency 549 Email: llziegl@tycho.ncsc.mil