idnits 2.17.1 draft-vassilev-acvp-iana-00.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 21, 2019) is 1889 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TBD A. Vassilev, Ed. 3 Internet-Draft NIST 4 Intended status: Informational February 21, 2019 5 Expires: August 25, 2019 7 ACVP IANA Registry 8 draft-vassilev-acvp-iana-00 10 Abstract 12 This document defines a set of IANA registries for supported 13 cryptographic algorithm test specifications in the Automated 14 Cryptographic Validation Protocol (ACVP) [acvp]. This document also 15 shows how to extend the capabilities of ACVP with testing for new 16 cryptographic algorithms. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 25, 2019. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. IANA namespaces . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Algorithm registry . . . . . . . . . . . . . . . . . . . . . 3 55 4. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 56 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 58 6.1. ACVP URN Sub-namespace . . . . . . . . . . . . . . . . . 5 59 6.2. ACVP URN Parameters . . . . . . . . . . . . . . . . . . . 5 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 The Automated Cryptographic Validation Protocol (ACVP) [acvp] defines 67 a mechanism to automatically validate the cryptographic algorithm 68 implementations of software or hardware cryptographic modules. The 69 ACVP specification defines how a cryptographic module communicates 70 with a validation authority server, including cryptographic 71 capabilities negotiation, session management, authentication, test 72 vector processing and more. The ACVP specification does not define 73 algorithm-specific JSON constructs for performing the cryptographic 74 validation. A series of ACVP-related sub-specifications define the 75 constructs for testing individual cryptographic algorithms, see for 76 example [sub-symmetric]. Each such sub-specification addresses a 77 specific algorithm or a class of cryptographic algorithms. This 78 document defines the IANA registry for the supported algorithm test 79 specifications that work with ACVP. The registry defined here 80 provides the binding between the protocol and the supported algorithm 81 test extensions. 83 2. IANA namespaces 85 There are three namespaces envisioned for extensions to the ACVP: 87 o ACVP - the approved algorithms for testing with one or more 88 validation authorities 90 o EXPERIMENTAL - candidate algorithms for approval. 92 o LOCAL - locally supported algorithms, not guaranteed for 93 interoperability. Algorithms in this namespace cannot be 94 registered with IANA. 96 TBD 98 3. Algorithm registry 100 Each entry in the algorithm registry must record the following 101 fields: 103 o Name: a URN segment that conforms to the pattern 104 {namespace}-{algorithm}. The keywords are defined as follows: 106 * {namespace}: one of the options from Section 2. 108 * {algorithm}: a required US-ASCII string that conforms to the 109 URN syntax requirements (see [RFC8141]). This string must be 110 unique within the corresponding namespace. 112 o Revision: the revision identifier for the test specification of a 113 particular algorithm. A required US-ASCII string that conforms to 114 the URN syntax requirements (see [RFC8141]). 116 o Reference: A static link to the specification and section where 117 the definition of the parameter can be found. 119 +-------------------+----------+-----------------+ 120 | Name | Revision | Reference | 121 +-------------------+----------+-----------------+ 122 | "ACVP-AES-ECB" | "1.0" | [sub-symmetric] | 123 | "ACVP-AES-CBC" | "1.0" | [sub-symmetric] | 124 | "ACVP-AES-OFB" | "1.0" | [sub-symmetric] | 125 | "ACVP-AES-CFB1" | "1.0" | [sub-symmetric] | 126 | "ACVP-AES-CFB8" | "1.0" | [sub-symmetric] | 127 | "ACVP-AES-CFB128" | "1.0" | [sub-symmetric] | 128 | "ACVP-AES-CTR" | "1.0" | [sub-symmetric] | 129 | "ACVP-AES-GCM" | "1.0" | [sub-symmetric] | 130 | "ACVP-AES-CCM" | "1.0" | [sub-symmetric] | 131 | "ACVP-AES-XPN" | "1.0" | [sub-symmetric] | 132 | "ACVP-AES-CMAC" | "1.0" | [sub-symmetric] | 133 | "ACVP-AES-GMAC" | "1.0" | [sub-symmetric] | 134 | "ACVP-AES-KW" | "1.0" | [sub-symmetric] | 135 | "ACVP-AES-KWP" | "1.0" | [sub-symmetric] | 136 | "ACVP-AES-XTS" | "1.0" | [sub-symmetric] | 137 | "ACVP-TDES-ECB" | "1.0" | [sub-symmetric] | 138 | "ACVP-TDES-CBC" | "1.0" | [sub-symmetric] | 139 | "ACVP-TDES-OFB" | "1.0" | [sub-symmetric] | 140 | "ACVP-TDES-CFB1" | "1.0" | [sub-symmetric] | 141 | "ACVP-TDES-CFB8" | "1.0" | [sub-symmetric] | 142 | "ACVP-TDES-CFB64" | "1.0" | [sub-symmetric] | 143 | "ACVP-TDES-CTR" | "1.0" | [sub-symmetric] | 144 | "ACVP-TDES-KW" | "1.0" | [sub-symmetric] | 145 +-------------------+----------+-----------------+ 147 Table 1: Algorithm registry 149 4. Requirements Language 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted in RFC 2119 [RFC2119]. 155 5. Acknowledgements 157 Many thanks to David Waltermire for his helpful comments to get us 158 started on the right path. 160 6. IANA Considerations 162 This memo includes several requests to IANA. 164 6.1. ACVP URN Sub-namespace 166 IANA should add an entry to the "IETF URN Sub-namespace for 167 Registered Protocol Parameter Identifiers" registry located at 168 https://www.iana.org/assignments/params/ as per [RFC3553]. 170 The entry should be as follows: 172 Registered Parameter Identifier: ACVP 174 Specification: this document 176 Repository: ACVP URN Parameters (see Section 6.2) 178 6.2. ACVP URN Parameters 180 A new top-level registry should be created, titled "Automated 181 Cryptographic Validation Protocol (ACVP) URN Parameters". 183 Registration in the "ACVP URN Parameters" registry is via the 184 Specification Required policy [RFC8126]. Registration requests must 185 be sent to both the ACVP Working Group mailing list (acvp@ietf.org) 186 and IANA. IANA will forward registration requests to the Designated 187 Expert. 189 Each entry in this subregistry must record the following fields: 191 Name: A required US-ASCII string that conforms to the URN syntax 192 requirements (see [RFC8141]). This string MUST be constructed 193 according to the specification in Section 3. Note: entries from 194 the namespace "LOCAL" SHALL be forbidden from this table. 196 Revision: A required US-ASCII string that conforms to the URN 197 syntax requirements (see [RFC8141]). The combination 198 {Name}-{Revision} for each entry MUST be unique for the entire 199 subregistry. 201 Reference: A static link to the specification and section where 202 the definition of the parameter can be found. 204 This repository SHALL have as initial values the entries in Table 1. 206 7. Security Considerations 208 Security considerations are addressed by the ACVP specification. 210 8. Normative References 212 [acvp] Fussell, B., Vassilev, A., and H. Booth, "Automatic 213 Cryptographic Validation Protocol", 2018, 214 . 217 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 218 Requirement Levels", BCP 14, RFC 2119, 219 DOI 10.17487/RFC2119, March 1997, 220 . 222 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 223 IETF URN Sub-namespace for Registered Protocol 224 Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 225 2003, . 227 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 228 Writing an IANA Considerations Section in RFCs", BCP 26, 229 RFC 8126, DOI 10.17487/RFC8126, June 2017, 230 . 232 [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names 233 (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, 234 . 236 [sub-symmetric] 237 Celi, C., "ACVP Symmetric Algorithm JSON Specification", 238 2018, 239 . 242 Author's Address 244 Apostol Vassilev (editor) 245 NIST 246 100 Bureau Dr. 247 Gaithersburg, MD 20899 248 USA 250 Email: apostol.vassilev@nist.gov