idnits 2.17.1 draft-ietf-lamps-pkix-shake-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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 18 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 145: '... the encoding SHALL omit the paramet...' RFC 2119 keyword, line 146: '...orithmIdentifier SHALL be a SEQUENCE o...' RFC 2119 keyword, line 152: '...ificates or CRLs MUST generate such DS...' RFC 2119 keyword, line 176: '... the encoding MUST omit the paramete...' RFC 2119 keyword, line 177: '...orithmIdentifier SHALL be a SEQUENCE o...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2017) is 2341 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA3' Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LAMPS WG P. Kampanakis 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track Q. Dang 5 Expires: May 3, 2018 NIST 6 October 30, 2017 8 Put Your Internet Draft Title Here 9 draft-ietf-lamps-pkix-shake-00 11 Abstract 13 This document describes the conventions for using the SHAKE family of 14 hash functions in the Internet X.509 PKI as one-way hash functions 15 with the RSA, DSA and ECDSA signature algorithms; the conventions for 16 the associated subject public keys are also described. Digital 17 signatures are used to sign messages, certificates and CRLs 18 (Certificate Revocation Lists). 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 3, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. Algorithm support . . . . . . . . . . . . . . . . . . . . . . 2 57 3.1. SHAKE One-Way Hash Functions . . . . . . . . . . . . . . 2 58 3.2. Signature Algorithms . . . . . . . . . . . . . . . . . . 3 59 3.2.1. RSA with SHAKE . . . . . . . . . . . . . . . . . . . 3 60 3.2.2. DSA with SHAKE . . . . . . . . . . . . . . . . . . . 3 61 3.2.3. ECDSA with SHAKE . . . . . . . . . . . . . . . . . . 4 62 3.3. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 7.2. Informative References . . . . . . . . . . . . . . . . . 7 69 Appendix A. ASN.1 module . . . . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Change Log 74 o draft-kampanakis-adding-shake-to-pkix-00: 76 * Initial version 78 2. Introduction 80 EDNOTE: More here. 82 3. Algorithm support 84 This section describes several cryptographic algorithms which may be 85 used with the Internet X.509 Certificate and CRL profile [RFC5280]. 86 This section describes two one-way hash functions and digital 87 signature algorithms using these functions, which may be used to sign 88 certificates and CRLs, and identifies OIDs (Object Identifiers) for 89 public keys contained in certificates. 91 3.1. SHAKE One-Way Hash Functions 93 The SHA-3 family of one-way hash functions is specified in [SHA3]. 94 In the SHA-3 family, two extendable-output functions, called SHAKE128 95 and SHAKE256 are defined. Four hash functions, SHA3-224, SHA3-256, 96 SHA3-384, and SHA3-512 are also defined but are out of scope for this 97 document. The output lengths, in bits, of the SHAKE hash functions 98 is defined by the parameter d. The corresponding collision and 99 preimage resistance security levels for SHAKE128 and SHAKE256 are 100 respectively min(d/2,128) and min(d,128) and min(d/2,256) and 101 min(d,256). The OIDs (Object Identifiers) for these two hash 102 functions are as follows: 104 id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 105 country(16) us(840) organization(1) gov(101) csor(3) 106 nistalgorithm(4) hashalgs(2) 11 } 108 id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 109 country(16) us(840) organization(1) gov(101) csor(3) 110 nistalgorithm(4) hashalgs(2) 12 } 112 The output length, d, is always 256 and 512 bits for SHAKE128 and 113 SHAKE256 respectively in this specification. 115 3.2. Signature Algorithms 117 3.2.1. RSA with SHAKE 119 EDNOTE: To be discussed by the WG about what RSA standard with SHAKE 120 is to be covered by this draft. 122 shake128WithRSAEncryption OBJECT IDENTIFIER ::= { } 124 shake256withRSAEncryption OBJECT IDENTIFIER ::= { } 126 3.2.2. DSA with SHAKE 128 The DSA algorithm is defined in the Digital Signature Standard (DSS) 129 [FIPS186-4]. When SHAKE128 is used with DSA, the OID is: 131 id-dsa-with-shake128 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 132 country(16) us(840) organization(1) gov(101) csor(3) 133 algorithms(4) id-dsa-with-shake(3) x } 135 When SHAKE256 is used with DSA, the OID is: 137 id-dsa-with-shake256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 138 country(16) us(840) organization(1) gov(101) csor(3) algorithms(4) 139 id-dsa-with-shake(3) y } 141 EDNOTE: "x" and "y" will be specified by NIST later. 143 When the id-dsa-with-shake128 or id-dsa-with-shake256 algorithm 144 identifier appears in the algorithm field as an AlgorithmIdentifier, 145 the encoding SHALL omit the parameters field. That is, the 146 AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id- 147 dsa-with-shake128 or id-dsa-with-shake256. 149 Encoding rules for DSA signature values are specified in [RFC3279]. 151 Conforming CA implementations that generate DSA signatures for 152 certificates or CRLs MUST generate such DSA signatures in accordance 153 with all the requirements in Section 4 in [FIPS186-4]. The lengths 154 of p and q must be at least 2048 and 224 bits respectively. 156 3.2.3. ECDSA with SHAKE 158 The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in 159 "Public Key Cryptography for the Financial Services Industry: The 160 Elliptic Curve Digital Signature Standard (ECDSA)" [X9.62]. The 161 ASN.1 OIDs of ECDSA signature algorithms using SHAKE128 and SHAKE256, 162 are below: 164 id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 165 country(16) us(840) organization(1) gov(101) csor(3) algorithms(4) 166 id-ecdsa-with-shake(3) x } 168 id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 169 country(16) us(840) organization(1) gov(101) csor(3) algorithms(4) 170 id-ecdsa-with-shake(3) y } 172 EDNOTE: "x" and "y" will be specified by NIST later. 174 When the id-ecdsa-with-SHAKE128 or id-ecdsa-with-SHAKE256, algorithm 175 identifier appears in the algorithm field as an AlgorithmIdentifier, 176 the encoding MUST omit the parameters field. That is, the 177 AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID 178 ecdsa-with-SHAKE128 or ecdsa-with-SHAKE256. 180 Conforming CA implementations MUST specify the hash algorithm 181 explicitly using the OIDs specified above when encoding ECDSA/SHAKE 182 signatures in certificates and CRLs. 184 Conforming client implementations that process ECDSA signatures with 185 any of the SHAKE hash algorithms when processing certificates and 186 CRLs MUST recognize the corresponding OIDs specified above. 188 Encoding rules for ECDSA signature values are specified in [RFC3279], 189 Section 2.2.3, and [RFC5480]. 191 Conforming CA implementations that generate ECDSA signatures in 192 certificates or CRLs MUST generate such ECDSA signatures in 193 accordance with all the requirements specified in Sections 7.2 and 194 7.3 of [X9.62] or with all the requirements specified in 195 Section 4.1.3 of [SEC1]. They MAY also generate such ECDSA 196 signatures in accordance with all the recommendations in [X9.62] or 197 [SEC1] if they have a stated policy that requires conformance to 198 these standards. These standards above may have not specified 199 SHAKE128 and SHAKE256 as hash algorithm options. However, SHAKE128 200 and SHAKE256 with output length being 256 and 512 bits respectively 201 are subtitutions for 256 and 512-bit output hash algorithms such as 202 SHA256 and SHA512 used in the standards. 204 EDNOTE: Depending on the updates to the Charter, the group may want 205 to consider an EdDSA with SHAKE section here. 207 3.3. Public Keys 209 The conventions for RSA, DSA and ECDSA public keys are as specified 210 in [RFC3279] and [RFC5480]. 212 We include them here for convenience: 214 EDNOTE: Add the public key OIDs here. 216 ... OBJECT IDENTIFIER ::= { } 218 ... OBJECT IDENTIFIER ::= { } 220 4. Acknowledgements 222 We would like to thank Sean Turner for his valuable contributions to 223 this document. 225 5. IANA Considerations 227 IANA is kindly requested to register two OIDs in the SMI Security for 228 PKIX Module Identifier registry for the ASN.1 modules found in 229 Appendix A. The description is as follows: 231 o EDNOTE: More here 233 where the four digits at the end represent the ASN.1's publication 234 date. 236 6. Security Considerations 238 EDNOTE: More here. 240 7. References 242 7.1. Normative References 244 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 245 Identifiers for the Internet X.509 Public Key 246 Infrastructure Certificate and Certificate Revocation List 247 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 248 2002, . 250 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 251 Housley, R., and W. Polk, "Internet X.509 Public Key 252 Infrastructure Certificate and Certificate Revocation List 253 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 254 . 256 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 257 "Elliptic Curve Cryptography Subject Public Key 258 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 259 . 261 [SHA3] National Institute of Standards and Technology, "SHA-3 262 Standard - Permutation-Based Hash and Extendable-Output 263 Functions FIPS PUB 202", August 2015, 264 . 267 7.2. Informative References 269 [FIPS186-4] 270 National Institute of Standards and Technology, "Digital 271 Signature Standard (DSS) FIPS PUB 186-4", July 2013, 272 . 275 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 276 Elliptic Curve Cryptography", May 2009, 277 . 279 [X9.62] American National Standard for Financial Services (ANSI), 280 "X9.62-2005 Public Key Cryptography for the Financial 281 Services Industry: The Elliptic Curve Digital Signature 282 Standard (ECDSA)", November 2005. 284 Appendix A. ASN.1 module 286 EDNOTE: More here. 288 Authors' Addresses 290 Panos Kampanakis 291 Cisco Systems 293 Email: pkampana@cisco.com 295 Quynh Dang 296 NIST 297 100 Bureau Drive, Stop 8930 298 Gaithersburg, MD 20899-8930 299 USA 301 Email: quynh.dang@nist.gov