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